Проектный менеджмент в AI и личный опыт

"В AI использовать классический айтишный проектный менеджмент – стрелять себе в ногу" – нарратив, которую я все чаще слышу от опытных ИИ интеграторов. Дальше – почему я согласен и как сам строю процесс

Дело в том, что в разработке AI решений гораздо больше неопределенности. Разработать сайт – достаточно предсказуемая штука. Да, там вылезет что-то, чего не было в тз или ошибки проектирования не позволят добавить "очень нужную функцию", которая понадобилась заказчику.

Но с AI системами все по-другому. Это в самой своей сути всегда немного исследовательский проект. Получится ли добиться нужной точности? А если другую архитектуру попробовать? А другую модель? А если форматирование данных с json поменять на xml? А что если ошибки не в поведении системы, а в самой разметке тестовых данных? А как это понять?

Это все – набор экспериментов. Результатом является не разработанная система, а проверенные гипотезы + выводы. Все как в науке => проектный менеджмент нужен похожий скорее на академический, чем на айтишный.

Но заказчику нужны не выводы, а рабочий продукт. Как быть?

Я свои заказы практически всегда делю на два ключевых этапа: исследовательский и интеграционный

Исследовательский

* Цель – проверить гипотезы и разработать LLM-core часть.

* Заказчик на вход дает примеры данных, с которыми система работает:
* Набор документов для извлечения данных
* Аудиозаписи для транскрибации
* Переписку продажников, которую хотим анализировать на ошибки

* В идеале получить еще разметку – ожидаемые результаты. Это может быть то, какой результат сейчас получают вручную

* На выходе тоже данные – результаты работы системы. И если есть разметка, то еще и сравнение с ней – где совпадает, а где нет (высший пилотаж, если даем еще и анализ почему)

* Никакой рабочей системы, продакшена и интерфейсов. Данные на вход, данные и метрики на выход,

* Если результаты исследования устраивают – идем дальше

Интеграционный

* Цель – обернуть llm-систему в сервис/приложение и интегрировать в существующие процессы.

* Я стараюсь вынести требования к прайваси именно сюда, чтобы они не тормозили на первом этапе. Тут уже может быть и разворачивание инфраструктуры в своем контуре, и работа с локальными моделями, и переезд в Azure вместо обычного OpenAI API.

* Много погружения в существующие процессы или код для бесшовной интеграции. Для примера, на текущем проекте идем в два этапа:
* Сначала внутренний сервис, который сотрудники используют под своим контролем – вручную детектим проблемы, которые не видели на тестовых данных.
* А когда основные edge-кейсы обработаны, выносим в самостоятельный сервис без участия человека.

* Настраиваем мониторинги, деплой, A/B тесты, ретраи с exponential backoff, фоллбэки на других провайдеров для надежности. Короче, продакшн

* По большей части обычная айтишная разработка.

———

Разделяя так проект, я снижаю и свои риски, и заказчика – если сразу видим, что задача автоматизации не решается на нужном уровне, можно вообще не тратить деньги и время на продакнш.

Заказчик экономит время и деньги, а я – сохраняю репутацию (чтобы не было "вон столько денег потратили, а пользоваться не возможно").

Еще и итерации без всей этой продакшн части делаются на порядок быстрее. Я за последние три года видел много ситуаций, когда люди сразу делали продакшн, а потом серьезное обновление LLM-системы тянуло за собой кучу приседаний.

И люди просто отказывались делать такие обновления. Да, в идеале оно все абстрагировано друг от друга. Но в реальности я такого не видел 🤷‍♂️

Кстати, бонус: если на исследовательском этапе метрики не устраивают, не обязательно отказываться от дальнейшей разработки. Можно менять подход к интеграции в сторону "копайлота". Работает AI + человек, который следит за ошибками и направляет систему, работая за целую команду.

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