前沿重器[49] | 聊聊搜索系统2：常见架构

前沿重器

  栏目紧张给各人分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和各人分享，和各人一起把握前沿技术。详细介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）
  2023年文章合集发布了！在这里：又添十万字-CS的陋室2023年文章合集来袭
  往期回顾
  

• 前沿重器[44] | Adaptive-RAG:根据难度自适应检索方案
  
• 前沿重器[45] RAG开源项目Qanything源码阅读1-概述+服务
  
• 前沿重器[46] RAG开源项目Qanything源码阅读2-离线文件处置惩罚
  
• 前沿重器[47] | RAG开源项目Qanything源码阅读3-在线推理
  
• 前沿重器[48] | 聊聊搜索系统1：开篇语
  

  RAG在整个大模型技术栈里的紧张性毋庸置疑，而在RAG中，除了大模型之外，另一个不可或缺的部分，就是搜索系统，大模型的正确、稳定、可控生成，离不开精准可靠的搜索系统，大量的实验中都有发现，在搜索系统富足准确的前提下，大模型的犯错环境会骤然降落，因此，更全面、系统地相识搜索系统将很紧张。
  听读者建议，像之前的对话系统一样（前沿重器[21-25] | 合集：两万字聊对话系统），我也会拆开揉碎地给各人讲解搜索系统目前业界比较常用的架构、技术方案，目前的筹划是分为这几个模块讲解：
  

• 开篇语：给各人简朴介绍一下搜索系统的概况，以及现在各人比较关注在大模型范畴的发展环境。
  
• 搜索系统的常见架构（本期）：经过多代人的探索，目前探索出相对成熟可靠，适配多个场景、人力、生产迭代等因素的综合性方案。
  
• 文档内容处置惩罚：对原始文档内容、知识的多种处置惩罚方案。
  
• Query理解：对query内容举行剖析，方便后续检索利用。
  
• 索引和检索、粗排：利用query理解的结果，从海量数据中找到所需的信息。
  
• 精排：对检索的内容举行进一步的精筛，提拔返回的准确性。
  
• 其他搜索的附加模块：补充说明一些和搜索有关的模块。
  

  本期给各人介绍一下目前常见的搜索系统架构，这些架构多半是大厂经过实验探索得到的比较通用的方案，时至本日仍在被广泛利用，而且这些布局很大程度上恒本RAG的应用所鉴戒。
  本篇的布局和内容，会和之前写的对话系统雷同而且有所鉴戒（前沿重器[21-25] | 合集：两万字聊对话系统），思路上是参考案例然后是举行拓展和表明。
  目录：
  

• 先来几个案例
  
• 搜索的架构
  
• 架构背后的考量
  
• 架构和项目阶段的关系
  

  先来几个案例

  腾讯搜索架构

  起首放出来的是我在很早之前写的一篇有关腾讯搜索的架构文章（前沿重器[4] | 腾讯搜索的Query理解如何直击心灵），在这篇文章中，腾讯搜索给出的架构是如许的。
  

  这里把整个搜索引擎分别为7个模块，分别是客户端、AS、BS、Query理解、召回组件（搜索引擎）、排序模型和离线，各有各负责的部分。
  

• 客户端是向用户直接展示搜索功能的窗口，下属结果页、直达、联想词、干系搜索这几个部分，这也是搜索除了检索内容外的生态下其他内容。
  
• AS是高级检索，Advanced Seach，对外提供搜索引擎能力，在别的一些地方也有成为Center之类的，在我的视角下一般雷同BAT之类的厂商或者有关的职员，都会有这个AS的说法，不过其他厂商好像会比较少。
  
• Query理解，是对用户输入的Query举行完整美满的剖析，我们熟知的预处置惩罚、意图啥的就都放在这个部分，旨在抽取有利于后续召回、排序等步骤的信息。
  
• BS是基础检索，即Basic Search，完成根本的检索能力，文本（字面）召回、Tag召回、语义（向量）召回等都是在这个部分，直接面对的就是下面的搜索引擎了，架构上作者把排序，即精排和粗排也放在这里。
  
• 召回组件，这里我倾向于叫做搜索引擎，紧张是因为这个就是工程层面用于加快召回的各种检索的组件了，毕竟对于海量的知识，要快速查询出来，这个并不是一件容易的事。此处提到的是ES，即ElasticSearch，可以支持多种索引，至今仍然是很常用的搜索工具。
  
• 排序，这里夸大的是在线的LTR（learning to rank），团结更多其他信息来举行综合排序，注意此处不止有语义自己，还有一些额外的信息，比方文档的质量（如点击量）、用户偏好、时间热门等信息，这些信息很多都来源于离线的挖掘（利钱按模块负责），此时简朴的语义模型肯定办不到的，这里常用的模型和推荐系统很雷同，比方LR、XGBoost、Wide&Deep等，旨在融合多个来源的特征。
  
• 离线模块紧张是对各种离线数据举行处置惩罚，包括搜索文档、推搜日记的处置惩罚，这块有大量的工作，单独创建一个模块处置惩罚黑白常有必要的。
  

  电商搜索

  商品搜索给出两个例子，一个是我之前写过的淘宝搜索，另一篇是闲鱼搜索。
  先讲淘宝搜索内里的例子，在论文"Embedding-based Product Retrieval in Taobao Search"中，作者给出了淘宝内部检索引擎中的一个开端的架构，这个同样非常有代表性。
  

  商品搜索相比通用搜索带来的特殊性，这个我在上一期也有讲过（前沿重器[48] | 聊聊搜索系统1：开篇语），商品搜索的用户在风俗上多数是输入简朴的品牌、商品名词，这种简朴输入下符合检索词的物料就会非常多，为了举行进一步的精筛，就依靠其他信息，比方用户偏好，到了这一步，与其说是搜索，不如说是推荐了，协同过滤之类的招数就直接用上了。
  起首对query，作者举行了3个维度的处置惩罚：倒排字面检索、item协同过滤、向量表征检索（论文的重点），而后履历归并去重后，就开始进入排序了。排序内有相似度、重排，还有考虑内容视频、广告的归并等。
  别的这篇论文我也写过解读（前沿重器[18] | KDD21-淘宝向量检索），商品搜索是通用搜索下非常特别的一个品类，细致拼读有利于对这个方向的理解。
  然后是闲鱼搜索，这篇文章“电商搜索里都有啥？详解闲鱼搜索系统（长文）”，原文在：https://zhuanlan.zhihu.com/p/568564519（背面有空我应该也会专门写文章聊），这里直接给出他提供的技术架构。
  

  这个布局和前面的腾讯的布局非常接近，根本的query理解、召回等都有，只是分别会有些不一样，与之不同的是搜索干系的组件变得更加丰富。起首，各人应该比较关心的应该是推理的关键流程：
  

• 请求接入，进入应用层。应用层实质是内部服务对外的接口层，如H5、APP端的接入。
  
• 应用层请求排序接入层，这里的排序接入层是指到达核心搜索引擎内部。
  
• 意图预测。此处会举行各种query理解的工作。
  
• 搜索引擎。向底层数据库发起请求，举行内容的检索，重点是海选、粗排、精排3个阶段。
  
• 精排模型打分。对内容举行终极的筛选。
  
• 结果返回。重新返回到排序接入层、应用层、接入层，完成渲染，把结果有序返回给用户。
  

  而此中的不同点，我也整理了出来。
  

• 容灾，紧张针对服务，固然没有睁开说，不过提出来还是点出了安全的紧张性。
  
• 运营投放平台，一般是给运营利用的综合性平台，包括安全合规、广告平台等。这个的背后需要和算法等模块共同努力，才能让整个搜索系统更为可控稳定。
  
• 中控台。中控此处的概念会有些不同，内容好像比较杂，舆情、debug、评测、请求回放的功能都会放在这，实质看起来像是一个供给开发等职能的工作者举行分析和研究的工具。
  
• 离线，即图中的紫色部分，也给出了离线需要做的工作，包括离线的各种特征的处置惩罚、物料等内容的理解和入库、模型训练。
  

  RAG架构

  特别地，这里我把RAG的常见架构也写在文章里，这里我也根据之前我看文章的履历，把有关布局这块的讨论给出来。
  起首是，在科研界看来，RAG整体模块的分别，目前还在一个研究试验的阶段，无论是从RAG的综述来看（前沿重器[41] | 综述-面向大模型的检索增强生成（RAG）），还是在论文的讨论上看（CRAG：前沿重器[43] | 谷歌中科院新文：CRAG-可改正的检索增强生成、self-RAG：前沿重器[42] | self-RAG-大模型决策的典范案例探究），都在非常大胆的实验中，其核心缘故原由是，需要探索Retrieval和大模型如何更好地团结，希望以更低的消耗成本达到强化效果的效果，在这个缘故原由下，研究的中心不会局限在检索自己，但重点还是离不开优秀的检索模块，在综述来看，RAG在布局上的研究，可以简朴地用这个图表现。
  

  显然，模块化应该是高级RAG后续发展的共识，但详细如何分别模块，分别逻辑该是什么样的，有待进一步的实验验证，但归根结底还是离不开“Modular”这个单词。
  有意思的是，如何模块化这点，在被深入研究，内里分别的模块在现在比较前沿的搜索系统中还是会出现的，如Rewrite对应的是query的改写，decide、rank、rerank的设计思路和检索模块的粗排、精排、重排的概念也非常相似，大有向现行搜索系统的架构靠近的倾向。
  然后让我们把目光聚焦在开源项目上，之前连续3篇给各人介绍了国产RAG开源项目QAnything的源码：
  

• 前沿重器[45] RAG开源项目Qanything源码阅读1-概述+服务
  
  
• 前沿重器[46] RAG开源项目Qanything源码阅读2-离线文件处置惩罚
  
  
• 前沿重器[47] | RAG开源项目Qanything源码阅读3-在线推理
  
  

  其紧张架构如图所示：
  

  内里的架构是比较接近综述内所提及的Advanced RAG的概念，紧张就是分了3块：
  

• offline：离线的文档切分梳理模块，该内容终极会入库。
  
• embedding&search：向量模型和检索服务，内部提到了milvus向量检索服务和经典的Elasticsearch。
  
• LLM服务。
  

  这里的检索，利用的两阶段排序，这个也和现在比较完整的搜索系统架构也非常接近，有关这点，作者在README内有专门举行表明。
        知识库数据量大的场景下两阶段上风非常明显，假如只用一阶段embedding检索，随着数据量增大会出现检索退化的题目，如下图中绿线所示，二阶段rerank重排后能实现准确率稳定增长，即数据越多，效果越好。
   

  第三想和各人分享的是我对RAG系统的理解，我自己是有对落地架构举行过讨论，（RAG落地架构：心法利器[113] | RAG布局思索：搜索系统范式和大模型作用压缩），内里详细讨论了我对RAG架构的设计思路，并给出比较严谨的迭代思路，可以看到，在Retrieval部分，我的思路同样是比较接近现在的搜索系统的，因为从搜索系统角度来看，RAG是对搜索系统的又一次新的应用，且RAG在搜索层面，大部分环境下和传统搜索的目标是一致的——检索精准，既然云云，本来搜索系统所总结的履历，在现在RAG的应用中，想必也很有参考价值。
  搜索架构

  纵观上述多个不同场景搜索系统的案例，我们可以看到，比较统一的分别方式，通常有如下部分：
  

• 离线部分：紧张是内容理解工作，别的还有用户画像等工作，按需增加。
  
• Query理解：负责对用户query举行处置惩罚，并提取卑鄙检索、排序所需要的信息。
  
• 检索召回：从数据库中快速找出符合的内容，并举行阶段。
  
• 排序：对内容举行精筛，找到最优的TOPN内容。
  

  总结下来，这4个应该是成熟的搜索系统比较关键的4个模块，内里的功能模块组大概并不一致，但是根本都会按照这个布局来分别工作，内部的功能也相对独立。
  搜索不可或缺的一部分就是物料，即被人检索出来的材料，这个内容无论是为了展示还是方便检索，都需要离线举行各种处置惩罚，比方清洗、合规性检测、标签实体抽取、embedding等，别的还有一些雷同用户画像、模型训练的操纵也是放在这里，这些都是不可克制、且不方便放在在线做的工作，这些流程不需要或者不方便跟随整个用户query请求流程做，此时就要离线或定时或实时地处置惩罚。
  Query理解是逐步从检索流程拆解出来的模块，要对范畴分别分别处置惩罚需要意图辨认，要抽取实体举行精准匹配需要实体抽取，要举行向量召回要向量化，这些本质上都是为了卑鄙检索、精排而做的预备，同时又是针对输入query举行的针对性处置惩罚，Query理解就由此诞生。这个可以说是传统搜索在字面检索期间的产物，时至本日向量化已经蓬勃发展，但因为向量化仍无法一统江湖，所以完整的Query理解甚至是内部的意图、实体抽取工作，仍有作用，而且还是不可或缺的作用，甚至到后续的Agent崛起，比方“路由”模块的作用，仍和Query理解里的意图辨认很接近。
  检索召回，指从海量的数据库里找到符合要求的内容，这里关键依靠的是搜索引擎，内部的通过多种数据布局的方式，把检索的时间复杂度降到最低，尽大概要求检索速率和库内数据量的关系降低，从而达到快速查询的效果，一般比较牛的检索引擎能让速率降低到几ms的级别，大大提拔服从，把时间留给其他部分，如精排、生成等。
  排序模块的核心目标，是把检索召回的内容举行精筛，筛选出最符实用户要求的内容推送给用户，尽管不同的系统排序的逻辑不同，甚至还有多次排序，但排序模块作为确保搜索精准的最后一道防线，在架构设计上一直屹立不倒。
  搜索架构设计逻辑

  回归搜索的核心目标，给出符实用户query表达需求最佳的结果，要分裂出两个方向：
  

• 内容，即物料，要足量，要处置惩罚好。
  
• 充分理解用户需求，即对应用户query，要照着用户query提供的信息查询内容。
  

  对前者，要求内容的完整性、真实性，且为了更方便检索，需要构造索引，就跟图书馆要有索书号一样，而且为了多个角度都充分找到，需要对内容举行尽大概多角度的表征，就这点要求而言，一般的向量，尤其是一个向量，很难完成这事，传统的布局化方案反而更容易、且可表明地找到，比方作者、年份、类目、标签、书名，都能提取，则对于用户而言，这几个方向都能轻松定位到详细内容，因此，内容理解成为非常必要的部分。
  后者，这里首要的一个内容就是query的理解，而理解query是为了背面的查询用的，同样以图书检索为例，用户大概搜书名、作者、年份、标签，我们需要充分提取这些信息，以便更快从对应字段中搜出来，这就是query理解。
  在理解以后，则需要根据query理解检索内容举行查询了，对早期项目，查询出来根据开端的相似度排序截断即可，而为了更加精准，大概会有更严格的二次排序，亦或者根据用户偏好举行更有针对性的筛选，比方同样是“统计”，大概是数学类、金融类的统计，可以根据用户的研究配景来精筛，此时就有从检索中分裂出了召回和精排两个工作。
  有关召回和排序的拆分，在几年前我也对这个现象举行了分析和表明（心法利器[15] | 准招分治效果调优方案），提出过一个概念——准招分治，即对准确率和召回率都比较高的时候，可以通过拆分这两者到两个模块中来举行的方式来分别调优，召回阶段负责从多角度召回大量的结果，这里也维护了搜索系统的多样性，很好地克制了召回单一内容的尴尬，提拔召回率的同时，肯定程度也控制了准确率不至于太低（这里指不干系的肯定不在这一轮漏斗里），而准确率的提拔可以来背面的排序，借助更多维度的信息来分析那几个更适合排到前面，固然拿了，可以通过打散等方式来增加多样性，于是起到了提拔准确率而控制召回率的题目，控制召回率过低的环境。
  别的有关多阶段排序的进一步表明，参考前面QAnything的讨论，从模型层面也可以初见端倪，一般的两阶段排序下的模型负责的使命并不相同，第一阶段的排序要负责区分“干系”和“不干系”，这本质是个二分类的题目，用简朴的0-1样本根本都能做得很好，但是大量的实验表明，对于前排的几个，区分度其实并不会很高，因为相似的物料相似度根本都集中在0.9+，甚至0.95+，这块的排序效果并不是很好，此时假如再有一个模型可以优中选优，则会更加理想，这一步本质是个“排序”题目，区分的是“谁更好”，此时LTR，即learning to rank会更优秀，假如需要样本，在线的点击或者人工标注的排序样本会更加符合，固然难度更高但是效果会很明显。
  架构和项目阶段的关系

  在之前聊对话系统架构的时候，有专门聊这个（前沿重器[22] | 聊聊对话系统：技术架构），此处再团结搜索系统重新聊。
        抛开需求谈架构绝对是不符合的。
    放在搜索系统里亦然，假如是项目开端创建的阶段，搜索系统并不需要上面的所有内容，只需要满意一个baseline即可。以之前我写的basic_rag项目为例（心法利器[105]  基础RAG-大模型和中控模块代码（含代码）），这里就没有意图辨认之类的模块，检索部分非常简朴，就是一个向量推理+FAISS检索就完事了，对于搜索系统就是差不多如许子。
  下面团结项目发展阶段讲讲各个阶段的迭代建议。
  0-1版本

  早期的搜索系统，可以直接把query扔进检索引擎举行检索就可以，这里一般是两条路，是目前很常用的做法：
  

• ElasticSearch之类的系统搭建起检索模块，query可以直接举行字面检索，ES自带BM25排序后直接截断即可。
  
• 用通用的向量召回模型对物料和query都做向量化，然后走雷同Milvus、FAISS的方式向量召回。
  

  个人建议优先考虑前者，前者固然泛化能力不行，但是准确率是比较可控的，甚至可以配合cqr+ctr（心法利器[99] | 无监督字面相似度cqr/ctr源码）的方式举行精排再把控一层，至少能出的内容还是相对可靠的，这符合搜索中的关键要素——准确。
  后者固然泛化能力强，但是后者对不对称内容的能力并不突出（即雷同QA匹配的相似度），而且即使内容对称，细节内容的不稳定性也比较难把控，这个相比泛化能力而言还是比较致命的，可以考虑会上，而并不要着急第一个版本上，有大概为第一版上线带来风险。
  注意，第一版每每需要把大量时间花在基础布局、基础代码、中间件的创建上，且发版存在工程和算法上的风险很大，因此在算法层面，需要用更稳定、可预见、可控的方案，尽大概降低这方面的风险。
  中期

  等到baseline完成后，就已经到中期了，中期可以开始联实用户反馈、第一版遗留题目开始，以终极架构为蓝图逐步搭建完整的搜索体系。
  query理解模块可以逐步创建起来，有目标性地、分门别类地处置惩罚题目，能显著地在关键题目上得到提拔（时候注意bad case分析，详细可参考bad case系列：心法利器[40] | bad case治疗术：办理篇）。
  多路召回，配合现有的召回缺失题目（一般不会那么快袒露），开始增加召回链路，并以多路召回融合为契机，开始规划精排，从早期的规则精排开始，逐步过渡到模型精排，记得保留肯定的可控可配置能力。
  后期

  后期的整体架构逐步完整，场景特异化题目开始逐步突出，即出现自己场景所特有的一些题目，这时候就会转为研究型或者探索型的使命了，比方前文有提到的淘宝搜索，对用户画像等举动的表征和处置惩罚，另一方面，可以开始平台化或者通用化的沉淀，形成通用的NLP、运营平台，降低业务拓展成本，再者，也可以考虑做雷同query推荐、干系搜索、多轮搜索等内容。
  小结

  本文通过多个成熟的案例，分析了搜索系统常见的架构，提炼出搜索系统目前比较常见的拆分模式，并在最后给了迭代思路，本文有6000多字，写得好刺激，希望各人能喜欢~
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。