Completion gate: как отличить реальный ответ локальной языковой модели от заглушки

Разработчик, тестировавший связки из локальных языковых моделей и окружающего кода, столкнулся с проблемой, знакомой каждому, кто автоматизирует генерацию документов. Три экспериментальных маршрута показали идеальный результат: десять из десяти сценариев пройдены. Медианы по времени отличались заметно: 28,9 секунды у быстрого маршрута, 99,1 у тяжёлого, 71,0 у смешанного. Но за одинаковой колонкой «принято» скрывались разное количество исправлений и разное качество итоговых документов.

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

Что такое completion gate и зачем он нужен?

Completion gate (шлюз завершённости) решает скромную задачу: определить, существует ли целый результат, который вообще можно оценивать. Это не оценка стиля, полноты анализа или правильности выводов. Это проверка предпосылок оценки.

В эксперименте модель должна была вернуть один JSON-объект (формат обмена данными, читаемый и машиной, и человеком) с четырьмя документами в формате Markdown: карту источников, контекст системы, найденные противоречия и пакет задач.

Минимальный набор проверок шлюза выглядел так:

• Процесс завершился без тайм-аута, сбоя или нехватки памяти
• Сырой ответ сохранён
• Парсер (программа-разборщик) разбирает ответ как JSON
• Объект соответствует схеме
• Все четыре документа присутствуют
• Каждый документ содержит текст, а не путь к файлу или заглушку
• Если формат пришлось чинить, ремонт записан отдельно

Аргументы за: почему одного pass rate мало?

Главный довод: фраза «pass rate равен 80%» ничего не говорит о знаменателе. В восемь «успешных» случаев могли попасть совершенно разные события:

• Ответы, прошедшие схему с первой попытки
• Ответы после ремонта формата
• Законченные документы с содержательной ошибкой
• Результаты, отклонённые человеком при ручной проверке

Каждый тип отказа требует своего исправления. Тайм-аут (когда система прерывает генерацию по лимиту времени) ведёт к настройке рантайма. Повреждённый JSON ведёт к парсеру. Пропущенное требование ведёт к промпту или к замене модели. Один процент стирает всю эту диагностику.

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

Ещё один сильный довод: валидный JSON обманчиво похож на готовый результат. Автор приводит два примера. Первый: модель возвращает не документы, а пути к будущим файлам. Второй: модель заполняет все поля формальными заглушками вроде «Источники перечислены в проекте» и «Противоречий не обнаружено». Оба варианта проходят проверку типов, но для пользователя бесполезны.

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

Аргументы против: где шлюз создаёт новые проблемы?

Автор честно обозначает ограничения. Запретить несколько фраз-заглушек недостаточно: локальная языковая модель найдёт другой способ вернуть формально заполненное поле. Проверка заглушек требует осторожности: минимальная длина текста после удаления заголовка, наличие структурных элементов, поиск обещаний вроде «будет добавлено позже», проверка ссылок между документами.

Чем больше смысловых правил попадает в completion gate, тем выше риск незаметно превратить его в ещё одного судью качества. Граница между «результат технически пригоден для оценки» и «результат хорош по содержанию» размывается, и шлюз начинает дублировать ту самую метрику, которую призван разгрузить.

Есть и практическая цена: отчёт со стадиями длиннее одной цифры. Для команды из двух человек это приемлемо, для конвейера из сотен запусков в день дополнительная сложность ощутима.

Один процент стирает диагностику. Тайм-аут ведёт к настройке рантайма, повреждённый JSON ведёт к парсеру, пропущенное требование ведёт к промпту или к способности модели. Это не рейтинг моделей и не рекомендация для выбора инфраструктуры. : Автор эксперимента

Что делать с этим прямо сейчас?

Разработчикам, которые строят системы на локальных языковых моделях. Разделите свой единый pass rate на два слоя. Первый: техническая пригодность (процесс завершён, JSON валиден, артефакты на месте и не заглушки). Второй: оценка содержания. Когда метрика падает, вы сразу видите, чинить рантайм или переписывать промпт.

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

Предпринимателям, выбирающим между облаком и локальным запуском. Метод применим к любой модели, облачной или локальной. Но именно при локальном запуске (через Ollama, llama.cpp и подобные инструменты) тайм-ауты и нехватка памяти случаются чаще, и без шлюза завершённости вы не отличите проблему железа от проблемы модели.

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