В одном из корпоративных проектов мы создавали ИИ-платформу на локальной языковой модели в закрытом контуре. Прототип команда собрала за две недели: система находила информацию в базе знаний и отвечала на её основе.

А на проверку качества ушло ещё шесть недель. Большую часть этого времени заняло согласование ожиданий экспертов и разработчиков.

Что считать правильным ответом? Может ли модель добавлять в ответ сведения, которых нет в базе знаний? Что отвечать, если информации не хватает? Достаточно ссылки на документ или человеку нужна понятная инструкция?

Прототип уже работал, а общего понимания, какой результат мы готовы принять, ещё не было.

Как менеджер проекта я помогла согласовать четыре критерия и включила их в условия готовности: • Факты: ответ подтверждается материалами базы знаний? • Корректность: нет выдуманных сведений и искажения смысла? • Польза: человек получает понятное действие, инструкцию или решение? • Границы задачи: модель остаётся в рамках роли помощника?

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

Главный вывод: договариваться о приёмке ответов ИИ нужно уже на этапе постановки задачи. «Модель работает?» – слишком общий вопрос. Важно понять, какой ответ поможет пользователю и как мы это проверим.

Четыре критерия собрала на карточке. Можно сохранить как основу и адаптировать под свой проект.

А у вас бывало, что система уже работает, а команда и заказчик по-разному понимают, что считать готовым результатом?