Языковая модель может показывать сильные результаты на чистом бенчмарке, а затем давать сбои в неоднозначных случаях, которые действительно важны для пользователей в производственной среде. Именно этот главный урок GitHub представляет в материале, написанном Mariko Wakabayashi и Zixiao Chen 25 августа 2026 года, на основе эксперимента по оценке системы, использующей языковую модель для сокращения ложных срабатываний в рамках GitHub secret scanning.
Сканирование секретов ищет учётные данные, такие как токены и ключи, которые могли попасть в программный репозиторий. Однако некоторые строки похожи на секреты, не являясь настоящими учётными данными, из-за чего разработчикам приходится проверять оповещения, не требующие обработки. Поэтому вопрос команды заключался не в том, может ли модель классифицировать отдельную строку, а в том, способна ли она уменьшить уровень шума, сохранив достаточную полноту, чтобы сделать чувствительный к безопасности рабочий процесс безопасным.
Начинайте с решения по продукту, а не с выбора модели
GitHub рекомендует определить решение, которое должна поддерживать оценка, до изменения промпта, добавления контекста или смены модели. В случае сканирования секретов целью было сокращение ложных срабатываний и повышение точности, тогда как полнота использовалась как ограничение безопасности. Случайно скрыть настоящие учётные данные может быть опаснее, чем попросить разработчика проверить дополнительное оповещение.
На практике критерии оценки были разделены на три уровня: основной результат, измеряющий пользу для пользователя, — сокращение ложных срабатываний и точность; ограничение безопасности — полнота; и эксплуатационные ограничения, включающие задержку, стоимость, надёжность и совместимость с производственной средой. Таким образом, повышение точности не считается автоматическим успехом, если оно сопровождается неприемлемым снижением полноты или делает систему медленной, дорогой либо сложной для интеграции.
Превратите оценку в воспроизводимый интеграционный тест
Оценка — это не единичный шаг перед запуском. Промпты, модели, способ формирования входных данных и окружающая их логика системы постоянно меняются, а любое изменение может привести к улучшению, ухудшению или переносу схемы ошибок в другое место. Поэтому GitHub повторно запускала оценку после каждого существенного изменения, каждый раз фиксируя версию промпта, модели, набора данных и настройки системы.
Кроме того, команда изолировала одну основную переменную в каждом эксперименте, сравнивая изменение промпта с известной базовой линией до проверки вместе с ним обновления модели. Промпты и настройки оценки описывались как код: им присваивались версии, изменения документировались, а возможность повторно запускать прежние настройки и откатывать их сохранялась. Это позволяет понять причину улучшения или ухудшения, а не ошибочно приписывать её последнему изменению.
Имитируйте производственную задачу, а не ограничивайтесь чистыми данными
Результаты офлайн-оценки полезнее, когда они похожи на реальную задачу. При сканировании секретов модель не обязательно смотрит на изолированное значение: она видит кандидата в окружающем программном коде и дополнительную информацию, которая может быть неполной или разрозненной. Она может сосредоточиться на другом значении, кажущемся более связанным с безопасностью, например на тестовом токене в коде, вместо кандидата, который требуется оценить.
Поэтому следует сохранять характеристики производственной задачи, включая оцениваемого кандидата, окружающий контекст, дополнительную информацию, способ форматирования входных данных и наложения ограничений, а также более широкую логику системы. Если в оценке используются более ясные примеры и более полный контекст, чем в реальности, результат может отражать более простую проблему, чем та, с которой система столкнётся после развёртывания.
Рассматривайте метки и данные как проверяемые свидетельства
Результат определённого действия в продукте не означает, что он представляет собой надёжную эталонную истину. Закрытие оповещения при сканировании секретов может означать, что учётные данные были заменены, что риск был принят, что оповещение закрыли для открытия рабочего процесса или что оно было ошибочно классифицировано. В данных рабочего процесса эти случаи выглядят одинаково, но не отвечают на один и тот же вопрос в рамках оценки.
Перед использованием производственных данных необходимо понять, как создавалась метка, соответствует ли она вопросу оценки и не были ли разные результаты объединены в одну категорию. GitHub предлагает проводить проверку людьми для важных или неоднозначных категорий, а не предполагать, что каждая метка верна. Синтетические данные и открытые бенчмарки могут восполнять пробелы в покрытии, особенно в редких случаях — таких как отсутствующий контекст, необычное форматирование и близкие к учётным данным значения, — но они должны дополнять данные, близкие к производственным, а не заменять их.
Анализируйте ошибки и осторожно используйте модель-оценщик
Итоговые метрики сообщают команде, улучшилась ли система, но не объясняют, что следует изменить дальше. Поэтому GitHub проверяла выборки ложноположительных и ложноотрицательных результатов и классифицировала их возможные причины как связанные с моделью, промптом, входными данными, конвейером, набором данных или метками. Такая классификация превращает общую проблему качества в конкретную инженерную задачу: лучшее представление входных данных, иное формирование контекста, очистка данных или более ясная политика продукта.
Другую языковую модель можно использовать в качестве оценщика, чтобы уменьшить нагрузку на людей, обрабатывая очевидные случаи и расставляя приоритеты среди неоднозначных. Однако её результаты не являются эталонной истиной: она может ошибаться или соглашаться с оцениваемой моделью по неправильной причине. Более безопасный подход — направлять случаи с низкой уверенностью, противоречивые или имеющие высокий эффект людям, периодически отбирать для проверки случаи, которым оценщик присвоил высокую уверенность, а также отслеживать его расхождения с системой и проверяющими, версионировать его промпт и проводить его оценку.
Что именно доказал эксперимент?
GitHub сообщила, что добилась сокращения ложных срабатываний на 95% на оценённом офлайн-наборе данных, сохранив полноту в пределах заданного ограничения безопасности. Однако компания не представила этот результат как доказательство того, что система будет вести себя так же во всех производственных сценариях. Наибольшая ценность заключалась в понимании того, как был достигнут результат: оценка, более близкая к реальной задаче, воспроизводимые базовые линии и документированные схемы ошибок.
Редакционный комментарий certi.news: фактическое изменение здесь заключается не в выпуске новой модели, а в превращении оценки систем LLM из эталонного эксперимента в непрерывный инженерный процесс, связанный с ясным решением, ограничениями безопасности и эксплуатации. Это важно для команд, занимающихся программным обеспечением, безопасностью и инструментами разработчиков, поскольку улучшение одной метрики может скрывать опасное снижение полноты или рост стоимости. В то же время результат остаётся ограниченным набором оценки, качеством меток и разрывом, который невозможно устранить между офлайн-тестированием и поведением в производстве; поэтому оценки являются основой для перехода к контролируемому производственному эксперименту, а не заменой мониторинга рисков после запуска.