LLM Wiki / RAG
RAG 的真实架构：从文档摄取到可引用答案
拆解生产级 RAG 的离线索引、在线检索、生成引用、评测观测四条链路。
多数 RAG Demo 只有一条短链路：切块、Embedding、向量召回、拼 Prompt、生成答案。生产系统不能这么看。更准确的拆法是四条链路：离线知识链路、在线检索链路、生成引用链路、评测观测链路。
核心判断
RAG 的质量问题通常不在最后一次 LLM 调用，而在前面的数据准备、索引设计、召回融合和上下文选择。
总体架构
离线链路：决定知识能不能被用
离线链路最容易被低估。解析错了、表格丢了、标题没了、权限没带上，后面换再强的模型也很难补回来。
| 环节 | 关键产物 | 常见问题 |
|---|---|---|
| 解析 | 原文、段落、页码、表格、图片描述 | PDF 断行、表格错列、扫描件 OCR 错误。 |
| 清洗 | 去重文本、有效版本、失效标记 | 旧文档和新文档同时进入索引。 |
| 元数据 | 来源、作者、更新时间、ACL、业务标签 | 检索时无法按权限、时间、业务线过滤。 |
| 分块 | Chunk、父子关系、标题路径 | 小块缺上下文，大块噪声太多。 |
| 索引 | BM25、向量、稀疏向量、图结构 | 单一路径召回不稳定。 |
实践建议
Chunk 不应该只保存正文。至少要附带 document_id、chunk_id、title_path、source_url、updated_at、page、acl、parent_id。否则很难做引用、权限和回归评测。
在线链路：决定证据是否相关
在线检索不是把问题向量化后查 Top-K。真实问题通常有省略、上下文、口语表达和业务暗语，需要先做查询理解。
一个稳定的在线链路通常包含：query rewrite、hybrid retrieval、metadata filter、rerank、context packing。每一步都应该可记录、可复现、可评测。
生成链路：答案必须绑定证据
生成 Prompt 的重点不是“请你专业地回答”，而是约束模型只能基于证据回答，并在证据不足时拒答或追问。
| 设计项 | 要求 |
|---|---|
| 引用 | 每个关键结论要能映射到 chunk 或文档位置。 |
| 拒答 | 证据不足时说明缺什么，不要编。 |
| 冲突处理 | 多个文档结论冲突时优先使用更新、更权威的来源。 |
| 输出结构 | 对复杂问题使用分点、表格或步骤，方便审阅。 |
评测链路：否则优化没有方向
没有评测，RAG 优化会变成“感觉更好了”。最小可行评测集应该包含问题、标准答案、标准证据、用户权限和期望行为。
| 指标 | 看什么 | 用于优化什么 |
|---|---|---|
| Recall@K | 正确证据是否被召回 | 索引、查询改写、召回策略。 |
| MRR / NDCG | 正确证据排序是否靠前 | 融合、重排。 |
| Context Precision | 上下文是否干净 | rerank、context compression。 |
| Faithfulness | 答案是否忠于证据 | prompt、引用约束、拒答。 |
| P95 Latency | 用户等待时间 | 并行检索、缓存、模型选择。 |
架构落地顺序
- 先打通可观测 baseline：解析、分块、混合检索、引用回答、trace。
- 建立 100 到 300 条真实问题的 golden dataset。
- 引入 reranker，把 Top-50 压到 Top-5 或 Top-8。
- 加入权限过滤，确保检索阶段已经完成 security trimming。
- 对复杂问题再引入 multi-query、router、GraphRAG 或 Agentic RAG。
生产级 RAG 不是堆组件，而是把每个环节的输入、输出、失败原因和评测指标讲清楚。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。