Microsoft и GitHub поделились опытом оценки и внедрения системы на базе больших языковых моделей (LLM) для снижения числа ложных срабатываний в функции secret scanning на GitHub. Этот инструмент ищет в репозиториях учетные данные и ключи, однако часть найденных строк только внешне похожа на секреты и порождает лишние оповещения для разработчиков.
Команда была заинтересована не в том, чтобы LLM просто правильно классифицировал строки, а в том, чтобы заметно сократить шумные алерты при сохранении безопасного уровня полноты (recall) в продуктивном сценарии. Задача заключалась в том, чтобы уменьшить количество ложных срабатываний и при этом не пропускать реальные секреты.
Авторы отмечают, что при оценке систем на основе LLM стандартные бенчмарки и офлайн-метрики полезны только на раннем этапе. По мере приближения к продакшену ключевыми становятся другие факторы: реальные входные данные неоднозначны, разметка неполна или противоречива, важный контекст отсутствует или обрезан, а распределение примеров отличается от используемых наборов.
Перед изменением промпта, модели или конвейера команда сначала формулировала решение, которое нужно было принять: может ли система снизить количество ложных срабатываний и при этом сохранить достаточную полноту для безопасной работы безопасности. Для этого заранее определялись допустимые ошибки, метрики, влияющие на продуктовые решения, и защитные ограничения.
В secret scanning риск от скрытого настоящего секрета выше, чем лишняя проверка разработчиком. Поэтому точность (precision) и полнота (recall) рассматривались неравнозначно: улучшение точности было основной целью, а снижение полноты допускалось лишь в заранее заданных границах. Приоритетом становилась конфигурация, которая сильнее всего сокращала ложные срабатывания, не выходя за рамки по полноте и эксплуатационным ограничениям, таким как стоимость и задержка.
Критерии оценки разделили на три уровня: пользовательский эффект, ограничения безопасности и эксплуатационные параметры. Это не позволяло считать любую метрику равноценной: изменение, которое улучшает качество, но делает систему слишком медленной или дорогой, не считалось полезным.
Оценка рассматривалась как повторяемый инженерный процесс, а не разовая проверка перед релизом. Команда запускала офлайн-оценку каждый раз при значимой смене промпта, модели, способа формирования входных данных или бизнес-логики вокруг модели. Для каждого прогона фиксировались промпт, версия модели, версия датасета и конфигурация системы, чтобы можно было воспроизвести результаты и сравнивать их с базовой линией.
Чтобы понимать, что именно привело к изменению метрик, эксперименты строили по принципу одного крупного изменения за прогон. Например, сначала оценивали обновленный промпт, отдельно — новую модель, а затем тестировали их вместе. Это важно, поскольку даже небольшая правка промпта меняет поведение модели, а обновление модели влияет на качество, стоимость, задержку и стабильность формата вывода.
Промпты и конфигурации оценок велись как код: их версионировали, документировали изменения, обеспечивали воспроизводимость прошлых вариантов и возможность отката. Это уменьшало риск ошибочной интерпретации результатов, полученных при разных скрытых условиях.
Отдельный акцент сделан на том, что более современная модель часто лучше работает с простым промптом, чем старая модель с большим количеством уточнений. Проще промпт — легче интерпретировать, тестировать и сопровождать систему. Однако любые обновления модели требуют тщательной повторяемой оценки, поскольку улучшения в одной категории могут сопровождаться регрессиями в других.
Авторы подчеркивают, что офлайн-оценка полезна только тогда, когда она близка к реальной задаче. В secret scanning модель обычно анализирует не одну строку, а значение с учетом окружающего кода и дополнительной информации, которая может быть неполной или отвлекающей. Поэтому офлайн-пайплайн должен сохранять важные характеристики продуктивного сценария: структуру ввода, формат контекста, неоднозначность и наличие «лишних» значений.
Даже небольшие отличия между офлайн-набором и продуктивными данными искажают картину. Более «чистый» датасет может исключать спорные случаи или предоставлять слишком полный контекст. Тогда высокая офлайн-метрика отражает более простую задачу, чем та, что система решает в реальной эксплуатации.
Производственные данные делают оценку репрезентативнее, но их разметка часто описывает результат рабочего процесса, а не фактическую истину. Например, отклоненное или закрытое оповещение secret scanning не всегда означает ложное срабатывание; визуально одинаковые статусы в продукте могут соответствовать разным реальным сценариям.
Для важных или неоднозначных подмножеств приходилось проводить ручной аудит. Цель была не в том, чтобы сделать разметку идеальной, а в том, чтобы добиться достаточной точности данных для принимаемого решения. Там, где доступ к продуктивным данным ограничен, использовались синтетические примеры, академические бенчмарки и открытые наборы, но как дополнение, а не замена данных, похожих на продакшен.
Синтетические примеры оказались полезны для тестирования редких и труднодоступных случаев: неоднозначных входов, отсутствующего контекста, необычного форматирования, специфических паттернов ошибок. В secret scanning это, к примеру, соседние строки, похожие на креденшелы, тестовый код, плейсхолдеры, косвенные ссылки. Внешние примеры адаптировались под задачу, а разметка, не совпадающая с определениями продукта, пересматривалась.
Авторы отмечают важность глубокой разборки ошибок. Совокупные метрики показывают общую динамику, но не объясняют, что именно нужно менять дальше. Для этого изучались ложноположительные и ложноотрицательные срабатывания, а затем они группировались по источнику проблемы: модель, промпт, входные данные, пайплайн, датасет, разметка.
Каждый тип ошибки вел к своему действию: рассуждение о неверном значении требовало переработки промпта или структуры входа, нехватка фактов — улучшения контекста, неверные метки — очистки данных. Повторяющиеся неоднозначности, специфичные для домена, могли сигнализировать о необходимости уточнить продуктовую политику или добавить отдельную категорию оценки.
Ручной просмотр десятков или сотен примеров занимает время, но, по оценке авторов, часто ускоряет прогресс: как только паттерн регулярной ошибки становится ясным, команда может внести целевое изменение и проверить его эффект. Полезный вопрос в анализе ошибок: ошибка связана с моделью, промптом, входом, пайплайном, набором данных или разметкой. Такой разбор переводит абстрактную претензию к качеству в конкретную инженерную задачу.
Полностью ручной разбор масштабируется плохо, поэтому часть нагрузки можно переложить на LLM, выступающую в роли «судьи». Такая модель может фильтровать очевидные случаи, подсвечивать потенциально неверно размеченные примеры и выделять спорные случаи для человека. Однако ее выводы рассматриваются как еще одно предсказание, а не эталонная истина, поэтому человеческий контроль остается обязательным.
Применив повторяемую офлайн-оценку и целенаправленный анализ ошибок, команда добилась сокращения ложных срабатываний на 95% на оценочном офлайн-наборе при сохранении полноты в рамках заданного ограничения. При этом стало понятно, за счет каких изменений достигнут результат: офлайн-оценка была ближе к реальной задаче, изменения сравнивались с воспроизводимыми базовыми конфигурациями, а оставшиеся паттерны ошибок были задокументированы.
Авторы подчеркивают, что такая оценка не гарантирует корректное поведение системы во всех сценариях в продакшене, но дает достаточно структурированных аргументов для перехода к онлайн-экспериментам с понятными рисками и защитными ограничениями. Они предлагают использовать чек-лист, который помогает проверить, достаточно ли четко определены цели, данные, экспериментальный план и оставшиеся риски перед внедрением системы.
Материал подготовили Марико, Principal Applied Scientist в Microsoft, которая занимается разработкой агентных ИИ-процессов для операций кибербезопасности, и Зиксяо, Senior Applied Scientist в Microsoft, работающая над системами обнаружения секретов и агентной безопасностью. Их работа фокусируется на переносе современных ИИ-исследований в практические масштабируемые продукты и операционные процессы.
Источник: блог GitHub / Microsoft.
