一、RAG 简介项目内容全称Retrieval-Augmented Generation检索增强生成核心思想先从知识库中检索相关内容再让 LLM 基于检索结果生成回答避免 LLM 编造信息解决的问题LLM 的幻觉问题编造信息、知识过时问题、领域知识不足问题基本架构用户提问 │ ▼ [查询处理] → [检索] → [重排] → [上下文组装] → [LLM生成] → 回答 ↑ [知识库] 索引 ← 文档处理 ← 数据源二、架构师要解决的核心问题2.1 数据处理层——“知识怎么灌进去”问题具体要决策的文档怎么切分按固定长度切按段落切按语义切切多大重叠多少切分粒度怎么定太大检索不精准混入无关内容太小丢失上下文答案碎片化元数据要不要加标题、章节、来源、时间戳——加了能过滤不加检索更简单多模态怎么处理图片、表格、公式要不要单独提取怎么和文本对齐数据更新怎么办增量更新还是全量重建过期文档怎么标记/删除切分粒度的典型权衡切分太小100字 ✅ 检索精准 ❌ 上下文断裂2023年营收增长30%不知道是哪家公司 切分太大1000字 ✅ 上下文完整 ❌ 检索噪声多一段话里只有一句相关 常见选择256~512 token重叠 50~100 token2.2 向量化与索引层——“怎么快速找到相关内容”问题具体要决策的用什么 Embedding 模型OpenAI text-embedding-3BGEM3E效果、速度、成本的权衡向量维度多少高维度表达力强但检索慢低维度快但可能丢信息用什么向量数据库Milvus、Pinecone、Weaviate、Qdrant、Chroma索引类型怎么选HNSW精度高、IVF速度快、Flat小数据量要不要混合检索纯向量检索 vs 向量关键词BM25混合多语言怎么处理跨语言 Embedding 还是翻译后统一向量化混合检索的必要性纯向量检索 问iPhone 15 Pro Max 多少钱 可能检索到这款手机售价9999元 ← 语义相近但没提具体型号 纯关键词检索 问iPhone 15 Pro Max 多少钱 可能检索到iPhone 15 Pro Max 参数配置... ← 有关键词但不是价格信息 混合检索向量关键词 同时匹配语义相关和关键词命中的内容 ✅2.3 查询处理层——“用户问的到底是什么”问题具体要决策的查询要不要改写用户说它多少钱它指什么需要结合上下文补全要不要拆分子查询“A和B的区别是什么” → 拆成什么是A“什么是B”“A和B对比”要不要加查询扩展用户说手机 → 扩展成手机 智能手机 mobile phone要不要加查询路由不同类型问题走不同检索路径闲聊/知识库/搜索查询改写的典型场景用户第1轮华为Mate60的电池容量是多少 用户第2轮那充电速度呢 不改写检索充电速度 → 找到各种充电速度的信息不知道是哪个设备的 改写后检索华为Mate60充电速度 → 精准定位 ✅2.4 检索与重排层——“找到的内容哪些真正有用”问题具体要决策的检索多少条Top-5Top-10Top-20多了噪声大少了可能漏要不要重排Rerank向量检索按相似度排不一定按相关性排重排模型能纠正用什么重排模型BGE-Reranker、Cohere Rerank、Cross-Encoder相似度阈值怎么定低于多少直接丢弃避免不相关内容混入要不要去重不同文档可能包含相同内容重复输入浪费 token为什么需要重排向量检索双塔模型 查询和文档分别编码算余弦相似度 → 快但不够精准 重排模型交叉编码器 把查询和文档拼在一起让模型判断相关性 → 慢但精准得多 典型流程 先用向量检索 Top-50快速粗筛 再用重排模型精排 Top-5慢速精选2.5 上下文组装层——“怎么把检索结果喂给 LLM”问题具体要决策的Prompt 怎么设计检索内容放前面还是后面要不要加指令约束上下文窗口溢出怎么办检索内容问题超过 LLM 上下文长度怎么截断多条检索结果冲突怎么办文档A说价格9999文档B说价格8999怎么处理要不要压缩检索内容用小模型压缩后再喂给大模型省 token检索结果要不要加引用标注让 LLM 标注答案来自哪个文档Prompt 设计的典型结构[系统指令] 你是一个问答助手根据以下参考资料回答用户问题。 如果参考资料中没有相关信息请回答我不知道。 不要编造信息。 [参考资料1] 来源产品手册.pdf 华为Mate60电池容量为4880mAh... [参考资料2] 来源评测文章.md 实测充电速度约40分钟从0充到100%... [用户问题] 华为Mate60的电池容量和充电速度是多少2.6 生成与输出层——“回答怎么保证质量”问题具体要决策的用什么 LLMGPT-4、Claude、开源模型效果、速度、成本怎么平衡怎么防止幻觉LLM 编造检索内容中没有的信息怎么办要不要加引用回答中标注信息来源增加可信度流式输出还是等完再输出用户体验 vs 实现复杂度要不要加安全过滤敏感信息、有害内容的检测和过滤防幻觉的关键手段1. Prompt 约束只能根据参考资料回答没有就说不知道 2. 事实校验生成后用另一个模型检查答案是否和检索内容一致 3. 置信度评估对答案的每个部分标注置信度 4. 引用溯源要求标注每句话来自哪个文档哪一段2.7 工程与运维层——“怎么跑得稳、跑得省”问题具体要决策的并发怎么处理向量检索和 LLM 推理都是计算密集型怎么扩缩容延迟怎么控制检索重排生成全链路耗时用户能接受多少缓存怎么做相同问题缓存答案相似问题缓存检索结果成本怎么控制Embedding 调用费、向量库存储费、LLM 推理费怎么评估效果召回率、准确率、答案质量的评估体系怎么建怎么监控检索质量下降、LLM 输出异常、知识库过期怎么发现数据安全企业内部知识库数据不能泄露给外部 API三、架构师面临的典型权衡权衡一端另一端精度 vs 速度重排多次检索大模型简单检索小模型成本 vs 效果GPT-4 长上下文开源模型 短上下文实时性 vs 完整性增量索引秒级更新全量重建质量更高通用 vs 专用通用 Embedding 通用 LLM领域微调模型安全 vs 便捷本地部署数据不出域云端 API开发快四、常见架构模式模式1基础 RAG用户提问 → 向量检索 → 拼接Prompt → LLM生成 → 回答 简单但效果有限 适合原型验证、简单场景模式2进阶 RAG用户提问 → 查询改写 → 混合检索 → 重排 → 上下文压缩 → LLM生成 → 回答 多了查询优化、混合检索、重排、压缩 适合生产环境主流方案模式3Agent RAG用户提问 → Agent规划 → 多轮检索/工具调用 → 综合判断 → LLM生成 → 回答 LLM 自主决定要不要检索、检索几次、用什么工具 适合复杂推理场景模式4Graph RAG用户提问 → 知识图谱检索 向量检索 → 融合 → LLM生成 → 回答 用知识图谱补充实体关系向量检索补充细节 适合关系密集型场景如组织架构、产品依赖五、意图识别——RAG 的入口路由5.1 什么是意图识别意图识别就是判断用户说的话属于哪种类型的需求本质是一个分类问题。用户说北京今天天气怎么样 → 意图查天气 用户说明天要下雨吗 → 意图查天气 用户说帮我定明天去上海的机票 → 意图订机票 用户说退掉我上周的订单 → 意图退订单 用户说你们客服电话多少 → 意图查联系方式 用户说你好 → 意图闲聊同一个意图可以有无数种说法意图识别就是把不同的说法归到同一个类别。5.2 意图识别在 RAG 中的作用场景意图识别的结果走什么路径“华为Mate60电池多大”知识查询走 RAG 检索知识库“你好你是谁”闲聊直接 LLM 回答不检索“帮我写一封请假邮件”内容生成LLM 直接生成不需要检索“计算3的平方根”工具调用调计算器不检索“总结这篇文档”文档处理走文档处理流程没有意图识别 用户说你好 → 也去检索知识库 → 检索结果无关 → 回答莫名其妙 用户说帮我写首诗 → 也去检索知识库 → 浪费资源 有意图识别 用户说你好 → 识别为闲聊 → 直接回答 ✅ 用户说帮我写首诗 → 识别为生成 → 直接生成 ✅ 用户说Mate60电池多大 → 识别为知识查询 → 走RAG ✅RAG 中意图识别的价值该检索的检索不该检索的不检索。5.3 意图识别怎么做方法1规则匹配最简单关键词匹配 if 天气 in query or 下雨 in query: intent 查天气 elif 订票 in query or 机票 in query: intent 订机票 elif 退款 in query or 退货 in query: intent 退订单 else: intent 未知优点简单不需要训练缺点覆盖不全明天出门要带伞吗识别不出是查天气方法2分类模型传统做法训练一个文本分类器 训练数据 北京今天天气怎么样 → 查天气 明天要下雨吗 → 查天气 帮我定机票 → 订机票 退掉我的订单 → 退订单 ... 模型BERT、FastText、SVM 等优点比规则准能理解语义缺点需要标注数据新意图要重新训练方法3LLM 直接判断当前主流Prompt 你是一个意图识别器判断用户输入属于以下哪个意图 - weather查询天气 - flight订机票 - refund退订单 - chat闲聊 - knowledge知识查询 - other其他 用户输入{query} 请输出意图类别 LLM 输出weather优点不需要训练数据零样本就能用灵活缺点每次调用有成本和延迟方法4Function CallingOpenAI 风格预先定义一组函数意图 functions [ {name: get_weather, description: 查询天气, parameters: {city: string}}, {name: book_flight, description: 订机票, parameters: {...}}, {name: refund_order, description: 退订单, parameters: {...}}, ] 用户说北京明天天气怎么样 LLM 自动选择get_weather(city北京)意图识别 参数提取一步完成这是当前最优雅的方式。5.4 意图识别的难点难点例子原因一句话多个意图“订机票顺便查下那边天气”订机票 查天气要拆分处理意图模糊“我的订单怎么了”是查物流还是退款还是投诉口语化表达“这破手机又卡了”是吐槽还是求助还是想退货新意图训练时没见过的意图分类模型无法识别需要兜底策略上下文依赖“那充电速度呢”上一轮在聊Mate60这里要继承上下文5.5 多意图怎么处理用户帮我订明天去上海的机票顺便查下那边天气 方案1识别为多意图并行处理 意图1订机票 → 走订票流程 意图2查天气 → 调天气API → 两个结果合并返回 方案2识别为主意图忽略次要 主意图订机票 → 只走订票流程 → 简单但可能遗漏用户需求 方案3逐个处理 先处理订机票 → 完成后追问还要查天气吗 → 体验好但交互多5.6 意图识别在完整系统中的位置用户输入 │ ▼ [意图识别] ──→ 判断意图类别 │ ├─ 闲聊 ──────→ LLM 直接回答 ├─ 知识查询 ──→ RAG 检索 LLM 生成 ├─ 内容生成 ──→ LLM 直接生成 ├─ 工具调用 ──→ 调用对应 API ├─ 多意图 ────→ 拆分后分别处理 └─ 未知意图 ──→ 追问澄清意图识别是整个系统的入口路由决定了后续走哪条路。六、意图识别的常见场景意图识别不是 RAG 独有的它出现在几乎所有智能交互系统中。场景例子意图有哪些RAG / 知识库问答企业知识助手知识查询、闲聊、内容生成、文档处理智能客服电商/银行客服查订单、退款、投诉、转人工对话系统/聊天机器人小爱同学、Siri播音乐、设闹钟、查天气、闲聊语音助手车载语音导航、打电话、开空调、听歌任务型对话订餐/订票机器人订位、改时间、取消、查菜单搜索系统搜索引擎找网页、找图片、找视频、算数学工单路由企业IT运维网络问题、账号问题、软件安装、硬件报修哪些场景必须用意图识别必须原因例子智能客服几十种意图每种走不同业务流程退款和查物流处理完全不同语音助手意图决定调哪个设备/API设闹钟和开空调调的是不同接口任务型对话意图决定执行什么动作订票和改签是不同流程多技能 Bot意图决定走哪个技能模块RAG、搜索、生成、工具不一定需要原因例子纯 RAG如果系统只做知识问答所有问题都检索内部文档问答不涉及闲聊纯闲聊只有一种意图聊天机器人不需要路由单任务系统只做一件事只做翻译的 Bot七、RAG 中意图识别的典型架构用户提问 │ ▼ [意图识别] │ ├── knowledge知识查询──→ [查询改写] → [RAG检索] → [重排] → [LLM生成] │ ├── chat闲聊──────────→ [LLM直接回答] │ ├── generate内容生成──→ [LLM直接生成] │ ├── tool工具调用──────→ [调用API] → [结果返回] │ └── unknown未知意图───→ [追问澄清]RAG 只是意图识别路由后的一个分支不是全部。八、各层核心问题总结层核心问题一句话数据处理怎么切、怎么灌、怎么更新知识的质量决定上限向量索引怎么编码、怎么存储、怎么检索检索的精度决定下限查询处理用户到底在问什么理解问题是正确回答的前提检索重排哪些内容真正有用粗筛精选宁缺毋滥上下文组装怎么喂给 LLM垃圾进垃圾出Prompt 是门手艺生成输出怎么保证不编造约束校验引用工程运维怎么跑得稳、跑得省可用性、成本、安全的平衡意图识别用户想干什么该检索的检索不该检索的不检索九、一句话总结RAG 的核心难题不是能不能跑起来而是检索准不准、回答对不对、成本控不控得住。意图识别是系统的入口路由决定后续走哪条路。架构师的价值在于在精度与速度、成本与效果、安全与便捷之间做出合理权衡。