Как устроен AI в нашем “AI-стартапе”, или что нового я понял перейдя из рисерча в топ-лабах о решении реальных проблем. Рассказываю инженерам.
Это майндсет бизнес-овнера, чем раньше вы его усвоите, тем быстрее вы вылезете из своей песочницы с формулами и начнете делать импакт, а с ним и расти в лид-позиции.
1. Всем поебать что вы там используете, на сколько большие у вас сетки, на сколько инновационный подход, доказана ли у вас полнота пространства, и какой сплит кросс валидации. По большому счету все, за что у вас в академии откусят жёпу, юзеру не интересно, и не влияет на ваш бизнес. Влияет только одно: работает или нет. “Это реально сделать?”, “Много менять придется?”, “Петрович, готов уже МЛ или остужать контейнеры?” – это вопросы которые определяют развитие продукта и ценность МЛ для него. Следовательно.
2. Работать сделать проще всего то, что ты понимаешь и можешь запустить малой кровью. Поэтому самые полезные в реальном применение вещи это эвристики или коробочные решения с простым интерфейсом. Если что-то нужно дописывать, настраивать, подстраивать, контролировать – для этого нужна отдельная команда, и в стартапе на это времени нет. Pro tip: очень хорошо работают комбинации сложных черных ящиков (например трансформеров), которые дают примитивы (например векторы фичей), и простая логика для обработки этих примитивов поверх.
3. Дебажить проще всего то, что ты понимаешь. Никому не нужны сюрпризы в проде. Даже если модель фейлит в 2% случаев, но фейлит конкретно – ее уже нельзя использовать. Поэтому, или такие случаи нужно очень хорошо знать, и подкреплять их эвристикой, или использовать эвристику и простые правила с самого начала.
4. Реальный мир непредсказуем, никаких контролируемых условий нет, все должно быть универсально и пуленепробиваемо. То-есть, никаких 5 гиперпараметров, которые нужно подкручивать для разных knowledge domains, и никакие приближения, типо ограничимся товарами с заказами или магазинами одежды, не проканают. Я вам скажу больше, мы очень старались над тем, чтобы полностью уйти от абсолютных значений, и перевести все в относительную форму. Практически все можно нормализовать, отсортировать и отсечь через статистику (топ-5, нижний квартиль, и тд). Константы вызывают рак.
5. Вы должны хорошо понимать проблему которую юзер решает, и быть способным описать идеальное решение из первых принципов. Жирным, потому что самое важное. Не 1., потому что проебался. Но. Вы не должны оперировать “какими-то” коэффициентами. Вы упростите себе жизнь когда станете понимать, что каждый коэффициент значит, и выбросите все то, что не понимаете. Меньше иногда больше. Таким образом вы сами сможете приходить к известным решениям, но уже с пониманием как они работают, и как они относятся к другим вариантам решения. И я не говорю знать все формулы или доказывать теоремы, я говорю понимать, что вы делаете, и главное почему так, а не иначе. Мы так сами вывели много формул, без сложной теории, а чисто из логики и базовой статистики, и смогли улучшить для нашего конкретного случая то, что другие берут не думая. Например, мы понимаем общий принцип для которого коллаборативная фильтрация является частным случаем, знаем как там информация движется, и можем ее улучшить. Из знания матричной факторизации, что является просто имплементацией, к этому не прийти, вы сможете улучшить только имплементацию. Это как понимать реализацию формулы в коде против понимания того как формула работает. Проверки понимания – вы должны мочь объяснить принцип работы пошагово на пальцах, можно с абстракциями, но без формул.
6. У всего есть цена. Рисерчить новый алгоритм ради рисерча не получится. R&D стоит денег и времени, и в стартапе еще неизвестно что из этого дороже. Как правило, последние 10% результата будут занимать 90% времени, поэтому однозначно надо ориентироваться на первые 10% усилий, и на соотношение impact/effort, а не на accuracy или AUC. (Это как elbow метод, нужно найти момент когда прирост падает я и ваши усилия выходят на асимптоту).
Это майндсет бизнес-овнера, чем раньше вы его усвоите, тем быстрее вы вылезете из своей песочницы с формулами и начнете делать импакт, а с ним и расти в лид-позиции.
1. Всем поебать что вы там используете, на сколько большие у вас сетки, на сколько инновационный подход, доказана ли у вас полнота пространства, и какой сплит кросс валидации. По большому счету все, за что у вас в академии откусят жёпу, юзеру не интересно, и не влияет на ваш бизнес. Влияет только одно: работает или нет. “Это реально сделать?”, “Много менять придется?”, “Петрович, готов уже МЛ или остужать контейнеры?” – это вопросы которые определяют развитие продукта и ценность МЛ для него. Следовательно.
2. Работать сделать проще всего то, что ты понимаешь и можешь запустить малой кровью. Поэтому самые полезные в реальном применение вещи это эвристики или коробочные решения с простым интерфейсом. Если что-то нужно дописывать, настраивать, подстраивать, контролировать – для этого нужна отдельная команда, и в стартапе на это времени нет. Pro tip: очень хорошо работают комбинации сложных черных ящиков (например трансформеров), которые дают примитивы (например векторы фичей), и простая логика для обработки этих примитивов поверх.
3. Дебажить проще всего то, что ты понимаешь. Никому не нужны сюрпризы в проде. Даже если модель фейлит в 2% случаев, но фейлит конкретно – ее уже нельзя использовать. Поэтому, или такие случаи нужно очень хорошо знать, и подкреплять их эвристикой, или использовать эвристику и простые правила с самого начала.
4. Реальный мир непредсказуем, никаких контролируемых условий нет, все должно быть универсально и пуленепробиваемо. То-есть, никаких 5 гиперпараметров, которые нужно подкручивать для разных knowledge domains, и никакие приближения, типо ограничимся товарами с заказами или магазинами одежды, не проканают. Я вам скажу больше, мы очень старались над тем, чтобы полностью уйти от абсолютных значений, и перевести все в относительную форму. Практически все можно нормализовать, отсортировать и отсечь через статистику (топ-5, нижний квартиль, и тд). Константы вызывают рак.
5. Вы должны хорошо понимать проблему которую юзер решает, и быть способным описать идеальное решение из первых принципов. Жирным, потому что самое важное. Не 1., потому что проебался. Но. Вы не должны оперировать “какими-то” коэффициентами. Вы упростите себе жизнь когда станете понимать, что каждый коэффициент значит, и выбросите все то, что не понимаете. Меньше иногда больше. Таким образом вы сами сможете приходить к известным решениям, но уже с пониманием как они работают, и как они относятся к другим вариантам решения. И я не говорю знать все формулы или доказывать теоремы, я говорю понимать, что вы делаете, и главное почему так, а не иначе. Мы так сами вывели много формул, без сложной теории, а чисто из логики и базовой статистики, и смогли улучшить для нашего конкретного случая то, что другие берут не думая. Например, мы понимаем общий принцип для которого коллаборативная фильтрация является частным случаем, знаем как там информация движется, и можем ее улучшить. Из знания матричной факторизации, что является просто имплементацией, к этому не прийти, вы сможете улучшить только имплементацию. Это как понимать реализацию формулы в коде против понимания того как формула работает. Проверки понимания – вы должны мочь объяснить принцип работы пошагово на пальцах, можно с абстракциями, но без формул.
6. У всего есть цена. Рисерчить новый алгоритм ради рисерча не получится. R&D стоит денег и времени, и в стартапе еще неизвестно что из этого дороже. Как правило, последние 10% результата будут занимать 90% времени, поэтому однозначно надо ориентироваться на первые 10% усилий, и на соотношение impact/effort, а не на accuracy или AUC. (Это как elbow метод, нужно найти момент когда прирост падает я и ваши усилия выходят на асимптоту).