RAG-архітектура

Два конвеєри, а не одна функція

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

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

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

Виміряйте пошук, перш ніж судити відповідь

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

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

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

RAG, довгий контекст чи fine-tuning

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

Ці два підходи не суперники, і зрілі системи зазвичай мають обидва: налаштована модель, яка знає формат і тон, відповідає з фрагментів, знайдених під час запиту. Що не працює — це вчити фактів через fine-tuning. Навчання на наборі документів не створює таблиці пошуку: факти розмиваються у вагах, повертаються ледь зміненими, на них не можна послатися і їх не виправити без перенавчання. Кожен факт, який може знадобитися оновити, процитувати чи обмежити, належить пошуку.

Як це виявляється в реальній поставці

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

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

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

Де це вироджується

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

Коли це застосовувати

Пов’язані сторінки

• РозробкаОснови LLMВелика мовна модель (LLM) робить рівно одну річ: маючи наявний текст, вона оцінює кожен можливий наступний токен, а щось один із них обирає. Чат, виклики інструментів, міркування й агенти — усе це та сама операція, повторена багато разів. На цій сторінці — що таке токен, скільки насправді коштує контекстне вікно, чому модель вигадує факти з цілковитою впевненістю і які налаштування справді змінюють відповідь.
• РозробкаFine-tuningFine-tuning продовжує навчання моделі на ваших власних прикладах, тож поведінка, яку ви щоразу описуєте в промпті, стає для неї типовою. Він чудово вчить форми, тону й суджень і майже не годиться, щоб навчити фактів. На цій сторінці — де він стоїть серед дешевших варіантів, чим насправді різняться методи, чому набір даних і є всім проєктом, і який рахунок за супровід починається в день релізу.
• РозробкаAI-агентиAI-агент — це цикл, у якому модель вирішує, що робити далі: викликає інструмент, читає результат і вирішує знову, доки не визнає задачу виконаною. Це одне проєктне рішення — керування, перенесене з вашого коду в модель, — купує здатність робити задачі, яких не можна описати заздалегідь, і коштує детермінованості, передбачуваного рахунку й обмеженого радіуса ураження. На цій сторінці — сам цикл, режими збою, які трапляються лише в ньому, і як зрозуміти, чи потрібен вам агент узагалі.