Шлюз завершенности: почему метрика «10 из 10» в тестировании локальных моделей — это обман
При сравнении локальных больших языковых моделей (LLM) единый показатель процента пройденных тестов (pass rate) часто оказывается бесполезным. Автор статьи объясняет, как разделение этапа генерации полного артефакта и этапа оценки его качества позволяет выявить скрытые сбои в работе моделей, которые маскируются под идеальные результаты.
# Шлюз завершенности: почему метрика «10 из 10» в тестировании локальных моделей — это обман
В мире оценки производительности локальных языковых моделей (LLM) соблазн похвалить систему за идеальную таблицу результатов очень велик. Однако, как показывает практика, красивая цифра «10 из 10» может скрывать фундаментальные ошибки в дизайне эксперимента. Главная проблема заключается в том, что традиционные метрики смешивают два совершенно разных процесса: техническое создание ответа и проверку его смыслового качества.
Для получения достоверных данных необходимо ввести понятие «шлюза завершенности» (completion gate) — механизма, который отделяет технически полный ответ от того, который пригоден для содержательной оценки. Ниже разберем, почему это различие критически важно и как оно меняет подход к выбору и настраиванию ИИ-моделей.
Ошибка измерения: когда «да» означает «почти нет»
Классическая ошибка при тестировании генеративных моделей заключается в объединении всех этапов в одну метрику успеха. Искусно спланированный эксперимент может показать 100% прохождения тестов, но на самом деле система могла просто генерировать формально верные ответы, которые были полны пустоты или ошибок, исправленных постфактум.
В одном из реальных случаев автор эксперимента получил результат, который выглядел безупречно на бумаге: три различных маршрута обработки данных (использующие разные конфигурации моделей) успешно прошли все десять сценариев тестирования. Медианное время выполнения варьировалось от 28,9 секунды до 99,1 секунды. Если смотреть только на колонку «принято», все системы казались равноценными. Если добавить время выполнения, преимущество отдавалось самому быстрому маршруту.
Однако, как только в расчет начали включаться «ремонтные работы» (deterministic repair) — автоматические корректировки формата ответа, — картина резко изменилась. Быстрая модель потребовала трех исправлений, тяжелая — двух, а смешанная конфигурация — одного. Это сразу указывало на нестабильность генерации. Тем не менее, даже после учета этих факторов делать однозначный вывод о превосходстве одной модели было преждевременно.
Проблема была не в модели или коде, а в определении единицы измерения. Автор смешал в одну категорию успешных результатов законченные ответы, корректный JSON, наличие обязательных документов, прохождение автоматических проверок и человеческую оценку. Такой «супер-метрика» давала высокий процент успеха, но не отвечала на вопрос: *почему* результат был получен или почему он мог не пригодиться пользователю.
Проблема усугубляется тем, что валидный JSON-объект часто воспринимается как готовый продукт. Модель может вернуть идеально структурированный объект, но в полях лежать только пути к будущим файлам или заглушки типа «требования необходимо реализовать». Для программиста, ожидающего реального контента, такой ответ бесполезен, но для ботворегистратора он проходит все формальные проверки.
Архитектура оценки: от шлюза к принятию
Для диагностики причин отказов необходимо декомпозировать процесс оценки на последовательные стадии. Ключевым моментом является разделение между завершенностью (completion) и качеством (quality).
Представьте себе поток данных, проходящий через несколько фильтров:
1. Завершение запуска: Рантайм завершил работу без тайм-аутов (timeout), падений (crash) или ошибки нехватки памяти (OOM). 2. Валидность формата: Сырой ответ сохранен, парсер успешно разберет его как JSON, и он соответствует заданной схеме (schema). 3. Комплетность артефактов: Ответ содержит все требуемые поля (например, source_map, system_context), и ни одно поле не является пустым или содержащим только ссылки на несуществующие файлы. 4. Качество содержания: Только на этой стадии начинается оценка того, насколько полезным является сгенерированный документ для решения конкретной задачи.
Шлюз завершенности (Completion Gate) выполняет функцию строгого фильтра. Его задача скромная и важная: определить, существует ли технически целый артефакт, который можно вообще подвергнуть оценке. Если генерация оборвалась на полуслове или модель вернула файл вместо текста, система должна помечать результат как incomplete. Это позволяет избежать ложных оценок качества, где ноль баллов за «плохой анализ» может быть получен просто из-за того, что модель молчала.
Разделение знаменателей (областей, в которых считается процент успеха) имеет решающее значение. Если раньше знаменателем для всех метрик были все попытки запуска, то теперь у каждой фазы свой знаменатель: * Endpoint completion: Процент успешных завершений работы рантайма. * Parse rate: Процент ответов, которые успешно разобраны парсером. * Quality pass rate: Процент ответов, которые прошли сценарные проверки, и знаменатель здесь — только те, которые достигли статуса quality_eligible (пригодны для оценки). * Human acceptance: Финальное решение человека о полезности результата.
Такой подход сохраняет диагностическую ценность. Вместо одной цифры «80%» мы получаем карту проблем: тайм-ауты говорят о настройке рантайма, невалидный JSON — о контракте взаимодействия, а ошибки содержательного характера — о запросе или контексте модели.
Почему таблица с результатами — это не рейтинг
Даже после внедрения шлюза завершенности и получения результатов, где все три маршрута показали «10 из 10», делать выводы о победе одной из конфигураций все равно рано. Таблица результатов отвечает лишь на вопрос: «Пройшла ли связка из модели, запроса и кода текущий набор проверок?». Она не показывает, насколько хорошо модель справится с непредвиденными ситуациями или сложными задачами, не включенными в тест.
В эксперименте были отмечены следующие ограничения интерпретации данных:
* Связка vs. Модель: Мы измеряем не изолированную модель, а комплексную систему: модель + запрос + схема + рантайм + политика детерминированного ремонта. Успех одного маршрута не гарантирует успеха при изменении даже одного параметра. * Отсутствие состязательных случаев: В наборе тестов отсутствовали специфические классы рисков, такие как полная утечка конфиденциальных данных, подмена инструкций (prompt injection) или специально спроектированные логические противоречия. Результаты на ролевых сценариях нельзя экстраполировать на отсутствие этих проверок. * Фрагментарность данных: В сохраненных записях доступны были только предварительные превью ответов (outputPreview), а не полные тексты. Семантические сравнения на основе этих фрагментов не являются доказательством превосходства модели. * Одиночный запуск: Данные основаны на единичных сохраненных прогонах. Для подтверждения стабильности необходимо повторять эксперименты при неизменных версиях модели, квантования и оборудования.
Таким образом, единственная достоверная заключительная мысль такова: успех в тестировании LLM определяется не только «умом» модели, но и тщательностью настройки всей инфраструктуры вокруг неё. Шлюз завершенности — это первый шаг к честной оценке, отделяющий техническую работоспособность от реального интеллектуального потенциала.
Рекомендации для будущих экспериментов
Для получения действительно воспроизводимых и объективных результатов при сравнении локальных моделей следует придерживаться следующего протокола:
1. Изоляция переменных: Фиксировать точную конфигурацию модели, рантайма, запроса, схемы и оборудования. Любое изменение создает новую экспериментальную конфигурацию. 2. Отдельные метрики: Для каждой фазы процесса (завершение, парсинг, валидация, качество) использовать свой собственный знаменатель. Не смешивать технические сбои с содержательными ошибками. 3. Сохранение полного следа: Архивировать полные исходные ответы и все этапы «ремонта» форматов. Это необходимо для воспроизводимости и глубокой диагностики. 4. Сценарное разнообразие: Включать в набор тестов не только ролевые задачи, но и состязательные случаи (конфликтующие источники, подмена инструкций, числовые несогласованности). 5. Человеческий контроль: Финальное принятие результата должно оставаться за человеком, отвечающим за использование документа. Автоматические тесты не могут заменить профессиональную оценку пригодности.
Шлюз завершенности не делает модель умнее и не повышает качество генерируемых ответов. Его функция — честно провести границу, за которой качественные метрики теряют смысл. Только после того, как рантайм вернет целый и валидный объект, парсер проверит контракт, а сценарные тесты согласуют свойства документа, человек может принять окончательное решение о пригодности результата. Именно это разделение превращает красивые таблицы с цифрами «10 из 10» в инструменты для реальной диагностики системы.