解决什么问题

通用大模型不知道你公司产品手册里的参数，不知道你三年的会议纪要定了什么。把文档临时贴进上下文能解决一次对话，但每次手动贴不可持续，也超不过上下文窗口的容量。知识库（RAG）是标准解法：文档离线切分、向量化入库，提问时先检索出最相关的片段，再交给模型作答。

Cherry Studio 内置知识库功能，在桌面端就能完成”导入文档 → 切分向量化 → 问答挂载”全流程，不需要自己搭向量数据库和检索服务。本文以”本地向量模型 + 本地文档”的完全离线方案为主线，云端 embedding 的差异点单独标注。

环境与版本

  • Cherry Studio【待补：版本号】；
  • 向量模型二选一：
    • 本地：Ollama 拉一个 embedding 模型（bge-m3，BAAI 出品、多语言支持好），零 API 成本，文档不出本机；
    • 云端：任意 OpenAI 兼容的 embeddings 接口（如 text-embedding-3-small），不占本机资源，但按量计费且文档要出本机；
  • 对话模型：本地或云端均可。知识库问答对对话模型的要求是”读得懂检索片段、不编造”，不一定非旗舰模型不可；
  • Ollama（选本地方案时），默认服务端口 11434，embedding 走它提供的 OpenAI 兼容接口。

选云端 embedding 的，动手前同样先自检链路（以硅基流动为例，base_url 与模型 ID 以平台文档为准）：

curl https://api.siliconflow.cn/v1/embeddings \
  -H "Authorization: Bearer $SILICONFLOW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"BAAI/bge-m3","input":"云端 embedding 链路自检"}'

返回向量数组即链路可用。注意云端方案的模型 ID 是”厂商/型号”格式（BAAI/bge-m3），和 Ollama 本地的裸型号名不同，填错会导致 404 或空结果。

分步骤

第一步：准备向量模型（本地方案）

ollama pull bge-m3
ollama ls          # 确认模型已就位
curl http://localhost:11434/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{"model":"bge-m3","input":"知识库链路自检"}'

第三条命令返回一个向量数组，说明 embedding 链路是通的。先把底层链路验证掉再进客户端配置，出问题时才能二分定位——是模型端的问题还是客户端配置的问题，一眼可辨。

第二步：在 Cherry Studio 里接入 Ollama

设置 → 供应商 → Ollama，地址填 http://localhost:11434（Ollama 默认端口），保存后模型列表里应出现 bge-m3【待补：界面步骤截图】。如果 Ollama 跑在另一台内网机器上，把 localhost 换成对应内网 IP 即可。

第三步：创建知识库并导入文档

知识库入口 → 创建 → 向量模型选 bge-m3 → 拖入文档。支持的格式与大小上限以官方文档为准【待补：格式清单】，常见的 pdf / markdown / docx / txt 一般都在列。导入后客户端自动完成切分与向量化，等状态变为完成即可【待补：切分大小、重叠比例、top-k 等参数的界面名称与默认值】。

批量导入的建议：按主题分库（产品手册一个库、会议纪要一个库），不要把所有文档倒进一个库——检索范围小，命中精度高，后续重建成本也低。

第四步：挂载知识库问答

对话页挂载刚建好的知识库，提问验证。验证问题有讲究：必须问一个”只有你的文档里才有答案”的问题，比如手册里的具体参数、纪要里的具体决议。通用问题（“什么是机器学习”）测不出检索质量——模型不检索也能答，结果好坏全凭它编。

知识库问答命中检索片段并给出带出处回答的效果

第五步：调优检索质量

答非所问时按顺序排查，每次只改一个变量，用同一组固定测试问题回归：

  1. 切分是否太大，导致片段里混了多个主题；
  2. top-k 是否太小，相关片段没进上下文；
  3. 检索命中的片段本身是否切坏了（表格、代码块被拦腰截断是重灾区）；
  4. 文档质量本身——扫描件没有文本层，检索结果为空，见坑 2。

常见坑

坑 1：换了向量模型，旧知识库直接报废

向量检索的相似度只在同一个模型的向量空间里成立。知识库建完后把 embedding 模型从 bge-m3 换成别的，新旧向量不在同一空间，检索结果变成噪声。结论：向量模型在建库前定好；换模型等于重建库，文档多的话重建成本要提前掂量。

坑 2：扫描版 PDF 看着导入成功，检索全空

扫描件没有文本层，切分出来是空的或乱码，向量化出来的是垃圾。导入前用 PDF 阅读器验证能否选中文字；选不中就先 OCR 再入库。这一步的检查成本是十秒，排查成本是半天。

坑 3：本地模型内存不够

embedding 模型普遍很轻（bge-m3 这类体积在 GB 级），真正吃内存的是本地对话模型：7B 量化版大约需要 4~8 GB 可用内存，8 GB 内存的机器同时跑 embedding 加 7B 对话模型已经贴着上限。资源紧张时的标准折中：对话模型走云端 API，知识库检索留在本地——检索环节才是隐私敏感的部分【待补：bge-m3 实测体积与内存占用】。

坑 4：从 PDF 转换的 Markdown 表格全乱

表格密集的文档（规格书、报价单）从 PDF 转格式后单元格经常错位，切分后语义全毁。优先找原始 markdown 或 docx 源文件入库；实在只有 PDF，考虑把关键表格单独摘出来作为独立文档。

最终效果

搭完后：几十份本地文档变成随问随答的私有知识库，回答能带出检索到的片段作为出处，方便人工核对；数据全程不出本机（本地 embedding + 本地对话模型）；同一套知识库可以被多个助手会话复用。与 Dify 这类自托管 RAG 平台相比，Cherry Studio 的知识库胜在零部署、桌面端即用；需要对外提供服务、多成员协作或复杂工作流编排时，再考虑平台型方案【待补：本机建库耗时与问答延迟实测】。

相关阅读