五大 RAG 开源项目对比 2026：Dify、RAGFlow、FastGPT、AnythingLLM、LightRAG

五大 RAG 开源项目深度对比

所有数据截至 2026-10-30，star 数经 GitHub API / shields.io 复核，issue 编号可点击验证。

起因：我自己的项目 tiered-rag-service（带权限分级的中文 PDF 问答服务）做到一半，想知道自己在生态里的真实位置，于是把这五个标杆逐个扒了一遍。扒完发现网上流传的很多"共识"已经过期——包括我自己笔记里的三条，以及我对自己项目的一句描述。更正全部放在文末附录。

先说我的项目是什么，免得对比没有参照物

一句话：FastAPI + LangChain 的中文 PDF 问答服务，混合检索（BM25/jieba + bge 向量）→ cross-encoder 重排 → 按权限档位编译独立检索引擎。

项	实际值（源码核对）
栈	Python 3.11+ · LangChain 1.4.5 · FastAPI 0.162 · Chroma 1.5.9 · sentence-transformers 6.2 · Redis · Gradio 6.30 · Docker Compose
切块	`RecursiveCharacterTextSplitter`，chunk_size=800 / overlap=20，分隔符 `\n\n / 。/ ！/ ？`
召回	BM25(jieba 分词) top-20 + Chroma 向量 top-20，`EnsembleRetriever` 权重 0.5/0.5
重排	`bge-reranker-v2-m3` 交叉编码器，压到 top-3
生成	qwen-plus（embedding 用 `bge-small-zh-v1.5`）
隔离	档位有序（`TIERED_RAG_LEVELS`，默认 `public,secret`，第 N 档读 0..N），每档一套 BM25 语料 + Chroma `{"level":{"$in":[...]}}` 过滤
质量	45 项单测（0.4 秒跑完，不依赖模型/Redis/密钥）· 10 条 ADR · CI 静态检查

它最有价值的部分不是链路本身，而是我把它测了一遍，结果扫了自己的台（数据在文末第五节和附录里）。这也决定了我看这五个项目时的判断标准：不接受没有证据的复杂度。

一张图定位

这五个项目根本不在同一个赛道上，硬排座次没意义。先把它们摊在两个轴上：抽象层级（底层框架 ↔ 开箱即用的产品）和检索范式（向量匹配 ↔ 结构化理解）。

项目	Star	定位	技术栈	许可	最低配置
Dify	160k	LLM 应用操作系统，工作流 + Agent 编排平台	Python 3.13 / Flask + Next.js	改自 Apache 2.0，附加条款	2C / 4G
RAGFlow	93k	深度文档理解 RAG 引擎（解析能力的天花板）	Go（1.0 已重写）	Apache 2.0	4C / 16G
AnythingLLM	68k	Local-First 私有 ChatGPT，桌面端双击即用	Node/Express + React/Vite	MIT（最宽松）	单机桌面
LightRAG	40k	知识图谱增强 RAG，做多跳关系推理	Python	MIT	看 LLM，不看机器
FastGPT	30k	轻量可视化知识库问答，RAG 链路可调参	Next.js 16 / TS 6 / MongoDB	Apache 2.0 + 附加条款	2C / 4G

两个第一眼就会被纠正的事实：

Dify 不是 ~100k，是 160k。两年翻了快四倍，已经是这个赛道的事实标准。
RAGFlow 的核心早就是 Go 了。v1.0.0-rc1 起整体重写，仓库语言构成 Go 占 71.2%，"Python + React"属于 v0.x 时代。这事很重要，因为它改变了二开方式（下面细说）。

1. Dify：平台化最彻底，但 RAG 只是它的一个子模块

它到底是什么

后端 api/ 是 Flask 3.1.3 + Celery + gunicorn/gevent，跑 Python ~3.13；前端 web/ 是 Next.js/React。真正值得注意的是架构演进：

工作流执行引擎被抽成独立库 langgenius/graphon——专门给 agentic workflow 用的 Python 图执行引擎，1.18.0 已锁定依赖。
插件运行时是独立的 Go sidecar dify-plugin-daemon，插件从 marketplace.dify.ai 安装，类型分 model / tool / agent-strategy / datasource / trigger / bundle。
向量库支持 30 种 VECTOR_STORE 选项（Weaviate 默认，qdrant/milvus/pgvector/opensearch/tidb 都有）。
Monorepo 里现在有 dify-agent、dify-agent-runtime、cli、skills、e2e——它要做的不是 RAG，是"LLM 应用操作系统"。

许可证是 Apache 2.0 修改版 + 两条附加条件：不提供商业授权不得做多租户/多工作区服务，web/ 的 LOGO 和版权信息不得移除。内部私有化没问题，拿去卖 SaaS 要谈。

RAG 链路：这是我要重点纠错的地方

Dify 现在的分块模式就是 General 和 Parent-child 两种，老的"Automatic / Custom"标签在当前文档里已经没了。父子分块从 v0.15.0（2024-12）就有：命中小子块，返回父块。

检索侧：High-Quality / Economical 二选一，向量 / 全文 / 混合三种，混合可给权重滑条也可上 Rerank 模型，TopK 默认 3，分数阈值默认 0.5。2025-09-23 加了 Knowledge Pipeline（可视化 ETL），2026-02 的 v1.12.0 又加了 Summary Index——用 LLM 给每个 chunk 生成摘要、单独向量化，作为额外一路召回，General 和 Parent-child 都能配。

对照我自己的默认值，有意思：我 rerank_top_n=3，Dify TopK 默认也是 3；但 Dify 有个我没做的东西——score threshold 0.5，即低于置信度就不喂。我是无条件把 top-3 全塞进 Prompt。

那个著名的 issue：#31510

我原本的叙事是"父子分块是 Dify 的空白，issue 被 Not planned，而我实现了它"。核实之后，这句话的每一段都需要改写。

#31510 真实存在，标题 "Upgrade RAG Indexing Architecture to address 'Context Fragmentation' (Moving beyond Naive RAG)"，2026-01-26 开，正文就是这个例子——标题"Project Alpha Specifications"和正文"The maximum voltage is 5V"被切开导致检索失效，作者建议用 LangChain 的 ParentDocumentRetriever。2026-03-14 被 dosubot 机器人自动关闭，state_reason: not_planned。

但关键在于：这个 issue 抱怨的是"naive RAG 索引架构"这个整体，而 Dify 早就有 Parent-child 模式。它被判定 not_planned，不是因为官方不承认痛点，而是因为症状已有现成开关，不值得为此重构索引层。

所以正确说法不是"我解决了 Dify 没解决的问题"，而是"Dify 提供父子分块已经两年了，而我自己的正式版没有用它那种结构"。为什么没有，见下面第 6 条。

真实痛点（都是一手 issue）

#16178：超过 10MB 的 Excel 解析要 30 分钟以上，分段是串行加载的。同样标记 NOT_PLANNED。
#27291：1.9.1 → 1.9.2 升级直接打断了已有的 Weaviate 知识库，用户被迫重建索引或降级。
#32297：迁移时 Redis 锁 TTL 只有 60 秒，大库升级中途锁过期。
#33725：v1.13.x 把执行挪到 Celery worker 之后，工作流跑完拿不到输出，临时解法是 CELERY_WORKER_CONCURRENCY=10。
#20768：Parent-child 模式会吃掉子块里的空白字符——父子分块本身也有坑，不是银弹。
#44923：循环/迭代节点单步调试丢 checkpoint，2026-10-28 还开着。

平台复杂度涨得比单机承载能力快。 官方最低要求写 2C/4G，但 1.18.0（2026-10-23）的升级说明里是：Agent Backend 和 runtime 必须同步升级、sandbox 新增必填鉴权 token、PASSWORD_PEPPER 必须保留、KnowledgeFS 镜像只有 amd64。那是"能起来"，不是"能用好"。

演进节奏（感受一下它有多快）

Knowledge Pipeline 2025-09-23 → 1.11.2 2025-12-25 → Summary Index 1.12.0 2026-02 → Human-in-the-loop 1.13.0 → Agent × Skills 1.14.0（"Workflows Become a Team Asset"）→ E2B sandbox 1.17.0 → New Agent 独立应用 2026-08-27 → 1.18.0 2026-10-23（Agent Output Routes、.ifpkg 可移植应用、嵌套工作流 trace 下钻、difyctl CLI）。

1.18.0 还塞了 Agent Knowledge Base (Beta)：独立的 knowledge-fs compose profile 和单独数据库，检索深度分 Fast / Deep / Research 三档。还没上云。

对 tiered-rag-service 的三条具体启发

借鉴 Summary Index。一次批处理生成 chunk 摘要、单独一张表做一路召回。它能治我实测里那类"跨段落综合"问题——docs/evaluation.md 的分层抽样表里，这一类的预期结论就是"两者都不行，暴露 chunk 策略问题"。
加 score threshold。我无条件塞 top-3，Dify 默认 0.5 卡一道。我的库里有"食堂几点开门"这种库外问题测试项，却只靠 Prompt 里的"严禁使用常识"来兜——用检索置信度兜比用 Prompt 兜可靠，这和我的权限设计哲学是同一个道理。
警惕它那个 #20768。父子分块会破坏子块文本完整性。任何"看起来更聪明"的切块策略都有自己的 bug 面，这不是免费的升级。

2. RAGFlow：把"文档解析"做到工业级，代价是整个团队重写了一遍

谁做的，现在什么状态

InfiniFlow 英飞流（上海），2023-08 成立，联合创始人张颖峰。Apache 2.0，纯开源协议，五个里除 AnythingLLM / LightRAG 之外最干净的。

最后一个 Python 版本是 v0.27.2（2026-09-10），v1.0.0-rc3 发布于 2026-10-30——就是今天。rc1 是 Go 整体重写，带一次不可逆的数据库迁移，官方要求的升级路径是一长串：v0.22.1 → v0.25.6 → v0.26.4 → v0.27.2 → v1.0.0-rc1，而且 Tag 类数据集不会自动迁移。

DeepDoc：它真正的护城河

这是 RAGFlow 唯一无可替代的部分。核实到的细节：

DLA（版面分析）+ OCR + TSR（表格结构识别）在 Go 服务里进程内跑 ONNX Runtime，模型在 internal/rag/res/deepdoc。v1.0 明确写着"DeepDoc currently supports CPU environments only"——不需要 GPU，这点比很多人以为的好。
版面分析 10 个类别：Text / Title / Figure(+caption) / Table(+caption) / Header / Footer / Reference / Equation。有 YOLOv10 变体，v0.18.0 起可选 VLM pipeline。
OCR 是自训的 det.onnx + rec.onnx（CTC 解码），权重在 HuggingFace InfiniFlow/deepdoc。是否源自 PaddleOCR 运行时，官方没说，我查不到，存而不论。
TSR 输出 5 个标签：Column / Row / Column header / Projected row header / Spanning cell，带表格自动旋转矫正。网上到处说的"TSRNet"这个名字，在当前仓库里没能核实。
解析器已经不止 DeepDoc：DeepDOC（默认）/ Naive / Docling / OpenDataLoader / TCADP / MonkeyOCRv2 / MinerU / Mistral OCR / PaddleOCR-VL 可选——它自己在吸收开源生态。
12 个内置切分模板：General、Q&A、Manual、Table、Paper、Book、Laws、Presentation、Picture、One、Audio、Email。v0.27 时代还有 resume 和 tag，v1.0 文档里没看到（这条是推断）。
格式：PDF、电子表格、图片、邮件、Markdown、文本和代码、HTML、DOC、DOCX、PPTX、音频。没有视频。

Infinity：为什么自己造数据库，以及为什么还不用它

Infinity 是同一家公司的 AI-native 数据库，支持 dense + sparse + tensor + full-text 四种索引混合，内置 ColBERT 重排，官方数字是向量检索 0.1ms/15K QPS、全文 1ms/12K QPS @33M 文档，单二进制部署。

但这里有个反直觉的事实：Elasticsearch 仍然是默认。docker-compose-base.yml 里写得很清楚 DOC_ENGINE=${DOC_ENGINE:-elasticsearch}，Infinity 只是 profile 里的可选项，锁在 v0.7.4-x64-v3。社区为此颇有微词（#7917）。而且引擎之间不能迁库：#8038 要求 ES → Infinity 迁移无人实现，#8624 报过 Infinity 数据丢失。

架构到底多重

我把 compose 拆开数了一遍。常驻服务：minio（镜像其实是 pgsty/silo）、kvrocks、nats。profile 门控：es01、mysql、clickhouse、infinity、opensearch01/oceanbase/seekdb/serenedb/vastbase、tei-cpu|gpu、kibana、jaeger、sandbox-executor-manager。应用容器 ragflow-cpu 内部塞了 Go API 9380 / Admin 9381 / MCP 9382，外面再套 nginx。

官方硬性要求：4 核 / 16GB / 50GB 磁盘，Docker ≥ 24，Compose ≥ 2.26.1，单容器 MEM_LIMIT 默认约 8GB，用 ES 还要 vm.max_map_count ≥ 262144。GPU 不需要。Go 后端不支持 macOS。

我之前笔记里那句"为了喝杯牛奶养一头奶牛"，看完 compose 之后觉得还是轻描淡写了。做个对比：tiered-rag-service 的 compose 只有 api + redis 两个服务。

2026 年的两个大动作

v0.20.0（2025-08-04）：Agent 和 Workflow 合并成一套，MCP 全面支持。
v0.27.0（2026-08-19）：推出 Knowledge Compilation（Wiki / Graph / Tree / PageIndex / Mindmap / Timeline / Skills 七种预编译产物），Agentic RAG 分 Low / Medium / High / Ultra 四档，同时 GraphRAG 和 RAPTOR 从 UI 移除。这个改动吵翻了天（#16337、#14617、#16874）。连最激进做图谱增强的项目，都把图谱从产品界面撤下了——这个信号值得咀嚼。
其他：v0.21 引入 ingestion pipeline 画布 + TOC 长上下文，v0.23–0.25 做 Memory，v0.26.3 上 SoMark OCR。

真实痛点

解析卡死/慢是最大的一类：#9466（19 条评论，2026-10-26 刚修）、#7165、#7576、#6664。内存：#7995、#21177（goroutine 泄漏，修复见 #19456）。执行器死锁 #11464。切分 bug 一长串：#18552、#20776、#21344。Go 重写后功能还没补齐：#15240、#20453。GPU 静默回落 CPU：#14565。

对 tiered-rag-service 的启发

先纠正我自己：我没有 pdfplumber，也没有正则表格解析。 src/tiered_rag/indexer.py 里只用了 pypdf 的 page.extract_text()，依赖清单里根本没有 pdfplumber。而且我的已知限制第 4 条白纸黑字写着：扫描版 PDF 无输出，提不到文字就返回空。

所以 RAGFlow 教我的不是"我也该上 OCR"，而是分界线设计：我现在在 text_cleaning.py 里用正则硬编码清洗页眉页脚（strip_repeating_layout，配置项 TIERED_RAG_HEADER_PATTERN / FOOTER_PATTERN）。这个思路是对的——它证明"清洗规则必须外置成配置"而不是写死。但我的能力上限也就是"识别重复行"，RAGFlow 用的是训练出来的版面模型。真正的分界线在每页字符数：pypdf 抽出来接近 0，就该明确报错"这是扫描件，本服务不处理"，而不是悄悄返回空文本、让用户以为知识库坏了。我现在返回的是 {"message": "未能提取到文本"}——诚实，但不够，应该升级为可观测的失败分类。

至于要不要为此上常驻 OCR：不要。 我有实测证据反对一切"未验证的复杂度"——重排把检索 P50 从 15ms 放大到 3306ms（约 220 倍），而在我的 3 题评测集上质量差异完全测不出来。RAGFlow 用 16GB 内存换 DeepDoc 是有理由的（它服务的就是扫描件和复杂表格），我没有那个理由，就该等着。

3. FastGPT：轻量可控的 RAG 链路，中文全文检索是它绕不开的短板

基本盘

labring 出品——做 Sealos、Laf、AI Proxy 那批人。最新 release v4.17.2（2026-10-09），main 已在 4.17.3。

栈核实过 pnpm-workspace.yaml 和 package.json：Next.js 16.3.6、React 18、TypeScript ^6.0.3、Chakra UI v2、pnpm + turbo monorepo、Node ^22.23.4、mongoose ^8.22.1、pg ^8.10、@zilliz/milvus2-sdk-node、@node-rs/jieba。

存储分工很直白：MongoDB 存除向量之外的一切，向量放 PostgreSQL/Milvus/OceanBase/SeekDB。compose 服务：fastgpt-app、mongo、向量库、s3、sandbox-proxy，还有 v4.17.0 起强制要求的 AI Proxy。

资源核实到具体档位：PgVector/SeekDB 最低 2C4G、推荐 2C8G；100 万向量要 4C8G（推荐 4C16G）；500 万要 8C32G（推荐 16C64G）；Milvus 最低 2C8G、推荐 4C16G。所以"2核4G"只在玩具规模成立。

许可证：这条最容易踩

协议名就叫 "FastGPT Open Source License"（Apache 2.0 + 附加条款），GitHub 页面直接显示这个名字。官方文档原话：

「FastGPT 允许被用于商业化，例如作为其他应用的"后端即服务"使用……然而，当满足以下条件时，必须联系作者获得商业许可」「多租户 SaaS 服务：除非获得 FastGPT 的明确书面授权，否则不得使用 fastgpt.io 的源码来运营与 fastgpt.io 服务类似的多租户 SaaS 服务」「LOGO 及版权信息：……不得移除或修改 FastGPT 控制台内的 LOGO 或版权信息」

还有一条被很多人忽略：贡献者条款里写着"生产者有权将开源协议调整为更严格或更宽松的形式"。授权方保留收紧的权利——把它当长期商业底座之前要想清楚。

（补一句：Dify 的附加条款和这个几乎一模一样。这个赛道想做 SaaS 的都上了同一道锁。）

RAG 链路：我扒了 v4.17.0 的源码枚举

这块变化很大，网上流传的老教程基本都失效了。当前 packages/global/core/dataset/constants.ts 里的真实枚举：

数据集模式：chunk | qa | imageParse | backup | template
分块设置模式：auto | custom | intelligent（intelligent 是外部"智能分块"服务）
切分模式 DataChunkSplitMode：paragraph | size | char，配 minSize / forceChunk / maxSize 三个触发阈值

注意：老教程里的"按标题切分 / 按特殊符号 / 正则分割"这几个 UI 模式，在 4.17 的枚举里已经找不到了。 谁还在背那套面试答案，答案已经过期。

全文检索：这是 FastGPT 最实在的技术债

实现是 MongoDB $text + jieba 分词。真正的 BM25 只有 Milvus ≥ 2.5.16 才有（v4.16.2 加的）。官方文档原话：「PG/OceanBase/SeekDB/openGauss 全文检索仍走 MongoDB $text」。

也就是说：你用 pgvector（最主流的部署选择），那你的全文检索就依赖 Mongo 文本索引，换库也逃不掉。

由此产生的真实 issue：

#2791（2024-09）：搜"上海交通大学"，命中的是"上海""交通""大学"三个独立词——Mongo $text 没有短语匹配，词法检索的经典失效。
#5182（2025-07）：pg 4000 万向量 + Mongo 1400 万行全文，查询超时。
#6749（2026-04）：mongo 全文查询过大，用户请求一个能关掉分词请求的配置项。
#3695（2025-02）：升级后报 text index required for $text query——索引没建上就查了。
#4301（2025-03）：73 条记录检索卡死，next-server 内存爆满，容器被重启。
#1896：Mongo 空间不回收，白占 7.9GB。
#4197 / #3731：pgvector HNSW 的 ef_search 默认值导致召回丢失。

升级痛：4.0 到 4.17.3 的官方迁移文档约 150 个页面，而且写着"升级到 V4.17.0 之前，先升到 V4.16.x 把所有遗留升级脚本跑完"。

编排能力

文档化 20 个节点：ai_chat、content_extract、coreferenceResolution（指代消解）、custom_feedback、dataset_search、document_parsing、form_input、http、knowledge_base_search_merge、loop、loop_run、parallel_run、question_classify、reply、sandbox-v2、text_editor、tfswitch、tool、user-selection、variable_update。MCP 既做客户端（v4.9.6+）也做服务端发布。OpenAI 兼容 /v1/chat/completions 和 /v1/responses。

近期：v4.17.2 加了知识库数据预存储 + 训练链重构 + 目录限定检索；v4.17.1 加了权限快照、知识库标签、OFD 解析（国产化场景）；v4.17.0 加了 SSO（LDAP/钉钉）、Agent V2 TTS、强制 AI Proxy。v4.13.2（2025-10）已标记"不再维护"。

对 tiered-rag-service 的启发

第一，jieba 这件事我们撞在同一堵墙上，但我撞得更便宜。 我这边是 BM25Retriever.from_documents(docs, preprocess_func=jieba.lcut)——rank-bm25 默认按空格切，对中文等于按整句切，所以分词器必须显式传。FastGPT 也用 jieba（@node-rs/jieba），但它下面接的是 Mongo $text，于是出了 #2791 那种"上海交通大学"被拆成三个独立词的失效。我的 BM25 是真的在做词法打分，不是词袋并集。这条可以好好叙述，但措辞要克制：不是我比 FastGPT 聪明，是同一堵墙，我们的落地方式不同，而且我还没有用 recall@k 证明我更好——评测集那 3 道题根本没有区分度。

第二，它教会我"默认关闭"是一种勇气。 FastGPT 的 datasetSearchUsingReRank 默认 false。我当时觉得这像是没优化好；现在我的看法变了：我自己的实测里，重排把检索 P50 放大 220 倍，而质量差异测不出来。 那么"默认关"就是诚实的默认值。我现在把 rerank_top_n=3 写死在默认配置里，这一条我该重新审视。

第三，rrf 作为独立打分选项值得抄。 我现在只用 EnsembleRetriever 的加权融合，README 里我自己也提醒了"融合的是两路候选排名，不能把 BM25 原始分数与向量相似度直接当成同一量纲相加"。既然本质是在融排名，那不如把 RRF 显式做成一种可选策略——它没有权重这个需要手调的超参，正好适合我那"权重 0.5/0.5 仍是经验值"的尴尬现状（docs/evaluation.md 的消融矩阵 C/D 两行就是在回答这个）。

第四，指代消解不该只用一张代词表。 FastGPT 把它做成了独立工作流节点。我的 D-003 是 if not history or not any(p in question for p in _PRONOUNS)——我自己在文档里就写了它的问题：不含指代词的省略问句可能仍依赖历史，含"这""那"的问题也未必需要重写。评测计划里那条"构造 30 条需要重写但不含表内代词的追问，量漏重写率"，就是冲这个来的。

4. AnythingLLM：产品化交付最成功，但 RAG 内核刻意做得很薄

基本盘

67,747★ / 7,623 forks，MIT——五个里对二开最友好的协议（和 LightRAG 并列）。pushed_at 就是今天。v1.19.0 发布于 2026-10-26，约一月一版。

yarn monorepo，三个包：

server/（anything-llm-server v1.19.0）：Express 4.21 + Prisma 5.3.1/SQLite，langchain 锁死在 0.1.36，@lancedb/lancedb 0.15.0，@modelcontextprotocol/sdk ^1.24.3，带 swagger。
frontend/：React 18.2 + Vite 4.3 + Tailwind 3.3 + i18next（约 30 种语言）。
collector/：独立的 Express 采集服务（8888 端口），parser 覆盖 docx/mbox/pdf/audio/wav，扩展加载器包括 RepoLoader（GitHub/GitLab）、Confluence、DrupalWiki、ObsidianVault、PaperlessNgx、WebsiteDepth、YouTube 字幕。

embed 和 browser-extension 是 git submodule。

桌面版：Local-First 的真正落地形态

Electron 打包，macOS Intel + Apple Silicon、Windows x64 + ARM64、Linux x64/ARM64（AppImage，官方标注"limited"）。

官方文档把桌面版叫 "single-player"，功能表里多用户、用户管理、工作区权限、密码保护、嵌入组件、白标、浏览器访问——桌面版全 ❌，Docker 版全 ✅。桌面版 "Network discovery" 只把 API 暴露到 0.0.0.0，浏览器访问直接 404。

这里有个要提醒的事：Mintplex-Labs/anythingllm-desktop 这个仓库现在返回 404，org 下也搜不到桌面仓库；安装包走 cdn.anythingllm.com 分发，主仓库里只有一个陈旧的 desktop 分支（package.json 停在 v0.2.0）。想读桌面端源码学打包方案的，路径和以前不一样了——这条我没能完全核实清楚。

本地模型：Lemonade 是 2026 年最重要的变化

Lemonade 是 AMD 出品的开源 llama.cpp 服务器（lemonade-sdk/lemonade）。时间线：v1.11.1 作为 provider 接入 → v1.18.0（2026-10-13）成为桌面版默认引擎，取代了原来捆绑的 Ollama → v1.19.0 又带进 Docker（-e ENABLE_BUILT_IN_LLM=true）。

从"依赖用户自己装 Ollama"变成"自带引擎"，这才是双击即用的完整闭环。向量库：LanceDB（默认）、PGVector、Chroma/ChromaCloud、Milvus、Zilliz、Pinecone、Qdrant、Weaviate、Astra。（网上教程里的 SingleStore 在代码、README、文档里都已不存在。）

RAG 内核：薄到出乎意料

分词器只有 LangChain 的 RecursiveCharacterTextSplitter，文档原话是"currently the only splitting strategy"。默认 chunk = 1000 个字符（注意是字符不是 token），overlap = 20。可调，但只对重新 embed 的文档生效，且受 embedding 模型上限约束。

检索旋钮只有：Max Context Snippets（文档建议 4–6）、相似度阈值（默认 20%，Low .25 / Med .50 / High .75）、文档 pinning（把某篇全文注入 prompt，绕开 RAG）、v1.8.5 起的会话级附件全文。重排（"Accuracy Optimized"）只有 LanceDB 支持，而且是固定的 Xenova/ms-marco-MiniLM-L-6-v2，+100–500ms。

三种对话模式：Agent（v1.11.1 后新工作区默认，v1.13.0 从 "Auto" 改名）、Chat、Query。

"深度定制受限"这个说法成立，有 issue 背书：#3941（要求 LanceDB 之外的重排支持）、#2146（要求语义分块，9 个赞，未实现）、#3198、#5413。向量库还是系统级配置，不能按工作区选。

其他痛点：#3700 多用户内存增长、#3515 桌面端空闲占 40% CPU、#3367 2 万个文件时文档页很慢、#5712「embedding brutally slow」、#6199 静默数据丢失 / 孤儿向量、#4443 硬编码 5 分钟 Ollama 超时、#5025（11 个赞）要求桌面端做 server 瘦客户端。桌面升级方式是覆盖安装（数据保留），但 v1.18 换引擎时会删掉旧的 Ollama 模型。

2025–2026 在忙什么

MCP（只有 client 的 Tools 能力，不支持 Resources/Prompts/Sampling）、Agent Skills + Community Hub + Intelligent Tool Selection（v1.12.0，宣称省最多 80% token）、文件系统与文档生成 agent、Telegram bot、Model Router、定时任务、Automatic Memories、Agent Surveys（均 v1.13.0）、图片生成（v1.16.0）、Meeting Assistant（v1.19.0，有 /v1/meeting-assistant/start|stop|search API）、AnythingLLM Mobile（Android，端侧推理，开源）、live document sync（beta）。

对 tiered-rag-service 的启发

AnythingLLM 是这五个里唯一把"交付"当核心问题的。它的 RAG 内核比我的还薄——只有一种切分器、1000 字符一刀切、重排只有 LanceDB 能用——但它 68k star。这本身就说明问题：在开源产品的传播里，"能跑起来、不配置、隐私好"的价值远大于"召回率高 5 个点"。

这里我要对自己诚实：tiered-rag-service 的检索策略确实比它多两层（BM25 融合 + cross-encoder 重排），但我的 README 里写的已知限制第 2 条是"评测只有小样本流程验证，尚无生产级指标"。我没有资格说我的链路更好，因为那 3 道题上纯向量和混合+重排的上下文精确率/召回率都是 1.0。

要借鉴的两件具体事：

文档 pinning。它承认了一个朴素事实：检索有失败率，低于阈值就别装了，直接把用户指定的全文塞进 prompt。我的阈值卡掉的长文档，用户其实知道自己在问哪篇。这也是我那个"库外问题应拒答"测试项的另一半答案——拒答之外，还应该给用户一个"我知道在哪，别检索了"的逃生门。
/healthz 已经有了，但要学它把交付体验做完。我已经有 Dockerfile + docker-compose + CI（这点比素材里的我以为的要好），真正卡住别人复现的是 README 里那句"首次启动会下载 bge-small-zh-v1.5 和 bge-reranker-v2-m3（约 1.2GB）"。任何要在别人机器上跑的东西，1.2GB 的首次下载都是一道真实的墙，得给出预打包或可选降级的方案。

不借鉴的：Electron。#3515 那种空闲 40% CPU 是它的用户在对 issue 里抱怨出来的，我不想背。

5. LightRAG：图谱增化的性价比之王，但那个"10 倍"是假的

基本盘

港大 HKUDS，40,438★ / 5,844 forks，MIT，Python，[EMNLP 2025] 论文，创建 2024-10-02，pushed 昨天。对照组 microsoft/graphrag：36,496★，MIT，当前 pyproject.toml 版本 3.3.0。

LightRAG 已经追上并反超了微软的 GraphRAG——两年时间，这本身就是它路线被验证的证据。

双层检索：核实之后发现有五种模式

低层（low-level）负责具体实体和它们的关系，高层（high-level）负责宏观主题和跨文档关联。README 现在列的是五种：local / global / hybrid / naive / mix，默认是 mix（把 local + global + naive 融合）。WebUI 类型定义里还有第六个 bypass。另外从 2025-08 起，混合查询默认开启 reranker。

（我笔记里写的"四种模式"是 2024 年的老信息。）

增量更新是它最漂亮的设计：索引成本只有 total_tokens / chunk_size 次 LLM 调用，新文档只抽取自己那批 chunk，不重建全库。删除文档时，受影响的实体关系从 LLM 响应缓存里重建（2025-08 加的）——省掉重新抽取。

存储侧的诚实说明我很喜欢：默认后端 JsonKVStorage / NanoVectorDBStorage / NetworkXStorage / JsonDocStatusStorage，README 明说这些"not suitable for production"，因为吃内存。生产可选：PostgreSQL（官方推荐，一个库能承担全部四种存储）、MongoDB、OpenSearch（2026-03）、Neo4j、Memgraph、Milvus、Qdrant、Faiss、Chroma、Redis、Apache AGE、Gremlin、TiDB。

"索引速度提升约 10 倍" —— 这条我查了，是讹传

必须点名纠正，因为我自己笔记里也写了。

我把 arXiv 2410.05779v3 正文全文搜了一遍：10x、ten times、order of magnitude、times faster 零命中。论文 §4.5（Legal 数据集）给的是公式，不是倍数：检索 token 610 × 1,000 vs <100；检索 API 调用 610,000 / C_max vs 1；增量更新 1,399 × 2 × 5,000 token vs T_extract。

那个"10x"来自第三方营销博客（比如 ragdollai.io 写的"10x faster queries at 90% lower cost"）。而"10x faster indexing"这个数字实际属于另一个项目 E²GraphRAG，被张冠李戴到了 LightRAG 头上。

更该说的是：LightRAG 论文自己的表格里，在 Mix 数据集上它输给了 GraphRAG（Overall 49.6% vs 50.4%）。它在 Agriculture / CS / Legal 上赢（54.8 / 52.0 / 52.8）。这不是"全面碾压"，是"多数场景更划算"。

真实痛点

实体去重只按名字精确匹配 → 大量重复节点和断裂子图。论文里 entity resolution、duplicate 各出现 0 次。学术界已有外部补丁（DEG-RAG, arXiv 2510.14271）。
幻觉出通用实体（"相关人物""某部门"这种垃圾节点）从 #191（2024-11-01）开到现在没关。
人工清理：POST /graph/entities/merge 接口确实存在（合并重复/拼错的实体），但自带的 WebUI 客户端只调 /graph/entity/edit（带 allowMerge）和 /graph/label/list（返回 merge_candidates），没有调用那个 merge 端点。我笔记里"WebUI 有 merge 按钮"的记忆，方向对、细节错。
LLM 调用量：抽取阶段之后还有实体合并和关系合并两个阶段。README 强制要求抽取模型是 non-thinking 类型，并警告吞吐低于约 50 tok/s 的模型会超时（实际超时 = 配置值 × 2）。
对模型能力要求高：README 原话承认"higher capability requirements for LLMs than traditional RAG"，并把 Qwen3-30B-A3B-Instruct 称为"一个合理的下限"。想用 7B 模型跑图谱增强，基本别指望质量。
中文：SUMMARY_LANGUAGE 支持设中文（默认英文），递归切分里有 CJK 标点处理，WebUI 有 zh/zh_TW 界面和 README-zh。但论文所有 benchmark 都是英文 UltraDomain 数据集，中文质量没有任何公开量化数据。这是"支持"，不是"验证过"。

2026 的关键动向

RAG-Anything（24,310★，2025-06 发布）已于 2026-05 合并进 LightRAG，多模态解析（走 MinerU / Docling）现在是它的一个特性，不再是独立选型。同门还有：MiniRAG（2,026★，ACL 2026，专攻小模型场景）、VideoRAG（3,496★，KDD'2026，视频）。AnyGraph 跟这条线无关（那是个 231★、2024-09 起停更的图基础模型项目，别混）。

GraphRAG 独有的能力是 Leiden 社区发现 + 自底向上的层级化社区报告，这是 global search 的地基。LightRAG 是故意砍掉社区报告来换成本和速度的——这是两者真正的分野，不是速度。

对 tiered-rag-service 的启发

第一，"增量成本"是图谱方案能不能落地的唯一硬指标。 LightRAG 把成本压到 chunk 数 × 1 次调用，用缓存做删除回滚，这才让图谱在我的量级上变得可讨论。顺便解掉了我一个真实的技术债：我的已知限制第 3 条写着"每次上传全量重建 BM25，O(N) 且随库增长变慢"。LightRAG 的增量思路给了我参照——Roadmap 里那条"BM25 索引持久化，避免全量重建"，优先级该提到引用溯源之前。

第二，也是最重要的：三条证据指向同一件事——图谱在这个场景投产比仍然打不过调好的混合检索。 RAGFlow 把 GraphRAG 从 UI 撤了；LightRAG 需要 30B 级模型才有质量保证；实体去重只按字符串精确匹配。我不上图谱。

第三，这个项目教会我的其实是"怎么评价自己没做的东西"。 我原本准备的叙事是"我用父子切片解决了 Dify Not planned 的痛点"。实际情况是：

父子切片我只在学习原型里做过（D:\python_project\Langchainn\RAG进阶\6+父子文档切块.py，子块 200 / 父块 1000，metadata 存 parent_text），正式版的 indexer.py 是单层切块 800/20，没有父块字段；
而 Dify 提供 Parent-child 已经两年，这个功能本身不稀缺。

所以我现在能站得住的说法不是"我做了别人没做的切块"，而是："别人都在宣称自己的检索链路更好，而我把重排的 220 倍延迟成本和'3 道题测不出差异'这件事测了出来，并且据此重新质疑了自己的默认参数。" 这比父子切片值钱得多，而且它是我真的做过、真的有数据的部分。

6. 横向对比：真正该比的六个维度

文档解析

	解析能力	中文适配	可插拔
Dify	弱（Excel 10MB+ 要 30 分钟，#16178）	一般	有 Knowledge Pipeline
RAGFlow	天花板（DLA+OCR+TSR，进程内 ONNX，CPU 可跑）	好	9 种解析器可换
FastGPT	中规中矩（v4.17.1 加了 OFD）	好	有限
AnythingLLM	采集器齐全但以纯文本为主	一般	collector 独立进程
LightRAG	2026-05 起并入 MinerU/Docling 多模态	无 benchmark	—
tiered-rag-service	pypdf 单层文本抽取，扫描件返回空	正则清洗页眉页脚 + CJK 软换行拼接	规则外置为 env，解析器不可换

分块策略

Dify：General + Parent-child（2024-12 就有），外加 Summary Index 一路召回。
RAGFlow：12 个模板按文档类型走不同切法，这是"分块"最工程化的做法。
FastGPT：paragraph / size / char + 外部 intelligent 服务；老教程的"按标题/正则"已不在枚举里。
AnythingLLM：只有递归字符切分，1000 字符 / overlap 20。
LightRAG：chunk 只是抽取实体前的载体，切法不重要，图才重要。
我：单层 800 / overlap 20，分隔符按中文标点定制。和 AnythingLLM 同构，只是参数不同。

检索链路

	全文检索实现	混合检索	Rerank	置信度阈值
Dify	依赖所选向量库（30 种，Weaviate 默认）	权重滑条 / rerank 模型二选一	默认关，TopK=3	0.5（有）
RAGFlow	ES（默认）或 Infinity（自带 ColBERT）	强，多路融合	Infinity 内置	有
FastGPT	Mongo `$text` + jieba；真 BM25 只有 Milvus	加权 / rerank / RRF	默认关闭	0.4（有）
AnythingLLM	阈值 + pinning	无权重可调	仅 LanceDB，模型固定	默认 20%（有）
LightRAG	图遍历 + 向量	local/global/hybrid/mix(默认)	2025-08 起混合默认开	—
我	真 BM25（rank-bm25 + jieba），非 `$text`	EnsembleRetriever 0.5/0.5，两路各 top-20	bge-reranker-v2-m3，top-3	无（要补）

四个平台都有置信度阈值，只有我没有。这是这轮调研里最便宜、最该马上修的一条。

权限模型（这条我只写核实到的，不做"只有我做到"的断言）

我核实到的是：Dify 有 metadata 过滤和外部知识库 API；FastGPT 有知识库标签过滤但 isPro: true（付费功能）；AnythingLLM 的多用户/工作区访问管理只在 Docker 版存在；RAGFlow 和 LightRAG 的权限粒度我没有逐一核实。

所以我只能说：这五个项目里，我能确认的访问控制都是"用户能否打开哪个知识库/工作区"这一层，且过滤能力往往绑在商业版上；而 tiered-rag-service 走的是另一条路——密级作为 chunk 的 metadata，启动和每次入库时按档位编译一套检索引擎（该档专属 BM25 语料 + Chroma {"level":{"$in":[...]}}），低档候选集里物理上不存在高档 chunk。同时我也必须说清它的另一半：档位由请求体声明，没有真实鉴权（ADR D-010），所以它证明的是"检索层能做数据隔离"，没证明"系统能抵抗越权"。

我不写"独此一家"，因为我没验证过另外四家的完整能力矩阵。

编排与 Agent

Dify ≫ FastGPT > RAGFlow > AnythingLLM ≫ LightRAG（后者不在这个赛道）。我的项目刻意不是 Agent——Roadmap 最后一条才写"把检索器包成 tool，交给 agent 决定何时检索"。

部署重量（差距最夸张的一条）

AnythingLLM 桌面版   →  双击，0 配置
tiered-rag-service   →  pip install -r requirements.txt + docker compose up -d redis（首次下载模型约 1.2GB）
LightRAG 默认        →  pip install + 一个 API key（但生产要 Postgres/Neo4j）
FastGPT              →  2C4G 起步，Milvus 要 2C8G，向量上量后 4C8G ~ 16C64G
Dify                 →  名义 2C4G，实际 7 个服务 + Go sidecar，1.18 起还要 Agent runtime
RAGFlow              →  4C / 16G / 50G 硬性要求，常驻 3 个中间件，macOS 不支持

许可证（做产品的第一条红线）

	协议	能不能拿去做 SaaS
AnythingLLM, LightRAG, 我	MIT	能，无附加条件
RAGFlow	Apache 2.0	能，纯开源
Dify	Apache 2.0 + 附加	多租户需商业授权，LOGO 不得移除
FastGPT	Apache 2.0 + 附加	多租户需书面授权，LOGO 不得移除，且协议保留收紧权利
GraphRAG	MIT	能

我的项目是 MIT，这条在选型上算一个真实优势：别人因为许可证不得不考虑的事，我不用。

7. 选型决策

要一个"什么都能干"的应用平台，团队有运维，不介意附加条款 → Dify。160k star 的生态红利是真的，升级把知识库搞坏的风险也是真的。
文档质量差、扫描件多、表格复杂，且拿得出 16G 内存 → RAGFlow，解析层面没有对手。但 v1.0 的 Go 重写迁移不可逆，现在上车要么留 v0.27.2，要么承担 rc 的风险。
个人项目 / 小团队 / 快速 demo → FastGPT（中文场景 + 可调 RAG 链路，但 pgvector 用户要接受 Mongo 全文检索的精度）或 AnythingLLM（MIT、部署最轻，但 RAG 内核薄到需要你自己改）。
问题本质是"A 和 B 有什么关系""跨文档综述" → LightRAG。前提：抽得起 30B 级别的模型，且接受实体去重要自己补。
只是问答，不做分析 → 老老实实向量 + BM25 + rerank。上图谱是过度设计，RAGFlow 自己都把 GraphRAG 从 UI 撤了。

8. 五个项目教会我的三件事

一、瓶颈在检索前面，也在检索里面。 RAGFlow 用 93k star 证明：对真实企业文档，解析质量带来的召回提升，比调检索参数大一个数量级——垃圾进垃圾出，向量再准也救不回被漏掉的表格。而我自己的实测证明另一头：当我把瓶颈量化出来时，它不在模型调用，而在检索和重排（缓存命中后剩余 3369ms 里有 3361ms 是检索+重排，占 99.8%）。两个方向合起来是同一句话：优化预算该花在数据管道上，不是花在生成端。

二、"平台化"是有利息的负债。 Dify 每加一个能力就多一个 sidecar；RAGFlow 因为状态太重不得不整体换语言，并留下一条 5 跳迁移路径；FastGPT 有 150 页迁移文档。这三家在用同一个方式告诉我同一件事。 我的项目现在最值钱的地方是"只有 api + redis"，这个优势有保质期。所以我要守住的不是"永远不加依赖"，而是任何新状态都必须能删了重建、且重建时间可接受——这条约束直接解释了为什么 BM25 全量重建（限制 3）现在还能忍、千级 chunk 就不能忍。

三、开源项目的 star 数衡量的是交付摩擦，不是算法先进性。 AnythingLLM 只有一种切分器、1000 字符一刀切、rerank 只有 LanceDB 能用，"要求语义分块"的 issue 躺了三年没实现——它 68k star，比检索链路做得比它深的项目都高。用户要的是"不配服务器、数据不出本机、双击能用"。

这条结论我一开始不接受，因为它和我的自我叙事完全相反。但我自己的数据支持它：我在 3 道题上测不出混合+重排相对纯向量有任何质量优势，却要付 220 倍的检索延迟。"更聪明"如果不被测量支撑，它就只是更贵。 这大概是我这轮调研里最不舒服、也最有用的一条。

9. tiered-rag-service 的下一步

按"证据强度 ÷ 实现成本"重排，前四项是这次调研直接补上的：

加 score threshold（来自 Dify 默认 0.5 / FastGPT 0.4 / AnythingLLM 20%）——四个平台都有，只有我没有。这是本轮最便宜的修复，且直接改善"库外问题应拒答"那条测试项。
重新审视 rerank_top_n 默认值（来自 FastGPT datasetSearchUsingReRank=false）——我有 220 倍延迟的实测数据，默认开启却拿不出质量收益，这个默认值是错的。要么改默认，要么把评测集扩到能证明它。
BM25 索引持久化（增量思路来自 LightRAG 的 total_tokens/chunk_size 成本模型）——解掉已知限制 3，顺带让"删了重建"这条约束继续成立。
文档 pinning（来自 AnythingLLM）——承认检索有失败率，给用户一个绕过检索的逃生门。
RRF 作为可选融合策略（来自 FastGPT 的打分枚举）——去掉"0.5/0.5 是经验值"这个尴尬，消融矩阵 D 行也顺手能跑。
Summary Index 一路召回（来自 Dify v1.12.0）——针对评测集里"跨段落综合"那一类，这是唯一有预期收益的 chunk 侧改动。
评测集扩到 30+ 题、加干扰文档、换评委模型（这条排最后，但它是前 6 条的前提）——我自己写的通过标准是"混合检索 recall@3 ≥ 纯向量 +10 个百分点，否则承认参数没调对或语料不合适"。先有测量，再谈优化顺序。

明确不做：知识图谱、微服务、消息队列、独立对象存储、Electron 客户端、常驻 OCR。

附录 A：本次调研推翻的六个流行说法

流传说法	核实结果
"Dify 没有父子分块，issue 被 Not planned"	分两层。#31510 确实在 2026-03-14 被 dosubot 以 `not_planned` 关闭；但 Dify 从 v0.15.0（2024-12）就提供 Parent-child，被拒的是"重构索引架构"而非"做父子分块"。
"LightRAG 索引比 GraphRAG 快 10 倍"	讹传。论文正文无此倍数，"10x" 出自第三方博客；"10x faster indexing" 本是另一项目 E²GraphRAG 的宣传语。且论文表格中 LightRAG 在 Mix 数据集输给 GraphRAG（49.6% vs 50.4%）。
"RAGFlow 是 Python + React"	v1.0 已用 Go 重写，仓库语言 Go 占 71.2%。最后 Python 版本 v0.27.2（2026-09-10）。
"FastGPT 支持按标题/正则切分"	v4.17 枚举里已不存在，现在是 `paragraph / size / char`。
"AnythingLLM 支持 SingleStore"	代码、README、文档均已无此项。
"LightRAG 有四种查询模式"	五种，且默认值是新增的 `mix`。

附录 B：没能核实、存疑的项

RAGFlow 的 OCR 是否源自 PaddleOCR 运行时；TSR 模型是否叫 TSRNet；v1.0 是否真的移除了 resume/tag 模板；AnythingLLM 桌面端源码仓库为何 404 及其确切打包方式；"2026-02 FastGPT 发布 Memory API"仅见于搜索摘要；LightRAG 官方任何第一方索引速度倍数；GraphRAG "每 chunk 4–6 次 LLM 调用"；FastGPT 开发主体的确切公司注册名（二手来源不一致）；Dify 插件市场总量；以及另外四个项目的完整权限能力矩阵（故第 6 节权限那条只写核实到的部分）。GitHub API 本次触发限流，部分 star 数取自 shields.io 实时 badge（精度到千位）。

数据时间戳：2026-10-30。 这个赛道三个月一变，引用前先复核 release notes