探讨大模型在垂直领域的落地实践，小米的探索无疑是一个极具代表性的案例。小爱同学作为核心交互入口，每天要处理海量用户需求，从闲聊百科到商品参数查询，跨度极大。面对那些依赖私有领域知识、无法依靠大模型世界知识直接解答的场景，团队是如何一步步构建起统一架构的？核心结论是：RAG+LLM的组合方案是主流方向，但真正的竞争力隐藏在切片策略与定制化模型之中。

小米的垂直领域智能问答系统主要围绕两大核心板块展开：商品助手与汽车问答助手。在商品助手场景中，用户会查询各类产品参数，例如“小米15的像素是多少”；也会咨询售后政策，甚至在手机会询问电量、在车上会查询玻璃水余量。汽车场景则更为复杂，涉及设置项操作（如“雨刮器开关在哪”）、车辆状态查询（如“车门锁了吗”）、用户手册检索以及交规类问题。在大模型技术普及之前，这些场景依赖意图识别模型配合大量策略规则，每个垂直领域需定义众多意图和槽位，维护成本极高。

技术的关键转折点在于RAG（检索增强生成）的引入。小米团队的目标非常明确：打造一个基于RAG+LLM的统一问答架构，将分散在各处的定制化模块进行整合，同时淘汰老旧规则模块。整个方案遵循简洁高效原则，划分为四大核心模块：AgentParser（负责语义理解，输出function code）、AgentSkill（根据code执行检索、API调用等操作）、大模型生成及后处理（生成自然语言回复，处理图文混排），以及统一的知识库平台。

02 技术方案

在意图理解环节，传统做法通常采用Bert模型，但大模型的世界知识与泛化能力明显更优，尤其在处理长尾复杂query时表现突出。实验数据也验证了这一结论，因此最终选用1-3B量级的小模型进行解析，耗时控制在200毫秒以内，完全满足线上实时交互需求。为降低GPU资源消耗，团队还增加了意图预识别模块，对那些简单、无需大模型介入的高频query直接跳过LLM，快速生成function code。

端上上下文信息是影响问答质量的关键变量。在车载场景中，用户询问“怎么开远光灯”，这一操作高度依赖车机的实时状态——灯光开关当前处于哪个位置、系统界面呈现何种模式，这些信息均非静态知识库所能提供。因此，必须将端上的实时动态信号（如开关状态、玻璃水余量）融入prompt，帮助大模型准确理解用户真实意图，输出正确的function code。

AgentSkill模块负责具体执行，涵盖调用商城API获取实时价格、通过事件链路查询端上信号、以及执行RAG检索链路。RAG框架与主流方案基本一致，但在细节上进行了大量定制化改造。在粗召回阶段，通过大模型改写、HyDE（假设文档嵌入）改写优化查询语义，再结合向量检索、实体检索、Web搜索实现多路召回；精排环节早期采用bge reranker，后续升级为大模型排序，配合多种策略进行重排。

整个RAG检索体系的底层支撑是通用RAG平台，它整合了售后客服QA、商品百科、用户手册、米车销服等海量数据源。该平台的设计理念是“底层通用、上层定制”。模型管理模块统一部署各类排序和向量模型；数据分层模块负责文档解析、知识切片，并封装了语义、关键词、多模态检索能力；业务支撑模块则向上游提供调用接口，同时承载AB测试、版本管理、服务监控等工具。

需要强调的是，虽然这个平台名为“通用”，但在实际运行中会发现，80%的效果取决于定制化的切片策略。固定长度切分、标点符号切分等通用方案，在垂直场景中往往难以适应。要将系统可用性从90分提升至95分，必须深入理解业务特性与用户query分布，针对性地设计自定义切片方案。这正是各垂直领域RAG系统的核心竞争力所在。

03 落地难点

第一个关键挑战是知识库的向量化。小米商品百科数据规模庞大，手机、电视等品类的参数表格密集复杂，价格与库存为实时数据，更新不及时将严重影响用户体验。为保障数据时效性，团队首先设计了一套高效的离线实时更新合并流程。数据接入后，既要生成向量文本，还需完整保留层级索引关系——商品名称、属性归属、品类层级等结构化信息，以JSON格式存储于专用Schema库，与向量检索配合使用。

别名自动化模块同样是必须解决的问题。用户并非每次都会使用官方名称，例如“红米K80”可能被称作“红米80”或“K80”，因此团队专门构建了别名知识库。以红米Turbo 4的参数页面为例，得益于内部API接口，团队可直接获取格式化JSON数据，省去了文档解析的繁琐步骤。最终的向量化方案简洁高效：将goods+attr+value拼接，生成多组文本进行向量化，取得了良好效果。

汽车场景的挑战更为严峻，核心在于静态知识与动态知识的显著差异。静态知识（如用户手册）可离线建设，但文档解析、索引构建等步骤不能简单套用开源工具。例如，说明书的标题、段落、图片、表格均需解析，还需建立各级标题的父子映射关系，以及文本、图片、表格与标题的索引关联。切片时基于标题进行chunk切分，但若chunk超过1500 token，召回效果会显著下降，此时需结合语义模型进行二次切分，同时保留片段与标题的索引对应关系。向量构建不仅是对单个chunk做embedding，而是将block文本、标题+文本、表格表头、表格元素组合起来，进行多维度编码，召回率明显提升。

动态信号处理是另一核心挑战。车载场景中存在三类动态信号：SC信号（软件类，如空调温度，数量超过1900个，多为工程代码级字符串）、系统控制信号（安卓系统自带，格式规范）、CarloT信号（车载配件设备）。信号梳理完成后，数据分别流向小爱信号平台（支持实车环境实时检索）和静态知识库平台。针对开关类信号字段为硬编码字符串的问题，直接检索难以匹配用户自然语言query，因此需借助大模型进行辅助增强检索。对于语义不完整（指代问题、信息缺失）和语义不匹配（因果推理、用户表述差异）的情况，基于LLM进行SFT任务实现query改写，包括多轮rewrite和HyDE生成潜在query。

在领域知识检索的精细化阶段，早期的bge-reranker模型通过微调与架构改造，能有效区分Top-K头部样本的匹配度，但对尾部冗余样本的过滤效果不佳。随后尝试在大模型精排后增加重排模块，但因链路延迟过高而放弃。最终方案是直接让大模型担任排序器——将粗召回样本从数千级压缩至Top-60，采用Point-wise策略对单个候选文档独立打分。Pair-wise因prompt过长导致性能问题，同样被舍弃。最终效果显示：在复杂测试集上，大模型召回率与bge-reranker持平，但准确率显著提升，注入的文档数量从5篇降至3篇。

在回复对齐方面，团队总结了大模型的7项基础能力：知识总结摘要、特定信息提取、复杂推理、多轮交互、指代消歧、兜底回复等，再结合线上业务细分为16种细分能力。数据构建采用轻量化迭代策略——每个能力先进行少量标注，验证效果后再扩展，避免一次性大规模投入。全参微调效果优于LoRa，可使准确率提升2-3个百分点。如需优化回复风格，可叠加DPO（直接偏好优化），通常带来1-2个点的增益。模型选型上，考虑到线上延迟限制，最终采用7B轻量级模型，通过知识蒸馏加精标SFT数据混合训练，效果接近千亿级大模型。几个关键经验：样本质量远重于数量；先拿100条数据验证，有效果再扩充；prompt多样性可保留，但response需收敛，垂直领域助手不需要发散性回答；复杂推理任务可拆解为子任务进行课程学习。

最后，品牌舆情管理同样是垂直问答系统中不可忽视的关键环节。信息必须准确无误，以官方发布为准，不得杜撰；回复需保持客观，对公司进行正向引导。解决方案包括自研AI联网搜索以控制信源质量，以及通过SFT+DPO进行后训练对齐优化。

04 小结

回顾小米的垂直领域问答实践，核心经验可归纳为四点：一是知识库构建，基于多源数据Chunk切分与大模型辅助的向量化；二是领域检索模型优化，从bge-reranker微调升级至大模型排序；三是引入多轮改写模块解决多轮检索问题；四是回复对齐与品牌舆情管理，通过SFT+DPO组合优化解决业务场景中的各类问题。

05 Q&A

Q1：定制化分块策略在通用RAG平台上如何实现兼容与支持？

A1：平台在设计阶段便与开发方约定了接口协议，支持自定义切片策略。开发者按照既定协议封装切片逻辑，即可无缝移植至平台，实现通用能力与定制化需求的有机结合。

Q2：如何前置评估query改写质量？

A2：可采用两种方法：量化评估方面，ROUGE-l等指标可衡量生成文本与参考文本的匹配度，作为定量观测指标；业务导向评估方面，结合具体目标设计评测集，例如对比改写前后检索任务的召回率与准确率，直接反映改写对业务效果的提升效果。