心法利器
本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
2024年新的文章合集已经发布，获取方式看这里：再添近20万字-CS的陋室2024年文章合集更新，更有历史文章合集，欢迎下载。
往期回顾
- 心法利器[141] | 大模型学习的下一站
- 心法利器[142] | 大模型自动化标注：实战代码分享
- 心法利器[143] | 算法工作太枯燥？我的热情保持心法
- 心法利器[144] | 算法工程师深度、广度与高度的成长思考
- 心法利器[145] | 论文VS应用：算法工作的理想与现实，差距究竟有多大
生成式搜索，搜索领域在大模型版本下的一个突破性的尝试，并被大量研究者所重视，今天就来给大家总结性地聊一聊生成式搜索，让大家有一个更完整的认识。
目录：
- 什么是生成式搜索
- 生成式搜索的代表性工作
- 实践中存在哪些优劣势
- 强调一下数据更新的问题
- 后记
什么是生成式搜索
简单地，生成式搜索可以这么理解，让模型直接“生成”出与查询最相关的文档ID或内容本身。
这里，便要和之前的搜索（这里就先叫传统搜索吧）进行对比，传统搜索的基本模式便是Query理解、检索召回、精排最终得到最合适的文档列表，而生成式搜索并没有这些流程，他的结构更简单了，query进去后，经过一个模型，文档ID或者内容就都给生成出来了，中间的工作就是一个模型完成。
这个概念听起来就很酷了，这个模式可以说是很大限度地把大模型的优势给发挥了出来，即其扎实可靠的世界知识、强大的理解推理能力、可靠的语义理解能力，在前沿重器[59] | 淘宝LLM落地电商推荐实践启示里就有提到过这就是大模型相比传统推搜的一大优势），而且这正好就是传统推搜最缺的部分。
生成式搜索的代表性工作
首先，还是挖一挖历史，就像之前RAG我也喜欢考古一样（心法利器[112] | 考古RAG-20年RAG概念提出的论文），2021年的这篇：GENRE: Generative Entity Retrieval（https://openreview.net/pdf?id=5k8F6UU39V）使用BART尝试生成实体名称，提升检索效率，2022年谷歌的这篇：Autoregressive Search Engines: Generating Substrings as Document Identifiers（https://arxiv.org/abs/2204.10628），使用T5也做了类似的实验，我理解后者可能和我们理解的检索会更相似，效果属于尚可，论文是论证了这种可能性的存在，尽管当时的效果其实并不算优秀。论文里有这句话，现在的发展也证明了他们的猜测，现在视角再看这句话，真的挺浪漫的。
While our results show that SEAL could already compete with more established retrieval systems, we believe there is potential in exploring the use of existing (or yet to come) larger autoregressive models.
在2022年，A Neural Corpus Indexer for Document Retrieval（https://arxiv.org/abs/2206.02743）这篇论文提出的便是现在生成式搜索的重要范式，一个序列到序列模型，以query作为输入，直接输出相关文档的标识符。
这几年，在一些有代表性的大厂中，也涌现了生成式搜索的实践尝试，如小红书在24年10月对GDR（Generative + Dense Retrieval）概念进行了分享（https://mp.weixin.qq.com/s/yApGxCGxjWnZQu8PoO9Qeg），我理解这个分享一方面是将生成式搜索的概念进行了传播，另一方面也很中肯地指出了当下生成式搜索存在的问题，辩证地理解了这个概念，同时也给出了他们的解决方案。分享认为生成式搜索的本质就是记忆，在解码过程实现了query和候选文档的深度交互。
美团在ACL2025发表的这篇论文：Multi-level Relevance Document Identifier Learning for Generative Retrieval，提出一种基于多级相关性的生成式检索文档标识符学习方法（MERGE），通过分级的方式，让生成式搜索从考虑生成文档ID转化为丰丰富的语义信息，毕竟文档ID相比而言还是比较苍白。
当然了，生成式搜索的文章真不少了，这些应该是网上分享会被经常提及的部分，此处我就不赘述了，大家可以根据自己的要求自己看，此处推荐一篇综述：From Matching to Generation: A Survey on Generative Information Retrieval（https://arxiv.org/abs/2404.14851），这篇综述看第一版是24年4月的，但是后续改了几版，最近25年3月才有的更新，应该能覆盖一段时间内的关键工作了。
实践中存在哪些优劣势
要充分理解一个方法，理解他的优缺点还是非常重要，毕竟这直接关系着后续的应用。
首先，说一下优点。
- 端到端建模，整体结构比较简单，不需要做复杂的工程运维，也不再需要再构造索引存储数据，所有知识都以模型参数的形态存在。
- 在一些对比逻辑下，性能其实是要比传统搜索要快的。（注意，此处是一笔很精细的账，性能上并非生成式就优秀很多）
- 具有较强的可解释性和合理性，这点是大模型的一大优势了。
- 因为是端到端的，所以项目的启动节奏会比较快，直接训练就能有个“还行”的结果。
- 目测效果的上限会比传统搜索高的，大模型具有独特的理解和推理能力，加上训练后更深度的匹配识别能力（实质是对所有文档都做了匹配），理论上会更好一些。当然严谨的，要达到上限的难度还是不小的。
好了到缺点。
- 训练完以后搜索库就基本固定，无法进行灵活的增减和修改。
- 端到端的可更新能力较弱，对于搜索这种准确度要求很高的场景，小幅度的修改编辑很难做。
- 输出词表有限，而且数据稀疏下，因此对那种数据库很大的搜索场景，适配能力有限。
- 文档多了以后，细粒度的语义理解难度陡然增加，生成式的应对不佳。
强调一下数据更新的问题
个人理解生成式搜索的劣势还是比较硬的，尤其是在搜索库不断变化更新的场景下，生成式的灵活性问题就被放大很多，包括现在吹得比较火的小红书、美团等场景。小红书的笔记属于UGC，用户更新的速度绝对很快，大模型直接处理肯定会很难面对，美团的店铺虽然相对固定，但仍旧有很多更新，大模型肯定是无法适应的。
此时，我的视角一般是两个策略来解决这个问题。
- 生成式生成的是一个带有语义的token、自然文段解释或者向量，这个token或者向量是可以支持检索的，直接去查出对应的结果。随着知识库更新，查询的准确度提升，总能找到数据库内最接近的部分。
- 降低生成的复杂度，生成的是聚类得到的一个类目token，然后后续再用其他手段，查询到这个token下最合适的内容。后续的文档，基本都维护在类目token下，这样就让大模型绕开了这个更新不敏捷的问题。
诚然，这些思路都能有效解决数据库更新的问题，但大家仔细想，会发现有那么一丝熟悉的味道。（下面我还给了一些我写的老文章，大家可以比对着看这里的实际思路和任务结果差异，真的很像）
- 生成式如果生成的是一段文本解释来支持搜索，这和query拓展（如前沿重器[38] | 微软新文query2doc：用大模型做query检索拓展）所做的是区别不大了。
- 如果生成的是向量来进行搜索，那其实就和Embedding做向量搜索的区别不大了。（心法利器[16] | 向量表征和向量召回）
- 如果是聚类形成类目token，然后再来做进一步的搜索看，就和传统搜索里的意图识别，也区别不大了。（前沿重器[20] | 文本分类和意图识别调研思考）
说白了，大模型有一个很硬的问题，就是对内容的更新和细节调整能力比较差，类似这种更新需要依赖数据库来完成，与之类似的，像多轮对话里的Memory，之所以要外挂Memory模块，就是因为，新更新的对话内容无法在模型内部体现（估计会有人提到可以放在prompt里，但仔细想，这个模式本质也是一种外挂）。真要修改，那我们只能依赖微调，但是微调所需的数据和成本都不低，加一两条数据就训一次肯定不现实，盘下来，数据库真的是一个很好的辅助，这也是为什么我之前花很多时间学习和探索RAG的原因。
后记
说实话，一开始看生成式的这种应用，还是非常让人眼前一亮的，然而在我推导分析的时候就发现了这个数据更新的问题，这导致目前尽管有生成式搜索的研究在深入，但是在真正落地的是时候，仍旧无法全面推进和替代，更多是退化为一些传统搜索整个流程里的一部分，“数据更新”一直是萦绕在深度学习模型，尤其是现在版本下大模型的问题，我们很难精准的编辑大模型内存储的内容，而且伴随的可能还有遗忘的风险，这让我们如履薄冰，这块的研究肯定还有价值，也需要我们继续探索。
尽管推动端到端还是很难，但在这个思路的牵引下，伴随着另一条支线（DeepSearch/DeepResearch），整个搜索应用的研究，业界搜索系统的效果还是在长足推进，产品端也涌现了很多搜索工具或者功能模块，大家的搜索体验也越来越好，这也是一件不错的事了。