RAG Weaviate: чому пошук не знаходить потрібну відповідь
Поки корпоративна база знань невелика, пошук по ній тримається на удачі. Далі починається типова поломка: співробітник запитує про регламент відвантаження, а отримує інструкцію з приймання — слова збіглися, сенс ні.
Після двох-трьох таких відповідей помічника закривають і повертаються до ручного перебору папок на мережевому диску.
Причина майже завжди в підготовці даних, а не в моделі. Документи ріжуть на фрагменти фіксованої довжини, межі потрапляють у середину таблиці, векторні представлення рахуються за «сирим» текстом без метаданих — підрозділу, дати, типу документа.
Векторна база даних чесно віддає найближчі вектори, але найближчий не означає правильний: релевантність видачі задається схемою зберігання та фільтрами, а не розміром індексу.
Другий шар — відбір і переранжування. Без фільтра за терміном дії та підрозділом у відповідь потрапляють скасовані версії, без переранжування — фрагменти, де потрібне слово згадано побіжно.
У Weaviate це закривається схемою колекцій, гібридним пошуком і правилами відбору, але схему проєктують під реальні питання співробітників, а не за замовчуванням.
Розробка RAG тому починається не з вибору моделі, а з інвентаризації корпусу та розмітки метаданих. Втрати тут вимірюються не ліцензіями, а довірою: помічник, що помиляється в третині запитів, перестає використовуватися, і база знань знову стає архівом.
Розбираємо, як це закривається — від нарізки документів до оцінки релевантності видачі на живих формулюваннях.
Що дає керований пошук: швидкість відповіді та повнота видачі
Перший ефект — час до відповіді. Гібридний пошук у Weaviate об’єднує збіг за термінами та близькість за сенсом, тому видача не залежить від того, чи вгадав користувач формулювання.
На прогрітому індексі відповідь збирається за секунди замість хвилин ручного пошуку по папках, чатах і пошті.
Другий — повнота видачі. Фрагменти документів нарізаються з перекриттям, і до кожного прив’язані метадані: підрозділ, дата, рівень доступу.
Завдяки цьому зникає цілий клас відмов «документ є, а пошук його не бачить» — регламент знаходиться за сенсом, навіть якщо в запитанні немає жодного слова з його заголовка.
Третій — навантаження на підтримку. Коли у відповіді є посилання на першоджерело, типові питання закриваються без оператора, а повторні звернення з однієї теми скорочуються: людина отримує відповідь одразу, а не після листування. Частка звернень без ручного втручання — метрика, яку ми виводимо в регулярний звіт.
Четвертий — якість відповідей стає вимірюваною. Ми фіксуємо, які фрагменти потрапили в контекст і чи спирається на них відповідь, і проганяємо зміни бази знань за набором контрольних питань. Так правки в документації не ламають видачу непомітно.
Режими RAG Weaviate: векторний, гібридний, з переранжуванням
Режим пошуку вибирається за складом корпусу та за тим, як користувачі формулюють запит, а не за замовчуванням. Векторний пошук зіставляє сенс: знайде розділ про розірвання договору за фразою «як відмовитися від співпраці», але промахнеться повз артикул або код помилки.
Гібридний пошук додає лексичний збіг за точними термінами й зважує внесок обох каналів — у Weaviate це налаштовувана вага каналів.
| Режим пошуку | Коли підходить | Обмеження |
|---|---|---|
| Векторний | Вільні формулювання, переказ, синоніми, розмовні питання | Не знаходить артикули, коди та рідкісні абревіатури; залежить від якості ембедингів |
| Гібридний (вектор + лексика) | Змішана лексика: регламенти, каталоги, техдокументація з кодами та назвами моделей | Вага каналів підбирається під корпус; ранжування складніше пояснити |
| Гібридний + переранжування | Висока ціна помилки: юридичні та технічні відповіді, довгі багатоскладові запити | Другий етап додає затримку та витрати ресурсів; потрібний фрагмент має потрапити до пулу кандидатів |
Режими не виключають один одного: гібридний пошук розумно тримати базовим, а переранжування вмикати для окремих сценаріїв або лише для довгих запитів.
Вибір фіксуємо вимірюваннями на наборі реальних питань — рахуємо частку запитів, де потрібний фрагмент опинився в перших трьох позиціях, і тільки потім закріплюємо налаштування в продакшені.
Етапи впровадження: від аудиту корпусу до передачі в експлуатацію
Впровадження пошуку ламається не на моделі, а на даних: дублі, застарілі редакції та скани без текстового шару дають найдорожчі помилки у відповідях.
Тому порядок робіт фіксований — спочатку аудит корпусу документів і еталонні питання, потім індексація бази знань і тільки після цього впровадження пошуку в інтерфейс. У команди з’являється вимірюваний критерій приймання замість «наче відповідає правильно».
- Аудит корпусу документів — інвентаризація джерел: формати, власники, термін актуальності, права доступу. Окремо позначаємо дублікати та застарілі редакції.
- Розмітка контрольної вибірки питань — 100–200 реальних питань з правильними відповідями та зазначенням документа-джерела. Вона ж стає тестом приймання.
- Схема зберігання — структура індексу в Weaviate, розмір фрагмента та перекриття, поля для фільтрації за відділами, датами й правами доступу.
- Налаштування індексації бази знань — розпізнавання сканів, нарізка на фрагменти, розрахунок векторів, довантаження лише змінених документів за розкладом.
- Перевірка на контрольній вибірці — частка відповідей з правильним посиланням на джерело та частка коректних відмов, коли даних у корпусі немає. Поріг узгоджуємо заздалегідь.
- Впровадження пошуку в робочий контур — доступи на рівні фрагментів, журнал запитів і джерел, передача регламентів і навчання команди оновлювати корпус без нас.
Комплект передачі: конфігурації, схеми доступу, регламенти
Роботу ми закриваємо не запущеним контуром у робочому середовищі, а комплектом передачі в експлуатацію. За цією документацією ваша команда зможе сама змінювати корпус, додавати сценарії та розбирати інциденти — без звернення до нас за кожним уточненням.
- Описи конфігурацій. Схема колекцій, правила розбиття документів на фрагменти, модель векторизації, поріг релевантності та кількість повернутих фрагментів — з поясненням, чому вибрано саме ці значення і що станеться за їх зміни.
- Схема обробки запиту. Шлях від питання користувача до готової відповіді: де будується вектор, як застосовуються обмеження прав, як збирається контекст і де він обрізається за довжиною.
- Політики доступу за ролями. Які колекції та поля бачить кожна роль і як обмеження накладаються на етапі пошуку, щоб їх не можна було обійти формулюванням питання.
- Регламент оновлення корпусу. Коли перераховуються вектори, що відбувається при видаленні або заміні документа і як перевіряється, що в пошук не потрапили застарілі версії.
- Контрольний набір питань. Еталонні пари «питання — очікуване джерело»: частка влучань за ними вимірюється після кожного оновлення корпусу або зміни моделі, тому просідання якості видно до скарг користувачів.
- Порядок відкату. Як повернути попередній стан пошукового індексу та налаштувань, якщо після оновлення відповіді стали гіршими.
- Розбір звернень. Куди дивитися при скарзі на відповідь: журнали пошуку, збережені контексти, час відгуку на типових запитах.
Комплект залишається у вас у вигляді файлів у репозиторії, а не в листуванні. Опишіть задачу — повернемося з оцінкою та планом, включно зі складом такого комплекту під ваш контур.
Кейс: як зросла точність відповідей у базі знань
Точка старту
База знань служби підтримки — кілька тисяч документів: регламенти, інструкції, розбори інцидентів. Оператор шукав за ключовими словами й вручну гортав видачу, бо формулювання клієнта майже ніколи не збігалося з формулюванням у регламенті.
На розміченій вибірці реальних звернень частка коректних влучань у цільовий документ трималася близько 40%, а пошук відповіді займав 4–6 хвилин — частина звернень на той момент уже переходила на другу лінію.
Що змінили
Документи розбили на фрагменти за смисловими межами, перерахували їхні векторні представлення та склали в Weaviate.
Пошук зробили гібридним: векторна близькість плюс лексичний збіг за термінами й артикулами, з фільтрами за правами доступу та лінійкою продукту, щоб оператор не отримував чужі розділи.
Зверху поставили переранжування — на початок видачі потрапляють фрагменти, з яких дійсно збирається відповідь, а не просто схожі за темою.
Через місяць після викочування точність влучання в потрібний документ зросла з ~40% до 85%, час пошуку відповіді впав до 40–50 секунд разом із читанням знайденого фрагмента. Частка звернень, які оператор закривав сам, без передачі на другу лінію, піднялася з 55% до 80%.
Перевіряли не на показових прикладах, а на відкладеній вибірці закритих звернень із заздалегідь розміченим еталонним документом: рахували влучання в перший і третій результат, окремо розбирали випадки, де документ застарів або суперечить сусідньому.
Цей набір залишився в проєкті як регресійний — перед будь-якою правкою налаштувань пошуку видно, стало краще чи гірше, і відкат параметрів не перетворюється на ворожіння.
Що робити, якщо пошук уже працює на іншому рішенні?
Якщо пошук уже працює, міграція — це не переписування з нуля, а перенесення зі збереженням контракту: ті самі запити, ті самі поля метаданих у відповіді, ті самі права доступу.
Перший крок — інвентаризація корпусу та налаштувань: як документи нарізані на фрагменти, які фільтри беруть участь у запитах, що показує лог звернень. Часто вже тут видно, що частина корпусу не індексувалася взагалі, а перевірка доступів ішла за одним сценарієм.
Далі — перенесення індексу. Weaviate піднімається поряд зі старою системою, індексація йде на копії корпусу, чинний пошук обслуговує користувачів у попередньому режимі.
Ключовий ризик — зміщення векторного простору: якщо моделі побудови векторів не збігаються, перенести їх напряму не можна, потрібна повна переіндексація. Тому версія моделі та правило нарізки фіксуються заздалегідь, інакше видача поїде на межах фрагментів.
Паралельна перевірка йде на контрольному наборі — кілька сотень реальних питань із відомими джерелами-відповідями. Порівнюємо повноту й точність видачі, частку відповідей без опори на документ, час відгуку на довгих запитах.
Окремо проганяємо фільтри за правами доступу та рідкісні формулювання: розбіжності вилазять саме там.
Перемикання робиться без простою: спочатку на новий пошук іде невелика частка трафіку, метрики звіряються на живих запитах, потім частка зростає. Відкат — один перемикач, стара система залишається доступною, поки якість не підтверджено. Так міграція пошуку перестає бути подією з ризиком простою і стає керованим процесом.
Технічні сумніви: нарізка, доступ, оновлення індексу
П’ять питань технічний керівник ставить до старту — і відповіді визначають, чи буде пошук по базі знань точним, чи перетвориться на генератор упевнених помилок.
Універсальних значень немає: розмір фрагмента та правила оновлення залежать від корпусу. Тому спочатку дивимося на реальні документи й питання користувачів, а потім фіксуємо параметри.
Який розмір фрагмента вибрати?
Відштовхуємося від 300–800 токенів із перетином 10–15%: дрібні фрагменти втрачають контекст, великі розмивають релевантність. Значення підбираємо на 50–100 реальних питаннях.
Що робити з таблицями та сканами в документах?
Таблицю зберігаємо окремим фрагментом разом із заголовками рядків і стовпців — інакше числа втрачають сенс. Скани розпізнаємо й перевіряємо на контрольних сторінках: без цього частина корпусу не знаходиться.
Як часто оновлювати індекс?
Інкрементально: порівнюємо хеш документа й переіндексовуємо лише змінене, повне складання — при зміні параметрів. Видалений документ прибираємо з індексу, інакше відповідь іде за застарілою версією.
Як розмежувати права доступу до даних?
Перевірка прав — на етапі пошуку, до генерації: у кожного фрагмента зберігаються метадані про роль і підрозділ. У контекст моделі потрапляє лише дозволене, витік через відповідь виключено.
Як зрозуміти, що рішення стало кращим чи гіршим?
Контрольний набір питань з еталонними відповідями та джерелами проганяємо при кожній зміні параметрів. Дивимося частку влучань у потрібний фрагмент і повноту відповіді — регрес видно до розгортання.
Обговоримо задачу: що підготувати до першої розмови
Перша розмова потрібна не для знайомства, а щоб зафіксувати вихідні дані. Розбір корпусу, класів запитів і обмежень за доступами — те, без чого будь-яка оцінка перетворюється на вилку з подвійним запасом. Нижче — що підготувати, щоб обговорити задачу предметно й одразу перейти до справи.
- Приклади корпусу: кілька сотень реальних документів у тому вигляді, у якому вони живуть зараз — зі сканами, таблицями та вкладеннями, а не вивантажений ідеальний набір.
- 20–50 типових питань користувачів і відповіді, які вважаються правильними — з них збирається перевірний набір для вимірювання релевантності.
- Поточний спосіб пошуку та його слабкі місця: де потрібні фрагменти знаходяться сьогодні, а де видача йде вбік.
- Обмеження щодо доступу: у яких ролей які права, чи потрібно розділяти видачу фрагментів між відділами та клієнтами.
- Вимоги до свіжості: як часто оновлюється корпус і яке відставання індексу від джерела допустиме.
- Мови та формати: змішані документи, рукописні правки, вкладення без текстового шару.
- Критерії приймання: частка питань, на які відповідь цілком міститься у знайдених фрагментах, і поріг, нижче якого рішення не приймається.
- Середовище розміщення: ізольований контур, власник інфраструктури, хто обслуговує розгорнутий пошук після здачі.
Із цим набором ми повертаємося з оцінкою та планом: етапи робіт, склад корпусу під векторизацію, схема перевірного набору, точки приймання. Якщо частину вихідних даних ще не зібрано — обговоримо, що закриваємо на своїй стороні, і зазначимо, що знадобиться від вас.
