从上传资料到生成答案，拆开看 AI 为什么能查到、也为什么会答错
**摘要：**讲透RAG底层流程
**关键词：**RAG是什么、RAG教程、AI知识库原理、Embedding、向量检索
本文是「AI知识库完整教程」第 3 课。
为什么卖家需要懂一点 RAG
很多人以为 AI 知识库不好用，是因为模型不够强。
真实情况经常相反：模型已经够强，但它没有拿到正确资料，或者拿到的资料被切碎了、排序错了、旧版本混进来了。
比如你问：“为什么这个榨汁杯最近退货率上升？”AI 回答说“可能是产品质量问题”。这句话听起来像那么回事，但如果它没有查退货原因、客服记录、Listing 改版、广告关键词和竞品评论，这个结论就只是猜测。
RAG 的价值，就是让 AI 在回答前先去资料库里找证据。你可以把它理解成给 AI 配了一个资料检索员：先查资料，再组织答案。
RAG 到底是什么
RAG 的全称是 Retrieval-Augmented Generation，通常翻译成检索增强生成。
AWS 的官方解释是：RAG 会让大模型在生成回答前引用训练数据之外的权威知识库。LangChain 文档也把 RAG 拆成两段：先做 indexing，把资料处理并索引；再在用户提问时做 retrieval and generation，检索相关数据并传给模型生成答案。
用跨境卖家能理解的话说：RAG 不是让 AI 背下你的全部资料，而是让 AI 每次回答前先查最相关的资料片段。
这就是它和普通聊天最大的区别。普通聊天更像“凭模型记忆回答”；RAG 更像“开卷考试”，但前提是系统能翻到正确那一页。
一条完整 RAG 链路，分成两段
第一段叫入库，也就是 indexing。它发生在你提问之前。
系统要把 PDF、网页、表格、SOP、客服记录、广告复盘读进来，清洗格式，拆成片段，转成向量，存进向量数据库，同时保存标题、日期、SKU、站点、版本、来源这些元数据。
第二段叫问答，也就是 retrieval and generation。它发生在你提问时。
系统先理解你的问题，再去索引里找相关片段，可能还会重新排序，最后把问题和资料片段一起交给大模型，让它基于这些上下文生成答案。
所以，RAG 不是一个按钮，而是一条从资料到答案的链路。链路上任何一环做差，最终回答都会变差。
- 入库阶段：读取资料、清洗、切片、Embedding、存储、补元数据。
- 问答阶段：理解问题、检索、过滤、重排序、组装上下文、生成回答、引用来源。
第一步：资料进入知识库，先决定 AI 能不能看见事实
资料源决定了 AI 的视野。
如果你的知识库只有产品说明书，没有退货记录和客服记录，那么 AI 很难判断退货率上升的真实原因。它可能只能从产品参数里猜。
如果你的知识库里既有旧版 Listing，又有新版 Listing，但没有日期和版本标记，AI 可能把旧表达当成当前页面内容。
所以 RAG 的第一步，不是上传越多越好，而是把正确资料放进去，并标清楚每份资料的身份。
- 产品事实：材质、尺寸、认证、包装、适配范围。
- 运营事实：Listing 版本、广告复盘、活动记录、价格调整。
- 用户事实：Review、QA、客服工单、退货原因。
- 外部事实：竞品页面、竞品差评、类目规则、平台政策。
- 管理信息：日期、版本、站点、SKU、负责人、可信等级。
第二步：切片 Chunk，决定 AI 能不能看懂上下文
大模型不能每次都读完整个资料库，所以系统会把文档拆成较小片段，这一步叫 chunk。
切片像把一本运营手册拆成一张张卡片。卡片太大，检索结果会带入很多无关内容；卡片太小，AI 可能只看到一句话，却不知道这句话属于哪个产品、哪个站点、哪个限制条件。
比如“不可用于热液体”这句话，如果被单独切出来，AI 不一定知道它是在说便携榨汁杯，还是在说另一个厨房产品。如果切片保留标题、产品名、适用范围，答案就稳定得多。
对跨境团队来说，切片最怕机械按字数切。更好的方式是按业务结构切：一个卖点一片、一个 FAQ 一片、一次广告复盘一片、一个差评主题一片。
第三步：Embedding，把文字变成可以比较的坐标
Embedding 是 RAG 里最容易被讲玄的词。其实可以简单理解为：把文字变成一串数字坐标。
意思相近的内容，在这个数字空间里距离更近。
比如买家评论写的是“too small for my morning smoothie”，客服记录写的是“客户认为容量不够”，Listing 里写的是“compact portable cup”。字面不同，但都可能和“容量预期”有关。
Embedding 的作用，就是让系统不仅能按关键词找“capacity”，还可以找到语义上相关的“too small”“not enough”“expected bigger”。
这就是为什么 AI 知识库比传统关键词搜索更适合处理评论、客服、复盘这类自然语言资料。
第四步：向量数据库，负责快速找到相似资料
文字变成向量后，需要存放和检索。向量数据库就是做这件事的。
你可以把它想象成一张业务地图。每段资料都有坐标，用户问题也有坐标。系统会找出离问题最近的一批资料片段。
但这里有一个关键点：相似不等于正确。
系统可能找到了“尺寸投诉”相关资料，但它可能来自旧包装；也可能找到了“退货率上升”相关复盘，但那是另一个 SKU 的经验。所以元数据过滤非常重要。
一个卖家知识库，至少要用 SKU、站点、时间、资料类型、版本状态来过滤检索范围。
第五步：检索 Retriever，决定先把哪些证据拿出来
Retriever 可以理解成知识库里的资料检索员。
用户问“这个产品最近退货率为什么上升”，检索员要决定去哪里找：Review、客服工单、退货原因、Listing 修改记录、广告复盘、竞品资料。
如果检索员只找到了产品说明书，答案就会偏；如果它能同时找用户反馈、页面表达、广告流量变化，答案就会更接近业务真相。
这也是为什么测试 RAG 不能只看最终回答。你必须先看它检索到了哪些片段。检索结果错了，模型写得再顺也没有意义。
第六步：重排序 Rerank，让最相关的证据排前面
第一次检索通常会拿回一批候选片段，但排序未必最好。
Pinecone 文档把 rerank 放在两阶段检索里理解：先快速召回一批候选结果，再用模型对这些结果重新排序。
用业务语言说，第一轮检索像“先把可能相关的文件都拿来”，重排序像“再请一个更细的审核员判断哪几段最能回答这个问题”。
什么时候需要重排序？当你的知识库资料很多、问题复杂、相似内容很多时。比如客服 FAQ、Review 分类、广告复盘、多个 SKU 的相似产品资料混在一起，重排序会更有价值。
第七步：生成回答，必须带边界
最后一步，模型拿到用户问题和检索资料，生成回答。
这一步不是简单总结。一个好的 RAG 回答，应该告诉你三件事：资料明确写到了什么；基于资料可以合理推断什么；哪些地方还需要人工确认。
比如退货率上升案例，AI 可以说：资料明确显示近 30 天差评集中在容量预期；Listing 当前主图缺少手持比例参照；广告复盘显示最近引入了健身人群关键词。合理推断是页面表达和流量人群错配。但是否存在真实产品质量问题，需要结合退货检测和供应链反馈确认。
这种回答才适合运营使用。它不是替人拍板，而是把证据、推断和下一步检查拆清楚。
用一个完整案例跑一遍
问题：便携式榨汁杯最近退货率上升，原因是什么？
资料入库：产品参数、Listing 历史版本、Review、QA、客服记录、退货原因、广告搜索词报表、竞品页面。
切片：每条差评按问题主题切；每次 Listing 修改单独切；广告复盘按时间窗口切；客服问题按 FAQ 切。
Embedding：把“too small”“容量不够”“not enough for protein shake”“尺寸误解”这类表达映射到相近语义。
检索：系统找到容量投诉、Listing 主图变化、广告人群变化、客服尺寸解释相关片段。
重排序：把最近 30 天、当前 SKU、美国站、已确认的资料排到前面。
生成：AI 输出结论：主要风险不是单纯质量问题，而是容量预期管理不足；建议补充主图比例参照、五点重写容量场景、广告排除大容量需求词、客服 FAQ 增加容量解释。
复核：运营点击引用来源，检查每个结论是否真的来自资料，而不是 AI 自己发挥。
怎么判断一个 RAG 系统是否靠谱
不要只问“回答看起来好不好”。要按链路逐项检查。
- 源资料是否覆盖真实业务问题？
- 资料是否有 SKU、站点、日期、版本、负责人？
- 切片是否保留标题和上下文？
- 检索结果是否真的命中了正确资料？
- 是否过滤掉旧版本和无关 SKU？
- 相似资料很多时是否有重排序？
- 回答是否区分事实、推断和待确认事项？
- 是否能点击或追溯到来源？
- 无法回答时是否明确说资料不足？
- 是否有人工反馈机制改进下一次检索？
不要误读：RAG 不是防幻觉保险箱
RAG 可以降低胡说的概率，但不能保证永远正确。
如果资料源就是错的，AI 会基于错误资料回答；如果切片丢了上下文，AI 会误解；如果检索没找到关键证据，AI 可能用不完整资料做判断；如果提示词没有约束，AI 仍可能把推断说成事实。
所以，RAG 的正确用法不是“我上传了资料，AI 就一定可信”，而是“我设计了一条可检查的证据链，让 AI 的回答可以被追溯、被复核、被纠正”。
这才是企业和跨境团队真正需要的能力。
可以直接复制的提示词
请用 RAG 的思路，帮我诊断一个亚马逊产品知识库是否可靠。
产品：【填写 SKU / 产品名】
站点：【填写站点】
资料包括：【产品参数 / Listing / Review / QA / 客服记录 / 广告复盘 / 竞品资料】
我要解决的问题：【例如退货率上升 / 差评变多 / 广告转化下降 / 新人接手慢】
请按以下结构输出：
1. 这个问题需要哪些资料作为证据；
2. 哪些资料应该进入 indexing 阶段；
3. 每类资料应该怎么切片，避免丢上下文；
4. 哪些元数据必须保留，用于过滤检索范围；
5. 用户提问后，retriever 应该优先检索哪些资料；
6. 哪些情况需要 rerank；
7. 最终回答必须分成：资料明确写到、合理推断、需要人工确认；
8. 给我 10 个测试问题，用来判断这个 RAG 知识库是否靠谱。
明天可以照着做的清单
- 不要先研究模型，先检查资料是否覆盖业务问题。
- 每份资料补 SKU、站点、日期、版本、负责人。
- 切片要按业务结构切，不要只按字数切。
- 测试时先看检索结果，再看最终回答。
- 让 AI 回答时区分事实、推断和待确认事项。
- 保留引用来源，重要结论必须能回到原文复核。
结论
RAG 的核心不是“让 AI 读文件”，而是把资料处理、检索、排序、生成和复核连成一条证据链。理解这条链路，你才知道知识库为什么会准，也知道它什么时候不该被相信。
资料来源
- AWS：What is Retrieval-Augmented Generation?
- AWS 将 RAG 描述为让大模型在生成回答前引用训练数据之外的权威知识库，并解释了外部数据、Embedding、向量库、检索和提示词增强的流程。
- LangChain Docs：Build a RAG agent with LangChain
- LangChain 文档把 RAG 拆成 indexing，以及运行时 retrieval and generation 两部分：先索引资料，再在提问时检索相关数据并传给模型。
- LangChain Docs：Retrieval
- LangChain Retrieval 文档指出，大模型有有限上下文和静态知识两类限制，检索是在查询时获取外部相关知识来增强回答。
- Pinecone Docs：Rerank results
- Pinecone 文档说明 rerank 可作为两阶段向量检索的一部分，用模型对初步召回结果重新排序，提高相关性。