前沿重器[70] | Query优化前沿综述：核心方法解读与个人实战启示 - 文章 - 开发者社区

前沿重器

栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）

2024年文章合集最新发布！在这里：再添近20万字-CS的陋室2024年文章合集更新

往期回顾

上期介绍了deepsearch中的有关技术（前沿重器[69] | 源码拆解：deepSearcher动态子查询+循环搜索优化RAG流程），里面有个突出的特点——query拓展，通过多个角度的拓展，一方面能让搜索的匹配程度得到提升，另一方面能让搜索引擎找到更多有关这个话题的内容，从而提升最终结果的可靠性，在本期文章中，将给大家介绍一篇query优化的综述，为大家拓宽思路，了解query优化方面的有关技术，让大家在应用过程中能有更多有用的选择。

论文： A Survey of Query Optimization in Large Language Models
链接：https://arxiv.org/abs/2412.17558

query优化的背景
query拓展
Query分解
Query消歧
Query抽象
挑战和展望
文章感受
补充个人经验

query优化的背景

在RAG系统中，如果搜索的结果不准，那大模型最终输出的质量就会大打折扣，而提升搜索效果的关键，在于优化query和doc之间的连接方式，除了优化匹配模型（例如bm25、向量），另一个方式便是对query和doc进行更为深入的理解和转化，在对query进行理解和转化的诸多思路中，对query本身进行优化和改写（query optimization/rewriting）是一个重要方向。

我在之前的文章里有系统聊过搜索系统内比较常用的query理解方案，放在这里，本文不赘述了（前沿重器[51] | 聊聊搜索系统4：query理解）。

query拓展

query拓展旨在捕捉更广泛的相关信息，可以揭示原始查询中未曾显现的关联，这一过程包括分析初始查询、识别关键概念，并融入相关术语、同义词或关联想法，以构建一个新的查询，从而实现更全面的搜索。这里的拓展，作者分为了两种模式，内部拓展和外部拓展。

内部拓展是指基于大模型或者系统内自有资源来进行的拓展。

类似HYDE、QUERY2DOC（前沿重器[38] | 微软新文query2doc：用大模型做query检索拓展）、REFEED都是先让大模型生成一些伪答案，因伪答案的语义空间通常和文档比较接近，所以搜索起来的匹配度就会很高。这也是为啥早年的FAQ检索式任务，都喜欢用Query-Query匹配，宁可挖掘、配置更多的拓展问用于匹配，也比一般的Query-Answer好做。
如果大模型生成的拓展并不合适，那就进行迭代调整，INTER、FLARE都有类似的思路，不断生成拓展、校验后再生成。
一条不够就多生成几条，MILL、GEN-QRENSEMBLE等就是这个思路，生成多样、多种内容，分别查询，通过这种冗余的方式，兼顾针对性和广泛性。（PS：上一期写的deepsearch源码解读内就有类似的工作，生成多个拓展问然后分别搜索）

外部拓展则可以依赖外部的信息源的整合进行进一步的拓展。

先查，再把查询结果用于生成新的拓展query，此时的再次搜索相当于对原有的检索结果进行补充。
不生成答案和query，而是生成伪参考文献，方便进行针对性搜索。

Query分解

query分解，按照文章的解释，是旨在将复杂的多跳查询有效地拆解为更简单、更易于管理的子查询或子任务。该方法把需要从多个来源或步骤获取事实的整体查询，分解为若干个更小、更直接的子查询，使它们可以逐一得到回答。

LEAST-TO-MOST会把一个复杂问题拆解成多个简单问题分别解决，进一步，还可以设置计划，PLAN-AND-SOLVE，把复杂问题有计划地处理解决，这个已经有一点Agent里面的Planner的意思了，与之类似的还有REAPER，甚至还构造出多种搜索策略的分解方案，ConTReGen、RAG-Star会构造出树结构的检索策略，PlanxRAG则会构造一个有向无环图（DAG）。
为了提升子问题的质量，可通过反复查询（SELF-ASK）、使用重排器（EAR）、知识矫正（COK）、筛选信息源（ICAT）。
也可以构造一定的反馈机制，让模型能逐步修正结果（REACT、AUTOPRM、RA-ISF）。
更进一步，需要关注query分解查询后的答案整合，HIRAG将原始query拆解成多跳查询后，用CoT进行整合，MQA-KEAL则会将搜出的内容整合结构化的知识单元，最后按需整合相应。

Query消歧

消歧也是Query拓展里的重要课题，旨在识别并消除复杂查询中的歧义，确保其含义明确无误。具体而言，就是找出查询中可能被多重解读的要素，并对查询加以精炼，使其仅有一种精准、无歧义的解释。

这里的消歧，文章把他分为了两种情况，语义本身的模糊，以及多轮对话过程的模糊。总体而言大概有这些思路。

基于自然语言的演绎推理格式，将推理验证过程分解为一系列逐步的子过程。说的更直白一些，就是对大模型CoT的过程增加必要的约束和验证，例如让他阐明必要的思路框架或者推理依据，从而提升推理能力。（Deductive Verification of Chain-of-Thought Reasoning）这种思路用在消歧内，可以提升消歧的精准度吧。
ECHOPROMPT则是进一步增强CoT，加入“让我们重复查询并逐步思考”的提示促使模型进一步思考。TOC通过使用少量样本提示和外部知识，为模糊查询递归构建一个消歧树，它检索相关事实，基于这棵树生成一个全面的长篇回答，从而提供更准确和详细的回应，说白了就是尽可能完整列举可能得歧义，并针对多个歧义问题进行分别回答。
ADAQR通过对话答案来提炼检索器的偏好，从而训练出更适合检索器的query，这个改写器能计算query到检索器获得答案的概率，这个概率可以作为奖励，训练出效果更好的改写器。MAFERW也是用了类似的反馈机制，CHIQ则利用早年NLP的思路，例如共指和拓展上下文，减少对话历史的模糊性。

Query抽象

query抽象旨在从更广阔的视角审视所需事实，从而带来更富多样性、更全面的结果。这一过程包括识别并提炼查询的核心意图和基本概念要素，进而构建一个更高层次的表达形式：既保留查询的本质含义，又去除具体细节。

大部分方案主要通过设计特定的提示词来引导模型，要求对query中的概念进行专门的理解和推理，也可以借助框架或者特定结构化思路的约束，在这个高层次的结构下，能够出去很多不必要的杂质，从而实现更准确的检索。

挑战和展望

在文章的最后，作者提供了4个可能有用的思路。

查询中心的过程奖励模型：通过构造奖励模型来约束整个检索链路，从而得到一个更为合理的多步检索推理策略，说白了就是一种对齐，合理、符合预期的思考模式还是要落实到具体的每一步，人和大模型之间的对齐还是非常重要的。
查询优化基准：缺少benchmark，缺少评估这个问题解决程度、解决质量的标准，这点和上一点我的理解可以说是一个共同的问题了，何为优化成功，什么叫做没优化好，最好的该是什么样子，尤其是一些复杂的场景，例如多轮优化、多轮检索的场景。
提高查询优化的效率和质量：目前大多数方案都是类似穷举的模式，为了尽可能全面，计算和检索成本会变得很高，未来可能可以探索出比较好的检索路径，提升效率。
利用性能反馈进行优化：大模型可能可以检测出用户真实意图，但是因为和检索器的联动并不一定紧密，可能搜出来的依旧不是靠谱的答案，这块仍有大量的研究空间。

文章感受

文章读完，感觉收获还是不少的，简单总结一下自己的感受。

很多改写的优化策略都值得在工业界中尝试，例如query的拆分策略之类的。
里面的论文提到很多，但是感觉很多论文里的内容就是一些策略的排列组合，或者就是换个说法，实际上操作起来都是类似的。
文章很多内容可能和改写的关系不大，但是会被归类在这里，被综述后总感觉和原论文的说法存在偏差。
很多任务做到深处后，实用价值被拉低很多，一个改写，多次改写甚至自己还要做一轮检索增强，后续的可维护性和性能问题会比较严重。
大部分文章缺少真实目的牵引，改写的核心目的是为了改写出利于检索甚至最终结果的query，但有些策略似乎只关注于能改写出“符合自己预期”的内容，内容并不一定有利于检索结果，更和最终的回复结果关系不大。

补充个人经验

改写一事，早在搜索场景就已经有很多研究和尝试，也有大量的实际经验，大模型的到来让改写的门槛被降低，开发和研究效率都有很大的提升。在这里，我补充一些自己看比较重要的经验和思路。

一定要明确目标，明确“需要改成什么样”，不要为了改而改，否则后续无论怎么改，都不一定有所谓的“符合预期”。但凡有了目标配合大模型，便能有一个“还不错”的结果。
改写层面，在现在大模型环境下，让大模型生成“伪答案”真的是一个下限很高的优化方案，因为能把检索词和文档拉到一个很接近的语义空间下。
某种程度，query理解也是一种改写，理解所得到的意图、实体等内容，能剔除很多不必要的信息，甚至直接可以做字面匹配，准确率直线上升。
query或特定词汇的归一化，包括同义词、拼音纠错等早年使用的老方案，在现在的实际应用中还很有用，举个例子，“KFC”和“肯德基”的语义距离，无论如何不会比“肯德基”和“肯德基”近。
关于消歧，值得单独讨论，对多轮对话，还是建议通过对话管理的模式来维护（DM，前沿重器[25] | 聊聊对话系统：多轮对话），从根本上解决多轮下的各种信息问题，至于本身query层面的模糊，除了拆解各种情况都进行回复之外，还可以考虑“澄清”，即通过主动询问用户的方式让用户澄清，这个澄清的模式很多，直接问、给选项选择之类的，都可以。
所有的query改写，都需要注意监控一个有没有改错的情况，以及有没有补救措施。做事就有错的概率，改写也是，而在后面，搜索精排也好，大模型推理也罢，都需要把原始query的信息给考虑进去，这样能有效避免答非所问的情况。

picture.image