LLM 在生成答案时临时从外部文档集合检索相关片段并塞进 prompt 的范式。生产 Agents 的核心组件之一。
标准流程
你有文档集合,LLM 查询时检索相关 chunk,塞入 context,生成答案。
代表产品:NotebookLM、ChatGPT 文件上传、"大多数 RAG 系统"。
三个核心维度
来源:2026-04-14-ibm-7-skills-ai-agents 的 "Retrieval Engineering" 一节。
Chunking
怎么把文档切片?
- 太大 → 重要细节被稀释,信号噪声比下降
- 太小 → 丢上下文,片段失去意义
Embedding
向量表示:相似概念是不是真的在向量空间里彼此靠近?
- 不同 embedding 模型的"相似度"几何形状不一样
- 领域术语在通用 embedding 里可能误聚类
Re-ranking
检索后第二遍打分。
- 第一遍向量召回偏召回率
- 第二遍按真实相关性精排,把好东西推到顶部
你检索的内容质量决定 agent 性能的天花板。 喂了不相关文档,模型会自信地用不相关信息回答——它不知道 context 是垃圾,只是尽力而为。
有人一辈子只做检索。—— Bri Kopecki
两种视角的张力 ⚠️
本 wiki 两个源对 RAG 的态度不冲突,但视角不同——记下以备后续 lint。
| Karpathy (LLM Wiki gist) | IBM (Bri Kopecki) | |
|---|---|---|
| 关注层 | 知识结构 | 生产实现 |
| 态度 | 反例:RAG 无累积,每次重新发现 | 中性:RAG 是 agent 工程的核心专业 |
| 替代方案 | LLM-Wiki 预编译模式 | 提升检索质量(chunk/embed/rerank) |
| 隐含规模假设 | ~100 源,个人/小团队 | 生产 agent,任意规模 |
调和:两人在不同问题上都对。
- 个人知识库、需要综述与累积 → 用 LLM-Wiki
- 生产 agent、要从大规模文档现场答用户问题 → RAG 仍是必经之路
- 二者并非互斥:也可以用 LLM Wiki 模式管理沉淀,RAG 处理日常查询
与 LLM-Wiki 的对比
| 维度 | RAG | LLM Wiki |
|---|---|---|
| 知识状态 | 每次查询临时拼接 | 持续编译累积 |
| 综述 | 现场凑 | 已沉淀 |
| 矛盾标注 | 看不见 | 已显式标记 |
| 维护成本 | 零(因为不维护) | LLM 承担 |
| 工程依赖 | 向量库、embedding、rerank | 纯 markdown + git |
| 适用规模 | 任意 | ~100 源量级 |
与 Agents 的关系
RAG 是 agent 工程 7 项技能里的第 3 项。"检索质量 = agent 性能上限" 这个论断把 RAG 从"工程细节"提到了"生产瓶颈"的地位。
待补
- Hybrid search(向量 + BM25 / 关键词)实践
- GraphRAG / agentic retrieval / self-RAG 等高级变体
- 具体的 chunking 策略(语义切分、滑动窗口、文档结构感知)
- 评估 RAG 质量的指标(recall@k、faithfulness、answer relevance)
- 何时 RAG 仍是更优解 vs 何时该换微调/工具调用/LLM-Wiki
- 本地方案(eg qmd)与云方案的取舍
等专门讲 RAG 工程的源 ingest 后再写。