零售企业 Agentic AI 落地手册（二）：知识库架构、模型选型与成本真相

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

Agentic AI 知识库 RAG 模型选型 AI成本

开篇：知识库是地基，大模型是工具

如果上一篇文章帮你看清了全景地图和方向，这篇要帮你解决三个最核心的技术架构问题：

知识库怎么建？ 这是 Agent 质量的上限——知识库的质量上限，就是 Agent 的能力上限
模型怎么选？ 国内模型、海外模型、混合方案，各自的真实差距在哪
到底要花多少钱？ 四块成本的量级，以及哪些变量是可控的

很多项目在这一步走错了——把"文档丢进向量数据库"误认为是"建知识库"。实际上，知识库建设是一个人力密集型的工作，技术只是工具。

给管理层的总结： 知识库决定 AI 的上限，大模型只是执行工具。建知识库的核心瓶颈不是技术，而是需要懂业务的人来主导内容质量。本文会告诉你：建什么、怎么建、选什么模型、花多少钱。

三层知识库架构：规则层 / 产品层 / 经验层

在动手之前，需要明确知识库不是一个单一的东西，而是三个层次的叠加，每层的精度要求、处理策略和建设方式完全不同：

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

为什么要分三层？

因为每层的出错代价不一样：

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

给管理层的总结： 知识库分三层，因为出错代价不同。第一层（政策规则）出错 = 客诉，所以必须 100% 准确，不让 AI 自由发挥。第二层（产品知识）影响体验。第三层（经验）决定 AI 能处理多少复杂问题。

从零建知识库：200 条到 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 个问法变体的覆盖

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

给管理层的总结： 知识库建设最大的投入不是技术，而是人。你需要安排一位懂业务的资深客服来主导内容质量，研发团队负责工具和流程。 200 条 Q&A 就可以开始内测，不需要等到"完美"才启动。

检索策略：为什么纯向量检索不够用

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

客户问"某品牌 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 编排平台内置知识库，原因是团队学习成本为零。当知识库内容稳定、对话上量后，迁移到云厂商托管搜索服务。迁移成本可控，不要为了"未来扩展"在第一步就把架构搞复杂。

给管理层的总结： "把文档丢进向量数据库"不等于"建好了知识库"。需要混合检索（关键词+语义+重排），而且第一阶段用现成工具就够了，不需要大投入。

模型选型：路线 A / B / C 的真实差距

模型选型是技术团队和管理层都关心的问题。先说结论：在零售客服场景，模型选型不是"用最好的"，而是"用最合适的"。

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

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

路线 A 和路线 B 的真实差距

路线 A 和路线 B 的能力差距不是抽象的，以下是在客服场景下会直接感受到的具体差异：

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

关键结论： 路线 B 的主要风险不在于能力弱，而在于幻觉率更高且不自知。简单查询国内模型完全够用。真正的风险在于异常场景——客户提出知识库里没有的问题时，国内模型更容易给出错误但听起来可信的答案。这是设计 Critic 检查层的核心原因。

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）：查询物流、订单状态          |
| - 重要原则：工具调用失败必须有明确的降级处理        |
+--------------------------------------------------+

为什么要这样分层？

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

给管理层的总结： 5 层架构的核心思想是"分层控制成本和风险"。简单问题不用大模型（省钱），关键输出有安全检查（防风险），复杂操作能调用后台系统（做实事）。

成本真相：四块成本的量级与控制手段

成本低估是 Agentic AI 项目失控的主要原因之一。以下逐一做量级估算，并说明哪些变量是可以控制的。

基准假设： 日均数千客服工单，其中 AI 处理 70%（约 3,500 条），转人工 30%（约 1,500 条）。

第一块：推理成本（最大变量，最需要架构设计）

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

成本项	估算依据	月估算费用
主力大模型（国内 72B 级别）	每工单约 4 次调用 x 平均 1500 tokens	约 800-1,000 元/月
Embedding 模型	每工单约 5 次检索 x 512 tokens	约 60-100 元/月（几乎可忽略）
Rerank 模型	每工单约 3 次检索 x 按次计费	约 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 兴趣的工程师转型。

第三块：基础设施成本

基础设施项	月估算费用	备注
向量数据库	第一阶段 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 万/年	不是主要成本，且随架构优化可进一步降低
新增人员	最大变量，取决于招聘/转岗方式	最容易被低估的一块，需要从项目启动就规划
基础设施	3-5 万/年	相对固定，可预测
系统集成	一次性投入 + 持续维护	工期风险最大，建议第一周就启动

给管理层的总结： AI 客服的推理成本（大模型调用费）其实很低——日均数千工单只需要约 2,000 元/月。真正的成本在于人（AI 运维工程师 + 知识库运营）和系统集成（工期风险）。总体算账：AI 处理 70% 工单的全部成本，大约是等量人工成本的 1/30 到 1/50。

下篇预告

知识库建好了，模型选好了，成本算清了——接下来最关键的问题是：上线之后怎么办？

第三篇：运维闭环、安全机制与 CEO 决策清单

现有 BOT 的失败是运维失败，不是技术失败
6 个核心 KPI + 日/周/月三级调优闭环
Critic 安全层伪代码详解：AI 的最后一道防线
减员评估的 5 个前置条件
系列总结：30 天行动计划