大模型技术如何革新搜索排序？腾讯AI搜索架构与LLM排序实践详解

导读

本次分享由腾讯搜索应用部的高级算法工程师叶德志老师介绍了大模型用于搜索排序的探索和实践。

主要分为四个部分：

1. 背景及业务介绍
2. 整体 AI 搜索排序架构设计
3. 搜索排序挑战与解决思路
4. 未来展望

01 背景及业务介绍

1. 腾讯元宝 RAG

在显示器普及之前的很长一段时间内，搜索领域的从业人员主要依赖关键词匹配、检索及列表呈现的方式实现搜索功能。用户需主动输入关键词进行检索，并自行对检索结果进行任务加工与总结。随着 ChatGPT 等大模型的出现，RAG 逐渐成为一种主流的搜索技术。目前，各厂商已推出多种相关产品。例如，在所展示的 PPT 中提及腾讯推出的两款产品：腾讯元宝和 QQ 浏览器中的 Qbot。

从纵向流程来看，当用户输入一个 prompt 后，系统首先对该 prompt 进行任务规划（planner），以决定调用哪些组件，包括搜索及其他插件，并执行检索操作。搜索环节需要对用户的 prompt 进行分析，识别出能够满足用户需求的相关结果，并进行 Rerank。随后，系统对 Rerank 后的结果进行校验，筛选出能够回答用户问题、对用户有帮助的内容。最终，这些结果被返回给大模型，用于生成答案。为更好地满足用户需求，当前流程中还引入了多 Agent 协同、多轮反思等机制，以应对更复杂的任务。

2. 大模型+搜索：互补协同、共同进化

从两个角度来看，大模型和搜索能够分别为彼此带来价值。大模型与搜索是一种互相协同、共同进化的关系。对于大模型而言，搜索能够动态地为其补充外部知识，同时减少大模型的幻觉；大模型借助搜索获取实时的全新信息，并通过 RAG 的方式生成用户答案，从而大幅降低幻觉现象。对于搜索而言，其应用场景发生了进化：大模型为搜索提供了全新的“大脑”，驱动搜索从原先依赖人工返回列表、用户自行筛选的模式，转变为由 AI 自动总结并直接提供精准答案的模式。同时，最关键的是，这一转变带动了整体 AI 搜索架构的升级，推动其向深层次检索以及搜索算法的全链路重构方向演进。

3. 复杂场景：高考助手、财经分析助手

这是一个此前的业务场景：高考助手。在用户进行高考志愿填报时，面临的痛点是时间短、信息量大且决策复杂。针对这一场景，系统通过 Agent I`M AI 高考通实现了 Deep Search 的复杂功能需求。具体流程包括任务规划（task planning），在规划环节结合各省高考志愿填报规则，分析考生分数等特征，并执行规划、检索、阅读与反思等任务，以确保能够搜集全面且准确的信息。在工具层面，系统接入了大量专业工具，包括招生计划、历年录取分数、专业库等。最终，系统输出一份个性化的高考志愿填报方案。

02 整体 AI 搜索排序架构设计

1. AI 搜索架构设计

传统搜索本质上是一个静态的检索流程，其一般步骤包括快速理解用户查询、检索排序、融合排序，最终进行页面展示，整体基于关键词检索的逻辑。进入中期阶段后，发展为 RAG，该模式已较为成熟，表现为一种基于大模型决策能力的动态响应过程。在此过程中，系统引入了 Query Planning 和 Function Calling 能力，使大模型能够自动决策需要调用哪些工具，并由这些工具向大模型返回准确信息。当前主流方向已演进至 Agentic Search 阶段，这是一种多 Agent 协作框架。在该框架下，任务规划（planning）更为复杂，涉及多个 Agent 的协同；同时引入了反思机制（Retrieval），即大模型会自动判断是否需要再次调用工具，以及是否已获取足够信息以完成任务。

2. 架构设计

基于上述 Agentic Search 方案，搜索内部的结构需要进行相应的升级。系统架构正从传统搜索向 AI 搜索演进，其核心升级涉及四个链路：一是用户理解（或查询理解）需要如何改进，二是索引召回需要如何调整，三是排序模型需要如何优化，四是整体检索系统需要如何重构，以充分应对当前复杂的查询需求。

对于 query 理解而言，早期的 query 理解主要基于传统搜索的语义意图理解，核心包括分词以及诸如纠错等基础意图识别。而在 AI 检索场景下，用户的 prompt 通常十分复杂且高度贴近自然语言，因此需要对上下文进行拆解。此外，用户输入往往包含丰富的上下文信息，这就要求系统能够对复杂的上下文需求进行解析，并将其转化为适合检索系统的 query。该过程的核心在于将用户关注的目标——即用户想要完成的任务——转化为检索系统可执行的操作。这一转化步骤一方面依赖于领域知识的微调，另一方面还需结合检索效果进行强化学习，从而指导 query 理解模块生成更适合检索的 query 集合，最终获得更丰富、更贴合用户诉求的检索结果。

对于索引召回而言，传统搜索主要依赖 query 与文档之间的主体匹配，包括基于关键词的匹配以及较为粗糙的 embedding 召回方式。而在当前的 AI 搜索场景下，用户诉求往往由一大篇文章中的某一段精确片段来满足，而该关键信息容易被整篇文章的内容所淹没。为此，系统在原有基础上引入了 chunk 级别的索引，构建语义化的 chunk，并通过 chunk 级别的召回，实现对长文档中特定细粒度片段的精准识别与获取。

3. 搜索系统前身

早期系统主要面向综合搜索，并在此基础上针对 AI 搜索进行了定制化优化。整个系统分为几个模块：一是基于通用搜索（通搜）的检索，即传统意义上的综合检索；二是自建的 chunk 索引。其中，chunk 索引仅针对权威性高、质量高、时效性强的数据源构建，因为 chunk 索引的构建成本较高，系统并未对全量大库进行 chunk 化处理。此外还有两个召回模块，分别是面向事件的时效性召回，以及针对百科、医疗等垂直领域库的召回。

在完成所有综合检索后，系统会基于 PSG 对召回结果进行统一打分与排序，并将排序后的结果返回给大模型。同时，在最上层还实现了 prompt2query 模块，用于快速进行联网判断、生成子查询（Sub-Query）以及支持多轮补全等功能。整体来看，该系统本质上是对通用搜索系统的一种改造，尚未达到高度抽象的阶段。

4. 当前搜索系统示意图

近期为更好地适配 AI 搜索场景，对整个链路进行了升级，并对原有的排序阶段进行了整合。系统整体分为多个层级：L0 阶段为召回阶段；L1 阶段在分库基础上进行粗排；L2 阶段称为精排，会计算较高级的特征，包括基础相关性特征、相关性特征和时效性特征；L3 阶段称为精精排，此阶段引入大模型进行动态打标排序；L4 阶段为混合排序，主要针对外部检索 API（例如公众号检索、视频号检索等）以及插件检索结果，与自建索引进行综合排序；L5 阶段则对单个 sub-query 的结果进行整合，最终实现面向用户 prompt 粒度的排序。

03 搜索排序挑战与解决思路

1. 系统挑战

在搜索排序任务中，其基本定义较为简单：给定一个用户 query，对候选文档（doc）进行满足性排序。然而，进入 RAG、AI 搜索或 Agentic Search 场景后，该排序任务变得更为复杂。核心挑战在于 query 本身的复杂性显著增加：用户输入形态更加多样，表达更趋口语化，并包含更多上下文信息。例如，单个 sub-query 如“2025LPL 第一赛段哪位选手的终极杀榜排名第一？”或“董小姐那件事，卫健委的最新通报，给我卫健委的原文网址”，均为传统通用搜索中较少出现的口语化查询形式。

针对此类口语化查询，可从三个方面进行应对：模型、建模方式和样本。在模型方面，可从早期的 BERT 模型升级为大模型。在建模方式上，可从最初的 embedding-based（或 encode-based）模型，转变为生成式建模，并引入 COT 的解决方案。在样本方面，可通过生成更多合成样本和机器样本，以提升训练样本的质量。

2. 表示型 LLM for Ranking

早期的工作主要集中在利用表示型模型进行搜索排序。2020 年，系统主要采用 BERT in Code 模型，在 CLS 位置上外接一个线性层进行打分。到 2023 年年中，团队开始关注大模型的潜力，并尝试使用 decoder 类模型进行排序。当时的做法较为直接：在 EOS 位置上外接一个 dense 层进行打分，即将大模型视为一个规模极大的特征抽取器来执行搜索排序任务。得益于模型参数规模的提升，该方法取得了较好的效果。

为了将离线收益转化为在线收益，当时将大模型的 SOT 模型作为 teacher，对 student 的 BERT 模型进行蒸馏。整个过程利用了大量无监督数据来迁移大模型的计算能力。在实际落地时，采用了 point wise 的 MSE 和 pair wise 的马吉诺斯相结合的蒸馏方式。具体实现可参考下方提到的文章，该文章已介绍整个工作流。

3. 生成式 LLM for Ranking 的范式

自 2024 年开始，团队着手探索如何通过更深层次的方法解决排序（ranking）任务。当前主流的建模方式包括 pointwise、pairwise、listwise 和 setwise。其中，pointwise 方法较为直观，即给定一个 query 和一个 passage，判断该 passage 是否与 query 相关，或是否回答了用户的 query 问题。pairwise 方法则是在给定一个 query 和两个 passage 的情况下，判断哪一个 passage 与 query 更相关。listwise 方法的输入是一个 query 和一个 passage 列表，目标是生成一个排序后的列表，使得相关性高的 passage 排在前面，例如 passage 3 的相关性高于 passage 2，passage 2 又高于 passage 1。setwise 方法与 listwise 的最大区别在于，它仅需输出列表中最相关的 passage，而无需对整个列表进行完整排序，从而显著降低了 listwise 排序任务的复杂度。

从效果、效率和部署角度来看，就耗时（latency）而言，pointwise 的整体耗时最低，尽管其效果并非最优；pairwise 的效果最优，但整体耗时最长，因为它需要对所有文档进行 N 方级别的两两比较，这种方式难以支持在线部署。因此，后续采用了耗时最小的 pointwise 建模方式。

4. LLM for Ranking

当前的任务是对多个 query 进行细粒度的相关性打分。所采用的方案是一个细粒度的 pointwise 生成式 LLM 模型。该模型的任务设定为：给定一个 query 和一个 doc，明确告知模型任务类型、输入格式和期望输出格式，并据此对模型进行训练。在训练过程中，取模型输出中对应评分的最大 token，采用 MTP（Masked Token Prediction）方式计算 loss，即 not model loss；例如，若样本标签为 2 分，则要求模型最大化对应 token 的 logit 值。在推理阶段，获取模型生成的第一个 token 的 logit 值，在对应位置（如 1、2、3、4、0）上应用 softmax，再进行加权求和，最终得到一个介于 0 到 1 之间的相关性分数。

在前述基础上，整个训练流程被抽象为四个部分，用于实现 LLM for Ranking。第一部分是持续的预训练。该阶段可理解为 post 圈定，其任务包含多个组成部分：多个 content 的内容生成、从 doc 到 title 的生成、多 query 生成，以及 query 和 doc 相关性任务的判定。该阶段的目标是使模型从开源语料迁移到搜索领域，并对检索任务建立粗略的认知。

第二阶段是大规模监督的生成式学习。该阶段采用重要标注样本和人工精标样本对模型进行训练。除原始模型的 next token loss 外，还引入了一种 pair loss，用于缓解前文所述的推理不一致问题，并提升打分的区分度。在推理阶段，模型输出一个 0 到 1 的加权分数，该分数可通过正负样本构建 pair，进而采用马吉诺斯进行约束。

第三阶段将大模型蒸馏到规模较小的 student 模型上，student 模型参数量范围为 0.5B 到 3B，以缓解 14B 或三十几 B 的大模型在线部署困难的问题。

第四阶段将单目标的生成模式升级为多目标的大模型模式，模型连续生成四个打分，分别对应相关性、权威性、时效性和满足度，用于后续使用。

5. LLM for Reasoning Ranking

本章关注在解决大模型用于排序计算问题之后，将重点转向复杂 query 的处理。当前 query 形态日益复杂，一种朴素的思路是利用 COT 方式提升排序算法的效果。目前已有一些效果较好的开源方案，例如 Rank-1 和 Rank-R1，二者均显式生成了 COT。Rank-1 通过 COT 大模型进一步增强 DeepSeek 的 COT 过程，并让小模型从中学习；Rank-R1 则采用基于 GPU 的强化学习方式对模型进行 set-wise 训练，并以最终答案作为监督信号。这两种方法在复杂 query 的推理上取得了一定效果。

但在实际落地过程中，需权衡效果与效率。首先，显式生成 COT 的过程会导致 token 数量显著增加，在线部署难度大，整体耗时可能比之前增加十倍。此外，Rank-R1 所采用的 list-wise 或 set-wise 方式本身不太适用于粗排、精排、精精排等阶段，因其在候选条目较多时，单条推理延迟过高。

针对上述问题，团队提出了一种 Think-free 的方案，采用两阶段训练并在推理时进行优化。第一阶段使用双模板 SFT 进行大量样本训练：模板 A 要求模型输出思考过程和一个打分，模板 B 仅要求输出思考过程。这些数据来源于对 RRE 整体推理过程的蒸馏。在推理阶段，仅采用模板 B，而不使用模板 A。这是因为模板 A 需要生成完整的思考过程，而团队仅在复杂 query 上触发思考过程的生成。该设计的目标是利用显式生成的复杂 query 思考过程进行训练，从而提升模板 B 在处理复杂 query 时的效果。在 Bright 开源的大规模推理数据集上的实验结果显示，即使使用较小规模的模型，该方法也能取得较好的效果。

6. LLM for Ranking-自动样本

在介绍了之前的建模优化之后，接下来讨论样本方面的优化。目前团队全面拥抱大模型进行自动化标注样本。从标注效率、成本和质量上看，大模型在效率和成本上远超人工标注，并且在质量上，自动标注的 one rate 大约能达到 50%，与人工标注持平。尤其在处理复杂 query 的切片时，自动标注甚至优于人工标注。具体实施分为两个阶段：第一阶段，将用户的 prompt 输入到自有的检索引擎中进行查询，然后将查询结果输入到大模型中进行意图分析。这一步骤帮助大模型理解用户的真实需求。第二阶段，在进行样本标注时，针对每个文档及其对应的意图分析结果，让大模型进一步进行标注。这种方式极大地提升了标注的效率和效果。

例如，当用户提供一个 query 如“参加 93 阅兵的外国政要名单”并附带一个候选 doc 给大模型进行标注时，如果仅凭 query 和 doc，大模型可能难以准确理解该事件的具体背景。通过补充详细的意图描述，如“用户正在寻找 2025 年 9 月 3 日中国抗战胜利纪念阅兵式上的外国政要名单”，可以显著提高标注准确性，避免因缺乏外部知识而造成的随机标注问题。另一个例子是关于“八泉峡地理位置”的 query。在这种情况下，直接在意图描述中提供答案位置，使大模型在标注相关文档时能够更高效地工作，从而提升整体标注效率。这种方法不仅提高了标注的质量，还显著减少了对大量人工标注的依赖。

7. LLM for Ranking-合成样本

除了自动化标注样本，团队也在开展大量合成样本的工作。合成样本用于定向补充特定 case 形态的样本，并扩充样本总量。例如，定义了一些典型的 case 形态，包括 top 1 实体缺失、重要修饰词缺失以及散乱命中等。针对这些形态，构造特定规则，让大模型生成对应形式的样本，这类样本称为合成样本。这些合成样本会被输入到在线模型中进行打分，通过打分结果直接筛选出模型判断错误的案例，即 bad case。这些 bad case 会被补充到下一轮模型训练中。通过这种方式，整个数据流程得以持续运转，并能定向补充当前版本模型无法正确处理的问题。

右侧展示了一个构造 top 1 实体词缺失问题的示例：用户 query 为“二十多岁的肾气虚的一个判断方法”，对应的 doc 描述的是肾气虚的判断方法；生成的 query 为“二十多岁的肝气郁结的一个判断方法”。该生成 query 与原始 passage 构成一个负例，被视为正负 query 对。同时会生成一个改写原因说明：将“肾气虚”改为“肝气郁结”后，相关性变为完全无关。改写后的 query 语义自然、常见，不会显得生硬。相比之下，若采用手工方式进行增删改，容易导致语言生硬、语义不连贯，这对大模型的学习极为不利。

04 未来展望

最后介绍未来的展望。由于处于 AI 搜索场景，系统本身具备大量来自大模型的反馈信息，如何利用这些反馈是下一步需要思考的问题。一个初步思路是将排序模型的结果提供给大模型，由大模型生成最终 result；通过人工方式判断该 result 的好坏，并据此生成 reward，用于训练排序模型，整个过程构成一个强化学习流程。

第二个方向是从传统的 point-wise 建模方式升级到 list-wise 建模方式。与 point-wise 相比，list-wise 的优势在于模型能够同时观察多个候选文档。如右下角图所示，其输入包括一个 query 和多个 candidate 文档，模型在此基础上可获取完整的候选集信息。在许多情况下，文档之间的信息具有互补性，这种全局视角提供了更丰富的信息量，有助于模型做出更充分的决策。

以上就是本次分享的内容，谢谢大家。这篇文章分享的腾讯在 AI 搜索领域的实践经验，对于正在构建高可用系统的开发者来说，提供了宝贵的架构演进思路和技术选型参考。