Преобразование запроса полезно тогда, когда лечит конкретный сбой в поиске. В декоративный слой оно превращается в ту минуту, когда его добавляют просто потому, что на схеме чего-то не хватало.
Точечное преобразование
Запрос меняется, чтобы исправить известную проблему поиска.
- лучше полнота на смутных вопросах
- лучше маршрутизация по корпусу
- измеримый выигрыш в качестве top-k
Преобразование ради галочки
Система добавляет шаги просто потому, что так выглядит «сложнее и умнее».
- растёт задержка
- сложнее разбирать сбои
- поиск по-прежнему промахивается по старым причинам
1. Преобразование запроса — это не одна техника
Очень часто о преобразовании запроса говорят так, будто это один общий приём. На деле это несколько разных семейств техник:
- переписать вопрос в более явный вид
- разложить один вопрос на несколько меньших
- сделать более абстрактный step-back вопрос
- сгенерировать гипотетический ответ или документ, как в HyDE
- прогнать несколько вариантов поиска и затем их слить
У них разная задача. Если смешивать их в одну корзину, получится уверенная, но бесполезная аналитика.
2. Rewrite нужен прежде всего тогда, когда проблема в самом вопросе
Самый простой случай по-прежнему частый: пользователь задал вопрос коротко, смутно или с пропущенными сущностями.
Например:
- «Что изменилось после прошлого?»
- «Это вообще можно по политике?»
- «Сколько теперь длится?»
По таким формулировкам искать тяжело. Rewrite помогает восстановить недостающие объекты, сделать явными время и предмет запроса.
Это, как правило, самый дешёвый шаг преобразования. И одновременно один из самых лёгких для злоупотребления.
Если исходный запрос и так хороший, rewrite часто только добавляет задержку.
3. Decomposition полезен, когда ответ действительно требует нескольких поисковых ходов
Decomposition хорош там, где пользователь думает, что задал один вопрос, а корпус требует нескольких отдельных lookup-шагов.
Типичные случаи:
- сравнить две политики
- ответить на вопрос, где есть и основное правило, и исключение
- собрать ответ из нескольких фактов, лежащих в разных местах
В этих случаях один поисковый проход часто проигрывает, потому что каждый под-вопрос тянет свою опорную точку.
Цена понятна заранее: больше поисковых проходов, больше задержки, больше мест, где можно случайно испортить итоговый контекст.
Поэтому decomposition оправдан, когда задача и правда составная. Если проблема в плохом корпусе, он только добавит шума.
4. Step-back prompting нужен для поиска по понятию, а не для красоты
Step-back prompting работает так: система сначала формулирует более общий вопрос, а потом ищет и по нему тоже.
Это особенно полезно, когда прямой запрос слишком конкретен и не вытягивает само понятие, которое управляет ответом.
Например, узкий рабочий вопрос может лучше искаться, если система параллельно задаст себе более общий вопрос про принцип правила или юридическую категорию.
Выигрыш здесь — в концептуальном recall. Цена — дополнительный модельный вызов и ещё одна поисковая ветка.
Если корпус уже аккуратный, а сам вопрос хороший, step-back часто почти ничего не даёт. Если пользователь крутится вокруг понятия, которое сам не может нормально назвать, техника может помочь сильно.
5. HyDE — это поисковый трюк, а не способ стать умнее
HyDE строится на том, что система сначала генерирует гипотетический ответ или документ, а потом ищет уже по embedding этого синтетического текста.
Смысл вполне прагматичный: сам пользовательский вопрос может быть слишком коротким или неровным для хорошего семантического поиска, а гипотетический ответ иногда даёт более полезную точку для поиска.
Это может поднять recall. Но может и очень уверенно увести поиск вокруг неправильной идеи, если гипотеза поплыла.
Поэтому я воспринимаю HyDE как поисковый инструмент, а не как усилитель мышления. Измерять его надо качеством top-k, а не восхищением.
6. Fusion полезен, когда несколько слабых взглядов вместе становятся одним хорошим набором
Fusion-подходы запускают несколько поисковых веток и затем сливают результаты, часто через rank-based aggregation.
Это разумно, когда разные варианты запроса и правда находят разные, но полезные опорные фрагменты.
Это менее разумно, когда:
- все ветки в целом возвращают одно и то же
- корпус маленький, и одного хорошего поискового прохода уже достаточно
- reranker и так вычищает почти всё полезное
Fusion может отлично работать. Просто у него есть привычка выглядеть нужным раньше, чем он это реально докажет.
7. Считать полезно не «сработала ли техника», а «сколько пользы она дала на миллисекунду задержки»
Практический вопрос здесь не такой:
«Мы добавили умный шаг преобразования?»
А такой:
«Насколько выросло качество найденных опор на каждую добавленную миллисекунду и на каждый новый сценарий сбоя?»
Для каждой техники я хочу видеть:
- качество top-k до и после
- эффект на reranking
- добавленную задержку
- какие классы сбоев она лечит
- какие новые классы ошибок создаёт
Без этого архитектура начинает казаться лучше только потому, что стала длиннее.
8. Большинству систем нужно меньше техник, чем им кажется
Если корпус подготовлен нормально, а пользовательские вопросы чаще всего вменяемые, дефолтный стек может быть коротким:
- прямой поиск
- при необходимости rewrite для слабых формулировок
- reranking
- answer
Всё остальное стоит добавлять только тогда, когда есть устойчивый класс промахов, который иначе не лечится.
Обычный порядок, которому я доверяю, такой:
- привести в порядок корпус
- улучшить базовый поиск
- добавить reranking
- и только потом избирательно тестировать отдельные техники
Это менее зрелищно, чем диаграмма с пятью ветками. Зато гораздо легче дебажить.
9. Полезная стартовая матрица
Если выбирать быстро, я бы пользовался такой схемой:
| Симптом | Первый ход |
|---|---|
| запрос расплывчатый или обрывочный | rewrite |
| ответ зависит от нескольких разных фактов | decomposition |
| прямой запрос не достаёт управляющее понятие | step-back |
| semantic recall слаб на коротких или неуклюжих вопросах | HyDE |
| разные варианты запроса вытаскивают разные полезные источники | fusion |
| поиск плохой, потому что корпус грязный | сначала чинить подготовку корпуса |
Последняя строка тут делает почти всю работу. И правильно.
Что бы я внедрял первым
Я бы не строил сразу пять техник и не надеялся, что одна из них красиво спасёт систему.
Я бы:
- собрал реальные промахи поиска
- разметил их по классам ошибок
- протестировал по одной технике на каждый класс
- оставил только те шаги, которые действительно улучшают опорный набор настолько, что это оправдывает задержку
Системе не нужна более богатая теория промптов. Ей нужна честная причина для каждого лишнего шага.