黄益贺 2024-03 → 2026-05 的 RAG(检索增强生成)实战。本 wiki 是基于精华帖 + 跨桶交叉素材的 v1 版本;完整全量(341 帖)留待后续 session 升级 v2。
何时打开:
- 你想搭知识库,卡在 chunk size / embedding 模型选择
- 你用 RAG 但回答总是不准,怀疑是工具问题
- 你听过 GraphRAG / LightRAG / Contextual Retrieval,不知道值不值得用
- 你想理解 RAG 为啥逐渐被 NotebookLM / Long Context 模型替代
0. RAG 演化时间线(老黄视角)
graph LR
A["2024-03~05<br/>RAG 入门<br/>AnythingLLM 默认 LanceDB +<br/>nomic-embed-text"] --> B["2024-06~07<br/>GraphRAG 风暴<br/>但成本极高 $11/问<br/>(帖 360)"]
B --> C["2024-04~05<br/>Cohere Command R+<br/>(RAG 增强模型,帖 62)"]
C --> D["2025-02~03<br/>老黄做老黄项目<br/>用 Pinecone→pgvector<br/>(早期套壳)"]
D --> E["2025-04<br/>Milvus 本地 + MCP<br/>'数据库 + 模型分离'<br/>(帖 1083)"]
E --> F["2025-08<br/>Obsidian + Claude<br/>+ 自家 Obsidian MCP"]
F --> G["2026-01<br/>终态:自己→Obsidian<br/>别人→NotebookLM<br/>(帖 2201)"]
1. RAG 基础原理(老黄科普版,帖 36)
老黄 2024-03 给 RAG 写的"大白话":
"大模型对文档的处理,简单来说就是先进行 切割。比如每 1000 个 token 切一块。否则,文档太大了,大模型处理不了。这些切割好的 文本块 会被储存起来。
当你提出一个问题之后,大模型会根据 语义进行检索,找到匹配的文本块。这些文本块会作为参考信息,连同你的问题一起给到大模型,最终给出答案。
所以,如果文档里的内容含混不清,那肯定会影响大模型的回答质量。我都是尽量把文档手动改成简单的形式,比如一个概念或问题对应一个答案。"
核心步骤:
- 切块(chunk size + overlap)
- 嵌入(Embedding 模型把文本变向量)
- 存(向量数据库)
- 检索(语义匹配 + 可选全文搜索)
- 拼回 Prompt(检索结果 + 用户问题 → 模型)
- 模型生成回答(必要时附 citation)
2. RAG 优化 5 个关键点
2.1 文档预处理(最重要)
- PDF → Markdown(用 Marker / MinerU / Markitdown / 微软 markitdown-mcp)
- PPT 不建议直接用(视觉逻辑模型理解不了)→ 把每页文字单独写下来
- Excel 慎用(结构化数据 RAG 处理弱)
- 每节自包含 + 明确边界(模糊文档 RAG 一定崩)
2.2 Chunk Size + Overlap
- 默认 1000-token chunk 一般 OK
- 太小 → 切断语义,LightRAG 帖 864 提到这是常见问题
- 太大 → 检索精度下降,模型 Context 受限
2.3 Embedding 模型选型
| 场景 | 推荐 |
|---|---|
| 中文 + 本地 | nomic-embed-text / mxbai-embed-large |
| 多语言 + 高精度 | OpenAI text-embedding-3-large |
| 中文 + 云端 | OpenAI 3-large 同样 OK |
| 不要默认 | AnythingLLM 默认嵌入有时下载失败(fetch failed) |
2.4 模型推理能力是天花板(帖 1076 关键洞察)
实测(用户提交):
- 公网 Qwen Max:正确率高
- 本地 DeepSeek 70B / Qwen 2.5 70B:正确率不高
老黄解释:
"模型综合能力天壤之别。Qwen Max 的训练资源、推理资源远超本地运行的量化版本。它在指令遵循能力强得多。70B 的开源模型 容易偏离给定上下文,或依赖内部知识而非检索到的信息。
另外,Qwen Max 在 理解上下文细微差别、整合多个检索片段、处理矛盾信息、容忍上下文质量不完美 方面也有更强的能力。"
结论: 7B-14B 本地模型在 RAG 场景很弱。先用 GPT-4 验证流程,再降到本地。
2.5 RAG 不是万能(老黄的反复警告)
"目前这些应用所使用的 RAG 技术,对于 需要全局理解之类的问题,回答效果都不好,这个没办法。我个人使用的时候,只会把 QA、局部文字包含完整意思的文档(例如笔记)放到知识库里。"
RAG 致命弱点:
- 全局问题(比如"这篇文章主旨")→ RAG 只看片段,答不准
- 跨段落推理 → 检索可能漏关键片段
- 表格 / 图表 → RAG 处理弱
3. GraphRAG:贵但有用(2024-07 帖 358, 360 精华)
优势: 全局性问题 处理强(比如"这本书主旨是什么")。
致命缺点(2024-07): 成本极高。
- 单文档 + 单次问答 = $11(用 OpenAI API)
- 老黄试图接本地 Ollama,但 嵌入环节总报错
何时用: 需要全局理解 + 不在乎成本(企业级深度调研)。
何时不用: 个人知识库 / 频繁问答场景。
4. Cohere Command R+:第一个 RAG 增强模型(2024-04 帖 62 精华)
特点:
- 1040 亿参数
- 支持英文 / 中文 / 法文 / 德文等 10 种语言
- 对 RAG 做深度强化,减少幻觉
- 性能仅次于 GPT-4 Turbo,高于市面多数开源模型
- 成本大幅降低
Why 是个里程碑: 第一个明确为 RAG 设计的开放权重模型。后续的 Llama-3-ChatQA(NVIDIA 微调)、Gemini Long Context 都走类似路径。
详见 newtype · AI 工具栈实战与演化 §3 前端聊天层 — AnythingLLM 2024-05 加 Cohere API。
5. 老黄的"Milvus + MCP" 自建知识库(2025-04 帖 1083 关键)
思路:
- 把文档存进 Milvus,本地向量化
- 通过 Milvus MCP,任意 AI 客户端(Cursor / Claude Desktop / ChatWise)都可以访问
Why 这个组合好:
"这比之前的方案都更灵活,因为 把数据库和模型分开了。模型端可以随意更换,只要能调用 MCP 就可以接入。"
对比"传统 RAG 应用(AnythingLLM 等)":
| 维度 | 传统应用 | Milvus + MCP |
|---|---|---|
| 数据库 + 模型耦合 | 是 | 解耦 |
| 模型切换 | 应用支持哪些就哪些 | 任意 LLM 通过 MCP 接入 |
| 多客户端共享 | 不行 | OK |
| 升级模型代价 | 改应用 | 0 |
关联: 这也是 OpenMemory MCP(帖 1338)的同源思想。详见 newtype · MCP 协议与生态实战 §3.2 知识库/记忆类 MCP。
6. AI 编程工具的代码检索方式(对 RAG 启发,2025-06 帖 1392)
| 工具 | 方式 | 优 / 缺 |
|---|---|---|
| Cline | 实时搜索(文件内容 + 正则) | 准 + 实时 / Token 高 |
| Claude Code | Agentic Search(动态决定内容/文件名/多轮) | 准确性最高 / Token 更高 |
| Cursor | 经典 Embeddings + RAG | 性价比高 / Embedding 理解力受限 |
| WindSurf | 同 Cursor 但低延迟 + 企业 | 企业级 / 初始索引慢 |
Cline 拒绝 RAG 的理由:
"一个函数,定义在 200 行,调用在 300 行,相关依赖在 400 行。RAG 只能读取片段,打断了逻辑,所以并不适用。"
对个人 RAG 的启发:
- 处理代码类、强结构化文档 → 实时搜索可能比 RAG 好
- 处理短笔记、QA 形式 → RAG 适用
- 跨片段推理 → 优先 Long Context 模型(Gemini 1M+)
7. 老黄 RAG 工具评价(各时期)
2024 早期(2024-03~05)
| 工具 | 评价 |
|---|---|
| AnythingLLM | 入门首选,RAG 效果一般,Agent 功能初级(帖 449) |
| Open WebUI + Ollama | 自带 RAG,简单场景够用 |
| QAnything(网易有道) | 云端版好用,本地部署痛苦(用 WSL 搞好久放弃)(帖 60 精华) |
2024 中期(2024-06~08)
| 工具 | 评价 |
|---|---|
| GraphRAG | 全局问答强但 $11/问,本地接 Ollama 部分有 bug |
| MaxKB | 适合企业内训,iPanel 一键安装(帖 149) |
| RAGFlow | 文档解析多样,效果优于 AnythingLLM(帖 490 用户对比) |
2025 前半(2025-01~04)
| 工具 | 评价 |
|---|---|
| AnythingLLM | "降为备用,主要用 ChatWise / Obsidian"(帖 1176) |
| Obsidian Copilot | 主推 + 本地配置(LM Studio localhost:1234) |
| Milvus + MCP | 老黄自建方案(帖 1083) |
| 秘塔搜索 + 专题 | 团队/RAG as Service(帖 646) |
2026 终态(2026-01 帖 2201)
自己的东西 → Obsidian(local-first) 别人的东西 → NotebookLM(Source-Grounding 严格不胡说)
详见 newtype · AI 工具栈实战与演化 §4 知识库层。
8. 老黄的"AI 知识库系统"哲学(2024-05 帖 147 精华)
老黄给学员的"个人知识库系统"完整思路:
出发点 + 解法
- 信息过载 → AI 辅助总结提炼,快速大致掌握
- 人脑不适合记东西 → "第二大脑 / Second Brain" 存储 + AI 语义检索
- 记笔记是预处理 → 自己手敲信息才会内化
两套子系统
1) 外部信息处理(AnythingLLM + 大模型,2024 期)/ Obsidian MCP + Claude(2025 后)
- 像 "屠宰场":把日常信息丢进去,用大模型这把"刀"做"肢解"
- 有价值的内容手动放到笔记里(必须自己敲字)
- 专业资料用专业工具(如 txyz.ai 处理 AI 论文)
2) 笔记生成(Obsidian + 插件)
- 按 PAFP 逻辑建 4 个文件夹 + 子文件夹
- 用 3 层关联:文件夹 + 标签 + 笔记互链
- 形成 知识图谱,而非散点
核心心法:
"持续地把外部信息源源不断转化成我自己的东西。这种逐渐积累、内化的感觉,是非常让人欣喜的。"
详见 newtype 知识系统与 Life OS 全演化(待写,Phase 1.1 wiki #9)。
9. RAG vs Long Context vs NotebookLM(2025-2026 演化)
三种知识接入方式的对比:
| 方式 | 容量 | 适合 |
|---|---|---|
| RAG | 任意大(分块存) | 局部精确检索,但全局弱 |
| Long Context(Gemini 1M+) | 1M tokens(一本书) | 全局推理强,但成本随长度涨 |
| NotebookLM | 50-300 文档 / 笔记本 | Source-Grounding 不胡说,平衡 |
老黄的选择(2026-01):
- 自己笔记 < 100MB → 直接 Obsidian + Copilot/MCP,够用
- 别人资料 / 论文 → NotebookLM(免费版 50 个文档,高级版 300)
- 真正大型 → Gemini Pro(1M Context)直接喂
RAG 在哪里仍然有价值:
- 文档总量超 Long Context 上限(几百万 token)
- 多 Tenant 隔离(每用户独立 RAG 库)
- 频繁更新的实时索引
10. 反 pattern
| ❌ | ✅ |
|---|---|
| RAG 完美主义(找最强 Embedding/最佳 chunk size) | 先跑通 GPT-4 + 默认配置,再降级优化 |
| 文档堆海(几千 PDF 直接入库) | 挑选 + 预处理 + 改 Markdown 形式 |
| 7B 模型期待 GPT-4 效果 | 模型推理力是天花板,先用 GPT-4 验证 |
| 用 GraphRAG 个人场景 | 太贵,Source-Grounded NotebookLM 替代 |
| 知识库塞所有信息 | 只塞 QA 形式 + 自包含 + 高质量 内容 |
| RAG 期待全局推理 | 全局问题用 Long Context 或 GraphRAG |
| 数据库 + 模型耦合 | Milvus + MCP 解耦,任意 LLM 接入 |
| 处理代码用 RAG | Cline 实时搜索 / Claude Code Agentic Search 更准 |
| 不用 citation 校验 | 必看引用对不对,RAG 错很难自检 |
| 把"装好 RAG 工具"当目标 | 知识库的本质是 知识本身,工具只是承载 |
引用与延伸
主要引用: rag-knowledge 主题桶相关精华帖 + 跨桶素材。精华帖号:36, 60, 62, 147, 149, 198, 212, 215, 234, 290, 300, 358, 360, 444, 445, 449, 469, 481, 483, 488, 490, 510, 535, 573, 580, 593, 612, 614, 646, 673, 715, 717, 724, 731, 764, 770, 772, 777, 786, 791, 794, 795, 824, 830, 831, 836, 838, 841, 854, 874, 878, 882, 883, 886, 893, 895, 932, 1037, 1071, 1076, 1083, 1085, 1147, 1150, 1154, 1336, 1392, 1495, 1626, 1700, 2074, 2148, 2201 等。
注: 本 wiki 为 v1 版本,基于跨桶精华素材整合(已 Read 桶:mcp + prompt-engineering + tools-stack + ai-coding,内含 RAG 相关内容约 70%)。完整 v2 版本需后续 session Read bucket-rag-knowledge.md(249KB / 341 帖)全文 + supp-rag-knowledge.md(317 帖)非精华部分。
配套 wiki:
- newtype · MCP 协议与生态实战 — Milvus MCP / OpenMemory MCP / 知识库 MCP 接入
- newtype · AI 工具栈实战与演化 — AnythingLLM / Open WebUI / RAGFlow / NotebookLM 工具评价
- newtype · AI Coding 实战与工具栈演化 — Cursor / Cline / Claude Code 检索方式
- (TODO)newtype 知识系统与 Life OS 全演化 — Obsidian 笔记系统完整方案
- (TODO)newtype 模型评测、微调与硬件演化 — Embedding 模型评测 / RAG 模型(Command R+/ChatQA)
History
- 2026-05-16 v1.0 创建 — Phase 1.1 wiki #8 v1 版。基于精华帖 + 跨桶交叉素材整合。完整全量(rag-knowledge 桶 341 帖)留 v2 升级。