Розробка RAG з векторною базою даних Milvus — досвід і кейси

RAG Milvus: чому пошук за документами видає нерелевантні відповіді

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Час відповіді при зростанні бази поводиться нелінійно, якщо не керувати індексом. На Milvus ми розносимо колекції за призначенням, тримаємо параметри пошуку за сегментами і перебудовуємо індекс за розкладом, а не в момент релізу.

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

Стійкість до переформулювання — окрема метрика, яку замовники зазвичай не перевіряють до запуску.

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

Ми вимірюємо це часткою збіжних верхніх результатів за перефразуваннями — вона тримається вище дев'яноста відсотків.

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

Варіанти побудови пошуку по базі знань: порівняння підходів

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

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

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

Індексація бази знань у будь-якому варіанті починається з нарізки документів на фрагменти та метаданих: джерело, версія, права доступу. Схему перевіряємо на реальних запитах — яка частка потрібних документів потрапляє в топ-5 і як часто правильної відповіді немає взагалі.

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

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

Впровадження починається не з коду, а з інвентаризації знань.

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

1. Аудит джерел даних. Збираємо перелік систем, формати файлів, права доступу, дублі та версії. Окремо фіксуємо, як часто документи змінюються і що робити із застарілими редакціями — інакше пошук буде повертати скасовані накази та старі регламенти.
2. Схема індексації документів. Визначаємо правила розбиття на фрагменти та перекриття між ними, склад метаданих (підрозділ, тип, дата, гриф доступу) і модель векторизації під мову корпусу. На цьому кроці закладаємо фільтрацію за ролями: співробітник отримує лише ті документи, до яких у нього є доступ.
3. Збирання векторного сховища на Milvus. Розмічаємо колекції, вмикаємо версіонування та окремий контур для завантаження оновлень, щоб переіндексація не зупиняла пошук. Так регламент, змінений уранці, потрапляє у видачу без простою сервісу.
4. Налаштування пошуку. Збираємо гібридну видачу: близькість векторів плюс фільтри за метаданими та переранжування. Задаємо поріг відсікання — якщо відповідних фрагментів немає, система чесно повідомляє про це замість відповіді за здогадом.
5. Приймання на контрольних питаннях. Готуємо набір еталонних пар «питання — правильне джерело» разом з вашими експертами і вимірюємо попадання в джерело та повноту відповіді. Промахи розбираємо: частина закривається зміною розбиття, частина — доопрацюванням метаданих.
6. Передача та супровід. Віддаємо регламент оновлення індексу, дашборд якості та порядок дій при появі нового джерела знань.

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

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

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

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

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

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

Кейс: як скоротили частку нерелевантних відповідей утричі

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

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

На старті частка нерелевантних відповідей трималася на рівні 21%, а в третині випадків посилання вело на скасовану редакцію: чернетки й затверджені версії лежали в одній колекції, фрагменти сусідніх доменів перекривалися за сенсом. Користувачі переставали відкривати посилання й поверталися до ручного пошуку по папках.

Що перебудували

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

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

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

Метрики до та після

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

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

Чим відрізняється RAG Milvus від звичайного пошуку за ключовими словами?

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

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

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

Формулювання може взагалі не збігатися з текстом документа — важлива тема, а не буквальний збіг лексем.

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

Ключова відмінність проявляється в результаті. Пошук за словами віддає список посилань, і людина сама читає, порівнює та синтезує висновок.

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

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

Технічні сумніви: обмеження, ризики та контроль якості

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

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

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

Як розмежовуються права доступу до розділів?

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

Як часто оновлюється індекс?

Інкрементальна переіндексація йде за подіями зміни документа, повне перезбирання — за розкладом. Скасовані версії видаляються, щоб пошук не видавав застарілий пункт.

Що з вихідними документами і що після передачі?

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

Обговоримо задачу: склад робіт і що потрібно від вас

Щоб оцінка RAG-рішення та план робіт спиралися на факти, а не на здогади, на першій розмові потрібен мінімальний набір вхідних даних.

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

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

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

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