RAG простими словами: як зробити, щоб ШІ відповідав з ваших джерел

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

RAG (retrieval-augmented generation, «генерація з пошуком») розв'язує це прямолінійно: перед тим як відповідати, знайти потрібний фрагмент у ваших документах і дати його моделі разом із питанням.

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

Питання. Ваш запит перетворюється на вектор тим самим способом.

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

Відповідь. Знайдені фрагменти передаються моделі разом із питанням та інструкцією відповідати тільки на їх підставі. Модель формулює відповідь і посилається на джерела.

Останній крок — той, заради якого все й будувалося. Якщо у відповіді є посилання на конкретний пункт конкретного документа, її можна перевірити за секунди.

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

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

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

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

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

Пошук по фрагментах добре відповідає на питання виду «де сказано про X». Він погано працює там, де потрібен огляд усього масиву: «скільки в нас договорів із автопролонгацією» — це не пошук, а агрегація, і розв'язується вона запитом до структурованих даних, а не векторним пошуком.

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

Робочий підхід — вузько й на реальних питаннях:

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

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

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