我要投稿

基于 RAG 的 AI 搜索技术实践

发布日期：2025-11-25 19:15:58 浏览次数： 1539

作者：DataFunSummit

微信搜一搜，关注“DataFunSummit”

导读本文介绍了基于 RAG 的 AI 搜索技术实践。

今天分享主要包含三部分：

1. 搜索演进思路

2. 关键技术落地实践：重点阐述技术点的实际落地方式

3. 总结展望

补充说明：安全合规部分会简要提及，因敏感性不纳入 PPT 总结。

分享嘉宾｜钟啸林 NIO（蔚来汽车）搜推算法负责人

编辑整理｜陈锡杜

内容校对｜郭慧敏

出品社区｜DataFun

搜索演进思路

1. 搜索三个阶段

（1）第一阶段：被动搜索

典型应用：谷歌等传统搜索引擎。
核心特点：用户主动发起搜索，系统基于 RAG 技术增强搜索或总结结果，交互随搜索结果返回而结束。
局限性：用户查询词简短，模型难充分理解意图，无法预判用户后续需求。

（2）第二阶段：半主动搜索

典型形式：对话式交互（如 Kimi、DeepSeek 等应用）。
核心特点：

提供持续对话界面，支持用户多轮提问与交互（如展示 “其他人还在问” 引导进一步问询）。

结合多模态对话技术，提升用户活跃度（DAU）与体验。
商业模式潜力：通过替代传统搜索实现盈利，目前处于开发阶段。

（3）第三阶段：主动搜索

理想目标：系统预判用户需求，无需用户明确表达。
典型场景：汽车等领域（如监测到胎压异常时，主动推送处理方案、胎压值及服务通道）。
落地特点：依托后台数据监测，可能在垂直领域（如车联网）优先实现。

2. 从被动搜索到主动搜索

（1）被动搜索阶段（第一阶段）的局限

仅提供 “是什么” 的检索与总结（如告知用户车辆有 “运动模式”），无法满足用户 “如何做” 的操作需求（如驾驶模式设置步骤）。

（2）向半主动搜索过渡（第二阶段）的改进

增加服务通道：在 RAG 总结后提供操作入口（如点击按钮跳转 APP 设置驾驶模式），形成 “搜索 + 总结 + 服务通道” 模式。
交互延伸思考：发现用户期望系统自动完成任务（如识别设置意图后直接协助调整驾驶模式），而非仅提供手动入口，引出主动搜索构想。

（3）主动搜索阶段（第三阶段）的目标

系统预知用户意图，经用户确认后自动执行后续动作（如监测胎压异常时，主动完成报警、推荐服务并联动车载系统处理）。

（4）当前实践的核心问题与解决方案

核心问题：用户需求从 “信息获取” 转向 “任务完成”，传统搜索仅停留在信息层面，缺乏行动闭环。
解决方案：多模态结果整合：结合自然搜索结果（实体检索、相关性检索）、自动化信息卡片（如胎压数值）与 RAG 智能助手生成内容，统一展示。
交互形态设计：

顶层：RAG 生成总结性信息（如驾驶模式功能介绍）；

中层：直接展示服务通道（如 “立即设置驾驶模式” 按钮）；

底层：列出自然搜索结果（如其他用户常见问题）。
技术实现关键点：大模型训练

样本要求：需超过 1 万条高质量标注样本（如用户意图 - 操作路径映射数据），样本质量直接影响大模型微调效果。

当前定位：仍处于从第一阶段向第二阶段过渡状态，需通过持续优化对话交互与任务执行能力，逐步向主动搜索演进。

关键技术落地实践

1. 意图识别和请求改写/扩充

（1） 添加自定义 Token (Add Token)： 多数开源大模型允许添加自定义 Token。这对于处理特定领域的词汇至关重要，例如一些行业术语或特有表达（如讲者提到的“驾象”，作为“代驾”的一种更专业的说法），这些词汇通用大模型往往难以准确理解。通过增添专用 Token，能确保模型正确把握这些词汇的特定含义，避免歧义。

（2） 监督微调(SFT - Supervised Fine-Tuning)： 进行常规的监督微调训练。

（3） 直接偏好优化 (DPO - Direct Preference Optimization)： SFT 在处理许多“疑难案例”（hard cases）时效果有限——这些案例即便是人工也很难明确归类。DPO 作为一种类强化学习的训练方法，能让模型在两个选项（A/B）中学会选择相对更优的一个，从而提升模型的泛化能力。

模型训练完成后，便会部署上线，提供一个在线模型接口。除此之外，我们还建立了一套线上实时干预策略。例如，当业务部门新增一个活动或词汇，而模型在训练阶段未曾见过时，该策略能够通过分钟级统计分析用户交互行为（如用户搜索某新词后总是点击某个特定活动链接）来推断用户意图，进而实时校正线上搜索结果。

在性能方面，最初线上模型的接口响应时间为 350 毫秒。我们认为对于用户查询（Query）这一初始交互而言，此延迟偏高。为此，我们引入了基于 Redis 的缓存机制：请求首先访问缓存，若命中，则在 10 毫秒内直接返回结果；若未命中，再调用耗时 350 毫秒的实时模型接口。

基于缓存的引入，我们曾考虑是否可以利用一个更大、更精确的模型来生成缓存内容，以期获得更快的线上响应和更准的缓存结果。然而，（讲者示意此方案已调整或放弃）我们发现现有的小尺寸模型已能达到很高的准确率（最新的意图识别模型准确率约 96%），因此无需采用更大的模型。当前做法是，小模型直接在线上调用，其结果异步存入缓存，这样做也保证了数据的一致性，避免了使用多模型可能导致的结果不一致问题。

关于提示工程（Prompt Design），我们认为其整体设计与定义相对直接。而在 DPO 训练的样本设计方面，我们会筛选出“疑难案例”，并将其构建为“采纳”（chosen）与“舍弃”（rejected）的样本对，用以指导模型学习正确的偏好。

最终，我们线上服务的平均响应时间（AVG）控制在 250 毫秒左右，表现已相当迅速。在进行压力测试（包含大量长尾请求）时，响应时间可能会略有增加。

2. 多模态向量检索

（1） 文本向量检索

我们最初致力于实现文本的向量检索。这项通用的文本向量技术旨在覆盖社区资讯、服务等业务场景下特定话术的召回，以及商品信息的检索。为此，我们进行了数月的数据样本生成与聚合工作。

在选择基础模型（Base Model）方面，初期我们选用了当时中文开源领域表现最佳的 BGE 1.5 模型。目前，我们正在评估 GTE 模型的新版本（此版本尚在离线评估，未正式上线）。针对 BGE 版本，我们选取了最优模型，并在内部的召回率（Hit Rate）测试中验证了其最佳效果后采纳。

样本积累主要通过三种途径：线上疑难案例（case）的挖掘、规则生成以及人工标注。基于这些累积的大量样本，我们进行了模型训练。训练过程中，我们注重样本多样性的调控，确保不同业务类型的样本数量按比例分配。训练方法上，主要采用批量内负采样（in-batch negative sampling）策略，并结合对比学习损失函数（contrastive loss）等方法。训练完成后，模型在各个业务领域的测试集上，召回率基本都能达到95%左右。我们还进行了线上 A/B 实验，在其他条件一致的情况下，仅替换向量模型，也观察到了显著的指标提升。

（2） 文本检索的局限与多模态的需求

尽管文本向量检索模型取得了良好效果，但我们发现仍存在一些问题无法解决：

内容供给的挑战：许多内容（如图文帖子）文字描述极少，甚至只有一张图片，导致文本向量模型因缺乏文本信息而难以召回。
跨模态排序难题：如果单独为图像建立向量模型，会发现图像向量与文本向量因其向量空间不一致，无法直接进行统一排序和度量，难以解决跨模态检索的需求。
用户需求的多样性：用户实际上存在许多多模态的检索需求。

这些因素促使我们研发多模态向量检索技术。

（3） 图文多模态向量检索的探索

当前阶段，我们主要聚焦于图文形式的跨模态检索技术。我们测试了多种开源模型，其中 BLIP-2 模型表现相对突出（尽管业界公认谷歌的某模型效果最佳，但其并未开源）。我们选用了一个表现较好的中文多模态模型版本，并利用我们特有的一些图片数据进行测试，效果显著。该模型效果出色的一个主要原因在于其使用了超过两亿张高质量图文对进行训练，因此在我们的业务场景（如充电桩、放电站等特有图片）中也表现良好。

然而，其在特定相关领域的样本仍然不足。为此，我们正积极汇集公司内部所有的 UGC（用户生成内容）、PGC（专业生成内容）及其他图片资源，并通过 OCR、以及其他辅助手段生成训练样本，以持续优化我们的领域专用多模态模型。

（4） 混合检索策略与系统架构

拥有多模态向量模型后，我们在线上实际应用时，并非单纯依赖向量检索，而是保留了传统的文本检索能力。具体实现上，我们主要依托腾讯云 Elasticsearch (ES) 8.x版本的向量搜索平台。

之所以同时保留文本检索和向量检索，是因为我们发现：对于高精度、用户输入已非常具体的查询，传统文本检索的效果往往优于向量检索。我们不希望因为引入向量检索而牺牲这类简单、明确场景下的用户体验。

因此，我们的整体检索流程如下：

多路并行召回：用户的原始查询及经过意图模型扩充后的查询，会同时触发文本检索和向量检索（包括多模态向量）。
结果聚合：召回的多路结果会进行聚合。我们采用优先级队列的方式，优先保证文本检索的结果（以应对高精度查询场景）。
重排序（Re-rank）：聚合后的初步结果会经过一个重排序模型进行优化。
知识供给大模型：最终排序后的结果，作为知识输入，提供给我们的大语言模型进行后续的理解和生成。

这构成了从用户请求理解到知识检索阶段的完整链路。

3. 大模型技术

（1）基座模型的选型和开发思路

选择合适的大型语言模型是首要步骤。我们的考量因素主要包括：

模型自身指标：关注模型在各类公开评测和排行榜上的表现，尤其重视其在中文处理上的效果。同时，模型的参数规模最好能覆盖不同需求，以适应不同阶段的任务。

后续支持与生态：倾向于选择有稳定迭代支持、生态系统相对完善的模型，避免选择发布后便无下文的模型。
安全合规性：至关重要的一点是，所有面向消费者的（2C）大模型应用均需在中国工信部进行备案。因此，所选模型必须是已备案的，这能显著降低合规风险。国内企业多选用如 Qwen（通义千问）等已备案的开源模型。

经过筛选对比（如 DeepSeek、Kimi 以及公司自研的 Nomi 等模型的开源版本），我们最终选择了 Qwen 作为基础模型。

基于 Qwen 定制化：

与意图模型类似，添加领域特定的 Token。
由内部团队（如 Nomi 团队）进行包含公司业务背景知识的预训练，打造出一个已内化了部分自有知识的定制版 Qwen。
标准 Qwen + SFT 微调：直接使用标准版 Qwen，结合特定样本进行监督微调（SFT）。

所有路径最终都会通过业务指标进行评估。

（2） 高质量样本的生成与评估——核心挑战

在大型语言模型训练中，最核心的挑战在于获取高质量的训练样本，而非模型本身（许多优秀模型已开源）。

为解决此问题，我们设计了一个名为“数据生成与评估 Agent”的自动化系统：

核心组件：该 Agent 由两个 DeepSeek R1 模型构成（经测试，DeepSeek R1 在此类任务上效果优于 Qwen-7B 等其他模型）。

工作流程：

模型 A（生成器）：接收任务定义和相关输入（如用户查询），生成初始数据样本。
模型 B（评估器）：对模型A生成的样本进行评估，判断其是否满足任务及样本定义的要求（如专业词汇是否清晰、任务描述是否准确等）。
迭代优化：模型 B 向模型 A 提供“自反思”式的反馈，指出需改进之处。模型A根据反馈重新生成样本。此循环持续进行，直至模型B判定样本“可用”（达到预设阈值），或达到最大迭代次数限制（避免无限循环）。一旦可用，系统便输出样本并标记其可用性。
约 80% 的训练样本通过此 Agent 批量生成。

其他样本来源：

人工标注：通过搜索结果满意度标注等定期任务积累。
线上反馈：线上助手设有“满意/不满意”反馈按钮，用户的不满意反馈将作为负样本。

样本的二次分析与质控：

获取样本后，我们还会利用自研工具进行第二轮分析，主要从以下三方面评估：

数量：是否满足不同模型尺寸的需求（如小模型 6000 条，大模型 1 万条），以及各任务类型的样本量是否充足。

多样性：

词汇丰富度：如词频分布、同义词/近义词的覆盖情况。
任务覆盖多样性：是否覆盖了足够多种类的任务。
格式多样性：除了预设格式外，是否包含其他格式的样本。
业务覆盖多样性：是否覆盖了足够多的业务场景。

质量：

内部一致性：例如，同一查询不应对应多个内容冲突的样本。
准确性：检查错别字和格式问题。

最后进行人工抽样检查。通过上述流程，我们能够相对快速地获取大量高质量的训练样本。

（3） 大型语言模型的训练

对于使用开源模型的“调用派”，我们的工作重点在于样本的组合与设计，以及训练参数的调优。

样本组合：

完全随机打乱：适用于小尺寸模型。由于小模型记忆力较差，随机打乱有助于其学习；若分阶段按比例投喂，可能导致遗忘早期学习内容。
按类型、比例分阶段：适用于大尺寸模型。因大模型对样本需求量大，一次性加载所有样本会导致内存不足，故采用按比例、分阶段加权训练。

Prompt 格式探索（以 LLaMA-Factory 等框架为例）：

简单输入输出式：对小尺寸模型效果较好。
系统指令（System Prompt）抽取式：对大尺寸或复杂任务，将系统指令（描述任务要求）抽取出来。原因：大模型指令遵循能力强，无需在每轮对话中重复指令；工程实现上更简洁，只需填充输入槽位，无需每次都传入大量指令文本。

训练任务与方法：

LoRA (Low-Rank Adaptation)：主要用于大尺寸模型，受限于 GPU 资源（大部分 GPU 资源需优先保障自动驾驶 ADAS 研发）。
SFT (Supervised Fine-Tuning)：主要用于中小型模型，实践证明 SFT 能使小模型达到非常好的效果。
DPO (Direct Preference Optimization)：用于处理疑难案例和模型校准。

训练参数调整：可调参数不多，主要包括 Epochs、Learning Rate 等。核心依然是拥有高质量的样本数据。

通过精心的样本准备和恰当的训练策略，即便基于开源模型，也能训练出表现优异的领域专用大模型。

4. 数据流转与 RAG 系统持续优化机制

数据挖掘阶段（补足供给短板）：当用户请求进入后，系统会分析当前内容供给中存在的不足之处。通过各类数据挖掘手段，补充缺失的内容供给，以此弥补 RAG 系统在知识覆盖上的短板。

内容生成后的线上反馈与优化循环：

系统包含线上反馈机制。如果某一生成结果被用户多次标注为“不满意”，系统会自动将其下线，不再展示。
这些被标记为“不满意”的结果将作为负向样本，用于后续离线的 DPO（Direct Preference Optimization）训练，以持续优化模型效果。
所有内容在对外展示前，都会经过安全合规审查。
只有符合规范的内容才会被展示，以规避潜在的法律风险。

5. 数据时序关系

该系统采用 Agent 化的架构进行服务，其交互流程如下：

用户请求与意图识别：

用户发起请求后，系统首先调用后端服务，分析用户意图，判断是否命中预设的某个 Agent 的处理范围。
若未命中任何 Agent 的意图，则直接返回常规的自然搜索结果。
若成功命中 Agent 意图，则进入下一步。

信息召回：

系统尝试根据意图召回相关信息。
若无有效召回结果，则流程终止（可能返回自然结果或预设的兜底回复）。
若召回成功，则继续。

Agent 调用与结果选择（多 Agent 协作）：

系统会异步调用相关的两个（或多个）Agent。
每个 Agent 处理后，其返回的初始信息（如首个 Token）会表明自身是否成功匹配并处理了该请求（即是否“命中”）。
Agent 之间存在优先级（通过优先级队列管理）。系统会首先采纳优先级最高的已命中 Agent 所生成的结果。
若最高优先级的 Agent 未命中，则依次检查次级优先级的 Agent。
如果所有相关 Agent 均未能有效命中，系统将返回预设的兜底话术。

流式输出：为提升用户体验（鉴于大模型响应可能较慢），Agent 的回复内容采用流式数据的方式逐步返回给用户。

增强信息与服务引导：

在主要回复内容流式输出完毕后，系统会进一步判断是否存在对应的“服务通道”（如一键跳转至某项具体服务或功能，例如之前提及的“Nomi”相关服务）和“参考资料”。
如果存在相关的服务通道，会将其展示给用户，以便用户进行下一步操作。

这构成了从数据采集、反馈优化到实时 Agent 交互与服务提供的完整闭环。

总结展望

1. RAG 落地过程中的核心经验

首先，高质量的参考资料是基础。 他指出，如果召回的资料本身杂乱无章，后续的生成结果也难以保证。这意味着传统的搜索数据处理工作，如数据清洗、预处理等，仍然是不可或缺的一环。
其次，大量且优质的训练样本至关重要。 样本需要做到“多”与“精”，数量上建议在一万条以上，并且需要均匀分布，有效覆盖各个相关的业务领域。
再次，应采用多 Agent 并行而非单一全能 Agent 的策略。 试图用一个 Agent 处理所有任务会极大地增加工程实现的复杂度和交付难度。推荐采用多个专门的 Agent 并行工作，各自专注于自身领域，例如他们实践中使用的“加电 Agent”和“用车 Agent”

2. 对于大模型技术的未来趋势

一是向多模态技术融合。 大模型技术正持续向多模态方向发展与融合，以满足用户日益增长的对多模态交互的需求。
二是大模型应具备自我进化能力。 虽然他们已通过用户实时反馈进行小时级 DPO 训练来间接实现此能力，但认为目前 DPO 训练对模型整体参数的改进幅度仍然有限，未来需要更强的自进化机制。
三是个性化能力的深化。 鉴于不同用户关注点各异，未来需要探索如何将传统的个性化推荐技术与大模型的能力有效融合，提供更贴合用户需求的服务。