Реренкер-брехун

Розділ 3 — Реренкер-брехун

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

У 2025 році на ринку з’явилися різні хмарні сервіси, які пропонували реренкери як API. Ви надсилаєте запит і список документів, а вони повертають вам оцінки. Зручно, масштабовано, не потрібно купувати GPU, не потрібно завантажувати моделі. Один відомий європейський постачальник моделей — не називаючи імен, але ви знаєте, яких імен ми уникаємо — виставляв багатообіцяючу модель з родини Qwen, з чотирма мільярдами параметрів, позначену як "Reranker". Ціна була розумною, затримка прийнятною. Будь-хто в той історичний момент вибрав би його. Багато хто його вибрав.

Хіба що оцінки були неправильними. Не "трохи" неправильними, як може трапитися з будь-якою моделлю: неправильними структурно. Документи, очевидно релевантні, отримували 0.2, документи поза темою – 0.8. Перші підозри, як завжди в таких випадках, були спрямовані на звичних підозрюваних: модель ембедінгів, чанкінг, формулювання запиту, попереднє оброблення документів. Тижні розслідувань хибними шляхами. Лише порівнюючи систематично відповіді хмарного реранкера з відповідями локального реранкера-еталона – той самий вхід, ті самі документи, оцінки, поставлені пліч-о-пліч в Excel – виплила неприємна правда: модель, виставлена через API, була зламана. Можливо, помилка розгортання, можливо, випадково завантажена неправильна версія, можливо, помилка в серіалізації оцінок. Постачальник ніколи не визнавав цього формально. Проблема, однак, просто зникла одного дня, після тихого оновлення та без змін у примітках.

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

Вибір деяких команд, у ці місяці, піти проти течії — замість того, щоб рухатися до більшої хмарності, повернутися назад — полягав у тому, щоб повернути reranker *додому*. Модель з відкритим кодом з родини BGE, не гігантська, запущена на локальному GPU (навіть на Apple Silicon, з певною обережністю щодо драйверів). Більше роботи з управління, це правда. Але можливість проводити контрольовані експерименти, розуміти, коли виникає помилка, порівнювати версії, вести історію. І — не в останню чергу — не перераховувати API частку цента за кожен окремий пошуковий запит користувача. Частка, помножена на десятки тисяч запитів на місяць, швидко перестає бути часткою і стає статтею витрат.

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