Как оценить LLM перед продом: шесть практик на кейсе GitHub

В secret scanning GitHub LLM нужен не для «угадать класс строки», а чтобы убрать шумные алерты и не пропустить настоящие секреты. Команда описала шесть практик оценки модели до выкатки — когда офлайн-скор растёт, а поведение в проде нет.

На чистом бенчмарке входы однозначные, контекст полный. В проде метки расходятся, контекст обрезан, редкие краевые случаи вылезают постоянно. Precision и recall здесь не взаимозаменяемы: пропустить реальный токен опаснее, чем показать лишний алерт.

Шесть практик до прода

• Сначала продуктовое решение: цель — меньше false positive и выше precision; recall — ограничение безопасности; плюс guardrails по latency, стоимости и совместимости с пайплайном
• Офлайн как интеграционные тесты: прогон после каждого изменения промпта, модели или входа; версионирование конфигов; одна крупная переменная за раз
• Данные ближе к проду: тот же кандидат, окружение кода и формат входа — иначе сильный офлайн-скор отражает более лёгкую задачу
• Метки из прода — сигнал, не истина: закрытый алерт мог значить ротацию ключа или разблокировку CI, а не ложное срабатывание
• Синтетика для пробелов: неоднозначный ввод, соседние credential-like строки, пропущенный контекст — но не замена продоподобных примеров
• Разбор ошибок: агрегатные метрики показывают «стало лучше», error analysis подсказывает, что менять в промпте или контексте

Типичная ловушка: модель цепляется за example_token с «безопасным» именем переменной, хотя оценивать нужно соседний candidate_value. На датасете с одним очевидным кандидатом такое не всплывёт.

В гипотетическом baseline precision 0,71, recall 0,78, latency 1,2 с. Эксперимент с сильным ростом precision при recall ниже порога дальше не проходит — даже если по одной метрике выглядит как победа.

Источник: How to evaluate LLMs before production.