Гібридний пошук для корпоративного RAG: однієї щільності недостатньо

Пошук у корпоративних системах — кілька проблем під одним полем пошуку

Якщо запитати, як RAG здійснює пошук, часто чується: вбудовування запиту, найближчі сусіди, top-k. Це є щільний пошук. Він ефективний для запитів у парафразованій формі порівняно з прозовими текстами. Однак він невдалий у дорогих та передбачуваних ситуаціях під час щоденних корпоративних запитів, які потребують точних ідентифікаторів, рідкісних кодів чи структурованих пошуків.

Комбінація бізнес-завдань

Запити, пов’язані з процесами ескалації, вимагають семантичної відповідності. “Пункт 14.3(b)” потребує точного пошуку. “Характеристики з’єднувача XC-4421-B” вимагають точних записів. “Помилка 0x8A4F” потребує наявності ключових слів. Щільний пошук добре справляється з першим випадком, але погано — з рештою. При таких темпах роботи корпоративних систем використання лише щільного пошуку — це не виняткова проблема, а звичайна ситуація невдалих пошуків.

Де зазнає невдач щільний пошук

Ембеддинги відображають значення. Рідкісні внутрішні коди, посилання на регуляторні документи та ідентифікатори акцій часто знаходяться у погано навчених областях простору. Запити з точним ідентифікатором повертають „семантично близький“ шум. Невідповідність словникового запасу („підвищення заробітної плати“ проти „корекція винагороди“) все ще завдає проблем, коли парами доменів було мало під час навчання. Пошук фактів з високою точністю може виявити неправильний сусідній підрозділ.

Де BM25 досягає успіху та де зазнає невдач

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

Чому гібридний підхід є стандартом

Гібридні підходи працюють як у щільному, так і в розрідженому режимах — ідеально паралельно — а потім об’єднують рейтинги (RRF чи зважене об’єднання). Щільний режим охоплює парафрази; розріджений — ідентифікатори; об’єднання компенсує обидва види невдач. Послідовна робота спочатку в щільному, потім у розрідженому режимі призводить до затримок; необхідно використовувати паралелізацію:

# Parallel retrieval - the right pattern
dense_results, sparse_results = await asyncio.gather(
    dense_retriever.search(query_embedding, top_k=50),
    sparse_retriever.search(query_text, top_k=50)
)

# NOT sequential - this wastes latency
dense_results = await dense_retriever.search(query_embedding, top_k=50)
sparse_results = await sparse_retriever.search(query_text, top_k=50)

Ескіз повної архітектури

Шар ШІ: розуміння запиту (виявлення токенів, схожих на ідентифікатори), паралельні механізми пошуку, об’єднання результатів, необов’язкові пристрої переранжування, пакетування посилань.

Бекенд: сервіс пошуку на базі FastAPI (або подібного) з таймаутами, фільтрами для користувачів та флагами функцій для окремого вимкнення розрідженого/щільного режиму під час інцидентів.

Інфраструктура: подвійні індекси — векторні (HNSW/IVF) та зворотні — які підтримуються в синхронності під час запису даних; однакові ідентифікатори документів у всіх сховищах.

API: стабільна схема відповідей із каналами оцінок (dense_score, sparse_score, fused_score) для дебаггінгу.

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

Оцінка

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

Компроміси

Гібридний підхід вимагає більше ресурсів CPU/IO та ускладнює синхронізацію. Погані параметри об’єднання даних можуть затуманити обидва сигнали. Оператори повинні стежити за затримкою індексування між інвертованими та векторними базами даних. Проте для компаній із змішаною таксономією запитів гібридний підхід є дешевшим, ніж неправильні відповіді.

Висновки архітектора

Не використовуйте лише щільний пошук, оскільки це робив урок. Виявляйте запити з великою кількістю ідентифікаторів. Паралелізуйте механізми пошуку. Оцінюйте результати за класом запиту. Зберігайте фільтри оренди в обох індексах. Розглядайте коефіцієнти фузії як параметри продукту з використанням онлайн-експериментів.

Більш глибокі приклади невдач

Команда з контролю дотримання правил запитувала ідентифікатори пунктів та отримувала детальні абзаци з сусідніх розділів. Довіра зникла швидше, ніж при порушенні будь-яких термінів виконання. Інша команда використовувала журнали подій, де мали значення коди помилок; щільний пошук повертав „схожі помилки“, що змушувало інженерів звертатися до неправильних посібників. Пошук лише з розрідженими даними раніше призводив до того, що керівники ставили нечіткі стратегічні запитання. Гібридний підхід став компромісом, який дозволив обом групам досягти успіху без створення двох окремих продуктів.

Дисципліна при надходженні даних

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

Операції

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

Заключення

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

Механізми щільного пошуку без ілюзій

Запити та фрагменти тексту перетворюються на вектори; індекси типу ANN повертають сусідні елементи. Стійкість до перефразувань є реальною. Так само існують систематичні слабкі місця щодо токенів, яких простір ембеддингів ніколи не опанував належним чином. Компанії постійно створюють такі токени — SKU, ідентифікатори клозу, назви внутрішніх сервісів.

Механізми пошуку з розрідженим доступом без ностальгії

BM25 — це не „старий пошук“. Це скоригована стратегія, заснована на рідкісності термінів. Коли потреба користувача є буквально рядком тексту, ця стратегія працює ефективно. Коли потреба є концептуальною, вона провалюється. Гібридний підхід є оптимальним рішенням.

Варіанти фузії даних

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

Паралелізм та затримка обробки даних

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

Синхронізація та видалення індексу

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

Безпека та конфігурації користувачів

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

Сигнали довіри для фронтенду

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

План впровадження

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

Розширені висновки

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

Сценарії, які переконують у необхідності фінансування

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

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

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

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

Тиждень 1: впровадження BM25 поруч із існуючими векторами у зразковому корпусі даних; офлайн-оцінка за класами. Тиждень 2: паралельний API з RRF; аналіз трафіку. Тиждень 3: порівняння заявок на усунення проблем із позначкою „неправильний документ“. Тиждень 4: стандартна гібридна модель для клієнтів у продакшені з найвищими показниками точного ідентифікування. Зберігати окремий варіант лише для корпусів, де переважає парафразування.

Часткове розділення та цілісність ідентифікаторів

Зберігати токени коду, номери речень та SKU всередині частин документів. Додавати поля метаданих, які копіюють ці ідентифікатори для структурованих фільтрів. Відхиляти документи, у яких критичні ідентифікатори знаходяться лише у зображеннях, якщо не було виконано OCR. Гібридна модель не може відновити те, що було знищено під час обробки даних.

Ранжувальні алгоритми та об’єднання даних

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

Багатомовні та синонімічні примітки

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

Управління

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

Розширений чек-лист архітектора

• Двоє індексів, одна версія вхідних даних
• Паралельний пошук із термінами виконання
• Об’єднання з урахуванням класу
• Розділення систем перед об’єднанням
• Інтерфейс для відлагодження з показниками каналів
• Частини даних для оцінки, які не можна усереднювати
• Синхронізація цілей якості для видалення/оновлення

Інструкції для режимів зниженої продуктивності „sparse down“ та „vector down“

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

Заключні міркування

Щільний пошук сприяв популяризації технології RAG. Однак реалії корпоративних запитів змушують знижувати його статус з „основного інструменту“ до „окремого компонента“. Розріджений пошук стає рівноправним інструментом, а не залишком минулого. Гібридний пошук — паралельний, об’єднаний та оцінюваний за категоріями — дозволяє зберігати точність результатів, коли бізнес у один і той самий день запитує як „який настрій передбачений цією політикою“, так і „що сказано у пункті 14.3(b)“.

Додаткова інформація для фахівців

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

Вимірюйте затримку p95 окремо для щільних, розріджених даних та результатів об’єднання фьюжну. Також окремо враховуйте показники похибок бюджету. Здорова система демонструє взаємодоповнювальні переваги: розріджені дані ефективні для ідентифікаторів, щільні — для парафраз, а фьюжн — у цілому. Якщо фьюжн програє як щільним, так і розрідженим даним, ваш процес об’єднання несправний.

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

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

Вимірювання успіху без марних середніх значень

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

Вибір постачальників та технологій

OpenSearch/Elasticsearch, Typesense чи спеціалізовані розріджені двигуни можуть забезпечувати алгоритм BM25; Qdrant/Pinecone/pgvector — щільні формати. Деякі платформи пропонують гібридні варіанти в одному продукті — перевірте фільтри та можливості пояснення результатів перед тим, як обирати лише одного постачальника. Портабельність має велике значення у разі змін у процесі закупівель.

Зворотний зв’язок від даних навчання

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

Імітація збоїв

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

Люди та процеси

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

Короткий огляд на одній сторінці

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

Більше практичних порад щодо складних випадків фузії

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

Списки синонімів допомагають алгоритму sparse у роботі з термінами на кшталт „автомобіль“, але вони стають марними без контексту. Для регульованих словників краще використовувати ретельно підібрані списки; для відкритих формулювань — алгоритм dense. Гібридний підхід дозволяє призначати кожну технологію саме для вирішення конкретної проблеми, замість того щоб щодня під час аудиту змушувати один інструмент виконувати всі завдання, поки реальні користувачі чекають у черзі запитів, яка не спить навіть між регіонами.

Вимірювання успіху без марних середніх значень

Загальний показник recall@10 може приховати катастрофу у запитах з точним ідентифікатором, якщо у наборі даних для оцінки переважають семантичні запити. Необхідно враховувати склад трафіку у продакшені під час оцінки, або постійно публікувати чотири числа. Менеджери продуктів краще розуміють поняття „успішний пошук за клозулею“ порівняно з „середнім оберненим рангом“.

Вибір постачальника та технологій

OpenSearch/Elasticsearch, Typesense чи спеціалізовані розріджені двигуни можуть забезпечити підтримку алгоритму BM25; Qdrant/Pinecone/pgvector — щільні алгоритми. Деякі платформи пропонують гібридні рішення в одному продукті — перевіряйте фільтри та можливості пояснення результатів перед тим, як обирати лише одного постачальника. Портабельність має велике значення у разі змін у процесі закупівель.

Зворотний зв’язок від даних навчання

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

Імітація збоїв

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

Люди та процеси

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

Короткий огляд на одній сторінці

Enterprise RAG зазнає невдачі, коли вдає, що одна теорія пошуку покриває всі форми запитань. Щільні та розріджені дані поводяться по-різному; гібридний підхід у поєднанні з фузією, що враховує класи, та об’єктивною оцінкою відповідає реальному поєднанню. Створіть індекси, сервіс, API, візуальні підказки та режими зниженої продуктивності як єдину систему. Тоді поле пошуку перестане бути демо-версією та стане інфраструктурою, на яку інвестують ресурси.

Більше практичних рекомендацій щодо складних випадків фузії

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

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