跳到主要内容

中小企业开源 RAG 知识库怎么选：14 个平台实测横评，与三个必须读原文的许可陷阱

· 阅读需 28 分钟
sumshare
sumshare
coder

上一篇聊了 RAG 的现状与那条「像素方案」，那是「技术面」。这篇落到选型：中小企业想私有一部署一套 RAG 知识库，市面上这十几个开源项目到底怎么挑。

这篇做四件事：先把它们分类（它们根本不在一个赛道）→ 逐家拆解（含停更避坑区）→ 一张实测横评表 → 三个必须读 LICENSE 原文的坑。文中的 star 数、协议原文、最新版本、容器数全部是 2026-09-19 用 GitHub API 与 docker-compose 原文实测，不是二手转述；一手核不到的地方我直接标注「未证实」。

一句话先给结论：要编排能力 → Dify；要文档解析精度 → RAGFlow；要最省运维 → MaxKB；要开箱即用 → AnythingLLM；要把知识库嵌进现有系统 → AnythingLLM / LightRAG 这类「引擎」而不是「平台」。

一、先分类：它们根本不在一个赛道​

「哪个最好」是错的问法。把这 14 个项目摆在一起比「谁更强」，就像拿 MySQL 和 Excel 比「谁更适合存数据」。

类别代表一句话定位你付出的代价
应用平台型Dify、FastGPT、MaxKB拖拽编排 + 知识库 + 发布系统重、升级频繁、绑定深
RAG 引擎型RAGFlow、LightRAG、WeKnora只管把检索做准业务逻辑得自己写
开箱即用型AnythingLLM、Open WebUI、Onyx装完就有界面能用深度定制受限、偏个人/团队而非业务系统
避坑区Langchain-Chatchat、QAnything、R2R、Kotaemon曾经很火，现在不建议新上无人维护 / 漏洞无补丁

记住这条分界线：前三类是「用」，但你得想清楚买的是编排能力、检索能力还是上手速度——三者在这批项目里几乎不可兼得。

二、逐家拆解​

A. 应用平台型​

1. Dify —— 生态最成熟，但它是「平台」不是「知识库」​

  • 实测：156,363 star，v1.17.1（2026-09-10），最后提交 2026-09-18，TypeScript 为主（后端是 Flask + Celery，Python 3.12）；
  • 默认栈：PostgreSQL + Weaviate（VECTOR_STORE 默认值），对象存储走 OpenDAL；
  • 强项：可视化工作流、Agent 从工作流节点升级为独立可复用资产（v1.17.0 的里程碑改动）、MCP + 插件市场 + 自建 API 三路工具来源、可观测性接 Langfuse/Opik/Phoenix；
  • 知识库短板（写进官方文档的）：索引分「高质量（向量）」与「经济（关键词倒排，不耗 Token）」，高质量建成后无法降级；内置 PDF 解析不支持 OCR，扫描件直接失败，维护者在 issue 里回复「OCR will be available in RAG 2.0」；Rerank 默认关闭，且 TopK 与 Score 阈值只在启用 Rerank 时才生效（不开重排时这两个参数是摆设，这是最常被忽略的坑）；
  • 知识图谱：社区版没有。网上流传的「dense 0.65 + sparse 0.25 + graph 0.10」是某篇博客的自建实验，不是 Dify 内置能力——别写进选型矩阵。

2. FastGPT —— 知识库问答做得更专，官方部署分档给得最实在​

  • 实测：29,690 star，v4.17.0（2026-09-11），TypeScript，MongoDB（Mongoose）+ 中文分词用 @node-rs/jieba；
  • 官方部署分档表（这是所有项目里给得最清楚的一份）：PgVector 版测试档 2c4g，100 万组向量 4c8g / 50GB，500 万组 8c32g / 200GB；Milvus 版要求 ≥ 2.5.16，低于此版本 FastGPT 启动直接报错退出；
  • 强项：混合检索 + 重排、QA 拆分导入、chunk 级修改删除、知识库单点测试、完整调用链路日志；
  • 坑：① 必须外部依赖 MongoDB（且需副本集支持事务）+ 向量库 + Redis + MinIO + AI Proxy，有状态组件比 Dify 更多；② 默认索引策略曾导致召回退化——4.9.1–4.9.4 之间把「一个 Chunk 一个索引」改成子索引，丢了 Chunk 头部元数据，有用户只能回滚 4.9.0；③ MongoDB 全文检索不支持 $in，无法一次检索多个知识库，生产环境 1400 万行时单次查询可达 30 多秒，加索引能压到 1s 内但会牺牲多知识库检索能力——这是个硬权衡；④ 升级不可跳级、不可回退。

3. MaxKB —— 运维负担最低，社区版限制已在 V2 取消​

  • 实测：22,838 star，v2.10.6-lts（2026-09-03），GPL-3.0 纯净协议（35,149 字节标准 GPLv3 全文，无任何附加条款）；
  • 技术栈：Vue + Django + LangChain，PostgreSQL + pgvector 全在单容器内。官方在线安装就一条命令、一个容器，不依赖任何外部服务——这是全场运维负担最低的；
  • ⚠️ 最大的二手信息污染源：英文站 maxkb.pro/pricing 至今仍写社区版上限「2 users / 5 applications / 50 knowledge bases」，这是 V1 时代的过期页面。官方中文定价页明确「MaxKB V2 于 2025 年 7 月 17 日正式发布，社区版不再限制用户数量、应用数量和知识库数量」。别引用那组 2/5/50。
  • 社区版标「-」（仅付费版有）的关键项：开放 API、完整 RBAC、审计日志、SSO（LDAP/OIDC/CAS/OAuth2/SAML2）、第三方应用接入（企微/钉钉/飞书/公众号）；
  • 价格透明：专业版 ¥4.8 万/套（永久授权），第二年起维保 ¥9,600/年；企业版（多租户+集群）需询价；
  • 坑：官方 FAQ 的知识库首条就是「智能分段效果不理想」；默认匹配单个空行 \n\n，遇到连续多个空行会漏掉切分点（有用户导入 135 条处方仅前 2 条正确分段）；所谓「混合检索」是向量相似度与全文得分直接相加（(1 - 向量距离) + ts_rank_cd，得分可能超过 1），不是重排模型，且检索权重不可调；pgvector 在文档量超过 1000 页后出现内存压力，而集群/分片是企业版专属——撞到天花板没有官方扩容路径。

B. RAG 引擎型​

4. RAGFlow —— 文档解析最强，但有个大多数人不知道的变化​

  • 实测：90,966 star，v0.27.2（2026-09-10），Apache-2.0 纯净协议（无附加条款）；
  • ⚠️ 一个 2026 年的结构性变化：GitHub 语言统计现在显示 Go 占 49.8%（27.2 MB），Python 30.5%，TypeScript 15.7%——Go 已是第一大语言。compose 里也能看到对应证据：GO_HTTP_PORT=9384、GO_ADMIN_PORT=9383、--enable-adminserver。README 仍要求 Python ≥ 3.13。（Go 具体承担哪些职责，我没有逐模块核实，不臆测。）
  • 默认只起 5 个容器（实测 docker-compose-base.yml）：ragflow-cpu + minio + redis + es01 + mysql。默认 profile 是 ${DOC_ENGINE},${DEVICE},metadata-mysql，MEM_LIMIT=8073741824（约 8GB，给 ES 用）；
  • 文档引擎已扩到 6 种：Elasticsearch、OpenSearch、Infinity、SereneDB、OceanBase、SeekDB——这个扩展速度说明「检索后端可换」是它的核心设计；
  • 强项：DeepDoc 深度文档理解（复杂 PDF、多栏、表格、扫描件）、混合检索 + 重排、引用溯源、Agentic Workflow + MCP（2025-08 起）；
  • 坑：官方 README 明确只提供 x86 镜像，不提供 ARM64；对机器要求高（资源开销主要来自 ES 与 DeepDoc 模型）；默认 nats、sandbox-executor-manager 等新基础设施组件在 compose 里可选项很多，部署前必须读一遍 .env 的 profile 组合逻辑，否则容易起一堆用不上的容器。

5. LightRAG —— 想做 GraphRAG 又不想烧钱的话，看这个​

  • 实测：39,756 star，v1.5.7（2026-09-02），MIT，查询日仍有提交，非常活跃；
  • ⚠️ 一个被大量二手文章讲错的地方：README 的「dual-layer architecture」指的是 知识图谱 + 向量嵌入两层；论文的「Dual-level Retrieval Paradigm」指的是同一张实体-关系图上的双层检索策略（low-level 打具体实体与属性，high-level 打跨实体主题与汇总）。它不是「实体图 + 主题图」两张物理图——这个误传很广，写选型文档时别抄错；
  • 检索模式是 5 种不是 4 种：local / global / hybrid / naive / mix（官方默认）；
  • 相对 GraphRAG 的核心优势是成本：论文口径下，GraphRAG 需要一个文档集生成约 1,399 个社区、每份社区报告平均 1,000 tokens（合计约 610,000 tokens）并遍历社区，数百次 API 调用；LightRAG 用不到 100 tokens 做关键词生成与检索，全程 1 次 API 调用。增量更新时 GraphRAG 要拆解并完整重生成社区结构，LightRAG 直接并入新实体与关系；
  • 代价：① 每个 chunk 都要 LLM 做实体关系抽取，对模型能力的要求高于传统 RAG，官方给的本地模型下限建议是 Qwen3-30B-A3B；② 默认四类存储全是内存型，官方明确警告「只适合小规模测试、评估与调试，不适合生产」，生产要换 PostgreSQL（官方推荐 PGTableGraphStorage，普通 PG 14+ 即可，不再依赖 AGE 扩展）；③ 无 RBAC / SSO / 多租户账号体系，官方原文承认「只支持管理员账号密码配置，完整账号系统尚待开发」；④ 不支持 MCP。

6. WeKnora（腾讯）—— 社区版企业级特性最全的一个​

  • 实测：27,024 star，v0.8.0（2026-09-03），MIT（含第三方组件声明）——注意 GitHub API 判为 NOASSERTION，因为它不是标准 MIT 全文而是复合文本；
  • 技术栈：Go 1.26 后端 + Vue 前端，默认元数据库/检索引擎是 ParadeDB（PostgreSQL 17 + pgvector + pg_search BM25），文档解析独立服务 docreader（gRPC，内含 LibreOffice、Playwright）；
  • 实测容器：5 个常驻（app、docreader、frontend、postgres、redis）+ 18 个可选 profile（neo4j / qdrant / milvus / weaviate / doris / dex / langfuse / searxng / minio / mcp / sandbox …）。别被「23 个服务」吓到，默认只起 5 个；
  • 社区版就给的企业级能力（8 家里最全）：RBAC 4 级角色（Owner/Admin/Contributor/Viewer）、多工作区、每个工作区独立审计日志、OIDC（含 JWKS 校验）、细粒度 scoped API key、API key 与凭据 AES-256-GCM 静态加密；
  • 官方硬件建议：4 核 8GB 起步（docreader 含 LibreOffice + Playwright，较吃内存）；
  • ⚠️ 澄清一个流传的说法：「WeKnora 必须依赖腾讯云」——官方文档不支持。它是完全模块化的，腾讯能力（IMA、VectorDB、LKEAP rerank、混元）都只是 16+ 个 provider 里的一项；Lite 版默认走本地 Ollama。强绑定体现在发布渠道（镜像是 wechatopenai 组织、是微信对话开放平台的核心框架），不是技术依赖；
  • 坑：文档以中文为主（docs/ 下绝大多数是中文文档、官方文档站章节标题也是中文），对非中文团队不友好；Open Issues 680 个偏高；v0.8.0 有破坏性变更（移除 Local host-process 沙箱后端、Docker 沙箱默认关闭）；Lite 版功能受限（无共享空间、单空间）。

C. 开箱即用型​

7. AnythingLLM —— 单容器、可桌面、MIT，最省心的入口​

  • 实测：66,195 star，v1.16.1（2026-08-27），MIT，查询日仍有提交；2026 年 1–8 月发了 13 个版本；
  • 实测部署：compose 里就 1 个服务 anything-llm。官方推荐最低 2GB RAM / 2 核 / 5GB 存储，且不强制 Docker（有桌面端和裸机路径）；
  • 默认栈：Node + Express，默认向量库 LanceDB，元数据默认 SQLite（可换 PG）；
  • ⚠️ 一个硬性环境要求：CPU 必须支持 AVX2（LanceDB 编译基线是 Intel Haswell 2013+），否则 server 启动即 Illegal instruction (core dumped)。Proxmox/QEMU-KVM 默认的 kvm64 CPU 模型会屏蔽 AVX2，必须设为 host——虚拟化部署踩这个坑的很多；
  • MCP 是内置的（非插件），支持 stdio/SSE/streamable 三种传输，但官方明确只支持 Tools，不支持 Resources / Prompts / Sampling；托管云版不支持 MCP；
  • 短板：多用户模式进入后不可回退；SSO 只有一个「Simple SSO Passthrough」（令牌 URL），没有原生 OIDC/SAML/LDAP；数据连接器只有 9 个；没有知识图谱（仍是开放 feature request）。

8. Open WebUI —— 最流行的自托管 LLM 界面，但许可证有个精确阈值​

  • 实测：152,504 star，v0.11.3（2026-08-31），2026 年 1–8 月发了 26 个版本；

  • ⚠️ 它不是 OSI 开源。GitHub API 判 NOASSERTION，实际是自定义的「Open WebUI License」= BSD-3 三条款 + 第 4 条品牌保留条款。我把原文拉出来了：

    …licensees are strictly prohibited from altering, removing, obscuring, or replacing any "Open WebUI" branding … except … (i) deployments or distributions where the total number of end users … does not exceed fifty (50) within any rolling thirty (30) day period

    即：终端用户 30 天滚动周期内不超过 50 人，才可以去品牌；超过就得保留标识或买企业许可。 内部用通常没事，但对客产品必须算这一条；

  • 技术栈：Python + FastAPI，前端 Svelte；默认向量库 ChromaDB（本地 SQLite-backed），元数据默认 SQLite；

  • 强项：文档抽取引擎有 8 个可选（Tika、Docling、Mistral OCR、Datalab Marker、MinerU、PaddleOCR 等）；混合检索（BM25 + 向量）+ CrossEncoder 重排可开关；SSO/OIDC/LDAP/SCIM 2.0/RBAC/审计日志在免费社区版就有，不限用户数；

  • 坑：① 默认 ChromaDB 本地模式不是 fork-safe，多 worker / 多副本并发写会立刻崩，超过单副本必须换外部向量库；② 默认用 pypdf 解析，官方自己警告有内存泄漏，建议换 Tika 或 Docling；③ 一个配置静默失效陷阱——File Context 开 + Builtin Tools 关 + Function Calling 保持 Default 时，挂在模型上的知识永远不会被检索到；④ MCP 只支持 Streamable HTTP（不支持 stdio，需 mcpo 代理）；⑤ 未设 WEBUI_SECRET_KEY 时，OAuth 连接的 MCP 工具每次重启容器都会失效。

9. Onyx（原 Danswer）—— 连接器最多的企业搜索，Open Core 边界清晰​

  • 实测：32,162 star，v4.7.7（2026-09-16），MIT + ee/ 目录走 Onyx Enterprise License；2026 年发了 v3.0.0（03-10）与 v4.0.0（05-26）两个大版本；
  • ⚠️ 连接器数量有三个官方口径，别抄错：定价页写「40+」（2025 年口径）、README 写「over 50+」、而官方文档 sitemap 实测去重后是 56 个顶层连接器条目。当前准确口径约 54–56 个，「40+」是过时的；
  • 技术栈：Python 3.13 + FastAPI，前端 Next.js 16 + React 19；默认检索已从 Vespa 切到 OpenSearch（v3 双写迁移，v4 起完全 OpenSearch-only）；
  • 有 Lite 模式：只起 4 个服务（api_server、web_server、postgres、nginx），不用向量库也不用 OpenSearch，全部收敛进 PostgreSQL，基线内存不到 1GB——对中小企业这是很关键的一条（最小 2 vCPU / 2GB / 10GB）；
  • ee/ 里锁的是什么：OIDC/SAML SSO、Permission Sync Connectors、白标、User Groups & RBAC、Group-Based Permissions、Usage Analytics、Encrypted Secrets。官方把 EE 目标用户定义为「100 用户以上的组织」；
  • ⚠️ 两份官方来源自相矛盾：定价页的 Business 档（$20/user/月）列表含 RBAC，但 EE 文档把 RBAC 列为 EE 专属。且定价页档位是 Onyx Cloud 订阅，与自托管 EE 许可不完全等价。选型时以 EE 文档为准更稳妥；
  • 坑：v3 → v4 必须先经 v3 迁移，跳过 v3 直接升 v4 会「result in complete loss of indexed data」；v4.7 权限模型有破坏性变更（API key roles 被 group-based permissions 取代）；2026 年有 4 个安全公告，其中一个 critical（跨用户 OAuth token 泄漏，/api/mcp/servers*，2026-07-20）。

10. Kotaemon —— 不建议新上了（但不是因为协议）​

  • 实测：25,775 star，Apache-2.0（纯净，无 Open Core 分层），最新版 v0.12.0（2026-05-31）；
  • 关键事实：main 分支最后一次提交 2026-05-30，commits?since=2026-06-01 返回 0 条；此后社区 PR（#853 至 #862）全部 open 未合并；社区 issue #786「Project status and future updates」（2025-09-12 创建）至今 open，维护者零回复；
  • 结论口径要说准：仓库未归档、未发停维声明、2026 年 2–5 月仍有版本发布，但已连续约 16 周零提交、零 PR 合并、对活跃度询问零回应——是「未归档但无维护活动」，不是「官方宣布死亡」。引用时别把话说死。

D. 避坑区：曾经很火，现在别新上​

这一节是我最想提醒的，因为它直接改变选型结论。star 数是存量指标，pushed_at 才是增量指标。

11. Langchain-Chatchat —— 38.6k star，但带着无补丁的高危漏洞​

  • 实测：38,644 star，Apache-2.0，最后提交 2025-11-10，最新 release 仍是 v0.3.1（2024-07-12），无新 tag；
  • 仓库未被归档（archived: false），所以乍看是活的——这点最容易误判；
  • README 的「项目里程碑」止于「2024 年 6 月：0.3.0 发布」，随后一句「让我们一起期待未来 Chatchat 的故事」；
  • ⚠️ 最要命的是漏洞：CVE-2026-30617（未认证 RCE，经 MCP STDIO server 配置，CVSS 8.6）公告明确写 "Fixed versions: None published"；CVE-2026-7847 被标为影响全部版本且 "There is no fixed version"。根因在于代码库冻结在 2024-07，而这些 CVE 是 2026 年公布的——根本不存在一个能修掉它们的升级目标；
  • 官方后继项目是 LangGraph-Chatchat（同团队），保留知识库目录格式便于迁移。

12. QAnything（网易有道）—— 默认分支已经是 AGPL-3.0​

  • 实测：14,176 star，最后 release v2.0.0（2024-08-30），距今约两年；
  • ⚠️ 协议这条最容易写错，我逐分支核对过：默认分支 qanything-v2 是 AGPL-3.0（34,523 字节 AGPLv3 全文，GitHub 徽章也是 AGPL-3.0）；只有老的 master 分支是 Apache-2.0。很多二手资料写「Apache-2.0」引用的是历史快照；
  • 对中小企业的含义：AGPL-3.0 有网络条款——把它作为 Web 服务暴露（哪怕只是内部），需向使用者提供对应源码。这比 MaxKB 的 GPLv3 更严格；
  • 部署负担重：compose 实测 6 个服务（Elasticsearch + Milvus + etcd + MinIO + MySQL + 应用），要运维 ES 和 Milvus 才能拥有一个知识库；v2.0 最低 20GB 内存；项目自己的 FAQ 开头就是「报错大概率是因为内存不足」。

13. R2R —— 文档站已下线，2026 年新增多条未修复安全 issue​

  • 实测：7,999 star，MIT，最后提交 2025-11-07，GitHub 最新 Release 停在 v3.6.5（2025-06-06）；
  • ⚠️ 一个容易写错的版本口径：PyPI 上有 3.6.6（2025-08-17），但该版本没有对应的 GitHub tag / Release。写「最新 Release 3.6.6」是错的；
  • 旁证：官方文档站 r2r-docs.sciphi.ai 实测返回 404，云入口 app.sciphi.ai 返回 402，仓库 commit 历史里有一条 release note 直接写 "Remove SciPhi Cloud references"；创始人现已转任另一家公司 CEO；
  • ⚠️ 2026 年新增 6 条未修复安全 issue，均处 open 状态，标题自称包含 CRITICAL 认证绕过、跨用户 IDOR、多处 SQL 注入——结合「约 10.4 个月无推送」，「没修」是合理推断（各条技术细节我未逐条验证，不当作已确认漏洞，但足以说明维护状态）。

14. Khoj —— 云版已关停，公司转向新产品​

  • 实测：37,407 star，AGPL-3.0，最新 Release 是 2.0.0-beta.28（2026-03-26），2.0.0 至今未发正式稳定版；最后提交 2026-08-02；
  • 官方 Sunset 页面明确：「Khoj Cloud Has Been Sunset / April 15, 2026」，自述失败原因原文提到「multiple (6!) clients」让规模化变得困难，并称「Khoj remains fully open-source. You can continue to self-host it」；
  • 公司重心转向 Open Paper 与 Pipali 两个新产品；
  • ⚠️ 文档没同步：README 仍宣传 Khoj Cloud / Khoj Enterprise，并链向已 404 的 khoj.dev/teams。看到 README 说「有企业版」时，去点一下那个链接——这是识别项目健康状况最快的办法。

三、横评表​

表 1：实测基础数据（2026-09-19，全部来自 GitHub API 与仓库原文）​

平台Star协议（实测）最新版（日期）最后提交维护判断
Dify156,363改版 Apache-2.01.17.1（09-10）09-18极活跃
Open WebUI152,504自定义（BSD-3 + 50 人品牌条款）0.11.3（08-31）09-18高度活跃
RAGFlow90,966Apache-2.0（纯净）0.27.2（09-10）09-18极活跃
AnythingLLM66,195MIT1.16.1（08-27）09-19活跃
LightRAG39,756MIT1.5.7（09-02）09-19高度活跃
Langchain-Chatchat38,644Apache-2.0v0.3.1（2024-07）2025-11-10停更 + 漏洞无补丁
Khoj37,407AGPL-3.02.0.0-beta.28（03-26）2026-08-02降速（云版已关停）
Onyx32,162MIT + ee/ 企业协议4.7.7（09-16）09-19高度活跃
FastGPT29,690改版 Apache-2.04.17.0（09-11）09-18活跃
WeKnora27,024MIT（含第三方声明）0.8.0（09-03）09-18高度活跃
Kotaemon25,775Apache-2.00.12.0（05-31）07-14（main 停 05-30）未归档但无维护活动
MaxKB22,838GPL-3.0（纯净）2.10.6-lts（09-03）09-18活跃
QAnything14,176AGPL-3.0（默认分支）2.0.0（2024-08）09-03停更
R2R7,999MIT3.6.5（2025-06）2025-11-07实质停更 + 安全 issue 未修

表 2：选型维度（单位：本地实测 compose / 官方文档）​

DifyFastGPTMaxKBRAGFlowWeKnoraAnythingLLMOpen WebUIOnyx
默认容器数（实测）16多（有状态）15511–24（Lite）/ 多（Std）
默认向量库WeaviatePgVectorpgvectorESParadeDBLanceDBChromaDBOpenSearch
需外部服务否是（Mongo 副本集）否否否否否否（Lite）
知识图谱❌❌❌❌（有 Agentic）✅ Neo4j❌❌✅ 可选
MCP✅✅✅✅✅✅（仅 Tools）✅（仅 HTTP）✅ 双向
社区版 RBAC/SSO/审计❌ 全在付费版❌ 全在付费版❌ 全在付费版❌✅ 全有⚠️ 仅 Simple SSO✅ 全有❌ 在 ee/
官方最低配置2C/4GiB2c4g4C/8GB—4C/8GB2GB/2核未证实2vCPU/2GB（Lite）

表中「默认容器数」是我实际解析各家 compose 文件的 image/build 服务并套用默认 profile 得出的，不是文档转述。Dify 的 16 = 13 个常驻服务 + 默认 profile（weaviate,postgresql,collaboration）带出的 3 个；Dify 另有 26 个可选 profile 服务（MySQL/ES/Qdrant/Milvus/Oracle 等）。WeKnora 的 5 是常驻数，另有 18 个可选 profile。

四、三个必须读 LICENSE 原文的坑​

开源 ≠ 无条件可用。 我逐份读了这几家的 LICENSE 原文，有三条是选型会上一定会被问到的：

坑 1：Dify 和 FastGPT 不是 Apache-2.0，是「改版」​

两家的 LICENSE 都写了同一句话：licensed under a modified version of the Apache License 2.0, with the following additional conditions。附加的是两条：

  1. 多租户限制：Dify 是「不得用其源码运营多租户环境（一个 tenant = 一个 workspace）」；FastGPT 是「不得运营与 FastGPT 类似的 multi-tenant SaaS」。都要书面授权。
  2. LOGO 条款：不得移除或修改控制台及应用的 LOGO/版权信息。Dify 还补了一句「交互设计受外观专利保护」。

对中小企业的实际含义：内部自托管、当自有产品的后端，都不触发商业许可——受限的只是「拿它开 SaaS 转卖给多客户」。Dify 的协议已被第三方 license 数据库收录为独立标识 dify-exception-apache-2.0，即被认定为非标准 Apache。

坑 2：Open WebUI 的品牌条款有个精确数字：50 人 / 30 天​

不是「不能商用」，也不是「随便改」——阈值是 30 天滚动周期内直接终端用户不超过 50 人。低于这个规模可以去掉品牌；超过就必须保留标识、拿到书面许可，或买企业许可。内部工具通常无感，做对客产品必须逐字看。

另外它是三段协议并存：a76068d 之前是 MIT、到 60d84a3 之间是 BSD-3、之后是 Open WebUI License。官方 FAQ 说「可以零限制 fork v0.6.5」——如果你的合规部门只认 MIT，这条路存在，但那是很老的版本。

坑 3：AGPL 和 GPL 的差别，在网络服务场景是实质性的​

  • MaxKB 是 GPL-3.0：强 copyleft，但没有网络条款——纯内部自托管不触发分发义务；
  • QAnything 默认分支是 AGPL-3.0、Khoj 是 AGPL-3.0：有网络条款——把修改后的版本作为 Web 服务暴露，需向使用者提供对应源码。哪怕只是内部访问，合规上也要走一遍。

**所以「都是开源」这句话在选型会上一文不值。**读原文，读原文，读原文。

五、部署成本：三类平台的真实体感​

实测容器数说完了，落到中小企业最关心的钱和运维：

最省心的一档（MaxKB、AnythingLLM）：单容器，不用运维任何外部中间件。MaxKB 官方 4C/8GB + 100GB 盘；AnythingLLM 官方 2GB/2 核。但省心是有代价的——MaxKB 的检索能力有天花板（pgvector + 分数相加式「混合检索」），AnythingLLM 的多用户和 SSO 很薄。适合「先把知识问答跑起来」。

中间一档（RAGFlow、WeKnora）：默认 5 个容器，需要理解 profile 组合。WeKnora 官方建议 4C/8GB（docreader 吃内存）；RAGFlow 因为 ES 与 DeepDoc 更重。这一档是「检索质量明显上一个台阶」的性价比拐点。

最重的一档（Dify）：默认 16 个容器。官方最低 2C/4GiB，但这个数字和「可用」差距很大——有公开压测显示 4C8G 单实例约 10qps 就把 CPU 打满，应用与管理端同时不可用；内网离线部署要拉约 30 个镜像、几十 GB。如果你只是要一个知识库，Dify 是过度配置。

关于自建 GPU：这是另一个容易算错的账。多个来源的结论一致——低并发、偶发使用场景直接调 API 更划算；自建的盈亏平衡点取决于利用率而非规模，有实验显示自建 GPU 只有在利用率达到 22–48% 时才比 serverless 便宜，在 5–10% 利用率下反而贵 2–4 倍。中小企业做 RAG 知识库，先不要买卡。

六、怎么验证：别靠 demo，靠评测集​

选型会上最容易糊弄过去的一步，也是最该做扎实的一步。用你自己的最烂文档去测——扫描件、合并单元格的 Excel、截图——而不是干净的 PDF。

成熟的评测体系已经收敛到四个指标（RAGAS 提出，现在几乎所有框架都用）：

指标测什么对应故障
Faithfulness（忠实度）答案是否完全基于检索到的上下文幻觉
Answer Relevancy（答案相关性）答案是否直接回应问题答非所问
Context Precision（上下文精度）相关文档排序质量检索噪声大
Context Recall（上下文召回率）是否覆盖标准答案所需关键信息检索遗漏

中文场景有两个可用的公开基准：

  • CRUD-RAG（中科大等）：按 CRUD 四类操作划分，覆盖文本续写、单/双/三文档问答、幻觉修改、多文档摘要，并自带 86,834 条检索库——它的价值在于把「检索库构建」也纳入评测，而不只是问答；
  • RGB：中英双语，专门测四项能力——噪声鲁棒性、否定拒绝、信息集成、反事实鲁棒性。它的著名发现是 RAG 系统在「否定拒绝」上普遍很差，证据不足时倾向强行生成。

规模上的工程标准（综合多份实践）：PoC 50–100 条；内部工具上线 200–500 条；面向用户 1000+ 条。建议加入 5%–15% 的「拒答题」和「干扰题」——从 10% 开始验证。

⚠️ 三个必设的对照基线，否则「Recall@5 = 0.81」这个数字没有意义：纯 BM25 关键词检索（检验向量检索的增益）、纯 LLM 无检索（检验 RAG 本身值不值）、人类表现（上限参考）。

落地节奏（可直接抄的做法）：把线上 Trace 一键转测试用例（Langfuse 等可做），差评 Case 优先入集；接进 CI 做质量门禁——提测 50 条 / 阈值 0.70（faithfulness + precision），预发 200 条 / 0.75（全四指标），生产 200 条 / 0.80。

一个常被忽略的第五维度：上面四个指标都默认检索索引本身是可信的。有分析指出，一个系统可以在所有标准指标上接近满分，却在「忠实地引用一条业务上已经过时的错误定义」。所以还要监控索引的可信度——文档新鲜度、责任归属、版本时效。这比调参重要。

七、选型决策​

如果你只想记三句话：

  1. 先问「我买的是什么」——Dify 卖编排，RAGFlow 卖解析，MaxKB 卖省心，LightRAG 卖图检索，Onyx 卖连接器。没有一个卖「全都好」。
  2. pushed_at 比 star 重要。这篇里 38.6k star 的 Langchain-Chatchat 已停更且漏洞无补丁，14.2k star 的 QAnything 停在两年前。选型表里必须有「最后提交」这一列。
  3. 协议要读原文。Dify/FastGPT 是改版 Apache、Open WebUI 有 50 人品牌阈值、QAnything 是 AGPL。「开源」两个字在法务那里不构成任何结论。

下一篇（高 ROI Agent 场景盘点）会接着这篇的底座往上走：智能客服、商业尽调这些被讲烂了的场景，真实 ROI 到底是多少，以及哪些数字是厂商编的。

参考​

实测数据来源（2026-09-19）：

  • GitHub REST API：/repos/{owner}/{repo}（star/license/pushed_at/language）、/releases/latest、/languages
  • LICENSE 原文经 raw.githubusercontent.com 直读：Dify、FastGPT、MaxKB、Open WebUI、Onyx、WeKnora、QAnything（逐分支）
  • 部署数据经解析仓库内 docker-compose*.yml 与 .env.example 得出

官方文档与项目内文件：

评测：

本站相关：

声明：本文无厂商合作。star 数、版本号、协议条款均为 2026-09-19 实测快照，各项目迭代快，选型前请以官方仓库与最新 LICENSE 为准。凡我未能从一手来源核实的，文中已标注「未证实」；「适不适合」是基于公开事实与社区经验的判断，欢迎讨论。