Гібридний пошук для RAG: BM25, вектори та поєднання рангів у практиці
Гібридний пошук для RAG: чому пошук лише за векторами втрачає точні ідентифікатори, як Reciprocal Rank Fusion поєднує BM25 з ембеддингами та де гібридний підхід все ще має недоліки.
Джерела: Hybrid Search in RAG — BM25, Vectors, and Reciprocal Rank Fusion in Practice
Додавання пошуку за ключовими словами до системи пошуку, що використовує лише вектори, — це один із найдешевших способів підвищення точності в RAG, і компанія Anthropic перевірила це на власних корпусах даних: використання контекстуального алгоритму BM25 разом із контекстуальними ембеддингами зменшило кількість невдалих результатів у топ-20 на 49 відсотків без змін у самій моделі ембеддингів.
Розгляньмо причину цього показника. Користувач вводить ідентифікатор транспортного засобу, наприклад GX-V5-5N. Система, що використовує лише вектори, повертає загальні інструкції щодо реєстрації та історію обслуговування, а правильний документ відсутній навіть серед перших десяти результатів. Ембеддинги ідеально враховують автомобільний контекст, і саме тому вони ігнорують буквальний рядок. Йдеться не про слабкі ембеддинги — це структурна проблема, яка впливає на будь-яку систему RAG, побудовану виключно на векторах, що є характерним для більшості стандартних навчальних матеріалів.
Нижче: чому поєднання лексичного та векторного пошуку вимагає іншої математики, ніж усереднення оцінок, що робить метод Reciprocal Rank Fusion, де гібридний підхід перестає допомагати та що потрібно вимірювати перед його використанням.
Ідея за дві хвилини
Чистий векторний пошук систематично втрачає точні збіги, такі як коди помилок, ідентифікатори продуктів та власні імена. Ембеддинги не є поганими — семантична близькість та буквальне збіг є просто різними властивостями.
BM25, функція ранжування на основі лексики з 1990-х років, компенсує недоліки векторів. Вона майже безкоштовно виявляє рідкісні, специфічні токени, але водночас пропускає парафрази та синоніми. Обидва методи діють у протилежних напрямках, і саме це є структурною причиною їх поєднання, а не тимчасовою інженерною тенденцією.
Проблема полягає у тому, що їхні результати неможливо додати. Оцінки BM25 є необмеженими та залежать від корпусу даних, тоді як косинусова схожість знаходиться в межах від мінус одиниці до одиниці. Сума 15,3 та 0,82 не має жодного значення. Тому сучасні двигуни не об’єднують оцінки. Вони об’єднують позиції рангу за допомогою методу Reciprocal Rank Fusion.
Проте гібридний підхід не завжди є кращим. Для запитів, заснованих на точних ідентифікаторах, сам BM25 може перевершити всю систему об’єднання оцінок. Важливе питання полягає не у тому, чи використовувати гібридний підхід, а у тому, яка частина ваших запитів насправді його потребує, і це те, що потрібно вимірювати.
Два взаємодоповнюючі сліпі плями
Уявіть двох молодших колег із протилежними слабкостями.
Перший підхід є максимально буквальним, як у Ctrl+F. Якщо запитати про сторінку з кодом помилки ERR_CONNECTION_RESET, він знаходить її миттєво. Якщо ж запитати про проблеми з підключенням, він ігнорує документ про втрату сеансу, оскільки жодне зі слів запиту там не зустрічається.
Другий підхід передбачає розуміння контексту. Він знає, що проблеми з підключенням та втрата сеансу описують одне й те саме. Однак, якщо запитати про точний код помилки, він надає загальний опис мережевих несправностей, адже рідкісний фрагмент тексту загублюється серед загального значення речення.
Жоден з цих підходів сам по собі недостатній. У цьому суть усього аргументу, викладеного у двох абзацах.
Що враховує BM25
BM25 — це не магія і не застарілий інструмент. Він працює на основі зворотного індексу — таблиці, яка веде від кожного слова до документів, що його містять, тож двигун ніколи не сканує всю колекцію. Ранжування ґрунтується на трьох принципах інтуїції:
- Рідкісні терміни мають більшу вагу. Ідентифікатор GX-V5-5N говорить набагато більше, ніж слово «транспортний засіб».
- Повторення призводить до насичення. Десятий випадок вживання слова має значно менший вплив, ніж другий, оскільки крива починає спадати після кількох повторень.
- Довжина тексту є недоліком. Довгі документи не повинні перемагати лише через те, що в них більше можливостей для випадкових збігів.
Векторна модель працює за іншим принципом. Текст перетворюється на список чисел, які кодують значення, а ранжування здійснюється за ступенем близькості в цьому просторі, незалежно від того, чи мають запит та документ спільні слова. Один двигун вимірює охоплення символів, а інший — охоплення значень.
Помилка категорізації, якої варто уникати
Є спокуса розглядати векторний пошук як вдосконалену версію пошуку повного тексту — новішу, розумнішу та природну альтернативу. Це помилка категоризації. Вектори не замінюють лексичний пошук; вони вирішують іншу проблему, тому втрачають ту перевагу, якою безкоштовно володів лексичний пошук.
Якщо корпус містить коди, ідентифікатори чи власні назви, саме вбудовування даних призведе до їх втрати, яким би не був якісний модель. Обмеження походять від того, що представляє вектор. Правильний підхід полягає у визначенні того, які запити потребують певної інтенсивності, що залишає проблему об’єднання двох списків результатів, виміряних у нерелевантних одиницях.
Чому оцінки не можна просто додавати
Природним інстинктом інженерів є нормалізація, надання ваг та додавання. Однак це стикається з фактом, який неможливо усунути шляхом налаштувань.
BM25 не має теоретичного верхнього обмеження. Його результат зростає з кількістю зіставлених термінів запиту, їхньою рідкістю в корпусі та довжиною документа, тому один і той самий документ отримує різні значення після появи десяти тисяч нових файлів. Косинусна схожість, яка порівнює кут між двома векторами, залишається в діапазоні від мінус одиниці до одиниці.
Додавання 15,3 до 0,82 схоже на додавання кілограмів до фунтів без перерахунку: арифметично це можливо, але інформаційно це марно. Можна використовувати нормалізацію типу min-max або z-score, але тоді обидві системи оцінювання потребують перекалібрування щоразу, коли змінюється корпус, модель ембеддингів чи склад запитів. Калібрування, яке доводиться повторювати після кожного реіндексування, є відкладеним боргом.
Голосування за позицію
Метод взаємного злиття рангів уникає цієї проблеми, ігноруючи оцінки. Він бере до уваги лише ранг, який кожен двигун присвоїв документу. Формула проста: злита оцінка документа — це сума для кожного двигуна значення один поділене на (k плюс його ранг у списку цього двигуна). Документ, відсутній у списку, не вносить жодного внеску.
Отже, документ, який знаходиться серед трьох найкращих у обох списках, перевершує документ, який є першим у одному списку, але відсутній у іншому. Метод RRF винагороджує збіг у порядку, а не точність, причому позиція в рангу — це одиниця, яку кожен індексатор створює однаковим чином.
Цей метод був запропонований Кормаком, Кларком та Бюттчером на конференції SIGIR 2009, задовго до появи технології RAG. Їхнє обґрунтування: найвищі ранги мають мати найбільший вплив, нижчі ранги не повинні повністю зникати, а константа k пом’якшує вплив будь-якої окремої системи з незвичайними результатами.
Примітка, яка з’являється під час оглядів дизайну: стандартне значення k у 60 було визначене під час одного пілотного тестування та не коригувалося під час подальшої перевірки. Самі автори описали це як необдуманий вибір. При k=60 рейтинг першого місця на приблизно 1,6 відсотка вищий за рейтинг другого місця, тоді як рейтинг шістдесятого місця становить приблизно половину балів першого місця.
На практиці k є своєрідним регулятором, а не важелем. Важливішим є те, скільки кандидатів надає кожен етап. Якщо векторна частина надає п’ятдесят кандидатів, документ на п’ятдесят першому місці надає рівно нуль балів.
Як гібридний підхід став стандартом
Найбільш точні дані походять з експериментів Anthropic з контекстуальним пошуком у 2024 році на власних наборах даних, під час яких відстежувалося, наскільки часто правильний фрагмент відсутній у першій двадцятці результатів. Самі контекстуальні ембеддинги зменшили кількість випадків відсутності фрагментів на 35 відсотків. Додавання контекстуального алгоритму BM25 дозволило знизити цей показник до 49 відсотків, що означає, що лексичний підхід забезпечив значну частину ефекту від оновлення ембеддингів.
Слід уникнути неправильного тлумачення. У тому ж звіті зазначається зниження на 67 відсотків після додавання функції переранжування, проте переранжування — це окремий етап, який використовує інший клас моделей. Фузія та переранжування не є синонімами, і їх змішування на одному слайді є поширеною помилкою у презентаціях.
Конвергенція серед постачальників говорить більше, ніж будь-який окремий тестувальний маркер. Elasticsearch, OpenSearch, Weaviate, Qdrant та Azure AI Search усі вбудовано підтримують технологію RRF. Гібридний пошук перейшов від статусу розширеної опції до стандартного налаштування.
Вартість другого індексу
Існує певна ціна, яку слід врахувати ще до прийняття рішення, а не після першої проблеми:
- більше місця на диску, кількість якого залежить від конфігурації,
- кілька додаткових мілісекунд на етап об’єднання даних,
- і, що найважливіше, ще один елемент, який може вийти з синхронізації. Якщо документ видаляється з векторного індексу, але залишається в лексичному, він продовжує з’являтися знову та знову, наче привид.
Команди, які вже використовують Postgres, часто можуть отримати перевагу завдяки поєднанню pgvector із вбудованим пошуком повного тексту, що реалізується повністю за допомогою SQL без необхідності створення нової інфраструктури. Якщо поточна система RAG використовує лише векторні індекси, краще запитати, чому в ній відсутній алгоритм BM25 — це питання технічного боргу, а не інновацій.
Де гібридні рішення програють
Єдність думок постачальників може свідчити про те, що гібридний підхід завжди кращий. Однак прямі тести є більш складними, і незручні результати з’являються, коли аналізувати оцінки за типом запиту замість усереднення.
У порівнянні Azure AI Search від Microsoft за 2023 рік гібридний підхід до пошуку в цілому перевершив підхід, що використовує лише вектори. Якщо розглядати результати за категоріями, ситуація є менш очевидною: для запитів, заснованих виключно на ключових словах, один лексичний двигун може дати вищу оцінку, ніж гібридний результат. Усереднення приховує те, що розкриває аналіз окремих елементів.
Другий двигун не завжди покращує результати
Там, де лексичний двигун має рацію, наявність другого двигуна послаблює його ефективність. Припустимо, BM25 ранжує правильний документ на першому місці, а векторні методи — на десятому. Гібридний підхід може поставити його нижче документа, який обидва методи ранжують на третьому місці. Узгодженість результатів важливіша за точність, що є частиною концепції, але це має наслідки для деяких типів запитів.
Також важливою є якість другої частини процесу пошуку. Тести відновлення інформації на першій стадії на науковому корпусі показали, що гібридний підхід, заснований на слабкій моделі ембеддингу, посідає місце нижче за BM25 окремо, тоді як та сама конфігурація з потужнішою моделлю значно випереджає його. Фузія не створює нічого нового; вона лише поєднує наявні дані, і шум отримує такі самі шанси, як і сигнал.
Це не суперечить початковій думці. Якість ембеддингу визначає, наскільки векторна частина допомагає, але навіть найкращий ембеддинг не може відновити точний ідентифікатор, якого він не представляє. Це два окремі аспекти.
Жоден з результатів не спростовує гібридного пошуку. Обидва свідчать проти його використання без вимірювання власного розподілу запитів. Багато команд обирають гібридний підхід як очевидний стандарт і ніколи не аналізують цей розподіл.
Цей підхід є дешевим. Розділіть журнали запитів на ті, що мають точний ідентифікатор, та ті, що є суто концептуальними, та обчисліть показник для кожної групи окремо. Це займає години, а не хвилини, тоді як єдине агреговане число приховує проблеми, які згодом завдають шкоди у реальних умовах роботи.
Проблема консенсусу
У методі об’єднання рейтингів є більш тонка недолік, яка проявляється тоді, коли системи погоджуються, а не тоді, коли вони не погоджуються.
Візьмемо пошук у технічній документації з запитом про налаштування OAuth через змінні середовища. Метод векторного пошуку повертає загальний посібник з безпеки: актуальний за змістом, але без конкретики щодо OAuth. Метод BM25 повертає точний результат щодо OAuth, але він стосується запису з журналу змін, якому три роки. Жоден з варіантів не є найкращою відповіддю, і при об’єднанні рейтингів все одно на першому місці опиняється менш якісний варіант.
Це пряма наслідок того, як працює RRF. Застарілий журнал змін отримав оцінку середнього рівня від обох двигунів, тому сума їхніх взаємних рейтингів виявилася вищою, ніж у нової сторінки, яку сподобалася лише одна система. Дві не дуже ентузіастичні думки переважили одну впевнену та правильну.
Фільтрація перед об’єднанням
Виправлення знаходиться на етапі, що передує математичних обчислень. У більшості випадків жорсткі фільтри метаданих, такі як свіжість, дозволи та статус документа, мають працювати перед об’єднанням, а не після нього. Об’єднувальний механізм не повинен бачити кандидатів, яким ніколи не дозволялося брати участь. Деякі продакшн-системи фільтрують після цього та отримують хороші результати, тому це архітектурне рішення, яке потрібно перевірити на власному наборі даних, а не універсальне правило.
Тут послідовність має важливе значення. Фільтрація після об’єднання видаляє застарілу сторінку з результатів, проте свіжа сторінка, яка вже втратила голоси та опустилася нижче порогового рівня, залишається у списку. Фільтрація до об’єднання змінює список кандидатів, за які голосують обидва двигуни з самого початку.
На практиці слід одночасно застосовувати три фільтри на вході до обох етапів: дозволи користувача, статус документа та період свіжості, що відповідає домену. Обидва етапи мають отримувати абсолютно однакові фільтри. Інакше один з них заповнює свій список кандидатів документами, яких інший ніколи не бачив, а об’єднання перетворює цю асиметрію на перевагу у ранжуванні.
Ще один плюс для морфологічно багатих мов. Сильна інфлексія ускладнює зіставлення лексем. Без ефективної лематизації BM25 втрачає багато зі своїх переваг, адже варіанти слів з різними відмінками, як-от польські umowy та umowie чи німецькі Vertrags та Verträgen, виглядають як абсолютно різні токени. Це рідкісний випадок, коли векторний підхід рятує лексичний, а не навпаки.
Тож гібридний підхід виправляє одну групу помилок, створюючи при цьому нову, і нічого в системі пошуку не можна вважати надійним за замовчуванням без перевірки.
Що можна зробити з цього
Зниження кількості невдалих пошуків на 49 відсотків не стало наслідком використання більшої моделі чи потужнішого GPU. Це стало можливим завдяки усвідомленню того, що одна текстова репрезентація не може відповідати двом принципово різним типам запитів.
- BM25 та вектори дають негативні результати у протилежних напрямках, що є структурною причиною їх поєднання.
- RRF об’єднує позиції рангу, а не оцінки, оскільки масштабування BM25 та косинуса є несумісним, а нормалізація ніколи не усуває повністю проблему калібрування.
- Гібридний пошук є стандартом серед постачальників інфраструктури, тому ігнорування другого етапу є технічним боргом, а не проявом консерватизму.
- Стандартний варіант не означає автоматично кращий. При запитах на точні ідентифікатори BM25 окремо може перевершити метод об’єднання, а середнє значення показників це приховає.
- Застосовуйте фільтри метаданих перед об’єднанням, інакше збіг між пошуковими двигунами призведе до того, що застарілий документ буде вище за новий.
Для наступного тижня візьміть останні тисячу реальних запитів, позначте кожен як такий, що містить точний ідентифікатор, або як суто концептуальний, та обчисліть співвідношення. Потім окремо оцініть точність для обох груп та збережіть два рядки з результатами, а не змішану середню величину. Ця таблиця, набагато краща за будь-які стандарти постачальників, показує, чи покращить гібридний підхід вашу систему, чи просто дасть вам ще один індекс для обслуговування. Результат також вказує, наскільки ваш трафік залежить від точних рядків, що рідко хтось підраховує.
Пов’язані матеріали
- Практичні нотатки: Межі векторного пошуку в RAG — косинусна схожість та інше — Детальний огляд Практичних нотаток: Межі векторного пошуку в RAG — косинусна схожість та інше: контракти, перевірки та готові фрагменти коду для команд, які впроваджують цю модель.
- Apache Doris 4.1: Векторний пошук, зберігання у форматі JSON, OLAP та Lakehouse — Огляд нововведень Apache Doris 4.1: векторні індекси типу IVF, функція пошуку BM25, документи у форматі JSON об’ємом до 100 MB, технологія Segment V3, кешування запитів, можливість запису даних у форматі Iceberg, оператори MERGE INTO та TIMESTAMPTZ.