Чому для Enterprise RAG потрібен гібридний пошук, а не лише вектори

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

Вступ

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

Documents
    │
Chunking
    │
Embedding Model
    │
Vector Database
    │
Top-K Retrieval
    │
Large Language Model

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

Чому векторний пошук став популярним

Механізми пошуку за ключовими словами зіставляють токени. Запит „Як можна скинути пароль?“ знаходить документи, що містять слова reset/password/account. Запит „Неможливо отримати доступ до облікового запису“ може зовсім пропустити документ про паролі, незважаючи на ідентичну мету. Ембеддинги переносять значення у векторний простір, тому парафрази все одно призводять до помилок. Для часто ставлених запитань та наративних документів це є проривом.

Де провалюються чисті вектори

Корпуси даних корпорацій переповнені номерами рахунків-фактур, ідентифікаторами співробітників, кодами помилок, SKU, ідентифікаторами контрактів, номерами політик та рядками версій. Ці рядки мають значення для користувачів, але є складними для обробки інтенсивними моделями.

Якщо мати запис на кшталт:

Invoice Number : INV-93842
Status         : Paid
Customer       : ABC Corporation

запит „Який статус рахунку-фактури INV-93842?“ часто знаходить посібники з бухгалтерського обліку замість самої фактури, оскільки ембеддинги надають більше значення поняттям „рахунок-фактура/оплата“ ніж точному ідентифікатору.

Ще більше способів провалу

Пошук помилок у базі даних здійснюється за:

ORA-12514

може повертати загальні посібники з підключення замість сторінки ORA-12514.

Запити щодо продуктів, наприклад:

RTX-9000 Switch

можуть призводити до отримання оглядів мереж замість інструкції до RTX-9000.

Питання щодо версій, наприклад:

Version 4.3.12

часто повертають загальні примітки до випуску, а не конкретно 4.3.12.

Запити у сфері охорони здоров’я, наприклад:

Patient ID: P-482731

можуть повертати документи з процедурами реєстрації замість запису про пацієнта.

Коли важливі точні ідентифікатори, сама семантична схожість втрачає надійність.

Чому ембеддинги тут не справляються

Моделі вчаться розрізняти «лікар↔фахівець» та «автомобіль↔машина». Тексти на кшталт:

INV-93842

або

RTX-9000

містять мало семантичного змісту. Заміна:

INV-93842

на

INV-93843

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

Розділення пошуку для підприємств

Семантична інформація (політика залишення, процес подання заявок, скидання пароля) — тут ембеддинги є найкращим варіантом. Точна інформація (ID, коди, SKU, версії) — тут краще використовувати ключові слова чи алгоритм BM25.

Використання лише однієї стратегії означає відмінні результати в одному аспекті та труднощі в іншому. Гібридний пошук створений для покриття обох аспектів.

Що таке гібридний пошук

Замість використання лише BM25 або ембеддингів використовуються обидва підходи та їх поєднання:

User Query
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
 Keyword Search (BM25)           Vector Search
        │                                 │
        └──────────────┬──────────────────┘
                       ▼
              Merge & Score Fusion
                       ▼
                 Cross-Encoder Re-ranker
                       ▼
                Top Relevant Context
                       ▼
                 Large Language Model

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

Чому гібридний підхід кращий

Для запиту «Чому рахунок-фактура INV-93842 все ще чекає на схвалення?» гібридний підхід може знаходити точний ідентифікатор за допомогою ключових слів, отримувати відповідні документи робочого процесу за допомогою векторів та переурядковувати результати, щоб запис рахунка-фактури опинявся на першому місці, при цьому документи процесу залишалися доступними. Кожен метод виконує те, у чому найкращий.

Остаточні міркування

Бази даних на основі векторів залишаються фундаментальними. Вони не є повною заміною класичних систем пошуку інформації. Корпоративні знання поєднують прозу, коди та записи. Гібридний підхід до пошуку враховує саме цю суміш.

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

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

Створення гібридної системи без зайвих зусиль

Почніть із використання BM25 (або еквівалентного лексичного пошуку) разом із існуючим векторним індексом — багато векторних баз даних вже пропонують гібридні API. Забезпечте сумісність ідентифікаторів блоків даних, щоб фузія була простою. Спочатку використовуйте метод фузії на основі взаємного рангу, перш ніж тренувати модель для повторної класифікації; цей підхід є дешевим та часто „достатньо хорошим“, щоб довести, що різниця у продуктивності при пошуку за ідентифікаторами зменшується.

Створіть набір для оцінки з двома групами запитів: запити на перефразування (семантичні) та запити на ідентифікацію (точні). Оцінюйте показник recall@k окремо. Використовуйте гібридний підхід лише тоді, коли показники обох груп покращуються або принаймні одна з них покращується без погіршення іншої. Слідкуйте за затримкою: паралельна робота двох механізмів пошуку зазвичай є прийнятною; послідовна переорієнтація великих наборів кандидатів — ні.

Стратегія членування тексту все ще має значення. Ідентифікатори, які знаходяться в великих частинах тексту, послаблюють як показники BM25, так і щільні оцінки. Віддавайте перевагу межам частин, які зберігають заголовки рахунків-фактур, назви кодів помилок та рядки з SKU без змін. Фільтри метаданих (лінійка продукції, локалізація, тип документа) ще більше зменшують кількість хибних результатів перед об’єднанням даних.

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

Чек-лист реалізації

1. Перегляньте запити до інвентарю з журналів виробництва; позначте, які потребують точного збігу, а які — парафразування.
2. Створіть лексичний пошук на тому самому корпусі даних та з тими ж ідентифікаторами блоків, що й векторний індекс.
3. Об’єднайте його з RRF; фіксуйте джерела внеску для кожного знахідки.
4. Виміряйте показник recall@k для обох груп даних; скоригуйте ваги.
5. Лише після цього розгляньте можливість використання навченого ранжеру, якщо це дозволяє бюджет на затримку.
6. Зберігайте поля ідентифікаторів у метаданих для можливих жорстких фільтрів, коли інтерфейс вже знає номер рахунку чи SKU.

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