你的知识库不到 100 万 Token，上什么 RAG？

• 一、RAG 的真相：48% 的失败率被藏起来了
• 二、Context Window 革命：1M 已成标配
• 三、Wiki 模式：不是复古，是重新对齐
• 四、六维度拆解：RAG 和 Wiki 到底差在哪
• 五、决策框架：什么时候选什么
• 六、收束：误区、行动建议、一句话结论

本文首发地址 https://h89.cn/archives/620.html

2024 年，每个做 AI 知识库的人都在说 RAG。检索增强生成，Retrieval-Augmented Generation，这串字母组合几乎成了企业知识管理的唯一答案。搭一个向量数据库，把文档切成块，灌进 Embedding 模型，再套个重排器——恭喜你，拥有了一个"AI 驱动"的知识库。

但 2026 年 4 月，OpenAI 联合创始人 Andrej Karpathy 发了一条 X 帖子，描述自己怎么用一组 Markdown 文件替代了整个 RAG 管线。48 小时内，1600 万人围观。他放出的 GitHub Gist 零代码，收获了 5000 多个 star。

这件事说明一个问题：很多团队用 RAG，不是因为需要，而是因为不知道还有别的选项。

我想聊的不是"RAG 好不好"。RAG 当然好——在合适的场景下。我想聊的是：你的知识库真的大到需要 RAG 吗？

一、RAG 的真相：48% 的失败率被藏起来了

先说一个让人不舒服的数字。

2025 年一篇 arXiv 论文 对政府文档的 QA 任务做了误差分析。结果发现，48% 的 RAG 错误答案，根源不是模型胡说八道，而是检索阶段就漏掉了关键证据——所谓"黄金块"（golden chunk）根本没有出现在 top-k 检索结果里。

模型本身没问题。它拿到了错误的材料，只能基于错误的材料编答案。

这不是孤例。另一项 研究 显示，当关键信息位于文档中间位置（而非开头或结尾）时，GPT-3.5-Turbo 的多文档 QA 性能下降超过 20%。同一项研究还表明，同一主题内的不相关内容混进检索结果，能让 LLM 的生成准确率再掉 10% 以上。

也就是说，你花了三个月搭的 RAG 管线——向量数据库、Embedding 模型、重排器、监控面板——可能有近一半的问题出在检索器上。而检索器的问题，换个思路可能根本不存在。

更糟的是切片（chunking）。文档切多大合适？切太小，上下文断裂，一个句子失去段落的背景；切太大，检索效率下降，关键匹配被淹没。没有统一最优解，每换一次文档格式就要重新调参。我见过有团队为了调 chunk size 开了三次会，最后发现还不如把整篇文档直接塞给模型。

哦对了，RAG 还有隐性成本。Embedding API 调用、向量数据库存储、索引重建、检索管线监控。一个 10 人团队的 RAG 系统，仅基础设施月运维成本就在 500 到 2000 美元之间。这还没算调参的人力。

二、Context Window 革命：1M 已成标配

Context window，上下文窗口，指的是模型一次能"看"多少 Token。2022 年底 GPT-3.5 只有 4K，2024 年初 Gemini 1.5 Pro 跳到 1M。2026 年 3 月，Anthropic 发布 Claude Opus 4.7，1M 窗口按标准 API 定价卖，明确取消了长上下文溢价。（callmissed.com）

换成人话：1M Token 不再是卖给大客户的增值功能，是买模型就送的标配。

看一组数字：

3.5 年内从 4K 到 1M，扩展了 250 倍。2026 年的新模型已经默认把 1M 当起点。

1M Token 能装什么？约 75 万英文单词，相当于 1500 页密集文本。或者 3-5 万行代码的完整代码库。或者一年的邮件往来。（verticalapi.com）

但窗口大小不等于可用大小。 广告里的 1M 是"能装"，不是"能读懂"。多个独立评测显示，实际可用窗口约为广告最大值的 60% 到 80%。在 500K Token 位置的 needle-in-haystack 测试（在一堆文本里找一根"针"）中，Claude 4.7 准确率 97%，Gemini 2.5 是 98%，GPT-5 只有 89%——掉了 11%。（web3aiblog.com）

直说吧：如果你的知识库在 100K 到 1M Token 之间（约 200 到 1500 页），2026 年的主流模型可以直接全量加载，召回率 85% 以上。 这时候上 RAG，等于给自己制造一个 48% 概率出错的检索层，然后祈祷它别坏。

三、Wiki 模式：不是复古，是重新对齐

Karpathy 的做法很简单：一个 raw/ 目录放原始素材，一个 wiki/ 目录放 LLM 编译的 Markdown 文件（含摘要、反向链接、概念分类），再加一个 CLAUDE.md 规定 LLM 怎么操作。

没有向量数据库。没有 Embedding。没有分片。

他围绕单一主题的个人研究 Wiki 累积了 100 篇文章、40 万字，比大多数博士论文还长。然而这些内容几乎没有一篇是他直接写出来的。（preuve.ai）

这模式不是"复古"，而是把 context window 当硬盘用。传统 Naive RAG 每次查询都从零开始翻书找答案（Agentic RAG 和 prompt caching 能缓解，但系统更复杂）。LLM Wiki 直接把书读进脑子里，读完后还能写读书笔记——知识越用越厚，第 50 个来源比第 1 个更有价值。

对比一下成本。传统企业知识图谱（OWL/SPARQL 时代）前期投资 1000 万到 2000 万美元，专家劳动数年，生产部署率仅 27%。（Pebblous）Karpathy 模式呢？一个文件夹的 Markdown 文件，加上你已经在付钱的 LLM API。

Wiki 不是万能的。但太多团队拿着电钻去拧眼镜螺丝，还觉得自己在搞工程。

四、六维度拆解：RAG 和 Wiki 到底差在哪

这张表里最刺痛的一行是"年运维成本"。RAG 方案需要有人管向量数据库、调切片参数、监控索引健康。Wiki 方案呢？改完文件 git commit 就行。

单次查询成本的差距没有想象中大——RAG 约 $1.65（按 Pinecone 存储 + GPT-5 API + Embedding 检索开销粗略估算），Wiki 直接加载用 Gemini 是 $1.25，用 Claude 是 $3-5。国产 1M 模型价格极具竞争力：Flash 级（Qwen3.5 Flash $0.10/M、DeepSeek V4 Flash 和 MiMo V2.5 各 $0.14/M）比 Gemini 便宜近 9 倍；Pro 级（DeepSeek V4 Pro $0.42/M、MiMo V2.5 Pro $0.42/M）也远低于 Claude（[rival.tips](https://www.rival.tips/compare/qwen3.5-flash-02-23/qwen3.7-max)、[devtk.ai](https://devtk.ai/en/models/deepseek-v4-flash/)、[pricepertoken.com](https://pricepertoken.com/pricing-page/model/xiaomi-mimo-v2.5)）。如果知识库在 200K 以内，Kimi K2.6（256K 窗口，$0.95/M）也够用。

但上面这些数字还不是真正的差距。 Wiki 模式每次查询都加载同一批知识库内容，国产模型（DeepSeek、MiMo）的缓存命中价只有未命中的 1/50——¥0.02/M（约 $0.003/M）。实际使用中，知识库作为固定前缀加载，绝大部分查询都会命中缓存，知识库部分的成本接近 $0.003/M 而非 $0.14/M。RAG 呢？每次查询都要重新做 Embedding 检索和向量搜索，没有缓存红利。

真正的差异不是"单次查询便宜多少"，而是Wiki 的成本结构简单到不需要专门的人维护。

五、决策框架：什么时候选什么

选 Wiki 的信号：

1. 总规模 < 50万-100万 Token，范围明确。注意是 Token 数，不是文档数——1000 篇 FAQ（每篇 500 Token）只有 50万 Token，可全量加载；100 篇技术白皮书（每篇 2万 Token）已达 200万 Token，必须 RAG。
2. 检索精确度比召回率更重要。政策条款、定价层级、无歧义流程——向量相似度搜索是概率性的，只能找到"可能相关"的块。
3. 内容高度结构化。Markdown 的标题、列表、表格携带的语义信息，纯 Embedding 会丢失。
4. 需要 Git 版本控制和审计链。向量数据库的更新策略是黑盒。
5. 工程资源有限。低代码/无代码团队别碰 RAG。

选 RAG 的信号：

1. 总规模 > 100万 Token，无法装入单次上下文的有效召回范围。
2. 查询不可预测、开放式。用户可能问任何问题，你事先不知道哪些文档相关。
3. 内容密集、非结构化。法律合同、研究论文、支持工单历史——这些内容本身就不自然地被划分为可检索单元。
4. 跨异构数据源检索。PDF + HTML + Notion + Slack 线程，统一向量索引提供单一搜索面。
5. 内容变化频繁，需要增量索引。

混合模式：

结构化知识（政策、流程、产品规格）走 Wiki，大型非结构化档案（历史工单、研究文档）走 RAG。Wiki 处理确定性查询，RAG 处理长尾。一个经验法则是"80/20 分割"（结构化知识占 80%，RAG 处理 20% 长尾），但目前缺乏大规模生产环境的独立验证，务实做法是：先让 Wiki 承担确定性知识，当查询覆盖范围明显超出 Wiki 容量时再引入 RAG。

六、收束：误区、行动建议、一句话结论

四个常见误区，快速过：

1. "RAG 一定比 Wiki 先进"——对于 <100万 Token 的知识库，Wiki 构建更快、运行更便宜、更精确。Karpathy 的 Gist 零代码收获 5000 stars，说明开发者社区对简单方案的渴望是真实的。
2. "Wiki 能省 95% Token"——这是相对于"把所有完整文档无脑加载"的对比。与调优良好的 RAG 对比，差距没那么大。但大型 Wiki 反而可能比 RAG 更贵——比如 50万 Token 的 Wiki 用 Claude Opus 4.7（$5/M）单次 $2.5，超过 RAG 的 $1.65；但换成 Qwen3.5 Flash（$0.10/M）则只需 $0.05，别盲目迷信任何一方。
3. 忽视隐性成本——综合计算后，RAG 与 Wiki 的 API 费用价差并不如表面看起来那么大。真正的差异在运维人力：RAG 需要有人管，Wiki 不需要。
4. "知识库 = 问答系统"——传统 RAG 只做问答。LLM Wiki 的价值在于知识复利——每次摄入新素材都交叉引用已有内容。

今天就能做的 3 步：

1. 数 Token。把文档丢进 tokenizer 跑一遍，别凭感觉。中文按 1 字 ≈ 1-1.5 Token 估算。
2. 试 Wiki。扔一组 Markdown 文件进 Claude、Gemini、DeepSeek、Qwen 或 Kimi，问 20 个常见问题，看回答质量。
3. 再决定。只有当 Wiki 开始漏信息时，才考虑引入 RAG。别反过来——先假设你需要 RAG，再想办法证明。

最后一句话：

2024 年，不上 RAG 显得你落伍。2026 年，盲目上 RAG 显得你没算过账。先数清楚你的知识库有多少 Token——如果不到 100 万，那个向量数据库可能根本不该存在。

参考链接：

1. Exploring One-shot vs. Iterative Retrieval Strategies for RAG, arXiv:2509.04820v1, 2025
2. When Graph Meets Retrieval Augmented Generation for Wireless Networks, arXiv:2412.07189, 2024（无线网络领域案例，文中引用的是其关于上下文位置与不相关内容对 RAG 精度影响的通用发现）
3. Context Window 2026: 1M to 10M Tokens, callmissed.com, 2026-05-08
4. DeepSeek V4 Flash API Pricing, devtk.ai, 2026-05-31
5. MiMo V2.5 API Pricing, pricepertoken.com, 2026-06-05
6. Qwen3.5 Flash vs Qwen3.7 Max, rival.tips, 2026-05-22
7. LLM Context Window Comparison (2026), verticalapi.com, 2026-05-04
8. Claude 4.7 vs GPT-5 vs Gemini 2.5 Deep Think, web3aiblog.com, 2026-05-06
9. AI Memory Systems Statistics You Need to Know in 2026, preuve.ai, 2026-05-04
10. LLMs That Compile Knowledge, Pebblous, 2026-04-05