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

Чеклист побудови RAG

Спершу весь чеклист, бо саме його варто мати перед очима на проєктному рев’ю, а не після інциденту. Він пронумерований, щоб на рядок можна було послатися: «ми не зробили 4.1» — це те, що хтось може запланувати, на відміну від «над правами доступу треба подумати». Більшість прототипів RAG доходять до демо, зробивши групи 2 і 5 і не зробивши нічого з 1, 4.1, 6 чи 7, — і кожен із цих пропусків виринає згодом як клас збоїв, а не як окремий баг.

1. 1.Джерела й межі

   1. 1.1Корпус — це явний список джерел, а не «все, до чого дотягнувся краулер».
   2. 1.2Кожне джерело має названого власника, у якого можна спитати, чи має документ там бути.
   3. 1.3Права доступу кожного джерела можна виразити на рівні документа. Джерело, де цього не можна, лишається поза межами.

2. 2.Фрагментація

   1. 2.1Ріжте за структурою документа: заголовок і його розділ, таблиця з підписом, функція з описом.
   2. 2.2Кожен фрагмент несе назву документа й шлях розділу, щоб уривок і далі казав, про що він.
   3. 2.3Кожен фрагмент має стабільний ідентифікатор, що переживає переіндексацію: відповідь може на нього послатися, а лог — назвати.
   4. 2.4Таблиці, блоки коду й списки не розрізаються навпіл.

3. 3.Ембединги й індекс

   1. 3.1Одна модель ембедингів для документів і питань, і її назву записано разом з індексом.
   2. 3.2Зміна моделі ембедингів означає повну перебудову, і для цього є записана процедура.
   3. 3.3Індекс зберігає правила доступу й метадані свіжості поруч із кожним фрагментом, а не в окремій системі.

4. 4.Пошук

   1. 4.1Фільтрація за правами працює до пошуку за схожістю, тож заборонений документ ніколи не стає кандидатом.
   2. 4.2Пошук за ключовими словами працює поруч із векторним, і два списки результатів обʼєднуються.
   3. 4.3Шукайте широко, переранжуйте кандидатів і передавайте в промпт лише кілька найкращих.
   4. 4.4Повноту на розміченому наборі питань вимірюють і ведуть як число, що рухається.

5. 5.Генерація

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

6. 6.Свіжість і видалення

   1. 6.1Оновлення інкрементні й ключовані за ідентифікатором документа: правка заміняє фрагмент, а не дублює його.
   2. 6.2Видалення обробляються явно, і відкликаний документ залишає індекс того самого дня.
   3. 6.3Є сформульована свідома відповідь на питання «наскільки застарілим це може бути?», і хтось із нею погодився.
   4. 6.4Переіндексація джерела, чиї права змінилися, — це планова рутинна задача, а не реагування на інцидент.

7. 7.Експлуатація

   1. 7.1Версія індексу є частиною того, що розгортається, — поруч із версією промпту й версією моделі.
   2. 7.2Знайдене логується з кожною відповіддю, щоб скаргу з минулого тижня можна було відтворити.
   3. 7.3Повна перебудова ідемпотентна і запускається на вимогу без відновлення з бекапу.

Девʼять симптомів і де кожен лікується

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

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

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

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

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

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

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

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

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

Правильна відповідь, яка є інцидентом

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

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

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

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

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

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

Пʼять систем, які знайшли рівно те, що їм звеліли

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

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

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

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

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

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

• ІнфраструктураВекторні бази данихВекторна база відповідає на питання «що найбільш схоже на це» серед мільйонів обʼєктів за мілісекунди — і робить це, не дивлячись на більшість із них. У цьому й уся угода: кожна відповідь наближена, а наскільки саме — це число, яке ви задаєте, а не властивість продукту. На цій сторінці — що насправді зберігається, родини індексів і чого кожна коштує в памʼяті, чому фільтрація за метаданими складніша, ніж здається, що роблять з індексом видалення й переобчислення ембедингів, і коли колонка в базі, яку ви вже тримаєте, є кращою відповіддю.
• РозробкаFine-tuningFine-tuning продовжує навчання моделі на ваших власних прикладах, тож поведінка, яку ви щоразу описуєте в промпті, стає для неї типовою. Він чудово вчить форми, тону й суджень і майже не годиться, щоб навчити фактів. Сторінка починається з вісімнадцяти умов, які варто пройти до навчального прогону, і таблиці, що каже, який щабель вам справді потрібен; далі — чим різняться методи, чому набір даних і є всім проєктом, відкладене порівняння, що вирішує, чи воно було варте, чого це коштує в інших місцях моделі, і пʼять задокументованих випадків.
• РозробкаAI-агентиAI-агент — це цикл, у якому модель вирішує, що робити далі: викликає інструмент, читає результат і вирішує знову, доки не визнає задачу виконаною. Це одне проєктне рішення — керування, перенесене з вашого коду в модель, — купує здатність робити задачі, яких не можна описати заздалегідь, і коштує детермінованості, передбачуваного рахунку й обмеженого радіуса ураження. Сторінка починається з рішення про те, чи потрібен він вам узагалі; далі — цикл і арифметика, що ним керує, поверхня інструментів, режими збою, які трапляються лише в циклі, запобіжники й чеклист готовності на девʼятнадцять рядків, як оцінювати траєкторію, і пʼять задокументованих прогонів.