AIAPI - 转向 AI 原生检索
导读
大型语言模型（LLMs）展示了非常强大能力，但在实际应用中仍旧有一些问题需要解决，比如幻觉现象、在垂类细分场景下的知识更新较慢，以及在回答中缺乏透明度（模型黑盒问题）等。检索增强生成（RAG）是在使用 LLM 回答问题之前，从外部信息系统中检索最新，最相关的信息，再借助 LLM 的生成能力，生成准确的结果。在多方论文和文献中，RAG 已被证明其有效性。
百度作为全球最大的中文搜索引擎，收录了超过千亿的中文网页数据库，为用户提供准确、高效、便捷的搜索服务。百度搜索系统经历了 20 年的搜索产品演进，系统的目标是高效的为人们解决信息检索问题，经过数据抓取、收录、检索，排序和展现，为用户提供准确、易用的搜索服务。但是对于大模型来说，人类易读的搜索结果内容却不便于模型对内容抽取和理解。
在 RAG 场景下，提出了一个既要又要的问题：一方面希望能够利用百度检索排序的优质策略，保证数据的高相关、高时效和多样性，为大模型提供完整的全文结构化内容；另一方面又希望用更低的检索成本、更高的时延要求给大模型的内容精细化组织预留足够的空间。在此背景下，我们启动了 AIAPI 项目，为大模型提供更加 AI 原生的检索能力。
01 RAG 简介
1.1 什么是 RAG
RAG（Retrieval-Augmented Generation）检索增强生成。检索是方法，生成是目的，通过高质量的检索系统，解决 LLM 生成过程中的一些问题。从当前 RAG 模式上，LLMs 时代 RAG 的发展基本三种范式：简单型 RAG(Naive RAG)、高级型 RAG(Advanced RAG)和组件化 RAG(Modular RAG)[1]。
简单型 RAG：遵循传统的过程，包括索引、检索和生成，通常也称之为『检索-读取』框架 。 Advanced RAG：专注于提高检索质量，高质量的检索结果为 LLM 生成的提供了非常稳定，正确的数据源。
Modular RAG：采用了多种策略来改进其组件，例如添加用于相似性搜索模块(需要有一定的泛化能力)以及通过微调来改进检索器。Modular RAG 方法正在变得普遍，尽管具有独特性，Modular RAG 仍建立在 Advanced RAG 和 Naive RAG 的基本原则之上，体现了 RAG 进步和完善。
1.2 百度搜索：RAG 中 R?
在检索增强生成的背景下，检索质量的优劣在很大程度上影响了生成模型的最终生成结果的优劣。百度在提升检索质量等方面做了很多卓有成效的工作。
但是 RAG 不是 R and G 的简单结合。百度搜索经过多年的产品迭代和技术演进，搜索产品策略逻辑、中间态的数据结构和特征表示非常复杂。从功能上看，百度搜索的在线拓扑架构、排序召回策略设计，特征建设、检索结果的摘要/标题计算、飘红策略等都是围绕最大限度的提升用户体验和检索效率这个目标而构建，如图 1 所示；从数据资源维度看，百度除了拥有千亿级别的互联网数据外，还有有很多非常优质的自建资源，比如阿拉丁资源，但其中大部分是基于业务需求定制化的数据。这些数据内容虽然优质，但是对于大模型来说，明确其数据结构和意义是一件成本非常高的事情。
△图 1
直接复用搜索产出结果，在模型生成前需要对数据进行清洗，筛选和结构化整理。这无疑对在线生成系统增加了复杂性。那么再为 LLM 的需求搭建一套类似系统呢？答案当然是否定的，其原因不仅仅是巨大资源成本开销无法满足，更多的挑战源于两套系统下的开发，效果打平和运维成本的翻倍。
我们要寻找一种架构解决方案，能够同时高效支持搜索业务场景和大模型生成场景。既能复用百度搜索技术，保证高质量的检索效果；又能做到对用户/大模型请求的系统 QoS 分级表达，在大模型场景下提供更低成本、时延的套餐方案来满足差异化 QueryPlan 生成。
02 AIAPI 设计概述
2.1 AIAPI 的设计要求
AIAIP 的设计要求是为了提供更好的检索效果用于模型生成，同时又兼顾资源，速度，效率等需求。要求从系统层面到数据效果层面均有比较大的提升。为了更好的拓展接口和能力，Aiapi 设计了一整套标准协议，保证了接口的高可解释性、可扩展性，增强大模型对检索内容吸收理解能力；同时提供基于 QueryPlan 的多级 Qos 系统控制，在保障效果的同时追求成本控制的极限；
数据上：
优质：优质性包括了数据来源是权威的、可信的、优质的、实时的。在大模型场景下权威优质库带来的体验提升可能远大于全网库。从号和站的角度，去做先验的判断，也一定程度上可以提升权威性和内容的可信性；同时搜索产品积累的大量丰富的用户后验的特征信号，可以更好的反馈生成系统，提升大模型生成质量。
完整：只言片语或者跟检索词高相关的飘红信息对于人来说是有帮助的。能够帮用户快速判断这条结果的价值。而对于 LLM 来说，在 token 数量有限的场景下，尽可能的给模型完整的文本内容或者检索命中的上下文关联信息比给经过展现策略优化的摘要好得多。不完整的摘要反而会诱导模产生幻觉。
结构化表达：高效简洁可解释的结构化接口对于大模型来说是非常重要的。有助于大模型的内容理解。百度搜索在产品化演进过程中，阿拉丁资源是非常重要的一个组成部分，但是阿拉丁资源数据结构定制化高，除了阿拉丁之外，视频，图片等资源也不是统一的结构化数据来表征。因此需要设计一套统一的结构化且有明确语义的接口，将检索结果的内容 改为对 LLM 更友好的结构，数据层级更加扁平，其中 key 的语义更加明确。
系统上：
低时延：大模型检索增强的首 token 时延，会对用户的体验带来较大的影响。应该尽量压缩检索系统的整体时延。传统检索系统中的一些步骤（例如混排，摘要飘红计算，出图策略等）对于大语言模型不是必须的。同时在面向用户的检索产品中，由于展示位置有限，在排序中的精排阶段消耗了比较大的时间，但是对大模型而言，第一位和第二位的资源排序对其来说可能不是那么重要。因此基于搜索产品效果的策略集合在检索增强场景下存在策略裁剪的空间。
成本控制：对于收录全网内容的检索引擎来说，在大模型生成场景下，可控的成本一定是生成模型对系统的要求。否则资源会成为模型生成效果的一大制约条件。特别是在当前 RAG 设计场景下，仅仅一次生成往往不能满足需求，在生成时会有多轮次生成过程:迭代检索，在文本生成过程中涉及多次检索迭代，以实现动态信息集成，如图 2 所示。这种情况下检索成本是成倍数放大的。因此检索成本成为了系统设计中非常重要的一个指标。
△图 2
2.2 AIAPI 的系统分层
百度当前的搜索产品细分为基础检索、生成式检索以及多轮对话检索三大类别，此外还囊括了文心一言这一大型语言模型应用。具体产品阵列展示如图 3 所示：
△图 3
面对既要提升效果又要优化系统资源利用率的双重挑战，如何在百度既有的技术框架基础上，以最小的工程代价开创一条全新的检索路径，对当前搜索架构分层提出了要求。
第一步，召回和排序层复用。在召回排序层，尽可能复用了当前排序和召回的架构，主要原因是对成本和效果的双重考虑。对于在 AIAPI 场景下的差异化需求，基于流量、接口控制参数，提供了若干套套餐组合。使得业务可以根据自己的业务场景定制最合适的套餐组合，提升 AIAPI 的灵活性。
第二步，在数据层进行能力拓展。数据层的主要功能是对不同的流量来源做不同路由控制和数据加工（统一检索增强场景下的数据表达方式）。在数据层使用图引擎能够高效实现对不同流量的隔离和定制化数据处理。同时增加网页内容获取能力，添加对结果类型（主搜、视频、不同阿拉丁）的筛选和数据组织能力，便于业务侧做 Query Planning；出于成本和速度方面考虑，数据层还设计了不同的缓存方案。
第三步，将上层的展现层进行了拆分，即检索流量和 AIAPI 的生成流量在展现层是不同的。主要原因是搜索产品的前端数据渲染和数据的处理在 LLM 生成场景下是无法复用的，同时在 AIAPI 场景下基于用户的鉴权，流控，特征管理等功能是需要同步建设的。针对速度、效果、成本不同倾向的需求，提供分级的 API 能力，便于用户选择；
△图 4
03 AIAPI 场景下的架构升级
3.1 双通道
△图 5
在一套检索框架同时支持传统搜索业务（P 请求）和检索增强（R 请求），从架构视角看，两类请求是两个不同的数据通道，但是两个通道间还在一些阶段存在交集。拓扑关系示意图如图 5 所示。基于上述要求，我们将数据模式抽象为三种情况况：
仅有 P 请求：常规的检索请求，同时可以低成本预充 R 请求中 P 流量库结果 cache；
仅有 R 请求：Rag 的相关请求，优先复用 P 请求下的召回结果，如果没有可以复用的 P 请求召回结果，会触发一次新的检索，同时在排序层根据业务需求选用排序策略套餐进行排序；
P+R 混合请求：常规检索中在 query 分析阶段用户主要意图，比如问答类、建议类需求下，会生成先验特征信号，在混合请求场景下，100%复用召回和排序的计算过程。
假设：产品请求的召回结果集是针对该次请求最完整的结果集合，同时召回效果也会随着业务发展持续提升。那么产品请求的召回结果是完全可以满足检索增强请求的召回需求。而在资源层面，我们希望达到 1(产品请求) + 1(增强检索请求) < 2 次检索召回成本开销。这样就达成了效果最优的同时资源开销最小的目标。
该目标达成缓存系统也发挥了非常重要作用。一套灵活的 cache 方案可以极大提升整体系统的吞吐，减少重复计算。同时 cache 系统对检索系统的稳定性也起到了非常重要的作用。
3.2 完整内容获取方案
关键设计点：
展现策略解耦：产品搜索结果的摘要等内容信息获取在排序层，实现基于 Query 做的复杂段落选取、飘红等展现策略。而检索增强结果不依赖展现策略，可以与展现策略拆分；
内容加工效率：为了满足不同业务的内容定制化能力和提升内容获取效率，该服务在存储访问，数据加工等阶段使用动态并发处理模式，如图 6 所示，保证在返回结果数过多场景下的时延和效率。
△图 6
cache 存储优化：检索增强场景下数据 Cache 在数据层和排序层之间，为了减少了 cache 的存储开销，需要将内容获取上移到 Cache 层之上，最终 R-Cache 的存储成本降低 70%左右。
04 评估
基于百度文心 4.0 大模型的 gsb 评估结论：评估结果表明**AIAPI 优质检索结果占比提升显著。**速度方面 AIAPI 相对产品检索接口速度相对提升 34%。
效果上测评：
△图 7
图 7 中左侧使用百度搜索产品原生数据，回答内容过于宽泛，右侧使用 AIAPI 接口，回复准确且丰富。提升了回答的效果。
05 展望
尽管 AIAPI 的架构设计能够快速将业务效果提升同步到生成式检索效果上，在计算复用、资源优化方向上持续不断优化和提升资源利用效率。但作为 RAG 中重要的检索环节仍存在许多挑战，需要进行深入研究。比如如何降低正排，摘要的存储成本、能够在每次搜索中方便表征检索 query 与命中文档中相关章节的关系，解决正排存储信息中的冗余存储问题等等。因此可以预见的是随着 LLMs 的不断发展，AIAPI 的检索架构也需要不断进行优化和升级。
———— END ———— 推荐阅读
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论