Переписывание запросов и HyDE

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

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

Самое простое преобразование: LLM переписывает пользовательский запрос в более ясную, самостоятельную и удобную для поиска форму. Она исправляет опечатки, раскрывает сокращения и удаляет разговорный шум.

Это особенно важно в многоходовом диалоге, где последнее сообщение непонятно без контекста («А как насчёт второго?»).

В диалоговой RAG объединяйте диалог и новый ход в один самостоятельный вопрос. Без этого местоимения и многоточия делают векторное представление бессмысленным, а поиск перестаёт работать.

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

Расширение создаёт синонимы, связанные термины или альтернативные формулировки, чтобы расширить лексическое и семантическое покрытие. Оно устраняет несоответствие словаря: в документе написано «invalidate», а пользователь говорит «revoke».

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

Создайте несколько разных переформулировок, выполните поиск по каждой из них и объедините списки результатов с помощью взаимного слияния рангов. Разные формулировки выявляют разные релевантные фрагменты; объединение сочетает их преимущества и стабилизирует полноту поиска.

За это приходится платить дополнительными вызовами поиска, но система становится устойчивее к неудачной формулировке отдельного запроса.

Для сложных многошаговых вопросов требуется декомпозиция на подвопросы, поиск по каждому из них и последующее объединение результатов. На вопрос о том, какой CEO компании, приобретшей X, старше… нельзя ответить с помощью одного поиска.

Разложите вопрос на части, выполните поиск по каждому подвопросу и позвольте генератору объединить собранные свидетельства.

HyDE (гипотетические векторные представления документов, Гао и др., 2022) меняет саму постановку задачи. Вместо того чтобы создавать векторное представление короткого запроса, система просит LLM сгенерировать гипотетический документ с ответом, затем создаёт векторное представление этого документа и выполняет поиск по нему.

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

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

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

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

Смягчите проблему, сочетая векторный поиск HyDE с поиском по исходному запросу через объединение результатов, чтобы неудачный гипотетический документ не мог полностью снизить полноту поиска.

Эти преобразования дополняют друг друга. Используйте конденсацию для диалогов, расширение и поиск по нескольким запросам при несоответствии словаря, декомпозицию для многошаговых вопросов и HyDE при несоответствии стиля вопроса и документа. Во многих производственных системах выстраивают цепочку: condense, затем HyDE, затем объединение с исходным запросом и переранжирование.

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

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

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

Основные выводы:

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