AI-пилот, который так и не дошёл до продакшена: чего не хватило в данных и эксплуатации

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

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

Демо доказывает, что модель умеет читать; прод спрашивает о каждом документе

В 2015 году Sculley и коллеги из Google написали, что лишь малая доля реальных систем машинного обучения состоит из собственно кода машинного обучения, а необходимая инфраструктура вокруг него огромна и сложна. Пайплайн на языковой модели устроен так же, и у пилота, собранного только из этой малой части, вокруг нет ничего, на чём он мог бы работать в проде.

Сопоставьте то, что было у пилота, с тем, что нужно очереди в проде, — и недостающая работа превращается в список:

• Оценка: несколько примеров, которые кому-то понравились, — против размеченного набора с согласованным проходным порогом по каждому полю
• Данные: выгрузки, образцы или облачный API — против живых источников, которым может быть запрещено покидать вашу инфраструктуру
• Вход: чистые PDF — против сканов, цепочек писем, вложений и шаблонов, которые меняются без предупреждения
• Выход: текст, который прочитал человек, — против записей, которые потребляет другая система и которым она должна доверять
• Эксплуатация: один пользователь за раз — против пикового объёма, простоя сервера модели и владельца после запуска

Составьте приёмочный набор до того, как трогать модель

Первый недостающий артефакт — размеченный набор реальных документов с ответом, который должен получиться для каждого из них. Без него любую смену промпта или модели оценивает тот, кто в этот день читает вывод, и пилот не может пройти планку, которую так никто и не записал.

В Rules of Machine Learning от Google измерение стоит раньше модели: правило № 2 — «Сначала спроектируйте и внедрите метрики». Для извлечения данных и маршрутизации тикетов метрика — это не одна оценка на весь документ:

• Берите документы из реального трафика за период, достаточно длинный, чтобы в него попали конец месяца, праздники и отправители с нестандартными форматами
• Поручите разметку людям, которые делают эту работу сегодня, причём часть набора пусть двое размечают независимо друг от друга, а их расхождения считайте пробелами в спецификации, а не шумом
• Оценивайте каждое поле отдельно, потому что при усреднении правильное имя не перекрывает неверную дату
• Запишите проходной порог для каждого поля и типа документов и назовите, какие поля можно автоматизировать, а какие всегда уходят человеку
• Измерьте текущий ручной процесс на том же наборе, чтобы модель сравнивалась с реальной базовой линией, а не с идеалом
• Держите часть набора закрытой от всех, кто подбирает промпты, чтобы итоговая оценка не измерялась на примерах, под которые подгонялся промпт

Данные, которые не могут покинуть периметр, меняют архитектуру, а не только поставщика

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

Модель — очевидный компонент, который нужно перенести внутрь. Но не единственный, потому что пайплайн на языковой модели копирует данные в большее число мест, чем один вызов модели:

• Сервер инференса и веса модели с зафиксированными версиями
• Эмбеддинги и векторный индекс: они получены из документов и должны защищаться так же, как сами документы
• Промпты, ответы модели и трейсы в логах, поскольку залогированный промпт содержит документ, из которого он собран
• Приёмочный набор, инструмент разметки и очередь ручной проверки
• Мониторинг и трекинг ошибок: работая как облачный сервис, они становятся внешней копией данных

Маскирование помогает там, где логам приходится покидать закрытую зону. Presidio — open-source фреймворк, разработка которого началась в Microsoft, — обнаруживает и анонимизирует персональные данные в тексте, а в его документации указано, что, поскольку обнаружение автоматическое, нет гарантии, что оно найдёт всю чувствительную информацию. Маскирование уменьшает объём раскрываемых данных, но не заменяет хранения данных внутри.

Вход — неблагодарная половина: сканы, цепочки писем и вложения

Пилот получает документы; прод получает всё, что присылают отправители. До любого вызова модели пайплайн должен превратить это в текст с привязкой к источнику:

• Сканы и фотографии проходят через OCR, чьи ошибки в цифрах и столбцах таблиц доходят до модели как уверенный текст
• Цепочки писем и тикетов содержат цитируемые ответы, подписи и дисклеймеры, поэтому последнее сообщение нужно отделять от истории
• Содержимое часто находится именно во вложениях, и каждому формату нужен свой путь извлечения
• Каждый чанк хранит свой источник — файл, страницу и смещение, — чтобы любое извлечённое поле можно было проследить до фрагмента, из которого оно взято
• Дубликаты — например, пересланное уведомление или тикет, переоткрытый по почте, — обнаруживаются до того, как станут двумя записями

Длинные входы требуют отдельного внимания. В статье Lost in the Middle, опубликованной в TACL в 2024 году, Liu и коллеги показали, что для протестированных ими моделей качество часто наиболее высокое, когда релевантная информация находится в начале или в конце входного контекста, и значительно падает, когда она находится в середине длинного контекста. Разбивать длинный документ по разделам, сохраняя источник в каждом чанке, — более безопасный вариант по умолчанию, чем рассчитывать, что модель читает весь контекст равномерно, а приёмочный набор покажет, что верно для ваших документов.

Структурированному выводу нужны схема, валидатор и место для неверного ответа

Ограниченное декодирование (constrained decoding) допускает на выходе модели только JSON, соответствующий схеме: vLLM поддерживает его как structured outputs, а llama.cpp — через грамматики. Оно фиксирует форму записи — в пределах возможностей схемы, которые поддерживает бэкенд, и пока генерацию не обрезал лимит токенов, — но не её истинность: корректно сформированная запись всё равно может содержать неверную дату.

Истинность проверяется после модели — кодом, которому бизнес уже доверяет:

• Проверки типа и формата: даты, валюты и идентификаторы с контрольной цифрой, например ISIN
• Межполевые правила, например: дата окончания периода не может быть раньше даты начала
• Сверка со справочными данными, которые компания уже ведёт, например с известным инструментом или клиентом
• Согласованность с источником: каждое извлечённое значение до нормализации должно присутствовать во фрагменте, на который оно ссылается

Собственная уверенность модели — слабый фильтр. GPT-4 Technical Report от OpenAI, опубликованный в 2023 году, показывает, что на бенчмарке с выбором из нескольких вариантов предобученная модель была хорошо откалибрована, а пост-обучение эту калибровку снизило. Уверенность, которую модель сообщает о себе сама, или вероятность токена — это сигнал, который нужно проверить на приёмочном наборе, а не порог, которому можно доверять по умолчанию.

Запись, не прошедшая хотя бы одну проверку, уходит в очередь ручной проверки, а не в систему-потребитель. Очередь — самостоятельный продукт: ей нужны владелец, план мощностей в часах работы проверяющих, исходный фрагмент рядом с каждым полем и исправления, которые возвращаются в приёмочный набор.

Тикеты и документы — недоверенный вход для модели

Тикет поддержки — это текст, написанный кем-то вне компании, а документ может нести инструкции, которые отправитель поместил туда намеренно. OWASP Top 10 for LLM Applications 2025 ставит prompt injection на первое место, включая непрямую инъекцию, при которой инструкции приходят внутри внешнего контента, обрабатываемого моделью, например веб-сайта или файла.

Три пункта того же списка превращаются в правила проектирования для пайплайна обработки документов:

• Prompt injection (инъекция промпта): помечайте каждый документ и тикет как недоверенный контент и держите его отдельно от инструкций, которые лежат в шаблоне, недоступном отправителю для правки
• Improper output handling (некорректная обработка вывода): проверяйте вывод модели до того, как на его основе начнёт действовать любая система, так же как проверяли бы ввод от пользователя
• Excessive agency (избыточные полномочия): дайте пайплайну минимальные привилегии, нужные для его задачи, чтобы модель, читающая тикеты, не могла закрывать счета или отправлять платежи

OWASP также отмечает, что неясно, существуют ли стопроцентно надёжные способы предотвратить prompt injection. Основной вес несут проверки вывода и ограничение привилегий, а не формулировка промпта.

Фиксируйте модель, промпт и парсер как одну версию

Поведение пайплайна — результат нескольких артефактов, которые меняются независимо друг от друга. Считайте их одним релизом и сохраняйте его идентификатор в каждой записи, которую он порождает:

• Веса модели по контрольной сумме вместе с квантизацией и версией сервера инференса
• Шаблон промпта, схема вывода и параметры декодирования
• OCR-движок, правила разбиения на чанки и валидаторы
• Версия приёмочного набора, по которой оценивался релиз

Фиксация версий не делает ответы одинаковыми. Thinking Machines Lab в сентябре 2025 года показала, что сервер инференса может возвращать разные ответы на один и тот же промпт при нулевой температуре, потому что результат запроса зависит от того, сколько других запросов попало с ним в один батч; тот же пост показывает, что батч-инвариантные ядра устраняют это ценой скорости. Если сервер не использует такие ядра, воспроизводимость означает повторный прогон приёмочного набора на каждом релизе и сравнение оценок, а не ожидание идентичного текста.

Эксплуатация: мощности, очереди и час, когда сервер модели лежит

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

Системы сервинга объединяют запросы в батчи, чтобы ускоритель не простаивал. В статье о vLLM, представленной на SOSP 2023, Kwon и коллеги сообщили, что страничная организация KV-кеша внимания повысила пропускную способность в 2–4 раза при том же уровне задержки по сравнению с системами, которые они оценивали. Более крупные батчи повышают пропускную способность, но и увеличивают задержку каждого запроса; бэк-офисная очередь может это поглотить, а интерактивный шаг — нет, поэтому их разделяют:

• Интерактивная работа, например разбор тикетов, которого ждёт сотрудник поддержки, — со своими мощностями и целевой задержкой
• Пакетная работа, например ночное извлечение, — в очереди, которая поглощает пики и может быть поставлена на паузу
• Backpressure между приёмом и сервером модели: ограниченная очередь и лимит параллелизма, чтобы всплеск документов ждал или отклонялся с сигналом повторить попытку, а не перегружал сервер
• Идемпотентная обработка с ключом по документу, чтобы повтор после сбоя не создавал вторую запись
• Фолбэк на ручной процесс, когда сервер модели недоступен, чтобы работа ждала человека, а не пропадала

Именно фолбэк делает включение пайплайна обратимым. Существующий сегодня ручной процесс остаётся нижней планкой, а пайплайн снимает с него работу поле за полем, а не заменяет его в один день.

Мониторьте ответы, а не только серверы

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

• Доля записей, ушедших в очередь ручной проверки, и исправления проверяющих — по полю, по типу документов и по релизу
• Регулярная выборка автоматически созданных записей, которую люди перепроверяют по критериям приёмки
• Дрейф входных данных: новые отправители, новые шаблоны, соотношение языков и длина документов
• Срабатывания валидаторов в разрезе правил: они могут выявить новый формат раньше, чем сдвинутся метрики точности
• Токены, часы ускорителя и возраст очереди по типу документов — рядом с задержкой каждого этапа

Generative AI Profile от NIST, NIST AI 600-1, опубликованный в июле 2024 года, раскладывает эту работу по четырём функциям своего AI Risk Management Framework: govern, map, measure и manage (руководство, картирование, измерение и управление). Названия важны меньше, чем следствие: измерение после запуска — это явно обозначенная работа с выделенными под неё людьми, а не то, чем команда пилота занимается, когда у неё есть время.

Выкатывайте по полям и типам документов: теневой режим, режим с подтверждением, затем автоматический

Включение пайплайна для всего сразу в один день сводит все риски в одно событие. Поэтапная выкатка держит их порознь:

• Теневой режим: пайплайн обрабатывает живой трафик, никуда не пишет, а его записи сравниваются с тем, что сделали люди
• С подтверждением: пайплайн предзаполняет запись, человек подтверждает каждую, а исправления считаются по каждому полю
• Автоматический режим по каждому полю и типу документов — только там, где проходной порог выдерживается на живом трафике, а всё остальное по-прежнему проходит проверку
• Переключатель обратно в режим с подтверждением для отдельного типа документов, которым владелец эксплуатации пользуется без отдельного согласования, когда отслеживаемый показатель выходит за допустимый предел

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

Компания, которая доводит это до прода, просит ваши документы раньше, чем спрашивает, какую модель вы предпочитаете

У вопроса, стоящего за этой статьёй, — кто может развернуть LLM-пайплайн внутри вашей собственной инфраструктуры и действительно довести его до прода, — есть проверка, которой не нужен список подрядчиков. Компания, которая делает такую работу, спрашивает о приёмке и эксплуатации раньше, чем рекомендует модель:

• Просит посмотреть выборку реальных документов и тикетов, включая проблемные, внутри вашей среды или в рамках вашего соглашения о данных и спрашивает, как с ними сегодня справляется ручной процесс
• Предлагает сначала собрать приёмочный набор вместе с вашими людьми, с проходными порогами по каждому полю, и только потом что-либо настраивать
• Перечисляет все места, куда будут скопированы данные, — от весов и индексов до логов, трейсов, данных оценки, инструмента ручной проверки и мониторинга — и показывает, что каждое из них остаётся внутри
• Включает валидаторы, очередь ручной проверки и фолбэк на ручную обработку в тот же проектный документ, что и модель
• Приходит с релизом, который фиксирует модель, промпт, схему и парсер вместе, и с планом выкатки от теневого режима до автоматического по каждому полю
• Называет, кто эксплуатирует пайплайн после запуска, кто проверяет выборку и кого вызывают, когда сервер модели останавливается

О каждом пункте можно спросить в первом же разговоре, и расплывчатый ответ означает, что объём недостающей работы по пилоту ещё не определён.

Поэтому первый вопрос — не о том, какую модель запускать внутри вашего периметра. Он о том, какие поля и в каких документах вы готовы принимать в автоматическом режиме, относительно чего это измеряется и кто подхватывает записи, не прошедшие валидацию.

Что amBrain может подтвердить публично помимо интеграции в проде, описанной в кратком ответе выше: amBrain пишет софт с 2019 года. Мы работаем в трёх форматах: полная разработка, выделенная команда или наши инженеры в вашей команде.