NotebookLM 架构深度拆解：长上下文时代最好的 QA 系统是怎么做的

本文基于掘金文章《拆解 NotebookLM：长上下文时代最好的 QA 系统是怎么做的》（作者：肖凤生）整理提炼，补充了原理层面的解释，并结合自建 RAG 项目给出落地启示。
原文链接：https://juejin.cn/post/7646985522289836083

一、为什么要拆解 NotebookLM

NotebookLM 的对话功能，在”给定源文档进行问答”这个场景下，目前可以认为是行业 SOTA（最好水平）。它同时做到了三个特点的平衡：

除了 NotebookLM，当前其他产品都没有同时做到这三点：

• • ima：快、能溯源，但溯源体验不如 NLM 丝滑，准确性也差一点

• • ChatGPT / Claude Projects：完全无法溯源，你无法快速验证它说的对不对

Google 内部很少公开 NotebookLM 的技术细节，早期团队成员只提到过一个词：source grounding（来源锚定），承认这类似外界说的 RAG（检索增强生成），另一个反复出现的关键词是长上下文。

所以核心问题就变成了：在 NotebookLM 里，RAG 和长上下文到底是怎么协作的？

二、先破除一个误解：它不是 Agent

很多人的第一反应是：NotebookLM 看起来会”思考”（输入问题后有一串变化的进度文字，像在检索、校对、确认），那它是不是一个 Agent（自主智能体）？

结论：不是。 证据有三条：

1. 1. 系统提示词里没有检索工具。作者通过技巧拿到了 NotebookLM 的系统提示词，它的工具箱里只有 discover_sources（搜索新来源）和 Studio 相关工具（生成报告、脑图等），没有任何”检索当前来源”的工具。

1. 1. 交互验证：当问题需要的资料不在已选来源中时，NLM 会问你是否要搜索新来源——这说明”检索已选来源”根本不是它自己要做的动作。

1. 1. 行为验证（泰国实验）：作者向一个只含”中国+欧盟食品法规”的笔记本，问泰国添加剂合规问题。NLM 的”思考”里反复确认来源里有没有泰国，但始终没有重新检索——如果是真 Agent，它一定会调整检索词重新搜索。这说明：它的”思考”只是回答阶段的反思，不是检索动作。

真相：NotebookLM 的对话 = 普通 RAG 检索 + 长上下文问答，检索和回答是两个独立阶段。思考展示来自回答 LLM 本身，检索阶段快得几乎不需要思考。

三、整体架构：一个极简的三阶段 Pipeline

┌─────────────────────────────────────────────────────┐
│  离线阶段：上传文档时                                │
│  程序提取文字 → 扫描件/乱码整页截图 → 快速切块       │
│  → 记录原文起止位置 → 写入 RAG 数据库（向量+倒排）    │
└─────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────┐
│  在线阶段：用户提问后                                │
│                                                     │
│  ① 检索 Retrieval                                   │
│     多角度问题改写 → 混合检索（语义+关键词）          │
│     → 大量召回 100~400 个片段（纯程序，无 Agent）     │
│                                                     │
│  ② 生成 Generation                                  │
│     片段按文件分组 + 全局编号 → 问题首尾复述          │
│     → 组装进 user message → 长上下文 LLM 一次性消化   │
│     → 每句话以 [i] 引用结尾                         │
│                                                     │
│  ③ 展示 Display                                     │
│     前端把离散引用重编号为 [1][2][3]                 │
│     → 点击引用 → 跳转原文 → 高亮对应段落             │
└─────────────────────────────────────────────────────┘

整个架构没有：Agent 编排、OCR 识别扫描件、结构感知切块、LLM 级别的上下文增强。
只有：快速切块、大量召回、长上下文兜底。

四、逐环节详细拆解

4.1 文档解析：速度与成本的极致取舍

做法：

• • 能提取文字的文档，直接程序提取文字

• • 扫描件 → 整页截图

• • 无字体库导致 PDF 文字乱码 → 也整页截图，让 LLM 直接读图回答

为什么不学业界主流？
业界共识是 RAG 需要精细切块：

• • 结构感知切块（Google Layout Parser）：识别文档结构，让每个切块携带祖先标题；大表格保留表头信息

• • 上下文感知切块（Anthropic 提出）：用 LLM 为每个切块生成全文视角的描述

这些方法确实提升检索准确率，但延迟高、成本高。NotebookLM 是免费消费者产品，延迟和成本是生死线，所以选了最快最省的方案：直接提取 + 截图兜底。

代价：在表格密集、内容跨多个主体容易”张冠李戴”的场景，没有结构信息的切块会把 A 物质的限量安到 B 头上（复现测试中 NotebookLM 在法规表格场景只有 71% 准确率）。

4.2 检索：反共识的”大量召回”

传统 RAG 的思路：追求精准——重排后只返回 10~20 个高相关片段。

NotebookLM 的思路：不追求精准，追求”相关且不遗漏”。

• • 对原始问题进行多角度改写，扩展出多个搜索视角

• • 混合检索（语义向量 + 关键词倒排）

• • 一次召回 100~400 个片段（实测最多一次 372 个）

• • 即使问题和来源完全不相关，也会返回不少片段

为什么反共识还更好？

相似性 ≠ 相关性，语义相关 ≠ 事实相关。

精准召回必然遗漏”语义上不那么近、但事实上相关”的信息，而这些遗漏信息的缺失，决定了回答是片面的还是全面准确的。

不相关也返回的另一个妙用：当来源里真的没有答案时，LLM 可以基于这些片段告诉用户”已有资料是关于什么的”，并把用户自然引导回资料范畴内——比干巴巴说”无法回答”体验高一大截。

判断权交给 LLM：检索阶段只负责”捞”，捞多捞全；判断哪些有用，交给长上下文 LLM。

4.3 生成：动态上下文的组装艺术

系统提示词（作者获取的真实提示词，关键片段）：

Your response should be directly supported by the given sources and cited
appropriately without hallucination. Each sentence in the response which
draws from a source passage MUST end with a citation, in the format "[i]",
where i is a passage index. Use commas to separate indices if multiple
passages are used.

DO NOT start your response with a preamble like 'Based on the sources.'
Jump directly into the answer.

核心要求：

• • 每句引用来源，句尾必须带 [i] 编号，禁止幻觉

• • 禁止以 “Based on the sources” 套话开头

• • 工具箱只有发现来源和 Studio 工具，没有检索工具

User Message 的动态组装（这是最精巧的部分）：

Notebook 的基本信息（哪些来源被勾选）和召回的片段都是动态内容，所以放在 user message 而非系统提示词。组装规则：

<notebook_state>
Notebook title: "Food Contact Materials Standards"
Sources in Notebook:
1. "GB 4806.15-2024 黏合剂.pdf" [PDF]
2. [NOTE: EXCLUDED FROM QUERY BY USER] "GB 4806.3-2016 搪瓷制品.pdf" [PDF]
3. "GB 4806.5-2016 玻璃制品.pdf" [PDF]
Total sources in notebook: 3
Total sources selected by user: 2
</notebook_state>

My query is {黏合剂的总迁移量限值是多少？}.

These are the sources you must use to answer my query: {
NEW SOURCE ()
Excerpts from "GB 4806.15-2024 黏合剂.pdf":
{
[1] 5 技术要求
5.3 理化指标 ...
总迁移量a/(mg/dm2)b ≤ 10 GB31604.8
}
...
}

Conversation history is provided to you.

Now respond to my query {黏合剂的总迁移量限值是多少？}
drawing on information in the sources and our conversation history.

三个关键细节：

1. 1. 未选中的来源标记 [NOTE: EXCLUDED FROM QUERY BY USER]——明确告诉 LLM 哪些不能用

1. 1. 片段按文件分组 + 全局编号——每个片段自带全局唯一序号，LLM 只需引用编号，不用自己数数

1. 1. 问题首尾复述——原始问题在片段列表前和后各出现一次。作用：LLM 读片段前脑子里带着问题，读完全部片段后不会因内容太多而忘记原始问题。这是管控 LLM 注意力、防止跑偏的有效技巧

4.4 展示：引用从”离散”到”连续”的小魔法

• • LLM 输出的是被引用片段的全局序号，可能是 [3]、[70]、[205] 这种跳跃数字

• • 前端程序按出现顺序重新编号为 [1]、[2]、[3]…，用户看到的是连续序号

• • 每个片段在切块时记录了原文中的起止位置，检索时连同片段一起返回

• • 用户点击引用 → 来源面板打开原文 → 根据起止位置高亮对应文本

为什么必须这么做：如果你直接展示 [3][70][205]，用户会困惑；重新编号后既准确又美观。而溯源（点击→跳转→高亮）不是锦上添花，是用户愿意在专业场景信任 AI 的前提。

五、五条关键设计启发（最值得学的东西）

1. 宁可多召回，让 LLM 自己判断相关性

不要让检索阶段替 LLM 做决定。相似性不等于相关性，精准召回必然遗漏”语义不近但事实相关”的信息。把判断权交给 LLM，用长上下文消化更多片段，是更优的 tradeoff。

2. 引用编号不要让 LLM 数，预编号更可靠

给每个片段预设全局唯一编号，LLM 只需引用编号而不用数数。前端再对引用重编号，让用户看到的永远是从 1 开始的连续序号。

3. 问题首尾复述，管控注意力

在大量片段的前后都放一遍用户的原始问题。LLM 读片段前带着问题，读完后不会因为内容太多而丢失注意力跑偏。

4. 简单架构 vs 结构感知切块，是分场景的权衡

NotebookLM 选了最简方案（提取文字 + 截图兜底）。作为免费消费者产品，这个取舍合理，长上下文 + 大量召回在一定程度上弥补了切块精度的不足。但复现验证表明：在表格密集、内容跨多个主体容易张冠李戴的场景，结构感知切块能显著提升准确率。做不做，取决于你的产品对准确性的要求。

5. 溯源不是锦上添花，是必须有的体验

用户不会完全信任 AI。点击引用 → 跳转原文 → 高亮段落，是让用户愿意在专业场景使用 AI 的前提。每个切块在解析阶段就应该记录原文位置。

六、复现验证：这套架构经得起检验

作者用同一套回答层（NotebookLM 系统提示词 + Gemini 3.5 Flash），对比不同解析/检索方案的准确率：

读表结论：

1. 1. 文档解析直接决定回答天花板：同一个回答模型，不同解析方案准确率从 97% 拉到 82%，差 15 个百分点。解析不只是预处理，它是准确率的天花板。

1. 1. 结构感知切块有用：Google 自家 Layout Parser 比 LLM Parser 在 FCM 上高 3 个百分点；作者自建的两种方案都做了结构感知切块，差距很小（3~4%），差距来自解析层（乱码 PDF 的提取 vs 截图）。

1. 1. NotebookLM 为什么只有 71%：没有结构感知切块——表格密集场景下，一个切块缺少表头和祖先标题上下文，容易把 A 物质的限量安到 B 头上；另外它把图片链接混在文本里，不如把截图以图片形式直接提交给 Gemini。

1. 1. ima 是另一种能力分布：解析没问题（88%），但面对口语化跨语言、跨多份法令整合的场景理解力不足（53%）。

核心结论：NotebookLM 的架构思路（大量召回 + 长上下文）经过复现验证是成立的，但准确性的天花板取决于每一环的执行质量：文档怎么解析、切块有没有结构、截图怎么处理、检索怎么做，每一步都在影响最终的回答。

七、对自建 RAG 项目（BrainPress / notebook）的落地启示

结合你正在做的文件驱动知识库 + AI 问答，这套拆解直接给出一份可执行的升级清单：

按优先级落地

关键判断

1. 1. 你的文件驱动是天然优势：原文就是 Markdown 文件，起止位置、锚点天然存在，做溯源比 PDF 场景简单得多——PDF 需要记录页码+字符偏移，md 直接用标题锚点即可。

1. 1. 不要急着上结构感知切块：如果知识库以文字为主、表格不多，先照搬 NotebookLM 的极简方案（快、省、够用）；等出现”张冠李戴”类错误再升级切块。

1. 1. 引用溯源值得优先做：这是 NLM 和普通 RAG 产品的分水岭，也是用户信任的来源。你的 BrainPress 渲染层 + notebook 问答层天然可以打通：点击引用 → 跳转到 BrainPress 里的对应文章锚点并高亮。

1. 1. 系统提示词可以直接借鉴：NLM 的提示词（每句引用、禁套话、工具政策）是公开拆解产物，直接作为你 QA 层的基线，再按你的产品微调。

八、参考来源

• • 掘金：《拆解 NotebookLM：长上下文时代最好的 QA 系统是怎么做的》https://juejin.cn/post/7646985522289836083

• • Google 官方博客：NotebookLM Mind Map / 学习功能介绍 https://blog.google/technology/google-labs/notebooklm-studying-help/

• • markmap 官方文档（思维导图渲染层参考）：https://markmap.js.org/docs

一句话总结：NotebookLM 没有魔法，它只是把”大量召回 + 长上下文 + 预编号引用溯源”这三个简单设计组合到了极致，并针对免费消费者产品做了正确的延迟/成本取舍。这套架构完全可以自建复现，甚至能在解析和切块环节做得比它更好。