在 GitHub 上搜 "RAG"，出来的项目数以千计。我维护的一个开源项目目录里，光是"RAG 与知识库"这一个分类就收了 843 个。对要选型的人来说，这不是财富，是噪声。
下面是我自己用的三步筛选法，从 843 到 1，每一步都有明确的淘汰标准。
第一步：用段位粗筛，但别迷信 stars
先看 star 数分段，目的是淘汰长期无人维护的项目，不是选最高的：
- 15 万+ 段位：dify（155k）、open-webui（152k）——平台型，功能全，社区大；
- 10 万段位：langchain（146k）、awesome-llm-apps（138k）、graphify（118k）——框架与合集型；
- 7-8 万段位：crawl4ai（84k）、hello-agents（79k）、headroom（72k）——特定环节的工具型。
注意两点。第一，stars 衡量的是关注度，不是匹配度：langchain star 再多，也解决不了"我只要一个能私有部署的知识库问答"这个需求。第二，要看趋势而不是绝对值：一个 8 万 star 但半年没 commit 的项目，不如一个 2 万 star 且每周都在修 issue 的。
第二步：按场景归类，砍掉不对口的
843 个项目大体落在四类里，先想清楚你要哪类：
- 平台型（dify、open-webui）：开箱即用的界面+工作流，适合不想写代码的团队；
- 框架型（langchain、llama-index）：给你积木自己搭，适合有工程力量的团队；
- 环节工具型（crawl4ai 管数据抓取、向量库管存储）：补进你现有链路里的某一环；
- 垂直应用型：面向特定场景（客服、调研、会议纪要）的成品。
多数选型错误发生在这里：要平台的人选了框架，结果养不起工程团队；有工程能力的人选了平台，结果被界面束缚。先把这一步定死，候选通常就只剩五六个。
第三步：两文档冲突测试做终筛
最后的几个候选，用我之前写过的一个五分钟手工测试：上传两份只有日期冲突的同源文档，问一个答案取决于"哪份是当前版本"的问题，看它引用哪份、敢不敢说"两份不一致"。能诚实处理冲突的才进短名单——这一步抓的是"答案流畅但出处错误"的失败，演示里看不见，指标里也不疼。
方法全文在这里：《测一个 RAG 工具，五分钟就够了：两份日期冲突的文档》。
筛完之后
短名单里的项目，再做两件事：读它的 issue 区（看真实用户在抱怨什么），以及用自己的真实文档跑一周。目录、测试、试用都是必要条件，没有一个是充分条件——选型最后省不掉的，是拿自己的场景喂它。
我把这 843 个项目的目录放在这里，可以按分类、stars、活跃度直接筛，网页免费浏览：
https://aiworkstation.cn/githubai/
声明：我是 AI 开源项目雷达的开发者。本文由 AI 辅助整理；筛选方法本身是重点，适用于任何项目目录。文中 star 数为撰写时的目录快照数据。
