同一个大模型，3 款知识库工具差距这么大？我把它们都逼出错误了

用同一台 RTX 5070 Ti、同一个 qwen2.5:7b、同一份企业文档、同样的 5 个问题，实测 Cherry Studio、AnythingLLM、Dify 三款本地知识库工具。结果：两家满分，一家在关键问题上当场卡死。本文记录完整的测试过程、真实数据和一路踩过的坑。

一、测试背景：为什么要做这个对比

上一篇《Ollama 部署 Qwen3 显存不足？3 个方案亲测有效》里，我把 qwen2.5:7b 跑在了本地 GPU 上。但"能聊天"和"能干活"中间还差一个东西——企业知识库（RAG）。

很多公司想上本地大模型，真正的痛点不是模型本身，而是：怎么让模型回答自己公司文档里的问题。市面上的工具一抓一大把，宣传语都很美，但没有一个肯把"实测数据"亮出来。

所以我自己做了一轮横评：

• 硬件：RTX 5070 Ti 16GB

• 模型：qwen2.5:7b（Ollama 0.40.12 部署）

• 语料：4 份虚构的无人机企业文档（产品手册、售后 FAQ、作业规范、电池维护手册），共约 4000 字，答案全部埋在文档里

• 测试题：5 道，难度递进，最后一道是跨文档推理题——需要同时理解"288Wh"和"≤100Wh 才能登机"两条分布在不同位置的规则

• 判分：人工核对答案是否正确、是否引用了正确的文档

先说结论：

如果你赶时间：不想折腾选 AnythingLLM，想搭企业级服务选 Dify，Cherry Studio 当聊天客户端很好、当知识库入口要谨慎。想知道那个"卡死"是怎么发生的，接着往下看。

二、测试语料设计：埋了三个坑

测试语料是 4 份 Markdown 文档，模拟典型的企业知识场景：

5 道测试题：

Q4 是个陷阱题：答案在"电池维护手册"里，但手册的标题是《智能电池 TB-80 维护手册》，问题里没有出现"TB-80"或"维护手册"这些字眼。Q5 更狠：模型要先找到 288Wh 这个数字，再找到"≤100Wh 才能随身携带"的规则，两段信息隔了半个文档。

三、实测结果与关键发现

3.1 Cherry Studio：败在"让模型自己决定何时检索"

Cherry Studio 是三者里界面最精致、上手最快的：装好 → 设置里填 Ollama 地址 → 建知识库 → 拖入文档，全程点鼠标，5 分钟搞定。前 3 题它也答得不错：

• Q1：✅ 42 分钟，还主动补充了"抗风 6 级续航降至 31 分钟"和"低温预热 5 分钟"——比标准答案还丰富

• Q2：✅ 不能用 + 补充了回收处置建议

• Q3：✅ 三级分级 + 一级 24 小时

然后 Q4，它露出了马脚。回答界面出现了一段奇怪的输出：

为了回答关于电池长期存放时电量保持多少的问题，
我将搜索知识库"kbtest"以获取相关信息。

Ronaldo
{"name": "kb_search", "arguments": {"query": "电池长期存放电量保持", …}}

答案在这里戛然而止——模型调用了 kb_search 工具，然后就没有然后了，它陷在工具调用里没能走出来，最终没有给出任何回答。

这就是 Cherry Studio 和另外两家的本质区别：它用的是 Agent 式检索——把知识库做成一个工具，让模型自己判断"这个问题要不要查知识库、查什么关键词"。这种设计灵活（模型可以多轮检索、组合检索），但代价是把稳定性押在了小模型的工具调用能力上。qwen2.5:7b 在这个环节掉链子了：它生成了调用参数，却没能等工具结果回来继续作答。

而 AnythingLLM 和 Dify 用的是注入式 RAG：用户问题进来 → 先固定执行一次向量检索 → 把检索到的文本片段拼进提示词 → 模型只负责"阅读理解"。流程虽笨，但每一步都是确定性的，不存在"卡住"这个状态。

顺带一提，Cherry Studio 的生成速度只有 9~10 token/秒——远低于裸模型实测的 47.6 token/秒。原因是知识库问答把系统提示词撑到了 8000~9500 token，长上下文显著拖慢了解码速度。知识库场景下，"裸模型跑分"高不等于"实际体验"好，这是我做这个测试前没想到的。

3.2 AnythingLLM：无脑装，但装桌面版会翻车

AnythingLLM 的测试结果无可挑剔：5/5 全对，包括最难的 Q5：

Q5 回答：根据电池维护手册，288Wh 超过 100Wh 限制，不能随身携带登机，需要货运申报 ✅

每题耗时 19.5~31.1 秒，平均 27 秒——比 Dify 慢，但对"公司内部问答"场景完全够用。

不过它有个大坑要先提醒你：别装桌面版。我一开始下载了 Windows 桌面版，启动后卡在 100% 白屏。翻日志发现是内置数据库的 Prisma 迁移失败（PRISMA:MIGRATION EXITCODE:1），这是个能搜到一长串 GitHub issue 的老问题。换 Docker 版一切正常。

Docker 版的初始化比我预想的麻烦一点：它没有配置文件，所有设置存数据库里。我是直接进容器用 Node 脚本改库完成的 LLM 配置和 API 密钥生成。对普通用户来说，正常路径是走完网页引导，我在文章末尾会给出"如果引导卡住怎么办"的备选方案。

3.3 Dify：最快最准，但部署配置是"纯手工活"

Dify 的成绩单最漂亮：5/5 全对 + 平均 17 秒 + Q4 只花 6.4 秒（Cherry Studio 卡死的那道题）。

有个反直觉的细节值得单独说：我测了 Dify 的纯向量检索质量，发现它并不好——5 道题里有 4 道，排序第一的召回结果都是错误文档（比如问电池续航，召回来的是"固件升级失败怎么办"）。但它最终 QA 依然全对，因为 top-4 召回里包含了正确片段，模型在生成阶段把正确答案"捞"了出来。

这给我一个重要启发：端到端效果 ≉ 检索精度。生成模型对噪声的容错能力比想象中强，一段"正确但排第 3"的上下文，照样能产出正确答案。当然这不意味着检索质量不重要——语料规模上千份后，噪声会淹没信号，那时就得上 rerank 模型了。这就是为什么 Dify 的检索架构里预留了 rerank 插槽，而小工具们没有。

代价是：Dify 是三款里部署配置最重的。它是插件化架构，装完 Docker 套装后一个模型供应商都没有，需要手动装 Ollama 插件、手动添加 LLM 和 embedding 模型、手动设置默认模型。这个流程走通了价值很大（企业里就该用 Dify 这种可审计、可编排的形态），但个人玩家第一次接触会被劝退。

四、踩坑实录（这部分可能对你更有用）

横评过程本身踩的坑，比测试结果更值钱。如果你也打算走这条路，这里是完整的雷区地图：

① Dify 1.18 初始化接口返回 422 新版加了"初始化密码"护栏。解法：在 docker/.env 里加 INIT_PASSWORD=你的密码，重启 api/worker 容器，浏览器打开 http://localhost 会先要求输初始化密码，然后才是设置管理员账号。

② AnythingLLM 桌面版卡 100% Prisma 迁移失败的已知问题，直接换 Docker 版。

③ Dify 索引文档全部报错 报错 PGVECTOR_PASSWORD is required。原因是官方 .env 是精简版，pgvector 的连接配置不在里面。需要在 .env 补上：

PGVECTOR_HOST=pgvector
PGVECTOR_PORT=5432
PGVECTOR_USER=postgres
PGVECTOR_PASSWORD=difyai123456
PGVECTOR_DATABASE=dify

然后重启容器，对报错文档执行"重试索引"。

④ Ollama 旧版本会让知识库工具集体哑火 我一开始用的是 Ollama 0.5.7，AnythingLLM 对它发起的模型能力查询返回空，问答直接变成空回复。升级到新版 Ollama 后恢复正常。如果你也遇到"知识库工具连不上模型"，先检查 Ollama 版本。

⑤ 嵌入模型别用 LLM 充数 RAG 需要专门的 embedding 模型把文本转向量。我用的组合是 qwen2.5:7b（生成）+ nomic-embed-text（嵌入，仅 274MB）。ollama pull nomic-embed-text 一条命令的事，但很多人会漏掉这步。

五、怎么选（以及本系列的下一步）

三款工具代表三种真实需求：

• 个人电脑随便玩玩 → Cherry Studio。安装包双击就用，知识库功能对 7B 模型的容错有限，但个人笔记量级问题不大。重要问题多问一遍，防止它卡死你没发现。

• 小团队/公司内部知识库 → AnythingLLM。全对的成绩 + 最低的配置成本，Docker 起一个容器就能给全组人用。记得绕开桌面版。

• 要做成正经产品/接 API/编排工作流 → Dify。它慢一点点、配置烦一点点，但它给出的知识库 API 是可以拿去对接业务系统的——本次测试里我的 5 道题就是全程 API 调用完成的，没有任何一次手动点击。

这个系列接下来两篇：

数据说明：本文所有耗时均为本机实测（RTX 5070 Ti / qwen2.5:7b / 4 文档约 4000 字），你的数据会因硬件和语料不同而变化，但"注入式 RAG 比 Agent 式 RAG 稳"这个结论与硬件无关。