零售企业 Agentic AI 落地手册（二）：知识库决定上限，模型只是工具——客服 Agent 的真实成本拆解

Yaqin Hei·February 28, 2026·25分钟阅读

中文EN

零售企业 Agentic AI 落地手册（二）：知识库决定上限，模型只是工具——客服 Agent 的真实成本拆解

本系列《零售企业 Agentic AI 落地手册》第二篇——讲"把第一个客服 Agent 从 0 做到 1"的技术架构选型。 第一篇是 28 场景挑哪 4 个先做。English version: Retail Agentic AI Handbook (2): Knowledge Base Caps the Ceiling, the Model Is Just a Tool.

开篇：供应商演示完 demo 说"用最新大模型 + 向量数据库"——你应该问的下一个问题

某次供应商方案评审会，对方展示完一个客服 Agent demo——

"我们用最新大模型，配合行业领先的向量数据库，准确率 95%。"

CTO 在记录本上沉思——准确率 95% 是怎么算的？什么场景下测出来的？知识库里的 Q&A 是谁写的？同一道题换 5 种问法还是 95% 吗？产品编号查询和退货政策咨询是同一套准确率吗？

供应商没回答这些问题，但价格已经报到 200 万。

这一年我看到的客服 Agent 项目里，8 成的钱花错了地方——花在最贵的大模型（其实国内模型完全够），花在最酷的向量数据库（其实平台内置就够），花在最复杂的工程（其实知识库才是上限）。

真正决定 Agent 能不能上线的，是 3 个工程师不爱讨论但管理层必须问清楚的问题——

知识库怎么建？ 这是 Agent 质量的上限——文档质量直接决定 Agent 能力天花板
模型怎么选？ 国内、海外、混合方案，在客服场景里的真实差距是哪 4 个具体能力？
四块成本里钱花哪？ 推理只占 5%，人才是大头——大多数预算把比例搞反了

读完 5 分钟你能在下次架构评审会上判断供应商的方案是不是"文档丢进向量库"糊弄；20 分钟你能给老板交一份"知识库分三层 + 模型选 B 不选 A + 四块成本估算"的技术方案。

一、知识库不是一团文档，是三层完全不同的东西——出错代价决定怎么建

先把结论摆桌面上：知识库出错代价决定它该怎么建——不是一团文档全丢进去，是三层完全不同的东西，每层用不同的处理策略。

层级	内容范围	具体示例	处理策略
第一层（结构化规则）	退换货政策、品牌授权规则、物流时效承诺	"七天无理由退货适用条件"、各品牌退换货差异政策	准确率要求 100%，用硬规则判断不用大模型
第二层（产品知识）	商品属性、尺码指南、材质说明、适用场景	"某款跑鞋的鞋底材质、适合跑步类型、与同系列对比"	Agent 回答产品咨询的主要来源
第三层（经验沉淀）	高频问题的最优回答、边缘案例处理方式、投诉安抚话术	"客户情绪激动时的应对范式、物流超时的解释口径"	最难建但最有价值，来源于历史对话挖掘

为什么必须分三层——出错代价完全不同

第一层出错 = 直接客诉。 AI 把退货政策说错了（告诉客户"30天可退"实际只有 7 天），客户会投诉、要求品牌方介入。所以第一层必须用硬规则直接返回原文，不经过大模型生成——把规则交给 LLM"翻译"一遍，就是给自己埋雷
第二层出错 = 体验下降。 产品知识说错了（推荐了错误的尺码），客户可能退货，但不会上升到投诉
第三层没有 = 效果打折。 没有经验层，AI 遇到复杂情况只能转人工，首次解决率上不去

检测信号： 供应商方案里把所有文档"统一向量化"——直接 fail。这是 2026 年最常见的设计错误，第一层规则被 LLM 改写之后，客诉率反而比纯人工还高。

二、知识库不是"建完"才上线——分三阶段进化，200 → 800 → 2000

知识库没有"完成"这个状态，只有"当前质量分"。下面是分阶段的最低可用标准——

阶段	知识库规模	质量指标	验证方式
Alpha（内部测试）	200 条 Q&A，覆盖 TOP 50 高频问题	Top-5 召回率高于 60%	内部员工测试，发现知识盲区
Beta（小流量上线）	800 条 Q&A，覆盖主流程	Top-3 召回率高于 75%，答案准确率高于 80%	接入 10% 真实流量，人工兜底
生产（规模替代）	2000+ 条 Q&A，覆盖异常场景	Top-1 召回率高于 70%，首次解决率高于 65%	开始考虑减少人工客服比例

建设三步法

第一步：文档诊断（1 周）

收集所有现有客服相关文档：政策文件、品牌手册、培训材料、邮件通知
按三个层次分类，评估每份文档的时效性（过期政策比没有文档更危险）
识别"口头知识"——哪些重要规则只存在于老员工脑子里，没有书面记录

第二步：结构化改造（2-3 周）——这是最关键也最耗人力的步骤

将非结构化文档改写为问答对（Q&A）格式——这是提升检索准确率最有效的单一手段
每个 Q&A 包含：标准问题 + 标准答案 + 适用条件 + 来源/负责人 + 最后更新日期
政策类文档拆分到最小颗粒度——不要把整个退换货政策文档作为一个检索单元
使用客户的真实用语写问题，不是内部术语（客户说"换货"不说"商品调换申请"）

第三步：从历史对话挖掘（持续进行）

导出客服平台的历史对话数据，提取高频问题的实际问法变体
找出人工客服处理得好的案例，整理为标准话术
找出投诉升级的案例，分析触发原因，补充到边缘案例处理指南
目标：每个高频问题有 3-5 个问法变体的覆盖

关键提醒： 文档改造是人力密集型工作，不是技术问题。资深客服（不是研发）主导内容质量，研发负责格式和入库流程。这个人力配置如果在第一周没确认，知识库质量会成为整个项目最大瓶颈。

三、"把文档丢进向量数据库"是 3 个月白烧钱的开始

很多项目踩过的坑——把文档向量化就以为完成了知识库。实际上纯向量检索在零售客服场景有 3 个具体短板：

客户问"某品牌 Air Max 270 能退货吗"——语义检索容易找到 Air Max 系列的一般介绍，而不是退货政策
客户说产品编号"AT4525-100"——向量检索完全没有优势，关键词精确匹配才对
政策文档里的条件逻辑（"如果...则..."）在向量化后丢失结构信息

推荐的检索策略是混合检索（Hybrid Retrieval）——

检索类型	适用场景	技术实现
关键词检索（BM25）	精确产品编号、品牌名、政策关键词	AI 编排平台内置支持，云厂商托管搜索服务原生支持
向量检索（Semantic）	意图模糊的咨询，如"这双鞋跑步合适吗"	需要 Embedding 模型（如云厂商 text-embedding 服务）
混合重排（Rerank）	结合两种结果，选出最相关的 Top-K	推荐使用 Rerank 模型，AI 编排平台和云厂商托管搜索均支持

存储和检索技术选型建议——

方案	适用场景	推荐度
AI 编排平台内置知识库	快速验证期，团队已熟悉平台，文档量低于 5 万条	第一阶段首选
云厂商托管搜索服务	文档量大，需要混合检索（关键词+向量），生产级稳定性	生产阶段推荐
Elasticsearch + 向量插件	已有 ES 经验，需要复杂过滤条件（品牌/品类筛选）	有经验才考虑
专用向量数据库（Milvus 等）	超大规模向量检索，纯语义场景	暂不推荐

第一阶段（验证期）用 AI 编排平台内置知识库，原因是团队学习成本为零。知识库内容稳定、对话上量后再迁移到云厂商托管搜索服务——不要为了"未来扩展"在第一步就把架构搞复杂。

检测信号： 供应商一上来就推荐 Milvus / Pinecone 这种专用向量数据库——问他"我们日均工单量是数千条，需要这个规模吗？" 答不出来就是过度工程。

四、国内模型在简单查询和海外模型没差距——真正的差距在异常场景

模型选型一句话给完：简单查询国内模型完全够用，真正的风险点不在能力，在异常场景的幻觉率。

零售客服 AI 有三条技术路线——

路线 A（海外模型）： OpenAI / Anthropic 级别
路线 B（国内模型）： 通义、百川、GLM 级别
路线 C（混合方案）： 国内为主力 + 海外做能力基准

A 和 B 的真实差距——5 个具体能力

场景类型	路线 A（海外模型）	路线 B（国内模型）	差距分析
简单查询（政策查询、订单状态）	准确，格式好	准确，格式好	无明显差距——国内模型完全可胜任
多轮对话（需要记住上文）	上下文追踪稳定，指代消解准确	5 轮以内稳定，超过后容易丢失关键信息	长对话场景下需要额外的上下文管理逻辑
复杂投诉处理（情绪+逻辑双重挑战）	能识别情绪，调整语气，同步给出合理解决方案	逻辑处理可以，情绪识别和语气调节明显弱	投诉升级率可能因此上升
工具调用（查订单、触发退款）	多步工具调用可靠，失败时有合理的错误处理	单步可靠，多步串联时偶发中间结果丢失	需要额外的调用重试和结果验证逻辑
异常场景（问题不在知识库里）	能识别知识盲区，给出合理的不确定性表达	容易"自信地"给出错误答案（幻觉更多）	第一层（规则类）错误率上升，产生客诉风险

关键结论： 路线 B 的主要风险不在于能力弱，而在于幻觉率更高且不自知——客户提出知识库里没有的问题时，国内模型更容易给出错误但听起来可信的答案。这就是为什么需要 Critic 检查层（详见第三篇）——靠换更贵的模型解决不了这个问题。

五、客服 Agent 的 5 层架构——每一层都在分担成本和风险

把模型选型和知识库结合起来，完整的客服 Agent 系统架构是 5 层——

用户消息进入
    |
    v
+--------------------------------------------------+
| 层 1: 意图识别与路由（轻量模型）                    |
| - 使用国内小模型（7B 级别）或规则分类器             |
| - 分类维度：查询类 / 投诉类 / 操作类 / 超出范围    |
| - 避免每个请求都调用大模型，节省 30-50% 推理成本   |
+--------------------------------------------------+
    |
    v
+--------------------------------------------------+
| 层 2: 知识检索层（混合检索）                        |
| - BM25 关键词检索 + 向量检索 + Rerank 重排         |
| - 从知识库中检索 Top-K 相关文档，注入大模型上下文   |
| - Top-K 建议 3-5，过多会稀释相关度，过少会遗漏     |
| - 第一层（规则类）查询直接返回规则原文，不经过大模型 |
+--------------------------------------------------+
    |
    v
+--------------------------------------------------+
| 层 3: 生成层(按复杂度选模型)                        |
| - 简单查询/标准答案：国内主流大模型，成本低延迟低   |
| - 复杂投诉/多步操作：优先国内模型，质量不够时升级   |
| - 第一层规则查询不走生成——这是准确率的保证          |
+--------------------------------------------------+
    |
    v
+--------------------------------------------------+
| 层 4: Critic 检查层（规则引擎，不走大模型）         |
| - 在生成结果输出前做合规检查                        |
| - 必检项：无法兑现的承诺、具体金额赔偿、内部信息泄露 |
| - 触发转人工条件：情绪关键词、连续 3 轮未解决       |
| （详见本系列第三篇）                                |
+--------------------------------------------------+
    |
    v
+--------------------------------------------------+
| 层 5: 工具调用层（系统集成）                        |
| - 企业微信 API：接收消息、发送回复、获取客户信息    |
| - 工单系统 API：创建工单、更新状态、查询历史        |
| - 订单系统(如有 API)：查询物流、订单状态           |
| - 重要原则：工具调用失败必须有明确的降级处理        |
+--------------------------------------------------+

5 层分工的核心思想是"分层控制成本和风险"——

层 1 价值： 大约 20-30% 的请求是简单政策查询，不需要调用大模型。路由层用小模型或规则就能判断，省掉这部分大模型推理成本
层 2 价值： 混合检索比纯向量检索的准确率高 15-20%。尤其是产品编号、政策关键词这类精确查询
层 3 价值： 按需选模型而不是一刀切。简单问题用便宜的模型，复杂问题用更强的模型
层 4 价值： 这是安全兜底。无论大模型多强都可能生成不该说的内容，Critic 层是硬编码规则，不依赖大模型判断（详见第三篇）
层 5 价值： Agent 不只是"聊天"——还能查订单、创工单、触发退款流程

检测信号： 供应商的方案里没有层 4（Critic）——直接 fail。这意味着大模型生成什么就发什么，等于"给客户一个能自信编造退款承诺的客服"。

六、四块成本里推理只占 5%——人才是大头

成本低估是 Agentic AI 项目失控的主要原因之一。基准假设：日均数千客服工单，AI 处理 70%（约 3,500 条），转人工 30%（约 1,500 条）。

第一块：推理成本——架构设计直接决定

推理成本是运营成本中最难预测、最容易失控的一块，与架构设计直接相关——

成本项	估算依据	月估算费用
主力大模型（国内 72B 级别）	每工单约 4 次调用 × 平均 1500 tokens	约 800-1,000 元/月
Embedding 模型	每工单约 5 次检索 × 512 tokens	约 60-100 元/月（几乎可忽略）
Rerank 模型	每工单约 3 次检索 × 按次计费	约 500-700 元/月
客服平台 API	取决于现有合同或套餐	需单独确认，建议纳入年度谈判
合计（路线 B 主力）	—	约 1,500-2,000 元/月（约 1.5-2 万/年）

可控变量（架构优化手段）——

每个工单的大模型调用次数（从 4 次降到 3 次，成本直降 25%）
上下文长度（精简 System Prompt，每次节省 200 tokens）
意图识别用小模型（7B 而不是 72B）——路由层成本降低 90%
第一层规则类查询不走大模型——约 20% 工单可直接返回，节省对应推理成本

对比参照： 日均数千工单、月成本 1,500-2,000 元——这大约是 1-2 名客服月薪的水平。但这是 AI 处理 70% 工单的成本，对等的人工成本是这个数字的 30-50 倍。推理成本不是项目的主要成本压力，新增人员成本才是。

第二块：新增人员成本——最容易被低估的一块

减少客服人员会带来新增的技术人员需求。这两个数字不能只看"减少多少"，必须同时看"增加多少"——

新增角色	核心职责	招聘/转岗方式	备注
AI 运维工程师（必须）	监控 Agent 表现，分析错误日志，调整 Prompt，处理异常场景	要求 LLM 经验	市场稀缺，不能用普通运维替代
知识库内容运营（必须）	维护知识库更新，处理"知识盲区"工单，协调业务方更新政策	可内部转岗	必须同时懂业务和 AI，建议从资深客服转岗
规则库维护（兼职，可转岗）	Critic 规则更新，新投诉类型的规则补充，合规检查	可由 AI 运维工程师兼任	规则逻辑必须由懂业务的人写，不能纯靠研发
数据标注（早期集中投入）	对话数据标注，用于微调和评估，知识库 Q&A 质量审核	可外包	早期需要集中投入，后期可降至兼职

最难招的是 AI 运维工程师——这个角色不是普通后端工程师，他需要理解 Prompt Engineering、会分析 LLM 调用链路、能从对话日志中定位问题根因。建议优先考虑团队内部有 LLM 兴趣的工程师转型，市场上抢人会推到月薪 5 万以上。

第三块：基础设施成本——相对固定，可预测

基础设施项	月估算费用	备注
向量数据库	第一阶段 0（用平台内置），第二阶段 800-1,500 元起	按存储量和请求量计费
AI 编排平台运行	约 1,200-1,800 元/月（云服务器，主备各一台）	如已有部署可复用
对话日志存储	约 100-300 元/月（对象存储）	需保留至少 6 个月用于审计
监控与告警	约 200-500 元/月	必须有，是运维闭环的基础设施
合计	约 2,300-4,100 元/月（约 2.8-5 万/年）	不含平台硬件如已有

第四块：系统集成成本——最容易被严重低估，工期最容易拖

集成成本是整个项目中最容易被低估的，也是工期拖延最常见的来源。每个系统对接都是独立工程任务，而且会随着上游系统升级持续产生维护需求——

集成目标	预计工期	技术难度	注意事项
企业微信客服 API	1-2 周	低（接口稳定）	消息格式限制多，富文本支持有限
客服平台对话数据导出	3-5 天	低（数据导出任务）	数据格式可能需要清洗，历史数据量大时 IO 耗时
工单系统 API	2-3 周	中（依赖供应商）	供应商 API 文档可能不完整，测试环境获取困难
订单/物流系统查询	3-4 周	高（业务系统敏感）	这是最复杂的集成，需要 IT 部门深度配合，权限审批周长
知识库更新自动化	2 周	中	需要定义触发机制：谁更新、何时同步、如何验证

经验： 订单/物流系统集成是最可能成为关键路径阻塞点的任务——项目第一周就启动与 IT 沟通，不要等到知识库建完再去谈。

成本全景——把比例摆桌面上

成本类别	年度量级	占比	管理层关注点
推理成本	1.5-2 万/年	约 5%	不是主要成本，且随架构优化可进一步降低
新增人员	50-150 万/年	约 70%	最大的、最容易被低估的一块
基础设施	3-5 万/年	约 10%	相对固定，可预测
系统集成	一次性投入 30-80 万	约 15%	工期风险最大，建议第一周就启动