Більшість команд зупиняється на векторному top-k і питає, чому асистент помиляється кожен п’ятий раз. Відповідь майже завжди одна й та сама: пошук повернув фрагменти, схожі на запит, але не ті, які відповідають на питання. Реренкінг вирішує саме цю проблему, і це без перебудови всього пайплайну.
Чому самі ембедінги недостатні
Ембедінг, перетворюючи текст на вектор, стискає інформацію до одного числа на вимір. Модель ембедінгів ніколи не бачить питання та фрагмент разом — вона їх вбудовує окремо, а схожість вимірюється потім геометрично. Це швидко та масштабовано, але має свою ціну.
Приклад, який регулярно зустрічається у продакшені: база знань компанії містить два документи. Один описує «процедуру рекламації для приватних клієнтів», інший — «процедуру рекламації для бізнес-клієнтів». Обидва мають дуже схожі ембедінги, оскільки більшість слів спільні. Запит «як подати рекламацію як компанія» вектором також близький до обох. Пошук ANN повертає обидва з подібним скором. Генеративна модель отримує обидва фрагменти і має шанс переплутати шляхи.
Cross-encoder reranker бачить усе інакше: він отримує одночасно запит і кожного з кандидатів як пару, обчислює relevance score з урахуванням взаємного контексту. Фрагмент про бізнес-клієнтів отримує вищий скор. Релевантність зростає без зміни векторного індексу.
Це також причина, чому hybrid search і реренкінг природно поєднуються: гібрид збільшує покриття кандидатів (BM25 + ANN), реренкер підвищує точність із цієї вибірки.
Як працює cross-encoder: механізм зсередини
#Cross-encoder — це трансформерна модель (зазвичай варіант BERT або подібна), тренована на парах (запит, фрагмент) з міткою релевантності. Під час інференсу:
- Запит і фрагмент конкатенуються як один вхідний рядок зі спеціальним токеном-сепаратором.
- Модель обробляє цю пару через усі шари уваги одночасно, завдяки чому кожен токен запиту може «дивитися» на кожен токен фрагмента.
- Вихід — один скаляр: relevance score цієї конкретної пари.
- Пайплайн обчислює скор для кожного кандидата з top-k, сортує за спаданням і повертає top-n до генеративної моделі.
Вартість: інференс cross-encodera для кожного кандидата окремо. При top-20 кандидатах це 20 forward pass-ів моделі реренкінгу замість одного. Тому реренкер обробляє лише кандидатів із пошуку, а не весь індекс.
| Механізм | Вхід | Взаємодія запит-фрагмент | Швидкість | Релевантність |
|---|---|---|---|---|
| Bi-encoder (ANN) | кожен текст окремо | відсутня (post-hoc cosine) | дуже швидка | добра |
| Cross-encoder (reranker) | пара запит+фрагмент | повна (перехресна увага) | повільніша | висока |
| Гібрид BM25+ANN+reranker | обидва | повна на кандидатах | помірна | найвища |
Bi-encoder масштабується на мільйони документів. Cross-encoder не масштабується на мільйони, оскільки повинен порівнювати кожне запитання з кожним фрагментом. Тому продуктивний патерн завжди такий: швидкий пошук кандидатів, потім дорогий реренкер на невеликій вибірці.
Коли реренкінг дає найбільший ефект
Не кожен пайплайн потребує реренкінгу з першого дня. Варто його додати, коли:
База знань містить документи зі схожим формулюванням і різним змістом. Процедури для різних груп клієнтів, регламенти в кількох версіях, інструкції для різних моделей пристроїв. Ембедінг сприймає їх майже однаково, реренкер розрізняє.
Запитання багатоаспектні або неоднозначні. «Як скасувати підписку, якщо я був у відпустці і не встиг у термін» має багато складових. Bi-encoder спрощує до одного вектора. Cross-encoder читає все.
Пайплайн відповідає англійською на польські запитання або навпаки. Багатомовні моделі мають гірші ембедінги для змішаних мов. Cross-encoder, тренований на багатомовних парах, краще справляється з контекстною релевантністю.
У вас довгі фрагменти (понад 512 токенів). Bi-encoder стискає довгий фрагмент до одного вектора, втрачаючи деталі. Cross-encoder обробляє весь контекст пари.
Якщо ваша база невелика (до кількох сотень документів), запитання короткі та точні, а відповіді задовільні, реренкінг може не дати вимірюваного покращення. Завжди перевіряйте результати на тестовому наборі перед впровадженням.
Моделі реренкінгу: що запускаємо локально
Вибір моделі реренкінгу впливає на якість, латентність і те, чи залишають дані інфраструктуру. Основне правило: якщо база знань містить конфіденційні або персональні дані, реренкер повинен працювати локально. Фрагмент документа, відправлений до зовнішнього API реренкінгу = дані залишають корпоративну мережу.
Використовуємо моделі реренкінгу, які запускаються локально. Практичні варіанти у 2026 році:
| Модель | Розмір | Мови | Латентність (пара) | Хостинг |
|---|---|---|---|---|
| bge-reranker-v2-m3 | 568 MB | багатомовна (PL, EN, DE...) | ~30 мс (CPU) | локальний |
| bge-reranker-large | 1,3 GB | багатомовна | ~60 мс (CPU) | локальний |
| ms-marco-MiniLM-L-12 | 127 MB | EN | ~10 мс (CPU) | локальний / хмара |
| Cohere Rerank v3 | API | багатомовна | ~80 мс (API) | хмара |
Для польської бази знань bge-reranker-v2-m3 — перший вибір: багатомовна, поміщається на стандартному CPU-сервері, латентність на рівні кількох десятків мілісекунд на пару. При 20 кандидатах це менше 700 мс додаткового часу, що в більшості сценаріїв корпоративного асистента є прийнятним.
Self-hosting моделі реренкінгу має ще один вимір відповідності до RODO: фрагмент документа ніколи не залишає інфраструктури, навіть тимчасово під час оцінки релевантності. Це важливо для баз знань, що містять процедури, договори або дані клієнтів.
Побудова пайплайну з реренкінгом
Повний пайплайн виглядає так. Кожен крок має одне завдання і виробляє чітко визначений вихід.
Крок 1: Індексація. Кожен документ ділиться на фрагменти (зазвичай 256-512 токенів з нахлестом 64 токени). Кожен фрагмент вбудовується моделлю BGE-M3 і зберігається у векторній базі (Qdrant) з метаданими: категорія, дата, відділ, тип документа.
Крок 2: Гібридний пошук. На запит користувача запускаються паралельно BM25 (Postgres FTS або Elasticsearch) і ANN (Qdrant). Результати зливаються через Reciprocal Rank Fusion (RRF) у пул 20-50 кандидатів. Цей крок зазвичай триває менше 100 мс.
Крок 3: Реренкінг. Кожен кандидат оцінюється cross-encoder-ом як пара (запит, фрагмент). Результати сортуються за спаданням. До генеративної моделі потрапляє top-3 до top-5 фрагментів.
Крок 4: Генерація з контекстом. Генеративна модель отримує запитання та вибрані фрагменти через router LLM. Guardrails перевіряють вихід перед наданням користувачеві. Якщо жоден фрагмент не перевищив поріг релевантності, система відповідає «не знаю» і перенаправляє до людини (див.: human-handoff).
Критична деталь: поріг релевантності реренкінгу. Якщо найвищий скор у пулі менше 0.3 (шкала 0-1), фрагмент недостатньо пов'язаний із запитанням. Краще не генерувати відповідь, ніж генерувати з низькорелевантним контекстом. Ця логіка прямо обмежує галюцинації.
Реренкінг і латентність: як утримати час відповіді
Реренкінг додає час. Питання, чи цей час прийнятний, залежить від контексту.
У корпоративному асистенті з відповіддю менше 3 секунд реренкінг на 20 кандидатах і CPU займає 600-800 мс. Це 20-30% загального часу відповіді. У більшості сценаріїв обслуговування клієнтів і внутрішньої підтримки це прийнятно.
Якщо пайплайн має бути швидшим, кілька оптимізацій:
- Зменш пул кандидатів. Top-10 замість top-20 — вдвічі швидший реренкер при незначній втраті покриття.
- Кешуй результати реренкінгу для повторюваних запитань (з TTL 24h). Запитання FAQ повторюються в 30-50% у системах обслуговування клієнтів.
- Використовуй меншу модель реренкінгу. MiniLM у 5 разів швидший за bge-reranker-large при прийнятній втраті релевантності для простіших баз знань.
- Фільтруй метаданими перед реренкінгом. Якщо категорія документа відома з контексту (наприклад, користувач у розділі «продукти»), обмеж пул цією категорією вже на етапі ANN.
Throughput і латентність — це виміри, які ми вимірювали при кожному впровадженні. Деталі про моніторинг пайплайну описує стаття моніторинг якості агента AI.
Оцінка: як перевірити, чи допоміг реренкінг
Не додавай реренкінгу без тестового набору. Без вимірювання немає впевненості, що щось покращив.
Мінімальний оціночний набір — 50-100 пар (запитання, очікуваний фрагмент). Можна створити його з логів продакшену (запитання користувачів + фідбек від консультантів) або вручну для найважливіших областей бази знань.
Метрики, на які варто звертати увагу:
- MRR (Mean Reciprocal Rank) — наскільки високо релевантний фрагмент з'являється у списку. MRR@10 вимірює це на перших 10 результатах.
- NDCG (Normalized Discounted Cumulative Gain) — зважена міра, де вище = більш релевантні.
- Precision@k — скільки з top-k фрагментів дійсно релевантні.
- Час відповіді p50/p95 — до і після реренкінгу.
Бенчмарк AB до/після реренкінгу на тому самому тестовому наборі дає конкретну відповідь. У типових проєктах з різноманітною базою знань реренкінг підвищує MRR@5 на 15-30% відносно самого ANN. Це призводить до меншої ескалації до людей і вищого containment rate.
Спробуй наживо
Наведений нижче sandbox запускає пайплайн з реренкінгом на твоєму тексті. Встав фрагмент документа, задай питання. Система здійснить пошук, оцінить кандидатів cross-encoder-ом і згенерує відповідь. PII маскуються перед моделлю, нульове збереження.
FAQ
#Чим відрізняється реренкінг від звичайного векторного пошуку?
Векторний пошук обчислює схожість ембедінгів запитання та фрагментів окремо, без їх взаємного порівняння. Реренкінг обробляє кожну пару (запитання, фрагмент) разом через модель cross-encoder, яка розуміє взаємний контекст. Результат: векторний пошук швидкий і добре масштабується на мільйонах документів, реренкер повільніший, але значно точніше оцінює, який з кандидатів дійсно відповідає на запитання.
Чи потрібен реренкінг у кожному RAG?
#Ні. При невеликій, однорідній базі знань (до кількох сотень добре структурованих документів) і точних запитаннях сам семантичний пошук часто достатній. Реренкінг вигідний, коли база велика або неоднорідна, запитання багатоаспектні або є документи зі схожим формулюванням і різним змістом. Перш ніж додавати реренкінг, виміряй MRR і Precision@k на тестовому наборі без нього, а потім порівняй результати після додавання. Дані вирішують, а не інтуїція.
Чи відправляє реренкінг дані в хмару?
Тільки якщо використовуєш API реренкінгу (наприклад, Cohere Rerank). При локальній моделі (bge-reranker-v2-m3 через Ollama) усі фрагменти та запитання обробляються на власному сервері. Для баз знань, що містять конфіденційні дані або підпадають під RODO, завжди обираємо локальні моделі. Обов'язки компаній при обробці персональних даних в AI описує стаття AI Act і RODO 2026.
Як довго триває впровадження реренкінгу в існуючому RAG?
#Якщо пайплайн RAG вже працює, додавання реренкінгу зазвичай займає дні, а не тижні. Крок пошуку розширюється моделлю cross-encoder (завантаження та запуск локально), логікою сортування за новим скором і опціонально порогом мінімальної релевантності. Більший обсяг роботи — це оціночний набір і бенчмарк, які підтверджують, що зміна покращила якість. Без них не знаєш, що насправді отримав.
Чи допомагає реренкінг при запитаннях про числа, коди та власні назви?
Тут реренкінг допомагає, але ефективнішим є hybrid search як попередній крок. BM25 точно виловлює номери договорів, SKU чи унікальні назви продуктів, з якими ембедінги справляються погано. Реренкер оцінює потім, який з кандидатів (і BM25, і ANN) дійсно відповідає на запитання. Поєднання обох механізмів дає найкращі результати на різноманітних базах знань, про що ми детальніше пишемо у статті семантичний пошук та ембедінги у компанії.