Демонстрация удалась. Модель отвечала хорошо, заинтересованные стороны кивали, и кто-то задал резонный вопрос: как быстро это может оказаться в эксплуатации?
Почему демонстрация далась легко
Честный ответ обычно — «позже, чем кажется по демонстрации», и не потому, что модель должна поумнеть, а потому, что демонстрации позволили пропустить всё, что делает систему заслуживающей доверия. Команды, закладывающие бюджет только на демонстрацию, не выпускают ничего. Команды, закладывающие бюджет на десять задач ниже, выпускают системы, которые выдерживают встречу с реальными пользователями.
Прототип впечатляет за счёт молчаливых допущений. Он работал на отобранном вручную наборе документов. Он отвечал на вопросы, на которые, как знали его авторы, он ответить может. Никто не просил его учитывать права доступа, потому что всем в комнате было можно видеть всё. Никто не измерял частоту его ошибок, потому что ошибки тихо перезапускались. Его стоимость не стоила учёта, потому что низкая нагрузка прототипа редко показывает цену эксплуатации в масштабе организации.
Ничто из этого не упрёк: работа прототипа — показать, что идея заслуживает инженерии. Ошибка — считать прототип системой с парой недоделок, а не первой строкой спецификации настоящей системы.
Данные и привязка к источникам: от отобранных примеров к реальным
Первый вопрос эксплуатации — не «какая модель?», а «какие данные и кому их можно видеть?»
В демонстрации поиск работал по чистому корпусу. В эксплуатации он работает по реальным источникам организации — вики, противоречащим друг другу, документам с ограниченным доступом, записям, меняющимся ежедневно. Поиск должен научиться учитывать права: система, показывающая документ тому, кому его читать не положено, — это инцидент безопасности, каким бы полезным ни выглядел ответ. Ответам нужна атрибуция: ответ, называющий источники, можно проверить; ответу без них приходится верить вслепую — и корпоративные пользователи справедливо этого не делают.
Полезный тест: возьмите лучший ответ прототипа и спросите, откуда взялось каждое предложение и разрешено ли каждому будущему пользователю системы видеть эти источники. Если хотя бы один ответ неясен — слой данных не готов.
Оценка: определите, что значит «работает», до запуска
Прототипы судят по впечатлению; рабочим системам нужны критерии. До запуска ИИ-функции должны существовать три вещи: определение правильного ответа для её задачи, тестовый набор, отражающий реальное использование, а не удачные сценарии, и базовое измерение, с которым сравнивается каждое будущее изменение.
Это не бюрократия — это то, что делает изменения безопасными. Модели обновляются, промпты правятся, источники растут. Без механизма оценки каждое изменение — ставка, которую никто не может оценить; регрессия приходит незаметно и обнаруживается пользователями. С механизмом оценки обновление версии модели, тихо ухудшившее качество ответов, ловится в день, когда произошло, а не кварталом позже.
Эксплуатация: та часть, которую никто не демонстрирует
Четыре задачи превращают ИИ-функцию в эксплуатируемую систему:
- Границы безопасности. Доступ системы к данным и инструментам — это интеграция, и она проходит ревью интеграционного уровня: собственная учётная запись, минимальные привилегии, возможность отзыва. Прототип на личном токене разработчика — не путь к развёртыванию.
- Наблюдаемость. Когда ответ неверен, кто-то должен видеть почему — что было найдено, о чём спросили модель, что она вернула. ИИ-система без трассировки неотлаживаема по построению.
- Обработка отказов. Модели не отвечают вовремя, провайдеры ограничивают частоту запросов, поиск возвращает пустоту. Каждому режиму отказа нужно спроектированное поведение — запасной вариант, отказ отвечать, эскалация человеку, — а не исключение в логе.
- Бюджеты стоимости и задержек. Процесс, стоивший центы на демонстрации, в масштабе организации может стоить настоящих денег, а десятисекундный ответ, забавлявший публику на демонстрации, ежедневные пользователи забросят. Обоим нужны бюджеты, измеряемые на каждый запрос, до масштабирования — а не после счёта.
Изменения: система не будет стоять на месте
Рабочие ИИ-системы стоят на подвижной почве. Провайдеры выводят модели из эксплуатации по собственному расписанию. Промпты накапливают правки, пока никто не помнит, зачем там то или иное предложение. Исходные данные дрейфуют. Процесс, который система автоматизирует, меняет форму.
Поэтому последняя задача — организационная, а не техническая: владение. Кто-то владеет результатами оценки, решает, когда переходить на новую версию модели, просматривает, для чего систему реально используют, и отвечает за её поведение. ИИ-функция без владельца — не инфраструктура, а эксперимент, случайно открытый пользователям.
Чек-лист готовности к эксплуатации
Десять вопросов, на которые можно ответить за один вечер и которые предсказывают, близок прототип к эксплуатации или далёк от неё:
- Какие источники система читает и проверяются ли права для каждого пользователя?
- Может ли каждый ответ назвать свои источники?
- Что такое правильный ответ — письменно?
- Есть ли тестовый набор, отражающий реальное использование?
- Есть ли базовое измерение для сравнения изменений?
- Есть ли у системы собственная учётная запись и доступ по принципу минимальных привилегий?
- Можно ли проследить неверный ответ до его причины?
- Спроектирован ли каждый режим отказа, а не просто залогирован?
- Каковы бюджеты стоимости и задержек — и что происходит при их превышении?
- Кто отвечает за поведение этой системы через год?
Команда, отвечающая на все десять, завершает инженерный проект. Команда, отвечающая на три, имеет многообещающую демонстрацию — что само по себе неплохо, пока никто не называет её почти готовой.