Оцінювання LLM для не-ML команд: вимірюйте якість, а не відчуття.

Чому «спробувати кілька промптів» не працює

Відповіді LLM варіюються, а покращення в одному місці часто спричиняє регресію в іншому. Зміна, що виправила три спробувані приклади, може зламати двадцять неспробуваних. Без фіксованого тестового набору кожна дискусія про якість — думка проти думки, і перемагає найгучніший стейкхолдер.

Перший набір оцінювання за тиждень

1. 1

   Зберіть реальні входи

   Візьміть 50–100 реальних питань, тікетів чи документів із робочого процесу. Включіть типові, складні кейси й ті, де правильна відповідь — «не знаю».

2. 2

   Запишіть, що означає «добре»

   Для кожного кейсу — еталонна відповідь чи ключові факти, які вона має містити, разом з експертами. Це найцінніша година проєкту.

3. 3

   Позначте кейси

   Мітки за типом (напрям продукту, мова, складність), щоб бачити слабкі місця, а не лише середнє.

4. 4

   Автоматизуйте прогін

   Скрипт, що проганяє кожен кейс через систему й зберігає відповіді, оцінки, вартість і затримку для кожного запуску.

5. 5

   Підтримуйте набір живим

   Кожна помилка в продакшні стає новим кейсом. Набір росте разом із реальним використанням.

Як оцінювати відповіді

Метрики, важливі для більшості команд

• Правильність — чи відповідь правильна?
• Достовірність — чи кожне твердження підтверджене наданими джерелами? (RAG)
• Якість відмов — чи відмовляє, коли треба, і не відмовляє, коли не треба?
• Відповідність формату — валідний JSON, обов'язкові поля, ліміти довжини.
• Безпека — без витоку персональних даних і порушень політик, стійкість до prompt injection.
• Вартість і затримка на кейс — поруч із якістю в кожному прогоні.

Оцінювання в CI: звичка, що запобігає регресіям

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