Генеративний штучний інтелект: дослідження RAG та особливості

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обчислення комбінованої оцінки

Зворотна рангова фузія (RRF)

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

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

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

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

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

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

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

Для PostgreSQL (pgvector і повнотекстовий) ви можете написати один 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 DESCLIMIT 10;

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

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

Можливо, вам цікаво, як працюють деякі незвичні оператори та типи даних, що використовуються в наведеному вище коді. Оператор <=> є оператором косинусної відстані 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-кодувальника.
Генерація LLM	Міжпрограмне забезпечення / API	Остаточний крок, що використовує отриманий контекст.

Дізнайтеся більше про рішення OpenSearch та PostgreSQL, або зв’яжіться з нами.

Подальше читання

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