Перейти до вмісту

Генерація з доповненням через пошук

Матеріал з Вікіпедії — вільної енциклопедії.

Генерація з доповненням через пошук (Retrieval-Augmented Generation, RAG) — це техніка, що поєднує пошук інформації з її генерацією для створення більш точних і контекстуально релевантних відповідей.

Генерація з доповненою вибіркою інформації надає генеративним моделям штучного інтелекту можливості пошуку інформації.[1] Вона змінює взаємодію з великою мовною моделлю (LLM) так, щоб модель відповідала на запити користувачів, спираючись на визначений набір документів, використовуючи цю інформацію для доповнення даних, отриманих із її власного великого статичного набору навчальних даних. Це дозволяє LLM використовувати інформацію, яка є специфічною для певної галузі, або актуальнішу інформацію.[2] Застосування включають надання чат-ботам доступу до внутрішніх даних компанії або надання фактів лише з авторитетних джерел.[3]

Процес

[ред. | ред. код]

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

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

Індексація

[ред. | ред. код]

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

Огляд процесу RAG: поєднання зовнішніх документів і введення користувача у запит до великої мовної моделі (LLM) для отримання індивідуалізованого результату.

Пошук

[ред. | ред. код]

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

Доповнення

[ред. | ред. код]

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

Генерація

[ред. | ред. код]

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

Покращення

[ред. | ред. код]

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

Кодувальник

[ред. | ред. код]

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

  • Продуктивність можна покращити за допомогою швидших скалярних добутків, приблизного пошуку найближчих сусідів або пошуку центроїдів.
  • Точність можна покращити за допомогою пізніх взаємодій (Late Interactions).
  • Гібридні вектори: густі векторні представлення можна поєднувати з розрідженими векторами one-hot, щоб використовувати швидші розріджені скалярні добутки замість повільніших густих. Інші методи можуть поєднувати розріджені методи (BM25, SPLADE) із густими, такими як DRAGON.

Методи, орієнтовані на пошук (Retriever-centric methods)

[ред. | ред. код]

Ці методи спрямовані на покращення якості звернень із векторної бази даних:

  • попередньо навчити механізм пошуку (retriever) за допомогою завдання зворотного закриття (Inverse Cloze Task).
  • прогресивне доповнення даних. Метод Dragon вибирає складні негативні приклади для навчання механізму пошуку з використанням густих векторів.
  • під наглядом навчайте механізм пошуку (retriever) для заданого генератора. На основі запиту та бажаної відповіді отримайте топ-k векторів і передайте їх до генератора, щоб отримати оцінку заплутаності (perplexity) для правильної відповіді. Потім мінімізуйте KL-дивергенцію між спостережуваною ймовірністю отриманих векторів і ймовірностями мовної моделі (LM), щоб налаштувати механізм пошуку.
  • використовуйте повторне ранжування для навчання механізму пошуку.

Мовна модель

[ред. | ред. код]
Мовна модель Retro для RAG. Кожен блок Retro складається з шарів уваги (Attention), покрокової крос-уваги (Chunked Cross Attention) та прямого поширення (Feed Forward). Поля з чорним текстом показують змінювані дані, а синій текст вказує алгоритм, що виконує ці зміни.

Переробивши мовну модель з урахуванням механізму пошуку (retriever), можна створити мережу, яка у 25 разів менша за розміром, але має порівняльний рівень заплутаності (perplexity) з набагато більшими моделями. Оскільки ця модель (Retro) навчається з нуля, її реалізація вимагає високих витрат на навчання, яких уникала початкова схема RAG. Гіпотеза полягає в тому, що, надаючи знання про домен під час навчання, Retro потребує менше уваги до домену і може зосередити свої обмежені ресурси ваг лише на мовній семантиці. Тут показано перероблену мовну модель.

Було повідомлено, що Retro не є відтворюваним, тому були внесені зміни для забезпечення відтворюваності. Більш відтворювана версія називається Retro++ і включає RAG у контексті.

Розбиття на фрагменти (Chunking)

[ред. | ред. код]

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

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

Три типи стратегій розбиття на фрагменти:

  • Фіксована довжина з перекриттям. Це швидко та просто. Перекриття послідовних фрагментів допомагає зберігати семантичний контекст між фрагментами.
  • Фрагменти на основі синтаксису можуть розбивати документ на речення. Для цього можуть допомогти бібліотеки, такі як spaCy або NLTK.
  • Розбиття на фрагменти на основі формату файлу. Деякі типи файлів мають природні фрагменти, і їх найкраще враховувати. Наприклад, файли з кодом найкраще розбивати та векторизувати як цілі функції або класи. У файлах HTML слід залишати елементи <table> або закодовані в base64 зображення <img> недоторканими. Подібні підходи слід застосовувати і до pdf-файлів. Для цього методу можуть бути корисними бібліотеки, такі як Unstructured або Langchain.

Переваги та обмеження

[ред. | ред. код]

Переваги

[ред. | ред. код]
  • Підвищена точність інформації
  • Актуальність даних
  • Можливість посилання на джерела
  • Зменшення ризику "галюцинацій" моделі

Обмеження

[ред. | ред. код]
  • Технічна складність реалізації
  • Залежність від якості бази знань
  • Обчислювальна ресурсоємність

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

Список літератури

[ред. | ред. код]
  1. Sajid, Haziqa (3 січня 2024). Що таке доповнена пошукова генерація?. Unite.AI (укр.). Процитовано 27 листопада 2024.
  2. Gao, Yunfan; Xiong, Yun; Gao, Xinyu; Jia, Kangxiang; Pan, Jinliu; Bi, Yuxi; Dai, Yi; Sun, Jiawei; Wang, Meng; Wang, Haofen (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997 [cs.CL].
  3. What is RAG? - Retrieval-Augmented Generation AI Explained - AWS. Amazon Web Services, Inc. Процитовано 16 липня 2024.