Глава 5 — Архитектура поискового пайплайна

Пятый пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. Один векторный поиск — это место, где останавливается большинство прототипов, и место, где начинается большинство продакшен-отказов. Глава проходит весь путь от полусырого запроса до финальных кандидатов, доходящих до генератора, — и почему каждая стадия существует.

Почему существует эта глава

Главы 2–4 произвели векторное хранилище: распарсенные документы, аккуратно разрезанные, заэмбежденные, индексированные. Наивный следующий шаг — эмбеддить запрос пользователя, выполнить nearest-neighbour поиск и подать top-k генератору. Для тривиальных корпусов это работает. Для продакшена — почти никогда. Запросы приходят недоопределёнными и полными собственных имён, которых эмбеддер никогда не видел; корпуса содержат почти-дубликаты, толпящиеся в верхушке любого одиночного ранжирования; идентификаторы и коды несут смысл, который эмбеддер сглаживает.

Глава 5 — о той архитектуре, к которой сходятся зрелые системы. Это не исследовательский артефакт. Это форма, в которой команды реально работают, когда recall, precision и латентность должны держаться одновременно.

5.1 Почему одного векторного поиска недостаточно

Плотный поиск переписывает экономику поиска, но сама терпимость к перефразированию, делающая эмбеддинги полезными, делает их хрупкими. Цифровые токены, ссылки на статьи закона, коды транзакций, номера деталей — всё, где поверхностная форма и есть смысл — приземляются в произвольных уголках векторного пространства. У BM25, который просто считает то, что есть, такой проблемы нет.

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

5.2 Гибридный поиск: плотные векторы и BM25 параллельно

Два индекса по одним и тем же чанкам: плотный HNSW или IVF индекс от эмбеддера и разрежённый инвертированный индекс от BM25 или SPLADE. Оба опрашиваются, оба возвращают ранжированные списки, а пайплайн ингеста пишет в оба синхронно. BM25 — не наследие; это самая надёжная keyword-ранжирующая функция, что когда-либо изобреталась, малопараметрическая, но не беспараметрическая, и на BEIR-бенчмарках гибридный поиск обгоняет dense-only на большинстве out-of-domain задач. Разрыв расширяется по мере отхода домена от обучающего распределения эмбеддера.

Специфический режим отказа, который стоит назвать: BM25 должен корректно токенизироваться под каждый язык в области применения. Запуск японского корпуса с дефолтным английским анализатором тихо превращает BM25-ногу в чистый шум, и система кажется рабочей только потому, что плотная нога тянет всё. Разрежённый поиск тоже двинулся вперёд — выученные разрежённые модели в стиле SPLADE наследуют операционную простоту BM25 с recall-поведением плотного ретривера.

5.3 Reciprocal rank fusion и cross-encoder reranking

Наивный способ объединить два ранжированных списка — сложить их оценки. Это не работает: значения BM25 неограниченные и зависят от корпуса; косинусные сходства сидят примерно в [-1, 1]. Они несоизмеримы, и любая фиксированная весовая комбинация — вечная задача настройки. Reciprocal Rank Fusion обходит проблему, выбрасывая сами оценки. Для каждого кандидата объединённая оценка — сумма 1/(k + rank) по всем ретриверам с k = 60. Кривая крутая в начале и плоская в хвосте, результаты нечувствительны к k, и алгоритм естественно компонуется с multi-query expansion — шесть списков от трёх перефразировок против двух ретриверов сливаются одной строкой кода.

RRF не способен спасти документ, который не достал ни один ретривер; эту работу делает переписывание запроса. Что RRF делает дёшево и без гиперпараметров — мирит ретриверы, которые апгрейдятся и заменяются независимо. Пайплайн, чей fusion не надо перенастраивать при смене ноги, заметно дешевле в сопровождении.

Bi-эмбеддеры, давшие эти ранжирования, никогда не видели запрос и чанк вместе. Cross-encoder reranker видит — он склеивает пару и пропускает их совместно через трансформер, fine-tuned выдавать оценку релевантности. Каждая голова внимания видит обе стороны сразу, и модель способна обратить внимание на конкретную фразу в запросе, которая должна совпасть с конкретной фразой в чанке. Его нельзя предварительно посчитать, поэтому он слишком медленный как первичный ретривер, но идеален поверх 50–200 кандидатов, которые поднимает гибридный поиск. Прирост по NDCG@10 обычно 5–15 пунктов — больше, чем смена модели эмбеддингов внутри семейства bi-эмбеддеров.

5.4 Понимание запроса: переписывание, расширение, HyDE

Всё, что выше, предполагало, что запрос корректно сформулирован. Редко так. Пользователь help-desk набирает «отпуск»; политика говорит «право на ежегодный отпуск». Разработчик набирает «auth fails 500»; runbook описывает «сервис аутентификации возвращает HTTP 500 с ошибкой валидации токена». Работа должна случиться на стороне запроса. Три паттерна компонуются: переписывание запроса в самодостаточную форму (разрешение местоимений, расшифровка аббревиатур, перевод языка под корпус); расширение в несколько перефразировок, каждая из которых веерно идёт в оба ретривера; и HyDE, который просит маленькую модель написать гипотетический ответ и эмбеддит его вместо вопроса. Корпус полон ответов, а ответы похожи на другие ответы больше, чем на вопросы.

Защитный паттерн — держать оригинальный запрос рядом с переписанным и диспатчить оба. Результат переписывателя — гипотеза, а не замена. Большинство «регрессий поиска» в агентных системах — это регрессии переписывания, и они невидимы без постадийной телеметрии.

Что подготавливает глава 5

Нарисованный пайплайн — это и вся поверхность, которую злоумышленнику нужно подменить. Каждая стадия принимает вход, производит выход и доверяет данным, над которыми работает. Корпус может быть отравлен на ингесте; эмбеддер может быть манипулирован adversarial-чанками; reranker — смещён; генератор обманут инструкциями, спрятанными в найденном контенте. Дальше книга открывает Часть IV, и рамка смещается с того, как искать хорошо, к тому, что происходит, когда поиск атакуют.

Дальше — Глава 6: Модели угроз и уязвимости RAG. Та же открытость, что делает RAG полезным, — это и поверхность, которую эксплуатируют противники: отравление корпуса, adversarial-поиск, непрямой prompt injection, инверсия эмбеддингов и confused deputy.