Пошук та оцінка для RAG: чому для отримання даних потрібен окремий етап переурочування
RAG потребує пошуку та оцінки: ембеддинги знаходять кандидатів, але не можуть оцінити їхню релевантність. Двоступенева схема з використанням RRF, крос-енкодерів, ColBERT та моделей LLM для переоцінки рангу.
Багато команд стикаються з однаковими проблемами під час використання генерації з підтримкою пошуку даних. На дошці оголошень система виглядає простою: вставляється запит, порівнюються вектори, найкращі результати передаються моделі, і отримується відповідь. Однак у реальних умовах швидко з’являються проблеми. Пропускаються релевантні документи, потрапляють нерелевантні фрагменти, навіть незначна зміна формулювання запиту змінює відповідь, а галюцинації залишаються навіть тоді, коли пошук, здається, пройшов успішно.
Зазвичай як рішення пропонують використати кращу модель ембеддингу, підвищити розмір векторів чи налаштувати параметри top-k та розмір фрагментів. Ці заходи є розумними, але вони впливають не на ту частину системи. Справжня проблема полягає в архітектурі. Традиційний підхід змушує один механізм — порівняння схожості ембеддингів — виконувати дві зовсім різні функції: знаходити кандидатів та вирішувати, які з них є значущими.
Рішенням є розділення завдань. Це можна описати як пошук шаблонів та оцінку: двоступенева схема, де генерація кандидатів та оцінка їхньої релевантності є окремими інженерними завданнями, які вирішуються за допомогою окремих інструментів.
Чому сама лише схожість недостатня
Naive RAG перетворює запит на ембеддинг, бере K найближчих фрагментів з бази знань, розміщує їх поруч із запитом та дозволяє моделі дати відповідь. Неявною передумовою є те, що близькість еквівалентна релевантності, тому список K найкращих результатів приймається без жодної перевірки. У цьому підході є чотири проблеми.
Схоже не означає того самого, що й релевантне. Відстань вбудовування є приблизним показником тематичної близькості. Два уривки можуть знаходитися поруч, проте жоден з них не може відповісти на запитання, поставлене іншим. Текст про рекомендації щодо лікування гіпертонії та текст про методологію тестування кардіоваскулярних препаратів можуть розташовуватися поруч, проте лише перший може допомогти людині, яка вирішує, як лікувати пацієнта.
Порядок є слабким. Векторна відстань є евристикою, а не функцією ранжування, створеною так, щоб положення відображало релевантність. Різниця між третім та сьомим результатом у ранжуванні за косинусом часто є шумом.
Контекст розривається. Розділення на частини порушує зв’язки, ієрархію та причинно-наслідкові зв’язки. Частина, що описує дозування, може опинитися окремо від частини, що описує протипоказання, і жодна з них сама по собі не є повноцінною.
Результати є нестабільними. Невеликі зміни формулювань можуть змінити набір елементів типу top-K. Запит про побічні ефекти метформіну порівняно з негативними реакціями на нього може дати інші кандидати, і кінцева відповідь може змінюватися разом з ними. Це є дефектом надійності, а не деталлю налаштувань.
Коротко кажучи, пошук надає кандидатів. Він не гарантує правильності.
Двоетапний підхід
Замість того, щоб одна система знаходила та оцінювала, створіть два етапи, кожен з яких налаштований під власну мету.
Перший етап – пошук, передбачає використання якомога ширшого діапазону пошуку. Він знаходить від 50 до 200 кандидатів, що значно більше, ніж можна було б показати моделі, адже тут метою є виявлення всіх можливих варіантів. Правильні документи просто мають знаходитися в цьому наборі, навіть якщо він містить багато шуму.
Друга стадія, судді, передбачає набагато суворішу перевірку. Це зазвичай крос-енкодер-реранкер, який читає запит та кожен з кандидатів разом та обчислює справжній рейтинг релевантності. Він звужує список до п’яти–десяти уривків із високою ступенем впевненості. Лише тоді зібраний контекст надсилається до мовної моделі.
Що насправді вносять ембеддинги
Неправильне розуміння ролі ембеддингів є причиною того, чому команди занадто сильно на них покладаються. Уявіть бібліотекаря, який не читає кожну книгу, але позначає кожну кількома ключовими темами. Коли з’являється запит, бібліотекар перетворює його на схожі теги та дістає книги, чиї теги найкраще збігаються. Це швидко та зазвичай дозволяє знайти щось корисне, але це ґрунтується на поверхневих темах, а не на глибокому розумінні, тому деякі книги є пов’язаними, але не є саме тим, що вам потрібно.
Наслідок: ваша модель ембеддингів визначає поведінку пошуку. Вона вирішує, що буде знайдено, а що пропущено. Вона не визначає, що є правильним, і це є завданням етапу оцінювача.
Тому вибір моделі ембеддингів — це рішення щодо рівня відтворення даних. Ви обираєте „об’єктив“, через який перший етап бачить корпус даних. Враховуйте такі показники, як MTEB та BEIR, охоплення мов, розмір моделі у порівнянні з вашим обладнанням, розмір векторів, максимальну довжину вхідних даних та швидкість обробки. Усі ці фактори стосуються рівня відтворення даних.
Варіанти оцінювача та ситуації, коли кожен з них підходить
Оцінювач — це роль у архітектурі. Її можуть виконувати кілька реалізацій, які мають різні компроміси щодо точності, затримки, складності та витрат.
Фузія взаємних рангів
RRF зовсім не оцінює релевантності. Він об’єднує ранжовані списки з кількох джерел, наприклад пошук за ключовими словами та семантичний пошук, у один порядок. Для кожного документа він додає значення 1 / (k + ранг) у всіх списках, де k — це константа, зазвичай 60, яка пом’якшує домінування документів з найвищими рангами. Документи, які мають високі ранги в кількох списках, піднімаються вище.
Цей метод є швидким, детерміністичним, не вимагає інтерпретації моделі та майже не створює затримок. Оскільки він використовує позиції в ранжуванні, а не сухі оцінки, він уникає неузгодженості між оцінками BM25 та косинусовими схожостями, тому нормалізація не потрібна.
Його обмеження полягає у тому, що він розпізнає лише згоду. Якщо кілька пошукових систем вважають документ важливим, RRF припускає, що він, ймовірно, такий і є. Це розумна евристика, але все одно евристика. Він не може знайти релевантний документ, який пропустили всі пошукові системи, і не може відокремити документ, тематично пов’язаний із запитанням, від документа, який на нього відповідає.
Використовуйте його для гібридного пошуку, коли вам потрібен простий спосіб об’єднання списків. Він належить до етапу пошуку як засіб покращення кандидатів, але не замінює оцінювача.
Крос-кодери
Крос-енкодер передає запит та один з кандидатів через модель у вигляді єдиної послідовності та повертає оцінку релевантності. Бі-енкодери інкорпорують запит та документ окремо один від одного, тоді як тут кожен токен запиту може взаємодіяти з кожним токеном тексту. Таким чином модель може аналізувати, як певні фрази у запиті пов’язані з певними фразами в тексті. Типовими прикладами є моделі Sentence Transformers, такі як cross-encoder/ms-marco-MiniLM-L-12-v2, сервіси для переранкінгу та крос-енкодери, налаштовані на медичні, юридичні чи наукові дані.
Їхня сильна сторона — точність. На тестах ранкінгу вони зазвичай перевершують інші підходи, оскільки вони враховують дрібні взаємодії, яких не може досягти метод схожості інкорпорації. Це найближче до перевірки того, чи дійсно документ відповідає на запит, без необхідності використання повноцінного LLM.
Вартість полягає у окремому обробленні кожної пари запиту та кандидата. Набір з 100 документів означає 100 запусків моделі на кожен запит, тож затримка зростає лінійно з розміром набору, а більші моделі погіршують ситуацію.
Вони є стандартними інструментами оцінки там, де першочергово важлива якість відповіді: охорона здоров’я, право, дотримання норм, фінансовий аналіз — будь-де, де неправильне пошукове результат може мати наслідки. Якщо бюджет на затримку дозволяє приблизно від 50 до 200 мілісекунд на переорієнтацію рейтингу, що є можливим для більшості нереальних часових систем, почніть саме з цього.
ColBERT та пізня взаємодія
ColBERT, скорочення від contextualized late interaction over BERT, знаходиться між бі-енкодерами та крос-енкодерами. Він незалежно кодує запит та документ у вектори для кожного токена, а потім оцінює їх шляхом порівняння токенів запиту з токенами документа. Оскільки вектори документів можна попередньо обчислити, його використання під час обробки запиту є значно дешевшим, ніж у крос-енкодера, водночас він зберігає більше деталей, ніж один об’єднаний вектор. Недоліком є більший розмір індексу, адже кожному токену потрібен власний вектор. Цей підхід підходить для систем, які потребують кращої класифікації, ніж звичайні ембеддинги, та мають вищу пропускну здатність, ніж можуть забезпечити крос-енкодери.
LLM як суддя
Загальна модель мови може безпосередньо оцінювати кандидатів. Вона враховує складні, багатоетапні аспекти релевантності, наприклад, розуміє, що документ про взаємодію ліків стосується питання про безпеку лікування, навіть якщо їхній словниковий запас не перетинається. Вона також може дотримуватися чітких критеріїв релевантності, вказаних у запиті, що робить її придатною для розуміння значень релевантності в конкретних галузях.
Це також, безумовно, найдорожчий варіант. Одна операція переоцінки може зайняти від однієї до п’яти секунд та коштувати в десять–сто разів більше, ніж один проходження через крос-кодер. Оцінки можуть варіюватися між різними виконаннями, а моделі демонструють упередженість щодо позицій, віддаючи перевагу документам, наведеним раніше у запиті. Моделі, що працюють на сервері, створюють додаткову зовнішню залежність.
Це має сенс у двох ситуаціях: офлайн-режимі або пакетних завданнях, де затримка не має значення, наприклад під час створення ретельно підібраних баз знань, оцінки процесу пошуку під час розробки чи генерації даних для навчання спеціалізованих алгоритмів ранжування; а також у інструментах з високою важливістю та невеликим обсягом роботи, де цінність правильної відповіді виправдовує витрати на обробку кожного запиту, наприклад у експертних медичних чи юридичних дослідженнях.
Вибір моделей для кожної стадії
Розуміння закономірностей — це одне, а вибір моделей — інше. Архітектура пропонує два варіанти вибору, кожен з яких залежить від завдання.
Почніть з завдання
Відповіді на клінічні запитання, аналіз документів та дотримання регуляторних вимог вимагають різних підходів. Контроль якості вимагає високої точності при невеликій кількості даних. Аналіз документів цінує широту та різноманітність інформації. Дотримання вимог вимагає детермінованого та перевірюваного пошуку з мінімальною кількістю хибно негативних результатів. Профіль завдання впливає на кожен подальший вибір.
Модель вбудовування визначає верхню межу точності пошуку
Вона визначає, що система може знайти до того, як втрутиться людина-експерт. Релевантний документ, який ніколи не потрапляє до списку кандидатів, не може бути знайдений жодним іншим алгоритмом ранжування. Порівнюйте кандидатів за цими критеріями:
- Бенчмарки. Дивіться результати MTEB та BEIR для типу завдання, найближчого до вашого, наприклад, пошуку уривків чи відповідей на запитання, а не лише загальний бал.
Принцип: налаштовуйте модель вбудовування з урахуванням охоплення та швидкості, а не точності. Точність — це справа оцінювача.
Реранкер визначає остаточну точність
Це останній фільтр перед LLM, тож його якість безпосередньо впливає на точність відповідей. Оцінюйте його за:
- Точність ранжування. Основний показник. Перевіряйте nDCG, MRR та MAP на тестах, схожих на вашу сферу діяльності. Навіть невеликі покращення тут можуть суттєво зменшити кількість хибних результатів.
- Затримка. Реранкер виконується один раз для кожного кандидата, тож якщо кількість кандидатів становить 100, це означає 100 операцій. Час на одну операцію та загальний час є важливими обмеженнями у продакшені.
- Узгодженість доменів. Загальні інструменти для переранкінгу добре справляються з широким пошуком, але домени з високими вимогами часто отримують перевагу від інструментів, налаштованих на основі даних про релевантність домену. Інструмент для переранкінгу, навчений на медичній літературі, краще оцінюватиме клінічні запити, ніж загальний інструмент, навіть якщо останній має вищі результати на загальних тестах.
- Пропускна здатність. Під великим трафіком інструмент для переранкінгу може стати вузьким місцем. Варто розглянути можливість групування запитів, паралелізм моделей, а також те, чи може легша версія — стиснутий крос-енкодер чи модель з пізньою взаємодією — забезпечити прийнятну точність при значно вищій пропускній здатності.
Інвестуйте в обидва підходи
Найкращі системи не обирають між хорошим інструментом для генерації ембеддингів та хорошим інструментом для переранкінгу, оскільки ці два інструменти виконують незалежні один від одного завдання. Сильний інструмент для генерації ембеддингів у поєднанні з слабким інструментом для переранкінгу забезпечує високий рівень відтворення результатів, але призводить до шумних кінцевих результатів. Слабкий інструмент для генерації ембеддингів у поєднанні з сильним інструментом для переранкінгу дає точне ранжування серед неповного набору кандидатів. Жоден з цих підходів сам по собі недостатній.
Секрет ефективності — це швидкий пошук із високим рівнем відтворення результатів у поєднанні з сильним та точним механізмом оцінки. Підберіть інструмент для генерації ембеддингів відповідно до ваших потреб у відтворенні результатів, а інструмент для переранкінгу — відповідно до потреб у точності, а потім налаштуйте розмір набору кандидатів між етапами, щоб знайти баланс між охопленням та затримкою переранкінгу.
Приклад з реального застосування
Уявімо, що до клінічного асистента звертаються з питанням, чи може пацієнт, який приймає певний препарат від діабету, безпечно приймати ще один препарат. На етапі пошуку одночасно виконується запит на ключові слова та векторний запит, після чого вони об’єднуються за допомогою методу RRF, і залишається 100 кандидатів. Серед них — монографія про кожен препарат, стаття про проект дослідження, загальний брошура з питань харчування та кілька таблиць про взаємодію препаратів. Лише за критерієм схожості стаття про дослідження та брошура могли б опинитися вище за таблицю взаємодій, оскільки їхній словниковий запас ближчий до запитання.
На етапі судді читається запитання біля кожного зі ста уривків, і оцінюється, чи справді уривок стосується комбінованого використання. Таблиця взаємодії та відповідний параграф з протипоказаннями піднімаються на вершину, листок опускається, і модель отримує шість уривків замість шумних десяти. Те саме корпус, ті самі ембеддинги, різний результат — тому що другий компонент прийняв рішення, яке перший ніколи не був створений для прийняття.
Налаштування передачі даних між етапами
Розмір набору кандидатів є ключовим параметром. Якщо він занадто малий, суддя ніколи не бачить правильного уривка, що обмежує ефективність системи в цілому. Якщо ж він занадто великий, затримка та витрати на переранжування зростають без значного покращення результатів. Практичний спосіб налаштування — це зафіксувати на позначеному зразку ранг, у якому правильний уривок з’являється на першому етапі, а потім обрати набір, який охоплює майже всі такі уривки. Якщо правильний уривок регулярно знаходиться після 150-го рангу, проблема, ймовірно, полягає на етапі пошуку — потрібен кращий алгоритм вбудовування даних, гібридний метод пошуку чи покращена структуризація даних, а не більший алгоритм переранжування.
Також допомагають інші звички:
- Оцінюйте обидва етапи окремо. Вимірюйте рівень відтворення даних у наборі кандидатів перед оцінкою та точність кінцевого списку після неї, щоб можна було визначити проблемну стадію.
- Зберігайте результати переранжування для часто виконуваних запитів, якщо корпус даних змінюється повільно.
Розглядайте це як гіпотезу, яку потрібно перевірити на власних даних, а не як гарантію, адже ефективність залежить від галузі та від того, наскільки слабким був початковий рівень.
Висновок
Надійний RAG досягається не шляхом пошуку кращого ембеддингу. Він полягає у розділенні пошуку та оцінки: один етап максимізує охоплення, а інший — точність.
Ця зміна спочатку є концептуальною, а вже потім технічною. Перестаньте розглядати результати типу top-K як остаточну відповідь — сприймайте їх як набір кандидатів. Перестаньте вважати схожість істиною — розглядайте її як гіпотезу, яку потрібно перевірити. Широко шукайте, а потім точно оцінюйте.
Пов’язана література
- Розширені можливості RAG у Milvus: гібридний пошук, HyDE, переписування запитів та їх переранжування — Крок за кроком створення потоку обробки даних RAG у Milvus: щільні та BM25-вектори, гібридний пошук RRF, фільтри метаданих, переписування запитів, HyDE, розкладання даних та переранжування за допомогою крос-кодерів.
- Практичні нотатки: Штучним інтелект-агентам більше не потрібен векторний пошук: всередині системи Agentic — Детальний огляд практичних нотаток про те, що штучним інтелект-агентам більше не потрібен векторний пошук, а також інформація про заміну технології RAG у 2026 році: контракти, перевірки та готовий код.