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

电商AI智能客服，表面上看起来只是自动回复，但真正实现高质量落地，尤其是面对海量SKU、实时变化的平台规则和五花八门的用户需求时，技术挑战远比想象中复杂。熠智AI作为这个赛道的新锐玩家，在服务淘宝、天猫、京东、拼多多、快手、抖音、闲鱼等主流平台头部店铺的过程中，积累了不少实战经验。核心问题在于：如何让AI在动辄上万的商品库中，精准理解用户“这个怎么样”“耗电吗”“怎么安装”里的“这个”到底指什么？当大促期间咨询量暴增十几倍，技术架构如何扛住压力？

以下技术实现与试错过程，来自熠智AI一线团队的深度拆解。

01 核心需求拆解

在着手搭建技术架构前，我们先梳理了智能客服RAG过程中最棘手的几类挑战：

用户大量问题像“这个怎么样/耗电吗/怎么安装”，如果第一步没搞清楚“这个”到底指哪个商品，后续的一切都毫无意义。商品一旦检索错，生成再好也是白搭。

商品检索既要处理“制热快不快”这种强语义问题，也要应对型号、系列名、SKU、简称等强词法查询。单靠一种检索策略，要么语义对了但商品张冠李戴，要么商品找对了但细节答非所问。

既有通用QA（售后、物流、保修），也有商品知识（参数、卖点、说明书），还可能涉及结构化表格（活动价、规格清单、库存数据）。如果一股脑塞进一个知识库，后期治理和迭代都很痛苦。

比如用户查询“@暖风机表格中价格小于100的商品”，基于相似度的语义检索根本无能为力。

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

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

早期版本中，我们采用了单一的Ragflow架构。不得不说，RAGFlow在复杂格式文档处理方面确实优秀，无论是复杂表格还是技术文档都能很好解析。但随着业务增长，接入的店铺数据量和咨询场景复杂度飙升，单纯依赖Ragflow开始暴露出严重的工程与业务痛点。

首先是Ragflow只能对信息做粗放式的切片处理，检索粒度完全不可控，导致大量无关噪音混入上下文。同时系统本身日益臃肿，维护难度和系统脆弱性同步上升。

经过大量调研与测试，在技术架构升级的第二阶段，我们将语义搜索的向量数据库迁移到了Milvus，与Postgres传统数据库的精确匹配形成互补。新的思路是把检索与数据链路拆成可演进的模块。具体来说，一次对话请求被拆解为四段：

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，作为索引指针。这里只存储用于计算相似度的向量和主键ID（product_{productId}），不存放冗余业务字段。索引选择IVF_FLAT，平衡检索速度和存储成本。

：商品的实时价格、高清图片URL、上下架状态等结构化信息存储在Postgres中。

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

如前所述，用户的Query五花八门，有时还存在指代不明。比如用户进线看了“美的取暖器”后问：“这个制热快吗？”如果直接拿“这个制热快吗”去检索，召回率几乎为零。为此，我们在检索前引入了

。

通过QuestionRewriteUtil，利用LLM对用户问题进行重写，转化为最新问题（latestQuestion）。例如：原始问题“这个制热快吗？”重写后变为“美的取暖器制热效果如何？”这一步把对话语句转化为检索语句，对后续召回准确率起到决定性作用。

3.4 向量查询

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

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

客服场景对响应速度极其敏感。我们将知识库分为两层：QA通用库（售后政策、退换货流程）和商品专属库（商品参数、规格）。在Workflow.run()中，利用线程池进行并行执行。

• QA检索
  ：使用原始问题

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

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

• 商品名称向量（goodnamevector）
  ：权重70%，侧重对象定位，确保搜到正确的商品

• 描述向量（describevector）
  ：权重30%，侧重语义理解，提升回答细节的相关性

系统并行检索这两个字段，合并得分后进行加权融合重排序。返回的主键ID会到PostgreSQL进一步查询，获取最精准的商品数据，最后由大模型根据QA检索和商品检索的topK数据生成回复。

3.4.2 自定义表格检索引擎

以上是标准的RAG流程，但企业内部还有大量结构化数据（如Excel价格表、参数对比表）。对于“查询价格小于100的商品”这类数值比较问题，纯向量检索几乎不可用。为此，我们在Agent模式下开发了自定义表格检索引擎，借助Milvus及Agent能力实现精确查询与语义检索的结合。

04 实施效果与验证

相比单纯使用RAGflow，基于Milvus搭建的灵活集中功能组件方案，让商品检索的召回率大幅提升，达到95%。Milvus对检索精度的掌控力、原生支持的混合检索能力、极高的性能扩展性和社群活力，挖掘出我们产品更大的潜力。

05 尾声

在AI智能电商客服赛道上，智能检索需要面对对象定位、语义与词法冲突等多重挑战。基于Milvus搭建的分层检索体系，不仅实现了精准的商品定位、高效的多源知识融合、稳定的高并发支撑，也让熠智AI客服的回复质量与服务效率实现双重飞跃。未来，还将进一步深化对Milvus的使用，引入混合检索等能力，在关键词模块用Milvus的BM25替代对传统数据库的依赖，降低后期维护成本。