Пояснення RAG: як не дозволити чат-ботам вигадувати факти про компанію.
Практичний огляд процесу RAG — завантажувачі, розділення на частини, ембеддинги, сховища векторів, переранжування, гібридний пошук та RRF — а також ситуації, коли взагалі не варто використовувати механізм пошуку інформації.
Типове завдання для ранніх чат-ботів виглядає так: відповідати на запитання з корпоративних документів. Швидкий прототип часто здається досконалим — але вигадує факти. Він може стверджувати про «підтримку 24/7 у 12 країнах», хоча насправді підтримка існує лише в одній країні, протягом робочих годин та лише тоді, коли є певна IT-спеціалістка.
Саме ця проблема є суттю технології RAG (Retrieval-Augmented Generation): модель, яка може створити відповідь, — це не те саме, що модель, яка має справжні дані організації. Без підтримки реальними даними такі моделі поводяться, як впевнений родич, який на весіллі вигадує історію родини — приблизно на сорок відсотків правильно та на сто відсотків впевнено.
Частина 1: Що таке RAG насправді?
RAG означає Retrieval-Augmented Generation. Ідея проста.
Замість того, щоб просити модель відповісти лише на основі запам’ятаного під час навчання, система спочатку отримує відповідний матеріал, а потім просить про відповідь, обмежену цим матеріалом.
Розглядайте текстову модель як амбітного, надто впевненого стажера: чудово вміє писати, але погано пам’ятає політику кадрів 2023 року. Завдання RAG — покласти потрібну сторінку в руки стажера до того, як почнеться відповідь.
Без RAG: відповіді ґрунтуються на пам’яті (застарілій, універсальній або не пов’язаній з компанією). З RAG: відповіді ґрунтуються на пам’яті плюс файлах, отриманих для цього запиту.
Коротке формулювання, яке залишається актуальним:
Правильна інформація × Правильний контекст × Правильне запитання = Правильна відповідь
Частина 2: Конвеєр RAG
Покращення через отримання даних — це не один магічний крок. Це багатоетапний процес: якщо будь-який етап зламається, відповіді надходять з запізненням або є неправильними.
Етап 1 — Джерела знань
Де знаходиться матеріал? PDF-файли, файли Word, сторінки Notion, таблиці SQL, експорти з Slack та забуті таблиці — усе це вважається джерелами знань.
Етап 2 — Завантажувачі документів (надходження даних)
Процес обробки перетворює PDF/HTML/CSV тощо на чистий, уніфікований формат — зазвичай щось на кшталт:
Document(
page_content="The quick brown fox...",
metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)
Ігнорування ретельного завантаження та безпосереднє введення необроблених байтів PDF у потік часто призводить до того, що заголовки та підписи стають „фактами“ („Згідно зі сторінкою 47 із 92…“). Ніхто не просив ці додаткові елементи.
Урок: брудна обробка даних призводить до брудного пошуку та некоректних відповідей. Необхідно очищувати дані вже на початковому етапі.
Етап 3 — Розділення на частини
200-сторінковий PDF не можна просто вставити у запит. Вікна контексту є обмеженими, тож надання моделі всього кулінарного посібника, коли потрібен був лише один рецепт, погіршує точність відповідей.
Тож документи розділяються на сегменти.
Поширені стратегії:
- Розділення на фіксованому розмірі — розрізати кожні N токенів. Швидко, але виникають розрізи посеред речення.
- Розділення на фіксованому розмірі з перекриттям — ті самі розрізи з невеликим перекриттям, щоб контекст меж зберігався. Поширений стандартний варіант.
- Ієрархічне/рекурсивне розділення — враховувати розділи та абзаци перед розрізанням.
- Семантичне розділення — групувати речення з однією темою за допомогою ембеддингів. Більш розумне, але потребує більше обчислень.
- Розділення на основі LLM / Агентське розділення — запитати модель, де слід робити розрізи. Дорого, але корисно для юридичних/медичних текстів.
Практичне правило після спостереження за тим, як у контракті сегментується фраза “shall NOT be liable” після “shall”: починайте з фіксованого розміру з перекриттям; додавайте складність лише тоді, коли якість пошуку справді погана.
Етап 4 — Ембеддинги (перетворення слів на координати GPS)
Ембеддинг перетворює речення на список чисел, який фіксує значення, а не правопис. Речення з схожим значенням розташовуються поруч навіть у разі відсутності спільних слів.
Фрази „Як можна скинути пароль?“ та „Креденції входу забулися“ майже не мають спільних елементів, проте означають майже одне й те саме. Пошук за ключовими словами не бачить цього зв’язку; ембеддинги виявляють його шляхом порівняння значень.
Історія розвитку йшла від методу „Мішок слів“ (який бере до уваги лише кількість) → TF-IDF → Word2Vec → BERT → сучасних API ембеддингів та відкритих моделей (OpenAI, Cohere, BGE, E5 та інші), які враховують контекст.
Аналогія: „Мішок слів“ — це машинний переклад слово за словом. Сучасні ембеддинги схожі на людину, яка живе в обох культурах та розуміє суть.
Етап 5 — Бази даних векторів (бібліотека, де зберігаються всі ці списки чисел)
Коли сегменти перетворюються на вектори, їм потрібне швидке зберігання та пошук: Pinecone, Qdrant, Weaviate, Milvus, ChromaDB, FAISS та подібні системи.
При отриманні запиту повертаються топ-K сегментів, вектори яких знаходяться найближче до вектора запиту. Варіанти індексації включають:
- Груба сила — порівнювати все. Точний метод, але повільний у великих масштабах.
- ANN (Апроксимований найближчий сусід) — трохи менша точність, але значно швидше. Хороший стандартний варіант.
- IVF — спочатку створюються кластери; пошук проводиться лише в перспективних кластерах.
- HNSW — швидке пересування по графі сусідів. Поширений у продакшн-системах типу RAG.
Використання методу грубої сили з мільйонами векторів «для ідеальної точності» може перетворити запити, які виконуються за мілісекунди, на операції з значними затримками. Підбирайте індекс відповідно до розміру даних, а не з міркувань гордості.
Етап 6 — Отримання даних (пошук за схожістю)
Коли надходить запитання, його вбудовують за допомогою того самого моделі, що використовується для файлів — поєднання різних моделей є класичною помилкою — а потім отримують топ-K схожих фрагментів.
Косинусна схожість є стандартним показником: вона визначає, наскільки два вектори суміжні за напрямком, ігноруючи їх довжину. Це стабільний параметр, який підходить для різної довжини тексту.
Етап 7 — Розширення (надання інтерну правильного файлу)
Отримані фрагменти вставляють у запит разом із запитанням користувача. Це і є крок «Розширення»:
System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?
Етап 8 — Генерація (LLM нарешті відповідає)
Лише тоді модель формулює остаточну відповідь, ґрунтуючись на отриманому контексті, а не на інтуїції.
Частина 3: Те, що відрізняє «це працює» від «це працює добре»
Навчальні матеріали часто обмежуються базовим алгоритмом. Для якісних реальних систем зазвичай потрібно більше.
Поновна класифікація — тому що перший результат пошуку не завжди є найкращим
Метод бі-енкодерів є швидким, але грубим: запит та документ кодуються окремо, а потім порівнюються. Він чудово підходить для звуження мільйонів елементів до приблизно 50 кандидатів.
«Швидко та приблизно правильно» не завжди означає «справді правильно», тому повільніший крос-енкодер для поновної класифікації оцінює запит та документ разом, враховуючи нюанси, заперечення та контекст. Він працює лише з коротким списком та підвищує якість справжніх найкращих результатів.
Аналогія: бі-енкодери швидко переглядають резюме для формування короткого списку; крос-енкодери проводять співбесіду.
У боті з часто задаваними запитаннями в медицині без переранжування запит про взаємодію з алкоголем може вивести інший препарат, який лише має спільну лексику. Крос-кодер з переранжуванням часто миттєво вирішує цю проблему. Коли важлива точність (у юридичних, медичних чи фінансових ситуаціях), переранжування є обов’язковим, а не факультативним.
Гібридний пошук — тому що як лексичний, так і векторний пошук окремо є дещо обмеженими
Векторний пошук враховує значення, але може пропустити точні токени — коди SKU, ідентифікатори помилок, власні назви. Лексичний пошук BM25 точно знаходить конкретні рядки, але не бачить синонімів.
Гібридний пошук поєднує метод BM25 та векторне пошукове знаходження: точність ключових слів разом із семантичною відтворюваністю. Коли немає впевненості, гібридний підхід є хорошим стандартом — рідко гірший, часто кращий.
Fusion RAG — поєднання кількох думок, як у груповому проекті (але цього разу воно справді працює)
Кілька пошукових алгоритмів (щільні, на ключові слова, специфічні для домену) створюють кілька ранжованих списків. RAG Fusion об’єднує їх за допомогою Reciprocal Rank Fusion (RRF).
Ідея проста, навіть якщо формула виглядає формальною: документ, який посідає високе місце за кількома незалежними методами, ймовірно, є релевантним. RRF надає перевагу послідовності між списками, а не сухим оцінкам, які неможливо порівняти між різними пошуковими алгоритмами.
RRF(d) = Σ 1 / (k + rank_i(d))
Тут k зазвичай дорівнює 60 — це більше індустріальна конвенція, ніж виведена константа.
Метадані — мітки, які згодом врятують вам життя
Метадані — це дані про дані: назва, автор, дата, джерело, рівень доступу. Вони здаються незначними, поки не з’являється правило доступу — «ніколи не показувати внутрішні документи HR зовнішнім користувачам» — і тоді мітки access_level: internal раптово стають важливими.
Метадані дозволяють використовувати фільтри, покращувати ранжування, забезпечувати контроль доступу та діагностувати проблеми („Чому документ 2019 року відповів на запитання 2026 року?“ → відсутні фільтри за датою).
Пам’ять та кешування — тому що ніхто не хоче платити двічі за одні й ті самі обчислення
Дві ідеї, які часто плутають:
- Пам’ять = довгострокове зберігання уподобань, попередніх дій користувача та постійних фактів.
- Кешування = короткострокове повторне використання дорогих результатів (відповідей моделі, результатів пошуку) для подальших запитів.
Пам’ять робить асистентів послідовними у своїх діях. Кешування робить їх швидкими та економічними у використанні. Поєднання цих методів — наприклад, кешування уподобань із терміном дії 10 хвилин — може призвести до видалення імені користувача під час розмови. Тримайте ці концепції окремо.
Частина 4: Коли не варто використовувати RAG?
Метод посилення через отримання даних не є універсальним рішенням.
Уникайте використання RAG, коли:
- Питання стосується загальних знань, які модель вже може обробити („столиця Франції“ не потребує векторного індексу).
- Факти постійно змінюються (ціни, результати матчів у прямому ефірі) — краще використовувати API.
- Завдання є суто творчим (поезія, мозковий штурм) — пошук інформації рідко допомагає.
- Корпус достатньо малий, щоб його можна було безпосередньо включити до запиту.
- Ультраповільна затримка не дозволяє додаткових кроків пошуку інформації.
Іноді рішенням є корекція формулювання запиту чи фінтунінг, а не повний векторний підхід. Виберіть інструмент перед тим, як починати роботу.
Частина 5: Найкращі практики, навчені на власному досвіді
- Розділяйте інформацію розумно, а не на дуже маленькі частини. Дуже маленькі фрагменти втрачають контекст; дуже великі — точність. Краще використовувати фрагменти з перекриттям.
- Використовуйте один інструмент для ембеддингу файлів та запитів. Поєднання різних моделей означає вимірювання у змішаних одиницях.
Команди, які розглядають процес отримання інформації як щось другорядне, зазвичай знову стикаються з тими самими проблемами: беззвучна зміна схеми у завантажувачах, межі блоків даних, які розділяють заперечення, неузгодженості моделей вбудовування між офлайн-індексуванням та онлайн-запитами, а також панелі керування, які вимірюють лише „затримку відповіді“, ігноруючи її точність. Ефективна практика RAG розглядає кожну стадію процесу як окремий продукт із визначеними власниками, тестами та планами на відкат — особливо коли асистент працює з клієнтами чи в регульованих робочих процесах.
Під час оцінки змін краще використовувати парні експерименти: однаковий набір запитань, однакова шкала оцінювання, порівняння показників Recall@k та groundedness до та після змін у розбитті даних на блоки чи коригуванні алгоритму ранжування. Невеликі покращення у процесі отримання інформації часто є ефективнішими за більші зміни, пов’язані лише із формулюванням запитів, оскільки генератор не може посилатися на те, що ніколи не потрапляло у вікно контексту.
Мантра RAG
Правильна інформація → Правильний контекст → Правильне запитання → Правильна відповідь.
RAG — це технологія, а не магія. Чистий джерело даних, розумний процес пошуку, чесне доповнення інформації та чітке формулювання запиту перетворюють занадто впевненого користувача на кваліфікованого фахівця, який спочатку ознайомлюється з файлом, — і таким чином уникає вигадування уявної 24/7 підтримки, якої насправді не існує.