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

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

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

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

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

1. Дані кодуються у вектори за допомогою спеціалізованої моделі ШІ, прискореної за допомогою ГПУ. Ці вектори представлені як числові списки, де кожне число представляє координату у високовимірному просторі.
2. Ці вектори зберігаються в таблиці бази даних, та зазвичай попередньо обчислюється спеціальний індекс бази даних за допомогою пошукової системи, спеціалізованої на векторних пошуках, для прискорення процесу.
3. Потім, під час виконання запиту, обчислюється “відстань” між двома концепціями за допомогою одного з різних математичних метрик – наприклад, косинусної схожості, евклідичної відстані (L2 пошук) та ін.
4. Коли виконується пошук, повертаються результати найближчих відповідних векторів, які потім зв’язуються з записями в первинних даних. Це можуть бути текстові частини, (або в разі використання мультимодальної мовної моделі) це можуть бути зображення, аудіозаписи, PDF документи тощо. У цій статті ми будемо дотримуватись текстових частин для спрощення.

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

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

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

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

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

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

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

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

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

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

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

Взаємний ранг об’єднання (RRF)

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

Фузія відносних оцінок (вагова середня)

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

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

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

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

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

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

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

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

З ГІБРИДНИМ ПОШУКОМ У PostgreSQL: --- 1. Семантичний Пошук: Ранжування за подібністю векторівsemantіc_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', 'your search terms') 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_score FROM combined_results c JOIN documents d ON c.id = d.id GROUP BY d.id, d.content ORDER BY final_rrf_score DESC LIMIT 10;

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

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

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

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

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

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

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

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

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

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

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

Повторне ранжування в середній програмі додатка

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

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

Підсумок

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

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

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

Повний виробничий процес RAG зазвичай виглядає наступним чином:

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

Дізнайтеся більше про рішення OpenSearch та PostgreSQL від Canonical.

Додаткова інформація

Досліджуйте наш “Посібник з RAG” для створення та розгортання робочого процесу RAG у публічних хмарах за допомогою інструментів з відкритим вихідним кодом.