研究报告 · 约 24,541 字 · 预计推送 3 部分

个人知识库方案对比：RAG vs 知识图谱 vs 长上下文 未开始

目录

题记与说明

横纵综合报告 | 时间截面：2026-10-28

成文说明：本文由两份章节研究综合而成——纵轴《从诞生到当下的发展历程》与横轴《横向对比》。两份源章节存于同目录 parts/ 文件夹：原纵轴章节为 2026-10-28-个人知识库方案对比-RAG-知识图谱-长上下文-vertical.md，原横轴章节为 2026-10-28-个人知识库方案对比-RAG-知识图谱-长上下文-horizontal.md；下文"原纵轴章节/原横轴章节"均指这两份源文件，与本报告自身的"纵轴/横轴"两章相区分。两章均基于 2026-10-28 当日的实时网络检索写成，关键事实附来源 URL；部分量化数字（token 开销、硬件盈亏平衡点、个别工具的发布月份）来自搜索引擎对多来源的综合摘要，已标注"约"或"转述"，引用时应视为量级参考而非精确值。两章之间的矛盾与重复已在综合时消解，消解过程在"交叉洞察"末节透明列出。本文是文献级横评，未实际搭建环境做端到端复测。

TL;DR

截至 2026 年 10 月，"RAG 已死"已被证伪——死掉的只是单轮朴素向量 RAG。三条路线并非互斥，而是按语料规模、隐私与问题类型分层组合：长上下文适合小语料直读，但有效窗口低于标称值，本地基本不可行；向量 RAG 是工作马，桌面工具已把门槛降到"装个软件"级；知识图谱在多跳关系与全局总结上不可替代，但建图昂贵，个人宜用 LightRAG，正以"记忆层"身份复活。每次窗口扩大都引发"检索已死"论战，又都被有效性与成本证据拉回。行动建议：小语料先用云端长上下文（NotebookLM）；中等规模或隐私敏感上本地/混合 RAG；只有全局问题与跨会话记忆才值得上图；用 MCP 把知识库做成服务，混合路由兜底。

纵轴：发展脉络

0. 课题界定

"个人知识库"指个人开发者/知识工作者将私有文档（笔记、书摘、聊天记录、代码、PDF）喂给 LLM，使其可被检索、问答与推理的系统。三条技术路线构成课题主体：

纵轴部分要回答的问题是：这三者不是并列的替代品，而是一条相互挤压、彼此吸收的演化史——它们各自如何走到 2026 年的位置。

1. 史前铺垫（2012–2019）：三条线各自埋下伏笔

主要参与者：Google（知识图谱）、FAIR/DeepMind（检索）、Roam 社区（个人知识管理）。驱动因素：LLM 出现之前，"把知识注入模型"只有微调或检索两条路，而个人用户既不会微调也没有训练数据；Roam 证明了一个事实——个人笔记天然就是"图"而非"文档流"，这为图谱路线后来在个人场景的复兴埋下伏笔。

2. 诞生（2020–2022.11）：RAG 论文定义了问题

主要参与者：FAIR（RAG）、Columbia/UW（DPR）、Obsidian 团队（Shida Li/Erica Xu）、向量数据库创业公司。此阶段三条线尚无交集：图谱在工业界，检索在学术界，长上下文在体系结构论文里，"个人知识库"还只是 PKM 社区的事。

3. 爆发（2022.11–2023）：RAG 成为默认方案，本地分支诞生

主要参与者：OpenAI、Anthropic、LangChain/LlamaIndex、向量数据库阵营、Ollama/llama.cpp 社区、Google Labs。驱动因素：隐私（个人笔记不想上传）、API 成本（128K 全量塞入太贵）、幻觉（需要 grounding）。r/LocalLLaMA 与 Hacker News 成为个人级方案的主要策源地。此阶段格局：RAG = 唯一主流，图谱与长上下文只是背景板。

4. 分化（2024）："RAG 已死？"论战与图谱 RAG 的反击

主要参与者：Google DeepMind、Microsoft Research、NVIDIA、Anthropic、HKUDS/OSU（学术图谱派）、Letta/Mem0/Zep（记忆层创业）。驱动因素：128K 成为开源标配 → "还需要 RAG 吗"必须回答；向量检索对多跳、关系型、全局性问题先天弱 → 图谱派找到突破口；GraphRAG 索引成本高 → 催生轻量化变体。三条路线从"默认/边缘/真空"变成"各自拥有明确的最优场景"。

5. 融合与智能体化（2025–2026.10）：context engineering 与个人级平价化

主要参与者：Anthropic（MCP/context engineering）、OpenAI（开源转向）、DeepSeek（价格锚）、Meta/Google/Qwen（窗口军备）、Zep/Mem0/Letta（记忆层）。驱动因素：token 价格暴跌、推理模型让"多轮 agentic 检索"可控、MCP 把知识库从管道变成生态位。

6. 三条路线的状态速览（时间维度）

时点向量 RAG知识图谱 RAG长上下文直读
2020 年仅论文，无个人工具与 LLM 无关512–4K，不可用
2023 年默认方案，工具链爆发几乎无人用于个人库128K 但按 token 计费，成本高
2026 年底座方案，被 agent 调度收窄为"全局问答 + 时序记忆"（LightRAG/Zep）小语料首选；大语料受有效窗口制约

（成本与效果的细节对比见下文横轴部分，此处不再重复。）

横轴：横向对比（2026-10 截面）

1. 对比对象的界定：三条路线 + 一层"产品化替代品"

  1. RAG 路线（含其图谱化变体）：LlamaIndex、LangChain 等框架；面向个人的成品——AnythingLLM、Cherry Studio、RAGFlow、Dify、FastGPT、Khoj、Obsidian Copilot 插件。
  2. 知识图谱路线：Microsoft GraphRAG、LightRAG、nano-graphrag 等建图检索方案；以及面向智能体记忆的时序知识图谱——Zep/Graphiti（基于 Neo4j）、Mem0（向量+实体混合）。
  3. 长上下文路线：云端 frontier 模型（Gemini 3 / 3.1 Pro 的 1M 窗口、Gemini 3 Ultra 的 2M、GPT-5.5、Claude Opus 4.8 等）；本地开源模型的长上下文形态（Llama 3.1 全系 128K（ZDNet）、Qwen3 原生 32K/YaRN 扩展 128K）；以及把这层能力产品化的 NotebookLM。
  4. 产品化替代品（"不自建"选项）：NotebookLM（云端源锚定问答）、Open Notebook（自托管开源 NotebookLM 替代）、Reor（全本地 AI 笔记）等。

2. 检索效果：各自的真实边界

表 1：三条路线的能力对比

维度RAG（向量/混合检索）知识图谱（GraphRAG 一族）长上下文（直接塞入）
单跳事实问答✅ 强（混合检索下很稳）✅ 强✅ 强（短窗口内）
多跳关系推理（A 和 C 通过谁关联？）⚠️ 弱项，需多轮 agentic 检索弥补✅ 不可替代的优势（子图遍历）⚠️ 理论可行，实际受有效上下文限制
全局主题总结（"我的笔记整体在关心什么？"）❌ 朴素 RAG 做不到，需 Map-Reduce✅ 社区摘要（community summary）专为此设计⚠️ 语料塞得下就行，但成本高
增量更新✅ 加一条嵌一条，近乎实时⚠️ 需重抽实体/改图，GraphRAG 增量索引仍较重⚠️ 每次会话重新塞入（prompt caching 可缓解）
可溯源/可解释✅ 引用原文片段✅ 引用实体+关系+原文❌ 整段上下文，溯源粒度差
对脏数据（扫描件/表格）鲁棒性⚠️ 取决于解析器（RAGFlow 最强）⚠️ 抽取错误会污染图✅ 交给模型自己读，反而最鲁棒
有效规模上限✅ 几乎无限（检索层可扩展）⚠️ 图规模大后遍历和摘要成本上升❌ 受窗口限制；个人十年笔记量级（数百万 token）已超限

来源：RAG vs 长上下文的系统性研究结论见 SELF-ROUTE（arXiv:2407.16833，GoPenAI 解读——小语料长上下文更优、大规模 RAG 更省的混合策略）；GraphRAG 社区摘要与全局检索机制见 DataStudios 的机制拆解；GraphRAG 在关系型问题上优势的从业者讨论见 Reddit r/Rag。

三项关键事实展开：

3. 成本：本地部署成本 + 维护成本，门槛差一个数量级

表 2：成本对比

成本项RAG知识图谱长上下文
本地硬件门槛（最低可用）无 GPU 可跑：16GB 内存机器 + CPU 嵌入（BGE-M3）+ 云 API；仅当"生成也全本地"才需 24GB 显存跑 32B 级模型同左 + 建图阶段额外消耗大量 LLM token（本地跑抽取会很慢）云端：0（订阅制）；本地长上下文基本不可行——本地模型标称 32K–128K，且小参数模型的有效上下文缩水更严重
代表性配置AnythingLLM/Cherry Studio：桌面安装包，零 Docker；RAGFlow：最低 4 核 16GB 内存 + 50GB 磁盘 + Docker（内含 ES/MinIO/MySQL/Redis），推荐 8 核 32G（搭建门槛）LightRAG：单 Python 服务，可配本地 Ollama 模型建图；Microsoft GraphRAG：Python 管道 + 大量 API 调用NotebookLM：免费；Gemini Advanced $19.99/月；Gemini Ultra $249/月解锁 2M 窗口
建库/索引成本（API 计费）极低：普通向量嵌入约 $0.50/百万 token 量级高：Microsoft GraphRAG 全量索引约 $50/百万 token（GPT-4 级），实测案例：6 小时约 $80；LightRAG 比完整 GraphRAG 快 3–5 倍、便宜 50–70%（检索摘要转述）0（无建库），但首次塞入即按输入 token 计费；长上下文阶梯定价下单个 500K-token 请求成本显著上浮
查询成本低：检索 + 数 K token 注入GraphRAG 全局搜索单次可达 610K+ token，LightRAG 压到 <100 token/查询（MemoryHub 2025 分析，检索摘要转述）最高：每次查询重复支付全部语料的输入 token；prompt caching 可部分缓解
维护成本（个人视角）低：换模型需重嵌（换嵌入模型 = 全量重建索引）；一体化工具基本免维护高：图 schema、实体消歧、增量更新都是持续工作；社区共识"图可能比答案更贵"最低：无管道可维护；但语料增长会不断逼近窗口和预算上限
本地 GPU 一次性投入（纯本地路线）二手 RTX 3090（24GB）约 $700，或 AMD 7900 XTX / Intel Arc Pro B70（32GB）；Qwen3-32B 常见量化约需 19–20GB 显存（检索摘要转述）同左，且抽取阶段对显存/时长要求更高不适用

三条要点展开：

4. 生态与产品化替代品（2026-10 截面）

表 3：生态与成熟度

路线代表工具部署形态成熟度
RAGAnythingLLM、Cherry Studio、RAGFlow、Dify、FastGPT、Khoj、Obsidian Copilot桌面安装包 / Docker★★★★★ 最成熟，工具密度最高；中文社区对比丰富（知乎选型讨论、CSDN 四工具对比、掘金五工具部署对比）
知识图谱Microsoft GraphRAG、LightRAG、nano-graphrag；智能体记忆方向：Mem0、Zep/Graphiti（时序 KG，基于 Neo4j，Community 版单机无集群）、LettaPython 管道 / 图数据库（Neo4j）★★★☆☆ 上升期：方向热度高、头部工具迭代快，但个人级开箱即用产品少，多需拼装
长上下文Gemini 3 / 3.1 Pro（1M）、Gemini 3 Ultra（2M，$249/月）、GPT-5.5、Claude Opus 4.8；产品化形态 NotebookLM、Open Notebook（自托管替代）订阅制 / API★★★★☆ 能力成熟但被 frontier 厂商垄断；13+ 模型已提供 1M+ 窗口，2M 窗口一年内出现（presenc.ai 综述）

产品化替代品：很多"自建需求"其实已有成品

产品形态适合谁来源
NotebookLM云端、免费起步、源锚定问答/思维导图/音频概览语料量有限、隐私不敏感、不想动手者notebooktoolkit 对比
Obsidian + Copilot 插件本地 Markdown + 插件生态 + RAG已有笔记积累、要求数据主权者（"笔记已在 Obsidian，这就是赢家"）thinkdifferent.blog 指南
Reor全本地 AI 笔记（Ollama 内置、自动关联）隐私极敏感、能接受小生态者2026 各"第二大脑"盘点（检索摘要）
Open Notebook自托管开源 NotebookLM 替代想要 NotebookLM 体验但要数据自持的开发者KDnuggets，2026-01

5. 数据可信度说明

  1. 本文多数量化数字（GraphRAG $50/M token、$80 实测、LightRAG 50–70% 节省、610K vs <100 token/查询、Qwen3-32B 显存、盈亏平衡 50 万–200 万 token/天、80% 生产管线失败率（已按社区轶闻降格处理，见横轴第 2 节）、普通嵌入 $0.50/M token）来自搜索引擎对多来源的综合摘要，已尽量附原始链接或标注"转述"，未逐一打开原文复核，引用时应视为量级参考而非精确值。
  2. 检索工具返回的 2026 年模型名（GPT-5.5、Claude Opus 4.8、Gemini 3.1 等）与写作工具链相关，个别型号/价格可能因信源聚合有出入；决定性的、可复核的事实（1M 窗口成为 frontier 默认、RULER/NoLiMa 的有效性折扣、GraphRAG 与向量 RAG 的成本数量级差）有多来源交叉印证，置信度较高。
  3. 未实际搭建环境做端到端复测；本文是文献级横评，不是 bench 报告。

交叉洞察

洞察一：同一条权衡曲线，重演了四次

纵轴给出的历史序列，在横轴的成本-效果坐标系里可以读出一条反复重演的曲线：

  1. 2020 年：窗口 512–1024 token → 检索是唯一现实选项，RAG 论文定义问题；
  2. 2023 年：窗口涨 30 倍到 128K，但每 token 计费 → "整库塞窗口"太贵，RAG 仍是默认解；
  3. 2024 年：Gemini 1M + Llama 3.1 免费开源 128K → "RAG 已死"论战爆发 → 三份证据（RULER、Lost in the Middle、SELF-ROUTE）把问题从"塞不塞得下"改写为"成本 × 有效窗口"，论战落幕；
  4. 2025–2026 年：token 价格塌方 + agentic 检索 + prompt caching → 问题不再是"RAG 还是长上下文"，而是"如何在 agent 循环里调度两者"（context engineering）。

规律是：长上下文每一次扩容，重新定义的都是 RAG 的形态，而不是 RAG 的存亡。 2020 年的 RAG 是"检索是唯一选项"，2026 年的 RAG 是"自适应检索 + 上下文管理"——名字没变，内涵换了三代。今天声称"向量库已死、agentic search 取代一切"的论调（Medium），与 2024 年的"RAG 已死"是同一个句式，大概率也是同一个结局。

洞察二：知识图谱的两次生命，个人场景要的都不是"本体"

图谱路线在纵轴上经历了两次生命：第一次是 2012 年 Google Knowledge Graph 开启的工业本体时代，与个人无关；第二次是 2024 年 GraphRAG 以"全局问答"名义回归，但索引成本高企，随后在 2025 年收窄为时序记忆层（Zep/Graphiti 双时序图、Mem0）——管理"会随时间演化的项目状态、人际关系、偏好"，而不是管理静态知识本体。

两轴结合的结论：个人知识库场景对图谱的真实需求很窄，只有两类——全局性问题（"我这三年的研究主线是什么"）和跨会话的演化记忆。这与横轴的能力表完全吻合：图谱在多跳与全局两项上不可替代，在其余五项上并无优势，而 Letta 的 LoCoMo 基准（74.0%，文件式记忆）甚至提示连这两类需求也可能被更轻的方案部分满足。为图而图是个人场景最贵的错误。

洞察三：2025 年，个人开发者的两大成本杠杆同时松动

两者叠加的结果是：对个人开发者，硬件和钱都不再是主要门槛，维护与 token 消耗才是。 横轴"维护成本是最易低估的一项"的判断，与纵轴"成本 × 维护 × 效果"的框架在此交汇——选型时真正该问的问题从"我买得起吗"变成了"我养得起吗"。

洞察四：竞争重心从"路线"上移到"调度层"

MCP（2024.11 发布 → 2025.03 OpenAI 采纳）把知识库从"管道"变成"生态位"；context engineering（2025.09）把"检索什么、何时检索"的决定权交给 agent。纵轴显示这是 2025 年后的主线事件，横轴显示这是 2026 年产品收敛的方向（混合架构）。两轴合起来说明：2026 年的选型问题已经不是"选哪条路线"，而是"选哪个调度层"。 一个用 MCP server 封装的知识库，底层可以随时从纯向量换成混合检索再加图谱——接口稳定，内部自由。

洞察五：产品化替代品正在吞噬自建需求

横轴的产品替代品表 + 纵轴 NotebookLM/Obsidian 插件的演化史合起来看：NotebookLM 免费档 + 桌面级 RAG 工具已经能覆盖绝大多数常见个人需求，自建的价值收窄到四件事——数据主权（隐私敏感）、脏文档深度解析（RAGFlow）、agent 记忆（Mem0/Zep）、全局性问题与多跳关系问答（在 RAG 之上叠加 LightRAG，见决策树第 5 条）。动手自建之前，先确认自己的需求落在这四件事之内，否则默认答案是不自建。

对用户的判断与建议

决策树（按语料规模 × 隐私要求 × 问题类型）：

规模换算基准（决策树所有档位共用）：中文 1 字在不同 tokenizer 下约折合 0.6–2 token（粗略经验值，量级参考），本文统一按 1 篇千字笔记 ≈ 2K token 保守粗算。据此：< ~50 万 token ≈ 250 篇以内的千字笔记；32K ≈ 16 篇；1000 篇千字笔记 ≈ 200 万 token。"数万 token"统一锚定为 32K：RULER（见纵轴第 4 节）证明许多 128K 模型在超过 32K 后性能显著衰减，故本地直读的有效上限取 32K 而非标称 128K。
  1. 语料 < ~50 万 token（按换算基准 ≈ 250 篇以内的千字笔记）且隐私不敏感 → 直接用 NotebookLM 或 Gemini 长上下文。零部署、零维护，小语料问答的综合体验最好。注意区分两种形态：NotebookLM 是"源锚定问答"（见横轴第 4 节"产品化替代品"表），逐句附引用、可溯源；把语料裸塞进 API 长上下文则溯源粒度差（表 1"可溯源"一项为 ❌）——需要引用出处时优先 NotebookLM 形态。NotebookLM 免费档官方限额：每个笔记本最多 50 个来源、单来源 ≤ 50 万词/200MB、共 100 个笔记本、每天 50 次对话（Google 官方帮助：添加来源、官方 FAQ）；50 万 token 量级的语料拆分成几个来源即可塞下，对照限额先核自己的语料量。这是 2026 年的默认起点，别自建。
  2. 语料小但隐私敏感，且折算 ≤ 32K token（≈ 16 篇千字笔记；32K 即本地模型的有效窗口锚点，见上方换算基准） → 本地长上下文直读：gpt-oss-20b（16GB 内存）或 Qwen3 级开源模型 + Ollama。零索引零维护，此规模档下体验最好。注意此档上限远低于标称 128K（理由见消解说明第 1 条）。
  3. 中等规模（数千至十万篇）默认答案：向量 RAG。 两条子路径：
    • *不想动手*：AnythingLLM / Cherry Studio（零 Docker）或 Obsidian + Copilot（若笔记已在 Obsidian）；LLM 走云 API（个人用量月成本通常个位数美元）+ 本地嵌入（BGE-M3，CPU 可跑），GPU 非必需。
    • *要生成也全本地*：24–32GB 显存（二手 RTX 3090 24GB / Intel Arc Pro B70 32GB，与表 2 及预算表一致）+ Qwen3-32B 量化 + Ollama + 内嵌向量库（SQLite-vec/Chroma/LanceDB）+ BM25 混合检索 + bge-reranker。
    • 必抄的两份免费作业：① Anthropic Contextual Retrieval（检索失败率 -49%）；② 重排序——叠加上①后累计 -67%（Anthropic 官方口径，见纵轴第 4 节；上一条中的 bge-reranker 正是第②份作业的落地件）。
  4. 文档又重又脏（扫描件、复杂表格、学术论文）且愿意养 Docker → RAGFlow（16GB 内存起步，推荐 32GB）。
  5. 问题以"关系"和"全局"为主（对应洞察五第四件自建价值"全局性问题与多跳关系问答"）→ 在 RAG 之上叠加 LightRAG（而非 Microsoft GraphRAG）：索引成本省 50–70%，查询 token 从 61 万级降到百级（转述数据）；增量更新特性对"每天写一点"的个人使用模式是决定性的。建图用云端便宜模型（DeepSeek 级 API 约 $0.1–0.3/百万输入 token）或本地 7B–14B 抽取，先在小语料上验证图质量再放量。个人笔记 < 1000 篇（按换算基准 ≈ 200 万 token）不上图。
  6. 在做个人 agent，需要跨会话记忆 → 先试 Letta 的文件式记忆（也许根本不需要图）；确认需要后再评估 Mem0（向量+实体，存储无关）或 Zep/Graphiti（时序 KG，需 Neo4j，Community 版单机即可跑个人规模）。
  7. 兜底原则：混合路由 + MCP 化。 SELF-ROUTE 的结论对个人同样成立——默认便宜路线，模型自评答不了再升级：小问题走长上下文，精确查询走向量 RAG，全局问题才触发图谱摘要。用 MCP 把知识库封装成服务，一次实现、多客户端复用，天然获得 agentic just-in-time 检索。

三档预算方案：

档位投入组合能拿到什么
零硬件投入¥0–150/月现有电脑 + NotebookLM（免费档）/ Gemini Advanced（$19.99/月）+ 云 API 按量付费覆盖绝大多数常见个人需求：长上下文问答 + 免费 RAG 产品
千元级约 ¥1000–2000 一次性 + 少量 API 费16GB 内存机器 + Docker + RAGFlow（最低 4核16G + 50GB 磁盘，推荐 8核32G，见表 2）或 FastGPT（2核4G 可跑）+ 云 API + 本地嵌入全数据自持的工程级 RAG，脏文档解析能力
万元级（全本地）约 ¥5000–8000（二手 RTX 3090 24GB 约 $700，或 Arc Pro B70 32GB 更低）+ 电费Ollama + Qwen3-32B 量化（约 19–20GB 显存，转述）+ BGE-M3/Qwen3-Embedding + AnythingLLM/LightRAG完全离线的问答 + 轻量图谱；注意：按盈亏平衡数据（50 万–200 万 token/天），个人用量下全本地不省钱，买的是隐私与离线

反模式清单（2026 年社区反复踩的坑）：

  1. 个人语料上跑完整版 Microsoft GraphRAG——索引贵、查询贵、增量更新重；LightRAG 或"混合检索 + agentic 循环"即可覆盖大部分动机。
  2. 把十年笔记全量硬塞长上下文——先撞有效上下文墙（RULER/NoLiMa），再撞阶梯定价墙。长上下文适合"一次性任务语料"（一组文档、一本书），不适合"永久增长的知识库"。
  3. 为图而图——没有大量"多跳关系"类问题时，图谱的持续维护成本（消歧、schema 演进）会超过收益。
  4. 频繁更换嵌入模型——每次更换 = 全量重嵌。一开始就锁定 BGE-M3 或 Qwen3-Embedding 这类有社区共识的开源模型。
  5. 只在三条路线里三选一——2026 年的主流答案是分层混合：长上下文做小任务、向量 RAG 做日常检索、图谱只给真正需要关系推理的子域、agentic 循环串联（Medium：Beyond the Vector Retrieval Bottleneck）。

两轴章节的矛盾消解说明

综合时发现并处理了三处分歧、若干重复，处理方式如下（供核查；下文"原纵轴章节/原横轴章节"指成文说明所列 parts/ 目录下的两份源章节文件，非本报告自身的"纵轴/横轴"两章）：

  1. 小语料能否"本地长上下文直读"：原纵轴章节建议笔记 < 20 万 token 时用 gpt-oss-20b 本地直读（原话："笔记总量折算 < 20 万 token（约 300–500 页）：直接走长上下文，配 gpt-oss-20b（16GB 内存）或 Qwen3 级开源模型本地直读"）；原横轴章节判断"长上下文在本地是伪选项"。消解：分歧源于规模档位与两处疏漏。其一，20 万 token 本身已超过多数本地模型的标称 128K 窗口，更不用说有效窗口（RULER 证明许多 128K 模型超过 32K 即衰减）；其二，本地 128K 的 KV cache 显存开销与模型权重二选一。故本报告把决策树第 2 档的本地直读上限收紧为"折算 ≤ 32K token（有效窗口锚点，见决策树前的换算基准）"，20 万 token 的本地直读定性为激进用法而非推荐档；隐私不敏感的小语料一律先走云端（免费/订阅制 + prompt caching）。这是本报告基于两章证据做出的综合判断，非任一原章的原话。
  2. RAG 要不要 24GB GPU：原纵轴章节推荐栈含 24GB 显存卡或 Apple 统一内存设备；原横轴章节强调 GPU 非必需。消解：拆分层——检索层（嵌入、向量库、重排）CPU 即可，生成层走云 API 则全程无 GPU；仅当要求"生成也全本地"才需要 24GB 级。决策树第 3 条已按此改写。
  3. 图谱的门槛表述：原纵轴章节给决策规则（原话："个人笔记量 < 1000 篇时不要上图谱"），原横轴章节给成本数字（GraphRAG 约 $50/百万 token 索引、LightRAG 省 50–70%，转述）。两者不冲突，合并为"规则 + 依据"：成本量级（转述数据）支撑"个人规模别用原版 GraphRAG"的规则。
  4. 重复内容去重：SELF-ROUTE 在两份源章节各出现一次（原纵轴章节引 arXiv 原文、原横轴章节引 GoPenAI 二手解读），本报告合并为一处引用两个链接；RULER/NoLiMa、GraphRAG 成本、Mem0/Zep、落地建议等两章重复展开的内容，本报告纵轴仅保留时间线叙事与状态表，细节统一收敛到本报告横轴的对比表与建议部分。

参考来源

基础论文与基准（arXiv）

长上下文与有效性

RAG vs 长上下文 / 行业共识

知识图谱 / GraphRAG 成本

智能体记忆（图谱的个人级近亲）

个人工具生态与部署成本

嵌入模型

产品化替代品与工具史

协议与工程范式

思考题（读完后想一想，参考答案可展开）

  1. 报告如何评述“RAG 已死”这一论调？其核心论据是什么？
    参考答案

    报告认为“RAG 已死”已被证伪——死掉的只是单轮朴素向量 RAG，历史规律是长上下文每次扩容重新定义的是 RAG 的形态而非存亡。RULER 基准证明许多 128K 模型超过 32K 后性能显著衰减，“标称窗口≠有效窗口”；SELF-ROUTE 显示长上下文成本高一个数量级。2026 年 RAG 演化为“自适应检索+上下文管理”，三条路线分层组合而非互斥。

  2. 在多跳关系推理与全局主题总结上，向量 RAG 为何是结构性盲区？知识图谱如何弥补，代价是什么？
    参考答案

    向量 RAG 靠相似度检索，答不了“A 和 C 通过谁关联”这类多跳问题，朴素方案也做不了全局总结。GraphRAG 建实体关系图，以子图遍历攻多跳、社区摘要供全局问题，两项能力不可替代。但代价高昂：全量索引约 $50/百万 token，全局搜索单次可达 610K+ token。故规则是个人笔记 < 1000 篇不上图，需要时优先 LightRAG（索引省 50–70%）。

  3. 长上下文路线有哪些主要风险？本报告结论自身有哪些局限？
    参考答案

    风险有三：有效窗口远低于标称值，RULER/NoLiMa 证明输入变长、干扰项增多时可用上下文大幅缩水；本地长上下文基本不可行，KV cache 显存占用随窗口线性暴涨，与模型权重二选一；语料增长不断逼近窗口与预算上限，只适合一次性任务语料。报告局限：未实际搭建环境做端到端复测，属文献级横评；多数量化数字来自搜索摘要转述，仅为量级参考。

  4. 个人开发者构建知识库的默认路径是什么？什么条件下才值得升级方案？
    参考答案

    默认不自建：语料 < 约 50 万 token 且隐私不敏感，直接用 NotebookLM。中等规模默认向量 RAG：AnythingLLM 等桌面工具零 Docker，生成走云 API 则无需 GPU；必抄两份作业——Contextual Retrieval（检索失败率 -49%）与重排序（叠加后 -67%）。仅当问题以关系和全局为主时叠加 LightRAG，再用 MCP 封装、混合路由兜底。

← 资料库今日播报 →