开篇：大模型不能只靠记忆

大模型很强。

但它有一个天然问题：它不知道你的内部文档，也不一定知道最新变化。

你问它公司最新退款政策，它可能凭训练记忆回答。你问它线上故障怎么排查，它可能给一套通用建议。

这就是 RAG 要解决的问题。

RAG 的思路很简单：先检索资料，再让模型基于资料回答。

它把大模型从“闭卷考试”变成“开卷考试”。

1. RAG 到底是什么

RAG，全称 Retrieval-Augmented Generation，中文一般叫“检索增强生成”。

它不是一个模型。

它是一条工程链路。

用户提问后，系统先从外部知识库里找相关材料，再把材料放进上下文，最后交给大模型生成答案。

所以，RAG 的核心不是“生成”，而是“把正确材料送到模型面前”。

2. 为什么 Agent 离不开 RAG

Agent 要完成任务，必须知道外部世界的信息。

工具调用能让 Agent 查接口、查数据库、发请求。

RAG 让 Agent 能查文档、查知识库、查历史记录。

这两者不冲突。一个偏“操作系统”，一个偏“知识系统”。

没有 RAG 的 Agent，遇到企业内部知识就容易失明。

没有引用的 Agent，回答再顺，也很难让人放心。

3. RAG 的核心流程

生产级 RAG 一般分两条线。

第一条线是离线建库：把文档清洗、切块、向量化、建立索引。

第二条线是在线问答：把用户问题改写、检索、重排、组装上下文、生成答案。

很多 RAG 效果差，不是模型差，而是建库差、切块差、召回差。

4. 关键组件讲清楚

文档加载：把 PDF、网页、Markdown、工单、Wiki 等资料接进来。

清洗切块：去掉噪音，按标题、段落、语义边界拆分，别粗暴固定长度切。

Embedding：把文本变成向量，方便按语义搜索。

索引存储：通常会同时用向量索引、关键词索引、元数据过滤。

检索召回：从海量资料里取候选片段。

重排过滤：把候选片段重新排序，去掉弱相关、重复、过期内容。

上下文拼装：把最有用的片段放进 Prompt，控制长度、顺序和引用。

答案生成：让模型基于资料回答，而不是自由发挥。

5. 标准 RAG 和 Agentic RAG 的区别

标准 RAG 通常是：检索一次，生成一次。

这对简单问答够用。

但复杂问题不够。比如资料冲突、问题太宽、文档过期、检索结果不完整。

Agentic RAG 会在中间加入判断层。

它会先判断问题要不要拆分，再选择检索源，评估材料质量，必要时二次检索或调用外部工具。

这就是 RAG 从“被动查资料”升级为“主动找证据”。

6. 案例：内部技术知识库问答 Agent

假设用户问：线上订单接口超时，历史上怎么处理？

普通大模型可能会给一套通用排查步骤。

RAG Agent 的做法不一样。

它会先检索订单服务 Runbook、故障复盘、监控规则、历史工单。

然后优先选择最新、官方、命中服务名的资料。

最后输出可执行步骤，并附上来源。

如果资料不足，它应该追问或者转人工，而不是硬编。

7. 工程运行逻辑

RAG 的伪逻辑很简单，但细节很多。

用户问题不能直接拿去搜。要先做意图识别、查询改写、必要时拆成子问题。

检索不能只靠向量。要结合关键词、元数据、时间、权限。

生成不能只拼一堆资料。要控制上下文长度，保留来源，过滤低质量片段。

答案不能只看流畅度。要看是否忠于检索材料。

8. 常见坑

第一，切块太粗。一个 chunk 里塞太多主题，检索命中后模型也抓不到重点。

第二，只做向量检索。很多技术词、订单号、接口名，关键词检索反而更准。

第三，不做重排。TopK 只是候选，不代表都该进上下文。

第四，不做权限控制。知识库问答不能让普通用户查到敏感文档。

第五，不给引用。没有来源，答案就不可追溯。

第六，不做评估。RAG 不是上线后看感觉，要看召回率、上下文准确率、忠实度和用户反馈。

9. 上线检查清单

10. 总结

RAG 是 Agent 的知识底座。

它解决的不是“模型会不会说”，而是“模型有没有依据说”。

标准 RAG 适合简单问答。

Agentic RAG 适合复杂知识任务。

真正可用的 RAG，不是一个向量库加一个 Prompt。

它是一套完整工程：数据接入、清洗切块、索引检索、重排过滤、上下文拼装、引用溯源、权限控制、持续评估。

把这条链路做好，Agent 才能从“凭感觉回答”，变成“带证据工作”。