У цій статті
Головна думка
Переконлива демонстрація не доводить надійності. Перевіряйте, чи знаходить система докази, чи правильно використовує їх і чи коректно діє без відповіді. Зберігайте експертну перевірку поряд з автоматичними оцінками.
Створіть випадки, здатні виявити помилку системи
Почніть із питань майбутніх користувачів. Для кожного запишіть роль користувача, редакцію джерела, потрібні докази й прийнятний результат. Деякі питання не повинні мати відповіді в колекції. Інші потребують уточнення продукту, дати чи юрисдикції. Це корисні перевірки, а не незручні винятки.
Відокремте оцінювальну колекцію від прикладів налаштування промптів. Включіть конкурентні версії, суперечливі уривки й правдоподібні хибні назви продуктів. Попросіть бізнес-експерта пояснити прийнятність відповіді внутрішнього асистента. Пояснення стане критерієм для іншого перевіряльника замість розпливчастого «має гарний вигляд».
Оцінюйте пошук і генерацію окремо
Ragas перелічує точність і повноту контексту, релевантність відповіді та вірність джерелам. Це корисні напрями оцінювання. Спочатку перевірте, чи знайдено необхідні уривки. Потім — чи правильно відповідь використала їх і чи справді відповіла на питання. Один загальний бал ускладнює діагностику різних помилок.
Автоматичні оцінювачі — докази, а не остаточні судді. Розбирайте розбіжності з людьми, особливо в галузевій термінології та франкомовних питаннях. Фіксуйте версії моделі-оцінювача й критеріїв, щоб зміну оцінки не прийняти за поліпшення застосунку. За близьких результатів вивчайте помилки, а не оголошуйте невелику числову різницю вирішальною.
Три перевірки перед довірою до відповіді
Визначте причину помилки до зміни системи.
Чи знайдені докази?
Перевірте вибрані фрагменти й відсутні джерела.
Чи відповідає відповідь доказам?
Перевірте фактичні твердження й підтверджувальні цитати.
Чи корисний результат?
Обговоріть відповідь, уточнення або передачу завдання з відповідальним за процес.
Явно перевіряйте посилання, відмови та права
Посилання корисне, лише якщо уривок підтверджує твердження й читач може його відкрити. Перевіряйте зламані посилання, видалені документи та відповіді з кількох джерел. Позначайте непідтверджені факти окремо від стилістики. Гарна відповідь із вигаданою умовою допуску має провалити перевірку.
Додайте негативні тести для інформації поза колекцією та поза правами користувача. Перевірте ворожі інструкції всередині документів: знайдений текст — матеріал для оцінювання, а не повноваження змінювати правила застосунку. Задайте очікувані відмову, уточнення чи передавання людині. Не винагороджуйте асистента просто за постійне видавання відповіді.
Включіть оцінювання в кожен випуск
Повторюйте порівняння за зміни моделі, ембедингів, поділу, фільтрів чи колекції джерел. Зберігайте базовий результат і вивчайте відмінності за категоріями. У важливому процесі регресія прав має блокувати випуск навіть за зростання середнього бала. Критерії приймання погодьте з власником до отримання результатів.
В експлуатації поєднуйте вибіркову перевірку людьми з метриками: часом відповіді, помилками завантаження, повідомленнями про непідтверджені відповіді та вартістю завершеного завдання. Не зберігайте чутливі діалоги лише заради зручності панелі. Практична поставка включає звіт оцінювання, приклади помилок і процедуру відновлення. Так «ШІ став кращим» перетворюється на перевірювану й оборотну зміну.
Створіть запис тесту, який може перевірити колега
Для кожного випадку зберігайте питання, профіль доступу, застосовну редакцію й очікувану поведінку. «Правильна відповідь» надто розпливчасто. Для питання про правила вкажіть твердження й підтверджувальний уривок. Для забороненого джерела — відсутність конфіденційного тексту й назви. Для питання без відповіді — очікуване уточнення або передавання.
Відокремте еталонний набір від прикладів налаштування промптів. Включіть звичайні й складні запити, записавши призначення кожного випадку. За провалу зберігайте результати пошуку й відповідь відповідно до політики зберігання. Це дає перевіряльникам докази замість червоного бала з недоступною причиною.
Невеликий реєстр оцінювання
Приклад структури тестів. Очікувані результати має перевірити власник документів.
Прокрутіть по горизонталі, щоб прочитати таблицю →
| Випадок | Очікуваний результат | Що перевірити в доказах |
|---|---|---|
| Відоме правило, користувач із доступом | Підтверджена відповідь за застосовною редакцією | Твердження й підтверджувальний уривок |
| Немає застосовного правила | Уточнення або явне передавання людині | Жодних вигаданих правил |
| Джерело з обмеженим доступом | Без конфіденційного тексту й назви | Пошук, відповідь, посилання й кеші |
| Суперечливі редакції | Суперечність явно показано | Дати дії та власники джерел |
Дивіться на розмір вибірки та наслідки помилок
Умовні 18 правильних відповідей із 24 — це шість помилок, а не доведена частка успіху в експлуатації. Розберіть нешкідливі відмінності формулювань, непідтверджені твердження й порушення доступу. Повторюйте нестабільні випадки та показуйте склад вибірки, щоб успіх на простих питаннях не приховував слабкої критичної категорії.
Автоматичні метрики допомагають знаходити проблеми й визначати пріоритети перевірки; калібруйте їх за експертними оцінками типових відповідей. Випуск можна блокувати за будь-якого виявленого порушення доступу, окремо оцінюючи пошук і користь. Розширюйте впровадження поступово та після аналізу додавайте реальні збої до набору. Офлайн-тести обґрунтовують випуск, але не скасовують спостереження в експлуатації.
Джерела й додаткові матеріали
Документацію перевірено .
ЗАПИТАННЯ / РІШЕННЯ
Поширені запитання
Чи є єдиний цільовий бал для промислового RAG?+
Ні. Помилки помічника для чернеток і асистента з правил мають різні наслідки. Визначайте пороги за типом помилки та впливом на бізнес, потім вивчайте конкретні випадки.
Чи може LLM-оцінювач замінити перевірку людиною?+
Він допомагає масштабувати відбір, але рішення потрібно калібрувати за експертною перевіркою. Зберігайте участь людей у неоднозначних, чутливих і важливих випадках.