Embedding и reranker в поиске документов: две разные работы

Команда подключила поиск по внутренним документам и видит странный результат: нужная инструкция попадает в десятку найденных, но модель отвечает по первому, менее подходящему фрагменту. Попытка заменить embedding-модель может помочь, но не всегда решает проблему порядка. Здесь появляется reranker — отдельный компонент, который оценивает уже найденные пары «вопрос — фрагмент». Он не заменяет первоначальный поиск и не добавляет недостающий документ в базу. Его задача уже: выбрать из кандидатов те, что лучше соответствуют конкретному вопросу.

Что делает первый этап

Embedding-модель превращает текст вопроса и документов в числовые представления. Индекс быстро выбирает близкие фрагменты среди большого массива. Это выгодно, когда искать нужно по тысячам или миллионам записей. Но близость в таком пространстве не тождественна ответу на точный вопрос. Запрос «когда заканчивается испытательный срок» может оказаться рядом с общим разделом о найме, хотя нужное исключение спрятано в приложении к договору.

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

Что добавляет reranker

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

У такого шага есть цена: дополнительная задержка, потребление памяти при локальном запуске или оплата вызова облачного сервиса. Если вы сравниваете сотню длинных документов на каждый вопрос, задержка может стать заметной. Reranker не следует запускать вслепую на всей базе — он предназначен для переоценки разумного числа кандидатов. Число выбирают по измерениям, а не по красивой цифре из примера в документации.

Тест на одном архиве

Соберите 30–50 настоящих вопросов сотрудников и для каждого вручную отметьте один или несколько допустимых фрагментов с нужной версией документа. Отдельно добавьте вопросы, на которые ответа в архиве нет. Запустите базовый поиск и запишите, присутствует ли нужный фрагмент в первых двадцати результатах. Если его там нет, reranker почти бессилен: перестановка не создаёт отсутствующий материал. Сначала чините индекс, фильтры и разбиение.

Если нужный фрагмент обычно находится в двадцатке, но редко в первых трёх, добавьте reranker и сравните положение на тех же вопросах. Считайте не только среднее место, но и конкретные провалы: потерю исключения, устаревшую редакцию, неверный филиал. Затем проверьте конечный ответ модели и цитату. Возможно, порядок улучшился, но генератор по-прежнему смешивает два правила. Тогда проблема уже на следующем этапе цепочки.

Для честного сравнения зафиксируйте базу, дату, формулировки вопросов и параметры поиска. В практике контрольного набора объясняется, почему изменять несколько компонентов одновременно — плохой способ понять причину улучшения.

Когда reranker не нужен

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

Есть и вопросы приватности. При облачной переоценке фрагменты внутренних документов уходят в ещё один сервис. Политика компании может позволять основной модели видеть документ, но не стороннему reranker. Проверьте маршрут данных, сроки хранения и журналирование. При локальном варианте сравните ресурсы: отдельная модель переоценки съест часть памяти, доступной генератору.

Практический критерий выбора

Выбирайте улучшение по тому месту, где теряется правильный фрагмент. Если он не найден — работайте с индексом, фильтрами и подготовкой документа. Если найден, но низко — тестируйте reranker. Если попал в контекст, но ответ неверен — меняйте инструкцию генератору и проверку цитат. Такой разбор не обещает волшебную точность, зато помогает не покупать дополнительную модель для проблемы, которую она не решает.

Итог: embedding и reranker не конкурируют за одну роль. Первый быстро сокращает огромный архив до списка кандидатов; второй может лучше расставить уже найденные фрагменты под конкретный вопрос. Решение о втором этапе принимают после теста на собственных документах, с учётом задержки, цены и маршрута данных.

Частые вопросы

Может ли reranker найти документ, которого нет в первичной выборке? Нет, если он получает только результаты первого поиска.

Нужно ли менять embedding-модель перед установкой reranker? Не обязательно. Сначала выясните, попадает ли правильный фрагмент в список кандидатов.

Повышение позиции гарантирует верный ответ? Нет. Генератор может неверно прочитать даже хороший фрагмент; проверяйте финальный ответ и цитату.

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