如何通过 Ollama 挂载本地知识库实现私有文档问答系统

直接把文档喂给 LLM 导致 Token 爆炸或者隐私泄露，最稳妥的方案就是走 RAG（检索增强生成）。我最近把公司内部的 API 文档全部私有化部署到了 Ollama + AnythingLLM 的组合上，基本实现了秒级响应且无需联网。

很多人的误区是觉得得写复杂的 LangChain 脚本，其实现在很多集成工具已经把向量数据库（Vector DB）内置了。我推荐用 AnythingLLM，因为它能直接通过 API 挂载 Ollama 运行的模型，省去了自己写 Python 脚本处理 PDF 分片（Chunking）的麻烦。

具体部署链路：

1. 安装 Ollama 并拉取支持长文本且逻辑能力强的模型。建议用 qwen2.5 或 llama3.1，因为 RAG 对模型的指令遵循能力要求较高，否则很容易出现“文档里有但模型说没有”的情况。

ollama run qwen2.5:7b

2. 在 AnythingLLM 的设置中，将 LLM Provider 选为 Ollama，Base URL 填写 http://host.docker.internal:11434（如果你是用 Docker 跑的）或 http://localhost:11434。

3. 创建一个 Workspace，直接把 PDF 或 Markdown 文档拖进去。关键点在于 Embedding Model 的选择，千万别用 LLM 本身来做向量化，速度极慢。建议在 Ollama 里单独跑一个 nomic-embed-text，然后在 AnythingLLM 的 Embedding 设置里指定它。

ollama pull nomic-embed-text

踩过的坑与优化技巧：

分片大小（Chunk Size）的权衡：默认的分片太小会导致上下文断层。我尝试过 500 token 一个分片，发现对技术文档效果最好。如果分片太大，检索回来的干扰信息太多，模型会开始胡说八道。

提示词微调：为了防止模型在文档找不到答案时强行编造，我在 System Prompt 里加了一段硬约束：

你是一个专业的文档助手。请仅根据提供的上下文回答问题。如果上下文中没有相关信息，请直接回答“文档中未提及”，不要尝试编造答案。

性能调优：如果发现检索速度慢，检查一下是不是在用 CPU 跑 Embedding。一旦换成 nomic-embed-text 这种轻量化模型，配合 GPU 加速，检索延迟能从 3 秒降到 200 毫秒左右。

目前这套方案在处理 50 份左右的内部文档时非常丝滑，完全不需要写一行 Python 代码就能搭建起一套可生产的私有知识库。