Гібридний пошук у RAG: Векторний та повнотекстовий пошук

Багато з нас знайомі з патерном RAG (retrieval augmented generative AI) для створення агентних AI-додатків, таких як цифрові консьєржі, чат-боти для підтримки на передовій, та агенти, які можуть допомогти з основними проблемами самообслуговування.

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

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

Векторний пошук і встраивание

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

Вихідні дані кодуються в встраивании за допомогою спеціалізованої, прискореної GPU AI моделі. Ці встраивания представлені як вектори — список чисел, де кожне число представляє координату в багатовимірному просторі.
Ці встраивания зберігаються в таблиці бази даних, а потім зазвичай попередньо обчислюється спеціальний індекс для бази даних за допомогою пошукового движка, спеціалізованого на векторному пошуку, щоб прискорити процес.
Далі, під час виконання програми, “відстань” між двома концепціями може бути підрахована за допомогою різних математичних метрик — наприклад, косинусної схожості, евклідова відстань (L2 пошук) та інших.
Коли запускається пошук, результати повертають найближчі відповідні вектори, повернені до записів в підлеглих вихідних даних. Це можуть бути текстові фрагменти, (або, якщо використовується мультимодальна мовна модель) це можуть бути зображення, аудіозаписи, PDF-документи тощо. У цій статті ми залишимося на текстових фрагментах, щоб спростити пояснення.

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

Пошук: Ваш запит перетворюється на вектор для знаходження відповідних частин даних у базі даних.
Отримання: База даних витягує оригінальний текст, пов’язаний з цими відповідними векторами.
Доповнення: Цей текст вставляється в шаблон запиту (наприклад, “Використовуючи цю інформацію: [Текст джерела], відповідайте на запит: [Запит користувача]”).
Генерація: Цей комбінований текстовий запит надсилається до LLM.

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

Щоб отримати змістовні результати, вам потрібно використовувати ту ж модель встраиваний, яку ви використовували, коли створювали векторний індекс у базі даних. Це пов’язано з тим, що кожна модель створює свою унікальну “карту” значень (часто звана векторним простором). Використання різної моделі встраивань — це безшумний вбивця: програма працюватиме без помилок, але отримана інформація буде абсолютно нерелевантною.

Отже, це векторний пошук. Але, щоб система RAG була готова до виробництва, вам зазвичай потрібно перейти від “наївного” векторного пошуку до багатоступінчастого процесу отримання.

Гібридний пошук

Гібридний пошук виконує як векторний, так і повнотекстовий пошук паралельно та об’єднує їхні результати.

Векторний пошук (густий) добре знаходить “значення”. Якщо ви шукатимете “сонячна погода”, він може знайти “ясне синє небо”, навіть якщо слова не збігаються.
Повнотекстовий пошук (рідкісний) добре шукає “точні відповідності”. Він використовує алгоритм порівняння тексту, наприклад, BM25, щоб знаходити специфічні ID продуктів, абревіатури, або рідкі технічні терміни, які векторні моделі іноді не можуть відрізнити.

Ці два методи використовують різні системи оцінки (0.0 до 1.0 для векторів проти необмежених оцінок для BM25). Тому їх об’єднують за допомогою алгоритму, наприклад, рекіпрокальний ранг фьюжн (RRF). RRF враховує позицію документа в обох списках замість сирих оцінок, надаючи вищий фінальний ранг документам, які з’являються близько до верху обох.

Обчислення комбінованого рейтингу

Рекіпрокальний ранг фьюжн (RRF)

RRF ігнорує сирі оцінки повністю і лише відповідає на ранг (1-й, 2-й, 3-й тощо) документа в кожному списку. RRF використовує фактор згладжування — зазвичай його встановлюють на ціле число `60`. Цей стандартний фактор “згладжування” запобігає повністю переважному рангу в одному пошуку, який заглушує помірний ранг в іншому.

Фьюжн відносної оцінки (вагове середнє)

Цей метод зберігає сирі оцінки, але спочатку їх нормалізує.

Як BM25, так і векторні оцінки масштабуються до діапазону 0–1
Застосовується параметр зважування, щоб визначити, якому методу пошуку ви довіряєте більше.

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

Гібридний пошук у базі даних

У сучасних стеках RAG, об’єднання повнотекстового пошуку ключових слів (BM25) та векторного пошуку все більше переміщається в шар бази даних, щоб зменшити затримку та “клейовий код” — логіку посередництва, яка в іншому випадку може збільшити загальну складність управління рішенням.

Для PostgreSQL (pgvector і `full-text`) ви можете написати один SQL запит або збережену процедуру, яка запускає два підзапити — один для векторної відстані та один для відповідності ключовим словам, а потім застосувати формулу RRF до результатів.
Деякі бази даних, як OpenSearch, забезпечують вбудовані функції, які автоматично обробляють обчислення RRF.

Гібридний пошук PostgreSQL з RRF

Розгляньмо, як може виглядати гібридний пошук у PostgreSQL. Цей приклад припускає, що у вас є таблиця з назвою documents з колонкою content (для пошуку тексту) і колонкою embedding (для векторного пошуку).

WITH -- 1. Семантичний пошук: Ранг за векторною схожістюsemantic_search AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY embedding <=> '[0.1, -0.2, ...]'::vector) as rank FROM documents ORDER BY embedding <=> '[0.1, -0.2, ...]'::vector LIMIT 50),-- 2. Пошук за ключовими словами: Ранг за текстовою релевантністю (BM25 або ts_rank)keyword_search AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY ts_rank_cd(to_tsvector('english', content), query) DESC) as rank FROM documents, plainto_tsquery('english', 'ваші пошукові терміни') query WHERE to_tsvector('english', content) @@ query LIMIT 50),-- 3. Фьюжн: Комбінування рангів за допомогою формули RRF: 1 / (rank + k)combined_results AS ( SELECT id, 1.0 / (60 + s.rank) as score FROM semantic_search s UNION ALL SELECT id, 1.0 / (60 + k.rank) as score FROM keyword_search k)-- 4. Остаточний вихід: Сума оцінок для елементів, знайдених у обох/будь-якому спискуSELECT d.id, d.content, SUM(c.score) as final_rrf_scoreFROM combined_results cJOIN documents d ON c.id = d.idGROUP BY d.id, d.contentORDER BY final_rrf_score DESC LIMIT 10;

Переваги виконання цього в збереженій процедурі всередині бази даних:

Продуктивність: Виконуючи фьюжн у базі даних, ви повертаєте тільки фінальні 10 рядків у вашу програму замість двох великих списків по 50.
Простота: Вам не потрібно писати логіку у вашому посередницькому програмному забезпеченні для “суміщення” ID з двох різних масивів.

Напевно, ви запитуєте про деякі незвичайні оператори і типи даних, використані в наведеному коді. Оператор <=> є оператором косинусної відстані pg_vector, що використовується для обчислення відстані між двома векторами. Символ [0.1, 0.2 … ] показує приклад, як представляється вектор. У свою чергу, @@ є оператором, використаним двигуном повнотекстового пошуку для перевірки відповідності між запитом на пошук та полем.

Повторне ранжування

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

Для повторного ранжування не потрібно кодувати дані в встраивания. Замість цього ви надсилаєте сирий текст запиту і сирий текст фрагментів результатів безпосередньо до моделі повторного ранжування.

Процес виглядає так:

Витяг: Ви виконуєте гібридний пошук і отримуєте відносно великий набір кандидатів (наприклад, топ 50–100 фрагментів).
Повторне ранжування: Ви надсилаєте запит користувача разом з цими найкращими кандидатами до моделі повторного ранжування. На відміну від векторних моделей, повторний ранжувальник дивиться на запит і документ разом, щоб побачити, наскільки добре вони фактично підходять.
Фінальний вибір: Ви берете лише топ 5–10 результатів з повторного ранжувальника і надсилаєте їх до LLM.

Як працює повторне ранжування

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

Вона бере єдиний комбінований вхідний рядок: [CLS] Запит [SEP] Фрагмент документа [SEP].
Оскільки вона бачить обидва разом, вона може виконувати “перехресну увагу” — фактично зважувати кожне слово в запиті проти кожного слова в документі одночасно.
Вона виробляє єдиний рахунок релевантності (звичайно дробове число між 0 і 1). Саме тому він такий точний, але й повільний; ви не можете заздалегідь обчислити ці оцінки, оскільки вони залежать від конкретного запиту.

Повторне ранжування в додатку

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

Ваше програмне забезпечення звертається до бази даних для отримання топ 50 “кандидатів” (через гібридний пошук), потім надсилає ці 50 сирих текстових фрагментів до моделі повторного ранжування.
Повторний ранжувальник повертає фінальні “найкращі” 5–10 фрагментів, які ваше програмне забезпечення потім передає до LLM.

Висновок

Отже, ми детально розглянули, як сучасні RAG архітектури здійснюють гібридний пошук та повторне ранжування для отримання найкращих результатів (і досвіду користувачів):

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

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

Повний виробничий потік RAG зазвичай виглядає так:

Завдання	Розташування	Чому?
Обчислення встраивань	Посередництво / API	Потребує моделі, що вимагає GPU для обчислення встраивань
Зберігання встраивань	База даних	Встраивания повинні зберігатися для подальшого пошуку та отримання
Векторні/ключові словосполучення	База даних	Потребує прямого доступу до індексів бази даних.
Гібридний пошук	Збережена процедура в базі даних	Швидше ранжувати на місці, ніж витягувати два великих списки до програми.
Повторне ранжування	Посередництво / API	Вимагає GPU важкої моделі Cross-Encoder.
Генерація LLM	Посередництво / API	Остаточний етап, що використовує отриманий контекст.