Гібридний пошук: коли поєднувати BM25 з векторами

Фірма впроваджує асистента RAG на базі продуктової документації і через тиждень пілоту виявляє проблему: запити з кодами SKU, символами запчастин або внутрішніми назвами систем (наприклад, «модуль INTAKE-3B») повертають семантично схожі, але не потрібні документи. Векторний пошук «розуміє намір», але губить ідентифікатори. Клієнти сервісу отримують опис схожого продукту замість технічної карти конкретного. Це одна з найпоширеніших причин, чому RAG чудово працює на демо і гірше — у продакшені.

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

Три конкретні класи запитів, на яких семантика регулярно дає збій:

Коди та ідентифікатори. SKU-4521, P/N 7742-A, номер замовлення ZAM-2024-08811 — це рядки символів без семантичного контексту. Ембедінг сприймає їх як шум і призначає їм вектори близько до документів із загальною продуктовою тематикою, замість того, щоб повернути документ з точним збігом.

Акроніми та галузеві скорочення. «IFRS 17», «KSeF», «CMMS» — модель може не мати достатнього контексту для рідкісних скорочень, особливо польських, спеціалізованих. Повертає документи про фінанси або системи обслуговування, але не той конкретний стандарт.

Власні назви та версії. «Comarch ERP XL 2024.2.1» vs «Comarch ERP Optima» — для ембедінгу це близькі сусіди. Для користувача це різні продукти. Плутанина версій у відповіді породжує реальні операційні помилки.

BM25 (Best Match 25) вирішує ці випадки інакше: рахує частоту терміна в документі, нормалізує відносно довжини документа і просуває результати, в яких запитані токени буквально зустрілися. Для коду SKU-4521 BM25 повертає документ, що містить цей рядок, на першій позиції. Для загального запитання «як налаштувати інтеграцію?» семантика справляється краще, бо користувач описує намір, а не ідентифікатор.

Reciprocal Rank Fusion — це алгоритм об'єднання рейтингів з незалежних пошукових движків. Формула для результату документа d проста:

RRF(d) = Σ 1 / (k + rank_i(d))

де k — це константа згладжування (за замовчуванням 60), а rank_i(d) — позиція документа в i-му рейтингу. Документ на позиції 1 в обох движках отримує результат 1/(60+1) + 1/(60+1) ≈ 0.033. Документ на позиції 1 у BM25, але 50 у семантиці, отримує 1/61 + 1/110 ≈ 0.025. Фузія винагороджує послідовність: якщо обидва движки погоджуються, що документ релевантний, він потрапляє високо. Якщо лише один його вказує, він все ще має шанс, але з нижчим результатом.

Перевага RRF над зваженою сумою балів: не потрібно нормалізувати результати з BM25 (цілі числа, залежні від корпусу) і cosine similarity (числа [-1, 1]). RRF оперує виключно позиціями, тому масштаби не мають значення. Це особливо важливо для динамічних корпусів, де діапазони результатів BM25 змінюються зі зростанням бази документів.

Після фузії RRF варто додати етап реранкінгу: модель cross-encoder оцінює кожного кандидата в контексті всього запиту. Реранкер покращує точність при складних багатоскладових запитах. Детальніше про архітектуру реранкінгу в статті про якість пошуку RAG.

Впровадження гібридного пошуку в існуючому стеку RAG вимагає кількох точних кроків. Припускаємо Qdrant як векторну базу та Elasticsearch або Postgres з pg_trgm / tsvector як движок BM25.

Крок 1: Індексуй корпус подвійно. Той самий текст потрапляє до векторної бази (ембедінги BGE-M3 або іншої моделі) і до повнотекстового індексу. Обидва індекси повинні використовувати ті самі ідентифікатори документів, щоб фузія могла об'єднати результати за ключем.

Крок 2: Виконай обидва запити паралельно. Для кожного запиту користувача відправ його одночасно до семантичного движка (top-k=50-100 кандидатів) і до BM25 (top-k=50-100). Обмежуй кількість кандидатів, бо реранкер на наступному етапі має обмежений бюджет токенів.

Крок 3: Фузія RRF. Об'єднай два списки кандидатів через RRF. Почни з k=60 (значення за замовчуванням). Якщо запити у твоїй системі переважно лексичні (багато кодів і SKU), знизь k до 20-30, що посилить вплив сильного лідера в одному рейтингу. Експериментуй на golden set з щонайменше 100 запитів із очікуваними відповідями.

Крок 4: Реранкер (опціонально, але рекомендовано). Передай топ-20 з RRF до моделі cross-encoder (наприклад, bge-reranker-v2-m3 локально). Реранкер обчислює пару (запит, фрагмент) і видає точний результат. Затримка зросте на 100-300 мс, але точність при складних запитах покращиться на 10-20 пунктів MAP.

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

Гібрид не безкоштовний. Два запити замість одного, фузія, опціональний реранкер: загальна затримка системи зростає на 80-200 мс (оцінка залежить від апаратного забезпечення та розміру кандидатів). У системах, що вимагають відповіді менше 200 мс end-to-end (наприклад, чат наживо з клієнтом), це може бути забагато.

Не впроваджуй гібрид, коли:

• Корпус однорідний і описовий (наприклад, тільки FAQ розмовною мовою) — чистої семантики достатньо.
• Усі запити мають концептуальний характер, а база не містить ідентифікаторів.
• Маєш менше 1000 документів, і проста семантика дає recall вище 0.9 на golden set.
• Затримка — жорстка вимога, а кешування результатів неможливе.

Хороша практика — виміряти recall@5 і recall@10 окремо для BM25, для семантики та для гібриду на репрезентативному golden set перед ухваленням рішення. Детальніше про побудову golden set і вимірювання якості в статті про оцінку якості RAG.

Не завжди. Якщо вже використовуєш PostgreSQL, можеш запустити BM25 через вбудовані tsvector і ts_rank — без додаткової інфраструктури. Elasticsearch або OpenSearch дають більше опцій тюнінгу (бустинг полів, кастомний токенізатор для кодів продуктів), але для малих і середніх корпусів (до кількох сотень тисяч документів) Postgres BM25 цілком достатньо. Qdrant з версії 1.10 має вбудований sparse vector search (SPLADE), який за функціональністю наближається до BM25.

Через RRF не налаштуєш безпосередньо «вагу» — алгоритм працює з позиціями. Можна регулювати кількість кандидатів з кожного движка (top-k) або застосувати зважену фузію з нормалізацією результатів (linear interpolation), де параметр alpha визначає частку семантики. Почни з alpha=0.5 (рівні частки) і експериментуй на golden set. Типові висновки з впроваджень: при великій кількості кодів і SKU alpha=0.3 (сильніший BM25) покращує результати, при описових текстах alpha=0.7 краще справляється семантика.

Так, за умови використання багатомовної моделі ембедінгів (BGE-M3 підтримує понад 100 мов) і токенізатора BM25, що враховує морфологію мови. Для української важлива лематизація перед індексацією BM25 (наприклад, через Morfologik або Stemmers), бо «замовлень», «замовленню», «замовлення» — це той самий токен після лематизації. Без лематизації recall BM25 падає на 20-40% на українських запитах.

Реранкер особливо цінний при багатоскладових запитах і питаннях, що вимагають розуміння повного контексту (наприклад, «яка процедура повернення товару, купленого в акції у грудні 2024 для клієнтів B2B»). RRF об'єднує рейтинговий сигнал, але не розуміє запит цілісно. Cross-encoder оцінює кожну пару (запит, фрагмент) незалежно і вловлює тонкі збіги. Архітектура семантичного пошуку у компанії детально описує, коли реранкер варто вбудувати в пайплайн.

Побудуй golden set: мінімум 100 запитів з очікуваними документами (можна почати з 50 і розширювати). Виміряй recall@5 (чи потрібний документ у топ-5) і MRR (Mean Reciprocal Rank, наскільки високо з'являється перший релевантний результат). Порівняй три варіанти: BM25 solo, семантика solo, гібрид RRF. У системах зі змішаною технічною лексикою гібрид покращує recall@5 на 15-35% відносно самої семантики. Якщо покращення менше 5%, спочатку перевір якість чанкування — часто проблема саме там. Корисним стартом є аудит сайту та системи, який вкаже вузькі місця перед впровадженням.