Коли RAG отримує неправильний документ при схожості 0,89: близькість проти релевантності

Це знайома сцена у технології генерації з підтримкою пошуку: фрагменти інтегруються та індексуються, користувач ставить запитання, запит інтегрується, коефіцієнт косинусової схожості вибирає найкращі фрагменти, вони потрапляють у промпт, і ШІ відповідає. Найкращий фрагмент отримав оцінку 0,89, що свідчить про високу впевненість, проте відповідь все одно є неправильною.

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

У огляді технології RAG за серпень 2026 року, опублікованому в журналі Symmetry, це протиріччя названо одним із чотирьох структурних суперечностей у цій галузі та описано як геометрично-семантична неузгодженість. Важливо точно розуміти, що означає цей термін. Він не стверджує, що векторний пошук нефункціональний, і не є доведеною теоремою про можливості геометрії. Це спосіб позначення обмеження, яке емпірично спостерігається у найрізноманітніших схемах пошуку інформації.

Коротко про процес

Якщо видалити додаткові інструменти, RAG складається з двох етапів, об’єднаних разом.

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

Одне ключове припущення підтримує всю структуру: відстань у векторному просторі відображає семантичну корелюваність у мові. Тексти з схожим змістом повинні знаходитися близько один до одного, а тексти з різним змістом — далеко один від одного.

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

Схожість — це не корелюваність

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

Це спостереження є давнім. У статті 2020 року, яка представила метод DPR, наведена цікава пара цифр: щільний двоканальний енкодер для пошуку досяг точності 78,4 відсотка серед топ-20 відповідей у задачах Natural Questions, але знизився до 63,2 відсотка у задачах SQuAD, де звичайний алгоритм BM25 показав результат 68,8 відсотка. Автори пояснили це упередженням у розподілі даних під час навчання: запитання SQuAD містять надзвичайно багато спільних слів із відповідними уривками, що дозволяє лексичним алгоритмам пошуку працювати ефективніше, ніж щільні енкодери, навчені на більш широких даних.

Один експериментальний даний не може створити універсального закону. Проте він чітко демонструє, що семантична схожість та лексична точність можуть давати різні результати на одному й тому самому тесті з використанням одного й того самого інструменту пошуку. Огляд Symmetry узагальнює цю закономірність: механізм, налаштований на схоже значення, не обов’язково є налаштованим на саме те слово, яке має значення, і навпаки. Чи справедливо це для всіх ситуацій пошуку, краще розглядати як робочу гіпотезу. Вона відповідає багатьом досвідам практиків.

Де змінюється геометрія

Ще глибше лежить сама геометрична проблема. Методи інтенсивного пошуку перетворюють текст у неперервний векторний простір, майже завжди евклідовий, оскільки дотичний добуток та косинусова схожість передбачають саме його. Евклідовий простір добре підходить для визначення схожості двох об’єктів у певних вимірах. Однак він гірше справляється з принаймні трьома закономірностями, які постійно зустрічаються у реальному тексті.

• Ієрархія. Собака — це ссавець, а ссавець — тварина. У плоскому векторному просторі немає вбудованого поняття включення „є-ти“, а наближення дерева за допомогою відстаней між прямими лініями спричиняє ще більше спотворень у міру поглиблення ієрархії.
• Синонімія проти майже-синонімії. „Дешевий“ та „недорогий“ мають знаходитися близько один до одного. „Дешевий“ та „низькоякісний“ за логікою не повинні бути близькими, проте вони так часто зустрічаються в навчальному тексті, що їхні вектори можна розмістити ближче, ніж це виправдано лише значенням.
• Час. Генеральний директор компанії — це різна людина залежно від того, коли було написано речення. У статичному ембеддингу немає вісі для фактів, які закінчують свою дію, якщо тільки щось у верхніх рівнях не кодує їх.

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

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

Приклад із документацією

Уявіть собі набір документації до продукту та запитання: як скинути свій API-ключ?

Ретрівер повертає фрагмент під назвою «Як скинути пароль облікового запису» із коефіцієнтом косинусової схожості 0,87. Це високий показник, адже опції скидання, API-ключ та пароль знаходяться у близькій взаємодії у сфері автентифікації та управління обліковими записами. Фрагмент про заміну API-ключа розташований у іншому розділі, формулюється з менш загальними термінами та має показник 0,81.

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

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

Система пошуку ранжує кандидатів, але не виносить вердикту

Багато підходів RAG припускають, що результат номер 1 або номер k є відповіддю на питання про місцезнаходження інформації. Краще розглядати його як кандидата, який все ще має заслужити місце в запиті.

Ретрівер, який повертає сторінку з паролем у відповідь на запитання щодо API-клуча, не обов’язково зазнав невдачі у виконанні своєї роботи. Строго кажучи, його завдання — це недорогий перший етап: скоротити величезну кількість варіантів до кількох ймовірних кандидатів. Слабкою стороною є така конструкція, яка сприймає перший результат як істинний та більше його не перевіряє. Ланцюжок не обов’язково має складатися з запиту, ретрівера, вибору найкращого варіанту та LLM. Він може так само складатися з запиту, потім дешевого ретрівера з високим рівнем відтворення даних, потім набору кандидатів, потім повільнішого, але точнішого інструменту для переурочення рангів, потім найкращого кандидата та нарешті LLM.

Помилка отримання даних та помилка генерації пов’язані, але є окремими, і їхнє плутання робить ситуацію гіршою, ніж вона є насправді. Модель типу single-shot top-1 не може виправити ситуацію, якщо класифікація виявилась неправильною. Система, яка розглядає отримані дані як кандидатів на результат та передає справжнє оцінювання релевантності на наступний етап, має шанс помітити майже правильний варіант — документ, достатньо близький у векторному просторі, щоб здаватися переможцем, але настільки неправильний за змістом, щоб це мало значення.

Чому це важливо для практичного використання

Це не просто академічне формулювання. Різниця між близькістю та релевантністю призводить до конкретних та дорогих помилок.

• Тихе посилення галюцинацій. Штучний інтелект не може визначити, що певний фрагмент тексту пов’язаний із темою, але є неправильним. Він формулює логічну, впевнену відповідь на основі неправильного джерела, а впевнена, але хибна відповідь гірша за визнання відсутності знань майже для будь-якого подальшого використання.
• Зниження точності у ієрархічних корпусах даних. Як приклади з практики, так і література свідчать про те, що чим глибшою та більш структурованою є база знань — з вкладеними правилами, версійними специфікаціями чи організаційними схемами — тим складніше є векторне пошукове забезпечення. У рецензії пропонується формальний метод діагностики, який вимірює, як знижується точність зі збільшенням глибини ієрархії. Цей показник пропонується як корисний індикатор, а не як фіксована крива, і його краще вимірювати на конкретному корпусі даних, ніж припускати його значення заздалегідь.

Невидимий у наборі для оцінки доки не почнуться фінансові витрати. Стандартні тестові сценарії, такі як recall@k для загальних пар запитів, не враховують ієрархічні чи майже синонімічні відмінності так, як це робить справжній корпус даних. Спочатку проходить внутрішній тест, а потім у третій тиждень експлуатації з’являється версія проблеми з паролем та API-ключем.

Заходи мінімізації

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

Гібридний пошук – лексичний та густий. Запускайте BM25 та густий пошук паралельно та об’єднуйте їхні оцінки, наприклад, за допомогою методу взаємного рангування – поширеного та простого підходу. Це безпосередньо усуває проблему, пов’язану з лексичним перекриттям, не впливаючи на модель ембеддингів.

# Minimal hybrid retrieval sketch: dense + BM25 fused via RRF
from rank_bm25 import BM25Okapi
import numpy as np

def reciprocal_rank_fusion(dense_ranked_ids, bm25_ranked_ids, k=60):
    scores = {}
    for rank, doc_id in enumerate(dense_ranked_ids):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    for rank, doc_id in enumerate(bm25_ranked_ids):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: -x[1])# dense_ranked_ids  = [doc_id, ...] from your vector store's top-k search
# bm25_ranked_ids   = [doc_id, ...] from bm25.get_top_n(query_tokens, doc_ids, n=k)
fused = reciprocal_rank_fusion(dense_ranked_ids, bm25_ranked_ids)

Переранжування за допомогою крос-енкодера. Використовуйте щільне пошукове відтворення для створення недорогого набору кандидатів у кількості від 50 до 100 елементів із високим рівнем відтворення, а потім переранжуйте їх за допомогою крос-енкодера, який одночасно бере до уваги запит та документ. Це коштує дорожче за пару елементів, але значно ефективніше у випадках тематично близьких, але фактично неправильних даних, оскільки не залежить від одного фіксованого вектора для кожного тексту.

Переписування чи розкладання запиту. RQ-RAG є одним із прикладів: система навчається переформулювати нечіткі чи багатокомпонентні запити перед початком пошуку. Це допомагає, коли невідповідність виникає через недостатньо конкретизований запит, а не через складну структуру даних у корпусі.

Отримання інформації з урахуванням структури у стилі GraphRAG. Для справді ієрархічних чи взаємопов’язаних даних, таких як організаційні схеми, залежності між реченнями чи таксономії продуктів, необхідно чітко представити цю структуру у вигляді графа, замість того щоб примушувати її у вигляді плоского простору. Геометрію більше не намагаються подолати — її уникають.

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

Кожен з цих підходів усуває лише певний симптом, і жоден з них не вирішує основної суперечності, що варто відверто визнати.

Більш загальне дослідницьке питання

Якщо різні геометрії добре описують різні об’єкти, то логічним наступним кроком є запитання про те, чи міг би формат простору представлення адаптуватися до запиту чи до корпусу даних, а не бути зафіксованим заздалегідь.

У огляді Symmetry йдеться саме про це, формулюючи це як порушення симетрії: вибір евклідової, гіперболічної чи змішаної метрики означає вибір тієї семантичної симетрії, від якої потрібно відмовитися. Пропонованим напрямком є навчання гібридного геометричного простору, де система коригує свою структуру метрики відповідно до взаємозв’язків, які кодуються в кожній точці корпусу, і не обмежується однією глобальною геометрією для всього індексу. Це напрямок, запропонований у науковій статті-огляді, а не готова технологія з вже наявними тестами. Це гіпотеза, яку варто стежити, а не основа, на якій можна будувати сьогодні.

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

Що варто запам’ятати

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

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

Пов’язана література

• Коли панель керування зелена, а агент помиляється: відстеження стану — як збої агента ховаються у стані, який передається між коректними кроками, та що потрібно враховувати для відстеження, обмежень під час виконання, записів маршрутизації та оцінок.
• Що схема не може сказати вашому агенту: формат відкритих знань у BigQuery — експеримент з BigQuery та ADK, який демонструє, як пакети знань у форматі Markdown у Git стабілізували відповіді агента та усунули помилку GMV у розмірі 29%.