Работает, но не готово: как определить готовность ИИ-систем
Три моих ИИ-проекта работают в промышленной эксплуатации от шести месяцев до двух лет. Один агент каждый день помогает аналитикам писать SQL, другой формирует черновики ответов для операторов поддержки, третий используется внутри компании как универсальная ИИ-платформа.
Недавно я попытался понять, можно ли считать эти системы завершёнными. Не проверить, запускаются ли они и приносят ли пользу - с этим проблем нет. Вопрос был практический: способен ли я уехать в отпуск на месяц и не думать о них вообще?
Ответ оказался отрицательным. Я не знал точную стоимость работы агента, давно не измерял качество ответов, а устройство каждого проекта держалось в основном в моей памяти. Все три решения существовали в продакшене, но ни одно нельзя было назвать по-настоящему готовым.
Почему обычный Definition of Done не подходит ИИ
В традиционной разработке фича считается завершённой, если она корректно работает во всех предусмотренных сценариях. Если код ведёт себя непредсказуемо, это обычно воспринимается как дефект, который необходимо устранить.
С генеративными моделями такой подход не работает. Они вероятностны по своей природе. SQL-агент может успешно обработать 75% простых запросов и лишь около 30% сложных. Дополнительные итерации улучшат результат, но не превратят систему в механизм со стопроцентной точностью.
Требование "работает всегда" фактически отправляет ИИ-продукт в бесконечную бету. Проблема не в том, что команда недостаточно старается. Просто понятие "доделать" для такой системы не определено.
Похожая ситуация возникает во множестве компаний: проект вызывает восторг на демонстрации, но после пилота не получает ни чётких критериев успеха, ни владельца, ни плана развития. Он не закрывается и не становится полноценным продуктом. Такой подход часто называют demo-driven development.
Исследования рынка также показывают масштаб проблемы. По данным S&P Global, в 2025 году 42% компаний свернули большинство ИИ-инициатив против 17% годом ранее. Среди причин обычно называют слабый контроль рисков и отсутствие понятной бизнес-ценности. На практике обе причины часто сводятся к одному: никто не знает, где проходит граница возможностей системы и какой результат она должна давать.
Новое определение готовности
После анализа проектов я пришёл к следующей формулировке:
> Готовая ИИ-система - это система, у которой граница возможностей определена, зафиксирована и регулярно поддерживается в актуальном состоянии.
Умение отвечать на любые вопросы в это определение не входит. Важно не сделать модель универсальной, а понимать:
- какие задачи она решает;
- где начинает ошибаться;
- как ведёт себя в опасных сценариях;
- кто отвечает за её состояние;
- сколько стоит эксплуатация;
- какую бизнес-метрику она улучшает.
На основе этого я составил чек-лист из девяти пунктов и проверил по нему все три проекта.
Чек-лист готовности ИИ-продукта
1. Результат можно проверить без помощи модели
Команда должна уметь отличить правильный ответ от неправильного и объяснить, почему он считается корректным. Если такой проверки нет, проект превращается в надежду на то, что модель "сама разберётся" после загрузки данных.
ИИ хорошо автоматизирует процессы, где результат можно объективно оценить. Всё остальное он способен убедительно имитировать, но не гарантировать.
Если проверяемого критерия нет, проект получает нулевой результат независимо от остальных пунктов.
2. Качество измерено по типам задач
Одной средней точности недостаточно. Нужно разделить обращения или запросы на классы и отдельно оценить каждый из них.
Например, для SQL-агента можно выделить:
- простые выборки;
- агрегации;
- соединения таблиц;
- вложенные запросы;
- работу с неочевидной бизнес-логикой;
- запросы к новым или плохо описанным данным.
Такая детализация быстро показывает, где инструмент действительно полезен, а где создаёт дополнительную нагрузку на пользователя.
3. Ограничения понятны пользователям
У системы должен существовать список задач, которые она не решает. Простого внутреннего знания команды недостаточно.
Пользователь должен видеть понятное предупреждение: например, что ассистент работает только с определёнными источниками данных, не даёт юридических рекомендаций или не обрабатывает вопросы вне конкретного продукта.
Чем яснее сформулированы ограничения, тем ниже риск неоправданного доверия к модели.
4. Для неподходящих запросов предусмотрен отказ или эскалация
Недостаточно сообщить, чего система не умеет. Необходимо проверить, как она ведёт себя при выходе за границы.
Для этого используются специальные вопросы-ловушки: намеренно неоднозначные, провокационные или не относящиеся к области применения. В корректном сценарии модель должна отказаться от ответа, запросить уточнение или передать задачу человеку.
Уверенный, но неверный ответ опаснее явного отказа.
5. Существуют сигналы тихих ошибок
Пользователь не всегда сообщает о проблеме. Иногда он просто исправляет ответ вручную и продолжает работу. В результате команда может долго не замечать систематические ошибки.
Поэтому нужны механизмы раннего обнаружения:
- выборочная проверка ответов;
- сравнение с эталонными результатами;
- сбор исправлений пользователей;
- анализ повторных запросов;
- автоматические проверки структуры и содержания;
- регулярный аудит сложных случаев.
Задача мониторинга - обнаружить ошибку до того, как она станет претензией, финансовой потерей или инцидентом.
6. У системы есть конкретный владелец
Ответственность нельзя распределять между "командой вообще". У проекта должно быть конкретное имя - человек, который следит за метриками, принимает решения о релизах и знает, что делать при ухудшении качества.
Владелец не обязан самостоятельно выполнять всю работу. Но он должен координировать изменения, обновлять документацию и обеспечивать регулярную проверку системы.
7. Изменения проходят через eval
Любая смена модели, системного промпта, цепочки инструментов или источника данных может повлиять на качество.
После каждого существенного изменения необходимо заново прогонять оценочный набор и фиксировать результат. Важно записывать не только новую цифру, но и дельту: что стало лучше, что ухудшилось и на каких классах задач.
Без этого команда легко принимает локальное улучшение за общий прогресс.
8. Известна стоимость эксплуатации
Необходимо понимать стоимость одного запроса и совокупные месячные расходы. В расчёт входят не только токены, но и вызовы внешних сервисов, хранение контекста, инфраструктура, логирование и ручная проверка.
У проекта должен быть экономический порог: после какого уровня затрат дальнейшее улучшение перестаёт окупаться.
Иногда качество можно повысить не сложной настройкой, а переходом на более мощную модель. Поэтому прежде чем месяц дорабатывать промпт и тестовый контур, стоит проверить, не покупается ли нужный прирост качества более дорогой моделью.
9. Понятно, кто пользуется системой и какую метрику она меняет
Фраза "инструментом пользуется команда" недостаточна. Нужно знать количество пользователей, частоту обращений, сценарии использования и реальный эффект.
В зависимости от продукта это могут быть:
- сокращение времени обработки заявки;
- снижение числа ошибок;
- рост доли обращений, решённых без оператора;
- ускорение подготовки отчётов;
- уменьшение нагрузки на экспертов;
- рост выручки или конверсии.
Если связь с бизнес-результатом не прослеживается, проект легко превращается в дорогую демонстрацию технологии.
Как оценивать результат
За каждый пункт можно поставить:
- один балл - критерий полностью выполнен;
- половину балла - выполнен частично;
- ноль - отсутствует.
Я использую следующую интерпретацию:
- 7-8 баллов - система готова и, скорее всего, переживёт длительное отсутствие автора;
- 4-6,5 балла - основные границы уже видны, но требуется плановая доработка;
- меньше 4 баллов - красная зона: проект существует главным образом благодаря энтузиазму владельца.
Гейт с проверяемостью результата является обязательным. Если его не пройти, высокий общий балл создаёт ложное ощущение контроля.
Что показал аудит трёх проектов
Внутренняя ИИ-платформа получила 3 балла из 8. Ею пользовались, но не существовало единого владельца, стабильного набора eval-тестов и прозрачного расчёта стоимости.
SaaS-сервис генерации контента набрал 1,5 балла. Он провалил обязательный гейт: команда не могла одинаково оценить качество результата для разных типов материалов. Формально сервис работал, однако его ценность зависела от субъективного впечатления пользователя.
Ассистент поддержки получил 3,5 балла. Он приносил пользу операторам и работал на реальном трафике, но не имел актуальной оценки точности, полноценной системы отслеживания тихих ошибок и чётко зафиксированных ограничений.
Ни один из проектов не был сломан. Но каждый оставался уязвимым: уход автора, смена модели или резкий рост нагрузки могли быстро превратить рабочий инструмент в источник проблем.
Что меняется после введения чек-листа
Первое изменение - документация перестаёт быть формальностью. В ней фиксируются не только архитектура и инструкции по запуску, но и границы применимости, известные слабые места, стоимость и порядок действий при сбое.
Второе - релизы становятся проверяемыми. Нельзя сказать "новая модель отвечает лучше" без сравнения с прежней версией на одном и том же наборе задач.
Третье - появляется возможность честно обсуждать компромиссы. Если качество сложных запросов ограничено, команда может решить: передавать их оператору, использовать более дорогую модель или отказаться от сценария. Это лучше, чем скрывать проблему за общим показателем удовлетворённости.
Наконец, система становится независимее от автора. Знания о проекте перестают храниться в голове одного человека, а отпуск перестаёт быть проверкой на прочность всей конструкции.
ИИ-систему не нужно доводить до мифического состояния, в котором она отвечает идеально. Её нужно сделать управляемой: определить область применения, измерять качество, отслеживать ошибки, контролировать экономику и назначить ответственного. Именно это отличает работающий прототип от готового продукта.
