推荐语
电商AI客服如何应对海量SKU与复杂需求？熠智AI分享从Embedding到数据处理的全流程实战经验。核心内容： 1. 电商智能客服面临的五大核心挑战与需求拆解 2. 从单一Ragflow到多模块RAG系统的架构演进历程 3. Milvus向量数据库与传统数据库的互补应用实践
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
熠智 AI，是电商智能客服赛道的新锐玩家，目前已经打通淘宝、天猫、京东、拼多多、快手、抖音、闲鱼等主流电商平台，深度服务多家头部店铺，跻身智能客服解决方案一线梯队。在他们看来，做智能客服容易，但做好智能客服却很难，做好头部电商的智能客服更是难上加难。不仅客户的SKU 动辄上万、平台规则实时变动 ，用户需求更是五花八门。这就对答语的准确性、真实性提出更严苛要求。尤其遇上大促节点，咨询量暴增十几倍，整体技术架构面临的压力也会陡增。因此，做好一个电商智能客服，其技术架构，设计难度以及细节，远比我们想象的要多且复杂。01
核心需求拆解
正式开始技术落地前，我们先梳理了智能客服 RAG 的过程中，最核心的几类挑战：用户大量问题是“这个怎么样/耗电吗/怎么安装”，如果没先定位“这个”到底指哪一个商品，后面一切都无意义。只要商品检索错了，后面生成再好也没用。商品检索里既有强语义（比如：制热快不快），也有强词法（型号、系列名、SKU、简称）。单靠一种检索策略，很容易要么“语义对了商品错了”，要么“商品对了细节不相关”。既有通用 QA（售后、物流、保修），也有商品知识（参数、卖点、说明书内容），还可能有结构化表格（活动价、规格清单、库存/渠道数据）。如果进同一个知识库，后期很难治理、也难迭代。用户可能会查询@暖风机表格中价格小于100的商品，依托于相似度的语义检索无法精确解决类似问题。客服是高并发、强实时，必须在可控的 token 开销与可预测的时延下运行。能规则化解决的问题要前置拦截；需要检索的问题要尽量并行；检索结果要尽量少而准。
02
架构演进：从单一Ragflow ，到多模块RAG系统
基于上文提出的五大类挑战，在架构搭建的早期版本中，我们采用了单一的Ragflow架构。这里必须承认一点，RAGFlow的深度文档能力非常优秀，在复杂格式文档处理方面，无论是复杂表格，还是学术论文、技术文档，都能很好的解析。但随着公司业务增长，我们接入的店铺数据量增长和咨询场景变得复杂，单纯的Ragflow开始暴露出了严重的工程与业务痛点：首先是Ragflow只能对信息进行粗放式切片（Chunk）处理，检索粒度完全不可控，导致大量无关噪音混入上下文。与此同时，Ragflow系统本身日益臃肿，维护难度大，系统脆弱性增加。于是，在经过大量的调研与测试以后，在技术架构升级的第二阶段，我们将语义搜索的向量数据库迁移到了Milvus，与postgres传统数据库的精确匹配形成互补。基于这些挑战，我们选择把检索与数据链路拆成可演进的模块，并采用Milvus 这个开源的向量检索中间件来解决这些问题。具体来说，新的思路中，我们会把一次对话请求拆成四段：
- 分层并行检索：通用知识库（QA）与商品知识库（Product）并行召回并使用rerank重排
- 两级回填拼装：Milvus 做召回与排序，Postgres 做权威字段与内容拼装
- 基于证据生成：把检索结果分层注入 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回填
客服场景对响应速度极其敏感。我们的知识库分为两层：在Workflow.run()中，我们利用线程池进行并行执行。
- 其中在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对检索精度极高的掌控力以及原生支持的混合检索的能力，以及极高的性能扩展性和社群活力，挖掘出了我们产品更大的潜力。5
尾声
在 AI 智能电商客服的赛道上，智能检索需要面临对象定位、语义与词法冲突等多重挑战，但基于 Milvus 搭建的分层检索体系，不仅实现了精准的商品定位、高效的多源知识融合、稳定的高并发支撑，也让熠智 AI 电商客服的回复质量与服务效率实现双重飞跃，赢得了合作头部店铺的广泛认可与信赖。未来，熠智AI还将进一步深化对Milvus的使用，引入Milvus混合检索等能力，在关键词模块，使用Milvus的BM25替代对传统数据库的依赖，降低后期的系统维护难度。
粤ICP备14082021号
免费POC，
零成本试错
