|
|||||||||
Як оцінювати RAG-системи: метрики, методи та що вимірювати насамперед
|
 Коли RAG-система дає збій, по одній відповіді неможливо зрозуміти, чому це сталося. RAG розшифровується як retrieval-augmented generation – генерація з доповненням через пошук – і це одна з найпоширеніших технік проектування контексту, що дозволяє додавати AI-агентам додаткову інформацію, а отже, і підвищувати точність їхньої роботи. Оскільки RAG є критично важливим компонентом сучасних AI-додатків, розробникам потрібен метод оцінки LLM, який дозволяє виявляти проблеми та відстежувати якість роботи RAG. В цьому посібнику розберемося, що саме потрібно вимірювати на кожному етапі RAG-конвеєра, чому важлива кожна метрика і як побудувати процес оцінки так, щоб він не просто фіксував наявність проблем, а показував, де саме вони виникають. Також розглянемо найефективніший підхід до оцінки LLM-as-a-judge. Підключення LLM до етапу оцінки багато в чому витіснило застарілі детерміновані метрики на кшталт BLEU та ROUGE, які вимірювали збіг слів, а не смислову точність. LLM краще справляються з оцінкою релевантності тексту, тому вони добре підходять для набору інструментів оцінки RAG. Як виходять з ладу RAG-системи і чому оцінка має бути роздільноюПомилки в RAG-системах діляться на три категорії, які зовні виглядають однаково, але вимагають різних способів виправлення:
Розглянемо конкретний приклад. Користувач запитує внутрішнього HR-асистента: «Чи я маю право на відпустку по догляду за дитиною, якщо працюю тут 11 місяців?» Система відповідає: «Співробітникам належить 12 тижнів відпустки для догляду за дитиною». Що це було — помилка пошуку, коли система знайшла спільний документ про політику відпустки, але згаяла документ з умовами, де вказано мінімальний стаж 12 місяців? Чи помилка генерації, коли потрібний документ було знайдено, але модель проігнорувала вимогу до стажу та відповіла лише на поверхневу частину питання? Виправляти ці випадки треба по-різному. Помилка пошуку може означати, що при розбитті на фрагменти критерії права на відпустку виявились відокремлені від інформації про пільги. Помилка генерації може означати, що у вашому промпті не вистачає очевидної вказівки перевіряти попередні умови перед тим, як відповідати. Роздільна оцінка – коли пошуковий модуль та генератор перевіряються незалежно один від одного, а потім оцінюється їх спільна робота – дозволяє локалізувати слабкі місця та вносити точкові покращення, а не ворожити наосліп. Три виміри якості RAG: «тріада RAG»Найкорисніша діагностична схема для оцінки RAG вимірює три взаємозв'язки:
Оскільки збої можуть виникати як на стороні пошуку, так і на стороні генерації, найкорисніші стратегії оцінки RAG передбачають роздільну перевірку пошукового модуля та генератора, а вже потім – вимірювання якості системи від початку до кінця. LLM-as-a-Judge: механізм оцінки, що лежить в основі цих метрикБільшість метрик, про які йдеться у цьому посібнику, засновані на підході LLM-as-a-judge: коли досить сильна LLM використовується для оцінки результатів, виданих іншими моделями. Цей підхід багато в чому витіснив застарілі метрики, що ґрунтуються на перетині токенів, такі як BLEU та ROUGE. Вони вимірювали збіг слів на поверхні тексту, а не зміст чи фактичну точність. Відповідь, яка передає правильну інформацію, але іншими словами, отримала б низьку оцінку BLEU; LLM у ролі судді здатна розпізнати семантичну еквівалентність.Варто знати про два фреймворки. G-Eval (Liu et al., EMNLP 2023) запропонував використовувати для оцінки покрокове міркування, при якому модель-суддя перед виставленням оцінки спочатку формулює критерії крок за кроком, а потім використовує ймовірності токенів, щоб отримувати безперервні, а не цілочисельні оцінки. Opik G-Eval реалізований як вбудована метрика, тому його можна безпосередньо застосовувати до результатів вашої RAG-системи. Prometheus (Kim et al., ICLR 2024) показав, що моделі з відкритим вихідним кодом, навчені спеціально для завдань оцінки, можуть демонструвати таку ж кореляцію з людськими оцінками, як і GPT-4, якщо їм задати структуровані рубрики. Для конвеєрів оцінки RAG це важливо тому, що ви не виявляєтеся прив'язані до пропрієтарних моделей у ролі судді: платформи на кшталт Opik дозволяють використовувати як основу для оцінки будь-яку LLM, що підтримується LiteLLM, включаючи open-source варіанти. Оцінка тріади RAG на практиціДавайте детальніше розберемо кожен вимір тріади RAG: що саме воно вимірює, чому це важливо і як реалізувати таку оцінку за допомогою Opik.Як виміряти якість пошуку у RAG-системах?Перший вимір оцінює зв'язок між запитом користувача і знайденим контекстом. Релевантність контексту показує, наскільки знайдені документи дійсно стосуються того, про що запитував користувач. Якщо пошуковий модуль отримує нерелевантні фрагменти, відбуваються дві речі: ви даремно витрачаєте токени в контекстному вікні LLM і підвищуєте ризик того, що модель включить у відповідь зайвий шум.У межах цього виміру точність контексту показує, наскільки добре пошуковий модуль ранжує релевантну інформацію. Знайти правильний документ важливо, але не менш важливо, де в списку він опинився. Дослідження Liu та ін. показало, що при обробці довгого контексту мовні моделі демонструють U-подібну криву якості: вони добре сприймають інформацію на початку та в кінці вхідних даних, але часто упускають те, що знаходиться посередині. Через цей ефект «втрата в середині» пошуковий модуль, який ховає найрелевантніший документ на 8-е місце з 10, по суті, майже так само марний, як би він взагалі його не знайшов. Opik надає і ContextPrecision, і ContextRecall як інтегровані метрики на базі підходу LLM-as-a-judge. Обидві використовують few-shot-промптинг із структурованими рубриками та виставляють оцінку за шкалою від 0.0 до 1.0: from opik.evaluation.metrics import ContextPrecision, ContextRecall
За замовчуванням обидві метрики використовують GPT-4o як оцінювача, але при необхідності ви можете переключитися на будь-яку модель, що підтримується LiteLLM, задавши параметр model. Метрика ContextPrecision штрафує системи, які поміщають релевантні документи нижче в ранжованому списку, тоді як ContextRecall показує, чи пошуковий модуль витягнув всю релевантну інформацію, необхідну для очікуваної відповіді.
precision_metric = ContextPrecision() recall_metric = ContextRecall() precision_score = precision_metric.score( input="Am I eligible for parental leave if I've been here 11 months?", output="Employees are eligible for 12 weeks of parental leave.", expected_output="Employees must complete 12 months of tenure to qualify.", context=["Parental leave policy: Eligible employees receive 12 weeks…", "Eligibility: Employees must complete 12 months of continuous employment."], ) recall_score = recall_metric.score( input="Am I eligible for parental leave if I've been here 11 months?", output="Employees are eligible for 12 weeks of parental leave.", expected_output="Employees must complete 12 months of tenure to qualify.", context=["Parental leave policy: Eligible employees receive 12 weeks…", "Eligibility: Employees must complete 12 months of continuous employment."], ) Як виявляти галюцинації у відповідях RAG?Друга сторона тріади, groundedness, тобто обгрунтованість, – у фреймворку Ragas її також називають вірність контексту (faithfulness) – оцінює, чи справді відповідь генератора підтверджується знайденим контекстом. Це ваш основний інструмент для виявлення галюцинацій, і для більшості продуктових команд саме ця метрика виявляється найважливішою у всьому стеку оцінки.Зазвичай оцінка вірності контексту під капотом працює так. Система спочатку розкладає згенерований у відповідь окремі фактичні твердження. Наприклад, відповідь «Вам покладено 12 тижнів відпустки для догляду за дитиною після першого року роботи, і ви можете розділити її на два періоди» містить три твердження: тривалість відпустки – 12 тижнів, для неї потрібен один рік стажу, і його можна розділити на дві частини. Потім оцінка перевіряє кожне твердження щодо знайденого контексту. Якщо в документі з політикою нічого не сказано про поділ відпустки, то третє твердження – це галюцинація: модель додала правдоподібну деталь зі своїх навчальних даних. Оцінка вірності контексту – це ставлення числа підтверджених тверджень до загальної кількості тверджень. Оцінка 1.0 означає, що кожен вислів можна простежити до знайденого контексту. Оцінка 0.6 означає, що 40% тверджень взялися звідкись ще — найімовірніше, з навчальних даних моделі або взагалі були вигадані. Високі значення вірності контексту показують, що генератор поводиться як «прошарок природної мови» над вашою базою знань, а не імпровізує за рахунок своєї параметричної пам'яті. В Opik виявлення галюцинацій реалізовано як вбудована метрика: from opik.evaluation.metrics import Hallucination
metric = Hallucination() score = metric.score( input="Am I eligible for parental leave if I've been here 11 months?", output="You're eligible for 12 weeks of parental leave after your first year, and you can split it into two blocks.", context=["Eligible employees receive 12 weeks of parental leave.", "Employees must complete 12 months of continuous employment to qualify."], ) Низькі оцінки – це тривожний сигнал: модель додає інформацію, яку ви не надавали. Особливо небезпечно це у таких галузях, як охорона здоров'я, право чи фінансові послуги, де точність не підлягає компромісам. Що вимірює релевантність відповіді в оцінці RAG?Третя сторона тріади виявляє тонкий, але важливий тип збою: відповідь може бути фактично обґрунтованою та технічно коректною, але при цьому не відповідати на запитання користувача по суті. Релевантність відповіді показує, наскільки згенерована відповідь відповідає вихідному запиту, і знижує оцінку відповідей, які неповні, надмірні або йдуть убік від теми.Щоб обчислити релевантність відповіді без заздалегідь написаної еталонної відповіді, можна використовувати підхід із зворотним відновленням. LLM генерує кілька гіпотетичних питань, на які поточна відповідь дійсно могла б бути відповіддю, а потім система вимірює семантичну схожість між цими синтетичними питаннями і реальним запитом користувача. Якщо відповідь дійсно релевантна, то відновлені таким чином питання повинні бути дуже близькими до того, що спочатку запитав користувач. Ця метрика дозволяє зловити сценарії, які виявляє лише вірність контексту. Користувач запитує: "Як мені скинути пароль?" А система у відповідь видає докладне, добре обґрунтоване пояснення архітектури безпеки вашої компанії. Кожне твердження підтверджується знайденим контекстом. Оцінка вірності контексту ідеальна. Але користувач все одно не розуміє, як скинути пароль. Метрика релевантності відповіді штрафує саме за такий розрив. У Opik для цього є метрика Answer Relevance, яка реалізує такий підхід. У поєднанні з ContextPrecision, ContextRecall та Hallucination ці чотири метрики дають повне діагностичне покриття тріади RAG. Метрики пошуку для налаштування у продакшеніТріада RAG надає вам високорівневу діагностику стану системи. Але коли потрібно тонко налаштувати реальну конфігурацію пошукового модуля – включаючи такі параметри, як розмір фрагментів, налаштування top-K та вибір моделі ембеддингів – знадобляться більш детальні метрики з класичної теорії інформаційного пошуку.Recall@K показує частку всіх релевантних документів, які потрапили до перших K результатів. Якщо у вашій базі знань є п'ять документів, здатних відповісти на конкретний запит, а пошуковий модуль видає лише три з них у першій десятці, recall@10 дорівнюватиме 0.6. Ця метрика особливо важлива в таких галузях, як право або медичні дослідження, де пропуск навіть одного релевантного документа може призвести до неповного чи неправильного висновку. Precision@K вимірює зворотний бік: яка частка перших K результатів дійсно релевантна. Якщо ви витягли 10 документів, але корисні лише 3, то precision@10 дорівнює 0.3. Низька точність означає, що ви забиваєте контекстне вікно LLM зайвим шумом, витрачаєте токени марно і підвищуєте ймовірність того, що модель заплутається через нерелевантний вміст. Mean Reciprocal Rank, або MRR, фокусується на тому, наскільки швидко пошуковий модуль знаходить один-єдиний найкращий результат. Ця метрика обчислює середнє значення зворотного рангу першого релевантного документа набору запитів. MRR, що дорівнює 1.0, означає, що найкращий документ завжди виявляється на першому місці. MRR, що дорівнює 0.5, означає, що він зазвичай з'являється на другому. Ця метрика особливо важлива у випадках, коли системі, як правило, потрібна одна авторитетна відповідь, а не синтез інформації з кількох джерел. Normalized Discounted Cumulative Gain, або NDCG, враховує градуйовану релевантність, тобто визнає, що одні документи можуть бути релевантнішими за інші, замість того щоб розглядати релевантність як бінарну характеристику. Ця метрика заохочує системи, які ставлять найрелевантніші документи нагору, застосовуючи логарифмічне зниження вкладу для результатів, розташованих нижче у списку. Для складних запитів, де різні документи вносять різні частини відповіді, NDCG дає більш тонку картину ніж бінарні precision або recall. Ці метрики також допомагають оптимізувати гіперпараметри пошуку. Якщо у вас низька оцінка контекстної релевантності, тобто частка дійсно корисного тексту серед знайдених фрагментів невелика, можливо, ви отримуєте надто великі шматки тексту. Коли мала частина кожного фрагмента має відношення до запиту, це сигнал, що варто поекспериментувати з меншим розміром фрагментів або з більш агресивним етапом переранжування. Усунення оцінювача, за якими потрібно стежитиLLM у ролі оцінювача несуть у собі систематичні усунення, які можуть спотворювати ваші оцінки. Найпоширеніші їх – це позиційне зміщення, коли перевага надається відповідям залежно від своїх місця у промпті, а чи не від якості; зміщення на користь багатослівності, коли довші відповіді отримують вищі оцінки незалежно від змістовності; і усунення у бік згоди, коли модель краще підтверджує правильні відповіді, ніж виявляє неправильні. Через це автоматична оцінка може систематично завищувати надійність системи.Якщо говорити саме про оцінку RAG, варто знати про такий підхід до калібрування, як Prediction-Powered Inference, або PPI, запропонований у фреймворку ARES (Saad-Falcon et al., 2024). PPI використовує невеликий набір прикладів, розмічених людьми, щоб статистично скоригувати автоматичні оцінки та додати довірчі інтервали. Це свого роду перевірка на реальність, яка допомагає відкалібрувати ступінь довіри до решти результатів автоматичного оцінювача. Як впровадити оцінку RAG на практиціТепер, коли метрики зрозумілі, давайте обговоримо, як перетворити їх використання на робочий процес, що відтворюється.Почніть якомога раніше збирати датасет для оцінкиОснова будь-якого конвеєра оцінки – це тестовий датасет із пар «запит-відповідь», який відображає передбачувані сценарії використання вашої системи. Почніть збирати його перш, ніж оптимізувати щось ще. Корисний датасет для оцінки має включати різні типи запитів: прості фактичні питання з однозначними відповідями, складні питання, які вимагають синтезу інформації з кількох документів, неоднозначні запити, де системі потрібно коректно працювати з невизначеністю, і навіть «негативні» запити, куди система має відмовитися відповідати, оскільки потрібної інформації немає базі знань.Щоб розпочати, не потрібні тисячі прикладів. Навіть 50-100 добре складених пар «запит-відповідь», що покривають ключові сценарії, з якими має справлятися ваша система, вже дадуть вам осмислену базу. Приклади рівня «золотого стандарту», розмічені експертами, ідеально підходять для перевірки високорискових сценаріях, але їх підготовка обходиться дорого. Масштабуйтеся за допомогою синтетичних даних, але обережноЩоб доповнити датасети, розмічені людьми, можна використовувати LLM для створення синтетичних тестових даних на основі вашого корпусу документів. Поширений підхід виглядає так: ви подаєте документи на вхід досить сильної моделі та просите її згенерувати кілька різноманітних питань та відповідних відповідей щодо їхнього змісту. Це корисно для швидких ітерацій та розширення покриття, але тут є важливе застереження: синтетичні дані відображають розуміння генеруючої моделі, а не обов'язково справжній стан справ.Для продакшен-систем у високоризикових сферах – таких як охорона здоров'я, фінанси чи юридичні послуги – синтетичні дані варто розглядати лише як відправну точку для тестування на етапі розробки. А перед прийняттям рішень про виведення системи в продакшен завжди потрібно перевіряти результати щодо «золотих» наборів, що пройшли людську верифікацію. Оцінка за допомогою Opik: наскрізний робочий процесНайсильніші команди відносяться до оцінки RAG так само, як команди розробки відносяться до модульного тестування: вона запускається автоматично, блокує викладку під час падіння якості та видає результати, які зрозумілі всій команді. Ось як це виглядає у Opik.Спочатку визначте метрики. Почніть із покриття тріади RAG: Hallucination, ContextPrecision, ContextRecall та AnswerRelevance. Функція evaluate в Opik приймає список метрик і проганяє їх усі по вашому датасету за один прохід: from opik.evaluation import evaluate
from opik.evaluation.metrics import ( Hallucination, ContextPrecision, ContextRecall, AnswerRelevance ) metrics = [ Hallucination(), ContextPrecision(), ContextRecall(), AnswerRelevance(), ] results = evaluate( dataset=your_dataset, task=your_rag_pipeline, scoring_metrics=metrics, experiment_config={ "model": "gpt-4o", "chunk_size": 512, "top_k": 5, }, ) Задайте пороги проходження та провалу. Потрібно явно визначити, що для вашого сценарію вважається «досить гарною» якістю – наприклад, вірність контексту має бути вищою за 0.85, а релевантність відповіді – вищою за 0.75. Запускайте оцінку як частину вашого CI/CD-конвеєра, щоб зміни в промпті або оновлення конфігурації пошуку, що викликають регресію, відловлювалися ще до виходу в продакшен. Порівнюйте експерименти. Параметр experiment_config дозволяє помічати кожен запуск оцінки конфігурацією, яка його породила: моделлю, розміром фрагментів, значенням top-K, версією промпта. Потім інтерфейс Opik дає можливість порівнювати експерименти пліч-о-пліч, щоб ви точно бачили, як зміна конфігурації вплинула на кожну метрику. Переходьте до моніторингу у продакшені. Коли система вже працює в бойовому режимі, правила Online Evaluation в Opik дозволяють автоматично проганяти ті ж самі метрики продакшен-трейсами. Якщо оцінка вірності контексту знижується, ви можете провалитися в конкретний трейc, який дав низький результат, побачити, які саме документи були вилучені, вивчити промпт, відправлений до LLM, і зрозуміти, де виник збій – на етапі пошуку чи генерації. Саме тут сходяться спостереження та оцінка якості. Логування трейсів під час розробки допомагає робити ітерації. Логування у продакшені допомагає виявляти дрейф та деградацію. А автоматична оцінка цих трейсів перетворює сирі дані спостереження на прикладні сигнали про якість системи. Стрес-тестування та змагальна оцінкаМетрики, про які йшлося раніше, оцінюють, чи коректно працює RAG-система в нормальних умовах. Але продуктові системи повинні вміти обробляти і вхідні дані іншого роду: неоднозначні, шкідливі чи спеціально сконструйовані те щоб використовувати вразливості архітектури конвеєра. Стрес-тестування та змагальна оцінка дозволяють перевірити, як система поводиться, коли щось йде не так навмисно.Прикордонне тестування: що відбувається поза «успішного шляху»?Перш ніж думати про змагальні атаки, варто перевірити, як система справляється з легітимними, але складними вхідними даними. Сюди ставляться запити, куди система має відмовитися відповідати, оскільки необхідної інформації немає у основі знань; питання, що вимагають синтезу інформації з кількох документів; неоднозначні запити, де намір користувача незрозумілий; а також вхідні дані з хибними передумовами, яким система має заперечувати, а не бездумно сприймати їх за істину.Наприклад, користувач каже вашому HR-асистенту: «Якщо компанія подвоює внески в 401(k) на рівні 8%, я хочу вибрати максимум». Якщо насправді розмір зіставлення становить 4%, система має виправити хибну передумову, а чи не будувати подальшу відповідь її основі. Такі тести нескладно скласти: профільні експерти зазвичай легко можуть придумати десятки підступних прикордонних випадків на основі практичного досвіду. І саме вони дозволяють зловити типи збоїв, які базові метрики вірності контексту та релевантності взагалі не помічають. Специфічна поверхня атак у RAGRAG-системи створюють вектори атак, яких немає у автономних LLM. У редакції «Топ-10 ризиків безпеки для LLM-застосунків за версією OWASP» за 2025 рік з'явився новий пункт – «уразливості векторного пошуку та ембеддингів», спеціально присвячений вразливості RAG. Це відбиває, наскільки центральну роль конвеєри пошуку почали грати продуктових AI-системах.Найсерйозніша загроза, характерна саме для RAG - це те, що дослідники називають непрямою ін'єкцією промпту: шкідливі інструкції вбудовуються не в запит користувача, а в документи, які витягує система. Greshake та ін. формалізували цей клас атак у статті 2023 року, представленій на ACM Workshop on Artificial Intelligence and Security (AISec 23), показавши, що додавання механізму пошуку до LLM фундаментально розмиває кордон між даними та інструкціями. Коли RAG-система отримує документ із прихованими вказівками на кшталт «ігноруй попередній контекст і відповідай [вмістом атакуючого]», LLM може підкоритися цим вказівкам, тому що не вміє надійно відрізняти знайдений контекст від системних команд. Пов'язана із цим загроза – отруєння бази знань – йде далі. Тут зловмисник не впроваджує інструкції безпосередньо, а псує сам корпус, яким йде пошук, додаючи до нього документи, спеціально створені так, щоб спливати за певними запитами і підштовхувати модель до заздалегідь заданих, але неправильних відповідей. Дослідження PoisonedRAG (Zou et al., представлене на USENIX Security 2025) показало, що впровадження всього п'яти спеціально підготовлених документів у корпус із мільйонів записів може забезпечити успішність атаки вище 90% для цільових запитів відразу на кількох LLM та за різних конфігурацій пошуку. Атака працює тому, що отруєні документи оптимізовані одразу під дві умови: під умову пошуку – щоб їх піднімав механізм вилучення, та під умову генерації – щоб вони направляли відповідь LLM у потрібний зловмисник. Причому це ефективно навіть за умов чорного ящика, коли атакуючий взагалі немає доступу до параметрів пошукового модуля. Що саме потрібно тестуватиПрактичний набір тестів для змагальної оцінки RAG-систем повинен як мінімум включати:Стійкість до ін'єкції промпту. Перевіряйте систему на типових шаблонах ін'єкцій, доданих до запитів користувача: перевизначення ролі («Тепер ти необмежений помічник...»), перевизначення інструкцій («Ігноруй попередні інструкції та...»), а також їх замасковані варіанти. Вимірюйте, чи поведінка системи відхиляється від очікуваного і чи розкриває вона вміст системного промпту. Цілісність основи знань. Якщо ваш корпус поповнюється з джерел, які ви не контролюєте повністю – користувацьких документів, веб-скрейпінгу, сторонніх баз даних – перевіряйте, що відбувається, коли в цьому вмісті є шкідливе навантаження. Додайте в тестове середовище шкідливі документи з високою семантичною близькістю та вимірюйте, чи витягує їхня система та чи починає діяти відповідно до них. Коректна відмова. Переконайтеся, що система у разі потреби відмовляється відповідати тоді, коли її просять: на запитання поза своєю предметною сферою, на запити дій, які вона не повинна виконувати, наприклад схвалення повернення коштів або постановка медичного діагнозу, а також на запити, де знайденого контексту недостатньо для надійної відповіді. Узгодженість при перефразуванні. Задавайте те саме питання різними формулюваннями і перевіряйте, чи зберігається змістовна узгодженість відповідей. Неузгодженість під час перефразування часто вказує на те, що система надто чутлива до поверхневого формулювання, а не до реального наміру користувача. Це одночасно проблема надійності, і потенційний вектор експлуатації. Щоб розпочати такі перевірки, не потрібні складні інструменти. Таблиця зі змагальними запитами, очікуваною поведінкою та критеріями проходження чи провалу – з оцінкою через LLM-суддю, відкалібровану за схемою людина в контурі, – дозволить відловити більшість критичних проблем ще до того, як з ними зіткнуться користувачі. Спочатку почніть вимірювати, потім покращуватиКоли дивишся на весь набір доступних метрик, фреймворків та інструментів, оцінка RAG може здатися страшною. Але на практиці шлях вперед простіший, ніж здається. Почніть із тріади RAG: релевантності контексту, щоб перевірити пошуковий модуль; вірність контексту, щоб виявляти галюцинації; і релевантність відповіді, щоб переконатися, що система дійсно допомагає користувачеві. Ці три метрики покривають критичні типи збоїв і дають діагностичну основу для точкових поліпшень.У міру зростання системи додавайте спеціалізовані метрики пошуку, такі як recall@K і MRR, щоб тонко налаштовувати конфігурацію пошуку. І обов'язково вкладайтеся в калібрування вашого конвеєра LLM-as-a-judge за оцінками людей, щоб автоматичні бали дійсно відображали реальність. Якщо RAG у вас вже не на рівні демки, то головний біль зазвичай не в одній метриці, а в архітектурі: retrieval шумить, генерація додумує, пайплайн ламається на реальних сценаріях. | ||
|
Схожі матеріали:
| ||
| Всього коментарів: 0 | |
|
ЗАРАЗ ЧИТАЮТЬ
|
|
|
 |  |
 |  |
 |  |
 |  |
 |  |