Що таке RAG: надання ШІ моделям доступу до зовнішніх знань
Посібник для початківців з RAG — чанкінг, ембеддинги, векторний пошук, гібридне отримання даних та ситуації, коли RAG все ще створює галюцинації, із чіткими діаграмами архітектури.
Великі мовні моделі відповідають, спираючись на пам’ять, сформовану під час навчання. Ця пам’ять є потужною, але неповною: вона може не містити внутрішніх посібників, застарілих правил та фактів, які ніколи не з’являлися у публічних текстах. Технологія Retrieval-Augmented Generation (RAG) усуває цю прогалину, спочатку отримуючи відповідний зовнішній матеріал, а потім прослядаючи модель дати відповідь на основі цього матеріалу.
Що таке RAG?
Без процесу пошуку запит безпосередньо надходить до моделі:
User Question
↓
LLM
↓
Answer
За допомогою RAG система знаходить відповідну інформацію перед генерацією відповіді:
User Question
↓
Find Relevant Information
↓
Give Information to the LLM
↓
LLM
↓
Answer
Модель все одно формулює кінцевий текст; новим елементом є контекст з бази знань.
Чому нам потрібен RAG?
Ліміти навчання, приватні корпуси даних та стрімко змінювані правила руйнують можливість отримання відповідей, заснованих лише на пам’яті. Посібник для співробітників, оновлений минулого тижня, не буде входити до ваг моделі типу frontier. RAG дозволяє асистентові звертатися до цього посібника під час запиту без повторного навчання.
Простий приклад RAG
Співробітник запитує про можливість перенесення відпустки. Процес виглядає так:
Employee asks a question
↓
Search the employee handbook
↓
Find the relevant section
↓
Give that section to the LLM
↓
LLM generates the answer
Асистент повинен цитувати посібник, а не вигадувати правило, яке „звучить правильно“.
Як працює RAG?
Важливі дві фази: підготовка знань офлайн, а потім відповідь онлайн.
1. Підготовка знань
Завантажуються файли, вони діляться на частини, ці частини інкорпоруються, а вектори зберігаються для пошуку.
2. Відповідь на запит
Запит інкорпорується, отримуються найкращі частини даних, вони об’єднуються у запит до асистента та генерується відповідь.
Частина 1: Підготовка знань
Типові джерела інформації для асистента з кадрів:
Employee Handbook
Vacation Policy
Benefits Guide
Leave Policy
Процес підготовки:
Documents
↓
Extract Text
↓
Break into Smaller Pieces
↓
Create Embeddings
↓
Store for Search
Крок 1: Отримання інформації
Витягніть чистий текст з кожного джерела:
Employee Handbook
↓
Extract text
↓
"Employees receive..."
"Vacation requests..."
"Leave policy..."
Заголовки, підзаголовки та елементи навігації слід видалити на ранньому етапі, щоб вони ніколи не ставали „фактами“.
Крок 2: Розділення документа на частини
Довгі посібники перевищують обмеження контексту та приховують відповідні абзаци. Розділення на частини створює одиниці, які можна шукати:
Employee Handbook
↓
┌───────────────┐
│ Chunk 1 │
├───────────────┤
│ Chunk 2 │
├───────────────┤
│ Chunk 3 │
├───────────────┤
│ ... │
└───────────────┘
Чому важливе розділення на частини?
Частини, які занадто великі, знижують релевантність; частини, які занадто малі, втрачають сусідні правила (особливо заперечення та винятки). Накладання між сусідніми частинами зберігає контекст меж. Почніть просто — з фіксованим розміром та накладанням — а потім налаштовуйте, коли оцінки покажуть пропуски.
Крок 3: Створення ембеддингів
Ембеддинги відображають текст у вигляді векторів, тож фрази з схожим значенням розташовуються поруч навіть без спільних ключових слів.
Текст запитання:
"What is my vacation allowance?"
Парапрофізування з тим самим значенням:
"How many annual leave days do I get?"
Обидва варіанти можуть опинитися поблизу однієї й тієї самої частини з правилами відпусток після імбеддингу:
"What is my vacation allowance?"
↓
Embedding
↓
Numerical representation
Використовуйте один і той самий інструмент імбеддингу для індексації та пошуку; поєднання різних моделей таємно псує алгоритм пошуку найближчих сусідів.
Крок 4: Зберігання інформації для пошуку
Кожна частина разом із її вектором потрапляє до векторного індексу (або гібридного сховища):
Document Chunk
↓
Embedding
↓
Vector Database
Метадані — назва джерела, сторінка, рівень доступу, дата набрання чинності — мають супроводжувати частину для подальших фільтрів та посилань.
Частина 2: Відповідь на запит користувача
Онлайн-шлях:
User Question
↓
Understand the question
↓
Search the stored information
↓
Find relevant chunks
↓
Give those chunks to the LLM
↓
Generate an answer
Крок 5: Отримання релевантної інформації
Імбеддинг запитання дозволяє отримати найкращі частини, наприклад:
Chunk 147 → Vacation carryover policy
Chunk 148 → Vacation request process
Chunk 62 → Employee benefits
Chunk 300 → Security policy
Якість ранжування тут визначає якість кінцевої відповіді. Погане отримання даних не можна виправити за допомогою кращої формулювання запиту.
Крок 6: Надати інформацію LLM
Завантажений текст стає контекстом запиту:
Context:Employees may carry over up to 5 unused
vacation days into the following year.
Question:How many vacation days can I carry over?
Інструкції мають вимагати відповідей на основі контексту та визнання відсутності інформації, якщо вона не присутня.
Крок 7: Створити відповідь
Retrieved Information
+
User Question
↓
LLM
↓
Answer
Модель формує відповідь, ґрунтуючись на отриманих даних, а не на загальноприйнятих стереотипах у сфері HR.
Повна архітектура RAG
Етикетка офлайн-підготовки:
KNOWLEDGE PREPARATION
Діаграма «кінець-кінець»:
Documents
↓
Extract Text
↓
Chunking
↓
Embeddings
↓
Vector Database
│
│
│
▼
USER QUESTION
↓
Query Embedding
↓
Retrieval
↓
Relevant Information
↓
Question + Context
↓
LLM
↓
Answer
До поставлення запитання
Documents
↓
Chunks
↓
Embeddings
↓
Vector Database
Коли надходить запитання
Question
↓
Retrieval
↓
Relevant Context
↓
LLM
↓
Answer
Чи використовує RAG лише пошук векторів?
Ні. У продакшн-системах часто поєднують різні методи.
Пошук за ключовими словами
Лексичні засоби порівняння (BM25 та інші) ефективні для точних токенів: кодів політик, SKU, ідентифікаторів помилок, власних імен.
Семантичний пошук
Векторний пошук виявляє парафрази та синоніми, які залишаються непоміченими ключовими словами.
Гібридний пошук
Поєднайте обидва підходи, а потім об’єднайте рейтинги:
Keyword Search
+
Semantic Search
↓
Hybrid Search
Гібридний підхід є найкращим стандартом, коли трафік містить як точні ідентифікатори, так і запити природною мовою.
RAG не усуває галюцинацій
Механізм пошуку зменшує кількість необґрунтованих вигадок, але не усуває їх повністю. Серед причин невдач можна назвати:
Завантажено неправильний фрагмент:
User Question
↓
Wrong information retrieved
↓
LLM
↓
Wrong answer
Не знайдено нічого релевантного, проте модель все одно дає відповідь:
User Question
↓
No relevant information found
↓
LLM
↓
Unsupported answer
Засоби мінімізації: більш строгий пошук, переранжування, інструкції щодо відмови, посилання та оцінка точності — а не лише плавності мовлення.
RAG проти налаштування під конкретні завдання
RAG
Найкраще підходить, коли знання часто змінюються, їх потрібно цитувати або вони залишаються приватними поза межами даних навчання. Оновлення означають переіндексування, а не повторне навчання.
Налаштування під конкретні завдання
Найкраще підходить, коли необхідно змінити поведінку, стиль чи формат завдання, або коли знання достатньо стабільні та компактні, щоб їх вбудувати. Оновлення коштує дорого, коли змінюються правила.
Багато продуктів використовують обидва підходи: налаштування під конкретні навички та RAG для фактів.
Де корисний RAG?
Підтримка клієнтів
Асистенти, засновані на документації продукту та шаблонах заявок.
Охорона здоров’я
Пошук протоколів та рекомендацій із суворим контролем посилань та доступу (досі діють правила домену).
Фінанси
Відповіді щодо правил, розкриття інформації та правил продукту, які мають відображати найновіший схвалений текст.
Кадри
Інструкції, пільги, правила відпусток — саме такий же формат запитань від працівників, як і вище.
Розробка програмного забезпечення
Внутрішні ADR, посібники з експлуатації та довідники API поруч із публічною документацією.
Коли варто використовувати RAG?
Використовуйте RAG, коли відповіді мають відображати певний корпус даних, який більший за запит, змінюється швидше, ніж цикли налаштування, або потребує вказівки джерела. Уникайте RAG для простих фактів, які вже знає базова модель, для суто творчих завдань чи для сценаріїв з надзвичайно низькою затримкою, де неможливо дозволити собі крок пошуку інформації.
Що може ускладнити використання RAG?
Межі частин даних, зміни ембеддингів, застарілі індекси, витоки контролю доступу та прогалини у оцінці. Конкретний приклад неправильної роботи:
Користувач запитує:
User asks:
"What is the vacation carryover policy?"
Система знаходить неправильну групу правил:
↓System retrieves:
"Health insurance policy" ↓LLM receives wrong context ↓Poor answer
Потім модель виглядає впевненою, пояснюючи медичне страхування так, ніби це продовження страхування під час відпустки. Спочатку виправте процес пошуку та фільтри метаданих, перш ніж звинувачувати генератор.
Що потрібно знати, щоб створити RAG?
Практична ієрархія навичок:
RAG Fundamentals
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Databases
↓
Retrieval
↓
Prompt + Context
↓
LLM
↓
Evaluation
Обробка документів, стратегія часткової обробки, ембеддинги, сховища векторів, складання запитів, оцінка та операції (перебудова, доступ, моніторинг) — усе це має значення.
Загальна картина
Knowledge
↓
Find relevant
information
↓
Give it to LLM
↓
Generate
answer
Знання знаходяться поза моделлю; процес отримання цих знань заповнює прогалину; генерація є останнім етапом.
Вибір способу чанкінгу впливає на розмірність ембеддингів та тип індексу: конфігурації HNSW з лише щільними ембеддингами поводяться інакше, ніж гібридні сховища BM25+векторів, коли запити містять як прозу, так і ідентифікатори. Необхідно мати письмову політику щодо факторів, які спричиняють перебудову індексу — нові версії посібника, видалені сторінки, зміни прав доступу — та перевіряти, чи справді видалені матеріали зникають з індексу, а не залишаються у вигляді «сирітських» векторів. Форматування цитат також має бути частиною умов генерації: якщо інтерфейс користувача обіцяє інформацію про походження сторінки, то запит та постобробник мають генерувати стабільні ідентифікатори джерела, а не декоративні примітки, які нікуди не посилаються.
Поновлення ранжування заслуговує на коротке згадування навіть у початковому курсі. Складення списку за допомогою бі-енкодера є недорогим; обробка п’ятдесяти найкращих кандидатів за допомогою крос-енкодера часто усуває помилки типу „майже правильний документ, неправильний розділ“, які роблять демонстрації некоректними. Поєднайте це з простими правилами відхилення, коли показники схожості опускаються нижче встановленого порогу. Команди, які пропускають оцінку, зазвичай виявляють ці проблеми перед зацікавленими сторонами, а не у нотатках.
Нарешті, пам’ятайте про економічну структуру RAG: витрати на індексацію оплачуються постійно з ростом корпусів даних, тоді як витрати на доопрацювання сплачуються пакетами. Для сфер із суворими вимогами до політик ці постійні витрати на індексацію зазвичай є дешевшими, ніж щотижневе доопрацювання — крім того, це зберігає можливість навести точний абзац, про який просив аудитор. Саме ця можливість аудиту часто є справжньою вимогою до продукту, яка ховається за формулюванням „створити чат-бота“.
Під час інтеграції RAG у існуючу стек технологій підтримки почніть з одного корпусу даних та однієї групи запитань, замість того щоб намагатися охопити все. Вимірюйте кількість випадків відхилення, ескалації та скарг на неправильні відповіді у цьому обмеженому діапазоні, перш ніж масово додавати простори Confluence. Конкретні успіхи допомагають з’ясувати, які розміри фрагментів та гібридні ваги є ефективними; широкомасштабні запуски здебільшого показують, що панелі керування без метрик точності приховують проблеми з якістю. Протягом перших тижнів тримайте чергу для людського перегляду суперечливих відповідей, щоб редактори могли позначити «хороше отримання інформації/погане її генерування» та «погане отримання інформації» — це різні шляхи виправлення. З часом ці позначки стають сигналами для алгоритмів ранжування та допомагають вирішити, чи слід певну тему вийняти з RAG та перетворити на детерміністичний робочий процес.
Остаточні висновки
Store external knowledge
↓
Find relevant information
↓
Give that information to an LLM
↓
Generate a grounded response
Зберігайте зовнішні знання, знаходьте відповідну інформацію для кожного запитання, а лише потім генеруйте відповідь. Цей цикл з трьох кроків — це RAG: простий у схематизації, але вимогливий у ефективній роботі, і все ж залишається найпрактичнішим способом змусити асистентів дотримуватися приватних та змінюваних фактів.
Дисципліна у роботі відрізняє демонстраційні версії від надійних асистентів: заморожуйте набір запитань, вимірюйте частку успішних пошуків разом із точністю відповідей та регулярно оновлюйте індекси відповідно до частоти змін джерельних матеріалів. При використанні гібридних методів пошуку, переранжування чи фільтрів метаданих залишайте ту саму систему оцінювання, щоб покращення були помітними, а не лише припущеннями. Вважайте мітки доступу частиною навантаження даних з самого початку; додавання прав доступу пізніше є причиною витоку приватних записів HR у публічні чати. Нарешті, коли основні фрагменти інформації виглядають слабкими, краще відмовитися та попросити посилання, ніж робити впевнені припущення — користувачі більше довіряють обґрунтованій тиші, ніж витонченим вигадкам.
Зберігайте інструкції щодо оновлення індексів, перевірки доступу та відомих способів збоїв разом із схемами оптимальних процесів, щоб оператори отримували більше, ніж просто презентації.
Зберігайте посібники з процедурами відновлення індексів, перевірок доступу та відомих способів збоїв поруч із діаграмами оптимальних сценаріїв роботи, щоб оператори отримували більше, ніж просто набір слайдів.
Зберігайте посібники з процедурами відновлення індексів, перевірок доступу та відомих способів збоїв поруч із діаграмами оптимальних сценаріїв роботи, щоб оператори отримували більше, ніж просто набір слайдів.
Зберігайте посібники з процедурами відновлення індексів, перевірок доступу та відомих способів збоїв поруч із діаграмами оптимальних сценаріїв роботи, щоб оператори отримували більше, ніж просто набір слайдів.
Зберігайте посібники з процедурами відновлення індексів, перевірок доступу та відомих способів збоїв поруч із діаграмами оптимальних сценаріїв роботи, щоб оператори отримували більше, ніж просто набір слайдів.
Зберігайте посібники з процедурами відновлення індексів, перевірок доступу та відомих способів збоїв поруч із діаграмами оптимальних сценаріїв роботи, щоб оператори отримували більше, ніж просто набір слайдів.
Зберігайте посібники з відновлення індексу, перевірок доступу та відомих способів збоїв поруч із діаграмами оптимальних сценаріїв роботи, щоб оператори отримували більше, ніж просто набір слайдів.