Зміст
Коротко
На GitHub Blog команда Microsoft / GitHub розібрала, як оцінювати системи на великих мовних моделях (LLM) перед продакшеном — на прикладі зниження хибних спрацьовувань під час сканування секретів. Головний тезис: починати не з промпта й моделі, а з продуктового рішення, метрик і жорстких обмежувачів безпеки.
Що сталося
Бенчмарки й чисті набори зручні на прототипі, але в проді входи неоднозначні, мітки шумні, контекст обрізаний, а рідкісні крайові випадки стають частими відмовами. Для сканування секретів питання звучало так: чи можна зменшити шум для розробника, зберігши достатню повноту (recall), щоб не пропустити справжній ключ.
Критерії розклали на три рівні: основний результат (точність / менше хибних спрацьовувань), обмежувач безпеки (повнота в допустимому коридорі), операційні рамки (затримка, вартість, надійність, сумісність). Офлайн-прогін вели як інтеграційний тест: версія промпта, моделі, датасету й пайплайну; змінювали по одній великій змінній. Набір мав бути схожим на прод — кандидат поруч із відволікаючими «схожими» рядками, а не один стерильний рядок.
Мітки з проду трактували як сигнали, не як істину: «закрив алерт» ≠ хибне спрацьовування. Синтетика й відкриті набори доповнювали діри покриття. Помилки групували за джерелом (модель, промпт, вхід, пайплайн, датасет, мітка). Модель-«суддя» допомагала сортувати чергу рев’ю, але не замінювала людину на спірних випадках. На офлайн-наборі досягли ~95% зниження хибних спрацьовувань при утриманні повноти в межах.
Чому це важливо
Багато команд крутять промпт, доки «цифра на бенчмарку» не зросте — і дивуються регресії в проді. Стаття фіксує інженерну дисципліну: оцінка = продукт + дані + відтворюваність + розбір помилок. Без цього «краща модель» може просто розв’язувати іншу задачу.
На практиці
- Запишіть рішення однією фразою й що не можна погіршити (для задач безпеки — повнота як стоп-кран).
- Версіонуйте промпт, модель, датасет і конфіг; порівнюйте з відомою базою.
- Змінюйте одну велику змінну за прогін — інакше не дізнаєтесь причину.
- Тримайте офлайн-вхід близьким до проду: шум, обрізки, сусідні відволікаючі значення.
- Розбирайте хибні спрацьовування й пропуски за категоріями — агрегат ховає, куди бити далі.
- Модель-«суддю» використовуйте для сортування черги рев’ю, не як еталон.
Підсумок
Офлайн-оцінка не доводить поведінку в усіх прод-сценаріях, але дає структуровані докази для обережного онлайн-експерименту. Без явної продуктової рамки оптимізація моделі — лотерея.