企业官网建设流程全解析

本系列为《RAG 做智能客服》第 1 篇
前置条件：了解大模型基础概念（ChatGPT、通义千问等）

一、引言

过去两年，几乎每家做客服的公司都试过把大模型塞进自己的产品里。结果呢？上线前信心满满，上线后"智障"频出。

你肯定见过类似这样的对话：

用户：我上个月买的 iPhone 15 还没收到，能帮我查一下吗？

AI 客服：您好！根据您提供的信息，您的订单预计 3-5 个工作日内送达。如有疑问请联系我。（实际上用户已经收到货了，AI 凭"概率"瞎编了一个时间）

用户：你们的电池保修期是多久？

AI 客服：12 个月，行业标准。（其实这家公司提供 24 个月保修，AI 把行业最常见的标准当成了自己公司的政策——客户差点错失整整 1 年延保）

用户一看："这 AI 不靠谱。"然后直接转人工，客服坐席每天照样被淹没在重复问题里。

大模型本身并不"弱"——它能写诗、能写代码、能聊人生，但它天生不适合做智能客服。为什么会这样？这就是我们这一篇要讲清楚的事。

二、客服场景下大模型的"五大原罪"

大模型在客服场景翻车，表面看是"答错了"，往深挖其实是五个互相纠缠的结构性问题。

2.1 幻觉：一本正经地胡说八道

幻觉（Hallucination）是大模型最知名的缺陷，也是客服场景最致命的。

模型生成答案的原理，是基于训练数据中学到的统计模式去"续写"下一个 token。它不具备事实核查能力，也不知道"我不知道"该怎么回答。

客服场景中的典型幻觉：

📊数据：根据 Vectara 2024 年发布的幻觉率排行榜，主流商用大模型的"捏造事实"幻觉率仍处于0.7%–4.5%之间。听起来不高，但客服每天处理上百万次咨询，0.7% 就是 7000 次错误回答——足以毁掉品牌信任。

2.2 知识滞后：训练完就"定型"

大模型的知识截止于训练数据采集的那一刻。GPT-4o 的知识截止 2023 年 10 月，Claude 3.5 是 2024 年 4 月——但你的退货政策可能上周刚改过。

更麻烦的是，重新训练一个模型的成本极高：

• 一次完整预训练：数百万到数千万美元（数据 + 算力 + 人力）
• 训练周期：数周到数月
• 重新上线还要做对齐、安全、评测

而客服知识库几乎每天都在变：新品上架、政策调整、活动规则更新、bug 修复……你不可能为了改一行文档就重训一次模型。

2.3 无法溯源：用户最怕"嘴上说"

医疗、金融、法律这些领域，要求 AI 回答必须有据可查。用户问：“这个结论从哪来的？” AI 答不上来，没人敢信。

但大模型生成答案的过程是黑盒——它吐出的每个字都是概率采样，不是从某段原文"摘抄"出来的。即便你问"你是怎么得出这个结论的？"，它也只能编一个"听起来合理"的理由。

⚠️注意：让大模型"在回答中给出引用"很容易，但引用的内容是不是真的支持它的结论，是另一回事。这一点我们后面讲"引用溯源"时会专门拆解。

2.4 私有知识缺失：通用模型的"知识盲区"

大模型的训练数据来自公网，它知道 Wikipedia、知道新闻、知道 GitHub 上的开源项目，但它不知道你公司的内部文档：

• 你们公司的差旅报销标准
• 你们银行最新发行的某款理财产品
• 你们医院某位医生的出诊时间
• 你们电商平台的双 11 活动细则

这些是企业的核心资产，也是客服每天被问 90% 的内容。

为什么不能把这些塞进训练数据？三个理由：

1. 成本：每次更新都要重训一次
2. 数据安全：核心知识不能出企业内网
3. 规模：大模型上下文窗口（目前最长也就 200K tokens）放不下企业全部文档

2.5 多轮对话与上下文遗忘

用户和客服的对话很少是"一问一答"就结束的。常见模式是：

用户：iPhone 15 多少钱？

AI：iPhone 15 起售价 5999 元。

用户：256G 呢？

AI（好的模型）：256G 版本售价 6999 元。

AI（差的模型）：对不起，请告诉我您想了解哪款产品？

"256G 呢"是省略主语的指代，AI 必须记住上文是"iPhone 15"才能正确理解。

更复杂的是，用户可能会中途切话题：

用户：iPhone 15 256G 多少钱？
用户：对了，iPad 有优惠吗？
用户：那 iPhone 15 的学生折扣还有吗？

这种"话题跳跃 + 指代省略"对长上下文记忆是个巨大挑战。大模型虽然有上下文窗口，但：

• 窗口越长，注意力越分散
• 中间的内容容易被"遗忘"
• 每一轮都把整段历史传过去，token 费用会爆

三、RAG 是怎么"治"这些病的

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思想一句话讲清楚：

不靠模型"记住"知识，而是回答前先"查"知识。

具体做法：

1. 离线阶段：把企业知识库（产品文档、政策文件、FAQ 等）切成小块，用嵌入模型转成向量，建好索引存到向量数据库
2. 在线阶段：用户提问时，先用问题去向量数据库里检索出最相关的几段知识
3. 把检索到的知识 + 用户问题一起塞进 Prompt，让大模型基于这些知识生成答案

整个过程，模型的角色从"知识持有者"变成了"知识使用者"。知识本身被外置到可以随时更新的数据库里，模型只需要负责"读懂 + 表达"。

四、为什么 RAG 特别适合智能客服

RAG 不是万能解药，但在智能客服这个场景，它几乎直击所有痛点：

更重要的是，RAG 系统开发成本低、上线快：

• 不需要重训模型
• 不需要懂 Transformer 原理
• 几行 Python + 一个向量数据库就能跑起来 demo
• 出了问题好排查：召回的原文对不对、生成模块的 Prompt 合不合适，一目了然

五、本系列能给你带来什么

写完这 38 篇，你将能：

• 从 0 搭建一个生产级 RAG 智能客服系统
• 诊断并优化召回不准、生成胡说、延迟高这些真实问题
• 看懂最新论文（如 Self-RAG、GraphRAG、Agentic RAG）并评估是否值得引入
• 应对面试关于 RAG 的高频问题

读者画像：有一点 Python 基础，了解过大模型 API 调用，在公司里负责或即将负责智能客服项目。不需要Transformer 数学功底。

六、本文小结

• 大模型在客服场景的五大问题：幻觉、知识滞后、无法溯源、私有知识缺失、多轮遗忘
• RAG 的核心思想：让模型"开卷考试"，先查再答
• RAG 对客服场景天然友好：低成本、高可解释、知识随时更新

🔮下一篇预告：我们用一张完整的流程图，把 RAG 的五大核心环节——分片 → 索引 → 召回 → 重排 → 生成——一次性串起来，建立后续学习的认知地图。