电商客服智能体的构建远不止于简单调用大模型API。当面对商品参数、退换货政策、订单状态等具体问题时，RAG架构如何通过知识库检索、精准Prompt设计和混合检索策略，实现回答的准确性与可控性？本文从零开始拆解电商客服RAG系统的完整搭建过程，涵盖知识库建设、检索优化到成本控制的全链路实战经验。
当接到一个需求：搭建电商客服智能体，要求能准确回答商品咨询、订单查询、售后政策等问题。技术方案评审时，算法同学提出用RAG(检索增强生成)架构。作为AI产品经理，我需要理解RAG的原理，更要把它转化为可落地的产品方案。
这篇文章记录了我从技术小白到主导RAG搭建的完整过程，希望能帮助同样在做AI产品的朋友。
一、为什么电商客服需要RAG？
1.1 先理解问题本质
最初我也疑惑：直接用ChatGPT API不就行了吗，为什么要搞个RAG？后来在实际测试中发现了问题：
测试场景1：商品参数咨询
- 用户问：“这款手机支持5G吗？”
- GPT-4直接回答：“根据一般情况，2023年后的中高端手机通常支持5G”
- 问题：回答模棱两可，没有给出具体商品的准确信息
测试场景2：退换货政策
- 用户问：“7天无理由退货包括运费吗？”
- GPT-4回答：“一般来说，7天无理由退货需要买家承担运费…”
- 问题：我们平台的政策是商家承担运费，回答与实际不符
测试场景3：订单状态查询
- 用户问：“我的订单什么时候发货？”
- GPT-4回答：“我无法查询您的具体订单信息”
- 问题：无法访问实时业务数据
这些痛点让我明白：
大模型虽然强大，但它不知道我们平台的具体信息、实时数据和业务规则。
1.2 RAG解决了什么问题
RAG的核心思想很简单：在让大模型回答之前，先从我们自己的知识库里检索相关信息，把这些信息塞给大模型，让它基于真实数据生成回答。
用一个比喻：大模型像一个博学的老师，但它不了解你们学校的具体情况。RAG就是给老师配一个助手，先帮他查阅学校的规章制度、学生档案，然后老师再基于这些材料给出建议。
RAG带来的直接价值：
- 回答准确性：基于真实数据，不会胡编乱造
- 可控性：知识库由我们维护，可以随时更新
- 可追溯：每个回答都能找到来源，方便审核优化
- 成本可控：不需要对大模型进行昂贵的微调
二、RAG系统架构设计
2.1 整体流程梳理
我画了一张流程图，让团队所有人都能理解RAG的工作原理：
用户提问
↓
意图识别(判断问题类型)
↓
问题改写(优化为检索友好的形式)
↓
向量检索(从知识库找相关内容)
↓
相关性过滤(只保留高相关的结果)
↓
上下文构建(组装prompt)
↓
大模型生成(基于检索结果回答)
↓
答案后处理(格式化、添加来源)
↓
返回用户
2.2 核心模块拆解
作为产品经理，我需要把这个流程转化为具体的功能模块：
模块1：知识库管理系统
- 文档上传与解析
- 知识分类与标签
- 版本控制与更新
- 权限管理
模块2：向量化引擎
- 文本分块策略
- Embedding模型选择
- 向量存储与索引
- 检索性能优化
模块3：检索模块
- 混合检索(向量+关键词)
- 重排序算法
- 结果去重与融合
模块4：生成模块
- Prompt工程
- 大模型接口封装
- 流式输出控制
- 答案质量监控
模块5：业务对接层
三、知识库建设：RAG的基础工程
3.1 知识来源梳理
第一步是盘点我们有哪些知识来源。我做了一个清单：
结构化数据：
- 商品信息库(50万SKU)
- 订单数据库(实时)
- 用户信息库(脱敏后)
- 物流状态表(实时)
非结构化文档：
- 平台规则文档(PDF，200+页)
- 商品使用手册(1000+份)
- FAQ文档(800+条)
- 客服话术库(300+条)
- 历史客服对话记录(100万+条)
实时业务数据：
3.2 文档处理策略
这是最耗时的环节，也是最容易出问题的地方。我总结了几个关键决策：
决策1：分块粒度
一开始我让技术同学按512个token切分，结果检索效果很差。比如用户问”退货流程”，检索到的片段只有”请在7天内提交申请”，缺少前后文。
后来调整策略：
- 短文档(FAQ)：不切分，整条存储
- 中文档(政策说明)：按段落切分，保留标题上下文
- 长文档(使用手册)：按章节切分，每块600-800 tokens，重叠100 tokens
决策2：元数据设计
每个知识片段不仅要存文本内容，还要存元数据，方便后续过滤和溯源：
{
“content”： “平台支持7天无理由退货，商家承担退货运费…”，
“metadata”： {
“doc_type”： “policy”，
“category”： “退换货”，
“update_time”： “2025-01-15″，
“source”： “平台规则v3.2″，
“version”： “3.2”，
“applicable_scope”： “全平台”
}
}
决策3：数据清洗规则
原始文档质量参差不齐，必须清洗：
- 去除无意义的格式符号
- 统一专业术语(比如“退货”vs“退款”vs“退换货”)
- 补充缺失的上下文(比如FAQ的问题作为答案的前缀)
- 过滤过时信息(基于版本号和时间)
3.3 知识库架构设计
我设计了一个分层的知识库架构：
第一层：静态知识库
- 存储：向量数据库(我们用的Milvus)
- 内容：平台规则、商品知识、FAQ
- 更新频率：周更新
- 检索方式：向量检索
第二层：准实时知识库
- 存储：ElasticSearch
- 内容：促销活动、库存状态、热点问题
- 更新频率：小时级
- 检索方式：关键词+向量混合
第三层：实时数据接口
- 存储：直接调用业务系统API
- 内容：订单状态、物流信息、用户信息
- 更新频率：实时
- 检索方式：API调用
这样设计的好处是：既保证了检索性能(静态数据提前向量化)，又保证了信息时效性(关键数据实时查询)。
四、检索策略优化：提升准召率的关键
4.1 Embedding模型选择
这是我遇到的第一个技术决策。市面上Embedding模型很多，怎么选？
我的方法是：建立测试集，实际对比效果。
测试集构建：
- 从历史客服对话中抽取500个真实问题
- 人工标注每个问题的标准答案应该来自哪个知识文档
- 用不同模型检索，对比top-5准确率
对比结果：
- OpenAI text-embedding-3-large：准确率78%，成本高
- BGE-large-zh：准确率74%，开源免费
- M3E-base：准确率68%，速度快
最终选择：BGE-large-zh。虽然效果略逊OpenAI，但成本可控，且74%的准确率已经满足业务需求。
4.2 混合检索策略
单纯的向量检索有个问题：对于一些特定术语(比如”SKU12345″、”顺丰快递”)，向量检索效果不如关键词检索。
我设计了一个混合检索策略：
Step1：向量检索
Step2：关键词检索
- 提取用户问题中的实体(商品名、订单号、快递公司)
- 在知识库中精确匹配
- 召回top-10文档
Step3：结果融合
- 用RRF(Reciprocal Rank Fusion)算法融合两路结果
- 最终返回top-5给大模型
经过测试，混合检索的准确率从74%提升到82%。
4.3 查询改写(Query Rewrite)
用户的问法千奇百怪，直接用原始问题检索效果不好。我加了一个查询改写环节：
场景1：口语化问题
- 原始：“这个啥时候能到啊？”
- 改写：“订单预计送达时间”
场景2：多意图问题
- 原始：“这个手机怎么样，能退货吗？”
- 拆分：[“手机评价”， “退货政策”]
场景3：省略主语
- 原始：“能换颜色吗？”(上文提到了某商品)
- 补全：“[商品名]是否支持换颜色”
改写的实现方式：我让大模型做这个工作，成本很低，效果很好。Prompt示例：
你是一个查询优化助手。将用户的口语化问题改写为更适合检索的形式。
要求：
1. 补全省略的主语
2. 将口语化表达转为规范术语
3. 如果包含多个问题，拆分成列表
用户问题：{user_query}
改写结果：
4.4 重排序(Rerank)
检索召回的top-5不一定是最相关的。我加了一个重排序模块：
方法1：交叉编码器
- 用专门的Rerank模型(BGE-reranker)
- 对每个候选文档和问题计算相关性分数
- 重新排序
方法2：规则加权
- 新版本文档权重+10%
- 被用户点赞的知识片段权重+20%
- 近期高频命中的知识片段权重+15%
重排序后，最终给大模型的top-3相关性从82%提升到89%。
五、Prompt工程：让大模型按我们的意图工作
5.1 Prompt框架设计
这是产品经理最能发挥作用的环节。好的Prompt设计直接决定了回答质量。
我的Prompt模板：
# 角色定义
你是一个专业的电商客服助手，负责回答用户关于商品、订单、售后的问题。
# 回答要求
1. 基于提供的参考信息回答，不要编造
2. 如果参考信息不足以回答问题，诚实告知并建议转人工
3. 语言简洁友好，避免专业术语
4. 涉及金额、日期的信息必须准确
5. 敏感问题(投诉、退款)引导转人工客服
# 参考信息
{retrieved_context}
# 对话历史
{chat_history}
# 用户问题
{user_query}
# 你的回答
5.2 上下文组装策略
检索到的5个文档如何组装给大模型？我测试了几种方案：
方案A：直接拼接
文档1内容…
文档2内容…
…
问题：大模型容易被第一个文档影响，忽略后面的信息。
方案B：带序号和来源
[参考1
– 来源：退换货政策v3.2]
内容…
[参考2
– 来源：常见问题FAQ]
内容…
效果好很多，大模型会综合多个来源。
方案C：带相关度分数
[参考1
– 相关度：95%
– 来源：退换货政策v3.2]
内容…
最优方案，大模型会优先参考高相关度的内容。
5.3 答案引用与溯源
为了让用户信任答案，也方便我们后续审核，每个回答都要标注来源：
用户视角：
根据平台规则，支持7天无理由退货，商家承担运费。
参考来源：
• 退换货政策 v3.2
• 更新时间：2025-01-15
运营后台视角：
{
“answer”： “支持7天无理由退货…”，
“sources”： [
{
“doc_id”： “policy_001″，
“chunk_id”： “chunk_23″，
“relevance_score”： 0.95，
“content”： “平台支持7天无理由退货…”
}
]
}
这样运营同学可以快速定位答案是基于哪条知识生成的，如果答案有问题，直接去修改对应的知识库。
六、评估与优化：建立持续改进机制
6.1 评估指标体系
我建立了三层评估指标：
L1：检索质量
- Top-1准确率：首个检索结果包含答案的比例
- Top-5准确率：前5个结果中包含答案的比例
- MRR(Mean Reciprocal Rank)：平均倒数排名
L2：生成质量
- 答案准确率：人工抽检100条，判断对错
- 幻觉率：生成的内容在检索结果中找不到支撑
- 拒识率：该回答但说“不知道”的比例
L3：业务效果
- 自动解决率：无需转人工的对话占比
- 用户满意度：每次对话后的星级评价
- 平均响应时长：从提问到回答的时间
6.2 Bad Case分析流程
每天晚上，系统会自动收集Bad Case：
- 用户评价1-2星的对话
- 3轮内转人工的对话
- 检索相关度<0.6的问题
- 生成时间>10秒的请求
第二天早上，我会花30分钟分析：
分析维度：
- 是知识库缺失？(补充知识)
- 是检索不准？(优化召回策略)
- 是生成质量差？(调整Prompt)
- 是理解错误？(改进意图识别)
案例：某次Bad Case分析
- 问题：“这个能用花呗吗？”
- 系统回答：“抱歉，我不清楚”
- 分析：知识库里有支付方式说明，但用“花呗”这个口语化表达检索不到
- 优化：在知识库中补充同义词映射，将“花呗”、“蚂蚁花呗”、“分期付款”关联
6.3 A/B测试框架
新优化方案上线前，我一定会做A/B测试：
测试案例：重排序模块效果验证
- A组：不使用重排序，检索top-5直接给大模型
- B组：使用BGE-reranker重排序
- 流量分配：50% vs 50%
- 测试时长：3天
- 评估指标：用户满意度、自动解决率
结果：B组满意度提升8%，自动解决率提升12%，决定全量上线。
七、成本优化：让RAG跑得起来
7.1 成本结构分析
上线第一个月，成本超预算30%。我做了详细分析：
成本构成：
- Embedding成本：20%(用的开源模型，主要是GPU算力)
- 向量数据库：15%(Milvus集群)
- 大模型调用：60%(GPT-4 API)
- 其他(带宽、存储)：5%
大头是大模型调用。每次对话平均调用2次API(第一次查询改写，第二次生成答案)，每次平均消耗2000 tokens。
7.2 优化措施
优化1：模型降级策略
- 简单问题(FAQ类)：用GPT-3.5，成本降低90%
- 复杂问题(需要推理)：才用GPT-4
- 判断逻辑：检索到的知识相关度>0.9，降级到3.5
优化2：缓存机制
- 相同问题24小时内命中缓存，不重复调用API
- 高频问题预生成答案
优化3：上下文裁剪
- 原来把top-5全部塞给大模型，平均1500 tokens
- 优化后：top-3即可，且对检索内容做摘要，平均800 tokens
优化4：流式输出
- 采用流式返回，用户体验更好
- 提前终止：如果生成100个token后发现偏题，直接中断
经过优化，单次对话成本从0.15元降到0.06元，降幅60%。
八、上线后的经验教训
8.1 踩过的坑
坑1：过度依赖向量检索 一开始我以为向量检索是万能的，结果发现对订单号、SKU这种精确匹配需求效果很差。教训：混合检索必不可少。
坑2：忽视知识时效性 有次促销政策改了，但知识库没同步更新，导致回答错误，引发投诉。教训：建立知识库与业务系统的自动同步机制。
坑3：Prompt设计不够健壮 大模型有时会&#8221;发挥创造力&#8221;，编造一些听起来合理但实际不存在的政策。教训：在Prompt中反复强调&#8221;只基于参考信息回答，不要编造&#8221;。
坑4：没有设置降级方案 有次向量数据库故障，整个客服智能体瘫痪。教训：设计降级方案，数据库故障时回退到规则引擎。
8.2 成功经验
经验1：小步快跑 不要追求一次做到完美。我们MVP版本只覆盖了20%的高频场景，但快速上线后根据数据迭代，3个月覆盖率达到70%。
经验2：重视运营端设计 一开始只关注用户侧体验，后来发现客服主管们根本不会用后台。重新设计了运营端，让非技术人员也能轻松更新知识库。
经验3：建立人机协同 RAG不是要替代人工，而是人机协同。复杂问题交给人工，简单问题交给AI，转接要流畅无感。
经验4：数据飞轮 用户对话是宝贵的数据。我们把高质量对话加入训练集，用来优化检索模型和生成效果，形成正向循环。
九、给AI产品经理的建议
9.1 技术理解的边界
作为产品经理，我们不需要会写代码，但必须理解：
- RAG的基本原理
- 各个模块的作用和局限性
- 关键参数对效果的影响(比如top-k、相似度阈值)
- 成本构成和优化空间
只有理解技术，才能做出合理的需求决策和优先级排序。
9.2 从用户视角出发
技术同学容易陷入技术细节，我们要拉回到用户视角：
- 用户不关心你用的什么模型，只关心答案准不准
- 用户不在乎你的架构多优雅，只在乎响应快不快
- 用户不理解什么是RAG，只想问题能被解决
永远把用户体验放在第一位。
9.3 建立度量体系
没有度量就无法优化。从项目第一天就要定义：
- 成功的标准是什么(自动解决率？满意度？)
- 如何评估每次优化的效果
- 哪些数据需要持续监控
数据驱动决策，而不是拍脑袋。
9.4 保持学习迭代
AI技术变化太快了。两年前RAG还是学术概念，现在已经是行业标配。我们要保持学习：
- 关注最新的论文和技术进展
- 参加行业交流，了解最佳实践
- 在项目中不断试错和迭代
写在最后
搭建RAG系统是个系统工程，涉及知识工程、算法优化、工程实现、产品设计、运营机制等多个环节。作为AI产品经理，我们的价值在于把这些环节串联起来，确保技术真正服务于业务。
这篇文章记录了我两年来在RAG项目上的实践和思考。技术还在快速演进，方法论也会不断更新，但核心思路不变：理解用户需求，善用技术手段，用数据驱动优化，持续创造价值。
希望这些经验能帮助正在做或即将做AI产品的朋友少踩坑，多成长。
本文由 @洋洋 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
发表于 2026-1-26 23:58:54