我要投稿

小米商品助手、汽车问答垂直领域问答 Agent 建设

发布日期：2025-08-25 18:04:49 浏览次数： 1541

作者：DataFunSummit

微信搜一搜，关注“DataFunSummit”

导读本次主要围绕小米商品助手、汽车问答垂直领域问答 Agent 的建设展开。如何打造技术方案并克服挑战，为小米的商品助手和汽车问答助手等典型场景实现落地和赋能。

本文将围绕以下展开：

1. 业务背景

2. 技术方案

3. 落地难点

4. 小结

5. Q&A

分享嘉宾｜明振南北京小米移动软件有限公司高级算法工程师

编辑整理｜王丽燕

内容校对｜郭慧敏

出品社区｜DataFun

业务背景

在小米的众多产品中，语音交互是重要的用户交互方式之一。用户通过小爱语音助手提出各种需求，这些需求可分为通用问答和垂直领域问答。通用问答包括内容类需求（如音乐、视频资源查询）和闲聊、百科知识问答；而垂直领域问答则依赖私有领域知识，无法通过大模型的世界知识直接回复用户。

小米垂直领域问答的业务背景涵盖小米百科内容、小米生态链产品，涉及手机、汽车、音响、电视等商品，用户会针对这些商品产生各类查询需求。具体分为商品助手和汽车问答助手两大版块具体场景：

商品助手场景，主要涉及小米各类商品的相关查询，具体可分为以下几类：

产品参数查询：小米拥有十几大类、上百个子产品，用户会高频询问产品的各种参数，如手机的像素、价格、亮点和功能等。

售后客服咨询：用户购买小米产品后，会关注售后客服政策、保修权益等问题。

本机状态查询：由于小米业务是基于端上的语音交互，用户会询问设备的状态信息。在手机端，用户可能会问手机的电量、系统界面操作位置等；在汽车端，用户会询问车上的设置界面位置、实时状态信号（如车门锁状态、玻璃水剩余量、空调温度等）。

汽车问答助手场景：汽车作为小米的核心战略产品，其问答场景具有特殊性，单独拎出来作为一个精细化垂域。汽车问答助手场景主要包括以下几类：

设置项查询问答：用户知道汽车的某些功能，但不知道在车机上如何找到相应的设置界面，例如询问雨刮器开关的位置。

车辆状态查询：用户希望通过语音交互快速获取车上一些平常肉眼看不到的实时动态信号，特别是车机底层的状态信号。

汽车手册查询：当用户遇到车上的操作问题且在车机上无法直接找到答案时，可以通过查询汽车手册中的图文信息来了解操作方法。

车牌及交规问答：用户可能会询问与车牌规则、交规相关的问题。

在大模型技术兴起之前，针对商品助手和汽车问答等不同垂域，采用意图识别模型（如 Bert）进行语义理解和槽位抽取，再通过编写策略来满足用户需求。但这种做法需要为每个垂域和场景定义大量的意图和策略。随着大模型技术的发展，特别是 RAG 技术的出现，团队希望打造一个统一的垂直领域问答助手（Agent），基于 RAG + LLM 的统一架构方案来解决这些垂直领域问答场景，减少为每个业务场景定制细化功能和槽位的工作量，同时删除线上许多旧规则模块。

以上图所示终端设备交互场景为例：在手机端，用户问小米 15 等机型怎么样时，通过大模型垂直领域 Agent 把机型参数、功能亮点等信息，以自然语言生成结构化回答，并同步推荐商品卡片。在车载场景中，用户高频询问“当前驾驶模式”“远光灯开启方式”等操作类问题。Agent 通过车机系统实时数据接口获取车辆状态，针对“如何打开远光灯”的查询，系统可快速定位用户手册中的操作指南，以图文混排形式展示出来，解决新车用户对汽车功能的使用困惑。这就是我们要打造的垂直领域问答助手。

技术方案

为了满足小米垂直领域问答的业务需求，同时考虑到小爱作为线上实时语音交互入口对服务性能响应耗时的严格要求，技术方案遵循简洁原则，将整体架构分为四大核心模块：

AgentParser 模块：利用大模型进行语义理解，输出 function code，实现简单的意图筛选。该模块使用相对轻量级的大模型（量级在 1B 到 4B 之间）。
AgentSkill 模块：基于 function code 进行执行操作，包括 RAG 检索、API 接口调用、本机信号状态查询等。将执行结果信息收集、组装加工成 prompt，供大模型调用。
大模型生成及后处理模块：调用大模型生成结果，并进行后处理，如 Markdown 链接处理、图文混排等。
知识库模块：搭建面向小米集团内部的通用 RAG 平台，作为支持模块，解决汽车等领域私域知识的存储和检索问题，同时考虑隐私合规要求。

在垂直领域问答的意图理解方面，传统做法使用Bert模型，但大模型具有更广泛的世界知识。通过实验对比发现，大模型的性能远高于Bert模型，特别在长尾复杂 query 的意图理解上。因此，我们最终选择将模型升级为大模型，且其量级一般在 1-3B 左右即可满足线上业务需求，而且耗时能控制在一两百毫秒以内。

为了降低 GPU 和资源的使用，提高效率，在 AgentParser 模块中设置了 Agent意图预识别。对于小爱线上高频的简单查询需求，通过判断是否需要大模型理解，若不需要则直接生成 function code；对于需要大模型理解的 query，则输入包含系统人设要求、领域知识、多轮上下文和端上上下文信息的 prompt。

在小米的业务场景中，端上的上下文信息非常关键。以汽车载端为例，用户查询设置项操作时，设置项依赖于端上的实时状态，而静态知识库无法跟上端上的实时变化。因此，需要将端上的实时动态信息（如开关状态、玻璃水状态等）通过context 提供给大模型，以帮助其更好地理解用户意图并输出正确的 function code。

AgentSkill 模块主要负责根据 function code 进行执行操作，具体包括以下方面：

API 接口请求：当用户查询温度、实时价格等信息时，自动调用商品商城的 API 来获取相应信息。
端上信号查询：通过 event 请求链路实时获取端上的上报信息。
知识检索：涉及检索精排、重排和后处理策略。
商品检索：在电商购物领域，还包括商品推荐场景，使用 RAG 检索技术和排序来满足用户的推荐需求，最后将多路信号整合，构建大模型调用所需的 prompt。

RAG 框架与业界上大致相似，但在细节上有一些小模块的替换。用户 Query 首先进入粗召回阶段，通过大模型改写、HyDE 改写等模块优化查询语义，随后通过向量检索、实体检索及 Web 搜索实现多路召回。之后进入精排环节，早期采用 bge reranker 模型, 现升级为大模型进行排序，再根据一些策略和技术进行结果重排，完成对多路召回结果的综合排序，最终生成大模型所需的 Prompt。

RAG 检索模块的核心在于通用 RAG 平台，其整合了售后客服 QA、小米商品百科、用户手册、说明书、米车销服 QA 等多源领域数据。我们将更多精力投入到这类底层数据如何接入 RAG 库和如何切片上。

如上图通用 RAG 平台主要分为三大模块：

左侧为模型管理平台，集成了 bge Rank 排序模型、Embedding 向量模型等各类模型，统一部署于云端平台并由 RAG 平台调度管理；
中间为数据分层模块，底层橙色区域汇聚了小爱记忆、用户画像等多业务线的原始数据，经文档解析、知识切片等工具处理后，形成结构化知识库。平台封装了语义向量检索、关键词检索及多模态检索能力，覆盖文本、图像等多类型数据查询需求；
右侧为业务支撑模块，在统一 RAG 检索能力基础上，向小爱垂直问答等业务开放调用接口，同时提供 AB 测试、版本管理、服务监控等完善的工具，保障线上服务的性能与效果。

通用 RAG 平台之所以强调“通用”，核心在于其需兼容多业务场景的差异化需求。实践表明，RAG 系统的效果高度依赖知识切片策略与数据结构化处理，而单纯采用通用切片方案（如固定长度切分、标点符号切分）难以满足细分场景需求。以垂直领域为例，即使通过开源工具或自研组件将 PDF、Excel 等原始数据解析为 Markdown 格式，切片策略仍决定着检索质量。当前主流切片方式包括：固定长度切分、标点符号切分、层级索引切分、语义切分；尽管平台提供通用切片能力，但在实际应用中，各领域场景仍需定制化策略，对提升垂域检索效果具有显著作用。

因此，通用 RAG 平台仅能提供基础检索能力，难以直接满足线上业务高水平需求，若要将系统可用性从 90 分提升至 95 分，需结合业务理解与用户 Query 分布特征，针对性设计大量自定义切片策略，这正是各垂直领域 RAG 系统核心竞争力所在。

落地难点

下面聚焦小爱落地过程中的技术难点。首先是知识库向量化挑战。在小米业务场景中，数据源规模庞大且结构复杂，包含：商品百科数据：涵盖手机、电视等全品类商品的参数表格，包含价格、性能指标等海量数据。还有客服 QA 与运营 QA 等数据。面临的难题是如何用最快速高效的手段把这些数据接进来，同时保证线上业务的效果。

以商品知识为例，其典型数据包括百科信息与商城信息，主要为网页上的参数数据。该场景的首要任务是数据收集，需先爬取网页数据，再进行合并更新。此环节尤为关键，因商城信息中价格、库存等均为实时数据，需要保障知识库的时效性。若用户询问手机库存时，系统反馈与商城实际情况不符，会影响用户体验，因此确保知识库实时性是关键。

数据更新后，我们将开展两项工作。其一，进行向量文本生成，为构建 RAG 库奠定基础。其二，对静态知识进行深度处理，不仅生成向量文本，还需完整保留数据中的层级索引关系。将商品名称、属性归属、品类层级等结构化数据，以 JSON 格式存入专用 Schema 库。这种结构化存储与向量检索相辅相成，能辅助提高线上业务检索效果。

此外，我们还构建了别名自动化模块。在实际业务中，商品别名是无法回避的问题，比如用户用简称、俗称询问产品，因此我们专门建设了别名知识库。总而言之，构建商品知识体系，需要一套高效的离线实时更新合并流程，以此确保知识库的时效性，完整性和准确性。除构建基础向量文本外，还需对层级索引、属性归属等结构化数据进行 Schema 存储，并通过独立数据库管理。检索时，需综合多库数据完成知识整合。

以商品知识向量化为例，以红米 Turbo 4 手机参数页面为例，其品类层级、参数取值等信息均呈现于网页中。得益于内部 API 接口，我们可直接获取格式化的 JSON 数据，规避了文档解析、Markdown 处理等前期预处理难题，获得高度结构化的原始数据。在构建知识向量化时，尝试多种方案后发现，最简且有效的方式是对结构化数据进行字段拼接：即 goods + attr + value 的形式，对各种键值对进行组合，生成多组文本并向量化，能有效辅助召回。

在汽车场景中，典型场景可分为静态知识与动态知识两类。静态知识指可通过离线建设的固定信息，与需实时获取的动态信号形成区分。尽管业界有成熟和开源工具提供文档解析、检索模型等能力，但实践发现，直接复用开源工具往往难以满足业务需求，仍需结合业务特性进行适配：

文档解析：对说明书的标题、段落、图片和表格进行解析。
索引建设：建立各级标题的父子映射关系，以及文本、图片、表格与标题的索引映射，同时保留索引的有序性，保障位置信息。基于最简单的策略，通过标题来做 chunk 的切分。但是基于标题切分知识块时需注意长度控制, Chunk 过长会导致检索效果显著下降，若标题切分后仍超过阈值（如 1500 Token），可结合语义模型切分，但需保留片段与标题的索引对应关系，确保检索时语义完整性。综上，Chunk 切分需紧密结合业务场景、用户 Query 进行定制化设计，建议通过实践探索最优策略。
向量构建：将 block 文本、标题+ 文本、表格表头、表格元素进行组合构建向量。除直接对单个 Chunk 进行 Embedding 编码外，通过组合不同元素优化向量结构，多维度组合编码的方式，能使向量包含更全面的语义信息，显著提升检索召回率。

在汽车静态知识场景的实践中，我们验证了上述策略的有效性：一个 RAG 系统的效果中，约 80% 来自于 Chunk 切片策略与定制化索引构建。

在汽车问答场景中，动态信号处理是另一核心挑战。这类信号可分为三类：

SC 信号：车载软件类信号（如空调温度、开关状态），数量多达 1900+。多为底层工程代码级数据（如非中文字符串形式），需通过大模型结合人工策略清洗为文本化描述；
系统控制信号：车机安卓系统自带信号（如音量、蓝牙状态）。格式规范，可通过 Context 解析直接获取。
CarloT 信号：车载配件（如香氛、冰箱等 LT 设备）信号，遵循 Stack 协议，人工梳理结合快速解析即可整合。

完成信号梳理后，其向量数据将分流至两大平台：一是小爱信号平台，专为车机商用场景设计，支持实车环境下的动态信号实时检索；二是静态知识库平台，通过大模型增强手段构建文本检索体系。针对开关类信号的字段或英文字符串形式，直接检索难以匹配用户自然语言 Query，因此需借助大模型生成辅助增强检索 Query。

针对语义不完整（指代问题、信息缺失）和语义不匹配（因果推理问题、用户表述 gap、纠错问题）的情况，基于 LLM 做 SFT 任务实现 query 改写，包括多轮 rewrite 语义补全和 HyDE 生成潜在 query，以增强检索效果。

在领域知识检索环节，切片策略可将系统效果提升至 80-90 分，而从 90 分到更高水平则需依赖算法与模型层面的优化。

早期方案：初期采用 bge-reranker 模型，针对小米业务场景进行微调与架构改造：bge-reranker 通过构建“正样本-负样本”对优化相关性排序，能有效区分 Top-K 结果中头部样本的匹配度，但对尾部冗余样本的过滤能力不足。为解决实时性要求下的知识精简问题，叠加 MLP 二分类任务，通过判断候选文档是否与 Query 强相关，进一步过滤尾部样本。
升级方案：在经典 RAG 流程（粗召回→精排）后增加大模型重排模块，但因模块层级过多，导致链路延迟增加，最终放弃。
最终方案：直接以大模型替代排序模块，将粗召回样本量从数千级降至 100 级以内（如 Top-60），通过 Point-wise 排序策略对单个候选文档与 Query 的拼接文本进行独立打分。而使用 pair-wise 会导致 Prompt 过长而导致性能问题因此放弃使用。最终在复杂测试集上，大模型召回率与 bge-reranker 基本持平，但准确率显著提升，注入文档数从平均5篇降至3篇。

在垂直领域模型构建中，回复对齐是关键环节，核心涉及 SFT（监督微调）与 DPO 等后训练工程实践。首先，我们对大模型能力做了抽象能力，总结出 7 项基础能力：

知识总结摘要：对输入知识进行精简提炼，生成符合用户需求的摘要内容；
特定信息提取：从含噪声或冗余的 RAG 知识中甄别有效信息，过滤无效数据；
复杂推理能力：处理带条件的用户需求（如“推荐 5000 元左右带呼吸灯的手机”），结合多文档参数进行价格区间筛选、特征匹配等逻辑推理
多轮交互能力：支持上下文连贯的多轮对话，理解用户后续提问的指代关系；
指代消歧能力
兜底回复能力
其他能力等等

通过这一层能力定义，再结合线上业务总结划分出 16 种细分能力，完成能力维度归类后，进入 SFT 数据构建阶段。我们采用轻量化迭代策略：针对每个细分能力场景，先构建少量标注数据，逐能力验证效果后再逐步扩展，避免一次性全量建设带来的成本压力。数据构建完成后需进行加权整合，这一环节需结合业务经验设定各类数据比例。整合后通过全量微调提升模型拟合度，实践表明全量微调可使准确率提升 2-3 个百分点。若需进一步优化回复风格，可叠加 DPO 模块，但 SFT 本身已能满足大部分线上需求，DPO 通常仅带来 1-2 个点的效果增益。模型选型上，考虑到线上推理耗时限制，我们采用 7B 轻量级模型，通过知识蒸馏+精标 SFT 数据混合训练，使轻量级模型效果接近千亿级大模型。还有对比全参微调与 LoRa 微调，全参微调的效果优于 LoRa 微调，尽量建议采用全参微调。

针对回复对齐任务的经验总结有以下几点：

样本质量比数量更重要：SFT 数据中的噪声会严重影响模型训练，个别能力的训练数据即使只有 20 条左右，只要数据质量高也能取得较好效果。
无需一次性构造大量数据：可以先用 100 条左右的数据进行微调，评估收益后再决定是否扩充数据集。
prompt 多样性与 response 收敛：在不影响回复质量的前提下，减少 response 的多样性有利于 SFT 模型收敛。在垂直领域助手场景下，回复风格相对统一，不需要发散性回答。
课程学习有助于解决复杂推理任务：将复杂任务拆解成多个简单子任务进行学习，然后组合子任务完成更复杂的任务。