Поза межами Top-K: пороги релевантності, гібридний пошук та переранжування в RAG

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

Наївний пайплайн та його приховані припущення

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

Частини відповідно до структури документа

Розгляньмо посібник для співробітників. Слабкий підхід розділяє його на довільні фрагменти по 1 000 символів, що призводить до розриву правил посередині та з’єднання кінця однієї теми з початком іншої. Сильніший підхід дотримується власної структури документа, створюючи частини на кшталт «Віддалена робота», «Безпека», «Відпустки та витрати».

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

Top-K повертає найближчі результати, а не релевантні

Кращі фрагменти тексту часто призводять до наступних хибних уявлень. Встановлення top_k = 5 часто тлумачиться як „дайте мені п’ять релевантних результатів“. Насправді це означає отримання п’яти найближчих результатів, незалежно від того, чи є серед них якісні. Типове розподілення балів для запитання про віддалену роботу може бути таким:

Remote Work       0.62
Paid Time Off     0.36
Security          0.30
Expenses          0.28
Other Policy      0.24

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

Запитання, на які немає відповідей, потребують окремого підходу

Особливо важливим випадком є запитання, на яке база знань просто не може відповісти, наприклад „Який розмір внеску за медичне страхування у компанії?“، якщо в посібнику про це зовсім не згадується. Метод Top-K все одно поверне п’ять результатів, і примітивний алгоритм буде використовувати найбільш схожий з них як доказ та робити припущення.

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

No sufficiently relevant context was found.

Додайте фільтр релевантності між процесом пошуку та моделлю

Обробка як слабких збігів, так і запитань, на які немає відповіді, вимагає додаткового етапу. Простий алгоритм виглядає так:

Vector Search
   ↓
Top-K
   ↓
LLM

Удосконалений алгоритм розглядає список Top-K як кандидатів та вставляє фільтр перед моделлю:

Vector Search
   ↓
Top-K candidates
   ↓
Relevance Filter
   ↓
LLM

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

score >= threshold
    → keep

А всі, хто нижче цього порогу, відкидаються:

score < threshold
    → discard

Якщо жоден кандидат не залишився, система повертає відповідь „жодного релевантного контексту“ замість того, щоб запускати модель із шумом даних.

Вибір порогу на основі показників

Поріг має визначатися на основі даних. Один невеликий експеримент із набором даних корпоративного посібника порівняв рівень відтворення відповідей на запитання, на які є відповідь („відомі“), з коефіцієнтом відхилення запитань, на які відповіді немає („невідомі“), для кількох значень:

| Threshold | Known-query recall | Unknown-query rejection |
| --------: | -----------------: | ----------------------: |
|      0.20 |               100% |                      0% |
|      0.25 |               100% |                      0% |
|      0.30 |               100% |                     50% |
|      0.35 |               100% |                     50% |
|      0.40 |               100% |                     50% |
|  **0.45** |           **100%** |                **100%** |
|      0.50 |               100% |                    100% |
|      0.55 |               100% |                    100% |

У цьому наборі даних 0.45 був першим порогом, який зберігав усі відомі запити, відхиляючи всі невідомі, що робило його найкращим варіантом серед перевірених значень. Однак це число не є універсальним. Оцінки схожості залежать від моделі ембеддингу, корпусу даних, формулювання запитів та налаштувань пошуку; різні моделі дають значення в дуже різних діапазонах. Крім того, темп зростання коефіцієнта відхилення у кроках по 50% свідчить про дуже малий набір невідомих запитів, тому для реальної реалізації потрібен більший набір позначених даних, перш ніж можна буде довіряти цьому порогу. Те, що можна перенести, — це метод: вимірювати поведінку пошуку для відомих та невідомих запитів та обирати поріг на основі даних, а не інтуїції.

Пошук та ранжування — це різні завдання

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

Процес пошуку оптимізований для виявлення максимальної кількості результатів у великому наборі даних, звужуючи, наприклад, 10 000 фрагментів до керованого набору кандидатів:

10,000 chunks
      ↓
retrieval
      ↓
50 candidates

Потім процес перепріоритизації більш ретельно оцінює цей невеликий набір, зазвичай за допомогою моделі, яка читає запит та кожного кандидата разом, залишаючи найсильніші варіанти:

50 candidates
      ↓
reranker
      ↓
5 strongest candidates

Тепер ланцюжок обробки виглядає так:

Question
   ↓
Embedding
   ↓
Vector / Hybrid Search
   ↓
Candidate Set
   ↓
Reranking
   ↓
Best Context
   ↓
LLM

Семантичний пошук пропускає точні терміни

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

INC-48271
ERR_CONNECTION_RESET
POL-104
AWS us-east-1
customer_12345

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

Гібридний метод пошуку поєднує обидва сигнали

Стандартним рішенням є гібридний пошук, який одночасно використовує семантичний та лексичний аналіз:

Semantic Search
+
Keyword / Lexical Search

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

Question
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
   Semantic Search      Keyword Search
          │                   │
          └─────────┬─────────┘
                    ↓
              Candidate Set

Система забезпечує визначення семантичної схожості для перефразованих запитів та точне зіставлення термінів для ідентифікаторів.

Поток обробки для продакшну

Коли всі етапи на місці, повний процес виглядає так:

Documents
    ↓
Semantic Chunking
    ↓
Embeddings
    ↓
Vector / Hybrid Retrieval
    ↓
Relevance Filtering
    ↓
Reranking
    ↓
LLM
    ↓
Answer + Sources
    ↓
Evaluation + Observability

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

Базова версія, яку варто створити спочатку

Хорошим способом ознайомитися з цими компромісами є поступове будування системи. Проста базова версія може поєднувати Python, FastAPI, ембеддинги OpenAI та LLM-моделі, а також Pinecone як сховище векторів, разом із:

• розділенням даних з урахуванням заголовків та метаданими частин
• семантичним пошуком із налаштовуваним параметром top_k
• фільтрацією за схожістю
• присвоєнням походження даних
• оцінкою ефективності пошуку

Його алгоритм роботи є наступним:

Question
   ↓
Embedding
   ↓
Pinecone Retrieval
   ↓
Top-K Candidates
   ↓
Similarity Threshold
   ↓
Relevant Context
   ↓
LLM
   ↓
Answer + Sources

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

Оцінка надійності системи

„Чи працює чат-бот?“ — це не корисне запитання. Розберіть його на параметри, які можна виміряти:

• Якість пошуку: чи була отримана взагалі правильна інформація?
• Якість ранжування: чи опинився найкорисніший контекст близько до верху списку?
• Обґрунтованість: чи підтримується відповідь отриманим контекстом?
• Точність посилань: чи підтверджують цитовані джерела зроблені твердження?
• Обробка невідомих запитів: чи розпізнає система, коли відповідь відсутня у базі знань?

Затримка: скільки часу займає одночасне отримання та генерація інформації?

Витрати: скільки коштує кожен запит?

Мета змінюється з «чи може додаток відповідати на запитання?» на «чи можемо ми оцінити, чи є архітектура отримання даних надійною?»

Основні висновки

• RAG — це не просто надання LLM доступу до документів; ключовими є рішення про те, що отримувати, у що вірити, що передавати та коли відмовляти.
• top_k гарантує кількість результатів, а не їхню релевантність, тому необхідно фільтрувати кандидатів за порогом, налаштованим на основі власних даних.
• Гібридний пошук виявляє точні ідентифікатори, які стираються ембеддингами, а переранжування перетворює широкий набір кандидатів на точний контекст.
• Якість відповідей значною мірою визначається ще до того, як модель побачить будь-який контекст: кращий контекст призводить до кращих відповідей та більш надійних систем.
• Розглядайте систему RAG у продакшені як архітектурну проблему з вимірюваними етапами, а не як просту інтеграцію одного LLM.

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

• Гібридний метод пошуку RAG з використанням pgvector, BM25 та крос-енкодера для переупорядкування результатів — Дізнайтеся, чому чистий векторний пошук не дозволяє знаходити номери деталей та коди помилок, та як поєднати pgvector, BM25 та механізми переупорядкування в LangChain для точного пошуку за принципом RAG.
• Правильний вибір розміру LLM: маршрутизація, пошук та оцінка з урахуванням розміру моделі — Дізнайтеся, як обирати між невеликими та великими мовними моделями залежно від обсягу роботи, як вимірювати витрати на кожне успішне завдання, та як використовувати маршрутизацію, технології RAG, кешування та верифікацію на початковому етапі.
• Проектування інфраструктури RAG з основою в реальному часі: чанкінг, фільтрація та стрімінг — покроковий огляд основ RAG з основою в реальному часі: чанкінг з урахуванням структури, безпечне розділення на токени, трьохетапна фільтрація даних під час пошуку, збирання інформації з братських елементів, проектування запитів та стрімінг даних.