Регулярно спостерігаємо один і той самий сценарій: команда обирає модель ембедінгів на основі позиції в рейтингу MTEB, впроваджує її у продакшен і лише через кілька тижнів скарг користувачів виявляє, що асистент не знаходить очевидних документів. Публічний бенчмарк показує, як модель справляється з чужими даними англійською. Він нічого не говорить про те, як вона впорається з вашими договорами, процедурами ISO чи сервісними запитами польською. Єдине надійне вимірювання — це оцінка на наборі, який відображає реальні запити ваших користувачів.
Три метрики, які справді щось означають
#Оцінка семантичного пошуку зводиться до одного питання: чи для даного запиту відповідні фрагменти з’являються високо у списку результатів. Це вимірюють три взаємодоповнюючі метрики.
Recall@k відповідає, яка частка очікуваних фрагментів потрапила до топ k результатів. Це метрика «чи взагалі знайшли». Якщо очікуєте 3 релевантних документів, а в топ 5 з’явилося 2, recall@5 становить 0,67. Recall@k є ключовим для RAG, оскільки генеративна модель бачить лише те, що retrieval їй підкаже; відсутній фрагмент — це відсутній контекст і ризик галюцинацій.
MRR (Mean Reciprocal Rank) вимірює, наскільки високо з’являється перший релевантний результат. Для запиту, в якому релевантний документ на позиції 1, внесок становить 1; на позиції 2 — 1/2; на позиції 4 — 1/4. MRR усереднює ці обернені значення за всіма запитами. Високий MRR означає, що часто влучаєте «з першого разу», що дозволяє подати моделі менше контексту та знизити витрати на токени.
nDCG (normalized Discounted Cumulative Gain) — найвимогливіша з трійки. Враховує не лише те, чи релевантний результат високо, але й ступінь релевантності (можна позначити фрагмент як «дуже релевантний» або «частково релевантний») і штрафує за розміщення слабших результатів над кращими. nDCG варто рахувати, коли є градуйовані оцінки релевантності, а не лише бінарні «підходить/не підходить».
| Метрика | Що вимірює | Коли використовувати | Типовий поріг (корпоративні документи PL) |
|---|---|---|---|
| Recall@k | Покриття: скільки релевантних у топ k | Завжди, як перша метрика | recall@5: 70-80% |
| MRR | Позиція першого релевантного | Коли важливо «з першого разу» | 0,70-0,85 |
| nDCG@k | Якість ранжування з вагою релевантності | Коли є градуйовані оцінки | 0,75-0,88 |
| Precision@k | Частка релевантних у топ k | Коли хибні спрацювання коштують дорого | залежить від порогу |
Цифри у стовпці «поріг» — це діапазони, які ми спостерігали в проєктах з польськими корпоративними документами, а не універсальні константи. Сприймайте їх як точку відліку для калібрування, а не як самоціль.
Як створити тестовий набір пар запитання-фрагмент
#Без golden set нема чого вимірювати. Golden set — це список пар: реалістичне запитання + набір фрагментів, які мають з’явитися у відповідь. Створення виглядає так.
Почніть зі збору 50-100 реальних запитань. Найкраще джерело — логи реальних запитів до асистента, звернення до саппорту або інтерв’ю з людьми, які будуть користуватися системою. Запитання, вигадані «за столом», занадто регулярні й не відображають мову користувача, який пише з помилками, скороченнями та в різних відмінках.
Для кожного запитання позначте релевантні фрагменти. Тут виникає рішення: бінарні оцінки (підходить/не підходить) швидші, градуйовані оцінки (дуже релевантний / частково релевантний / нерелевантний) дають багатший сигнал для nDCG. Для першої ітерації достатньо бінарних оцінок. Анотування має виконувати людина, яка знає галузь, а не мовна модель, бо модель тут є об’єктом оцінки.
| Крок | Дія | Пастка, якої слід уникнути |
|---|---|---|
| 1 | Зберіть 50-100 реальних запитань з логів або інтерв’ю | Вигадані запитання занадто «чисті» |
| 2 | Позначте релевантні фрагменти (бінарно або градуйовано) | Анотування через LLM спотворює вимірювання |
| 3 | Проіндексуйте корпус тим самим пайплайном, що й у продакшені | Інший chunking = непорівнянний результат |
| 4 | Запитайте golden set, порахуйте метрики | Тест лише на «легких» запитаннях |
| 5 | Повторіть для 2-3 моделей паралельно | Зміна багатьох змінних одночасно |
Важливо, щоб корпус для оцінки був проіндексований точно так само, як і продуктивний: та сама стратегія chunking, той самий розмір фрагмента, та сама модель. Якщо зміните chunking між тестом і продакшеном, метрики перестануть щось означати. Вибір самої векторної бази розглядаємо окремо в статті про те, як обрати векторну базу.
Пастки офлайн та онлайн оцінки
#Метрики, розраховані на golden set, — це офлайн оцінка: контрольована, повторювана, дешева. Однак вона має обмеження, які не можна ігнорувати.
Перша пастка — перенавчання на golden set. Якщо багаторазово налаштовуєте пайплайн під той самий набір з 80 запитань, зрештою оптимізуєте під ці конкретні запитання, а не під реальні. Тримайте частину пар як «валідаційний сет», який не використовуєте для налаштування. Друга пастка — дрейф даних: golden set, створений на корпусі піврічної давнини, перестає відображати документи, які з’явилися пізніше.
Онлайн оцінка вимірює поведінку на живому трафіку: клікабельність результатів, частка запитів, що закінчуються ескалацією до людини, оцінки «палець вгору/вниз», частка відповідей, позначених як нерелевантні. Сигнал «брудніший», ніж офлайн, але саме він говорить правду про досвід користувача. Найкраща практика — поєднання обох: офлайн як швидкий фільтр при кожній зміні моделі або chunking, онлайн як остаточний арбітр у продакшені. Той самий поділ офлайн/онлайн застосовуємо при оцінці агентів AI, де синтетичні тести перевіряють регресії, а продуктивні метрики підтверджують реальну цінність.
Третя пастка специфічна для RAG: хороший retrieval — необхідна, але не достатня умова для хорошої відповіді. Можете мати recall@5 на рівні 85%, а користувачі все одно будуть незадоволені, бо генеративна модель погано підсумовує знайдений контекст. Тому метрики retrieval вимірюйте окремо від метрик якості відповіді (вірогідність, релевантність). Плутання цих двох шарів — найпоширеніша діагностична помилка, яку ми спостерігаємо.
Специфіка польської мови у вимірюванні
#Польська флексія ускладнює оцінку ембедінгів для польської мови. Користувач запитує про «fakturę», а документ містить «faktur», «fakturze», «fakturami». Слабка для польської модель сприйме ці форми як віддалені точки, тому релевантний фрагмент опуститься в ранжуванні, хоча змістовно підходить ідеально. У golden set свідомо додавайте запитання у відмінкових формах та з недбало введеною діакритикою («wez» замість «weź»), бо так пишуть реальні користувачі.
Другий фактор — це змішаний мовний корпус для валідації. Польські корпоративні документи сповнені англійських термінів: compliance, vendor, deliverable, SLA. Якщо ваш golden set містить виключно чисті польські речення, ви переоціните якість моделі на даних, які насправді є двомовними. Обираючи модель, варто звернутися до такої з багатим багатомовним корпусом, наприклад, BGE-M3; детальніше про це пишемо в статті про ембедінги для польської мови.
Третє питання: коли чистий векторний retrieval не закриває польські галузеві терміни та каталожні номери, варто виміряти, скільки додає гібридний пошук. Порахуйте recall@5 для самих векторів, а потім для векторів у поєднанні з BM25 на тому самому golden set. Якщо різниця перевищує кілька відсотків, гібрид окупається. Усі ці порівняння мають сенс лише тоді, коли змінюєте одну змінну за раз і вимірюєте на незмінному тестовому наборі.
FAQ
#Скільки пар запитання-фрагмент достатньо для надійної оцінки?
#Для першої, орієнтовної оцінки достатньо 50-100 ретельно підібраних пар. Такий набір виявить разючі відмінності між моделями та дозволить відсіяти очевидно слабкі варіанти. Для стабільних, статистично надійних порівнянь між близькими моделями варто прагнути до 200-300 пар, бо при малій вибірці кілька складних запитань можуть змістити результат на кілька відсотків.
Чим відрізняється recall@k від precision@k?
#Recall@k показує, яка частка всіх релевантних фрагментів потрапила до топ k, тобто вимірює покриття. Precision@k показує, яка частка результатів у топ k є фактично релевантною, тобто вимірює «чистоту» списку. У RAG зазвичай пріоритетом є recall, бо відсутній контекст боляче більше, ніж один зайвий фрагмент, який генеративна модель все одно проігнорує. Precision набуває значення, коли хибні спрацювання коштують дорого або вводять в оману.
Чи можна покладатися на рейтинг MTEB або BEIR при виборі моделі?
#Публічні бенчмарки корисні як попередній фільтр, щоб звузити список кандидатів, але не замінять вимірювання на ваших даних. Корпуси MTEB і BEIR здебільшого англомовні та загальногалузеві, тому погано прогнозують поведінку на польських договорах чи сервісних запитах. Сприймайте рейтинг як відправну точку, а рішення приймайте на основі власного golden set.
Як часто повторювати оцінку після впровадження?
#Офлайновий golden set варто перераховувати при кожній зміні моделі, стратегії chunking або reranker, бо це швидкий фільтр регресій. Незалежно від цього, раз на квартал оновлюйте сам golden set новими запитаннями з продакшену, щоб він встигав за дрейфом даних і мови користувачів. Онлайн метрики (оцінки, ескалації) моніторте постійно, як і при моніторингу якості агента AI.
Чи гарантує хороший recall@5 якісні відповіді асистента?
#Ні. Високий recall означає лише, що релевантні фрагменти потрапляють до контексту, що є необхідною, але не достатньою умовою. Генеративна модель може погано підсумувати хороший контекст, пропустити ключову деталь або додати інформацію поза джерелом. Тому якість retrieval (recall, MRR, nDCG) вимірюйте окремо від якості відповіді (вірогідність, релевантність), бо це два різні шари з різними причинами збоїв.