最近很多团队开始聊 GEO。也就是 Generative Engine Optimization，生成式搜索优化。简单讲，就是当用户在 ChatGPT、豆包、Kimi、元宝、DeepSeek 这类 AI 搜索或问答产品里提问时，品牌、产品、内容、官网能不能被 AI 提到，能不能被正确理解，能不能被推荐出来。

过去我们做 SEO，核心问题是怎么让网页排到搜索结果前面。现在做 GEO，问题变了。不是用户能不能搜到你。

而是 AI 在回答问题时，会不会「想起你」。这个变化很关键，因为在传统搜索里，用户看到的是一组链接，品牌还有机会靠标题、摘要、落地页转化用户，但在 AI 搜索里，用户看到的是一个被整合过的答案。

AI 可能直接告诉用户，某类产品有哪些选择，每个产品适合什么人，有什么优缺点，甚至直接给出购买建议。这时候，如果你的产品没有进入 AI 的答案，你就不是排名靠后。你是直接消失。所以 GEO 产品要解决的核心问题，其实可以压缩成一句话。如何提高品牌或产品在 AI 答案里的命中率。而 RAG，正是目前最现实的一条路径。

大模型自己脑子里不一定记得你，也不一定记得准你。 就先把和你有关的可信内容检索出来，再让模型基于这些内容回答。所以 RAG 的价值，不是让模型变聪明。而是让模型在回答时，更容易拿到「应该参考你的理由」，这也是 GEO 产品里最值得重视的地方。很多人做 GEO，第一反应是写更多文章、铺更多关键词、发更多通稿。这些当然有用。

但如果没有一套 RAG 思路，内容很容易变成堆料。你写了很多，AI 不一定抓得到。AI 抓到了,也不一定理解对，理解对了，也不一定在合适的问题里引用你。

真正有效的 GEO，不是单纯增加内容数量，而是让内容变成 AI 更容易检索、理解和引用的知识资产。

这里面至少有四件事要做。

第一件事，是把产品信息拆成「可检索的事实单元」

很多企业官网写产品介绍，特别喜欢写大词,比如一站式解决方案、智能化增长平台、全链路赋能、领先的行业实践。这些词对人类销售材料可能有点用，但对 AI 检索不一定友好。因为用户真实提问通常不是这么问的。

用户会问：

• 适合中小团队的 CRM 有哪些？
• 我的脸比较敏感有哪些防晒产品推荐？
• 有没有适合跨境电商的 BI 工具？
• 某某产品和某某产品有什么区别？
• 什么手机打游戏不发烫性价比高？

AI 要回答这些问题时，需要的是清晰、具体、可比对的含场景的信息。

你的产品是什么、适合谁、解决什么问题、不适合谁、核心功能有哪些、和竞品差异在哪里、价格区间如何、有没有典型客户、有没有行业案例、支持哪些平台和集成、有哪些限制条件。这些内容越清楚，越容易被 RAG 系统检索出来。所以 GEO 产品要做的第一步，不是写更多营销话术，而是把品牌和产品拆成结构化事实。让 AI 能看懂你是谁。

第二件事，是围绕用户问题建立内容库

传统 SEO 很重视关键词，GEO 更应该重视问题。因为用户在 AI 搜索里的表达方式，越来越接近自然语言。他不是搜「CRM 软件 排名」，他会问「我们是一个 30 人销售团队，主要做 B2B 大客户，预算有限，有没有比 Salesforce 更轻量的 CRM？」你看，这里面不只是关键词，里面有公司规模、预算、业务模式、替代对象、购买意图。

这类问题，才是 GEO 产品真正要覆盖的入口。所以做 RAG 内容库时，不能只按产品模块组织内容。还要按用户问题组织内容。

比如一个 SaaS 产品，如果想提高 AI 推荐命中率，至少要覆盖几类问题：

• 选型类问题，用户在比较不同方案
• 替代类问题，用户想找某个大产品的平替
• 场景类问题，用户有一个具体业务痛点
• 行业类问题，用户关心某个垂直行业方案
• 对比类问题，用户在比较你和竞品
• 价格类问题，用户关心预算和性价比
• 风险类问题，用户担心实施、迁移、安全、售后

每一类问题，都应该有对应的内容资产。不是一篇大而全的官网介绍，而是一组能够回答具体问题的内容块。RAG 最怕的不是没有内容。是内容太大、太虚、太不贴近问题。

第三件事，是提高内容的可信度和可引用性

AI 在生成答案时，不只看你有没有提到自己。它还会看信息是否可信，是否有外部佐证，是否表达清楚，是否适合被引用。这也是很多品牌做 GEO 容易忽略的地方。如果你所有内容都来自自家官网，而且都是自夸式表达，AI 未必愿意把你放进推荐结果。因为它缺少可信证据。所以 GEO 产品应该帮助企业构建证据链。

• 官网产品页是一层
• 帮助中心和文档是一层
• 客户案例是一层
• 第三方评测是一层
• 媒体报道是一层
• 社区讨论是一层
• 行业榜单和数据库又是一层

RAG 的检索结果越能形成互相印证，模型越容易把你的产品放进答案。

这里有一个很实用的判断标准。你的内容能不能被 AI 直接拿去回答用户问题。如果不能，说明内容还不够清楚。比如你写「我们服务众多头部客户」。

这句话没法引用。但如果你写「某跨境电商团队使用该系统后，将客服工单平均响应时间从 12 小时降到 3 小时」这就更容易被引用。AI 喜欢清楚的事实、明确的场景、具体的对象、可验证的结果。

GEO 产品要做的，就是把这些内容从企业材料里挖出来，整理成更适合 AI 检索和生成的格式。

第四件事，是建立命中率评测系统

这一步非常重要。没有评测，GEO 就会变成玄学。很多团队做 GEO，只看内容发了多少、页面收录了多少、品牌提及有没有增加。但真正应该看的，是一组具体问题里，AI 有没有命中你。比如你可以建立一个问题集。里面包含 200 个到 1000 个真实用户可能会问的问题。然后定期在不同 AI 搜索产品里测试：你的品牌是否出现

• 出现的位置靠前还是靠后
• 是否被正确描述
• 是否被列入推荐列表
• 是否被当成主要选择
• 是否出现错误信息
• 是否引用了可信来源
• 是否在关键竞品问题里缺席

这套评测集，就是 GEO 产品的核心资产，因为它能告诉你，问题到底出在哪里

• 有些问题是内容缺失
• 有些问题是内容存在但没有被检索到
• 有些问题是检索到了但表达不够有说服力
• 有些问题是竞品内容证据更强
• 有些问题是外部平台对你的认知有偏差

RAG 在这里的作用，不只是生成答案。它也可以反过来帮助诊断。比如系统可以分析每个问题对应的检索结果，判断为什么你的产品没有被命中。

• 是缺少行业场景内容？
• 是缺少对比页？
• 是缺少客户案例？
• 是产品定位不清？
• 还是外部资料里存在过时信息？

这会让 GEO 从「写内容碰运气」，变成「基于问题集持续优化」。我觉得这才是 GEO 产品真正有价值的方向。不是帮企业批量生成文章。而是帮企业建立一套面向 AI 答案的内容工程系统。这里面 RAG 的位置很清楚。它既是内容组织方式，也是评测工具，还是优化引擎。

对 GEO 产品来说，RAG 可以分成三层。

第一层，企业知识库 RAG

把官网、产品文档、案例、白皮书、FAQ、销售材料、竞品对比、行业方案统一整理，形成可检索知识库。这一层解决的是「AI 能不能拿到正确材料」。

第二层，问题场景 RAG

围绕用户真实提问，把内容切成更细的场景单元，并和问题意图建立映射。这一层解决的是「AI 能不能在正确问题里想到你」。

第三层，评测诊断 RAG

用固定问题集模拟不同用户搜索场景，检测品牌命中率、描述准确率、引用质量和竞品对比表现。这一层解决的是「我们怎么知道优化有没有效果」。

如果只做第一层，GEO 产品很容易变成知识库工具。如果能做到第二层，才开始接近真正的生成式搜索优化。如果能做到第三层，才有机会变成企业长期使用的增长工具。因为企业真正愿意付费，不是「你帮我存了多少内容」。而是「你能不能让我在 AI 答案里更容易被看见」。当然，这件事也有坑。

第一个坑，是把 RAG 做成简单的向量检索

很多团队觉得，把内容丢进向量数据库，再接一个大模型，就叫 RAG。技术上可能没错，但 GEO 场景里远远不够。因为 GEO 不是只要召回相似内容。它还要理解用户意图、商业场景、竞品关系、内容可信度和推荐逻辑。

一个用户问「适合创业团队的 CRM」，和问「Salesforce 太贵有没有替代品」，表面都和 CRM 有关，但背后意图完全不同。

前者要强调轻量、易用、低成本。后者要强调替代理由、迁移成本、功能差异。如果 RAG 不理解这些差异，命中率很难提升。

第二个坑，是只优化自家内容。

AI 对一个品牌的理解，不只来自官网。它还来自第三方网站、媒体、社区、问答平台、榜单、开发者文档、用户评论。如果外部信息缺失，或者外部信息和官网说法不一致，AI 的回答就可能偏。所以 GEO 产品不能只做站内内容管理。它还要监测外部认知。

• 哪里描述错了
• 哪里信息过时了
• 哪里竞品占了你的关键词
• 哪里用户讨论里出现了负面误解
• 哪里缺少第三方证据

这些都会影响最终命中率

第三个坑，是把命中率当成唯一目标。

GEO 当然要提高命中率，但不能为了出现而出现。如果 AI 在不相关问题里频繁提到你，反而可能伤害用户体验。更好的目标应该是有效命中。也就是在合适的问题、合适的场景、合适的用户意图里，被准确提及。

比如一个高端企业级产品，不一定要出现在「免费 CRM 推荐」里。但它应该出现在「大型销售团队 CRM 选型」「复杂权限管理 CRM」「企业级客户数据管理」这类问题里。GEO 的关键不是刷存在感。而是占住正确语境。所以 GEO 产品如果要做得专业，指标体系也要更细。不能只看总命中率。还要看核心问题命中率、商业意图问题命中率、竞品对比命中率、品牌描述准确率、错误信息率、引用来源质量、推荐位置、答案情绪倾向。这些指标加在一起，才更接近真实效果。

说到这里，其实可以发现，RAG 对 GEO 的价值不是一个技术功能点。

它更像是一套产品方法。先把用户问题结构化。 再把企业内容知识化。 再把知识和问题建立映射。 再用评测集持续检测命中效果。 最后反向指导内容生产和外部声量建设。这套链路跑起来以后，GEO 才不是玄学。

它会变成一个可诊断、可优化、可迭代的系统。我觉得未来比较成熟的 GEO 产品，大概率会长成这样。一边是品牌知识库，沉淀企业所有可信信息。一边是用户问题库，覆盖不同场景、行业、竞品和购买意图。中间是 RAG 引擎，负责把问题和内容连接起来。上层是评测系统，持续监测不同 AI 平台里的表现。再往上，是优化建议，告诉企业下一步应该补哪类内容、修正哪类事实、加强哪类外部证据。

这才是一个完整的 GEO 闭环。不是写文章，不是堆关键词，也不是到处发通稿。而是让 AI 在需要推荐某类产品时，有足够清晰、可信、结构化的理由，把你放进答案里。回到最开始的问题。GEO 产品如何用 RAG 提高产品引用率？我的答案是，不要把 RAG 当成一个搜索插件。要把它当成 GEO 的基础设施。

它要帮助企业解决三件事。

第一，让 AI 找得到你

第二，让 AI 理解得对你

第三，让 AI 在合适的问题里推荐你

这三件事，任何一件缺了，命中率都不会稳定。

未来的搜索流量，可能不再来自一个蓝色链接。而是来自 AI 答案里一句看似轻描淡写的推荐。用户问，有没有适合我的产品。AI 回答，可以考虑这几个。如果你的名字在里面，机会就开始了。如果不在里面，很多时候用户甚至不会知道你存在过。

这就是 GEO 为什么重要，也是 RAG 为什么会成为 GEO 产品的核心能力。

当接到一个需求：搭建电商客服智能体，要求能准确回答商品咨询、订单查询、售后政策等问题。技术方案评审时，算法同学提出用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：业务对接层

• 订单系统API调用
• 商品库实时同步
• 用户权限验证

三、知识库建设：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：向量检索

• 召回top-20相关文档
• 基于语义相似度排序

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分钟分析：

分析维度：

1. 是知识库缺失？(补充知识)
2. 是检索不准？(优化召回策略)
3. 是生成质量差？(调整Prompt)
4. 是理解错误？(改进意图识别)

案例：某次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设计不够健壮 大模型有时会”发挥创造力”，编造一些听起来合理但实际不存在的政策。教训：在Prompt中反复强调”只基于参考信息回答，不要编造”。

坑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产品的朋友少踩坑，多成长。