Після чотирьох місяців перенесення конвеєра RAG (Retrieval-Augmented Generation) із Jupyter notebook у живий сервіс, автор визначив п'ять конкретних рішень, які перетворили демонстраційну модель на систему, на яку користувачі дійсно можуть покластися. Різниця проявляється в цифрах: проста зміна способу розбиття тексту підвищила показник успішного пошуку (hit rate) з 61% до 83%, а скромний оціночний набір із 200 реальних запитів тепер виявляє більшість регресій ще до того, як вони потраплять до клієнтів.

Чому це важливо

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

1. Припиніть використовувати фрагменти фіксованого розміру

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

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

2. Використовуйте гібридний пошук

Чистий векторний пошук (на основі подібності ембедінгів) чудово справляється з пошуком уривків з однаковим значенням, але пасує перед точними ідентифікаторами, такими як коди помилок, номери версій або специфічна термінологія. Користувач, який шукає код помилки на кшталт «ERR-XXXX», може отримати семантично схожий абзац, який взагалі не містить цього коду.

Гібридний пошук поєднує щільний векторний індекс із традиційним індексом BM25 (на основі частоти термінів). Шляхом зважування обох показників система знаходить об'єкти, які є одночасно семантично близькими та містять точні терміни, введені користувачем. Для продакшену гібридний пошук є базовою вимогою, а не просто приємним доповненням.

3. Працюйте із застарілими даними

Неактуальні таблиці цін, документи з політикою компанії або примітки до випуску прошивок швидко підривають довіру. Три практичні кроки допоможуть підтримувати індекс у свіжому стані:

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

Ці заходи безпеки запобігають видачі системою ціни, яка була актуальною минулого кварталу, або політики, яка вже була замінена.

4. Використовуйте переранжування замість оновлення моделей

Оновлення моделі ембедінгів дає лише невелике покращення якості, тоді як додавання cross-encoder reranker забезпечує набагато більший стрибок при менших витратах.

Робочий процес у продакшені спочатку отримує 20 дешевих кандидатів за допомогою гібридного пошуку, а потім пропускає їх через reranker, щоб вибрати п'ять найкращих. Такий двоступеневий підхід дає значне підвищення якості за частку вартості повного оновлення моделі.

5. Створіть реальний оціночний набір

Ви не можете покращити те, що не вимірюєте. Автор зібрав тестовий набір із 200 справжніх запитів користувачів, кожен з яких має відповідь, підготовлену експертом. Кожна зміна коду перевіряється на цьому наборі; будь-яка регресія виявляється до розгортання.

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

Конвеєр у продакшені на практиці

  • Ingest (Збір): Чанкінг з урахуванням структури зберігає заголовки, блоки коду та повороти розмови.
  • Index (Індексація): Зберігання як щільних ембедінгів, так і статистики термінів BM25.
  • Retrieve (Пошук): Гібридний пошук повертає 20 кандидатів, балансуючи між семантичною схожістю та точним збігом термінів.
  • Rerank (Переранжування): Cross-encoder звужує список до п'яти найбільш перспективних уривків.
  • Generate (Генерація): LLM отримує ці найкращі фрагменти разом із їхніми метаданими для створення фінальної відповіді.
  • Evaluate (Оцінювання): Кожна відповідь логується; помилки повертаються до тестового набору з 200 запитів.

Ставки та компроміси

Добре налаштований пайплайн зменшує кількість галюцинацій, покращує релевантність відповідей і знижує витрати на моделі з надлишковими ресурсами. Результатом є вища задоволеність користувачів і менші витрати на підтримку. Ігнорування цих кроків призводить до створення нестабільного сервісу, що підриває довіру до бренду та змушує витрачати великі кошти на «гасіння пожеж».

На що звернути увагу далі

У міру того, як open-source ембедінги та векторні бази даних ставатимуть зрілішими, межа між «щільним» (dense) та «розрідженим» (sparse) пошуком розмиватиметься, проте принцип поєднання семантичного та точного зіставлення залишиться незмінним.

Головна думка: У RAG-системах мовна модель рідко є вузьким місцем. Справжня робота полягає в тому, як ви розбиваєте на частини, індексуєте та надаєте доступ до базового контенту. Правильні рішення в цих питаннях перетворюють яскраве демо на надійний продукт.