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

Архітектура мінімально життєздатної системи RAG

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

  1. 01Парсер документів: PDF, DOCX, HTML, квитки з Jira/Zendesk, потоки Slack
  2. 02Розбивач з 10–15% перекриттям та заголовками, збереженими як метадані
  3. 03Модель вбудовування (text-embedding-3-large або відкритий bge-m3)
  4. 04Векторна база даних — Pinecone, Qdrant або pgvector, якщо ви вже на Postgres
  5. 05Повторний ранжувач (Cohere Rerank або bge-reranker-v2) — критично важливий для якості
  6. 06LLM з системним запитом, який забороняє галюцинації поза контекстом

П'ять помилок, які вбивають проекти на етапі пілота

1. Погане розбиття

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

2. Відсутність повторного ранжувача

Схожість вбудовування дає вам топ-50 релевантних фрагментів, але саме повторний ранжувач обирає 5–7, які насправді відповідають на запитання. Без нього якість відповідей знижується на 30–40% — і це найдешевше покращення в усьому процесі.

3. Ігнорування метаданих

Версія документа, дата оновлення, відділ, мова — без фільтрів метаданих агент буде рекомендувати застарілі політики. Завжди зберігайте «свіжість» і враховуйте її під час отримання.

4. Один великий індекс

Не скидайте всю компанію в один індекс. Окремі простори імен для HR, юридичних, продуктових і клієнтських даних — як для безпеки, так і для якості.

5. Відсутність оцінок

Без набору з 100–200 контрольних запитань ви не знатимете, чи зміна підказки насправді покращила щось. Інвестуйте в оцінки з першого дня.

RAG — це 80% інженерії даних і 20% інженерії підказок. Команди, які вважають, що це навпаки, застряють на пілотному етапі.

Коли RAG не є вашим рішенням

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