RAG 自托管还是低代码平台？按数据要求决定
数据截至 2026-07，价格与限额以各官网为准。
自托管还是低代码平台，这个问题的答案不在框架能力对比表里，而在你的语料能不能离开内网、模型调用允许发到哪里。先把数据要求这一条约束写死，再回头看技术选项，八成的纠结当场就消失了；反过来先挑框架、后补合规，往往要推倒重来一次。
常见的误解是把”自托管”当成一个统一的动作——好像选了自托管就意味着同一套部署工作量。实际上不同项目所谓的自托管完全不是一回事：有的是拉一个 Docker 镜像起个带界面的系统，有的只是给你一堆 Python 库、服务和向量库全得你自己跑。搞不清这个差别，做出来的成本估算会偏得离谱。
一、自托管在不同项目里不是一回事
先把形态分清楚，后面的成本判断才有基础。
RAGFlow 是可以直接部署的引擎。 它走 Docker 部署，官方提供 slim 与 full 两种镜像，slim 约 2GB、full 约 9GB，区别在于是否内置嵌入模型。选 slim 意味着嵌入这一步你得另外接；选 full 则是把嵌入模型一起打包进来，磁盘和拉取时间的代价换来少一层外部依赖。它同时带一套低代码界面来配 RAG 工作流，所以”自托管”和”有界面”在它身上并不冲突。
LangChain 和 LlamaIndex 是库，不是系统。 说”自托管 LangChain”其实是一种口语上的省略——你真正要自己跑的是一个 Python 服务，加上向量库、嵌入服务、任务队列、日志这一整套周边。库本身没有部署形态，它只是被 import 进你的进程里。这一点在做人力估算时最容易被低估：框架文档里几十行就跑通的示例，离一个能被同事天天用的内部服务还差一整个工程。
低代码平台（比如 Dify 这类） 的定位是把搭建成本压下去，让你更快看到一个能用的知识库。它也可以自托管，但你面对的是”装一整套带管理后台的系统”，而不是”写一个自己的服务”。
二、决定权在数据要求，不在 star 排名
选型讨论里最容易被拿来当论据的是 GitHub star 数。按第三方整理的截至 2026 年 1 月的 GitHub star 排名，LangChain 约 125,000、Dify 约 114,000、RAGFlow 约 70,000、LlamaIndex 约 46,500、Haystack 约 24,000。这组数字只说明关注度和社区体量，跟”适不适合你的语料、你的合规要求”没有直接关系；而且这是某个时点的快照，具体数值以各项目仓库当前页面为准。
真正把选项砍掉一半的，是数据约束。语料要留在内网，那么托管在公有云上的商业平台就直接出局，剩下的都是可自托管的方案；反过来，如果语料本身就是公开资料、内部也没有强制的落地要求，那么优先用低代码平台减少搭建成本，是更划算的选择——省下的时间可以拿去打磨分块策略和评估集，那两件事对最终效果的影响通常更大。
三、把”数据要求”拆成四个能回答的问题
“数据敏感”是个太模糊的说法，落不到部署方案上。建议在开会前先把下面四个问题的答案写下来，每个都要有明确的人拍板：
- 原始语料能不能离开内网？ 合同、病历、未公开财报这类，往往有明文规定；而产品手册、公开白皮书通常没有这条约束。这一问直接决定文档解析和存储放在哪。
- 嵌入和生成的调用允许发到哪里？ 很多团队把文档存在内网，却用公网 API 做嵌入——那等于把文档原文按块发出去了。这是最常见的口子，下一节单独说。
- 检索日志谁能看到？ 用户问了什么、命中了哪些片段，这些日志本身也可能是敏感的。平台方能不能看到、保留多久，要提前问清楚。
- 出了问题谁运维？ 自托管意味着升级、备份、故障恢复都归你。如果团队里没有能长期接手的人，纸面上省下的授权费很可能被人力成本吃掉。
四个问题答完，选项基本就自己收敛了。答案里只要有一条要求”内容不出内网”，路径就锁定在可自托管的方案上。
四、模型调用这一段最容易漏
把向量库和文档都放进内网之后，还剩一个容易被忽略的出口：嵌入模型和生成模型。只要这两步走的是外部 API，你的文档片段和用户提问就会离开内网，前面的部署工作在合规意义上就打了折扣。
要真正做到内容不出网，嵌入和生成都得用本地部署的模型，这会显著抬高硬件门槛。折中做法也存在，比如嵌入用本地小模型、只把最终拼好的提示词发给外部模型，但这仍然是在往外发内容，只是发得少一些，能不能接受要由合规口径拍板，不是技术上能自行决定的事。
如果计划用海外厂商的模型 API，还有一层准入前提要先讲清楚：这几家官方并未面向中国大陆开放，注册、控制台与 API 端点都在境外，具体以各自官网当前的地区政策页为准。市面上确实存在第三方中转服务，但其合规性与稳定性风险由使用者自负，本文不提供也不背书任何具体渠道。把这一条放在方案评审的前面说，比做到一半才发现链路走不通要省事得多。
五、低代码平台省掉的是搭建成本
低代码平台的价值很具体：省掉搭建成本。文档上传、分块参数、检索配置、对话界面、权限管理这些东西都有现成的，一两天就能让业务同事真的用上，而不是等一个月看 demo。对于还在验证”这个场景到底有没有用”的阶段，这个速度差别比框架灵活性重要得多。
代价也同样具体。平台把能力封装成配置项，配置项里没有的东西就不好加；当你需要一个非常规的分块逻辑、或者要在检索和生成之间插一段自定义的业务规则时，可能要绕，甚至绕不过去。另外，方案一旦长在平台的数据结构上，将来迁移是有成本的——不是迁不动，但要重新导一次数据、重配一次流程。
比较务实的路径是：先用低代码平台把场景验证掉，确认有人真的每天在用、确认瓶颈在哪，再决定要不要投入做自托管的定制方案。倒过来做——先花两个月自研，再发现业务方根本不用——是更贵的顺序。
六、决定自托管之后，按瓶颈挑框架
确定要自己搭之后，别从”哪个框架更强”开始比，从”我卡在哪一段”开始选。按第三方对比整理的经验，大致是这样几种情况：
- 瓶颈在解析（扫描件、复杂表格、版式糟糕的 PDF）：从 LlamaIndex 的 LlamaParse 或 RAGFlow 入手。RAGFlow 的差异化就在文档理解这一段——分块尊重文档结构，带版面感知解析和内置的知识图谱构建，适合扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的语料。
- 瓶颈在检索（嵌入模型、混合检索、重排）：LangChain、Haystack、Cognita 这几个可调的旋钮最多。
- 瓶颈在评估（说不清改动到底有没有变好）：不用换框架，在现有的框架上加挂 RAGAS 即可。
- 语料是有链接关系的结构化内容：考虑图检索，比如 RAGFlow 的 GraphRAG 方向。
顺带说一个和性能有关的口径。有第三方评测指出，LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15-20% 的延迟开销。这是第三方基准口径而非官方指标，测试条件不同结论也会变；实际影响还要看你的场景对首字延迟有多敏感，别把它当成硬性排除某个框架的理由。
从定位上讲，LangChain 出现最早、生态最大，有 chains、agents 以及大量模型、嵌入、向量库的集成，适合复杂 agent 循环和外部工具调用，代价是学习曲线更陡；LlamaIndex 走的是数据优先路线，专注对私有内容做索引和查询，RAG 专用的原语更贴身。两者不在同一层做同一件事。
七、向量库这一块别省
自托管方案里，向量库常常被当作”随便挑一个”的组件，但它直接决定了检索延迟和能不能做业务过滤。
常配的一个选择是 Qdrant，它支持过滤、payload 索引与量化，可以作为独立二进制运行，也可以跑在 Docker 容器里——这个部署灵活性对内网环境很实用，不一定非得起一整套容器编排。性能方面，第三方称在 100 万级以上向量规模下可做到 50ms 以内的检索，这是第三方口径，具体表现跟硬件、索引参数、过滤条件强相关，务必在你自己的数据上实测，别拿别人的数字做容量规划。
选向量库时值得提前想清楚的是过滤能力：知识库几乎一定会有”只查某个部门的文档""排除已作废版本”这类需求，如果向量库的过滤能力弱，这些逻辑就得在应用层用很别扭的方式补。
八、不是二选一，也说说这几条判断的局限
自托管和低代码不是对立的两派，框架之间也不是。一种常见的生产组合是：LlamaIndex 负责 ingestion 与索引，LangChain 负责编排，LangGraph 负责 agent 工作流。谁在哪一段更顺手就用谁，没必要为了架构统一而勉强用一个框架把所有事做完。
局限也要说清楚。第一，本文没有给任何价格数字——这些项目本身是开源库或开源引擎，真实开销主要落在服务器、模型调用和人力上，得按你自己的规模去算。第二，这个领域的版本迭代很快，功能边界几个月就会变一次，任何具体能力都以各项目官方文档当前版本为准。第三，合规判定不是技术问题，最终由谁能拍板”这份数据能不能出网”来决定，技术方案只是执行结果。第四，star 数、延迟百分比、检索毫秒数这类流传较广的数字大多来自第三方测试，参考可以，别当验收标准。
小结
自托管还是低代码平台，先答数据问题，再答技术问题。语料能不能出内网、模型调用发到哪里、日志谁能看、谁来运维，这四条答完，选项自然收敛。要快、约束松就用低代码平台把场景先验证掉；要数据留在内网就走可自托管的路线，并且别忘了嵌入和生成这两步也是出网口。决定自托管之后，按你卡住的那一段挑框架，而不是按谁的关注度高。最后记住这几类方案本来就能混着用，先跑起来再优化，比在选型表上纠结一个月划算。