先说一个我观察很久的现象这两年企业内部聊RAG几乎绕不开“选型”两个字。我见过不少团队的开场方式完全一致——先去GitHub按star排序挑个最亮眼的项目docker compose up拉起来跑通一个demo就宣布进入落地阶段。结果呢卡在文档解析不准、召回结果稀碎、权限没法按部门隔离这些坎上回头才发现问题根本不在模型而在选型阶段就选错了对象拿框架当平台用或者拿平台当框架改两边都别扭。这篇文章想解决的就是这个问题。我会拆六款目前出镜率最高的开源RAG相关项目先横向对齐它们的定位差异不让你再凭star数做判断然后给一棵可以直接照着走的选型决策树按团队形态和业务场景分流最后聊聊真正影响落地的几个工程细节这部分才是demo跑通之后最容易翻车的地方。文章适合正在做技术选型的技术Leader、架构师也适合准备把RAG从实验项目推向生产环境的一线工程师。六款产品分别是LangChain、LlamaIndex、Dify、FastGPT、RAGFlow、QAnything。有人会问为什么没有MaxKB、没有Haystack、没有txtai——我的筛选标准是三条社区活跃度够、企业场景出镜率高、定位差异度足够大。这六个刚好覆盖“研发框架-应用平台”“通用编排-知识库垂直”“高控制力-开箱即用”几个光谱后面展开讲。1. 为什么凭GitHub Star选RAG容易翻车先聊一个反直觉的结论GitHub上star最多的RAG项目往往不是最适合企业内部落地的那个。原因不复杂——RAG不是单一组件而是一条完整的数据流水线。一条标准的RAG流水线包含文档加载、内容解析、切分、向量化、索引存储、召回、融合、重排、生成、引用溯源这些环节。不同开源项目对这条流水线的“切割点”完全不一样LangChain把切分策略、索引结构、召回逻辑全留给你自己写Dify把切分做成界面里的一个开关选了就生效RAGFlow连扫描件的版面结构、表格行列都会在解析阶段帮你还原。选型本质上是选“你愿意接管这条流水线的哪一段”star数完全回答不了这个问题。另一个容易踩的坑是“框架思维”和“平台思维”的混淆。我遇到过不止一个团队看中某个框架的灵活性和抽象能力选型时觉得“什么都能做”结果落地时发现知识库管理界面、文档解析服务、用户权限、日志链路全都要自己搭反过来也有人拿了平台型产品想通过改代码实现深度定制最后被平台自身的设计假设绑住升级一次痛一次。还有一个隐蔽陷阱只比功能清单不比各个产品在相同场景下的默认行为。同样是切分一份带多级标题的Word文档有的项目按固定token切标题层级直接断掉有的项目会识别标题结构把子章节切进同一个片段有的项目甚至会把表格单独提取出来做结构化存储。默认行为决定了你demo阶段的初始效果而这个效果往往会被误判成“模型能力的问题”实际上只是选型时选错了处理范式。所以我的建议是选型之前先回答三个问题——你的团队有多少工程资源可以投入你的文档源有多“脏”你需要的是一套可以直接交付的系统还是一个能被业务代码深度嵌入的引擎这三个问题的答案直接决定了你应该走向棵决策树的哪个分支。2. 六款开源RAG产品定位矩阵拆解先给一个坐标系横轴是从“研发基座”到“应用平台”纵轴是从“通用编排”到“知识库垂直”。六个产品落位之后看彼此的距离会非常有意思。项目一句话定位核心交付形态最擅长的事最容易在落地时暴露的短板LangChain应用编排框架Python/JS库要求代码集成多模型接入、Agent流程、复杂业务逻辑编排知识库相关能力需要大量自建升级破坏性改动频繁LlamaIndex数据与检索框架Python库要求代码集成文档切分、索引结构、检索管线深度定制学习曲线陡重索引而轻应用交付Dify大模型应用开发平台可独立部署的全栈应用提供API工作流编排、Agent、模型统一管理、日志标注RAG深度解析能力偏通用复杂版面文档需要外挂解析FastGPT知识库问答与工作流平台可独立部署的全栈应用提供API知识库权限、可视化工作流、B端多租户交付文档解析能力中规中矩深度定制受限RAGFlow深度文档理解驱动的RAG引擎独立部署服务自带前端与APIPDF版面分析、OCR、表格还原、模板切分、GraphRAG部署资源要求较高二次开发需要理解其解析服务架构QAnything开箱即用的本地知识库问答独立部署服务自带前端快速私有化部署、离线可用、文档格式覆盖广大规模知识库和深度定制场景下边界明显下面逐个展开。2.1 LangChain把“组装权”完整交给你LangChain不是为一个RAG场景设计的它是个通用编排框架。它的强项在于集成生态几百种模型、向量库、工具链都能接进来你可以用LCEL把检索、重排、提示词、模型调用、输出解析串成一条自定义流水线。对于研发能力强、业务逻辑复杂、需要把RAG嵌进现有代码库的团队它确实是自由度最高的选择。但它的自由是有代价的。抽象层多出了问题排查链路长版本演进激进几个月不升级再看文档接口可能已经变了两轮。如果你只有一两周时间交付一个知识库系统LangChain绝对不是最快的路径——它更像积木箱什么都有但需要你自己搭。2.2 LlamaIndex把“数据加工”做到极致LlamaIndex和LangChain经常被放在一起比较但两者的重心完全不同。LlamaIndex更聚焦数据侧它能精细控制文档怎么加载、怎么切分、用哪种索引结构、召回时怎么组合检索结果。它的NodeParser体系是我用过最灵活的文本拆解工具集之一尤其是处理带结构的长文档时能比固定token切分保留更多语义完整性。选LlamaIndex的团队通常是想把检索质量打磨成自己的技术壁垒。代价是它要求团队对RAG的底层机制有比较深的理解而且LlamaParse这类最强解析能力可能依赖配套服务。如果团队里没有一两个能读懂检索链路源码的人LlamaIndex的深度反而不容易兑现。2.3 Dify做应用交付而不是做检索引擎Dify给我的感觉是一个典型的“大模型应用开发平台”知识库只是它能力拼图里的一块旁边还站着工作流、Agent、模型管理、日志标注、插件市场这些模块。如果你的目标不只是做一个知识库问答而是想在企业里搭一个能承载多种AI应用的基础平台Dify非常合适——它把“应用怎么拼”这件事做得很顺手前端、API、管理后台都齐了。但用到RAG深度场景时会发现它的解析器偏通用。带复杂版面的PDF、扫描件、多栏排版Dify内置处理能力不够通常要前置接一个专门的文档解析服务再把结果导进知识库。它擅长的是把已有内容组织好而不是把杂乱内容吃干净。2.4 FastGPT知识库问答起家交付边界清楚FastGPT是六款里最像“B端交付产品”的一个。它的起点就是客服问答场景知识库权限、多用户隔离、可视化工作流、计费体系都做得比较早部署也轻量。如果你要给企业客户快速交付一套能管权限、能看统计、能改流程的知识库问答系统FastGPT的上手速度明显快于大多数框架型方案。它的短板同样明显文档解析能力不算突出遇到复杂PDF效果依赖前置处理深度定制时要理解它的工作流引擎改起来不如纯代码灵活。另外它的定位和业务耦合比较深适合按“产品”用不适合按“引擎”改。2.5 RAGFlow先解决“吃进文档”这一步RAGFlow是六个里面把“文档理解”这个前置环节做得最重的一个。它内置OCR、版面分析、表格还原、基于模板的切分策略甚至把GraphRAG也整合进来。对扫描件、表格、多栏排版、中英文混排这些真实企业文档里的老大难它比其他几款更能做到“结构化入库”。我实际用下来的感受是RAGFlow把RAG流水线的重心往前移了文档能被拆得多干净决定了下游召回能好到什么程度。代价是它需要比较完整的服务部署环境解析服务本身有资源占用想改切分模板和索引逻辑的学习成本也不低。适合文档源混乱、数据质量差是主要矛盾的企业场景。2.6 QAnything把“本地快速上线”做成了默认选项QAnything来自网易有道主打“任何格式、离线可用”。这六个字很实在它对PDF、Word、图片、扫描件的覆盖比较广自带OCR和向量模型部署轻量教程友好尤其适合对数据出境敏感、要求纯内网私有化的团队。我见过不少单位用它在几天内搭出第一版知识库反响普遍是“能出活”。但它的边界也很清晰大规模知识库场景、复杂权限体系、深度检索策略定制这些需求会很快触到它的能力上限。它是“一辆好开的车”但如果你要的是“能改装的重型卡车”得换个选择。3. 选型决策树的三个关键分叉选型决策树的核心思路和机器学习里的决策树分类器是一样的每次只回答一个判断题别想着一次性算完几十个维度的权重。真实场景里能卡死后续方向的判断就那么几个按优先级排下来就是一棵树。3.1 第一个分叉你要研发基座还是应用平台这是最根本的分叉。判断标准很简单你的团队是愿意花人月去维护代码、自定义流水线的工程型团队还是希望系统开箱即用、把精力放在内容和运营上的业务型团队走研发基座分支进入LangChain或LlamaIndex的选择。走应用平台分支进入Dify、FastGPT、RAGFlow、QAnything的选择。这里没有好坏只有代价。选研发基座意味着后续所有知识库通用功能你都得自己补齐选应用平台意味着深度定制时你会在别人的框架里找缝隙。3.2 第二个分叉选LangChain还是LlamaIndex如果已经决定走研发基座再往下分看你的重心在流程编排还是在数据加工。业务需要对接多个模型、多套Agent流程、复杂业务逻辑的LangChain更合适核心壁垒在文档切分、索引策略、检索质量想让RAG的“R”部分真正做到精细化LlamaIndex更值得押注。也可以组合用但我不建议一开始就这么做——两条框架会拖出两套学习成本和升级负担。3.3 第二个分叉四个平台产品按文档复杂度筛平台分支的内部差异集中在文档源状态和交付场景上文档源复杂扫描件、表格、多栏排版占比高——RAGFlow优先它赢在入库质量。文档源相对规范首要诉求是私有化快速上线——QAnything优先它赢在轻和快。不止做知识库还要承载Agent、工作流、多应用统一管理——Dify优先它赢在平台宽度。面向客户交付需要权限隔离、数据统计、甚至计费——FastGPT优先它赢在B端功能完整。3.4 决策路径速查表团队情况优先考虑次选/备选工程团队要深度定制RAG流水线LangChain 或 LlamaIndex按编排/索引分流平台型产品做基座再二次开发数据团队文档结构复杂要检索质量LlamaIndex 专用解析器RAGFlow业务团队快速上线文档相对规范QAnythingFastGPT业务团队还需要Agent和工作流DifyFastGPT给客户做系统交付要权限和计费FastGPTDify文档极度混乱扫描件表格多RAGFlowLlamaIndex 前置解析服务4. 落地阶段最容易被低估的四个工程细节选型只是开始。我把这几年从落地项目里总结下来的问题分成四组每一个都值得在选型评审时写上风险清单。4.1 文档解析链路决定RAG上限很多人问“RAG知识库能存储图片吗”答案是能存但要看你怎么存。直接把图片文件塞进知识库向量化的是图片文件的索引信息要真正支持“图片内容问答”得走多模态向量化或者OCR文本提取这完全是两条技术路线。在选型时就要确认产品支不支持多模态入库还是只能走OCR转文本。“本地文本拆解工具”值得多说一句。文档解析不是装一个库就行要关注标题层级识别、表格结构还原、跨页段落拼接这些细节。实测下来解析环节做不干净后面调切分参数、调召回权重都是事倍功半。我建议把一份20页左右的复杂PDF作为固定测试样本每个候选产品跑一遍看谁还原出来的Markdown或结构化文档最接近原始版式——这个测试结果比任何功能列表都真实。4.2 切分、召回与重排一个完整闭环切分这块常见的执念是“固定512 tokens最稳”。固定切分确实简单但对带层级结构的文档来说它会把语义完整的章节拦腰截断。结构感知切分、基于语义段落切分效果通常更好。RAGFlow的模板化切分能定义出“标题正文”的组装方式值得参考。召回层面我强烈建议不要只依赖向量检索。混合检索——向量召回加关键词召回再融合——能明显改善专有名词、型号、编号的命中问题。重排更是被普遍忽略的一环实际工程里接一个bge-reranker这类开源重排模型检索结果top准确率往往能提一截。关键是召回和重排的参数不能靠拍脑袋要配一套评测集。4.3 评测没建起来别急着调优RAG项目一个常见死法是“demo效果还行上线后问题百出”。因为demo阶段根本没有量化指标。我的习惯是上线前先建一个Golden Set收集50到100个真实业务问题标注好期望答案和来源文档每次改切分参数、换重排模型、调提示词都拿这套数据跑指标。能用RAGAS这类框架做自动化评估最好跑不了就先人工标注但一定要有基线。没有评测闭环的优化都是玄学。你永远分不清这次效果变好是因为换了模型还是因为换了切分参数还是只是运气好。企业在选型时应该把这个能力作为硬性要求不管选哪个平台至少要能导出检索记录和回答记录方便自己拿Golden Set做回归对比。4.4 权限模型、部署形态与成本选型时就要谈清楚企业内部知识库必然涉及权限问题而开源RAG产品的权限深度差异很大。有的只有应用级权限所有用户能看到同一套知识库有的支持知识库级授权但做不到文档级行级过滤。如果业务要求按部门隔离数据选型时必须确认在检索链路里能不能做文档级权限拦截——很多产品在这一层是空白的。部署形态上docker compose拉起只能算开发环境。真正常态化运行要考虑向量库用什么、解析服务跑在哪、模型用本地还是API、是否需要GPU推理。RAGFlow这类带重解析服务的产品资源规划要提前算QAnything这类轻量部署虽然省心但规模上去后单机扩展能力有限选型时把数据量增长预期放进去。成本更是一个常被低估的变量。License免费不等于运行免费向量化要消耗模型调用或GPU时间重排要额外算力解析服务吃CPU和内存大规模知识库的存储索引也有开销。我见过项目因为解析配额耗完而卡住上线的这部分钱一定要在预算里单列。5. 我给正在决策的团队几条操作性建议最后分享几条实际操作中总结下来的经验不按优先级排但每一条都是踩过坑换来的。第一别急着做“终身决策”。开源RAG的组件化程度已经足够高了选型的结果更多是“起点在哪”而不是“终点在哪”。先用最小成本跑通一个真实业务的端到端流程再逐步替换瓶颈组件比一次性搭一个精心设计的平台更靠谱。第二选型对比时准备同一份“脏数据”。用一份真实的、带扫描页、带表格、带多级标题的企业文档去测试所有候选产品比较结构化输出质量。很多产品宣传的效果是在干净数据集上跑出来的你的数据不一定干净。第三决策树只负责帮你排除明显错误选项。同一分支里的产品差距远没有“框架型/平台型”这个层级差异大。只要大方向对剩下来的都可以靠人力补齐不用反复横跳。第四团队状态也是选型变量。没有专门运维团队就不要选一个需要天天照料解析服务的方案没有熟悉检索算法的工程师就不要选LlamaIndex然后把切分策略全交给自己。一个团队能长期维护的工具比纸面上性能最漂亮的工具更值钱。第五二次选型不一定要推翻整个栈。如果你已经选了一个平台后来发现它最弱的是文档解析可以直接外接一个解析服务把产出的结构化文本喂回去。先拆出瓶颈再针对性地补是成本最低的升级路径。RAG落地这件事真正拉开差距的不是模型选得多新而是文档吃得多干净、评测建得多早、权限想得多全。把这几个环节守住无论最终选哪款开源产品都不会走得太偏。