← К списку статей
Quando l'AI aziendale non sa quello che sa Глава 3 из 6
AI 2026-04-16 ProtoMedia

Лживый переранжировщик

Автоматический перевод с итальянского · смотреть оригинал

Глава 3 — Лживый переранжировщик

В техническом жаргоне RAG есть ключевая, не слишком гламурная и малорассказанная фигура: переранжировщик. Представьте себе корпоративный поиск как вход в ночной клуб. Векторная база данных — это вышибала у входа: он быстро осматривает толпу и пропускает тридцать кандидатов, которые, на первый взгляд, похожи на то, что вы ищете. Переранжировщик — это вышибала внутри: он берет этих тридцать, внимательно их рассматривает, выбирает пять — те, которые LLM действительно прочитает для построения ответа — и отправляет остальных двадцать пять обратно. Это небольшая, но огромная функция: если он ошибется, ошибутся все. Если вышибала не умеет читать лица, клуб наполнится не теми людьми, и никто никогда не поймет, почему вечер прошел плохо.

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

Если не считать того, что оценки были неверными. Не "слегка" неверными, как это может случиться с любой моделью: неверными структурно. Документы, явно релевантные, получали 0.2, документы не по теме — 0.8. Первые подозрения, как всегда в таких случаях, пали на обычных подозреваемых: модель эмбеддингов, чанкинг, формулировку запроса, предварительную обработку документов. Недели расследований по ложному следу. Только систематическое сравнение ответов облачного реранкера с ответами локального реранкера-эталона — один и тот же ввод, одни и те же документы, оценки, поставленные рядом в таблице Excel — выявило неприятную правду: модель, представленная через API, была сломана. Возможно, ошибка при развертывании, возможно, случайно загруженная неверная версия, возможно, ошибка в сериализации оценок. Поставщик этого никогда не признал официально. Проблема, однако, просто исчезла однажды после тихого обновления и без изменений в примечаниях.

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

Выбор, идущий против течения, который сделали некоторые команды в последние месяцы — вместо того, чтобы двигаться в сторону облачных технологий, вернуться назад — заключался в том, чтобы вернуть reranker *домой*. Модель с открытым исходным кодом из семейства BGE, не гигантская, работающая на локальном GPU (включая Apple Silicon, с некоторой осторожностью в отношении драйверов). Больше работы по управлению, это правда. Но возможность проводить контролируемые эксперименты, понимать, когда она ошибается, сравнивать версии, вести историю изменений. И — что немаловажно — не выплачивать API долю цента за каждый отдельный запрос пользователя. Доля, умноженная на десятки тысяч запросов в месяц, быстро перестает быть долей и становится статьей расходов.

Когда компонент настолько критичен, что его неисправность нарушает вашу способность измерять все остальное, делегировать его «черному ящику» — это не эффективность. Это акт веры. А акты веры в производстве оплачиваются сложными процентами.

Краткий урок: Когда компонент настолько критичен, что его неисправность нарушает все остальное, делегировать его «черному ящику» — это не эффективность. Это акт веры.

Есть замечание? Напишите нам

Сообщение предназначено только для нас. Если ваш комментарий будет интересен, мы можем опубликовать его в конце статьи, но только после проверки.

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