Критерии приёмки LLM: как проверить качество, скорость и устойчивость

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

Разделите четыре результата

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

Блок	Пример проверяемого условия	Доказательство
Качество	Ответ опирается на актуальный разрешённый документ	Протокол оценки и ссылка на источник
Скорость	Согласованная доля запросов укладывается в задержку	Клиентские измерения и серверные метрики
Доступ	Пользователь не получает чужие документы	Отрицательные тесты по ролям
Эксплуатация	Сервис восстановлен из заданного состояния	Журнал учебного восстановления

Численные пороги назначает бизнес вместе с исполнителем. Универсального p95 или процента правильных ответов для всех корпоративных помощников нет.

Составьте контрольный набор до настройки

Возьмите реальные типы вопросов, но удалите сведения, которые нельзя передавать в тестовую среду. Включите обычные случаи, длинные документы, противоречивые версии, отсутствие ответа в базе и намеренно неверные предпосылки пользователя. Для задач извлечения данных сохраните эталонную структуру и правила нормализации.

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

Оценку сложных ответов проводят по инструкции: что считать ошибкой, когда требуется отказ, насколько существенна неполная ссылка. Разногласия оценщиков сохраняют. NIST рассматривает оценку и управление рисками в контексте назначения системы; приведённая схема является нашей практической адаптацией этого подхода. 1

Зафиксируйте условия производительности

В протоколе должны быть модель и ревизия, формат весов, версия runtime, GPU, CPU, память, настройки очереди, входная и выходная длина, concurrency и длительность теста. Укажите, прогрета ли модель и какие кэши доступны. Холодный запуск оценивается отдельно.

Время до первого токена, интервалы генерации и полная длительность характеризуют разные части ответа. Документация NVIDIA NIM описывает эти метрики раздельно. 2 Не сравнивайте скорость выдачи короткого ответа одного поставщика с длинным ответом другого. Отдельно считайте ошибки, отмены, таймауты и отклонённые запросы.

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

Проверьте границы и восстановление

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

Для RAG смените права пользователя, отзовите документ и проверьте, когда изменение отражается в поиске. Убедитесь, что история разговора и кэш не возвращают ранее доступный фрагмент после ограничения прав. Архитектура должна объяснять такие сценарии до нагрузочного теста.

Подпишите решение по результату

Итог содержит статус каждого критерия: выполнен, не выполнен или не проверен. Непроверенный пункт не считается пройденным. Условия исправления, срок повторного теста и допустимые ограничения фиксируют отдельно. Последующие обновления модели или runtime запускают согласованный регрессионный набор.

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