本地 rag 配 ollama 的开源项目有哪些

你想在自己机器上用 Ollama 跑一套本地 RAG，翻了一圈发现开源项目名字一大堆，每个 README 都写得能打，就是不知道装哪个、装完能不能跑起来。这篇不给排名也不给结论式推荐，只给一套判断标准：先看清你手里有什么硬件、想要多省心的界面，再去对应一类的项目里挑，最后附上装完不通时的排查顺序。

你想在自己机器上用 Ollama 跑一套本地 RAG，翻了一圈发现开源项目名字一大堆，每个 README 都写得能打，就是不知道装哪个、装完能不能跑起来。真正卡人的不是列表短，而是这些项目压根不在一个层面：有的是一整套带界面的知识库应用，有的只是给你调用的框架库，还有的只负责向量存储。把它们混在一张表里比，越比越乱。

这篇不给排名也不给结论式推荐，只给一套判断标准：先看清你手里有什么硬件、想要多省心的界面，再去对应的那一类项目里挑。判断完了再谈装哪个，最后附上装完不通时的排查顺序。核心是让你少走「装完发现根本跑不动」这种弯路。

先按使用场景分堆，再谈装哪个

最有效的第一步不是看项目名，而是先回答两个问题：谁来写代码、要不要图形界面。答案落在哪一档，就直接缩小到那一类项目里挑，别跨类比较。不写代码的人硬上框架库，光搭一个能用的界面就得花掉一整天；反过来，要嵌进自己系统的团队去用完整应用，改起来反而处处受限。

• 先写下你的两个答案：「有没有人要写代码」「有没有人要图形界面」，写在纸上比在脑内想靠谱。
• 答案都是「没有」，往应用类里找；只要有一个「有」，就去看框架库。
• 组件类不要单独当项目选，它是被上面两类调用的，选上层的时候顺带看它默认接哪个就行。
• 如果你只是想知道协议怎么对齐、客户端怎么填地址，那是配置层的事，这篇不碰，去站内相关页面看。

上手前的硬条件：先算清楚你跑得动什么

本地 RAG 和单纯跑一个聊天模型不一样，同一个时刻往往要装两样东西：一个负责生成的模型，一个负责把文本转成向量的模型。这两块都吃显存和内存，机器只能跑其中一个是不够的。装之前先按你的卡把两个模型的占用都算一遍，别只算了大的那个。

双模型占用

生成模型加向量模型的总和，才是你需要预留的资源下限

OCR 开销

扫描件、图片类文档要走版面识别，这部分经常被完全忽略

离线完整性

有些项目默认会去拉线上服务，装前先在配置里找有没有本地开关

端口冲突

本地服务默认监听哪些端口、要不要容器，先想好再装

• 按你的显卡型号把生成模型和向量模型的占用分别查一遍，再加起来，到 /models/deploy 核对当时的数字。
• 给磁盘留出索引和文档解析的空间，扫描件多的话这块会比你想的大。
• 装之前先在配置里全局搜一遍有没有指向线上服务的地址，有就换成本地选项。
• 把要占用的端口列个清单，对照机器上已经在跑的服务，避免装完发现抢端口。

拼装顺序：文档进料 → 切分 → 向量化 → 检索 → 生成

这条链路按顺序逐段验证，每一段单独能通再接下一段。最常见的错误是从头到尾一次性装好，然后发现答得不对，却不知道是哪一段坏了。分段验证的意义在于：出错时你能立刻定位到环节，而不是对着一个模糊的「效果不好」发愁。

1. 验证解析拿一份 PDF 和一份纯文本分别解析，看能不能拿到干净的正文；页眉页脚、表格错乱在打印日志里就能看出来。
2. 验证切分抽一段文字看切出来的块是否完整，断句是否断在句子中间；粒度太碎会让检索召回到一堆残句。
3. 验证向量化直接调向量模型接口，看能不能返回固定长度的向量，再拿同一句话发两次看结果是否一致。
4. 验证检索用一句你确定在原文里的原句去搜，看它能不能被召回；搜不到就说明前面某一段有问题，别急着调参。
5. 验证生成把召回结果和问题一起喂给模型，先不接界面，用命令行看它有没有引用到原句。

切分和向量化这两段最容易被跳过验证，但它们出错时的表现是「答得不准」，很容易被误判成模型不行。混合检索的项目配置项更多，调试时先把关键词那一路关掉，只留向量召回，确认单路能通再打开另一路。

跑不通时的排查顺序

排查讲究顺序，不要跳步。绝大多数「检索不到」的抱怨，真正的原因在前面两步，而不是参数没调好。按下面这个次序走，能省掉大量瞎试的时间。

• 第一步查模型是否真的加载成功，日志里会有加载失败或资源不足的记录，很多问题到这里就结束了。
• 第二步查向量模型和生成模型的地址有没有填反，两个服务的地址和端口被搞混是最高频的一类错误。
• 第三步查文档是否真的进了索引，用一条你确定在原文里的原句去搜，搜不到就是进料环节的问题。
• 第四步才轮到检索参数和提示词，前三条都排除后再调切分粒度和召回条数，别一上来就改参数。
• 如果日志看不懂，先把日志级别调到最详细再复现一次，比反复猜快得多。

什么情况下这套顺序不适用：如果你要的是多轮追问、工具调用这类流程编排，单条链路验证通过不代表整体能跑，那属于另一个工程问题，得单独设计调度和状态管理。

装完别急着用，先做这三项验收

能跑通只是第一步，能不能用得住是另一回事。本地部署的资源水位和线上完全不同，同样的配置在你机器上可能就是另一个表现。验收的核心不是看它答得漂不漂亮，而是看它在你的文档上会不会编。

编造的答案比答不上来更危险，因为你没法一眼看出来。验收时优先盯「有没有引用到文档里的原句」这一条，其余都可以放后面。具体指标和基线怎么定，去 /tools/quality-check 对一遍口径，别只凭主观感受下结论。