将内容导入 Open Notebook:添加 Source 的完整实战指南

将内容导入 Open Notebook:添加 Source 的完整实战指南 将内容导入 Open Notebook添加 Source 的完整实战指南【免费下载链接】open-notebookAn Open Source implementation of Notebook LM with more flexibility and features项目地址: https://gitcode.com/GitHub_Trending/op/open-notebook把文档、网页、音视频等外部材料转化为可供 AI 检索与对话的「研究原材料」是 Open Notebook 一切工作流Chat、Search、Transformations、Podcasts的起点。本文基于官方用户指南 adding-sources.md系统讲解在 Open Notebook 中如何通过上传文件、粘贴链接、粘贴文本三种方式添加 Source覆盖支持的格式清单、后台处理管线抽取→分块→向量化→入库、各类内容的处理时长预期、来源状态与上下文管理并结合仓库源码说明每次添加时实际发生了什么。读完本文你将能够根据材料类型选择正确的添加路径、预判处理耗时、排解常见错误并控制 AI 对来源内容的访问级别。快速开始添加你的第一个 Source在笔记本Notebook页面中点击Add Source即可开始。系统提供三种入口适用于不同形态的原始材料方式一上传文件PDF、Word 等1. 在笔记本中点击 Add Source 2. 选择 Upload File 3. 从本地电脑选择文件 4. 点击 Upload 5. 等待 30-60 秒处理 6. 完成Source 出现在你的笔记本中方式二添加网页链接1. 点击 Add Source 2. 选择 Web Link 3. 粘贴 URLhttps://example.com/article 4. 点击 Add 5. 等待处理通常比文件更快 6. 完成方式三直接粘贴文本1. 点击 Add Source 2. 选择 Text 3. 粘贴或输入内容 4. 点击 Save 5. 完成立即可用从 API 角度看这三种类型在底层分别对应create_source路由中的type字段取值upload、link、text。接口以 multipart/form-data 接收表单参数类型、目标笔记本、URL、正文、标题、是否嵌入等随后根据提交的async_processing标志决定走异步后台队列还是同步执行路径可参考 api/routers/sources.py 中parse_source_form_data与_build_content_state的实现。支持的格式文档类类别格式说明PDF.pdf支持最完善含扫描件 OCRWord.docx,.doc完整支持PowerPoint.pptx幻灯片转为文本Excel.xlsx,.xls表格数据EPUB.epub电子书文件Markdown / 纯文本.md,.txt纯文本格式HTML.html,.htm网页文件图片.png,.jpg,.jpeg,.tiff,.bmp通过 OCR 读取文字需要启用 Docling见下文文件大小上限约 100MB因系统而异。API 侧由MaxBodyMiddleware兜底默认上限 100MB可通过环境变量OPEN_NOTEBOOK_MAX_UPLOAD_SIZE_MB调整见 api/middleware.py若部署了反向代理还需同步放开代理的上传体积限制参考 docs/5-CONFIGURATION/reverse-proxy.md。处理时长10 秒到 2 分钟取决于长度与文件类型。OCR扫描版 PDF 与图片扫描版 PDF 和图片文件中的文字依赖 OCR 读取。OCR 走Docling引擎该引擎是可选组件当你在环境变量中设置OPEN_NOTEBOOK_ENABLE_DOCLINGtrue时容器会在首次启动时自动安装。启用后 OCR 默认开启如需关闭或强制使用更精确的抽取引擎可前往Settings → Content Processing调整详细说明见 内容处理引擎指南。音频与视频音频MP3、WAV、M4A、OGG、FLAC处理速度约为每小时音频 30 秒 - 3 分钟视频MP4、AVI、MOV、MKV、WebM处理速度约为每小时视频 3-10 分钟YouTube支持直接粘贴 URL播客支持 RSS feed 地址自动转写音频/视频会由系统自动转写为文本。该功能需要在设置中启用语音转文本speech-to-text。在源码中转写模型来自系统默认配置当配置了默认语音转写模型时content_process会把其 provider/model 写入 content-core 的抽取配置可参考 open_notebook/graphs/source.py 中读取default_speech_to_text_model的逻辑。网页内容文章博客、新闻、MediumYouTube完整视频、播放列表以及/live/、/shorts/链接Reddit公开帖子 URL通过 Reddit 公开 JSON 获取在线 PDF直接的 PDF 链接新闻新闻网站文章直接粘贴 URL 到 Web Link 即可。JS 重度网站URL 能抽取到什么程度取决于 URL 处理引擎。默认的auto引擎会依次尝试多个引擎启用 Crawl4AI 后可在本地渲染 JavaScript 页面。如果链接抽取结果为空参见内容处理引擎指南。此外YouTube 的字幕语言偏好由源码中的YOUTUBE_PREFERRED_LANGUAGES列表决定见 open_notebook/graphs/source.py包含 en、pt、es、de、nl、en-GB、fr、hi、ja 等语言。不支持的输入付费墙内容如 WSJ、FT 等——无法抽取带密码保护的 PDF——无法打开不支持的格式——立即被拒绝并给出清晰的 unsupported file type 提示不会让你长时间等待超大文件100MB——超时后端对「不支持格式」做了上传前置检查pre-flight check上传接口会先调用 content-core 的check_file_support按文件头判断类型一旦判定不支持就直接抛出UnsupportedTypeException映射为 HTTP 415而不会把注定失败的任务投进后台队列空耗重试预算可参考 api/routers/sources.py 中_assert_file_supported的实现与 tests/test_upload_type_mitigations.py 的测试用例。添加 Source 后会发生什么系统会自动完成四件事1. 抽取文本 (EXTRACT TEXT) 文件/URL → 可读文本 PDF 若为扫描件则走 OCR 视频若启用转写则转写 2. 切分块 (BREAK INTO CHUNKS) 长文本 → 约 500 词的片段 这样搜索命中的是具体片段而不是整篇文档 3. 生成向量 (CREATE EMBEDDINGS) 每个块 → 向量表示 支撑语义/概念搜索 4. 索引入库 (INDEX STORE) 全部 → 数据库 随时可检索、可召回何时可用进度条走完后Source 立即可用。向量化embedding在后台异步进行。源码视角的完整管线这四个阶段在仓库中由一条 LangGraph 工作流实现source_graph见 open_notebook/graphs/source.py状态流转为START → content_process → save_source → (条件触发) transform_content → END。content_process根据内容类型调用 content-core 的extract_content。对于 URL支持url_engineauto/simple/firecrawl/jina/crawl4ai对文件支持document_engineauto/docling/simple并可透传docling_ocr、docling_formulas、docling_vision开关。如果某个被配置的引擎是可选的且其运行时未安装_usable_engine会自动回退到auto并打印告警日志。抽取结果为空时含 YouTube 无字幕系统会抛出明确错误使任务标记为 failed 并可重试。save_source把抽取出的文本写入source.full_text仅当标题为占位符时才用抽取出的标题覆盖保留用户自定义标题随后保存数据库记录。切块文本切块由 open_notebook/utils/chunking.py 完成。核心逻辑若全文 token 数不超过块上限则直接作为单块否则按内容类型HTML/Markdown/纯文本选择对应 splitter再对超长块做二次切分、丢弃低于MIN_CHUNK_SIZE的碎片块。可通过环境变量OPEN_NOTEBOOK_CHUNK_SIZE默认 400 token最小 100、OPEN_NOTEBOOK_CHUNK_OVERLAP默认块大小的 15%、OPEN_NOTEBOOK_MIN_CHUNK_SIZE默认 5调优。内容类型优先按文件扩展名判定.html/.md/.txt等无扩展名或不确定时由文本内容启发式打分兜底。向量化save_source在embedTrue时调用source.vectorize()。该方法是 fire-and-forget 的向队列提交embed_source命令由 commands/embedding_commands.py 中的embed_source_command在后台执行「删除旧向量 → 检测内容类型 → 切块 → 批量生成向量 → 批量写入source_embedding表」。这也是为什么进度条完成后 Source 即可对话使用——检索所需的文本已就绪向量在后台补齐。以process_source命令为入口的后台任务还带有健壮的重试策略最多 15 次、指数抖动退避1-120 秒但对ValueError/ConfigurationError这类确定性错误不重试见 commands/source_commands.py。分类型实操步骤PDF最佳实践纯文字 PDF 1. 上传 → 完成 2. 处理时间约 30-60 秒 扫描版 / 图片型 PDF 1. 同样方式上传 2. 系统自动识别并启用 OCR 3. 处理时间约 2-3 分钟 4. OCR 带来额外开销耗时更高 大型 PDF50 页以上 1. 考虑拆分为多个小文件 2. 或按原样上传系统能处理 3. 处理时间随体量线性增长常见问题报错 Cant extract text → PDF 损坏或带复制保护对策先用 Adobe 打开试试。如果连 Adobe 都打不开该 PDF 很可能受保护。网页链接 / 文章最佳实践1. 从浏览器复制完整 URLhttps://example.com/article-title 2. 粘贴到 Web Link 3. 点击 Add 4. 等待抽取 处理时间通常 5-15 秒可以成功标准网页文章、博客、新闻、Wikipedia 页面、Medium、Substack 文章。无法成功Twitter 帖子串不可靠付费墙文章无法访问JavaScript 重度站点内容无法抽取专业建议如果链接抽取失败把文章正文复制后改用 Text 方式粘贴即可。前端添加对话框同时支持给链接打标签、关联多个笔记本以及附带变换transformations可参考 frontend/src/components/sources/AddSourceDialog.tsx。音频文件最佳实践1. 确保在 Settings 中启用语音转文本 2. 上传 MP3、WAV 或 M4A 文件 3. 系统自动转写为文本 4. 处理时间每 5 分钟音频约 1 分钟 示例 - 1 小时播客 → 约 12 分钟处理 - 10 分钟录音 → 约 2 分钟处理音质至关重要清晰音频转写快模糊/嘈杂音频转写慢且准确率下降背景噪音上传前尽量消除提示若音质差AI 可能误解内容。必要时可手动修正转写稿。YouTube 视频两种添加方式方式一直接 URL 1. 复制 YouTube 链接https://www.youtube.com/watch?v... 普通 watch、/live/、/shorts/ 链接均可用 2. 粘贴到 Web Link 3. 点击 Add 4. 系统抽取字幕若有 转写 方式二播放列表 1. 粘贴播放列表 URL 2. 系统将每个视频作为独立 Source 添加 3. 每个视频分别处理 4. 耗时更长视频较多抽取内容字幕/副标题若可用、转写文本若无字幕、基础元数据标题、频道、时长。处理时长10 分钟视频约 2-3 分钟1 小时视频约 10-15 分钟文本 / 粘贴内容最佳实践1. 添加 Source 时选择 Text 2. 粘贴或输入内容 3. 系统立即处理 4. 无需等待 适合 - 想引用的笔记 - 书中摘录 - 手头现成的文稿 - 快速研究片段管理你的 Sources查看来源详情点击 Source → 可查看 - 原始文件名/标题 - 添加时间 - 大小与格式 - 处理状态 - 分块数量详情接口还会返回该来源是否已嵌入embedded、已嵌入块数embedded_chunks、关联的命令 ID 与处理进度元数据以及原始文件是否仍可在服务器上访问file_available见 api/routers/sources.py 的get_source。列表接口支持按type、title、created、updated、insights_count、embedded排序并带分页limit1-100、offset。每当打开某个来源详情系统还会在后台更新last_viewed_at时间戳以支撑「最近查看」功能。用元数据组织来源每个 Source 都可以补充标题Title比原始文件名更友好的命名标签Tags分类标签例如 primary research、background、competitor analysis描述Description几句内容说明为什么重要让来源更易检索辅助 Chat 场景下的上下文构建便于组织大型笔记本在领域模型中Source 的标题与标签分别对应title与topics字段可通过PUT /sources/{id}接口update_source只更新传入的字段或界面直接修改见 open_notebook/domain/notebook.py 与 api/routers/sources.py。删除来源时Source.delete()会一并清理上传文件、source_embedding与source_insight记录避免产生孤儿数据。在来源内搜索来源添加完成后你可以 文本搜索找确切词组 向量搜索找概念相近内容 两种搜索都覆盖笔记本内全部来源。 结果会显示 - 来自哪个来源 - 命中的段落 - 相关度得分两者在代码中的入口分别是 open_notebook/domain/notebook.py 的text_search调用 SurrealDB 的全文检索函数与vector_search先调用generate_embedding生成查询向量再执行向量检索。文本检索在高亮出现字节位置溢出时会自动回退到向量搜索以保证可用性。上下文管理Sources 如何被使用你可以控制 AI 访问来源的方式。对 Chat 而言共有三个层级完整内容Full ContentAI 看到完整来源文本 成本100% token 适用需要精读分析、精确引用时 示例仔细分析这篇方法学论文仅摘要Summary OnlyAI 看到AI 生成的摘要而非全文 成本约 10-20% token 适用背景材料、参考上下文 示例把它当作背景但聚焦主来源不在上下文中Not in ContextAI 看到无被排除 成本0 token 适用机密、不相关或已归档 示例保留在笔记本里但本次对话不要使用如何在 Chat 中设置上下文1. 进入 Chat 2. 点击 Select Context Sources 3. 对每个来源 - 开关 ON/OFF包含/排除 - 选择层级Full/Summary/Excluded 4. 点击 Save 5. Chat 随即使用这些设置从源码看来源之所以能按「全文 / 摘要 / 排除」灵活注入是因为领域层提供了细粒度的上下文读取方法Source.get_context()支持short/long两种规格long会携带完整正文与洞察insightsshort仅返回标题与洞察Notebook.get_context()则把这些片段组装为带## Source:/## Note:标题的结构化长文供 Chat、播客等下游使用见 open_notebook/domain/notebook.py。界面侧的上下文选择器与切换控件见 frontend/src/components/common/ContextIndicator.tsx 与 frontend/src/components/common/ContextToggle.tsx。常见错误错误后果对策一次性上传 200 个来源系统变慢、处理停滞一次添加 10-20 个等处理完成所有来源都用完整内容token 消耗飙升、成本高背景材料用 Summary 或 Excluded上传超大 PDF 而不拆分处理慢、搜索结果不精确考虑把大 PDF 拆成章节忘记给来源命名相似来源难以区分上传后立即用描述性标题重命名不添加标签日后难查找、难组织立即加标签primary、background 等一个来源混用多种语言转写/向量质量下降每种语言单独成来源重复使用同一来源多次占用空间、造成混淆只添加一次在多个 Chat/笔记本中复用处理状态与故障排查状态指示的含义 处理中 (Processing) → 来源正在抽取与向量化 → 等待 30 秒 - 3 分钟取决于大小 → 暂时不要用于 Chat 就绪 (Ready) → 来源已处理完成且可搜索 → 可立即用于 Chat → 可应用 Transformations 错误 (Error) → 出了某些问题 → 常见原因 - 不支持的格式 - 文件过大或损坏 - 网络超时 ⚪ 不在上下文中 (Not in Context) → 来源已添加但被排除出 Chat → 仍可搜索但不会发给 AI这些状态标签直接来自后台命令的实时状态。每个 Source 关联一个command记录指向 surreal-commands 的处理任务Source.get_status()返回 queued/running/completed/failed 等状态get_processing_progress()返回起止时间与错误信息。异步创建路径会把状态初始化为new并标记queued同步路径则直接等待最多 5 分钟的执行结果见 api/routers/sources.py 的_create_source_async_path/_create_source_sync_path。处理失败或卡住的来源可以在界面一键重试重试接口POST /sources/{id}/retry会重新提交process_source命令并总是启用向量化。常见错误及解决Unsupported file type不支持的文件类型你上传了格式清单之外的文件如.webp图片上传会立即被拒绝并提示检测到的类型——不会长时间卡在 Processing 状态注意图片格式PNG/JPEG/TIFF/BMP仅在启用 Docling时受支持OPEN_NOTEBOOK_ENABLE_DOCLINGtrue对策转换成支持格式文档用 PDF、音频用 MP3或启用 Docling 以支持图片Processing timeout处理超时文件过大100MB或音频过长对策拆分成更小的片段或重新上传Transcription failed转写失败音频质量太差或未能识别语言对策用更好的质量重新录制或手动粘贴文本转写稿Web link wont extract网页链接抽取失败网站阻止自动化访问或内容依赖 JavaScript 渲染对策尝试不同的 URL 处理引擎见内容处理引擎指南——启用 Crawl4AI 可渲染 JavaScript 页面——或者复制文章正文后以 Text 方式粘贴最佳效果建议对 PDF干净的数字版 PDF 效果最好如有复制保护请先解除须合法扫描版 PDF 可用但耗时更长对网页文章使用包含域名的完整 URL避开满是 Cookie/弹窗的站点若抽取失败改用复制粘贴正文对音频清晰、录音良好的音频转写效果更好尽量去除背景噪音YouTube 视频通常自带良好转写对大文档考虑拆分成更小的来源搜索结果更精确小片段处理更快对组织管理给来源清晰命名不要叫 document_2.pdf上传后立即添加标签复杂文档用描述说明内容添加之后使用你的 Sources一旦添加完成来源即可驱动多种下游能力Chat→ 提问对话见 有效使用 ChatSearch→ 检索具体内容见 搜索指南Transformations→ 抽取结构化洞察见 笔记使用Ask→ 获取综合答案见 搜索指南Podcasts→ 转为音频见 创建播客值得注意的是你在添加来源时还可以顺带挂载变换transformations表单中的transformations字段支持传入一组预定义变换 ID后台处理完来源后会自动对全文运行这些变换并生成 insights见 api/routers/sources.py 与 open_notebook/graphs/source.py 中trigger_transformations的条件分支。行动清单添加来源之前逐项确认文件是支持的格式文件小于 100MB或对大型文件做了拆分网页链接是完整 URL而非短链音频文件发音清晰若依赖转写已给来源清晰命名已添加标签便于组织已理解上下文层级Full/Summary/Excluded完成以上确认后来源即可用于 Chat、Search、Transformations 及其他一切后续流程——这正是 Open Notebook 从「收集」走向「研究产出」的关键一步。【免费下载链接】open-notebookAn Open Source implementation of Notebook LM with more flexibility and features项目地址: https://gitcode.com/GitHub_Trending/op/open-notebook创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考