GitHub Security Lab опубликовала детальный разбор того, как команда оценивала LLM перед развёртыванием в системе секретного сканирования. Материал адресован разработчикам, которые переходят от прототипирования на бенчмарках к реальной эксплуатации языковых моделей. Основной тезис: чистая точность на бенчмарке не гарантирует, что модель справится с шумными, неоднозначными или редкими данными в продакшене.
Проблема: бенчмарки не отражают реальное распределение данных
Команда GitHub столкнулась с типичной ситуацией: LLM показывала высокие результаты на стандартных тестах, но в рабочем контуре — при фильтрации ложных срабатываний секретного сканирования — вела себя непредсказуемо. Реальные запросы оказались неполными, метки разметки — противоречивыми, а контекст часто обрезался. Кроме того, редкие, но критичные кейсы, почти не представленные в бенчмарках, в продакшене становились частыми источниками ошибок.
Для секретного сканирования GitHub это означало, что модель должна не просто классифицировать строку как секрет или не секрет, а существенно снизить количество ложных тревог, не пропуская при этом настоящие учётные данные. Пропуск реального токена — более серьёзная проблема, чем лишнее оповещение разработчика.
Метрики нужно разделять на три уровня
GitHub предложил структурировать оценку вокруг трёх категорий метрик:
- Целевые (пользовательский эффект) — то, ради чего внедряется система. В случае с секретным сканированием — снижение ложных срабатываний и повышение precision.
- Защитные (guardrails) — ограничения, которые нельзя нарушать. Для той же задачи — recall не должен падать ниже заданного порога, иначе система перестаёт быть безопасной.
- Операционные — стоимость, задержка, сложность интеграции. Улучшение качества не имеет смысла, если система становится слишком медленной или дорогой.
Такой подход исключает ситуацию, когда одну метрику улучшают за счёт другой, не осознавая последствий. Например, эксперимент A может повысить precision, но резко снизить recall, а эксперимент B — дать умеренный прирост precision при сохранении recall в допустимых границах. С точки зрения продукта, B — правильный выбор.
Ключевые факты
| Параметр | Значение |
|---|---|
| Источник | GitHub Blog, пост инженеров Security Lab |
| Дата публикации | 25 августа 2026 |
| Прикладная задача | Снижение ложных срабатываний секретного сканирования |
| Число уровней оценки | 3: целевой, защитный, операционный |
Оценка должна быть повторяемой и изолированной
GitHub подчёркивает: оценка LLM — не разовое действие. После каждого изменения промпта, модели, способа сборки контекста или бизнес-логики прогон нужно повторять. Для этого команда версионирует промпты и конфигурации, фиксирует версию датасета и параметры запуска. Это позволяет сравнивать результаты разных экспериментов и точно определять, какое изменение привело к улучшению или регрессу.
Важное правило: менять только одну переменную за раз. Если в одном эксперименте меняется и промпт, и модель, невозможно понять, что именно повлияло на результат. GitHub рекомендует сначала протестировать новую модель со старым промптом, затем — старую модель с новым промптом, и только потом — комбинацию.
Простота промпта как ресурс
Отдельный урок касается сложности промптов. Когда LLM работает хуже ожидаемого, инженеры часто добавляют в промпт новые инструкции. Однако более сильная модель может показывать лучший результат с коротким и простым промптом, чем старая модель с длинным списком правил. Простые промпты легче тестировать, поддерживать и откатывать.
GitHub предупреждает: смена модели может улучшить качество в одной категории, но ухудшить в другой, а также изменить стоимость, задержку или формат вывода. Каждый апгрейд требует полного перепрогона оценочного пайплайна.
Что это значит для разработчиков
Материал GitHub — не абстрактная рекомендация, а документированный опыт инженерной команды, работающей над реальным продуктом. Для читателей Comrad404, которые внедряют LLM в инструменты анализа кода, безопасности, обработки данных или автоматизации, этот пост даёт конкретную схему: как не попасть в ловушку бенчмарков, как отделить полезные улучшения от вредных и как сделать оценку воспроизводимой.
Источник: GitHub Blog — How to evaluate LLMs before production (https://github.blog/ai-and-ml/llms/how-to-evaluate-llms-before-production/)