电商 AI 客服从 0 到 1：Workflow、RAG 与评测闭环落地

AI 客服要解决的不是“自动回复”，而是可控地替人工接待

电商客服有几个典型特点：问题重复率高、咨询入口多、商品和订单信息变化快、错误回答的代价高。用户问“这件衣服有多长”“什么时候发货”“退货运费谁出”，看起来都是自然语言问答，背后却需要系统同时理解用户意图、识别商品或订单、检索商家知识、读取实时状态，再把这些信息组织成一句可靠的回复。

一个能上线的 AI 客服系统，目标不是让大模型自由发挥，而是让它在明确边界内工作：

• 能回答：商品参数、活动规则、物流政策、退换货说明、历史高频问答。
• 不能乱答：知识库没有依据、订单状态不确定、售后处理需要人工判断时，要转人工或追问。
• 能持续迭代：模型、提示词、知识库、检索策略、业务流程变化后，要能评测影响范围。

可以把 AI 客服拆成四层：

flowchart TD
    A[用户咨询] --> B[入口与会话上下文]
    B --> C[意图识别与流程路由]
    C --> D1[售前咨询流程]
    C --> D2[售后咨询流程]
    D1 --> E[知识检索与实时查询]
    D2 --> E
    E --> F[上下文组装]
    F --> G[大模型生成回复]
    G --> H{置信度与规则校验}
    H -->|可回答| I[返回用户]
    H -->|不确定或高风险| J[转人工/澄清问题]

这套结构的核心是“路由 + 检索 + 生成 + 校验”。大模型负责理解和表达，但不应该承担所有职责。流程能拆清楚，成本、稳定性和可维护性才有优化空间。

Dify 和工程化代码的边界

项目早期经常会面临一个选择：用智能体开发平台快速搭建，还是直接写工程化代码。

Dify 这类平台适合做 MVP（最小可行产品）验证。它提供可视化 Workflow、模型接入、工具调用、知识库、调试界面，能让产品和研发快速试出一条可用链路。对于 AI 客服这种不确定性很高的业务，早期速度很重要，先验证 PMF（产品市场契合度）比一开始追求完美架构更实际。

但平台化方案进入生产高并发场景后，会遇到几个限制：

更稳妥的落地方式是分阶段演进：

混合架构里，最适合先工程化的是知识召回检索。RAG（检索增强生成）链路直接影响回答质量和响应时间，而且通常需要结合业务做过滤、加权、缓存和实时查询。

flowchart LR
    A[Dify Workflow] --> B[意图识别]
    B --> C{核心链路?}
    C -->|否| D[Dify 节点处理]
    C -->|是| E[自研工程服务]
    E --> F[知识召回]
    E --> G[实时接口查询]
    E --> H[上下文组装]
    H --> A

后期如果需要把平台上的流程迁移到代码，可以考虑 Spring AI Alibaba Studio 这类工具，把可视化设计过的应用逻辑导出为标准 Spring AI 工程，再接入常规研发体系。

模型选择：不要只看榜单，要看业务链路里的表现

模型是 AI 客服的大脑，但“最强模型”不一定是“最适合当前链路的模型”。售前咨询、售后咨询、意图识别、问题改写、负面情绪识别，对模型能力和成本的要求不同。

模型选型可以按几个维度评估：

早期可以用能力更强的模型快速跑通完整流程，例如把意图识别、问题改写、重复问题识别、负面情绪识别都放到一个节点里处理。这样能减少流程拆解成本，尽快上线验证。

当流量上来后，成本和延迟会变成主要矛盾。一个常见优化是把部分节点从 GPT-4.1 这类高成本模型切到 Qwen 等更经济的模型，尤其是意图识别这种输出结构相对固定的任务。

模型切换不要凭感觉，需要评测集支撑。人工抽样能发现明显问题，但无法覆盖大量边界场景。Langfuse 这类评测工具可以把模型输出、提示词版本、输入上下文、评估结果记录下来，方便做回归对比。

还有一个容易被忽略的点：模型输出越少，速度越快，成本越低。能返回常量就不要返回大段 JSON。

不推荐：
{
  "intent": "pre_sale_product_consult",
  "confidence": 0.93,
  "reason": "用户正在询问商品尺码，属于售前商品咨询"
}

更推荐：
pre_sale_product_consult

如果业务确实需要解释原因，可以只在离线评测或调试环境打开，线上主链路保持精简。

Workflow 和 Agent 的取舍

AI Agent（智能体）强调自主规划、工具调用和动态决策。它适合开放任务，但在客服主链路里也会带来不确定性：路径不可控、耗时不可控、错误排查困难。

Workflow（工作流）更像传统后端流程编排。每个节点负责一个明确任务，输入输出固定，异常分支可预期。对于“不能答错”的客服系统，Workflow 往往更适合作为起点。

电商客服更适合从 Workflow 起步，再逐步引入 Agent 能力。比如主链路仍由 Workflow 控制，复杂售后问题里的“信息补全”“多工具查询”可以让 Agent 在受限范围内执行。

工作流从粗到细演进

版本 1：一个强模型快速承接售前咨询

早期版本可以把多个职责合并到一个模型节点里：

• 判断用户意图。
• 改写用户问题，让检索更准确。
• 识别重复问题。
• 识别负面情绪。
• 根据知识库生成回复或转人工。

flowchart TD
    A[用户问题] --> B[综合理解节点]
    B --> B1[意图识别]
    B --> B2[问题改写]
    B --> B3[重复问题识别]
    B --> B4[负面情绪识别]
    B --> C{是否可由 AI 回答}
    C -->|是| D[知识检索]
    D --> E[生成售前回复]
    C -->|否| F[转人工]

这种做法上线快，缺点也明显：单节点提示词很复杂，修改任何一项能力都可能影响其他能力；模型成本高；错误定位困难。

版本 2：拆分节点并降低成本

当目标转向降低成本和扩大 AI 承接率时，可以把综合节点拆开，尤其是把意图识别从高成本模型切到更便宜的模型。

flowchart TD
    A[用户问题] --> B[历史对话整理]
    B --> C[重复问题识别]
    B --> D[负面情绪识别]
    B --> E[问题改写与意图识别]
    E --> F{路由}
    F -->|售前可答| G[知识检索]
    G --> H[生成回复]
    F -->|不确定/负面/高风险| I[转人工]

模型切换后，需要关注平台自带记忆机制是否会放大幻觉。如果某个模型对 Dify 的历史记忆拼接比较敏感，可以自己维护一个全局历史对话变量，只把必要轮次和必要字段拼入 System Prompt（系统提示词）。

示例结构：

历史对话：
用户：这件是现货吗？
客服：当前商品库存充足，正常下单后安排发货。
用户：那多久能到？

不要把完整会话无脑塞给模型。客服上下文里有很多噪声，例如寒暄、重复追问、无效情绪表达，全部塞进去会降低回答稳定性。

版本 3：售前和售后分流

售前和售后的回答风格不同：

• 售前更偏引导，重点是商品参数、优惠活动、购买建议。
• 售后更偏严谨，重点是订单状态、物流政策、退款退货规则。

把两类问题放在同一个流程里，会让提示词越来越复杂，也会增加误答概率。更合理的方式是先做意图路由，再进入不同流程。

flowchart TD
    A[用户问题] --> B[意图识别]
    B --> C{咨询类型}
    C -->|售前| D[售前流程]
    C -->|售后| E[售后流程]
    C -->|闲聊/无关| F[兜底回复或转人工]

    D --> D1[商品知识检索]
    D --> D2[商品实时信息查询]
    D1 --> D3[售前回复生成]
    D2 --> D3

    E --> E1[订单/物流查询]
    E --> E2[售后政策检索]
    E1 --> E3[售后回复生成]
    E2 --> E3

这种设计牺牲了一些灵活性，但换来了可控性。客服场景里，回答错误比不回答更危险。承接率到一定阶段后，如果继续提高，重点不只是优化意图识别，而是拓展可安全承接的业务场景。

上下文工程：不要把所有信息都塞给模型

上下文工程的目标是让模型看到“足够、准确、结构清晰”的信息。窗口再大，也不能随意填充。信息过载会让模型忽略关键事实，甚至在冲突知识里选择错误内容。

上下文处理可以分三步：获取、筛选、组装。

flowchart LR
    A[信息获取] --> B[筛选提纯]
    B --> C[结构化组装]
    C --> D[模型生成]
    
    A1[商品静态知识] --> A
    A2[实时库存/物流/订单] --> A
    A3[历史高频 QA] --> A
    A4[商家文档] --> A
    
    B1[入口场景过滤] --> B
    B2[语义相关性过滤] --> B
    B3[权重加权] --> B

信息获取：静态知识和动态信息分开

商品详情、商品主图、规格参数属于相对静态的信息，可以提前抽取并入库。库存、商品状态、预售信息、订单物流属于动态信息，不适合预先写入向量库，应该在会话中通过接口实时查询。

多模态模型可以替代部分 OCR（光学字符识别）工作。OCR 只能识别图片里的文字，多模态模型还能理解图片结构，过滤装饰信息，并把商品详情页里的规格、卖点、注意事项整理成更适合检索的文本。

但多模态抽取也会带来知识冲突。例如商品规格里没有紫色款，商品详情图却出现紫色车，模型可能会误以为存在紫色规格。解决这类问题不能只靠提示词，还要在上下文里定义知识优先级：规格信息优先于详情图描述，实时接口优先于离线知识。

筛选提纯：让上下文有更高信噪比

入口场景会影响知识权重。用户在商品详情页提问，应优先检索当前商品知识，而不是全店通用知识；用户从订单页进入，应优先加载订单和物流信息。

可以用一个简单的加权策略控制召回结果：

def final_score(query, chunk, scenario):
    semantic = semantic_similarity(query, chunk.text)
    scenario_weight = get_scenario_weight(chunk.source, scenario)
    source_weight = get_source_weight(chunk.source)
    return semantic * scenario_weight * source_weight

candidates = retrieve(query)

selected = [
    chunk for chunk in candidates
    if final_score(query, chunk, scenario) >= threshold
]

权重示例：

信息组装：结构化比纯文本拼接更可控

早期常见做法是把知识片段直接拼成一段字符串。随着知识源变多，这种方式容易出现重叠、冲突和优先级不清晰的问题。

结构化组装更适合客服场景。模型能更明确地区分商品信息、物流政策、历史问答和实时查询结果。

<知识库>
  <商品信息>
    <商品名称>知识片段</商品名称>
    <商品规格 priority="high">知识片段</商品规格>
    <商品详情 priority="medium">知识片段</商品详情>
    <实时库存 priority="highest">接口返回结果</实时库存>
  </商品信息>

  <物流政策信息 priority="high">
    知识片段
  </物流政策信息>

  <历史问答 priority="medium">
    <qa>
      <question>用户高频问题</question>
      <answer>经过清洗后的答案</answer>
    </qa>
  </历史问答>
</知识库>

提示词里要明确说明优先级：

回答规则：
1. 如果实时接口结果与离线知识冲突，以实时接口结果为准。
2. 如果商品规格与商品详情描述冲突，以商品规格为准。
3. 如果知识库没有依据，不要猜测，转人工或追问。
4. 售后问题必须严格依据订单信息和售后政策回答。

知识工程：商品、历史对话、文档三条线并行

商品知识：预学习 + 实时查询

商品知识分成两类：

• 预学习商品信息：主图、规格、详情页内容。
• 实时商品信息：库存、上下架状态、预售物流、当前价格等。

预学习适合通过离线任务完成：

flowchart LR
    A[商品主图/详情/规格] --> B[多模态抽取]
    B --> C[清洗与切片]
    C --> D[向量化]
    D --> E[(向量数据库)]

实时信息不能入库后长期使用，应在流程中按需查询：

sequenceDiagram
    participant U as 用户
    participant W as Workflow
    participant API as 商品/订单接口
    participant LLM as 大模型

    U->>W: 这件什么时候发货？
    W->>API: 查询商品状态、库存、预售信息
    API-->>W: 返回实时结果
    W->>LLM: 注入实时信息和政策知识
    LLM-->>W: 生成回复
    W-->>U: 返回答案

历史对话知识：从高频问题里抽取 QA

客服历史对话里有很多“文档里没有但人工经常回答”的隐性知识。把这些内容抽成 QA（问答对）后，可以补充知识库。

历史对话处理难点主要有三个：

• 数据量大，噪声多。
• 同一个问题表达方式很多，需要去重。
• 人工客服回答不一定全部正确，需要质量判断。

可行流程如下：

flowchart TD
    A[历史会话] --> B[按咨询维度分组]
    B --> C[大模型抽取 QA]
    C --> D[RAG 相似问题去重]
    D --> E[QA 分类]
    E --> F[质量审核]
    F --> G[(历史 QA 知识库)]
    G --> H[单独召回]

历史 QA 不建议直接和普通文档混在一起召回。可以单独建召回通道，提高精准匹配权重，避免低质量历史答案影响主知识库。

文档知识：切片参数要平衡完整性和密度

商家上传的说明文档需要切片后入库。切片太短，语义被切碎；切片太长，召回片段信息密度低，容易带入无关内容。

两个关键参数：

一个可用起点是：

chunk_size: 600
chunk_overlap: 100

这不是固定最优值。商品说明、售后政策、活动规则的文本结构不同，需要结合评测结果调整。

评测体系：AI 客服不能只靠人工试几句

传统软件测试面对的是确定逻辑，输入固定，输出可预期。AI 客服不同，同一个问题可能因为模型版本、提示词、上下文、召回片段变化而输出不同结果，所以需要专门的评测体系。

一个完整评测体系至少包含四部分：

flowchart TD
    A[评测对象] --> E[评测任务]
    B[评测数据集] --> E
    C[评估指标] --> E
    E --> D[评测结果]
    D --> F[根因分析]
    F --> G[优化提示词/知识/流程/模型]
    G --> E

评测对象

评测对象不要只看端到端回复，也要拆到节点级别。

评测数据集

上线前可以从历史对话中抽取一批问题，再人工构造边界用例。上线后，要持续沉淀线上 Goodcase 和 Badcase：

• Goodcase：回答准确、无需人工介入的样本。
• Badcase：答错、没答全、召回错误、误转人工、语气不合适的样本。

数据集要记录完整上下文，包括用户入口、商品信息、订单状态、召回片段、模型版本、提示词版本。否则只保存一句用户问题，后续很难复现问题。

评估指标

AI 客服的指标不能只看“回答是否像人工”。更实用的指标包括：

对于回复相似度，可以用评估器基于历史标准答案判断，但高风险问题仍要保留人工审核。售后政策、退款金额、物流承诺这类问题不能只依赖语义相似度。

反馈闭环：从 Badcase 找到真正原因

线上 Badcase 不能只归因于“大模型不稳定”。同样的错误回复，根因可能完全不同：

反馈闭环可以这样设计：

flowchart LR
    A[线上会话巡检] --> B[识别 Badcase]
    B --> C[标注问题类型]
    C --> D[根因分析]
    D --> E{优化方向}
    E -->|知识缺失| F[补充/清洗知识]
    E -->|流程错误| G[调整路由和节点]
    E -->|提示词问题| H[修改 Prompt]
    E -->|模型问题| I[模型评测与切换]
    F --> J[回归评测]
    G --> J
    H --> J
    I --> J
    J --> A

只有把“评测 -> 优化 -> 再评测”跑顺，AI 客服才会稳定进化。否则每次改提示词都像手工调参，修好一个问题又引入另一个问题。

协作方式也要跟着变

AI 项目里，Prompt、上下文、业务规则、知识库并不是完全独立的模块。一个提示词调整可能改变意图识别结果，一个知识优先级调整可能影响售后回复，一个流程节点拆分可能改变整体成本和延迟。

协作方式需要从“交付接口”变成“共同迭代数据、逻辑和提示词”。

几个机制很有必要：

测试角色也需要变化。重点不只是手工点页面，而是建设评测集、标注体系、自动化评测流水线，让每次迭代的影响可量化。

落地清单

电商 AI 客服从 0 到 1，可以按这条主线推进：

1. 用 Dify 这类平台快速搭建 MVP，先验证完整闭环。
2. 主链路优先选择 Workflow，让路径和结果可控。
3. 核心检索、实时查询、上下文组装逐步迁入工程化服务。
4. 模型按节点选型，意图识别和生成回复不一定使用同一个模型。
5. 商品知识、历史 QA、文档知识分开建设，并设计不同召回权重。
6. 动态信息通过接口实时查询，不要长期写入向量库。
7. 上下文结构化组装，明确知识优先级和冲突处理规则。
8. 建立评测集和线上 Badcase 闭环，模型、提示词、知识、流程一起迭代。
9. 高风险问题坚持保守策略：没有依据就澄清或转人工，不让模型猜。

AI 客服真正难的地方不在于接一个大模型接口，而在于把不确定的大模型能力放进可观测、可评测、可回滚的工程体系里。流程、知识、上下文和评测闭环搭好后，AI 承接率才有持续增长的基础。