先交代我原来怎么用
我手上有一套内容生产的链路。最上游是一个号池网关（sub2api），把 OpenAI、Claude、Gemini、千问几十个账号收进一个池子，对外只露一个 OpenAI 兼容的口子。下游的小说工厂从池子里取一把”只出千问”的 key，让千问写正文，让 Claude 写随笔，路由、重试、模型映射都压在号池这一层。
这套东西的好处是算力跟业务解耦。我的服务器都是小机器——主控那台总共才 3.6G 内存，真要在上面架本地大模型是做梦。可一旦把生成这件事整个外包给号池，服务器就只剩下编排的活，轻得很。
用久了就想再往前走一步：我还有一大堆 Obsidian 笔记，三百多篇，读书笔记、技术记录、计划草稿都在里头。能不能让聊天机器人答问题的时候，先去翻我的笔记，answer 带着出处回来？这就是检索增强，绕不开一个知识库。
候选有两个，都已经在我服务器上跑着：RAGFlow 和 Dify。
我一开始问错了问题
我最初的问法是：“哪个向量检索更强？”
查下来才发现这个问法本身是歪的。向量检索这一步，两者几乎没有区别。
道理也简单。所谓向量检索，就是把你的问题变成一串数字（向量），再去库里找数字最接近的几段文本，算的是余弦相似度。这套数学 RAGFlow 用 Elasticsearch 做，Dify 用 weaviate 做，底层都是成熟的近邻搜索。我的语料才 34M，撑死几万个片段，这种规模的相似度查询，两边都是毫秒级，差异小到我根本感知不到。
换句话说，“检索快慢”压根不是这两个东西的分水岭。我盯着检索比，就像两辆车都在市区限速 60 的路上，我却在争谁的极速更高——极速是真的不一样，可在这条路上跑不出来。
真正的差别在检索的前后两头
把检索这一步放下，差别立刻显出来，全在它的上游和下游。
上游是解析。 这是 RAGFlow 真正的看家本事。它有一套叫 DeepDoc 的东西，能 OCR、能认表格结构、能做版面分析，把一份排版复杂的 PDF、扫描件、带表格的财报拆解得干干净净。Dify 的解析就朴素得多，大体是按段落、按字数切。
可问题是，我喂进去的是什么？是 Obsidian 的 markdown 笔记。标题层级、列表、缩进，本来就是结构化的纯文本，干净得不能再干净。DeepDoc 那套重型解析在 markdown 面前，几乎无事可做。我等于为了一个用不上的强项，去扛它的全部重量。
下游是 embedding，也就是把文本转成向量的那一步。 检索快是快，可”转向量”这件事是要跑模型的，这才是真正吃内存、决定延迟的地方。这一步要么用本地 embedding 模型，要么走 API。对我那台 3.6G、swap 都快吃满的机器，本地模型是碰都不能碰的。
但这里有个关键：embedding 走哪，跟我选 RAGFlow 还是 Dify 没有关系。两边我都可以让它走号池的千问。所以这一项，是打平的——我原来的号池架构，恰好在这里又派上了用场，把最吃资源的一步接着往外包。
还有一头是我差点忽略的：常驻开销
选型不能只看功能，得看它停在那儿不动的时候吃多少。
RAGFlow 是一整套：Elasticsearch、MySQL、MinIO、Redis、任务执行器。光一个 Elasticsearch，JVM 堆默认就要两个 G 起步。这一套空载就吃掉三四个 G。
Dify 用的 weaviate 轻得多，空载几百兆到一个 G，而且它本来就在我机器上跑着，不是新增的负担。
对一台总共 3.6G 的机器，这一栏几乎是判决性的。
把账摊开
| 维度 | RAGFlow | Dify | 对我的意义 |
|---|---|---|---|
| 向量检索速度 | 毫秒级 | 毫秒级 | 打平，感知不到 |
| 检索质量（干净 md） | 略好但优势用不上 | 够用 | 几乎打平 |
| 复杂 PDF / 表格解析 | 强 | 一般 | 我用不到 |
| embedding（都走号池） | 外包 | 外包 | 打平 |
| 常驻内存 | 三四个 G | 不到 1G 且已在跑 | Dify 完胜 |
| 是否新增系统 | 重栈 | 复用现有 | Dify 完胜 |
一句话收尾：我以为在比”谁检索更强”，可检索那一步两边一样快、一样准——我的语料太干净，根本拉不开差距。RAGFlow 的真本事是”啃复杂文档”，而我喂的是干净 markdown，这个强项落在我身上等于零，我却要为它的重型底座付出机器扛不住的内存。
那为什么我最后没有一刀切
按上面这张表，最省的选法是 Dify。
但选型从来不只是一张表。RAGFlow 在我机器上已经部署好、healthy 跑着，我对它的检索质量也更信任一些；DeepDoc 今天用不上，不代表明天不会往里喂复杂文档。真正让 RAGFlow 重新成立的，是那个老办法——把 embedding 和问答都甩给号池的千问，让这套重栈只干检索，算力一两不留在本地。RAGFlow 重在底座，可底座之上最吃资源的两件事，被我搬走了。
于是结论不是”哪个更好”，而是”在我的约束下，怎么让选中的那个不把机器压垮”。这跟我当初做号池是同一个念头：机器小，就别让它扛重活，重活外包，本地只留编排。
所以这件事真正的教训，不在 RAGFlow 和 Dify 谁赢，而在我一开始就问错了题。我问”谁的向量检索强”，可向量检索压根不是战场。把问题问对——“在我这台小机器、这堆干净笔记上，瓶颈到底卡在哪”——答案自己就浮出来了：瓶颈从来不是检索，是解析用不上、内存扛不住、算力得外包。
想清楚这一层，选哪个反而成了小事。
Pinterest Saved Pins 
Pinterest Saved Pins 
Pinterest Saved Pins 
Pinterest Saved Pins 
Pinterest Saved Pins 
Pinterest Saved Pins 
Pinterest Saved Pins 
Pinterest Saved Pins