Почему вы упорно меняете 7-миллиардную модель на 70-миллиардную, ожидая, что она перестанет выдумывать факты? Это иллюзия. Большая языковая модель галлюцинирует не от скудоумия, а оттого, что слой поиска скармливает ей откровенную дичь. Базовый векторный поиск вытаскивает релевантный ответ на восемнадцатую позицию, а в контекстное окно помещаются только первые пять. Модель смотрит на эту грязь, пожимает плечами и начинает сочинять. Искать куски текста только через косинусное сходство эмбеддингов — инженерия вчерашнего дня, которая жестоко ломается о специфику русского языка.
Реранкер для RAG на русском: нужен ли cross-encoder и бенчмарк bge-reranker-v2-m3 vs альтернатив на on-prem
Двухэтапный поиск, или two-stage retrieval, больше не опция, это суровая необходимость для корпоративного сектора. Если вы читаете этот текст, значит, вы дошли до стадии принятия проблемы. Векторные пространства жестко ограничены размерностью. Вы берете сложную семантику абзаца из пятисот токенов и трамбуете её в массив из тысячи чисел. Происходит колоссальная потеря информации. Если в тексте упоминается сложная процедура оформления банковской гарантии с исключениями, вектор схлопнет это в абстрактное облако. Пользовательский запрос про одно конкретное исключение пролетит мимо, потому что его эмбеддинг укажет в другую область гиперсферы. Косинусное расстояние слепо.
Архитектура cross-encoder работает принципиально иначе. Она не сжимает текст в вектор. Запрос и документ склеиваются в единую последовательность и прогоняются через все слои внимания совместно. Каждый токен вопроса смотрит на каждый токен документа. Трансформер буквально взвешивает семантическую связь в реальном времени. Отрицания отрабатываются безупречно. Спросите систему про то, какие справки НЕ нужны — базовый поиск выдаст все нужные, потому что лексика совпадает. Кросс-энкодер уловит частицу и её связь с контекстом. Точность возрастает драматически. Расплата за это — производительность. Вы не можете прогнать базу из миллиона записей через такую модель, это положит любой кластер.
Поэтому пайплайн строится слоями. Быстрый и глупый эмбеддер выгребает топ-50 кандидатов. Затем тяжелая модель переоценивает эту полсотню и оставляет топ-10 кристально чистого контекста, который уходит в генерацию. В Morana Labs мы набили достаточно шишек на закрытых банковских датасетах, чтобы утверждать: без этого этапа качественный RAG на внутренних данных мертв. Метрики меняются кардинально. Классический recall@5 редко превышает 0.65. Добавление реранкера вытаскивает его за 0.90. Оценка nDCG@10, учитывающая порядок документов, взлетает с жалких 0.45 до 0.82. Лучший ответ теперь лежит первым.
Бенчмарк без маркетинга: цена точности
Рынок долгое время монополизировал Cohere. Для бизнеса в реалиях 152-ФЗ отправка внутренней документации через внешний API — это статья и немедленное увольнение. Нам нужно крутить веса строго on-prem, на собственном железе. Звезда текущего момента — bge-reranker-v2-m3 от BAAI. Это 568 миллионов параметров, чистая мультиязычность с отличным пониманием русского канцелярита и лицензия Apache 2.0. Но маркетинг всегда скрывает компромиссы. Мы прогнали модель в сравнении с альтернативами на золотом наборе русскоязычных договоров.
| Архитектура / Модель | nDCG@10 (RU) | VRAM (GB) | Задержка GPU на 50 чанков (ms) |
|---|---|---|---|
| bge-reranker-v2-m3 | 0.82 | 2.5 | 120 |
| LLM-as-a-judge (Llama 3 8B) | 0.85 | 16.0 | 800 |
| MiniLM-L6-ru | 0.61 | 0.5 | 15 |
Таблица срывает покровы. Легковесные варианты проседают по качеству. Они выдают ответ за 15 миллисекунд, но пропускают много мусора. Использование полноценной LLM в качестве судьи выбивает шикарный скор, но требует огромных объемов видеопамяти и добавляет почти секунду задержки на батч. Секунду до того, как начнется генерация финального ответа. Это смерть для высоконагруженного сервиса.
Здесь китайская модель оказывается идеальным компромиссом. Да, это дополнительный такт. Но 120 миллисекунд переранжирования экономят вам секунды генерации, так как большой модели больше не нужно продираться через тысячи токенов лишнего контекста.
Экономика задержек: CPU против GPU
Любое архитектурное решение упирается в железо. Технический директор должен понимать физику процесса. Переход на двухэтапное извлечение означает, что на каждый пользовательский запрос запускается полноценный прямой проход тяжелой нейросети.
Процессоры справятся, если у вас внутренний поиск на десять обращений в минуту. На современных серверных CPU переварить батч из пятидесяти чанков займет около семисот миллисекунд. Вполне приемлемо для бэкофиса. Но если система смотрит наружу и вы ловите сотни RPS, процессорный кластер захлебнется. Точка окупаемости перехода на видеокарты лежит в районе пятнадцати запросов в секунду. Именно здесь закупка условных L4 становится дешевле горизонтального масштабирования процессорных нод. Главная метрика — пропускная способность памяти. Вы агрегируете запросы на уровне инференс-сервера и прогоняете матрицы большего размера, удерживая латентность в пределах жестких SLA.
Анти-хайп: когда вам не нужна вторая стадия
Инженерия — это умение не использовать технологии там, где они бесполезны. В ряде сценариев внедрение второй стадии поиска только сожжет электричество без влияния на бизнес-метрики. Ваш домен — это жестко структурированные артикулы или логи? Векторная база уже отлично справляется, а BM25 добивает остатки несовпадений. Чанки состоят из пары предложений и кандидатов на выдачу в принципе меньше десятка? Тяжелый энкодер будет стрелять из пушки по воробьям. Задержка удвоится, а качество не изменится.
Реранкер абсолютно бесполезен, если у вас сломан базовый слой ретривала. Если система из-за кривого парсинга PDF вообще не находит нужный документ и не включает его в стартовые топ-50, никакая магия его оттуда не вытащит. Переранжировать можно только то, что уже найдено. Сначала чините извлечение текста, настраивайте гибридный поиск и только потом полируйте выдачу трансформерами.
Вам нужен жесткий протокол замера до и после. Бездушный автоматический скоринг не спасет, если он не видит специфику вашей предметной области. Вы собираете golden set — ручную выборку из пятисот реальных вопросов пользователей и привязанных к ним кусков текста, где кроется ответ. Прогоняете этот сет через голую векторную базу и фиксируете метрику hit rate. Затем добавляете в пайплайн bge-reranker-v2-m3 и смотрите на дельту. Метрика nDCG@10 учитывает позицию правильного документа. В реальном проде, где контекстное окно забито мусором, падение релевантного факта ниже третьей позиции почти гарантированно ведет к галлюцинациям генеративной модели из-за эффекта lost in the middle.
Влияние правильного внедрения на фактическую достоверность ответов в проде невозможно переоценить. Доля галлюцинаций падает кратно. Когда в генерацию приходят ровно три абзаца с прямым ответом на вопрос, системе физически не из чего сочинять бред. Снижается объем промпта, падает стоимость токенов или освобождается VRAM для параллельных запросов. Тюнинг RAG-пайплайна под ваши данные on-prem — это фундамент предсказуемого интеллекта, который приносит деньги, а не головную боль.