Реранкеры в RAG: когда ранжирование лучше длинного контекста

Почему policy-ответы дают сбой

Policy-вопросы обычно ломаются по простой причине: пользователи формулируют их коротко, а компании пишут правила слоями. Человек вводит: «Могу ли я получить возврат?» В базе знаний при этом может лежать десять страниц, которые выглядят релевантными: правила биллинга, исключения по странам, старые условия кампаний и устаревшая справка, где всё ещё используются те же слова.

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

Старый policy-контент создаёт больше проблем, чем многие команды ожидают. В support-центрах редко удаляют каждое устаревшее правило, черновик или временное исключение. Какие-то страницы остаются в индексе, какие-то копируются в FAQ, а какие-то висят во внутренних заметках. Модель не знает, какая версия важна, если retrieval не делает это очевидным.

Больше контекста не всегда помогает. В работе с policy лишний текст может сделать ответ хуже. Когда вы отправляете в prompt несколько связанных документов, модель может слить их в аккуратное, но ложное резюме. Она видит пять абзацев про возвраты, один абзац про особый случай, а потом уверенно отвечает, игнорируя особый случай, потому что он оказался слишком далеко внизу.

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

Support-команды расплачиваются за такой конфликт дважды. Сначала пользователи получают медленный ответ. Потом агенту приходится проверять его вручную. Быстрые неверные ответы подрывают доверие. Медленные неверные ответы подрывают его ещё быстрее.

Именно поэтому реранкеры так важны в policy и support-задачах. Сложность обычно не в том, чтобы найти больше текста. Сложность в том, чтобы поставить один релевантный абзац выше всего, что лишь похоже по теме.

Когда более длинный контекст помогает

Более длинный контекст полезен тогда, когда ответ не лежит в одном аккуратном абзаце. Многие policy-вопросы охватывают два или три соседних раздела: основное правило, исключение и пример, который меняет применение правила. Если retrieval уже нашёл нужное место в документе, дать модели больше локального текста часто лучше, чем пытаться ранжировать мелкие фрагменты.

Это часто встречается в support и compliance. Политика возвратов может определять «цифровые товары» в одном разделе, указывать сроки в следующем и добавлять крайние случаи несколькими строками позже. Если модель видит только срок, она может ответить быстро и всё равно ошибиться.

Более длинный контекст обычно лучше всего работает, когда одновременно верны несколько условий:

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

Структура документа здесь очень важна. Если в инструкциях есть стабильные заголовки вроде «Право на участие», «Исключения» и «Примеры», retrieval может собрать компактный набор связанных фрагментов. Важны и даты версий. Они помогают удержать модель внутри одной редакции политики, а не смешивать старые и новые правила в один запутанный ответ.

Для более сложных случаев небольшая задержка обычно приемлема. Люди готовы подождать ещё секунду-две, когда спрашивают о спорах по биллингу, правилах доступа или условиях договора. Им важнее, чтобы исключение было учтено правильно, чем получить быстрый догадочный ответ.

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

Где реранкеры помогают больше всего

Реранкеры особенно полезны, когда поиск находит страницы с нужными словами, но не с нужным смыслом. В policy и support-контенте это происходит постоянно. Запрос вроде «Можно ли вернуть деньги после продления?» может совпасть с гайдами по биллингу, FAQ по отмене, старыми заметками о релизах и самим документом с политикой возвратов. Базовый поиск видит общие слова. Реранкер сравнивает полный запрос с каждым кандидатом и поднимает настоящий источник выше.

Они помогают и тогда, когда одна маленькая деталь меняет ответ. Support-команды постоянно сталкиваются с вопросами, где важен один признак: пробный или платный план, monthly или annual billing, личный аккаунт или workspace-аккаунт, 7 дней или 14 дней. Если retrieval упускает такую деталь, модель может звучать уверенно и всё равно ошибаться. Реранкер часто справляется лучше, потому что оценивает соответствие целиком, а не только совпадение слов.

Шумные FAQ-страницы — ещё одна частая проблема. FAQ хорошо ранжируются, потому что повторяют распространённые термины и охватывают много тем на одной странице. Беда в том, что они дают общие ответы, а реальное правило находится на странице политики, в заметке о ценах или в узкой help-статье. Более длинный контекст не всегда спасает. Если вы отправляете модели десять смешанных фрагментов, вы просите её самой разобраться в беспорядке. Иногда она справляется. Иногда цепляется за наиболее знакомую формулировку вместо правильного источника.

Реранкеры особенно полезны, когда вам нужен один короткий ответ, привязанный к одному ясному источнику. Это типично для policy- и support-потоков, где пользователи ждут прямого ответа «да», «нет» или ответа с условиями.

Возьмём простой пример: «Можно ли перевести неиспользованные кредиты в другой workspace?» Поиск может вернуть материалы по настройке, FAQ по аккаунту и страницу про billing credits. Настоящее правило может быть в маленьком разделе политики, где сказано, что кредиты остаются у исходного workspace и не переносятся. В таком случае лучше выбрать один-два лучших фрагмента, чем засыпать prompt длинной кучей связанных текстов и надеяться, что модель сама разберётся.

Как провести честный тест

Начните с реальных вопросов, а не с выдуманных prompt’ов. Возьмите 30–50 вопросов поддержки из тикетов, чатов или email-цепочек. Сохраните честную смесь: простые проверки политики, запутанные проблемы с аккаунтом и неудобные крайние случаи. Если набор слишком чистый, любая схема будет выглядеть умнее, чем она есть на самом деле.

Перед тестом запишите ожидаемый ответ для каждого вопроса простыми словами. Затем привяжите точный источник этого ответа — например, раздел политики, help-документ или внутреннюю заметку, которая должна его подтверждать. Гладкий ответ ничего не значит, если он цитирует не то правило или опирается не на ту страницу.

Прогоните один и тот же набор вопросов через три варианта: базовый retrieval, базовый retrieval с более длинным контекстом и retrieval с реранкингом. Всё остальное оставьте неизменным. Используйте одну и ту же модель, prompt и правила chunking во всех трёх случаях. Если менять сразу несколько вещей, вы не поймёте, что именно дало результат.

Каждый раз отслеживайте четыре метрики: точность ответа, совпадение с источником, стоимость одного ответа и время отклика.

Хорошо работает простая таблица оценок. Отмечайте каждый ответ как правильный, частично правильный или неверный. Затем фиксируйте, использовал ли система правильный источник. Для времени отклика не полагайтесь только на среднее значение. Медленные ответы раздражают пользователей сильнее, чем слегка неловкая формулировка.

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

Часто реранкинг помогает тогда, когда несколько документов выглядят одинаково, а только один содержит предложение, которое и определяет ответ. Более длинный контекст полезен, когда ответ находится в двух соседних разделах одного документа. Небольшой рост точности всё равно может быть плохой сделкой, если он добавляет целую секунду к каждому обычному support-ответу. С другой стороны, для юридических, billing- или compliance-ответов такая задержка может быть оправдана.

Пример для support-отдела

Пользователь пишет в поддержку после того, как уже использовал часть месячного сервиса, и спрашивает о возврате. Вопрос звучит просто, но help-center устроен беспорядочно. Одна статья объясняет текущую billing-политику, другая — promo credits и discount codes, а третья описывает старые исключения с прошлой миграции.

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

Вот где реранкеры часто помогают больше всего. Базовый retrieval может принести десять фрагментов, которые выглядят связанными. Затем реранкер оценивает их по точному вопросу, например: «Можно ли получить возврат после частичного использования?» В удачной настройке текущая billing-политика поднимается наверх, а старая заметка с исключением опускается так низко, что модель перестаёт воспринимать её как главное правило.

Ответ обычно становится короче и чище. Вместо того чтобы сводить вместе три политики, модель видит документ, который и должен решать этот случай. Тогда support-агент может ответить просто: при частичном использовании возврат по текущему плану не положен, а promo-условия не меняют это правило, если только аккаунт не попадает под указанное исключение.

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

Такой узкий сценарий обычно и есть разумный компромисс. Потратьте чуть больше времени на те редкие случаи, где порядок документов меняет ответ, и оставьте быстрый путь для обычных запросов.

Как задержка меняет выбор

Более правильный ответ не всегда означает лучший опыт, если он приходит слишком поздно. В policy и support люди в первую очередь оценивают скорость, когда они застряли в задаче. Покупатель на этапе оформления заказа будет ждать гораздо меньше, чем внутренний агент, который решает запутанный случай.

Это меняет способ использования реранкеров. Если модель проверяет правила возврата, ограничения по доставке или policy по возврату денег во время checkout, задайте этому пути жёсткий лимит времени и придерживайтесь его. Если реранкинг добавляет 600–900 миллисекунд, а качество ответа улучшает лишь немного, большинству команд лучше отказаться от него в таком сценарии. Быстрый ответ, который чаще всего верен, лучше медленного ответа, который приходит после того, как клиент ушёл.

Внутренние инструменты дают больше пространства. Support-агент в рабочем приложении может спокойно подождать лишнюю секунду, если ответ станет точнее и покажет правильный фрагмент политики. Такая задержка может сэкономить две минуты ручного поиска. В этом случае реранкинг часто окупается.

Тип устройства тоже имеет значение. Пользователи на мобильных устройствах чувствуют задержку раньше, потому что у них уже маленький экран, слабее соединение и больше отвлекающих факторов. Агент за рабочим столом сидит в рабочем процессе с клавиатурой, несколькими вкладками и понятной целью. Одинаковая задержка в 1,2 секунды на телефоне ощущается длиннее, чем на support-экране.

Измеряйте полное время ответа, а не только время retrieval. Если вы засечёте только retriever или реранкер, вы не увидите того, что реально чувствует пользователь. Отслеживайте весь путь от начала запроса до окончательного ответа на экране. Разбейте его на время, потраченное на retrieval, реранкинг и генерацию, а затем сравните это с качеством ответа и числом уточняющих вопросов.

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

Именно с такими trade-off’ами Oleg Sotnikov часто работает с командами на oleg.is: не гонится за самой «модной» схемой, а выбирает ту, что подходит задаче, бюджету по времени и цене ошибки.

Ошибки, которые искажают результаты

Большинство RAG-тестов льстят системе. Команды берут простые вопросы, используют чистые формулировки из исходных документов, а потом удивляются, почему оценки выглядят отлично. Реальные пользователи так не пишут. Они задают расплывчатые вопросы, смешивают в одном сообщении две проблемы или используют неправильное название продукта.

Честный тестовый набор должен содержать грязные вопросы. Добавьте короткие тикеты, policy-вопросы без важных деталей и prompt’ы, где используется обычный бытовой язык, а не язык документа. Если ваша support-команда часто получает «Можно ли ещё вернуть деньги, если я уже это использовал?», не заменяйте это аккуратной версией вроде «Какова политика возврата после частичного использования?»

Устаревшие документы портят тесты. Так же, как и дублированные страницы. Если retrieval приносит две старые страницы политики и одну актуальную, реранкинг всё равно может выбрать неправильную, потому что пул источников изначально плохой. До тестирования реранкеров очистите индекс, уберите почти дубликаты и отметьте, какой документ актуален.

Ещё одна частая ошибка — оценивать ответ как образец текста. Вежливый, гладкий ответ всё равно может быть неверным. Это особенно важно в policy и support, где одна неверная деталь может привести к возвратам, чарджбэкам или злым повторным обращениям. Сначала оценивайте фактическую точность. Если используете цитаты, следующим шагом оценивайте соответствие источнику. И только потом — тон.

Средние значения тоже скрывают неприятные провалы. Если 85 вопросов выглядят нормально, а в 5 ответах система выдумывает исключения к billing-политике, средняя оценка всё равно может казаться хорошей. Пользователи запомнят именно эти 5. Разбирайте худшие случаи вручную и группируйте их по типу сбоя.

Для каждого тестового прогона фиксируйте, нашёл ли retrieval текущий документ, появились ли в топе дубликаты или устаревшие страницы, скопировал ли финальный ответ неверную деталь и сколько задержки добавил каждый этап.

Ещё одна ловушка встречается очень часто: команды добавляют реранкинг до того, как исправят chunking и metadata. Это наоборот. Если chunks разрезают правила политики посередине или metadata не разделяет регионы, продуктовые линейки или типы планов, реранкингу почти нечего спасать. Сначала исправьте базовый retrieval. Потом проверьте, улучшает ли реранкинг сложные вопросы настолько, чтобы оправдать задержку.

Проверки перед запуском

Хорошего тестового прогона недостаточно, если живые данные беспорядочны. Policy-ответы ломаются, когда система читает старое правило, смешивает две версии или забирает chunk, который сваливает пять исключений в один комок. Чистый retrieval обычно важнее, чем ещё одна попытка подкрутить prompt.

Начните с контроля над самими источниками. У каждого policy-документа должна быть одна активная версия, понятная дата вступления в силу и простая метка, которая показывает retrieval-слою, какую версию использовать. Если старая политика возвратов лежит рядом с новой без даты, модель может ответить сразу обеими.

Размер chunks — следующий простой выигрыш. Держите chunks достаточно маленькими, чтобы в них помещалось одно правило, одно исключение или один шаг процедуры. Когда chunk охватывает право на участие, сроки, крайние случаи и внутренние заметки одновременно, реранкингу сложнее спасти результат. Маленькие chunks дают системе чистый материал для retrieval и сравнения.

У задержки должен быть жёсткий лимит до запуска, а не после жалоб. Установите бюджет по типу вопроса. Вопрос о сбросе пароля или статусе доставки должен ощущаться мгновенным. Подробный спор по policy может занять немного больше времени, если ответ станет заметно лучше. Если реранкинг добавляет 400 миллисекунд, но помогает только в редких крайних случаях, не включайте его в быстрых support-потоках.

Полезно также хранить небольшую коллекцию плохих ответов и использовать её повторно. Сохраняйте сам сбой, извлечённые chunks, финальный ответ и то, что ответ должен был сказать вместо этого. Двадцать неудачных примеров обычно учат большему, чем двести простых. Они ещё и не дают команде объявлять успех только потому, что средние оценки немного сдвинулись.

Выборочно использовать реранкинг обычно лучше, чем включать его везде. Он особенно хорошо окупается на policy-heavy вопросах, где два похожих правила могут изменить ответ. И намного меньше помогает на простых support-запросах вроде «Где мой счёт?» или «Как изменить email?». Для таких случаев чаще нужен быстрый поиск, а не ещё один проход ранжирования.

Короткий чек-лист перед запуском поможет:

• У активных policy есть видимые даты и нет дублирующихся живых версий.
• Chunks достаточно хорошо отделяют одно правило, чтобы человек мог быстро их просмотреть.
• Для каждого типа вопросов задан максимальный срок ответа.
• Известные сбои сохранены в отдельный тестовый набор.
• Реранкинг включён только в тех сценариях, где он выигрывает с заметным отрывом.

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

Что делать дальше

Начните с одного policy- или support-потока, который уже создаёт повторяющуюся нагрузку на команду. Выберите случай, который каждую неделю забивает очередь, например правила возврата, доступ к аккаунту или billing-исключение. Если тестировать на слишком расплывчатом или редком кейсе, результат не поможет принять реальное продуктовое решение.

Соберите небольшой тестовый набор, прежде чем что-то менять. Обычно 20–50 реальных вопросов достаточно, чтобы увидеть закономерности. Добавьте простые вопросы, запутанные вопросы и несколько тех, что обычно сбивают ассистента. Затем сравните две схемы рядом: простой retrieval с разумным окном контекста и retrieval с реранкингом.

Используйте простое правило для решения:

• Оставьте ту схему, которая даёт такой же уровень качества ответа при меньшей задержке.
• Добавляйте реранкинг только если он достаточно часто исправляет неверные или неполные ответы.
• Расширяйте его на другие потоки только после того, как выигрыш подтвердится на втором тестовом наборе.
• Останавливайте настройку, если вы добавили 500 миллисекунд, а пользователи всё равно получают тот же ответ.

Именно здесь многие команды теряют время. Они продолжают добавлять chunks, prompt’ы и model-tricks, хотя простая версия уже работает. Если более простая схема отвечает так же хорошо, оставьте её. Дополнительная логика ранжирования — не награда. Это ещё один движущийся элемент, который нужно запускать, мониторить и объяснять.

Если результаты всё ещё выглядят беспорядочно, перестаньте гадать. Когда настройки retrieval, формулировка prompt’а и инфраструктурные ограничения постоянно мешают друг другу, внешний взгляд может сэкономить много времени. Проблема часто не в самом реранкере, а в плохом chunking, слабых исходных документах или медленной инфраструктуре.

Именно здесь помогает взгляд Fractional CTO. Oleg Sotnikov работает со стартапами и небольшими командами над архитектурой RAG, компромиссами по задержке и решениями по запуску, особенно когда нужно сбалансировать качество ответа, стоимость и время отклика без построения большой платформы вокруг этого.

Для большинства команд следующий шаг — не «больше». Он — уже, точнее и основан на реальных данных поддержки.