Чем ML в корпорации отличается от ML в стартапе. Или как инженеру вырасти до business owner'а

Здесь я рассказываю как устроен AI в нашем “AI-стартапе”, или что нового я понял перейдя из исследователя в топ-лабах о решении реальных проблем. На данный момент я CTO в Suggestr, YC W22, где мы занимаемся продвинутыми рекомендациями. До этого я был в Facebook AI Research.

Это майндсет бизнес-овнера, чем раньше вы его усвоите, тем быстрее вы вылезете из своей песочницы с формулами и начнете делать импакт, а с ним и расти в лид-позиции.

1. Никому не важно, что вы там используете, на сколько большие у вас сетки, на сколько инновационный подход, доказана ли у вас полнота пространства, и какой сплит кросс валидации. По большому счету все, за что у вас в академии закидают камнями, юзеру не интересно, и не влияет на ваш бизнес. Влияет только одно: работает или нет. «Это реально сделать?”, “Много менять придется?”, »Петрович, готов уже МЛ или остужать контейнеры?” – это вопросы которые определяют развитие продукта и ценность МЛ для него. Следовательно.

2. Работать сделать проще всего то, что ты понимаешь и можешь запустить малой кровью. Поэтому самые полезные в реальном применение вещи это эвристики или коробочные решения с простым интерфейсом. Если что-то нужно дописывать, настраивать, подстраивать, контролировать – для этого нужна отдельная команда, и в стартапе на это времени нет. Pro tip: очень хорошо работают комбинации сложных черных ящиков (например трансформеров) , которые дают примитивы (например векторы фичей), и простая логика для обработки этих примитивов поверх.

3. Дебажить проще всего то, что ты понимаешь. Никому не нужны сюрпризы в проде. Даже если модель фейлит в 2% случаев, но фейлит конкретно – ее уже нельзя использовать. Поэтому, или такие случаи нужно очень хорошо знать, и подкреплять их эвристикой, или использовать эвристику и простые правила с самого начала.

4. Реальный мир непредсказуем, никаких контролируемых условий нет, все должно быть универсально и пуленепробиваемо. То-есть, никаких 5 гиперпараметров, которые нужно подкручивать для разных knowledge domains, и никакие приближения, типо ограничимся товарами с заказами или магазинами одежды, не проканают. Я вам скажу больше, мы очень старались над тем, чтобы полностью уйти от абсолютных значений, и перевести все в относительную форму. Практически все можно нормализовать, отсортировать и отсечь через статистику (топ-5, нижний квартиль, и тд). Константы вызывают рак.

5. Вы должны хорошо понимать проблему которую юзер решает, и быть способным описать идеальное решение из первых принципов. Жирным, потому что самое важное. Вы не должны оперировать “какими-то” коэффициентами. Вы упростите себе жизнь когда станете понимать, что каждый коэффициент значит, и выбросите все то, что не понимаете. Меньше иногда больше. Таким образом вы сами сможете приходить к известным решениям, но уже с пониманием как они работают, и как они относятся к другим вариантам решения. И я не говорю знать все формулы или доказывать теоремы, я говорю понимать, что вы делаете, и главное почему так, а не иначе. Мы так сами вывели много формул, без сложной теории, а чисто из логики и базовой статистики, и смогли улучшить для нашего конкретного случая то, что другие берут не думая. Например, мы понимаем общий принцип для которого коллаборативная фильтрация является частным случаем, знаем как там информация движется, и можем ее улучшить. Из знания матричной факторизации, что является просто имплементацией, к этому не прийти, вы сможете улучшить только имплементацию. Это как понимать реализацию формулы в коде против понимания того как формула работает. Проверки понимания – вы должны мочь объяснить принцип работы пошагово на пальцах, можно с абстракциями, но без формул.

6. У всего есть цена. Рисерчить новый алгоритм ради рисерча не получится. R&D стоит денег и времени, и в стартапе еще неизвестно что из этого дороже. Как правило, последние 10% результата будут занимать 90% времени, поэтому однозначно надо ориентироваться на первые 10% усилий, и на соотношение impact/effort, а не на accuracy или AUC. (Это как elbow метод, нужно найти момент когда прирост падает я и ваши усилия выходят на асимптоту).

7. МЛ не существует в вакууме. Для него нужны данные, для данных нужно хранилище, для запуска нужны ресурсы, нужна инфра, нужна бекенд-логика. Здесь, опять же, не получится просто прикрутить вторую модель на ТФ когда первая на пайторче, потому что зависимости улетят в космос. Не получится использовать любые данные, и не получится съедать все ресурсы машины или допускать краши. Нужно думать про соседей, потому что дырка в стене это проблема для обоих.

8. МЛ не существует в моменте, и точно запускается не только во время тестирования. Вы должны понимать что ваша модель будет крутиться в облаке 24/7, и если вы заранее не позаботитесь, чтобы ее кручению ничего не препятствовало, то будете просыпаться ночами и крутиться вместе с ней. МЛ нужно поддерживать, и чем этой поддержки меньше, тем лучше.

Итого: бизнес не оценит крутость, модность, новизну, и даже интеллектуальность ваших алгоритмов, что действительно ценится это простота, прозрачность, эффективность в решении поставленной задачи, и стоимость внедрения и поддержки. Тащемта, то же можно сказать и про самого МЛ-инженера.

* Это зацензурированный репост из телеграм-канала.