RAG на ChromaDB: від прототипу до продакшену

Чому RAG-прототип не доходить до промислової експлуатації

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

Далі починається реальний корпус — тисячі сторінок, скани, вкладені таблиці та три версії одного регламенту одночасно.

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

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

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

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

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

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

Що дає керований RAG-конвеєр в експлуатації

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

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

Гібридний пошук замість одного векторного

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

Гібридний пошук додає векторну видачу до лексичної та пропускає результат через переранжування: на наборі перевірних запитань частка правильних відповідей піднімається приблизно з двох третин до дев'яти з десяти. Розмиті відповіді, які прототип ховав за впевненим тоном, стають видимими й придатними для розбору.

Що видно в експлуатації

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

Оновлення бази знань перетворюється на регламент: змінений документ переіндексовується за хвилини, стара версія не підмішується в нові відповіді.

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

Режими пошуку: векторний, гібридний, з переранжуванням

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

Щойно в тексті з'являються артикули, номери пунктів і абревіатури, близькість за смислом промахується: модель не розрізняє «АБ-1200» і «АБ-2100».

На практиці режими не замінюють, а доповнюють один одного: гібрид піднімає кілька десятків кандидатів, переранжування залишає 3–5 справді релевантних фрагментів, які йдуть у контекст моделі.

У RAG на ChromaDB це налаштовується на рівні запиту, тому зміна режиму не потребує перезбирання індексу — змінюється лише шар видачі, а не самі дані.

Як ми впроваджуємо RAG: етапи інженерної роботи

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

Без такого набору якість пошуку немає чим обговорювати, і приймання перетворюється на суперечку про смаки. Тому кожен етап закінчується артефактом, який можна перевірити, а не звітом про виконану роботу.

1. Інвентаризація джерел. Позначаємо власника, формат і частоту оновлення кожного документа — від цього залежить розклад перерахунку індексу.
2. Схема конвеєра. До коду малюємо шлях даних: як документ потрапляє в індекс, як ділиться на фрагменти, як оновлюється і як зникає застарілий.
3. Налаштування пошуку. Підбираємо модель ембедингів, розмір фрагмента та гібридну видачу — вектор разом із пошуком за ключовими словами. Нерелевантні фрагменти відсікаємо, інакше модель відповідає за шумом.
4. Генерація та цитування. Збираємо контекст і вводимо правило: відповідь посилається на вихідний документ, а за низької впевненості система честно каже, що даних немає.
5. Перевірка на контрольних запитаннях. Рахуємо частку правильних відповідей і частку вигадок; розбиття на фрагменти та формулювання підказок змінюємо, доки метрики не вийдуть на ціль.
6. Приймання рішення та передача в експлуатацію. Фіксуємо метрики, віддаємо команді схему, налаштування векторного сховища на ChromaDB і регламент оновлення. Черговий уміє дивитися логи та якість видачі.

Склад постачання: конфігурації, схеми конвеєра, регламенти

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

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

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

Такий пакет знімає залежність від підрядника: систему можна розвивати, перевіряти й передавати всередині команди, не відновлюючи логіку за кодом.

Кейс: пошук за базою знань для служби підтримки

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

На першій лінії це давало 4–6 хвилин на пошук відповіді, близько 40% відповідей ішли без опори на джерело, а спірні випадки ескалювалися на другу лінію — там накопичувалася третина звернень.

Що зробили

Зібрали пошуковий контур на ChromaDB: документи нарізали на фрагменти з перекриттям у 10–15% довжини, щоб відповідь не рвалася на межі смислу, і проіндексували.

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

У видачу жорстко вшито посилання на вихідний фрагмент: оператор відкриває першоджерело й звіряє формулювання, а не довіряє моделі на слово.

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

Що вийшло

• Час пошуку відповіді: 4–6 хвилин → 25–40 секунд.
• Частка відповідей з опорою на джерело: 40% → 92%.
• Звернення на другу лінію: мінус 35%.
• Питання, закриті на першій лінії без ескалації: 78%.

Частина звернень усе одно йде на другу лінію — це нетипові інциденти, де рішення ухвалює інженер. Але оператор приходить туди зі знайденими джерелами та чернеткою відповіді, і друга лінія витрачає час на рішення, а не на листування.

Чим відрізняється RAG від дообучення моделі

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

RAG вирішує ту саму задачу інакше: зовнішні документи лежать у сховищі, і на кожен запит система дістає релевантні фрагменти та передає їх моделі разом із запитанням.

Звідси різниця в оновленні знань. У пошуковому контурі достатньо завантажити змінені документи й перерахувати індекси — правка в регламенті або інструкції опиняється у відповідях того ж дня, без зупинки сервісу.

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

Дообучення виправдане, коли змінювати потрібно не факти, а поведінку: тримати стиль і структуру відповіді, впевнено працювати у вузькій термінології, виконувати однотипну задачу — класифікацію, вилучення полів, розбір звернень за рубриками.

RAG або дообучення обирають і за вимогами до перевірюваності: у пошуковому контурі видно, з якого фрагмента зібрано відповідь, і посилання на джерело можна перевірити без розбору ваг.

На практиці частіше працює зв'язка: модель дообучають на форматі та предметній області, а знання тримають у ChromaDB і оновлюють індексацію при кожній правці документів.

Тоді частка відповідей із посиланням на джерело зростає, а строк оновлення знань вимірюється годинами, а не циклами перенавчання.

Технічні сумніви: якість, дані, доступ

Перед стартом майже завжди спливають ті самі п'ять запитань. Нижче — короткі відповіді по суті: саме вони визначають, чи буде система приносити користь, чи залишиться демонстрацією.

Як оновлюється база знань?

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

Права доступу дотримуються?

Фільтр прав застосовується до ранжування: пошук бачить лише доступні співробітнику фрагменти, тому закритий розділ не може потрапити у відповідь. У журналах залишається, які фрагменти використано.

Що якщо знадобиться змінити сховище?

Шар доступу відокремлено від сховища: вектори та описи вивантажуються, схема метаданих зберігається. Переїзд стає плановою операцією, а не новим проєктом.

Чи можна відкотити невдале оновлення?

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

Обговоримо вашу задачу: з чого почнемо роботу

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

Щоб обговорити задачу предметно й повернутися з оцінкою та планом робіт, нам потрібен від вас такий мінімум вихідних даних:

• Корпус документів у вихідних форматах — вивантаження за характерний період, а не одна «показова» папка: на п'яти файлах не можна перевірити, як пошук поводиться на дублях і суперечностях між версіями регламенту.
• Частота оновлення та власник даних — оновлення раз на квартал вручну або постійний потік із внутрішньої системи: від цього залежить, робимо ми разове завантаження чи регулярну переіндексацію з видаленням застарілого.
• Права доступу: хто які розділи має право бачити й чи потрібно фільтрувати видачу за підрозділами або ролями. Це впливає на схему зберігання та на те, де саме застосовується фільтр.
• 15–30 реальних запитань користувачів з очікуваними відповідями та зазначенням джерела — на цій вибірці ми фіксуємо критерій приймання й міряємо якість, а не сперечаємося про неї на демо.
• Точки вбудовування та обмеження контуру: куди пошук віддає відповідь (чат, внутрішній портал, робоче місце оператора), чи допустимий вихід даних у зовнішні сервіси або все має працювати в закритому контурі.
• Поточні труднощі в цифрах: скільки часу йде на пошук відповіді зараз, яка частка звернень залишається без відповіді, які помилки повторюються найчастіше.
• Критерій готовності: частка запитань, на які відповідь знайдено й підтверджено посиланням на документ, і допустимий час відповіді.

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