RAG OpenSearch: чому пошук у базі знань видає не те
Асистент із бази знань відповідає впевнено й по суті — але не на те питання. Користувач питає, як оформити повернення при браку, а отримує регламент гарантійного ремонту: слова збіглися, а сенс запиту залишився за кадром.
Недоречні відповіді асистента дорожчі за явну помилку — за правдоподібною інструкцією починають діяти.
Причина зазвичай одна: шар пошуку зібраний як надбудова над повнотекстовим індексом. Лексичне ранжування за частотою термінів не знає синонімів, перефразувань і внутрішнього жаргону.
Якщо в базі написано «дефект при прийманні», а питають «прийшло бите» — пошук у базі знань не знаходить потрібний пункт, хоча він лежить поруч. Генератор тут не винен: він переказує те, що йому передали.
Вузьке місце шару пошуку видно за вимірами: частка запитів, де правильний фрагмент потрапляє в топ-5, виявляється вдвічі нижчою за очікувану.
Чим більше в базі схожих за формулюваннями документів, тим сильніше просідає якість видачі RAG — знаходиться сусідня тема, і відповідь звучить зв'язно, але мимо.
Закривається це не заміною моделі, а перебудовою пошуку: векторне подання запиту й документів, гібридна видача, де лексика й сенс складаються, відсікання нерелевантних фрагментів моделлю переранжування, розбиття документів із перекриттям. Розбираємо, як це працює в OpenSearch і що дає на живій базі знань.
Що дає керований шар пошуку над базою знань
Керований шар пошуку — це набір налаштувань, а не «магія моделі». Ми задаємо, які поля індексуються і з якими вагами, як нарізається база знань, як будується векторне подання фрагментів і що саме потрапляє в контекст відповіді.
Тому точність видачі стає вимірюваною величиною, якою можна керувати, а не удачею від формулювання питання.
В основі — OpenSearch у режимі гібридного пошуку: лексична частина ловить точні терміни, артикули й абревіатури, векторна — смислові перефразування. Поверх працює переранжування кандидатів і поріг відсікання слабких збігів, щоб у контекст не потрапляло сміття.
На контрольній вибірці реальних питань частка релевантних відповідей піднімається з 55–60% до 85–90%.
Окремо закриваємо стійкість до формулювань: синоніми, одруки, інший порядок слів і питання «своїми словами» більше не вибивають пошук із колії.
Це знімає цілий клас відмов, коли система впевнено відповідає не за тим фрагментом бази знань — помилка тим небезпечніша, що зовні виглядає правдоподібно.
Час відгуку пошуку тримаємо в межах часток секунди на етапі відбору кандидатів; основну затримку дає генерація відповіді, її обмежуємо окремо.
Виміри ведемо на фіксованому наборі питань з еталонними відповідями, тому після кожної правки налаштувань видно, що саме змінилося — у точності, у швидкості та в частці покритих сценаріїв.
Режими пошуку в RAG OpenSearch: що вибрати
Режим видачі вирішує, чи знайдеться потрібний фрагмент, коли формулювання питання не збігається з текстом документа. Лексичний пошук за інвертованим індексом упевнено ловить артикули, абревіатури й точні формулювання, але програє на перефразуваннях.
Векторний індекс знаходить збіги за сенсом, зате плутається в числах і кодах. На практиці вибір зводиться до чотирьох варіантів.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Лексичний пошук | Артикули, коди, абревіатури, точні терміни в запиті | Не знаходить синонімів і перефразувань, повнота падає на розмовних питаннях |
| Векторний індекс | Питання своїми словами, розмовні формулювання, різномовний корпус | Слабо розрізняє числа й рідкісні позначення, переіндексація при зміні моделі ембедингів |
| Гібридний пошук | Змішані запити, де є і сенс, і точний термін | Потрібна підібрана вага при злитті: при перекосі втрачається одна з сильних сторін |
| Гібрид і переранжування результатів | Високі вимоги до точності перших трьох-п'яти фрагментів, корпус обмежений | Додає час на кожен запит, потребує окремої моделі та ресурсів під неї |
Усі чотири режими працюють на одній колекції документів: в OpenSearch лексичний і векторний пошук збираються поверх одного індексу, тому перемикання — питання налаштування запиту, а не перебудови сховища.
Переіндексація потрібна лише при зміні моделі ембедингів — план міграції закладаємо заздалегідь. Гібрид не вмикаємо за замовчуванням: вимірюємо на реальних питаннях, який режим дає правильний фрагмент у топ-5, і вже після цього фіксуємо вагу гілок і необхідність переранжування.
Етапи впровадження: від аудиту корпусу до передачі
Впровадження пошуку за документами починається не з налаштування рушія, а з розбору корпусу: поки неясно, що лежить у джерелах і як пов'язані версії, будь-яка конфігурація індексу — вгадування.
Нижче — порядок робіт; частина етапів іде паралельно, якщо це не заважає перевірюваності результату.
- Аудит і розмітка корпусу. Зводимо джерела, дивимося формати, дублікати, версійність. Розмічаємо фрагменти — текст, таблиці, вкладення — і поля-фільтри: тип документа, підрозділ, дата редакції.
- Контрольний набір питань. З вашою командою збираємо реальні питання з еталонними відповідями та джерелами. Набір фіксуємо: він слугує міркою якості до кінця робіт.
- Схема індексів. Вирішуємо, що і якими порціями потрапляє в індекс, які поля працюють у векторному й текстовому пошуку і як складається гібридне ранжування.
- Налаштування пошуку. Підбираємо модель ембедингів під мову корпусу, розмір фрагмента, перекриття й ваги гібрида — спочатку на вибірці, потім на всьому масиві.
- Перевірка на контрольних питаннях. Рахуємо, як часто правильне джерело потрапляє у верхні позиції, і розкладаємо промахи за причинами: розбиття, застаріла редакція, питання поза корпусом.
- Коригування й передача. Правимо розбиття, метадані та фільтри до стабілізації показників, потім віддаємо конфігурації індексу, регламент оновлення, скрипти вимірів і документацію вашим інженерам.
Як закривається кожен етап
Етап вважається завершеним, коли є перевірюваний артефакт: розмітка, набір питань, схема індексів, звіт вимірів. Тому робота системи далі не залежить від того, хто саме з нашого боку її вів.
Комплект постачання: індекси, схеми, регламенти оновлення
Контур залишається працездатним без нас: усе, що налаштовується під час розробки RAG на OpenSearch, передається у вигляді відтворюваних артефактів.
Інженери замовника можуть підняти копію пошуку, підключити нове джерело або змінити правила доступу, не розбираючи чужу конфігурацію за логами. У постачання входить таке.
- Опис індексів: мапінги текстових і векторних полів, розмірність подань, аналізатори, кількість сегментів і реплік — із поясненням, чому вибрано саме такі значення.
- Правила розбиття документів на фрагменти: розмір вікна, перекриття, обробка таблиць і заголовків, щоб фрагмент зберігав сенс і посилання на вихідний документ.
- Схема гібридного пошуку: внесок лексичної та векторної складових, порядок об'єднання й уточнювального ранжування результатів.
- Набір перевірних запитів: еталонні питання з очікуваними документами, щоб після будь-якої правки бачити, чи не просіла видача.
- Налаштування прав доступу до документів: як мітки конфіденційності та групи користувачів потрапляють в індекс і як фільтр застосовується в момент пошуку, не пропускаючи зайвого.
- Регламент оновлення бази знань: інкрементальна переіндексація змінених файлів, розклад повного перезбору, обробка видалень і старих редакцій.
- Інструкції для підтримки: читання логів пошуку, дії при падінні якості відповідей, відкат до попередньої схеми індексу.
Цього достатньо, щоб команда замовника розвивала рішення самостійно, а ми підключалися точково — на розширенні або складних змінах.
Кейс: база знань підтримки, метрики до і після
База знань підтримки жила на лексичному пошуку: запит розбивався на слова, збіги шукалися за точними формами. Живі формулювання це ламали — «не надходить лист» і «немає сповіщень на пошту» йшли в різні результати, синоніми й одруки не оброблялися взагалі.
Метрики знімали на одній і тій самій вибірці: 200 реальних звернень з еталонними статтями. Перевірка на контрольних питаннях дала базу: потрібний документ у перших трьох результатах — 41%, ескалація на другу лінію — 38%, середній час до відповіді — близько 9 хвилин.
Що змінили
Пошук перевели на OpenSearch у гібридному режимі: лексичний збіг плюс векторні подання фрагментів, результати двох гілок об'єднуються й переранжовуються. Статті нарізали на фрагменти з перекриттям і приписали метадані — продукт, мова, тип статті, статус актуальності. Фільтр за продуктом спрацьовує до ранжування, щоб не спливали відповіді за чужою лінійкою.
Що стало
Той самий набір контрольних питань прогнали повторно: потрапляння в перші три — 87%, ескалації — 14%, час до відповіді — 2,5 хвилини.
Додалася відмова від хибних збігів: якщо відповідної статті в базі немає, система віддає порожній результат із позначкою, а не першу-ліпшу інструкцію.
Розбір помилок після прогону показав, де покриття бази неповне: частина питань пішла в чергу на написання статей, а не на доопрацювання пошуку.
Чим гібридний пошук відрізняється від чистого векторного
Чистий векторний пошук переводить запит у числове подання й дістає найближчі за сенсом фрагменти.
Перефразування й питання своїми словами він відпрацьовує впевнено, але лексику втрачає: артикул, шифр деталі або код помилки розчиняються в усередненому векторі, і у видачі опиняються документи про ту саму тему, але не ті.
Лексичний пошук працює навпаки: порівнює терми й знаходить точні збіги, зате провалюється, коли формулювання питання не збігається з формулюванням у документі.
Гібридний режим запускає обидва запити по одному індексу й об'єднує видачі — залишаються і смислова близькість, і потрапляння за точним позначенням.
Оцінки двох режимів не складаються напряму: шкали в них різні.
Позиції з обох списків перераховуються в єдиний рейтинг, ваги режимів задаються під корпус, а для полів із кодами й назвами моделей додаються підвищувальні коефіцієнти, щоб точний збіг піднімався вище за смислове сусідство.
На коротких запитах в одне-два слова вектор шумить, на вузькоспеціальних із абревіатурами й дефісами витягує лексика, на довгих природних формулюваннях сильніший вектор. Гібрид не вибирає переможця заздалегідь — він тримає обидва сигнали.
Окрема робота — розбір рядка: код не повинен розрізатися по дефісу й втрачати регістр, інакше точний пошук перестає знаходити документ.
Часті технічні сумніви перед стартом
Інженерні сумніви перед стартом рідко про те, «чи спрацює пошук взагалі» — вони про експлуатацію: скільки чекати відповіді, що робити при оновленні корпусу, як не видати п'ять копій одного абзацу і чи можна потім змінити модель. Нижче — відповіді на рівні реалізації.
Наскільки гібридний пошук збільшить затримку відповіді?
Гібрид — це векторний і лексичний проходи по індексу з об'єднанням видачі, тому сам пошук займає невелику частку загального часу відповіді.
Основний час іде на генерацію, і він залежить не від розміру корпусу, а від обсягу контексту: ми фіксуємо, скільки фрагментів віддаємо моделі, тому зростання бази знань не подовжує відповідь.
Затримку вимірюємо поетапно — пошук, переранжування, генерація — і оптимізуємо ту ділянку, яка реально просідає.
Як відсікти дублі документів і повторювані фрагменти?
Причина зазвичай у підготовці корпусу: один текст лежить у кількох файлах або фрагменти нарізані з великим перекриттям.
На завантаженні рахуємо відбиток вмісту й відкидаємо повтори, формати приводимо до єдиного вигляду, а перекриття задаємо так, щоб сусідні частини не конкурували між собою. У контекст моделі йде один найкращий фрагмент на джерело, а не всі схожі.
Чи потрібна повна переіндексація при кожному оновленні корпусу?
Ні. Кожен фрагмент зберігається з ідентифікатором джерела, тому при правці документа переіндексовуються лише його частини, а видалене закривається позначкою, що виключає фрагмент із видачі.
Повний перезбір потрібен, якщо змінилася модель векторизації або логіка нарізки: його виконуємо у фоні, в окремій версії індексу, і перемикаємо трафік, коли нова версія перевірена на контрольному наборі. Пошук у цей час залишається доступним.
Чи можна замінити модель, не переробляючи пошук?
Індекс зберігає векторні подання тексту, а пошук віддає готові фрагменти в будь-яку модель через єдиний інтерфейс — шари розділені. Зміна генеративної моделі перезбору не потребує: достатньо прогнати контрольний набір питань і порівняти відповіді.
А ось зміна моделі векторизації означає інший простір ознак — старі вектори з новими непорівнянні, тут перезбір неминучий, і його планують заздалегідь, як окремий етап.
Обговоримо задачу: що надіслати для оцінки
Оцінка пошукового рішення тримається на двох речах — реальному корпусі та реальних запитах. Частину даних зберемо на першому етапі разом з вашою командою, але чим більше вихідних даних, тим менше припущень в архітектурі RAG на OpenSearch і тим точніші строки.
- Корпус документів або вивантаження: формати (PDF, DOCX, таблиці, база знань), обсяг, мови, частка сканів — від цього залежить розбиття на фрагменти й розпізнавання.
- 50–100 справжніх запитів користувачів у живому формулюванні та очікувані відповіді хоча б на частину — на них вимірюємо якість до початку робіт.
- Розмітка релевантності, якщо велася: які документи вважаються правильним потраплянням. Без неї зберемо метрики на узгодженій вибірці.
- Правила доступу: хто які документи має право бачити, чи є поділ за відділами. Права вбудовуємо в сам запит, інакше з'явиться витік у видачі.
- Як пошук влаштований зараз і на що скаржаться користувачі: запити без відповіді, нерелевантна видача, загублені документи.
- Контур і обмеження: де розгортаємо сервіс, чи допустима передача даних у зовнішні моделі, чи потрібна робота всередині периметра.
- Навантаження й оновлення: скільки запитів на добу, пікові періоди, прийнятний час відповіді, як часто змінюється корпус.
За цим набором повернемося з оцінкою та планом робіт: схема індексації й розбиття, логіка гібрида — лексичний пошук плюс векторний — переранжування, етапи та порядок приймання. Опишіть задачу у вільній формі, уточнювальні питання поставимо одразу.
