熠智AI+Milvus:从Embedding 到数据处理、问题重写，电商AI客服架构怎么搭？

本文来自熠智 AI 的一线工程师投稿。

熠智 AI，是电商智能客服赛道的新锐玩家，目前已经打通淘宝、天猫、京东、拼多多、快手、抖音、闲鱼等主流电商平台，深度服务多家头部店铺，跻身智能客服解决方案一线梯队。

在他们看来，做智能客服容易，但做好智能客服却很难，做好头部电商的智能客服更是难上加难。不仅客户的SKU 动辄上万、平台规则实时变动 ，用户需求更是五花八门。这就对答语的准确性、真实性提出更严苛要求。

尤其遇上大促节点，咨询量暴增十几倍，整体技术架构面临的压力也会陡增。

因此，做好一个电商智能客服，其技术架构，设计难度以及细节，远比我们想象的要多且复杂。

以下是熠智AI的技术实现以及完整试错流程。

01

核心需求拆解

正式开始技术落地前，我们先梳理了智能客服 RAG 的过程中，最核心的几类挑战：

对象定位难

用户大量问题是“这个怎么样/耗电吗/怎么安装”，如果没先定位“这个”到底指哪一个商品，后面一切都无意义。只要商品检索错了，后面生成再好也没用。

语义理解与词法匹配的冲突

商品检索里既有强语义（比如：制热快不快），也有强词法（型号、系列名、SKU、简称）。单靠一种检索策略，很容易要么“语义对了商品错了”，要么“商品对了细节不相关”。

知识源多且形态不一

既有通用 QA（售后、物流、保修），也有商品知识（参数、卖点、说明书内容），还可能有结构化表格（活动价、规格清单、库存/渠道数据）。如果进同一个知识库，后期很难治理、也难迭代。

存在完全无法通过语义检索的场景

用户可能会查询@暖风机表格中价格小于100的商品，依托于相似度的语义检索无法精确解决类似问题。

时延、成本与稳定性约束

客服是高并发、强实时，必须在可控的 token 开销与可预测的时延下运行。能规则化解决的问题要前置拦截；需要检索的问题要尽量并行；检索结果要尽量少而准。

02

架构演进：从单一Ragflow ，到多模块RAG系统

基于上文提出的五大类挑战，在架构搭建的早期版本中，我们采用了单一的Ragflow架构。

这里必须承认一点，RAGFlow的深度文档能力非常优秀，在复杂格式文档处理方面，无论是复杂表格，还是学术论文、技术文档，都能很好的解析。

但随着公司业务增长，我们接入的店铺数据量增长和咨询场景变得复杂，单纯的Ragflow开始暴露出了严重的工程与业务痛点：

首先是Ragflow只能对信息进行粗放式切片（Chunk）处理，检索粒度完全不可控，导致大量无关噪音混入上下文。

与此同时，Ragflow系统本身日益臃肿，维护难度大，系统脆弱性增加。于是，在经过大量的调研与测试以后，在技术架构升级的第二阶段，我们将语义搜索的向量数据库迁移到了Milvus，与postgres传统数据库的精确匹配形成互补。

基于这些挑战，我们选择把检索与数据链路拆成可演进的模块，并采用Milvus 这个开源的向量检索中间件来解决这些问题。

具体来说，新的思路中，我们会把一次对话请求拆成四段：

1. Query 理解：把口语化对话句转成可检索表达

2. 分层并行检索：通用知识库（QA）与商品知识库（Product）并行召回并使用rerank重排

3. 两级回填拼装：Milvus 做召回与排序，Postgres 做权威字段与内容拼装

4. 基于证据生成：把检索结果分层注入 prompt，约束 LLM 在证据范围内回答

同时为提高拓展智能客服的智能上限，我们还拓展了Agent智能检索的能力，基于Milvus结合LLM开发了自定义表格检索引擎：让模型能查结构化数据，并保持确定性。

03

五个核心技术实现设计

智能客服的底层技术架构本质是RAG，但它的实际工程化以及选型细节却比RAG要复杂得多。我们共计梳理了四大环节的五大技术实现细节供大家参考：

3.1. 数据收集与预处理：单商品单记录策略

构建知识库首先要有数据。但与业界通用的将文档切分为碎片化 Chunks 分散存储的方案不同，我们发现商品数据具有极强的内聚性。如果把一个商品的参数、描述、评价拆得太散，检索时很难拼凑出全貌。

因此，我们采取了单商品单向量记录的策略 。 我们在同步数据到 Milvus 时，将一个商品下的所有内容块预先拼接合并，存为一条 Milvus 记录，ChunkID 统一格式为product_{productId}。

这种设计让 Milvus 中的记录数从N*M降低到了N（N=商品数），不仅显著降低了存储成本，更简化了后续的召回拼装逻辑：一次命中，即可获得该商品的完整上下文。

3.2. Embedding 与索引架构：两级存储设计

有了清洗好的数据，接下来是构建索引。我们采用了一套Milvus + PostgreSQL的两级检索架构，以此来兼顾检索速度与数据的权威性。

向量库（Milvus）负责找得准： 我们将数据向量化后存入 Milvus，作为索引指针。这里并不存储冗余的业务字段，只存储用于计算相似度的向量和主键 ID（product_{productId}）。然后选择IVF_FLAT索引，平衡检索速度和存储成本。

关系库（PostgreSQL）负责信息全： 商品的实时价格、高清图片 URL、上下架状态等结构化信息存储在 Postgres 中。

3.3. 查询前置处理：问题重写

如前面困境所说，用户的 Query 实际是多种多样的，有简单的 Query，也有指代不明的 Query。比如用户进线看了“美的取暖器”，然后问：“这个制热快吗？”。

如果直接拿“这个制热快吗”去检索，召回率几乎为零。为此，我们在检索前引入了Query 转换模块。 通过QuestionRewriteUtil，利用 LLM 对用户问题进行重写，将问题转化为最新问题(latestQuestion) 。

例如：

原始问题：“这个制热快吗？”

重写后：“美的取暖器制热效果如何？”

这一步把对话语句转成检索语句，对后续的召回准确率起到了决定性作用。

3.4. 向量查询

这是整个系统的核心。为了解决用户千奇百怪的提问方式，我们设计了多维度的检索策略。根据用户输入情况，自动选择最合适的检索策略。

3.4.1 双层知识库并行检索+postgre回填

客服场景对响应速度极其敏感。我们的知识库分为两层：

QA 通用库：存储通用的售后政策、退换货流程 。

商品专属库：存储具体的商品参数、规格 。

在Workflow.run()中，我们利用线程池进行并行执行。

• QA 检索：使用原始问题。

• 商品混合检索：使用重写后的焦点商品+问题。

• 其中在Milvus的商品混合检索中我们面临一个经典冲突：用户搜“HP21-K6”时需要精确的对象定位，搜“适合老人的取暖器”时需要模糊的语义理解。单一的向量索引很难同时满足。 为此，我们在 Milvus 中为每条记录维护了两个向量字段，并赋予不同权重：

• 商品名称向量 (goodnamevector)：权重70%。侧重对象定位，保证搜出来的是正确的那个商品。

• 描述向量 (describevector)：权重30%。侧重语义理解，提升回答细节的相关性。 系统并行检索这两个字段，确保了“先找对商品，再匹配细节”。

系统并行检索这两个字段，合并得分后进行加权融合重排序。

返回的主键 ID（product_{productId}），会到PostgreSQL进一步查询，返回最精准的商品数据。

最后，大模型会根据QA检索以及商品检索返回的topK 个数据生成回复。

3.4.2 自定义表格检索引擎

上面所说的算是一个比较标准的 RAG 流程，但是企业内部有大量的结构化数据（如 Excel 价格表、参数对比表）。对于“查询价格小于 100 的商品”这类涉及数值比较的问题，纯向量检索几乎不可用。

为此，我们在 Agent 模式下开发了自定义表格检索引擎，借助Milvus及Agent的能力实现自定义表格的检索功能，既保证了查询的精确性，也保证了语义检索的准确性。

04

实施效果与验证

比起单纯使用RAGflow的技术框架，我们在Milvus基础上设计了更加灵活集中功能组件的方案,让商品在多种业务场景下检索的召回率大大提升，在商品检索的召回率提升至95%。

Milvus对检索精度极高的掌控力以及原生支持的混合检索的能力，以及极高的性能扩展性和社群活力，挖掘出了我们产品更大的潜力。

05

尾声

在 AI 智能电商客服的赛道上，智能检索需要面临对象定位、语义与词法冲突等多重挑战，但基于 Milvus 搭建的分层检索体系，不仅实现了精准的商品定位、高效的多源知识融合、稳定的高并发支撑，也让熠智 AI 电商客服的回复质量与服务效率实现双重飞跃，赢得了合作头部店铺的广泛认可与信赖。

未来，熠智AI还将进一步深化对Milvus的使用，引入Milvus混合检索等能力，在关键词模块，使用Milvus的BM25替代对传统数据库的依赖，降低后期的系统维护难度。