电商客服智能体的构建远不止于简单调用大模型API。当面对商品参数、退换货政策、订单状态等具体问题时，RAG架构如何通过知识库检索、精准Prompt设计和混合检索策略，实现回答的准确性与可控性？本文从零开始拆解电商客服RAG系统的完整搭建过程，涵盖知识库建设、检索优化到成本控制的全链路实战经验。
当接到一个需求：搭建电商客服智能体，要求能准确回答商品咨询、订单查询、售后政策等问题。技术方案评审时，算法同学提出用RAG(检索增强生成)架构。作为AI产品经理，我需要理解RAG的原理，更要把它转化为可落地的产品方案。
这篇文章记录了我从技术小白到主导RAG搭建的完整过程，希望能帮助同样在做AI产品的朋友。
最初我也疑惑：直接用ChatGPT API不就行了吗，为什么要搞个RAG？后来在实际测试中发现了问题：
测试场景1：商品参数咨询
测试场景2：退换货政策
测试场景3：订单状态查询
这些痛点让我明白：大模型虽然强大，但它不知道我们平台的具体信息、实时数据和业务规则。
RAG的核心思想很简单：在让大模型回答之前，先从我们自己的知识库里检索相关信息，把这些信息塞给大模型，让它基于真实数据生成回答。
用一个比喻：大模型像一个博学的老师，但它不了解你们学校的具体情况。RAG就是给老师配一个助手，先帮他查阅学校的规章制度、学生档案，然后老师再基于这些材料给出建议。
RAG带来的直接价值：
我画了一张流程图，让团队所有人都能理解RAG的工作原理：
用户提问
↓
意图识别(判断问题类型)
↓
问题改写(优化为检索友好的形式)
↓
向量检索(从知识库找相关内容)
↓
相关性过滤(只保留高相关的结果)
↓
上下文构建(组装prompt)
↓
大模型生成(基于检索结果回答)
↓
答案后处理(格式化、添加来源)
↓
返回用户
作为产品经理，我需要把这个流程转化为具体的功能模块：
模块1：知识库管理系统
模块2：向量化引擎
模块3：检索模块
模块4：生成模块
模块5：业务对接层
第一步是盘点我们有哪些知识来源。我做了一个清单：
结构化数据：
非结构化文档：
实时业务数据：
这是最耗时的环节，也是最容易出问题的地方。我总结了几个关键决策：
决策1：分块粒度
一开始我让技术同学按512个token切分，结果检索效果很差。比如用户问”退货流程”，检索到的片段只有”请在7天内提交申请”，缺少前后文。
后来调整策略：
决策2：元数据设计
每个知识片段不仅要存文本内容，还要存元数据，方便后续过滤和溯源：
{
“content”： “平台支持7天无理由退货，商家承担退货运费…”，
“metadata”： {
“doc_type”： “policy”，
“category”： “退换货”，
“update_time”： “2025-01-15″，
“source”： “平台规则v3.2″，
“version”： “3.2”，
“applicable_scope”： “全平台”
}
}
决策3：数据清洗规则
原始文档质量参差不齐，必须清洗：
我设计了一个分层的知识库架构：
第一层：静态知识库
第二层：准实时知识库
第三层：实时数据接口
这样设计的好处是：既保证了检索性能(静态数据提前向量化)，又保证了信息时效性(关键数据实时查询)。
这是我遇到的第一个技术决策。市面上Embedding模型很多，怎么选？
我的方法是：建立测试集，实际对比效果。
测试集构建：
对比结果：
最终选择：BGE-large-zh。虽然效果略逊OpenAI，但成本可控，且74%的准确率已经满足业务需求。
单纯的向量检索有个问题：对于一些特定术语(比如”SKU12345″、”顺丰快递”)，向量检索效果不如关键词检索。
我设计了一个混合检索策略：
Step1：向量检索
Step2：关键词检索
Step3：结果融合
经过测试，混合检索的准确率从74%提升到82%。
用户的问法千奇百怪，直接用原始问题检索效果不好。我加了一个查询改写环节：
场景1：口语化问题
场景2：多意图问题
场景3：省略主语
改写的实现方式：我让大模型做这个工作，成本很低，效果很好。Prompt示例：
你是一个查询优化助手。将用户的口语化问题改写为更适合检索的形式。
要求：
1. 补全省略的主语
2. 将口语化表达转为规范术语
3. 如果包含多个问题，拆分成列表
用户问题：{user_query}
改写结果：
检索召回的top-5不一定是最相关的。我加了一个重排序模块：
方法1：交叉编码器
方法2：规则加权
重排序后，最终给大模型的top-3相关性从82%提升到89%。
这是产品经理最能发挥作用的环节。好的Prompt设计直接决定了回答质量。
我的Prompt模板：
# 角色定义
你是一个专业的电商客服助手，负责回答用户关于商品、订单、售后的问题。
# 回答要求
1. 基于提供的参考信息回答，不要编造
2. 如果参考信息不足以回答问题，诚实告知并建议转人工
3. 语言简洁友好，避免专业术语
4. 涉及金额、日期的信息必须准确
5. 敏感问题(投诉、退款)引导转人工客服
# 参考信息
{retrieved_context}
# 对话历史
{chat_history}
# 用户问题
{user_query}
# 你的回答
检索到的5个文档如何组装给大模型？我测试了几种方案：
方案A：直接拼接
文档1内容…
文档2内容…
…
问题：大模型容易被第一个文档影响，忽略后面的信息。
方案B：带序号和来源
[参考1
– 来源：退换货政策v3.2]
内容…
[参考2
– 来源：常见问题FAQ]
内容…
效果好很多，大模型会综合多个来源。
方案C：带相关度分数
[参考1
– 相关度：95%
– 来源：退换货政策v3.2]
内容…
最优方案，大模型会优先参考高相关度的内容。
为了让用户信任答案，也方便我们后续审核，每个回答都要标注来源：
用户视角：
根据平台规则，支持7天无理由退货，商家承担运费。
参考来源：
• 退换货政策 v3.2
• 更新时间：2025-01-15
运营后台视角：
{
“answer”： “支持7天无理由退货…”，
“sources”： [
{
“doc_id”： “policy_001″，
“chunk_id”： “chunk_23″，
“relevance_score”： 0.95，
“content”： “平台支持7天无理由退货…”
}
]
}
这样运营同学可以快速定位答案是基于哪条知识生成的，如果答案有问题，直接去修改对应的知识库。
我建立了三层评估指标：
L1：检索质量
L2：生成质量
L3：业务效果
每天晚上，系统会自动收集Bad Case：
第二天早上，我会花30分钟分析：
分析维度：
案例：某次Bad Case分析
新优化方案上线前，我一定会做A/B测试：
测试案例：重排序模块效果验证
结果：B组满意度提升8%，自动解决率提升12%，决定全量上线。
上线第一个月，成本超预算30%。我做了详细分析：
成本构成：
大头是大模型调用。每次对话平均调用2次API(第一次查询改写，第二次生成答案)，每次平均消耗2000 tokens。
优化1：模型降级策略
优化2：缓存机制
优化3：上下文裁剪
优化4：流式输出
经过优化，单次对话成本从0.15元降到0.06元，降幅60%。
坑1：过度依赖向量检索 一开始我以为向量检索是万能的，结果发现对订单号、SKU这种精确匹配需求效果很差。教训：混合检索必不可少。
坑2：忽视知识时效性 有次促销政策改了，但知识库没同步更新，导致回答错误，引发投诉。教训：建立知识库与业务系统的自动同步机制。
坑3：Prompt设计不够健壮 大模型有时会”发挥创造力”，编造一些听起来合理但实际不存在的政策。教训：在Prompt中反复强调”只基于参考信息回答，不要编造”。
坑4：没有设置降级方案 有次向量数据库故障，整个客服智能体瘫痪。教训：设计降级方案，数据库故障时回退到规则引擎。
经验1：小步快跑 不要追求一次做到完美。我们MVP版本只覆盖了20%的高频场景，但快速上线后根据数据迭代，3个月覆盖率达到70%。
经验2：重视运营端设计 一开始只关注用户侧体验，后来发现客服主管们根本不会用后台。重新设计了运营端，让非技术人员也能轻松更新知识库。
经验3：建立人机协同 RAG不是要替代人工，而是人机协同。复杂问题交给人工，简单问题交给AI，转接要流畅无感。
经验4：数据飞轮 用户对话是宝贵的数据。我们把高质量对话加入训练集，用来优化检索模型和生成效果，形成正向循环。
作为产品经理，我们不需要会写代码，但必须理解：
只有理解技术，才能做出合理的需求决策和优先级排序。
技术同学容易陷入技术细节，我们要拉回到用户视角：
永远把用户体验放在第一位。
没有度量就无法优化。从项目第一天就要定义：
数据驱动决策，而不是拍脑袋。
AI技术变化太快了。两年前RAG还是学术概念，现在已经是行业标配。我们要保持学习：
搭建RAG系统是个系统工程，涉及知识工程、算法优化、工程实现、产品设计、运营机制等多个环节。作为AI产品经理，我们的价值在于把这些环节串联起来，确保技术真正服务于业务。
这篇文章记录了我两年来在RAG项目上的实践和思考。技术还在快速演进，方法论也会不断更新，但核心思路不变：理解用户需求，善用技术手段，用数据驱动优化，持续创造价值。
希望这些经验能帮助正在做或即将做AI产品的朋友少踩坑，多成长。
本文由 @洋洋 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。