Карта полів RAG: від основних принципів до помилок у продакшені.

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

Ідея простою мовою

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

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

• Отримання: пошук у ваших документах та вибір кількох важливих уривків.
• Доповнення: розміщення цих уривків у запиті поруч із запитанням.
• Генерація: змусити модель написати відповідь, ґрунтуючись на отриманих даних.

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

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

Два потоки обробки, а не один

Структурний аспект створює труднощі майже для всіх. Система RAG — це не один потік обробки. Це два потоки, які ніколи не працюють одночасно.

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

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

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

Етапи, від основ до продакшну

Основи

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

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

Завантаження та розділення на частини

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

Візьмемо 60-сторінковий договір оренди, умови штрафування в якому залежать від визначення, наведеного на 40 сторінках раніше. Межі частин визначають, чи залишиться цей зв’язок цілим.

Ембеддинги та векторний пошук

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

Далі йде питання зберігання: що насправді робить векторна база даних, чому пошук методом brute-force не ефективний у великих масштабах та що доводиться жертвувати під час приблизного пошуку найближчих сусідів заради швидкості.

Цикл пошуку

Тут елементи об’єднуються. Вибір параметра top-k, тобто кількості фрагментів для отримання, є частиною цього процесу, і більше не означає краще. Фільтрація метаданих дозволяє пошуку охоплювати лише документи 2024 року або лише регіон Мумбаї. Також важливе правильне формування запиту, адже спосіб та порядок викладення отриманого контексту впливають на відповідь.

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

Оцінка

Майже всі пропускають цей етап, що пояснює, чому майже всі випускають несправні RAG. Проблему, яку неможливо виміряти, неможливо виправити. Якість можна оцінити за двома питаннями: чи був вилучений правильний матеріал, та чи залишався модель вірною йому? Кожен з цих аспектів має свої проблеми та вимагає окремого виправлення. У наборі інструментів є ідеальний набір тестових запитань від реальних користувачів, оцінка вилучення даних за точністю та повнотою, оцінка генерації відповідей за вірністю та релевантністю до запитання, а також ШІ, який виступає у ролі судді та визначає, де саме виникають проблеми.

Один з систем набрав 90% за ефективність вилучення даних та 55% за вірність відповідей. Його пошук працював добре, але відповіді все одно були неправильними.

Оновлення, кожне з яких пов’язане з певною проблемою

Краще вилучення даних

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

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

Краща індексація

Правильна обробка смуги A вимагає використання кількох технік. Пошук типу «батько-дитина» здійснює пошук у невеликих, точних фрагментах, але надає моделі більшу ділянку навколо них. Семантичне розділення на фрагменти відбувається там, де змінюється тема, а не за абсолютною кількістю символів. Анотації та ієрархічні індекси спочатку шукають анотації документів, а потім деталізують результати. Graph RAG зберігає взаємозв’язки між ентитетами, а не лише текст, тому може відповідати на запитання на кшталт «Які постачальники також є клієнтами?».

Гарним прикладом є запит щодо дотримання правил: для однієї відповіді потрібні правило, його поправка 2023 року та примітка про виняток — три документи.

Агентська поведінка

Після цього етапу RAG більше не є фіксованою схемою обробки та починає приймати рішення. Механізм маршрутизації спрямовує запит до відповідного індексу, до SQL-бази даних або зовсім не здійснює пошук. Механізм багатоетапного пошуку читає інформацію, виявляє прогалини та здійснює пошук знову. Технології Self-RAG та Corrective RAG дозволяють системі оцінити отриманий контекст та відкинути його, якщо він є нерелевантним, після чого звернутися до пошуку в Інтернеті або чесно визнати, що у неї немає відповіді.

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

Незвичайні документи

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

Проблеми виробництва

Усе ламається після демонстрації. Бюджети затримки показують, куди зникають мілісекунди. Важлива вартість за запит, а також кешування, яке справді допомагає. Індекс має залишатися актуальним, коли документи змінюються щогодини. Контроль доступу мусить гарантувати, що користувач А не зможе отримати фрагменти документів користувача Б — це поширена та реальна проблема. Отруєні документи можуть вводити шкідливі команди. Моніторинг та логування виявляють, коли якість тихо погіршується. Система, яка працювала чудово з 200 документами, може зламатися при 200 000.

Спочатку дізнайтеся про причини збоїв

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

Три принципи забезпечують чесність підходу:

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

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

Пов’язана література

• Практичні нотатки: перехід RAG у продакшн: проблеми на всьому шляху з реальних прикладів — Детальний огляд Практичних нотаток: перехід RAG у продакшн: проблеми на всьому шляху з реальних прикладів: контракти, перевірки та шаблони коду для команд, які впроваджують цю модель.
• Гібридний пошук у Postgres для асистента з охорони здоров’я: схема, чанкінг, RRF та оцінка — Створення шару пошуку для асистента з охорони здоров’я у Postgres: чанкінг з урахуванням структури, гібридний пошук pgvector з використанням RRF, бінарна квантація, пороги та оцінка.

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