最近看一位 IBM 研究员拆解 RAG 工程实操，
顺手用一段 IBM 风格的 prompt 生成了几张图，记录成图文。
01｜RAG 的真实架构：不是“搜一下再喂给模型”
真正的 RAG，是个严格分层的两阶系统：
Offline 做采集和向量化，Online 做问题理解与上下文组装。
离线决定“你能找到什么”，在线决定“你会不会用”。
大多数 RAG 效果差，不是模型问题，而是：
离线数据结构混乱和在线上下文拼接粗糙。
02｜规模化陷阱：Token 越多 ≠ 越聪明
RAG 失败后的常见反应：
Top K 不够？加。
Chunk 不够？加。
文档不够？全量灌。
结果往往是：
准确率先升后降，呈现倒 U 型。
问题不在“检索不够多”，
而在“噪声开始主导注意力”，
最终还是“检索不够准”。
03｜真正的第一步：数据不是越多，而是越干净
如果你现在还在做这件事：
把 PDF 扔进 RAG，然后祈祷模型理解它
那问题已经找到了。
PDF 是给人看的，不是给模型看的。
真正可用的 RAG 数据，必须经过结构化清洗：
→文本语义连续
→表格语义完整
→图片 / 页码 /标题具备元数据
→可被精确定位与引用
这也是为什么现在越来越多团队会用 Docling 这类工具：
PDF → Markdown / JSON + Metadata
左边是“文档集合”，右边才是“知识资产”。
04｜Context Engineering：RAG 的灵魂，不是检索算法
RAG 的核心不在“怎么搜”，
而在“上下文如何被组织”。
混合召回解决“找得到”，
重排序决定“信不信”。
优秀的 RAG，
更像一位替你整理证据链的研究助理。
05｜企业落地：私有化不是选项，是前提
在企业场景里，RAG 永远绕不开三件事：
数据主权、可审计性、性能稳定。
本地模型部署、KV Cache 管理、上下文控制，
不是优化项，而是入场门槛。
RAG 在企业里不是聊天工具，
而是可控、可复现的工程系统。
千言万语一句话：
RAG 的上限，不由模型决定，而由工程纪律决定。