reranker повторно сортирует уже найденные фрагменты документов перед ответом RAG. Такой второй этап полезен, когда первый поиск приносит подходящие кандидаты, но нужный фрагмент оказывается слишком низко в списке.
Два этапа поиска
reranker работает после первого поиска: он оценивает кандидатов вместе с вопросом и меняет их порядок перед ответом.
В базе знаний сотрудник спрашивает о сроке согласования счёта. Первый поиск быстро извлекает кандидатов из индекса, часто по близости векторных представлений. В списке могут оказаться общий регламент, архивная инструкция и точный пункт о сроке. Второй этап рассматривает вопрос рядом с каждым кандидатом и поднимает фрагменты, которые лучше отвечают формулировке запроса.
Главная граница проста: reranker получает только те записи, которые уже нашёл первый этап. Если правильный документ отсутствует в кандидатах, исправляйте первый поиск. Прежде чем добавлять новый компонент, посмотрите на исходную выдачу. Если проблема в распознавании PDF, правах доступа или устаревших редакциях, работу надо начинать с источников.
Общую цепочку описывает архитектура RAG. Хранение и первичное извлечение через специализированную базу разбирает материал о Qdrant. Здесь фокус уже: как изменить порядок кандидатов так, чтобы модель получила наиболее уместный контекст.
Отдельно проверьте вопросы, в которых соседние документы используют похожие термины. Первый поиск способен вернуть оба текста, и только предметная оценка показывает, какой из них отвечает на конкретное условие. Этот тип запросов особенно важен для повторной сортировки.
Место в цепочке
Поток запроса выглядит так: приложение проверяет права пользователя, первый поиск выбирает доступные фрагменты, reranker упорядочивает их, затем ограниченный набор попадает в контекст модели. У каждого этапа своя диагностика. Журнал должен хранить исходный список кандидатов и итоговый порядок, иначе команда увидит только конечный ответ и начнёт угадывать причину ошибки.
- Сформулируйте вопрос и найдите ожидаемый фрагмент в эталонной разметке.
- Проверьте, появился ли он среди кандидатов первого поиска.
- Передайте допустимые фрагменты на повторную сортировку.
- Сравните порядок до и после, затем проверьте ответ с источником.
Число кандидатов и размер каждого фрагмента подбирают на своих документах. Короткий фрагмент может потерять условие, длинный — спрятать нужную строку среди постороннего текста. Полезно показывать reranker заголовок раздела и редакцию документа вместе с основным содержанием, если эти поля влияют на смысл вопроса.
Если пользователю запрещён доступ к документу, его фрагмент следует исключить до сортировки. Компонент ранжирования решает вопрос релевантности; права чтения определяются отдельно. Эту границу важно закрепить в техническом задании и проверить отрицательными запросами.
Храните версию компонента сортировки рядом с журналом выдачи. После изменения модели или правил подготовки текста повторите контрольные вопросы. Без версии невозможно понять, почему одинаковый вопрос на той же базе стал получать иной порядок фрагментов.
Ручная разметка
Качество второго этапа проверяют на вопросах сотрудников с ручной отметкой полезных фрагментов. Эксперт видит текст вопроса, действующие документы и отмечает, какие участки действительно подтверждают ответ. Для спорных формулировок укажите допустимые альтернативы и причину выбора. Такая разметка дороже автоматической оценки, зато показывает предметную ошибку без самоуспокоения красивым ответом.
| Ситуация | Первый поиск | После сортировки |
|---|---|---|
| Точный пункт низко | Есть среди кандидатов | Проверить подъём |
| Пункта нет | Отсутствует | Вернуться к загрузке |
| Старая редакция | Попала в список | Исправить фильтр версии |
| Чужой файл | Попал в список | Исправить права |
Оцените отдельно долю вопросов, где нужный фрагмент вообще попал в кандидаты, и долю вопросов, где он оказался среди переданных модели после сортировки. Эти величины отвечают на разные вопросы. Если первая низка, сначала улучшайте первый поиск. Если первая приемлема, а вторая низка, повторная сортировка может дать полезный эффект.
Добавьте вопросы без ответа в базе. Хорошая система сообщает о пробеле и показывает отсутствие подтверждения, без выбора наименее плохого фрагмента. После изменения источников повторите разметку для затронутых тем: новый регламент способен изменить правильный ответ.
Ваш поиск находит нужный документ, но теряет его в выдаче?
Специалисту по документам удобнее отмечать подтверждающие фрагменты прямо в интерфейсе просмотра. Разработчику тогда достаются понятные метки и пояснения, а эксперту незачем разбираться в технических оценках сходства.
Ошибки проверки
Типичная ошибка оценки — судить только по гладкости итогового текста. Модель может уверенно пересказать нерелевантный фрагмент; перестановка такого фрагмента наверх делает ответ убедительнее на вид, но хуже по сути. Показывайте проверяющему ссылку на источник и конкретную строку, которая поддерживает вывод. Если подтверждения нет, отмечайте ошибку вне зависимости от стиля.
Сохраняйте контрольные вопросы из разных групп: точное название пункта, синонимы, сокращения, похожие процедуры и запросы о старой редакции. Вопросы из одного подразделения создают ложное ощущение стабильности. Проверку проводят специалисты, которым принадлежит содержание документов, а разработчик готовит удобный интерфейс разметки и журнал изменений.
Условный пример: сотрудник спрашивает о возврате товара по специальному договору. Первый поиск приносит общий порядок возврата и приложение к специальному договору. Если reranker поднимает общий порядок выше точного приложения, ответ будет выглядеть разумно, но нарушит условия сделки. Разметка должна помечать приложение как обязательный источник, а общий порядок как вторичный.
Наблюдайте также за задержкой ответа и объёмом обработки. Дополнительный этап требует вычислений, поэтому решение принимайте по измерениям вашего контура и ценности правильного попадания, без универсальных обещаний скорости или точности.
Смотрите также на ошибки, когда правильные документы близки по смыслу, но различаются условием применения. Если модель сортировки игнорирует условие, повышение общей похожести лишь замаскирует риск неверной инструкции сотруднику.
Рабочий запуск
Пилот разумно ограничить коллекцией с уже понятными правами и стабильными документами. Сначала зафиксируйте исходную выдачу. Затем включите сортировку и сравните ответы на тех же вопросах. Это позволит объяснить, какой именно фрагмент переместился и повлияло ли изменение на полезность ответа для сотрудника.
В смете проекта отдельно смотрите подготовку разметки, подключение ранжирования, журналирование, контроль прав и повторную оценку после обновления документов. Стоимость зависит от структуры базы, числа типов запросов и требований к эксплуатации. Обсудить полный контур можно на странице внедрения нейросети для документов.
Выберите вопрос, где нужный пункт уже есть среди кандидатов, но отсутствует в ответе. Сохраните обе выдачи и попросите владельца регламента оценить порядок фрагментов.
После запуска оставьте возможность быстро отключить второй этап для сравнения. Сотрудники могут сообщать о неверном источнике прямо из ответа. Такое сообщение полезнее общей оценки «плохо»: оно ведёт к конкретному вопросу, фрагменту и редакции. Команда сможет решить, меняется ли загрузка, первый поиск или повторная сортировка.
Перед расширением на весь архив согласуйте владельца разметки и порядок обновления эталона. Новый документ меняет правильный источник для части старых вопросов. Без этой процедуры проверка постепенно оценивает систему по устаревшей картине знаний.
Сформулируйте условие остановки эксперимента заранее. Если на размеченных вопросах правильный фрагмент и без сортировки оказывается в контексте, дополнительный этап может лишь усложнить поддержку. Если же полезные кандидаты регулярно теряются внизу списка, закрепите новую проверку в процедуре каждого обновления базы знаний.