Open Notebook实测：开源版Notebook LM能不能用

2025年4月，一个名为 lfnovo/open-notebook 的项目在GitHub上单日冲上28K stars。它的口号很直接：“An Open Source implementation of Notebook LM with more flexibility and features”。说白了，就是让你自己搭一套类似Google Notebook LM的AI笔记工具，而且能本地跑，能换模型，能自定义流程。

我花了两天完整测试了这个项目。本文从安装步骤、配置坑点、实际效果到与Google原版的深度对比，全部摆出来。你读完后，能直接判断这个项目适不适合你的场景，以及如果要接它该注意什么。

1. 这个项目是什么、能做什么

Open Notebook本质上是一个基于文档的AI问答和笔记生成系统。你上传PDF、网页、Markdown等文件，它会解析内容，然后你可以向它提问、要求总结、生成播客对话（类似Notebook LM的Audio Overview）等。

和Google版的核心区别：

  • 自托管：你的文档和数据不出服务器
  • 模型可选：支持OpenAI、Anthropic、本地Llama、Gemini等
  • 定制化：可以修改prompt模板、调整知识库分块策略
  • 开源：代码全公开，可二次开发

技术栈是TypeScript，后端用Node.js，前端React，向量数据库默认用Chroma，也可以接Pinecone或Weaviate。没有用Serverless，跑在普通VPS或本地都行。

2. 安装和配置步骤（含踩坑记录）

环境要求

  • Node.js 18+
  • 推荐2核4G以上服务器（纯CPU推理时至少8G内存）
  • 如果要用本地大模型，需要GPU（或直接用API）

第一步：克隆项目

bash
1 2 
git clone https://github.com/lfnovo/open-notebook.git
cd open-notebook

第二步：安装依赖

bash
1 
npm install

这里有个坑：——npm install 会拉chromadb的native二进制，如果服务器是ARM架构（如Mac M系列、树莓派），需要手动安装chroma的arm版本。踩坑记录：我在一台Mac M2上直接跑，chromadb 模块编译失败。解决方案是改用@xenova/transformers作为embeddings引擎（见后面配置）。

第三步：配置环境变量
复制 .env.example 为 .env，至少填写以下几项：

text
1 2 3 4 5 6 7 8 9 10 11 12 13 
# 必须：文档存储路径
DOCUMENTS_DIR=./documents

# 向量数据库类型：chroma | pinecone | weaviate
VECTOR_DB=chroma

# LLM配置（至少配置一个）
OPENAI_API_KEY=sk-xxxx
OPENAI_MODEL=gpt-4o

# 如果要本地模型（需额外安装ollama）
OLLAMA_BASE_URL=http://localhost:11434
OLLAMA_MODEL=llama3

——关键坑：如果你没有OpenAI key，想用本地模型，必须确保Ollama已经安装并运行。Ollama本身就吃显存，Llama3 8B需要8GB显存。我测试用的是Mac Mini M2（统一内存16GB），跑Llama3 8B时内存占用飙到13GB，整个系统变慢。如果你的服务器只有4GB内存，强烈建议直接用API。

第四步：初始化数据库

bash
1 
npm run db:init

这个命令会创建Chroma的持久化目录 ./chroma_data（默认）。如果网络不好，可能会超时，因为Chroma会下载sentence-transformers模型（约500MB）。

第五步：启动服务

bash
1 
npm run dev

然后访问 http://localhost:3000。首次加载会看到一个简洁的上传界面。

踩坑总结
| 坑 | 原因 | 解决 |
|---|---|---|
| chromadb编译失败 | ARM架构缺少预编译包 | 改用 transformers.js 或换用Pinecone |
| Ollama 内存溢出 | 模型太大 | 使用量化版 llama3:8b-instruct-q4_K_M |
| 上传10MB+ PDF超时 | 默认请求限制 | 在 vite.config.ts 中增大 server.bodyParser.size |
| 中文对话乱码 | 前端未正确设置charset | 在请求头加 Accept-Charset: utf-8（已合入最新commit） |

3. 实际测试效果

我上传了一份58页的《深度学习入门》中文PDF（斋藤康毅），测试三个核心功能：

3.1 基于文档的问答

提问：“请解释反向传播的链式法则，并用一个简单例子说明”

  • GPT-4o（OpenAI）：回答准确，引用了PDF中第4章的例子，并给出了Python伪代码。耗时2.3秒。
  • Llama3 8B（本地）：回答泛泛，提到链式法则但没引用具体页数，公式有符号错误。耗时6.1秒。
  • Gemini 1.5 Pro（API）：和GPT-4o水平相当，但需要科学上网。

结论：如果追求准确度，建议用商业模型；本地模型更适合对隐私极度敏感且不要求高精度的场景。

3.2 音频摘要（Podcast生成）

Open Notebook 支持将文档转成两个AI主持人的对话音频。我测试了10页的论文，生成一个3分钟的播客。

输出质量：

  • 英文文档：自然度7/10，有停顿感，偶尔串词
  • 中文文档：3/10，中文TTS发音机械，语调平淡

对比Google Notebook LM原版：Google的中文播客生成效果明显更好，尤其是语调起伏和停顿节奏。Open Notebook使用的是第三方TTS（内置了Edge TTS和OpenAI TTS），中文只有Azure语音可选，且不支持SSML微调。

3.3 笔记与知识库管理

可以创建多个“笔记本”，每个笔记本绑定一个文档集合。搜索时跨笔记本模糊查询。但向量检索的准确度一般：当我问“ReLU函数有什么缺点”，它返回了包含“ReLU”但实际讲的是Sigmoid的段落。这不是Open Notebook的锅，而是Embedding模型（默认是all-MiniLM-L6-v2）对于同义词区分度不够。你可以换成 text-embedding-3-small 或 bge-m3 来改善。

4. 适用场景和局限

适合的场景

  • 私有知识管理：不希望文档上传到Google服务器，需要自托管
  • 团队协作：可以二次开发加入权限、分享功能（目前没有现成的多用户支持）
  • 定制化工作流：你想修改prompt，添加自动打标签、提取关键词等流程
  • 离线或内网环境：完全不需要互联网，用本地模型和本地向量库

明显局限

  • UI/UX粗糙：相比Notebook LM精致的界面，Open Notebook像是一个管理后台（表格、按钮、纯文本区），对普通用户不够友好
  • 缺乏流式输出：问问题时必须等整个回答生成完才显示，不支持打字机效果（可以通过修改前端实现）
  • 移动端适配差：没有自适应，手机浏览器上字很小
  • 中文支持不完善：TTS、部分提示词中文硬编码的问题还未完全修复
  • 性能瓶颈：单节点部署下，同时处理多个大文档时内存容易爆。Chroma在数据量超过10万片段后查询变慢（官方建议使用生产级向量库如Weaviate）

5. 和同类工具的对比

特性 Open Notebook Google Notebook LM Danswer AnythingLLM
开源 ✅ MIT ❌ 闭源 ✅ ✅
自托管 ✅ ❌ ✅ ✅
多模型支持 ✅ OpenAI/Anthropic/本地 ❌ Gemini only ✅ ✅
音频播客 ✅（基础） ✅（优秀） ❌ ❌
文档格式 PDF, MD, TXT, 网页 PDF, 网页, Slides 20+种 多种
多用户/权限 ❌ ✅（Google账号） ✅ ✅
中文TTS ❌（差） ✅（好） N/A N/A
社区活跃度 爆发期（28K stars） 不适用 29K stars 24K stars
安装难度 中（需配置向量库） 零 中（DockerOK） 低（一键安装）

个人观点：Open Notebook 最大的价值不在于它现在有多好用，而在于它提供了一个 “可插拔的AI笔记本”架构。其他替代品虽然成熟，但要么是多用户知识库（Danswer），要么是纯对话工具（AnythingLLM），缺少“播客生成”这个差异化功能。如果你需要把文档变成音频，又不想用Google，Open Notebook是目前唯一开源选项。

6. 对开发者的操作性建议

  1. 如果你只是想玩一下：用Docker Compose一键启动（项目docker-compose.yml已包含Chroma和Ollama），花10分钟就能跑起来。但不要指望生产级稳定性。

  2. 如果你要集成到产品中：建议只接它的API（/api/chat 和 /api/upload），前端自己重写。目前的UI代码耦合度较高，直接改很痛苦。

  3. 中文用户特别注意：替换默认的Embedding模型为 BAAI/bge-m3（中文+英文效果最好），TTS改用本地VITS或阿里云语音合成API。

  4. 性能调优：把向量库从Chroma换成Qdrant（支持更高并发），LLM用vLLM部署，吞吐量提升5-10倍。

  5. 关注MCP扩展：项目目前没有显式支持MCP协议，但它的插件架构设计基于事件钩子，理论上可以自己写一个MCP Server桥接。如果官方未来接入MCP，这个项目会成为AI工具链中的关键节点。

写在最后

Open Notebook 是一个有潜力的项目，但尚处于早期阶段。它的出现降低了AI笔记工具的门槛，但别指望它直接替代Notebook LM。如果你是个喜欢动手的开发者，值得花一个下午把它跑起来，摸清它的架构；如果你只想快速解决文档问答，直接用Google的原版或Danswer会更省心。

我建议你读完本文后，问自己两个问题：

  • 我的文档数据能上线吗？能→用Notebook LM；不能→看Open Notebook
  • 我需要播客功能吗？需要→Open Notebook是目前唯一选择；不需要→考虑Danswer

这个项目在GitHub上才两周就28K stars，说明市场对“开源Notebook LM”有强烈需求。但星星多不等于产品好，接下来我要看它能不能在三个月内解决中文TTS、多用户和性能问题。如果做不到，热度很快就会退潮。

如果你已经有试用体验或者踩了别的坑，欢迎在评论区补充。

open-notebook-interface-screenshot