Сім архітектур RAG, що виходять за межі наївного підходу, та ситуації, коли кожна з них підходить.

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

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

Чому існує RAG

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

Основний алгоритм роботи наведено нижче.

Коли користувач ставить запитання, система виконує чотири кроки:

1. Шукає у зовнішній базі знань відповідний матеріал
2. Витягує найбільш відповідні фрагменти
3. Додає ці фрагменти до запиту поруч із питанням
4. Надсилає все це до LLM, який формулює відповідь на основі цього контексту

Коротко: запит, пошук, отримання даних, додавання контексту, LLM, відповідь. Цей підхід добре працює з невеликими, структурованими наборами документів. Реальні дані рідко поводяться так, як очікується, і зазвичай виникають п’ять слабких місць:

• Фрагменти втрачають контекст. Уривок про зростання доходів на 3% не вказує, про яку компанію чи квартал йдеться.
• Інформація може бути пропущена. Таблиці, діаграми та відскановані сторінки часто не залишаються під час пошуку в текстовому форматі.
• Перший пошук може бути неправильним, а базові системи RAG не намагаються зробити ще один пошук.
• Попередні розмови зникають. Без пам’яті кожна сесія починається з нуля.
• Факти залишаються розрізненими. Коли інформація розкидана по різних документах, її може знадобитися поєднати, щоб відповідь мала сенс.

Це не п’ять випадкових проблем. Вони пояснюють, чому існують різні архітектури, причому кожна з них спрямована на конкретну проблему в базовому процесі обробки даних.

1. Примітки до контекстуальних фрагментів

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

У самому фрагменті йдеться про те, що дохід зріс на 3% порівняно з попереднім кварталом, проте не вказано ні компанію, ні рік. З приміткою стає зрозуміло, що це дані з звіту ACME Corp за другий квартал 2023 року, далі йде те саме речення.

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

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

2. Багатомодальний пошук

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

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

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

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

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

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

Візьмемо запит „error E0502 borrow checker“. Пошук, заснований на сенсі, знаходить документи на схожу тему навіть без точного формулювання, а пошук точних слів знаходить саме рядок „E0502“, і об’єднаний результат поєднує обидва підходи.

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

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

4. Пошук у форматі графів та карт

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

Припустимо, хтось хоче дізнатися про основні теми всього, що було опубліковано цього року. Жодна окрема стаття не може на це відповісти. Якби організація була розділена на відділи, кожен з яких мав би односторінковий огляд своєї роботи, то прочитання лише цих сторінок дозволило б швидко отримати відповідь. Це і є карта. Більш розумна версія діє як асистент, який спочатку визначає, які відділи є релевантними для запитання, а не просто читає всі огляди.

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

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

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

5. Агентське, ітеративне пошукове забезпечення

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

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

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

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

6. Багатоагентний пошук

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

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

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

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

7. Пошук на основі пам’яті

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

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

Вибір

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

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