同一批30份资料喂给三个知识库：NotebookLM、Cherry Studio、Open WebUI 到底怎么选？

编辑说明：由于大纲未提供原始测试日志、工具版本、硬件配置和逐题评分结果，本文不会虚构正确率、耗时或费用。涉及这些数据的位置均保留为“待实测录入”，正式发布前应根据截图、评分表和 API 账单补齐。

我把同一批30份内部资料分别导入三个知识库，再向它们提出同一个问题。

理想情况是，三款工具都能从资料里找到答案。但实际更可能出现三种截然不同的结果：一个总结得很漂亮，却没有充分证据；一个找对了文档，却引用错了段落；另一个答案更可控，但从部署到调通检索链路，需要处理解析、切片、嵌入和模型接口。

这正是知识库选型最容易踩的坑：

我们以为自己在比较“谁回答得更聪明”，实际上是在选择三套完全不同的数据、检索和维护路线。

NotebookLM 更像一位会标注出处的资料研究员；Cherry Studio 更像一套面向个人和小团队的知识库工作台；Open WebUI 则更接近一套需要自己建设和维护的 AI 基础设施。

它们没有统一赢家，只有不同取舍。

一、这不是模型跑分，而是三条知识库路线的对照实验

本次测试的原则很简单：同一批资料、同一组问题、同一套人工评分标准。

测试资料共30份，按照真实团队文件夹的常见结构组合：

页数、总字数和文件大小不能凭印象填写。正式测试时，应通过脚本或文档统计工具生成完整清单：

总页数：<待实测录入>
可提取文本总字数：<待实测录入>
文件总大小：<待实测录入>
扫描件页数：<待实测录入>
最大单文件大小：<待实测录入>

问题集建议设置为24道，其中包括：

• 10道可以在单份文档中直接定位的事实题
• 7道需要跨文档归纳的综合题
• 4道涉及历史版本或相似术语的冲突题
• 3道资料中根本没有答案的陷阱题

每道题连续测试3次，由3名评分人员独立核验。评分时不能只看“意思差不多”，而要逐项检查：

1. 答案是否正确；

2. 结论是否完全来自资料；

3. 引用是否真正支持结论；

4. 能否点击或快速定位原文；

5. 是否遗漏相反证据；

6. 没有答案时，是否明确拒答；

7. 多次回答是否出现明显波动。

必须锁定的测试环境

为了让结果可以复核，报告中还应公开以下信息：

这里尤其要强调：NotebookLM 的模型与检索链路相对封闭，Cherry Studio 和 Open WebUI 则可以更换对话模型、嵌入模型及重排服务。因此，本文比较的不是单纯的“大模型智力”，而是从导入资料到核验答案的完整使用体验。

二、四道题，最容易看出知识库的真实水平

1. 精确事实题：制度从哪一天开始执行？

《费用报销管理制度》从哪一天开始执行？请给出依据。

标准答案必须来自制度中的生效条款，而不是文件创建时间、发布日期或审批日期。

• NotebookLM：重点检查引用能否直接跳到包含“自某日起施行”的原文，而不是只引用封面或审批页。
• Cherry Studio：检查切片是否把制度名称、生效日期和适用范围拆开。如果三个信息落在不同片段中，答案可能只找对日期，却无法提供完整依据。
• Open WebUI：除答案外，还要检查命中的知识片段、文档元数据和检索排序，确认问题出在解析、召回还是生成阶段。

人工核验时，只有“日期正确且引用支持该日期”才能算完全正确。答案正确但引用错段，不能给满分。

2. 跨文档归纳题：三个季度的变化原因是什么？

根据第一、第二、第三季度报告，某项指标变化的主要原因是什么？请区分各季度因素与共同因素。

这道题考验的不是关键词搜索，而是跨文档组织能力。

NotebookLM 的优势通常体现在阅读和归纳路径上，但仍要检查它是否遗漏某一季度的反向证据。Cherry Studio 与 Open WebUI 的结果则更依赖召回数量：如果只取回少量片段，模型即使推理能力再强，也无法总结没有进入上下文的材料。

人工评分应拆成三部分：

• 是否覆盖全部季度；
• 是否区分单季度因素与共同因素；
• 每个结论能否回到对应报告核验。

RAG最危险的错误，不是明显答错，而是只看见一半资料后，给出一个听起来非常完整的答案。

3. 版本冲突题：新旧制度不一致时怎么办？

新旧两版制度对审批额度的规定是否一致？当前应以哪一版为准？

资料库中故意保留两份名称相近、内容冲突的文件。如果知识库只依赖语义相似度，很可能同时命中新旧版本，却没有正确识别生效时间。

• NotebookLM 需要证明它不仅找到两份资料，还能区分发布日期、生效日期和废止说明。
• Cherry Studio 要检查文件名、版本号、日期等元数据是否进入了可检索范围。
• Open WebUI 则可以通过元数据过滤、集合拆分或检索规则增强版本控制，但这些能力需要主动配置。

正确回答不应只给一个额度，而应明确指出：旧版如何规定、新版如何修改、当前结论依据哪份文件。

4. 无答案题：工具会拒答，还是顺手编一个？

资料中提到的项目，下一年度预算具体是多少？

如果30份资料中没有下一年度预算，最好的答案不是“根据当前趋势预计……”，而是：

现有资料未提供下一年度预算，无法从知识库中确认。

这类题尤其适合检测生成模型的“热心过头”。系统提示词可以要求模型仅根据资料回答，但真正决定拒答效果的，还有检索阈值、上下文内容和模型自身的指令遵循能力。

三款工具都应该重复测试，记录是否出现：

• 明确拒答；
• 用历史数据代替未来预算；
• 给出没有出处的推测；
• 引用相关但不支持结论的片段。

三、三条路线的真实差异

NotebookLM：最像“会标出处的资料研究员”

NotebookLM 最突出的价值，不只是答案写得顺，而是让用户更容易完成“答案—引用—原文”的核验闭环。

对于研究报告、会议记录、制度文件和访谈材料，这种体验非常重要。你不必先理解向量数据库、嵌入模型和切片参数，也能较快进入阅读与提问状态。

但引用存在，不等于结论必然可靠。测试中仍要重点检查：

• 引用片段是否真的支持整句话；
• 是否漏掉其他文件中的反例；
• 中文扫描件是否完成了有效识别；
• 复杂表格的行列关系是否被保留；
• 历史版本是否被错误合并。

它更适合重视阅读、总结和引用核验，并且允许资料进入相应云端处理流程的个人与小团队。

如果企业要求完全本地化、自由切换模型、细粒度权限或复杂系统集成，NotebookLM 就不一定是合适答案。

Cherry Studio：搭得快，但结果高度依赖配置

Cherry Studio 对中国用户更友好的地方，在于中文桌面界面、多模型接入和相对直观的知识库操作。对于已经拥有模型 API 的用户，从导入文件到第一次提问，链路比自建服务短得多。

但“能够提问”不代表“知识库已经调好”。

中文检索结果通常会受到四个环节影响：

• 文档解析：标题、表格和段落是否被正确提取；
• 切片策略：片段太短会丢失上下文，太长又可能稀释关键词；
• 嵌入模型：是否适合中文及当前资料类型；
• 重排模型：能否把真正相关的片段排到前面。

调优前后应使用完全相同的问题重新测试，不能一边更换嵌入模型，一边又更换对话模型，否则无法确定提升来自哪里。

Cherry Studio 适合个人、两三人的轻量团队，以及希望低门槛尝试 RAG、又需要自由切换模型的用户。但多人权限、配置统一、备份恢复和数据边界，需要结合实际版本与使用方式评估，不能仅凭“桌面端运行”就认定全链路离线。

Open WebUI：控制权更高，维护账单也更长

Open WebUI 的关键价值是自托管与扩展能力。它可以运行在服务器、NAS或团队内网中，统一提供模型和知识库入口。

但它不是“免费版 NotebookLM”，而是一套需要长期维护的服务。

一个经过版本锁定后再使用的最小化 Docker 示例为：

docker run -d \
--name open-webui \
-p 3000:8080 \
-v open-webui:/app/backend/data \
--restart unless-stopped \
ghcr.io/open-webui/open-webui:<测试版本号>

不要为了省事直接把 <测试版本号> 改成未经验证的标签。正式部署前，应在测试环境中验证升级、回滚和数据备份。

模型 API 可以按 OpenAI 兼容格式配置：

Base URL: https://example.com/v1
API Key: sk-**
Model: <本次测试使用的模型>

更重要的是，Open WebUI 部署在本地，不等于全链路离线。

必须逐项确认：

如果生成模型使用云端 API，即使原始文档保存在本地，命中的文档片段仍可能被放进提示词并发送给模型服务商。

Open WebUI 更适合拥有服务器、NAS或基础运维能力，明确需要自托管、多人访问和后续扩展的团队。它带来的不是零成本，而是更高的数据控制权。

四、结果总表：不要只看一个总分

由于原始测试记录尚未提供，下表不填入虚构的正确率、耗时和费用。正式发布时，应从逐题评分表、系统监控和 API 账单中计算。

场景结论反而比总分更有意义：

• 最重视引用溯源和快速阅读：优先考虑 NotebookLM。
• 个人或两三人团队，追求快速上手与模型自由：优先考虑 Cherry Studio。
• 资料敏感，需要自托管和多人共用：优先考虑 Open WebUI。
• 零运维，但资料又绝不能上传第三方：三者都未必完美，应重新评估安全边界或企业级方案。
• 本地保存资料，但调用云端模型：Cherry Studio 和 Open WebUI 都可以实现，但检索片段仍可能发送给第三方。

“本地部署免费”是最常见的成本误判

知识库的真实成本至少包括：

• 对话模型、嵌入模型和重排模型的 API 费用；
• 服务器、NAS、硬盘和备份设备；
• CPU、显卡、电费与网络；
• 部署、升级和迁移时间；
• 故障排查及数据恢复；
• 团队培训与权限管理。

开源软件的许可证费用可以是零，但维护它的人不会是零成本。

五、先确定数据边界，再选择工具

在安装任何产品之前，先回答六个问题：

1. 资料是否允许上传第三方云端？

2. 是否必须看到可以核验的原文引用？

3. 是否需要多人访问和统一管理？

4. 团队有没有部署与维护能力？

5. 是否需要自由选择模型与 API？

6. 每月可以接受的真实总成本是多少？

决策路径并不复杂：

• 可以上云，最看重引用和阅读效率：选择 NotebookLM 路线。
• 需要模型自由，主要由一两个人维护：选择 Cherry Studio 路线。
• 必须自托管，并有多人协作与扩展需求：选择 Open WebUI 路线。
• 数据禁止外发：不仅文档要本地，嵌入、重排和生成模型也要逐项核查。

小团队最容易犯的错误，是先安装工具，再讨论数据安全和工作流程。正确顺序应该是：

先给资料分级，再确定部署边界，最后选择知识库工具与模型组合。

接入模型前的检查表

如果决定使用 Cherry Studio 或 Open WebUI，配置模型前至少确认：

• 接口是否兼容当前工具；
• 模型是否适合中文长文本；
• 上下文长度能否覆盖检索片段；
• 嵌入模型与对话模型是否分别计费；
• 服务商是否保存输入内容；
• 是否允许处理内部资料；
• API 密钥能否设置额度和权限；
• 是否有用量记录和费用预警。

可以前往 api.884819.xyz 查看可用接口与配置方式，再根据价格、上下文长度、中文表现和兼容性进行测试。平台使用用户名和密码即可注册，不需要邮箱验证；内置 AI 对话功能，注册后可以直接使用。国产模型如 Deepseek、千问等完全免费，没有月租和订阅，其他模型按量付费。

需要注意的是，接入任何第三方 API 时，都应先确认服务条款与数据处理方式。未经授权，不要上传包含客户信息、商业机密或个人隐私的内部资料。

最后的结论不是谁赢了，而是谁更符合你的边界：

NotebookLM 帮你更快读资料，Cherry Studio 帮你更快搭知识库，Open WebUI 帮你真正掌握知识库；选择哪一个，取决于团队最不愿意牺牲什么。

这次解决的是“选哪个知识库工具”，但还有一个更容易被低估的变量：同一个工具，只要换掉嵌入模型、切片长度或重排模型，中文检索结果就可能发生明显变化。

下一篇，我们会固定同一套知识库和同一批30份中文资料，对照测试5种嵌入模型与4组切片参数，看看哪些设置真的影响召回，哪些只是看起来专业的“参数玄学”。

#AI知识库 #NotebookLM #CherryStudio #OpenWebUI #RAG #AI教程 #8848AI