ИИ-пилот, который не выходит из демонстрации
Качество меряется на постоянном наборе задач, и выход в продуктив опирается на письменный критерий
Проверяется: эталонный набор задач и протокол замера
ПромышленностьРаботаем по NDA
Пилот показали, эффект на демонстрации признали, и дальше он живёт в демонстрационном режиме уже больше полугода. Внутри спорят, в чём причина — в данных, в модели или в процессе, но спор не решается, потому что качество ни разу не мерили на общем наборе задач. Нет письменного критерия, при котором систему можно принять или закрыть, и нет человека, который отвечает за неё после запуска, — поэтому решение по бюджету откладывается ещё на квартал.
Что съедает срок и бюджет на самом деле
Почти никогда — не модель. Ниже места, из-за которых такие проекты встают, и что мы с каждым делаем.
Пилот живёт на выгрузках, подготовленных руками
кто-то один раз собрал, почистил и загрузил данные. Кто будет делать это ежедневно в эксплуатации, обычно не решено, и на демонстрации этого не видно, потому что данные там заранее хорошие.
Меры качества не существует
Пока нет набора задач с ожидаемыми ответами и письменными правилами оценки, любое изменение промпта или модели остаётся вопросом вкуса, а разговор идёт о впечатлениях. Сначала строится мерило, потом чинится система — обратный порядок даёт бесконечный цикл правок.
Причины перемешаны и лечатся по-разному
подготовка данных, промпты и модель, процесс вокруг системы. Каждая корзина стоит своих денег и своего срока, и до разбора ошибок по корзинам оценка следующего этапа не защищается перед бюджетным комитетом.
Служба ИБ не пропускает систему в контур
нет описания потоков данных, ролей доступа и журналирования. Это не мелкая доработка, а отдельный объём работ, который в смету пилота обычно не закладывали.
Ограничение, которое определяет решение
Контур закрытый: модели работают на инфраструктуре заказчика, данные за периметр не уходят, поэтому обвязка эксплуатации — разграничение доступа и журналирование — проектируется под класс защищённости системы с опорой на приказы ФСТЭК России № 17 и № 21 и требования 152-ФЗ. Терминология доверия к системам искусственного интеллекта и требования к их приёмке берутся из ГОСТ Р 59276-2020, чтобы критерии в акте были сформулированы на общем языке со службой ИБ. Лицензируемые работы — аттестация объекта информатизации, оценка соответствия — выполняются организацией с лицензией ФСТЭК.
Как проверить, что работа сделана
Приёмка привязывается к числам из протокола замера, а не к формулировке «система работает». Прогон делается на том же эталонном наборе, который согласовали до начала работ, и выполняет его сотрудник заказчика по инструкции, без участия исполнителя — если повторить замер самостоятельно не получается, методика не передана.
Отдельно проверяется эксплуатационная часть: дежурный по регламенту обновляет промпт и откатывается на предыдущую версию в присутствии приёмочной комиссии, а мониторинг показывает деградацию качества на заранее испорченном контрольном прогоне. Проверяется и конвейер данных: суточная загрузка проходит без ручных шагов, а её отказ виден в журнале.
О чём спросить любого подрядчика
- Посмотрите, есть ли в предложении отдельная оплачиваемая строка «замер качества до работ».
- Если подрядчик сразу переходит к дообучению модели, мерить результат будет нечем, и разговор снова уйдёт в впечатления.
- Спросите, кому принадлежит эталонный набор задач после проекта: он должен остаться у вас и работать против самого подрядчика тоже.
- Попросите сформулировать критерий, при котором проект признаётся неуспешным, — готовность его написать отличает инженерную работу от продажи следующего этапа.
- Проверьте, заложены ли часы на конвейер подготовки данных, журналирование и разграничение доступа: пилоты чаще всего застревают именно здесь, а не в качестве модели.
- И уточните, кто на вашей стороне назначен владельцем системы после запуска, — без этого имени приёмка не имеет адресата.
Порядок работ по этапам
На каждом этапе назван результат, который остаётся у заказчика. На проверке — признак, по которому работу не приняли бы.
- Разбор пилотаПодняли, что показывали на демонстрации и на каких примерах, поговорили с теми, кто пилот собирал, и с теми, кто должен им пользоваться. Выяснилось, что общего набора задач нет и мерить качество не на чем — отсюда и спор об эффекте.
- Критерий приёмкиПервым решением стали письменный критерий приёмки и эталонный набор задач с ожидаемыми ответами. Ошибки договорились раскладывать по корзинам — данные, промпты и модель, процесс, — а версии промптов вынесли отдельно от кода, чтобы откат не требовал пересборки.
- Достройка обвязкиСобрали эталонный набор и замерили то, что уже было, затем достроили конвейер данных, журналирование каждого вызова и откат на предыдущую версию. Правки вносили по корзинам и после каждой прогоняли набор заново.
- Замер на набореМерили только на общем эталонном наборе, а не на удачных примерах из демонстрации. Провалом считали правку, которая улучшает показ и ухудшает результат на наборе, и ответ, который нельзя восстановить по журналу.
- Передача командеПередали набор тестов и протокол замера, письменный критерий приёмки, реестр разрывов и обвязку эксплуатации. Команда заказчика сама пополняет набор задач и прогоняет его перед каждой выкаткой.
Как это устроено внутри
Вокруг существующего пилота достроены три части: конвейер данных в Airflow, сервис замера на FastAPI и хранилище прогонов. Эталонный набор задач с ожидаемыми ответами лежит в PostgreSQL, входные документы и полные ответы модели — в MinIO, версия промпта и параметры генерации привязаны к прогону через MLflow, потому что без этой привязки нельзя сказать, изменилось качество от данных или от правки шаблона. Запросы к модели идут через очередь в Redis с ограничением параллельности: пилот делит карту с другими задачами, и прямой залп на инференс выбивал его по памяти. Ошибки помечаются на записях прогона по корзинам — данные, промпт и модель, процесс, — метрики выводятся в Grafana, откат на предыдущий шаблон делается сменой версии в реестре без пересборки образа; узлы подняты контейнерами.
- Python
- FastAPI
- PostgreSQL
- MinIO
- Redis
- Docker
- Airflow
- MLflow
- Grafana
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.