Розробка RAG з векторною базою даних Qdrant

Чому RAG Qdrant помиляється на вузьких запитах

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

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

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

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

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

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

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

Що змінюється після впровадження RAG Qdrant

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

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

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

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

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

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

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

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

Способи організації пошуку: порівняння підходів

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

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

У Qdrant ці режими працюють на одному індексі, тому комбінувати їх можна без другого сховища.

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

Етапи впровадження: від аудиту до передачі

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

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

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

Документація та артефакти на виході

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

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

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

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

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

На одне питання йшло 12–15 хвилин, а частка помилкових відповідей сягала третини: людина або брала скасовану редакцію, або не знаходила потрібний пункт і відповідала з пам'яті.

Що змінили

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

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

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

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

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

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

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

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

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

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

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

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

Технічні сумніви та часті питання

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

Корпус оновлюється щотижня — видача не поїде?

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

Чи можна розгорнути все в закритому контурі?

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

Що буде при кратному зростанні обсягу документів?

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

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

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

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

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

Далі ми повертаємося з пакетом, за яким можна ухвалювати рішення, а не з презентацією ідеї:

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