Open Notebook 核心心智模型全解Notebook 三层容器、Chat/Ask/Transformations 三模式与三级上下文控制【免费下载链接】open-notebookAn Open Source implementation of Notebook LM with more flexibility and features项目地址: https://gitcode.com/GitHub_Trending/op/open-notebook本文是对 Open Notebook 官方「Core Concepts」指南的深度解读。核心概念索引见 docs/2-CORE-CONCEPTS/index.md本文按该索引勾勒的五个心智模型三层容器模型、AI 上下文与 RAG、三种交互模式、上下文管理控制面板、Podcast 音频转化逐一展开并结合仓库源码notebook 领域模型、上下文构建器、Ask 图谱、内容设置讲清每个设计决策背后的实现原理。读完你会掌握数据在系统里如何流转、Chat 与 Ask 的根本区别、什么时候该用 Transformations、如何用三级上下文控制隐私与成本以及 Podcast 是如何被异步生成的。五个心智模型总览先理解系统「怎么思考」Open Notebook 是一个开源的 NotebookLM 式实现强调更灵活、更多特性。官方文档反复强调一个观点在动手使用之前先理解系统如何思考how it thinks——这些核心概念解释了设计背后的为什么。整套概念被归纳为五个相互关联的心智模型#心智模型一句话概括详细章节1Notebooks、Sources、Notes三层容器结构原始材料如何流向成品洞察notebooks-sources-notes.md2AI Context RAG让 AI 感知研究的两种不同途径ai-context-rag.md3Chat vs Transformations不同交互模式的职责划分chat-vs-transformations.md4Context Management隐私与成本的控制面板同上文档的 Context Management 一节5Podcasts Explained把研究转成音频对话改变消费方式podcasts-explained.md理解这五个模型实际上就理解了产品设计中反复出现的两条主线内容如何被组织容器模型与内容如何被 AI 使用上下文与检索模型。下面逐一深入。心智模型一Notebooks、Sources、Notes —— 三层容器模型系统用三个互相连接的分层来组织研究。理解这个层级关系是高效使用系统的前提。官方用一张图概括┌─────────────────────────────────────┐ │ NOTEBOOK (The Container) │ │ My AI Safety Research 2026 │ ├─────────────────────────────────────┤ │ SOURCES (The Raw Materials) │ │ ├─ safety_paper.pdf │ │ ├─ alignment_video.mp4 │ │ └─ prompt_injection_article.html │ │ │ │ NOTES (The Processed Insights) │ │ ├─ AI Summary (auto-generated) │ │ ├─ Key Concepts (transformation) │ │ ├─ My Research Notes (manual) │ │ └─ Chat Insights (from conversation)│ └─────────────────────────────────────┘1.1 Notebook —— 研究的容器ContainerNotebook笔记本是一个作用域化的研究容器scoped container针对一个研究项目或主题。就像一本实体笔记本里面所有东西都围绕同一主题、共享同一上下文、朝着同一目标累积。Notebook 中装入的东西包括一段描述如 This notebook collects research on X topic、Sources 原始材料、Notes 洞察产出以及对话历史。为什么要用这种隔离容器隔离Isolation每个 Notebook 完全独立Notebook A 里的 Source 绝不会出现在 Notebook B 中。因此你可以让不同研究主题彻底隔离、跨 Notebook 复用同名 Source 而不冲突、精确控制哪份 AI 上下文属于哪个研究。共享上下文Shared ContextNotebook 内所有 Sources 与 Notes 都继承该 Notebook 的上下文。若你的笔记本标题是 AI Safety 2026、描述是 Focusing on alignment and interpretability那么该上下文会作用于其内部所有 AI 交互。并行项目Parallel Projects可以同时运行 10 个 Notebook每个都是独立的研究环境。从源码结构看Notebook 领域模型 就是这一容器的实体化它通过 get_sources 与 get_notes 拉取属于自己作用域的全部 Sources 与 Notes后端在 notebooks 路由 中提供对容器的 CRUD 与资源关联操作。容器语义贯穿整个系统Ask 时搜索范围可限定在指定 NotebookPodcast 生成时以 Notebook 内所有 Sources Notes 为内容来源都体现了Notebook 是一切资源的作用域边界这一原则。1.2 Source —— 不可变的原材料Raw MaterialSource是一份独立的输入材料是带入系统的原始内容。它一旦被添加就不再改变只被处理和索引。官方列举的合法输入类型包括PDF论文、报告、网页链接文章、博客、音频文件播客、访谈、讲座、视频文件教程、演示、录像、纯文本笔记、转录稿、段落以及直接粘贴上传的文本。当你添加一个 Source 时系统会执行一条固定的处理流水线1. EXTRACTION File/URL → Extract text and metadata (OCR for PDFs, web scraping for URLs, speech-to-text for audio) 2. CHUNKING Long text → Break into searchable chunks (Prevents too much context in single query) 3. EMBEDDING Each chunk → Generate semantic vector (Allows AI to find conceptually similar content) 4. STORAGE Chunks vectors → Store in database (Ready for search and retrieval)对应到仓库实现文本抽取、分块、向量化在 source 图谱 中串成一条完整工作流该图内部还会把抽取出的内容交给 transformation 图谱 做洞察提取分块逻辑位于 chunking.py向量化逻辑位于 embedding.py。抽取哪种内容、是否 OCR、公式是否结构化则由 ContentSettings 里的default_content_processing_engine_doc可选auto/docling/simple、default_content_processing_engine_url可选auto/firecrawl/jina/crawl4ai/simple以及docling_ocr、docling_formulas、docling_vision等开关控制——即文档中说的PDF 做 OCR、URL 做网页抓取实际上由可插拔的 content processing engine 完成。Source 的关键属性是不可变Immutable——需要新版本就重新添加一份新 Source已索引Indexed——自动支持全文与语义两种检索作用域单一Scoped——一个 Source 只属于一个 Notebook可被引用Referenceable——其他 Sources 和 Notes 可以通过引用citation指向它。在代码里Source 模型 之下还挂了两类派生实体SourceEmbedding 承载每个分块的向量SourceInsight 承载从该 Source 抽取出的洞察。也就是说Source 不可变、但从它身上可以长出可变的洞察在数据模型上是一对多的父子关系。1.3 Note —— 可变的研究产出Processed InsightNote是加工后的产出是你或 AI 基于 Sources 创建的内容是研究工作的结果。官方将其分为三类手动笔记Manual Notes你自己写下的原始思考——从 Sources 学到什么、你的分析与诠释、下一步与疑问。AI 生成笔记AI-Generated Notes把 AI 处理应用到 Sources 上得到的产出。典型来源是Transformations结构化抽取要点、关键概念、方法论、Chat 回复从对话中保存的回答、Ask 结果保存到笔记本的综合答案。捕获的洞察Captured Insights在交互中显式保存的产出例如把这段回复存为笔记保存这次 transformation 结果任何 AI 输出都可以固化为一条持久笔记。Notes 可以包含文本、指向具体 Sources 的引用、元数据创建时间、手动/AI 创建方式、受哪些 Sources 影响以及可选的标签Tags。为什么 Notes 重要知识积累Notes 构成真正的知识库是研究后带走的东西可搜索Notes 与 Sources 一起参与搜索找到所有与 X 相关的内容会把笔记一并算入可引用Notes 能引用 Sources形成洞察来源的可审计链条可分享Notes 是产出可以分享、发布或在其他项目中复用。1.4 三者如何连接端到端数据流YOU │ ├─→ Create Notebook (AI Research) │ ├─→ Add Sources (papers, articles, videos) │ └─→ System: Extract, embed, index │ ├─→ Search Sources (text or semantic) │ └─→ System: Find relevant chunks │ ├─→ Apply Transformations (extract insights) │ └─→ Creates Notes │ ├─→ Chat with Sources (explore with context control) │ ├─→ Can save responses as Notes │ └─→ Notes include citations │ ├─→ Ask Questions (automated comprehensive search) │ ├─→ Can save results as Notes │ └─→ Notes include citations │ └─→ Generate Podcast (transform notebook into audio) └─→ Uses all sources notes for content1.5 关键设计决策与心智类比官方文档强调三条贯穿数据模型的设计决策一个 Source 只属于一个 NotebookOne Notebook Per Source边界清晰、无归属歧义、易于整项目隔离与导出、权限模型干净。Source 不可变Note 可变Immutable Sources, Mutable NotesSources 是证据证据不应被篡改Notes 是思考思考会随学习演化。显式上下文控制Explicit Context ControlSources 不会自动进入 AI。Chat 需要你手动勾选纳入上下文的 SourcesAsk 由系统自动决定搜索哪些内容Transformations 由你选择对哪些 Source 执行。这与总是把所有内容一股脑发给 AI的系统截然不同。为了便于记忆官方给出三个类比Notebook 像 Git 仓库内部同主题、可复制/派生、有清晰的入口出口、你知道确切包含什么。Source 像法庭证物exhibits入档后不变、可被引用、是你主张的事实基础、多个证物可交叉引用。Note 像案情摘要case brief基于证据撰写、是你的诠释、可为每条主张标注证据出处、是你真正分享和行动的成果。1.6 常见问题速答能把 Source 移到另一个 Notebook 吗不能直接移动。每个 Source 绑定一个 Notebook想要多个 Notebook 共享就再添加一次已处理过的内容上传很快。Note 能引用其他 Notebook 的 Source 吗不能。Note 只停留在自己的 Notebook 内、只引用本 Notebook 的 Source。想在 Notebook 内分组 Source使用标签Tags如 primary research / background / methodology然后按标签过滤。能合并两个 Notebook 吗无内置合并功能但可以通过重新上传把 Source 手工复制过去。1.7 总结表概念目的生命周期作用域Notebook容器 上下文创建一次持续配置它包含的所有 Sources NotesSource原始材料添加 → 处理 → 存储唯一 NotebookNote加工产出创建/捕获 → 编辑 → 分享唯一 Notebook心智模型二AI Context 与 RAG —— 两种让 AI 感知研究的方式2.1 问题如何让 AI 感知你的数据传统方案各有硬伤微调Fine-Tuning让模型在你的数据上训练。优点是可获得专用模型缺点是昂贵、缓慢、永久生效无法反学习。把一切发给云端把全部数据上传给 ChatGPT/Claude 类 API。效果直接但隐私是噩梦——数据脱离你的控制且成本高。忽略你的数据直接用基础模型。私密、免费但 AI 对你的特定主题一无所知。Open Notebook 采取双轨方案Chat走全量内容上下文Ask走 RAG检索增强生成Retrieval-Augmented Generation。RAG 的洞察很朴素搜索你的内容找到相关片段只把那些片段发给模型。2.2 RAG 的三阶段阶段一内容准备。Source 上传后为检索做准备PDF→文本、URL→网页文本、音频→转写文本、视频→字幕转写长文档按约 500 词切块AI 上下文有窗口上限更小的片段更精准每个分块生成语义向量即 embedding用数字数组表示语义OpenAI 默认是 1536 维向量分块向量元数据存入数据库待检索。官方示例一份 50 页的 PDF 被切成约 150 个分块、每个约 500 词、每块都生成向量。仓库侧的证据SurrealDB 迁移脚本中定义了数据库函数fn::vector_search见 迁移文件并在 后续迁移 中演进为支持$min_similarity相似度下限参数向量检索由领域函数vector_search封装后暴露给图谱调用。阶段二查询时检索。提问时系统把你的问题转换成同一套向量 → 用向量数学做相似度搜索不是关键词匹配→ 返回最相似的分块通常取 top 5–10→ 返回相关分块、来源出处source 页码与相关性分数。阶段三增强生成。系统把检索到的分块与用户问题拼装成提示词让 AI 仅依据这些材料作答并自动附上引用citation指明答案出自研究材料的哪一页。正因为一切都被显式检索你可以随时追问这个回答用了哪些 Sources看引用、AI 到底看到了什么看上下文级别、AI 的说法真的在我的 Sources 里吗核验引用。2.3 两种搜索模式精确匹配 vs 语义相似文本搜索关键词匹配向量搜索语义相似原理采用 BM25 排序官方文档称与 Google 所用算法同族按关键词出现频率、位置等排序把问题转成向量与分块向量求相似度适用场景我记得原话/某个名字/数字想精确定位我要原样引用我想找关于 X 的内容但不想限定措辞探索某个概念找出措辞不同但意思相近的观点示例搜 transformer architecture 返回包含该词 3 次的分块搜 model understanding 的机制即使分块里没有 understanding 一词也能命中 interpretability / attention 等语义相近内容2.4 源码级证据Ask 图如何实现多路检索 综合回答文档把 Ask 描述为自动跨全部 Sources 搜索、只把相关片段发给 LLM。在代码里这由 ask.py 中的 LangGraph 状态机实现第 148–157 行组装并编译图谱策略节点agent / call_model_with_messages用 prompts/ask/entry.jinja 提示词 结构化 JSON 输出解析让模型把复杂问题拆解成一个Strategy——最多包含5 个子搜索每个子搜索带term检索词和instructions告诉回答模型需要从这个搜索里提取什么。扇出检索节点trigger_queries / provide_answer通过Send把每个子搜索并行派发到provide_answer。每个子任务调用领域函数vector_search(term, 10, True, True)检索 top-10 结果再把结果与子问题交给 query_process.jinja 提示词生成该子问题的局部答案。汇总节点write_final_answer所有子答案合并后由 final_answer.jinja 提示词合成一份综合答案。这就是文档所说Ask 会为复杂问题拆解多种检索角度、逐路检索、再综合的确切实现——一次 Ask 实际是多次并行的小规模检索-回答因此官方建议 Ask 使用速度较快的模型models API 支持按用途配置不同模型策略/子答案/最终答案可以分别指定模型。2.5 Chat 与 Ask 的本质差异Chat全文上下文无 RAGAskRAG自动检索你的操作手动勾选纳入上下文的 Sources、设定上下文级别、提问只提出一个复杂问题系统行为把选中 Sources 的全部内容一次性发给 LLM不检索、不分块拆解问题→自动跨全部 Sources 搜索→向量相似度召回→只把最相关分块发给 LLM→综合AI 行为基于你给的全量内容回答上下文在后续对话中保持只看到被召回的片段一次性回答、无后续对话适合明确知道哪些 Sources 相关、想要来回对话、做细读与精析Sources 很多且不确定哪些相关、想要跨库综合答案、想最小化 token 用量优势简单透明、AI 不遗漏内容、对话流畅自动搜索、一次覆盖多 Sources、省 token局限受 LLM 上下文窗口限制、需手动挑选 Sources、多 Source 时 token 成本高非对话式、AI 只看到检索片段可能丢上下文、检索质量依赖问题与内容的匹配度官方文档还注明社区正在为 Chat 增加 RAG 能力未来有望鱼与熊掌兼得。两类交互目前均有相应 API 与前端入口Notebook 级对话走 chat 路由单 Source 细读走 source_chat 路由Ask 走 search/ask 路由 代理。心智模型三Chat vs Ask vs Transformations —— 哪种工具干哪种活系统提供三种与研究工作交互的方式。选对工具的关键判断是不同的问题需要不同的工具研究很少只靠一种模式。3.1 Chat —— 手动上下文 对话式探索流程你勾选in context的 Sources → 提问 → AI 只依据这些 Sources 回答 → 追问上下文保持不变→ 更换 Sources 或调整上下文级别后继续。上下文管理是手动的你决定 AI 能看到什么天然支持多轮共享历史的对话。典型示例把paper1.pdf设为 Full Content、research_notes.txt设为 Summary然后连续追问这两份材料的主要论点是什么它们有何分歧再替换新的 Sources 做交叉对比。最适合围绕明确主题的聚焦探索需要多轮来回的对话你清楚哪些 Sources 重要你想牢牢控制进入 AI 的内容。3.2 Ask —— 自动化的综合检索问答流程提出一个综合性问题 → 系统分析问题 → 自动搜索你的 Sources → 检索相关分块 → 从所有结果综合答案 → 返回一份详尽回答非对话式。上下文管理是自动的。若想追问文档的建议是改用 Chat。最适合一次性综合问答同时比较多个 Sources希望系统自行判断相关性需要多种检索角度切入的复杂问题不需要来回对话的场景。3.3 Transformations —— 基于模板的批处理抽取流程定义一个 transformation或选用预设模板如抽取核心论点、方法论、局限→每次作用于一个 Source→ Source 内容 transformation 提示词交给 AI → 结果作为新的 insight/note 存入 Notebook → 对下一个 Source 重复同一模板。注意官方文档明确说明当前 transformation逐个处理 Source批量处理一次作用于多个 Sources计划在后续版本推出。该语义与 api/routers/transformations.py 及 transformations 前端页面/transformations/page.tsx) 的交互一致前端同时提供默认提示词编辑DefaultPromptEditor.tsx/transformations/components/DefaultPromptEditor.tsx)与逐源执行入口。最适合从每个 Source 中重复抽取同一类信息生成格式一致的结构化摘要构建分类洞察知识库需要可复用模板逐源执行的场景。3.4 决策树该用哪个What are you trying to do? │ ├─→ 我想就这个主题进行对话 │ └─→ 是探索性的还是固定一问 │ ├─→ 探索性会追问 → USE: CHAT │ └─→ 固定一问 → 继续看下一个问题 │ ├─→ 我要比较这些 Sources / 要一份综合答案 → USE: ASK │ ├─→ 我要从每个 Source 抽取同样的信息逐个处理 │ └─→ USE: TRANSFORMATIONS │ └─→ 我只是想阅读和搜索 → USE: Search文本或向量或读 Notes3.5 并排对比维度CHATASKTRANSFORMATIONS用途对话式探索综合问答模板化抽取问题数多轮对话一问一答每个 Source 一个模板上下文控制手动你选自动系统搜索一次一个 Source对话式是支持追问否否单次操作输出自然对话自然语言答案结构化笔记耗时快来回较长综合按 Source 计最佳场景探索、不确定时需要全貌要统一格式模型选择任意模型均可推荐快速模型任意模型3.6 三套完整工作流示例示例 A学术研究15 篇论文写综述TRANSFORMATIONS定义抽取摘要、方法论、发现、相关性对 15 篇逐篇应用 → 得到 15 份格式统一的笔记通读这些结构化笔记用CHAT / ASK组织主题Chat帮我把这些按主题归类Ask这些论文共用了哪些方法论以 transformation 产出为地基完成综述。示例 B产品研究客户访谈添加访谈转录稿为 Sources2.ASK提到最多的 10 个痛点拿到带引用的综合答案3.CHAT帮我按严重程度分组持续对话以排序4.可选TRANSFORMATIONS定义抽取痛点、出现频率、谁提到逐访谈执行获得结构化数据。示例 C政策分析对比政策文件把所有政策文件加入 Sources2.ASK这些政策在气候措施上有何差异3. 需要时用CHAT讨论权衡哪个政策最契合 X 目标4. 把 AI 回复存为 Notes 用于报告。3.7 进阶把模式串联起来TRANSFORMATIONS → CHAT先用 transformation 抽取结构化数据再与结果对话讨论ASK → TRANSFORMATIONS先用 Ask 弄清什么重要再用 transformation 从剩余 Sources 中抽取CHAT → 存为 Note → TRANSFORMATIONS把对话中的好回答存为 Notes再把这些 Notes 当作 transformation 的上下文。3.8 选择速查表场景用哪个为什么我想带追问地探索一个主题CHAT对话式你控制上下文我需要一个复杂问题的一次性综合答案ASK自动搜索 综合回答我要每个 Source 出一份统一格式摘要TRANSFORMATIONS模板复用逐源执行我要比较两个具体 SourceCHAT只勾选这两个展开讨论我要按 X 标准给每个 Source 归类TRANSFORMATIONS从每个 Source 抽取归类信息我要跨所有 Sources 看大局ASK自动全面检索我要搭建知识库TRANSFORMATIONS每个 Source 生成结构化笔记我要反复迭代理解CHAT多轮提问逐步精化心智模型四上下文管理 —— 隐私与成本的控制面板前文多处出现 context level这正是第四个心智模型在 Open Notebook 中由你来决定 AI 到底能看到什么。这是它与把一切自动发给模型类系统最关键的区别。4.1 三级上下文级别共享内容示例成本隐私适用场景Full Content全文完整 Source 文本约 10,000 tokens低精细分析、细读Summary Only仅摘要AI 生成的摘要约 2,000 tokens高背景材料、参考资料Not in Context排除不共享任何内容0 tokens最高机密、无关或归档内容表中 token 数为主观示例量级用于说明三级之间的成本量级差异实际取决于文档长度与所用模型。三个典型操作场景Full Content要求分析 A 论文的方法论 → 系统检索并发送完整内容 → AI 给出精细、准确的回答。Summary Only想同时用 A、B 两篇论文对话 → 对 A 发送 AI 摘要背景、对 B 发送全文精读→ AI 用摘要提供语境、用全文支撑细节。Not in Context有 10 个 Sources 只想用其中 5 个 → 后 5 个完全不发送、不搜索AI 甚至不知道它们存在。4.2 为什么要这样设计隐私Privacy由你控制什么离开你的系统。典型场景——机密公司文档 公开研究材料混在一起时只把公开研究纳入上下文AI 永远看不到机密内容。成本Cost由你控制 token 用量。典型场景——100 个背景 Sources 5 个精读 Sources5 个发全文、95 个只发摘要token 成本比全部发送可降低约八成量级视文本而定。质量Quality由你控制 AI 的注意力。20 个 Sources 需要深度分析时只给相关 Source 全文并排除干扰项AI 不易分心、回答质量更高。4.3 源码级证据上下文级别是怎么落到实现上的这个控制面板在后端有一个单一实现点context_builder.py。该模块的 docstring 明确说明它是两个场景共用的唯一实现POST /api/chat/context 上下文组装由 chat 路由 调用根据一份 source/note 的 inclusion config 组装整个 Notebook 的上下文source_chat 图谱 的 build_source_context在 token 预算内组装单 Source 其洞察。关键实现细节状态值就是人话字符串inclusion config 使用可读的英文状态串——not in context、insights、full content——并且该协议与前端共享模块注释明确不要改动它。build_notebook_context的逻辑是状态含not in则跳过含insights则用get_context(context_sizeshort)即短上下文含full content则用get_context(context_sizelong)长上下文。注意 Notes 只支持full content。文档中的三级模型与代码的对应关系是Not in Context ↔ 直接跳过Summary Only/insights ↔ short context含摘要式洞察Full Content ↔ long context完整文本。前端同样维护着这组语义source-context.ts 定义了SourceContextDefault include | insights | full | exclude与批量动作applyBulkSourceContextContextToggle.tsx 提供逐 Source 的三态切换其中insights模式仅对 Sources 可用对应测试见 source-context.test.ts。健壮性与预算单条记录失败只记日志并跳过不会拖垮整个请求build_source_context支持max_tokens预算——超出预算时从尾部丢弃洞察source 本体最后才考虑丢弃并用token_count见 token_utils.py实时计量。4.4 控制面板的两条使用路径在 CHAT 与 TRANSFORMATIONS 中你逐个选择包含哪些 Sources、并为每个设置上下文级别全文/仅摘要/排除。在 ASK 中上下文自动——系统搜索你的全部 Sources、只召回最相关的分块。但你可以把搜索限定在特定 Notebook、按 Source 类型过滤再用检索结果决定后续 Chat 的上下文。4.5 其他影响什么数据被处理的设置与上下文控制相关的还有一份全局内容设置 ContentSettingsdefault_embedding_option可选ask/always/never决定 Source 添加后是否默认做向量化与auto_delete_files等。前者直接影响向量搜索能力是否默认开启属于在检索链路层面对隐私与存储成本的又一次把关。心智模型五Podcast —— 把研究变成可被动消费的音频对话5.1 为什么需要 Podcast研究天然以文本形态堆积PDF、文章、网页、笔记而消费文本需要坐下来、专注阅读、记笔记、安排专属时间。但生活里大量是被动时间通勤、锻炼、洗碗、开车、散步、碎片空闲。Podcast 的解法是把研究转为音频对话让你能被动吸收洞察——不占屏幕时间。5.2 与同类产品差异据官方文档陈述官方文档将其与 Google Notebook LM 的 Podcast 对比后者是固定双主持人对话格式、无法自定义主持人、每个说话人只能用一个 TTS 音色、仅用云端服务而 Open Notebook 支持 1–4 个说话人并允许设计人设、丰富的 Speaker Profiles、多 TTS 提供方OpenAI / Google TTS / ElevenLabs / 本地 TTS、异步生成不阻塞工作、并可控大纲结构/语气/深度。5.3 生成流水线六个阶段内容选择Content Selection在 Notebook 内容中选择哪些 Sources、哪些 Notes、聚焦哪些话题、覆盖深度如何。节目档案Episode Profile定义结构——主题、时长如 20 分钟、语气学术但易懂、格式如双人辩论、目标听众、重点话题。说话人配置Speaker Configuration创建 1–4 个说话人每人含专长expertise、性格personality、可选口音accent、以及从模型注册表选定的语音模型voice model并可按说话人覆盖节目默认语音模型。大纲生成Outline Generation系统生成带时间分配的分段大纲引言→主体→辩论→开放问题→结论。对话生成Dialogue Generation基于大纲生成多说话人对话稿。语音合成Text-to-Speech按模型注册表中配置的语音模型把每个说话人的台词转为音频混合输出为最终 MP3。凭据自动从各模型配置解析。5.4 失败与重试Podcast 生成依赖外部 AI 提供方多环节大纲、转写稿、TTS都可能失败。失败时的行为该 episode 标记为Failed红色徽章展示来自 AI 提供方的错误信息以便定位不自动创建重复 episode为防混乱关闭了自动重试。重试流程进入 Podcast 的Episodes页签 → 找到红色 FAILED 徽章与错误详情 → 点击Retry→ 失败的 episode 被删除、提交新生成任务 → 新 episode 以 pending 状态出现。常见错误处理建议API key 无效检查 Settings → Credentials 中 TTS 与语言模型提供方的凭据模型找不到确认模型存在于模型注册表且配置了有效凭据触发限流等几分钟后重试提供方不可用查看提供方状态页稍后重试5.5 关键架构决策源码印证异步处理Podcast 在后台生成。原因生成耗时30 分钟节目常需 10 分钟以上阻塞会卡死界面。仓库中 podcast_service.py、podcast 相关命令 以及 podcasts API 路由 共同支撑后台任务与任务状态查询tests 目录下 test_podcast_job_status_batching.py 等测试覆盖了任务状态的批量查询语义。多说话人可自定义 1–4 人支持独白1 人专家、访谈2 人主持人专家、辩论2 人对立观点、圆桌3–4 人不同专长。说话人可定制领域模型集中在 podcasts/models.py对应顶层目录另有 models.py 之外的其他 domain 层Speaker Profile / Episode Profile 的持久化与 API 分别在 speaker_profiles 路由 与 episode_profiles 路由前端提供 SpeakerProfileFormDialog.tsx 与 EpisodeProfileFormDialog.tsx。多 TTS 提供方不被单一语音供应商锁定——利于成本优化、音质偏好、隐私选项敏感内容用本地 TTS、无障碍不同口音/性别/风格。本地 TTS 选项可完全离线生成。对敏感研究音频绝不发送给外部 API。仓库配置示例见 docker-compose-speaches.yml相关说明见 5-CONFIGURATION/local-tts.md。5.6 隐私与成本数据去向云 TTS 会把大纲脚本发给 TTS 提供方并取回音频存回 Notebook——提供方看到的是你的脚本不含原始 Sources隐私级别中等本地 TTS 则一切本地完成提供方看不到任何内容隐私级别最高。成本量级官方文档给出的量级示例实际以各供应商最新价格为准提供方约每 1 分钟成本质量速度OpenAI~$0.015好快Google~$0.004优秀快ElevenLabs~$0.10出众中本地 TTS免费基础慢据此一段 30 分钟 Podcast 的生成成本量级约为OpenAI ~$0.45、Google ~$0.12、ElevenLabs ~$3.00、本地免费但慢。推荐策略敏感研究用本地 TTS、零 API 调用不太敏感的内容用 ElevenLabs 或 Google混合场景让朗读敏感内容的说话人走本地 TTS。5.7 主动阅读 vs 被动收听以及使用案例文本研究是主动学习高投入、需专注、难并行、适合精读音频 Podcast 是被动学习低投入、随时随地、可并行、适合概览与语境。二者互补先听 Podcast 建立语境 → 再读原文做精读 → 双轨并进掌握全貌。官方列举的典型案例学术出版论文→专家讲解/多解读辩论内容创作研究→Podcast→转录成文或直接作为节目发布教育课程材料→专家讲解音频学生听比读更容易投入市场调研客户访谈→客户视角 vs 团队视角辩论节目知识传承资深专家把框架与决策语境录成专家模式节目新人不必啃 100 份文档。5.8 同一份研究的多种音频形态同一批 Sources 可以产出多档 Podcast面向新人的专家独白教育向、面向资深研究者的乐观派 vs 怀疑派辩论讨论权衡、面向从业者的记者专家访谈QA 实操。每档用不同角度讲同一个故事。大图景三条贯穿性设计原则官方文档把整份核心概念收束到一个洞察你的研究理应属于你自己Your research deserves to stay yours并由三条原则支撑默认隐私Privacy by default除非你明确选择你的数据不会离开你的基础设施。结合前文——三级上下文控制、本地 TTS、可选择不向量化default_embedding_optionask/never、可选的本地内容处理引擎均为这一原则的实现细节。AI 是工具而非看门人AI as a tool, not a gatekeeper由你决定 AI 能看到哪些 Sources而不是让 AI 替你决定。灵活消费Flexible consumption阅读、收听、搜索、对话或转化你的研究一切取决于哪种方式对你有意义。如何阅读本指南 / 下一步按官方索引的指引刚接触 Open Notebook→ 从五个心智模型开始先建立概念框架再学功能分不清 Chat vs Ask→ 重点看 ai-context-rag.md全文 vs RAG 的区别纠结 Chat vs Transformations 何时用→ 重点看 chat-vs-transformations.md想理解隐私控制→ 重点看 chat-vs-transformations.md#context-management-the-control-panel 中的上下文管理部分对应本文第四模型好奇 Podcast 的设计动机→ 重点看 podcasts-explained.md。下一步行动路径想直接上手使用进入 用户指南想先完成概念阅读通读上述五个部分约 15 分钟首次部署配置则前往 安装与配置指南 与 5-CONFIGURATION 配置章节。总结理解 Open Notebook 的钥匙是这五组对应关系——Notebook 管组织Sources 进、Notes 出、Chat 管对话全量但手动、Ask 管检索RAG 且自动、上下文级别管边界隐私/成本/质量、Podcast 管消费被动收听。它们共享同一套领域模型与上下文构建器notebook.py context_builder.py并在各 API 路由与前端组件中保持一致的语义。掌握了这套心智模型后续阅读 用户指南 的每个功能模块时你都能知道它处于整个系统设计中的哪个位置、为什么要这样设计。【免费下载链接】open-notebookAn Open Source implementation of Notebook LM with more flexibility and features项目地址: https://gitcode.com/GitHub_Trending/op/open-notebook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Open Notebook 核心心智模型全解：Notebook 三层容器、Chat/Ask/Transformations 三模式与三级上下文控制
Open Notebook 核心心智模型全解Notebook 三层容器、Chat/Ask/Transformations 三模式与三级上下文控制【免费下载链接】open-notebookAn Open Source implementation of Notebook LM with more flexibility and features项目地址: https://gitcode.com/GitHub_Trending/op/open-notebook本文是对 Open Notebook 官方「Core Concepts」指南的深度解读。核心概念索引见 docs/2-CORE-CONCEPTS/index.md本文按该索引勾勒的五个心智模型三层容器模型、AI 上下文与 RAG、三种交互模式、上下文管理控制面板、Podcast 音频转化逐一展开并结合仓库源码notebook 领域模型、上下文构建器、Ask 图谱、内容设置讲清每个设计决策背后的实现原理。读完你会掌握数据在系统里如何流转、Chat 与 Ask 的根本区别、什么时候该用 Transformations、如何用三级上下文控制隐私与成本以及 Podcast 是如何被异步生成的。五个心智模型总览先理解系统「怎么思考」Open Notebook 是一个开源的 NotebookLM 式实现强调更灵活、更多特性。官方文档反复强调一个观点在动手使用之前先理解系统如何思考how it thinks——这些核心概念解释了设计背后的为什么。整套概念被归纳为五个相互关联的心智模型#心智模型一句话概括详细章节1Notebooks、Sources、Notes三层容器结构原始材料如何流向成品洞察notebooks-sources-notes.md2AI Context RAG让 AI 感知研究的两种不同途径ai-context-rag.md3Chat vs Transformations不同交互模式的职责划分chat-vs-transformations.md4Context Management隐私与成本的控制面板同上文档的 Context Management 一节5Podcasts Explained把研究转成音频对话改变消费方式podcasts-explained.md理解这五个模型实际上就理解了产品设计中反复出现的两条主线内容如何被组织容器模型与内容如何被 AI 使用上下文与检索模型。下面逐一深入。心智模型一Notebooks、Sources、Notes —— 三层容器模型系统用三个互相连接的分层来组织研究。理解这个层级关系是高效使用系统的前提。官方用一张图概括┌─────────────────────────────────────┐ │ NOTEBOOK (The Container) │ │ My AI Safety Research 2026 │ ├─────────────────────────────────────┤ │ SOURCES (The Raw Materials) │ │ ├─ safety_paper.pdf │ │ ├─ alignment_video.mp4 │ │ └─ prompt_injection_article.html │ │ │ │ NOTES (The Processed Insights) │ │ ├─ AI Summary (auto-generated) │ │ ├─ Key Concepts (transformation) │ │ ├─ My Research Notes (manual) │ │ └─ Chat Insights (from conversation)│ └─────────────────────────────────────┘1.1 Notebook —— 研究的容器ContainerNotebook笔记本是一个作用域化的研究容器scoped container针对一个研究项目或主题。就像一本实体笔记本里面所有东西都围绕同一主题、共享同一上下文、朝着同一目标累积。Notebook 中装入的东西包括一段描述如 This notebook collects research on X topic、Sources 原始材料、Notes 洞察产出以及对话历史。为什么要用这种隔离容器隔离Isolation每个 Notebook 完全独立Notebook A 里的 Source 绝不会出现在 Notebook B 中。因此你可以让不同研究主题彻底隔离、跨 Notebook 复用同名 Source 而不冲突、精确控制哪份 AI 上下文属于哪个研究。共享上下文Shared ContextNotebook 内所有 Sources 与 Notes 都继承该 Notebook 的上下文。若你的笔记本标题是 AI Safety 2026、描述是 Focusing on alignment and interpretability那么该上下文会作用于其内部所有 AI 交互。并行项目Parallel Projects可以同时运行 10 个 Notebook每个都是独立的研究环境。从源码结构看Notebook 领域模型 就是这一容器的实体化它通过 get_sources 与 get_notes 拉取属于自己作用域的全部 Sources 与 Notes后端在 notebooks 路由 中提供对容器的 CRUD 与资源关联操作。容器语义贯穿整个系统Ask 时搜索范围可限定在指定 NotebookPodcast 生成时以 Notebook 内所有 Sources Notes 为内容来源都体现了Notebook 是一切资源的作用域边界这一原则。1.2 Source —— 不可变的原材料Raw MaterialSource是一份独立的输入材料是带入系统的原始内容。它一旦被添加就不再改变只被处理和索引。官方列举的合法输入类型包括PDF论文、报告、网页链接文章、博客、音频文件播客、访谈、讲座、视频文件教程、演示、录像、纯文本笔记、转录稿、段落以及直接粘贴上传的文本。当你添加一个 Source 时系统会执行一条固定的处理流水线1. EXTRACTION File/URL → Extract text and metadata (OCR for PDFs, web scraping for URLs, speech-to-text for audio) 2. CHUNKING Long text → Break into searchable chunks (Prevents too much context in single query) 3. EMBEDDING Each chunk → Generate semantic vector (Allows AI to find conceptually similar content) 4. STORAGE Chunks vectors → Store in database (Ready for search and retrieval)对应到仓库实现文本抽取、分块、向量化在 source 图谱 中串成一条完整工作流该图内部还会把抽取出的内容交给 transformation 图谱 做洞察提取分块逻辑位于 chunking.py向量化逻辑位于 embedding.py。抽取哪种内容、是否 OCR、公式是否结构化则由 ContentSettings 里的default_content_processing_engine_doc可选auto/docling/simple、default_content_processing_engine_url可选auto/firecrawl/jina/crawl4ai/simple以及docling_ocr、docling_formulas、docling_vision等开关控制——即文档中说的PDF 做 OCR、URL 做网页抓取实际上由可插拔的 content processing engine 完成。Source 的关键属性是不可变Immutable——需要新版本就重新添加一份新 Source已索引Indexed——自动支持全文与语义两种检索作用域单一Scoped——一个 Source 只属于一个 Notebook可被引用Referenceable——其他 Sources 和 Notes 可以通过引用citation指向它。在代码里Source 模型 之下还挂了两类派生实体SourceEmbedding 承载每个分块的向量SourceInsight 承载从该 Source 抽取出的洞察。也就是说Source 不可变、但从它身上可以长出可变的洞察在数据模型上是一对多的父子关系。1.3 Note —— 可变的研究产出Processed InsightNote是加工后的产出是你或 AI 基于 Sources 创建的内容是研究工作的结果。官方将其分为三类手动笔记Manual Notes你自己写下的原始思考——从 Sources 学到什么、你的分析与诠释、下一步与疑问。AI 生成笔记AI-Generated Notes把 AI 处理应用到 Sources 上得到的产出。典型来源是Transformations结构化抽取要点、关键概念、方法论、Chat 回复从对话中保存的回答、Ask 结果保存到笔记本的综合答案。捕获的洞察Captured Insights在交互中显式保存的产出例如把这段回复存为笔记保存这次 transformation 结果任何 AI 输出都可以固化为一条持久笔记。Notes 可以包含文本、指向具体 Sources 的引用、元数据创建时间、手动/AI 创建方式、受哪些 Sources 影响以及可选的标签Tags。为什么 Notes 重要知识积累Notes 构成真正的知识库是研究后带走的东西可搜索Notes 与 Sources 一起参与搜索找到所有与 X 相关的内容会把笔记一并算入可引用Notes 能引用 Sources形成洞察来源的可审计链条可分享Notes 是产出可以分享、发布或在其他项目中复用。1.4 三者如何连接端到端数据流YOU │ ├─→ Create Notebook (AI Research) │ ├─→ Add Sources (papers, articles, videos) │ └─→ System: Extract, embed, index │ ├─→ Search Sources (text or semantic) │ └─→ System: Find relevant chunks │ ├─→ Apply Transformations (extract insights) │ └─→ Creates Notes │ ├─→ Chat with Sources (explore with context control) │ ├─→ Can save responses as Notes │ └─→ Notes include citations │ ├─→ Ask Questions (automated comprehensive search) │ ├─→ Can save results as Notes │ └─→ Notes include citations │ └─→ Generate Podcast (transform notebook into audio) └─→ Uses all sources notes for content1.5 关键设计决策与心智类比官方文档强调三条贯穿数据模型的设计决策一个 Source 只属于一个 NotebookOne Notebook Per Source边界清晰、无归属歧义、易于整项目隔离与导出、权限模型干净。Source 不可变Note 可变Immutable Sources, Mutable NotesSources 是证据证据不应被篡改Notes 是思考思考会随学习演化。显式上下文控制Explicit Context ControlSources 不会自动进入 AI。Chat 需要你手动勾选纳入上下文的 SourcesAsk 由系统自动决定搜索哪些内容Transformations 由你选择对哪些 Source 执行。这与总是把所有内容一股脑发给 AI的系统截然不同。为了便于记忆官方给出三个类比Notebook 像 Git 仓库内部同主题、可复制/派生、有清晰的入口出口、你知道确切包含什么。Source 像法庭证物exhibits入档后不变、可被引用、是你主张的事实基础、多个证物可交叉引用。Note 像案情摘要case brief基于证据撰写、是你的诠释、可为每条主张标注证据出处、是你真正分享和行动的成果。1.6 常见问题速答能把 Source 移到另一个 Notebook 吗不能直接移动。每个 Source 绑定一个 Notebook想要多个 Notebook 共享就再添加一次已处理过的内容上传很快。Note 能引用其他 Notebook 的 Source 吗不能。Note 只停留在自己的 Notebook 内、只引用本 Notebook 的 Source。想在 Notebook 内分组 Source使用标签Tags如 primary research / background / methodology然后按标签过滤。能合并两个 Notebook 吗无内置合并功能但可以通过重新上传把 Source 手工复制过去。1.7 总结表概念目的生命周期作用域Notebook容器 上下文创建一次持续配置它包含的所有 Sources NotesSource原始材料添加 → 处理 → 存储唯一 NotebookNote加工产出创建/捕获 → 编辑 → 分享唯一 Notebook心智模型二AI Context 与 RAG —— 两种让 AI 感知研究的方式2.1 问题如何让 AI 感知你的数据传统方案各有硬伤微调Fine-Tuning让模型在你的数据上训练。优点是可获得专用模型缺点是昂贵、缓慢、永久生效无法反学习。把一切发给云端把全部数据上传给 ChatGPT/Claude 类 API。效果直接但隐私是噩梦——数据脱离你的控制且成本高。忽略你的数据直接用基础模型。私密、免费但 AI 对你的特定主题一无所知。Open Notebook 采取双轨方案Chat走全量内容上下文Ask走 RAG检索增强生成Retrieval-Augmented Generation。RAG 的洞察很朴素搜索你的内容找到相关片段只把那些片段发给模型。2.2 RAG 的三阶段阶段一内容准备。Source 上传后为检索做准备PDF→文本、URL→网页文本、音频→转写文本、视频→字幕转写长文档按约 500 词切块AI 上下文有窗口上限更小的片段更精准每个分块生成语义向量即 embedding用数字数组表示语义OpenAI 默认是 1536 维向量分块向量元数据存入数据库待检索。官方示例一份 50 页的 PDF 被切成约 150 个分块、每个约 500 词、每块都生成向量。仓库侧的证据SurrealDB 迁移脚本中定义了数据库函数fn::vector_search见 迁移文件并在 后续迁移 中演进为支持$min_similarity相似度下限参数向量检索由领域函数vector_search封装后暴露给图谱调用。阶段二查询时检索。提问时系统把你的问题转换成同一套向量 → 用向量数学做相似度搜索不是关键词匹配→ 返回最相似的分块通常取 top 5–10→ 返回相关分块、来源出处source 页码与相关性分数。阶段三增强生成。系统把检索到的分块与用户问题拼装成提示词让 AI 仅依据这些材料作答并自动附上引用citation指明答案出自研究材料的哪一页。正因为一切都被显式检索你可以随时追问这个回答用了哪些 Sources看引用、AI 到底看到了什么看上下文级别、AI 的说法真的在我的 Sources 里吗核验引用。2.3 两种搜索模式精确匹配 vs 语义相似文本搜索关键词匹配向量搜索语义相似原理采用 BM25 排序官方文档称与 Google 所用算法同族按关键词出现频率、位置等排序把问题转成向量与分块向量求相似度适用场景我记得原话/某个名字/数字想精确定位我要原样引用我想找关于 X 的内容但不想限定措辞探索某个概念找出措辞不同但意思相近的观点示例搜 transformer architecture 返回包含该词 3 次的分块搜 model understanding 的机制即使分块里没有 understanding 一词也能命中 interpretability / attention 等语义相近内容2.4 源码级证据Ask 图如何实现多路检索 综合回答文档把 Ask 描述为自动跨全部 Sources 搜索、只把相关片段发给 LLM。在代码里这由 ask.py 中的 LangGraph 状态机实现第 148–157 行组装并编译图谱策略节点agent / call_model_with_messages用 prompts/ask/entry.jinja 提示词 结构化 JSON 输出解析让模型把复杂问题拆解成一个Strategy——最多包含5 个子搜索每个子搜索带term检索词和instructions告诉回答模型需要从这个搜索里提取什么。扇出检索节点trigger_queries / provide_answer通过Send把每个子搜索并行派发到provide_answer。每个子任务调用领域函数vector_search(term, 10, True, True)检索 top-10 结果再把结果与子问题交给 query_process.jinja 提示词生成该子问题的局部答案。汇总节点write_final_answer所有子答案合并后由 final_answer.jinja 提示词合成一份综合答案。这就是文档所说Ask 会为复杂问题拆解多种检索角度、逐路检索、再综合的确切实现——一次 Ask 实际是多次并行的小规模检索-回答因此官方建议 Ask 使用速度较快的模型models API 支持按用途配置不同模型策略/子答案/最终答案可以分别指定模型。2.5 Chat 与 Ask 的本质差异Chat全文上下文无 RAGAskRAG自动检索你的操作手动勾选纳入上下文的 Sources、设定上下文级别、提问只提出一个复杂问题系统行为把选中 Sources 的全部内容一次性发给 LLM不检索、不分块拆解问题→自动跨全部 Sources 搜索→向量相似度召回→只把最相关分块发给 LLM→综合AI 行为基于你给的全量内容回答上下文在后续对话中保持只看到被召回的片段一次性回答、无后续对话适合明确知道哪些 Sources 相关、想要来回对话、做细读与精析Sources 很多且不确定哪些相关、想要跨库综合答案、想最小化 token 用量优势简单透明、AI 不遗漏内容、对话流畅自动搜索、一次覆盖多 Sources、省 token局限受 LLM 上下文窗口限制、需手动挑选 Sources、多 Source 时 token 成本高非对话式、AI 只看到检索片段可能丢上下文、检索质量依赖问题与内容的匹配度官方文档还注明社区正在为 Chat 增加 RAG 能力未来有望鱼与熊掌兼得。两类交互目前均有相应 API 与前端入口Notebook 级对话走 chat 路由单 Source 细读走 source_chat 路由Ask 走 search/ask 路由 代理。心智模型三Chat vs Ask vs Transformations —— 哪种工具干哪种活系统提供三种与研究工作交互的方式。选对工具的关键判断是不同的问题需要不同的工具研究很少只靠一种模式。3.1 Chat —— 手动上下文 对话式探索流程你勾选in context的 Sources → 提问 → AI 只依据这些 Sources 回答 → 追问上下文保持不变→ 更换 Sources 或调整上下文级别后继续。上下文管理是手动的你决定 AI 能看到什么天然支持多轮共享历史的对话。典型示例把paper1.pdf设为 Full Content、research_notes.txt设为 Summary然后连续追问这两份材料的主要论点是什么它们有何分歧再替换新的 Sources 做交叉对比。最适合围绕明确主题的聚焦探索需要多轮来回的对话你清楚哪些 Sources 重要你想牢牢控制进入 AI 的内容。3.2 Ask —— 自动化的综合检索问答流程提出一个综合性问题 → 系统分析问题 → 自动搜索你的 Sources → 检索相关分块 → 从所有结果综合答案 → 返回一份详尽回答非对话式。上下文管理是自动的。若想追问文档的建议是改用 Chat。最适合一次性综合问答同时比较多个 Sources希望系统自行判断相关性需要多种检索角度切入的复杂问题不需要来回对话的场景。3.3 Transformations —— 基于模板的批处理抽取流程定义一个 transformation或选用预设模板如抽取核心论点、方法论、局限→每次作用于一个 Source→ Source 内容 transformation 提示词交给 AI → 结果作为新的 insight/note 存入 Notebook → 对下一个 Source 重复同一模板。注意官方文档明确说明当前 transformation逐个处理 Source批量处理一次作用于多个 Sources计划在后续版本推出。该语义与 api/routers/transformations.py 及 transformations 前端页面/transformations/page.tsx) 的交互一致前端同时提供默认提示词编辑DefaultPromptEditor.tsx/transformations/components/DefaultPromptEditor.tsx)与逐源执行入口。最适合从每个 Source 中重复抽取同一类信息生成格式一致的结构化摘要构建分类洞察知识库需要可复用模板逐源执行的场景。3.4 决策树该用哪个What are you trying to do? │ ├─→ 我想就这个主题进行对话 │ └─→ 是探索性的还是固定一问 │ ├─→ 探索性会追问 → USE: CHAT │ └─→ 固定一问 → 继续看下一个问题 │ ├─→ 我要比较这些 Sources / 要一份综合答案 → USE: ASK │ ├─→ 我要从每个 Source 抽取同样的信息逐个处理 │ └─→ USE: TRANSFORMATIONS │ └─→ 我只是想阅读和搜索 → USE: Search文本或向量或读 Notes3.5 并排对比维度CHATASKTRANSFORMATIONS用途对话式探索综合问答模板化抽取问题数多轮对话一问一答每个 Source 一个模板上下文控制手动你选自动系统搜索一次一个 Source对话式是支持追问否否单次操作输出自然对话自然语言答案结构化笔记耗时快来回较长综合按 Source 计最佳场景探索、不确定时需要全貌要统一格式模型选择任意模型均可推荐快速模型任意模型3.6 三套完整工作流示例示例 A学术研究15 篇论文写综述TRANSFORMATIONS定义抽取摘要、方法论、发现、相关性对 15 篇逐篇应用 → 得到 15 份格式统一的笔记通读这些结构化笔记用CHAT / ASK组织主题Chat帮我把这些按主题归类Ask这些论文共用了哪些方法论以 transformation 产出为地基完成综述。示例 B产品研究客户访谈添加访谈转录稿为 Sources2.ASK提到最多的 10 个痛点拿到带引用的综合答案3.CHAT帮我按严重程度分组持续对话以排序4.可选TRANSFORMATIONS定义抽取痛点、出现频率、谁提到逐访谈执行获得结构化数据。示例 C政策分析对比政策文件把所有政策文件加入 Sources2.ASK这些政策在气候措施上有何差异3. 需要时用CHAT讨论权衡哪个政策最契合 X 目标4. 把 AI 回复存为 Notes 用于报告。3.7 进阶把模式串联起来TRANSFORMATIONS → CHAT先用 transformation 抽取结构化数据再与结果对话讨论ASK → TRANSFORMATIONS先用 Ask 弄清什么重要再用 transformation 从剩余 Sources 中抽取CHAT → 存为 Note → TRANSFORMATIONS把对话中的好回答存为 Notes再把这些 Notes 当作 transformation 的上下文。3.8 选择速查表场景用哪个为什么我想带追问地探索一个主题CHAT对话式你控制上下文我需要一个复杂问题的一次性综合答案ASK自动搜索 综合回答我要每个 Source 出一份统一格式摘要TRANSFORMATIONS模板复用逐源执行我要比较两个具体 SourceCHAT只勾选这两个展开讨论我要按 X 标准给每个 Source 归类TRANSFORMATIONS从每个 Source 抽取归类信息我要跨所有 Sources 看大局ASK自动全面检索我要搭建知识库TRANSFORMATIONS每个 Source 生成结构化笔记我要反复迭代理解CHAT多轮提问逐步精化心智模型四上下文管理 —— 隐私与成本的控制面板前文多处出现 context level这正是第四个心智模型在 Open Notebook 中由你来决定 AI 到底能看到什么。这是它与把一切自动发给模型类系统最关键的区别。4.1 三级上下文级别共享内容示例成本隐私适用场景Full Content全文完整 Source 文本约 10,000 tokens低精细分析、细读Summary Only仅摘要AI 生成的摘要约 2,000 tokens高背景材料、参考资料Not in Context排除不共享任何内容0 tokens最高机密、无关或归档内容表中 token 数为主观示例量级用于说明三级之间的成本量级差异实际取决于文档长度与所用模型。三个典型操作场景Full Content要求分析 A 论文的方法论 → 系统检索并发送完整内容 → AI 给出精细、准确的回答。Summary Only想同时用 A、B 两篇论文对话 → 对 A 发送 AI 摘要背景、对 B 发送全文精读→ AI 用摘要提供语境、用全文支撑细节。Not in Context有 10 个 Sources 只想用其中 5 个 → 后 5 个完全不发送、不搜索AI 甚至不知道它们存在。4.2 为什么要这样设计隐私Privacy由你控制什么离开你的系统。典型场景——机密公司文档 公开研究材料混在一起时只把公开研究纳入上下文AI 永远看不到机密内容。成本Cost由你控制 token 用量。典型场景——100 个背景 Sources 5 个精读 Sources5 个发全文、95 个只发摘要token 成本比全部发送可降低约八成量级视文本而定。质量Quality由你控制 AI 的注意力。20 个 Sources 需要深度分析时只给相关 Source 全文并排除干扰项AI 不易分心、回答质量更高。4.3 源码级证据上下文级别是怎么落到实现上的这个控制面板在后端有一个单一实现点context_builder.py。该模块的 docstring 明确说明它是两个场景共用的唯一实现POST /api/chat/context 上下文组装由 chat 路由 调用根据一份 source/note 的 inclusion config 组装整个 Notebook 的上下文source_chat 图谱 的 build_source_context在 token 预算内组装单 Source 其洞察。关键实现细节状态值就是人话字符串inclusion config 使用可读的英文状态串——not in context、insights、full content——并且该协议与前端共享模块注释明确不要改动它。build_notebook_context的逻辑是状态含not in则跳过含insights则用get_context(context_sizeshort)即短上下文含full content则用get_context(context_sizelong)长上下文。注意 Notes 只支持full content。文档中的三级模型与代码的对应关系是Not in Context ↔ 直接跳过Summary Only/insights ↔ short context含摘要式洞察Full Content ↔ long context完整文本。前端同样维护着这组语义source-context.ts 定义了SourceContextDefault include | insights | full | exclude与批量动作applyBulkSourceContextContextToggle.tsx 提供逐 Source 的三态切换其中insights模式仅对 Sources 可用对应测试见 source-context.test.ts。健壮性与预算单条记录失败只记日志并跳过不会拖垮整个请求build_source_context支持max_tokens预算——超出预算时从尾部丢弃洞察source 本体最后才考虑丢弃并用token_count见 token_utils.py实时计量。4.4 控制面板的两条使用路径在 CHAT 与 TRANSFORMATIONS 中你逐个选择包含哪些 Sources、并为每个设置上下文级别全文/仅摘要/排除。在 ASK 中上下文自动——系统搜索你的全部 Sources、只召回最相关的分块。但你可以把搜索限定在特定 Notebook、按 Source 类型过滤再用检索结果决定后续 Chat 的上下文。4.5 其他影响什么数据被处理的设置与上下文控制相关的还有一份全局内容设置 ContentSettingsdefault_embedding_option可选ask/always/never决定 Source 添加后是否默认做向量化与auto_delete_files等。前者直接影响向量搜索能力是否默认开启属于在检索链路层面对隐私与存储成本的又一次把关。心智模型五Podcast —— 把研究变成可被动消费的音频对话5.1 为什么需要 Podcast研究天然以文本形态堆积PDF、文章、网页、笔记而消费文本需要坐下来、专注阅读、记笔记、安排专属时间。但生活里大量是被动时间通勤、锻炼、洗碗、开车、散步、碎片空闲。Podcast 的解法是把研究转为音频对话让你能被动吸收洞察——不占屏幕时间。5.2 与同类产品差异据官方文档陈述官方文档将其与 Google Notebook LM 的 Podcast 对比后者是固定双主持人对话格式、无法自定义主持人、每个说话人只能用一个 TTS 音色、仅用云端服务而 Open Notebook 支持 1–4 个说话人并允许设计人设、丰富的 Speaker Profiles、多 TTS 提供方OpenAI / Google TTS / ElevenLabs / 本地 TTS、异步生成不阻塞工作、并可控大纲结构/语气/深度。5.3 生成流水线六个阶段内容选择Content Selection在 Notebook 内容中选择哪些 Sources、哪些 Notes、聚焦哪些话题、覆盖深度如何。节目档案Episode Profile定义结构——主题、时长如 20 分钟、语气学术但易懂、格式如双人辩论、目标听众、重点话题。说话人配置Speaker Configuration创建 1–4 个说话人每人含专长expertise、性格personality、可选口音accent、以及从模型注册表选定的语音模型voice model并可按说话人覆盖节目默认语音模型。大纲生成Outline Generation系统生成带时间分配的分段大纲引言→主体→辩论→开放问题→结论。对话生成Dialogue Generation基于大纲生成多说话人对话稿。语音合成Text-to-Speech按模型注册表中配置的语音模型把每个说话人的台词转为音频混合输出为最终 MP3。凭据自动从各模型配置解析。5.4 失败与重试Podcast 生成依赖外部 AI 提供方多环节大纲、转写稿、TTS都可能失败。失败时的行为该 episode 标记为Failed红色徽章展示来自 AI 提供方的错误信息以便定位不自动创建重复 episode为防混乱关闭了自动重试。重试流程进入 Podcast 的Episodes页签 → 找到红色 FAILED 徽章与错误详情 → 点击Retry→ 失败的 episode 被删除、提交新生成任务 → 新 episode 以 pending 状态出现。常见错误处理建议API key 无效检查 Settings → Credentials 中 TTS 与语言模型提供方的凭据模型找不到确认模型存在于模型注册表且配置了有效凭据触发限流等几分钟后重试提供方不可用查看提供方状态页稍后重试5.5 关键架构决策源码印证异步处理Podcast 在后台生成。原因生成耗时30 分钟节目常需 10 分钟以上阻塞会卡死界面。仓库中 podcast_service.py、podcast 相关命令 以及 podcasts API 路由 共同支撑后台任务与任务状态查询tests 目录下 test_podcast_job_status_batching.py 等测试覆盖了任务状态的批量查询语义。多说话人可自定义 1–4 人支持独白1 人专家、访谈2 人主持人专家、辩论2 人对立观点、圆桌3–4 人不同专长。说话人可定制领域模型集中在 podcasts/models.py对应顶层目录另有 models.py 之外的其他 domain 层Speaker Profile / Episode Profile 的持久化与 API 分别在 speaker_profiles 路由 与 episode_profiles 路由前端提供 SpeakerProfileFormDialog.tsx 与 EpisodeProfileFormDialog.tsx。多 TTS 提供方不被单一语音供应商锁定——利于成本优化、音质偏好、隐私选项敏感内容用本地 TTS、无障碍不同口音/性别/风格。本地 TTS 选项可完全离线生成。对敏感研究音频绝不发送给外部 API。仓库配置示例见 docker-compose-speaches.yml相关说明见 5-CONFIGURATION/local-tts.md。5.6 隐私与成本数据去向云 TTS 会把大纲脚本发给 TTS 提供方并取回音频存回 Notebook——提供方看到的是你的脚本不含原始 Sources隐私级别中等本地 TTS 则一切本地完成提供方看不到任何内容隐私级别最高。成本量级官方文档给出的量级示例实际以各供应商最新价格为准提供方约每 1 分钟成本质量速度OpenAI~$0.015好快Google~$0.004优秀快ElevenLabs~$0.10出众中本地 TTS免费基础慢据此一段 30 分钟 Podcast 的生成成本量级约为OpenAI ~$0.45、Google ~$0.12、ElevenLabs ~$3.00、本地免费但慢。推荐策略敏感研究用本地 TTS、零 API 调用不太敏感的内容用 ElevenLabs 或 Google混合场景让朗读敏感内容的说话人走本地 TTS。5.7 主动阅读 vs 被动收听以及使用案例文本研究是主动学习高投入、需专注、难并行、适合精读音频 Podcast 是被动学习低投入、随时随地、可并行、适合概览与语境。二者互补先听 Podcast 建立语境 → 再读原文做精读 → 双轨并进掌握全貌。官方列举的典型案例学术出版论文→专家讲解/多解读辩论内容创作研究→Podcast→转录成文或直接作为节目发布教育课程材料→专家讲解音频学生听比读更容易投入市场调研客户访谈→客户视角 vs 团队视角辩论节目知识传承资深专家把框架与决策语境录成专家模式节目新人不必啃 100 份文档。5.8 同一份研究的多种音频形态同一批 Sources 可以产出多档 Podcast面向新人的专家独白教育向、面向资深研究者的乐观派 vs 怀疑派辩论讨论权衡、面向从业者的记者专家访谈QA 实操。每档用不同角度讲同一个故事。大图景三条贯穿性设计原则官方文档把整份核心概念收束到一个洞察你的研究理应属于你自己Your research deserves to stay yours并由三条原则支撑默认隐私Privacy by default除非你明确选择你的数据不会离开你的基础设施。结合前文——三级上下文控制、本地 TTS、可选择不向量化default_embedding_optionask/never、可选的本地内容处理引擎均为这一原则的实现细节。AI 是工具而非看门人AI as a tool, not a gatekeeper由你决定 AI 能看到哪些 Sources而不是让 AI 替你决定。灵活消费Flexible consumption阅读、收听、搜索、对话或转化你的研究一切取决于哪种方式对你有意义。如何阅读本指南 / 下一步按官方索引的指引刚接触 Open Notebook→ 从五个心智模型开始先建立概念框架再学功能分不清 Chat vs Ask→ 重点看 ai-context-rag.md全文 vs RAG 的区别纠结 Chat vs Transformations 何时用→ 重点看 chat-vs-transformations.md想理解隐私控制→ 重点看 chat-vs-transformations.md#context-management-the-control-panel 中的上下文管理部分对应本文第四模型好奇 Podcast 的设计动机→ 重点看 podcasts-explained.md。下一步行动路径想直接上手使用进入 用户指南想先完成概念阅读通读上述五个部分约 15 分钟首次部署配置则前往 安装与配置指南 与 5-CONFIGURATION 配置章节。总结理解 Open Notebook 的钥匙是这五组对应关系——Notebook 管组织Sources 进、Notes 出、Chat 管对话全量但手动、Ask 管检索RAG 且自动、上下文级别管边界隐私/成本/质量、Podcast 管消费被动收听。它们共享同一套领域模型与上下文构建器notebook.py context_builder.py并在各 API 路由与前端组件中保持一致的语义。掌握了这套心智模型后续阅读 用户指南 的每个功能模块时你都能知道它处于整个系统设计中的哪个位置、为什么要这样设计。【免费下载链接】open-notebookAn Open Source implementation of Notebook LM with more flexibility and features项目地址: https://gitcode.com/GitHub_Trending/op/open-notebook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考