Як оцінювати LLM-функцію до та після запуску

LLM-функція може видавати плавні відповіді й водночас не виконувати завдання користувача. Оцінювання перетворює нечітке враження на кшталт «нова модель здається кращою» на відтворювані докази того, чи покращує зміна продукт. Оцінювання має бути частиною дизайну функції та релізу, а не одноразовим тестом після вибору моделі.

Почніть із завдання користувача та ціни помилки. Запишіть, що має робити добра відповідь, чого вона не повинна робити, коли варто поставити уточнювальне запитання, утриматися від відповіді або передати запит людині. Розділіть вимоги: фактична точність, повнота, обґрунтованість джерелами, коректність формату, тон, затримка й вартість. Один загальний бал може приховати серйозне погіршення за окремим критерієм.

Створіть невеликий версійований набір реалістичних прикладів: типові запити, граничні випадки, неоднозначні введення, приклади різними мовами та відомі помилки. Додайте вхідні дані, потрібний контекст або знайдені джерела, очікувані властивості й еталонну відповідь лише там, де її справді можна обґрунтувати. Видаляйте персональні й конфіденційні дані, фіксуйте походження набору та залиште контрольну частину, на якій автори промптів не налаштовують рішення.

Використовуйте детерміновані перевірки для об’єктивних вимог: валідацію схеми, обов’язкові поля, наявність цитат, результат перевірки доступу чи точність обчислень. Для відкритих критеріїв якості поєднуйте експертну перевірку з модельними оцінювачами, що працюють за рубрикою. Калібруйте оцінювачів за людськими мітками, досліджуйте розбіжності й перевіряйте чутливість до формулювань. Модельний суддя — це допоміжний вимірювальний інструмент, а не істина.

Запускайте той самий набір на поточній системі й кожній запропонованій зміні: версії моделі, системному промпті, параметрах пошуку, описах інструментів чи декодуванні. Порівнюйте результати для окремих прикладів і зрізів за мовою, групою користувачів, типом завдання та ризиком. Зберігайте складні помилки в наборі й після виправлення. За мінливих відповідей моделі використовуйте повторні запуски або інтервали невизначеності.

Офлайн-бали не описують усього досвіду користувача. У продакшені відстежуйте виконання завдань, виправлення відповідей користувачами, ескалації, відмови й утримання від відповіді, затримку, вартість і події безпеки; вибірково аналізуйте відповіді з урахуванням приватності. Наперед визначте пороги релізу й умови відкату. Перевіряйте приклади з фахівцями предметної області: реальні користувачі й дані виявляють помилки, яких немає у штучних запитах.

Робочий цикл простий: визначити успіх, зібрати репрезентативні приклади, запустити автоматичні перевірки, передати невизначені або критичні випадки людям, порівняти версії, поступово розгорнути зміни й додати підтверджені продакшен-помилки до набору. Профіль генеративного AI від NIST рекомендує документовані перевірки та постійний моніторинг; посібник OpenAI Evals описує повторно використовувані набори й оцінювачі. Джерела: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ та https://platform.openai.com/docs/guides/evals