R&D-стратегия

Когда я начинал заниматься МЛ, моя жизнь была полна страданий. Я пришел в область из софтверной инженерии, соответсвенно подходил к мл проектам, как к софтверным: декомпозировал большую задачу на маленькие, строил план работы и шел по нему. Такое планирование сверху вниз, где какие-то дизайн решения принимаются из идейных соображений на старте проекта, а уже потом обрастают конкретикой и кодом. Если архитектура хорошая - то проблем будет мало, если плохая - много.

Экзекьюшн таких проектов - тоже относительно прямолинейный. Выписываешь зависимости, рисуешь сосиски-ганты и идешь по нему. Риски закладываешь более длинными сосисками. Если проект более непонятный - дизайнишь помельче, планируешь покороче (вот вам и скрам). Если все ясно, или в проекте очень много дорогих взаимозависимостей - то можно и водопадом течь. Возможны пивоты, но вообще считаем, что в основном мы все делаем скорее правильно. Основные риски в том, что ты сам тактически где-то накосячишь.

Но с МЛ дело другое - там чаще риск в том, что задача в принципе не решаема в необходимых ограничениях. А во вторых это очень data-driven системы. Когда меня спрашивают «как нам строить агентов саппорта» мой ответ - не знаю. В зависимости от потока запросов вам могут подойти совсем разные решения. Худшее в такой парадигме - это выбрать какой-то один подход и изо всех сил пытаться его «докрутить». Вот когда я в такой парадигме работал я и страдал. Вроде вкладываешь героические усилия - а отдача нулевая. Поставил все фишки на один подход - а он не работает.

Первый ментальный сдвиг, который нужно на мой взгляд сделать, чтобы заниматься R&D - это отказаться от идеи, что ты можешь спланировать финальное решение на берегу. Начать мыслить гипотезами а не «планом победы». И в этом смысле план работ из ганта с финишной прямой превращается в серию экспериментов, результатом которой может быть и понимание, что задача не решаема.

Когда команда осознает это обычно они врезаются в следующую проблему: пространство гипотез почти бесконечно. Если ребята продвинутые, то хотя бы они понимают что предпочитать одни гипотезы другим нужно по метрикам. Но даже так: мл индустрия предлагает огромное количество примитивов, из которых можно строить решение, у каждого из примитивов десятки гиперпараметров и десятки способов наливать в эти кубики данные. Как в этом пространстве приоритизировать гипотезы и что должно дать критерием остановки по каждой из гипотез - неочевидно. А еще хуже, что критерий остановки самого проекта становится непонятен - всегда можно выдвигать новые гипотезы.

И вот тут команде нужен второй фазовый переход: переход к data-driven формированию и управлению списком гипотез. Для начала необходимо сформировать «прогресс-бар» проекта. Найти какую то метрику, значение которой полностью отражает готовность системы к работе. В идеале перенести ее в офлайн. Попробовать измерить ей самое простое решение. Получить значение 0% готовности (или повыше если повезет). А дальше анализировать все отвалы-ощибки системы. В проектах gen-ai можно буквально посмотреть на каждый отвал и на каждый отвал сформировать гипотезу, какое изменение системы позволит этого отвала избежать. В задачах персонализации/предиктивной аналитики скорее нужно смотреть не на отдельные точки, а на когорты/сигналы (хотя и на отдельные точки иногда очень полезно посмотреть для инсайтов). Но важно что все ваши гипотезы должны решать конкретную проблему системы, которую вы обнаружили на данных.

После этого фазового перехода у команд дела идут бодрее, но их может ждать следующая проблема: команде может не удастся кластеризировать все увиденные проблемы в достаточно общие, и ребята начинают заниматься патчворком. Накидывать конкретные примеры в промпты например. Это движет метрику вверх, но очень очень медленно. Ни конца ни края не видно, и команда просто забрасывает проект.

И вот тут нужен последний фазовый переход: успешный мл проект - это набор кубиков + операционных процессов над ними.