Чеклист здорового мл проекта

В Т по долгу службы мне надо присматривать за десятками МЛ проектов одновременно. Со временем у меня сложилась простая диагностическая рутина, которая вылавливает очевидные косяки. Если кто-то из олдов помнит Joel test для кодинга, то вот моя выстраданная горьким опытом версия для МЛ:

1. Цель проекта ясна
Очевидно, но есть ньюансы: Вам могут говорить, что хотят денег заработать, а на деле пытаются обогнать внутренних конкурентов и занять поляну. Или же ожидают, что сделав Х - автоматически получат У. Настоящую цель вам могут не сказать, но ее можно выяснить вопросами типо «а вот представь мы запустили Х, и получим не У а Z, это будет считаться успехом?»

2. Все требования оцифрованы и измеримы
Не только ключевая цель проекта, но и разные неявные ожидания от системы (безопасность, косты инфры, дайверсити). По каждому из значений метрик можно однозначно сказать: система ок или не ок.

3. Продуктовый дискавери сделан
Проверочный вопрос: а давайте представим, что все сделали идеально, правда ли мы увидим ожидаемые эффекты? Иногда это сложно понять не эимплементировав систему, но boy oh boy, как часто это можно сделать малой кровью, понаблюдав за действиями пользователей системы. Особенно это больно в GenAI, где ускоряют кусочек бизнес процесса, а общего ускорения не происходит; протолкнули ботлнек дальше по пайплайну, и все.

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

5. Все решения принимаются через эвалы
Нет «волшебных чисел» или «волевых архитектурных решений». Если в проекте спорят, что лучше работает - это красный флаг, надо проверять на цифрах.

6. Начали с бейзлайна
Вы не поверите, как часто бейзлайн обгоняет сложные решения. Просто потому что в бейзлайне сложнее накосячить.

7. R&D бэклог опирается на аналитику
В автоматизации ошибки системы на эвале распричинены до руткоза. В персонализации фичи опираются на поведенческие или количественные исследования (или хотя бы здравый смысл). Если весь бэклог - это список архитертур моделей, то это плохой беклог. В идеале дифф между целевым значением таргет метрики и текущем должен быть полностью обьяснен и атрибутирован конкретным причинам.

8. Большая часть усилий уходит на работу с данными
Команда не пытается подстроить систему под имеющиеся данные, а активно эти данные меняет (вычищают мусор, переписывают источники, анализируют фичи).

9. Система покрыта интеграционными тестами
Мало толку от идеальной модели, если ее скоры перетираются по дороге. Особенно больно с инференсом LLM, где обновление рантайма может изменить поведение модели.

10. Эксперименты логируюися и воспроизводимы
В ответ на «мы уже это пробовали» можно посмотреть, а что конкретно пробовали, и если нужно вернуться к идее, но в чуть другой постановке.

11. Вы знаете, когда остановиться
Вы на берегу договорились, что будет критерием остановки проекта.

Ну и естественно, предполагается, что инженерная культура хорошая, млщики вычищают лики, не косячат в написании трейнлупа и т д. Этот чеклист не гарантирует успеха проекта, но если у вас проставлено меньше 9 галочек, то это плохой знак.