RAG 排行：15.6 万星的第一名，根本不是引擎

RAG 排行：15.6 万星的第一名，根本不是引擎

01

Top 10：引擎只占了一个位置

▲ RAG / AI 应用相关仓库星数 Top 10 · GitHub 搜索口径 2026-10-22

第一名 open-webui，15.6 万星。它的自我定位是「友好的 AI 界面」，支持 Ollama 和 OpenAI API。它是目前个人用户跑本地模型最顺手的壳，星数主要来自这个。

▲ 榜首 open-webui：About 写的是「友好的 AI 界面，支持 Ollama 和 OpenAI API」，截图 2026-10-26

第二第三是平台和合集。langchain-ai/langchain 14.8 万星，官方定位已经从「LangChain 这个库」改成了「agent 工程平台」；Shubhamsaboo/awesome-llm-apps 14.3 万星，是 100 多个 AI agent、skill 和 RAG 应用的合集。两者都不是检索引擎。

第六名才是真正的 RAG 引擎。infiniflow/ragflow 9.3 万星，是开源 RAG 引擎里的头名，做的是文档理解加检索增强的完整链路。

来源：GitHub Search API，q=topic:rag，sort=stars，统计日 2026-10-22；星数、fork、主语言取自同一响应。口径说明：星数为统计日累计值。

02

把这张榜按「你实际会用的东西」重排

▲ 按实际用途重新归类后的星数合计

RAG 这条链现在是四步。很多人以为 RAG 就是「检索 + 生成」，其实现在的链路是：先 crawl4ai 抓数据，再 PaddleOCR 解析文档，再 ragflow 做检索，最后 open-webui 提供界面。

上面这张按用途重排的图把这十个项目分成七组：最大的一组是界面与壳（open-webui 和 langchain），然后是上下文工程（graphify 和 claude-mem）、合集与教程、检索引擎（ragflow）、文档解析（PaddleOCR）、数据获取（crawl4ai），最后是中文教程仓库 hello-agents 单独一组。

graphify 13.3 万星、claude-mem 10.2 万星，合成一组 23.5 万。graphify 把整个代码库连同文档和配置变成一张能查询的知识图，在 Claude Code、Cursor、Codex、Gemini CLI 里是一个 /graphify 技能，靠本地解析代码结构建图，不依赖向量库。

claude-mem 是另一个思路：把 agent 这次会话干过的事全记下来，用模型压一遍，再塞回后面的会话。这两个都不叫 RAG，但解决的是同一个问题：怎么把对的东西喂给模型。

两个合集型项目的用法不一样。awesome-llm-apps 收的是 100 多个 AI agent、skill 和 RAG 应用的现成实现，克隆下来改就行；Prompt-Engineering-Guide 收的是提示词、上下文工程和 RAG 的指南、论文、笔记和例子，跟 datawhalechina/hello-agents 那本《从零开始构建智能体》一样，都是拿来读的。

星数高就代表靠谱吗？这行的星数分布比别的行平。第一的 open-webui 15.6 万星，倒数第一的 Prompt-Engineering-Guide 7.9 万星，头尾只差一倍。也就是说在这一行里，光看星数挑不出谁更靠谱——得看它到底管哪一段。

前两名也不是一回事。open-webui 15.6 万星是自带界面的本地 AI 对话壳，支持 Ollama 和 OpenAI API；langchain 14.8 万星是给开发者用的框架和平台，它现在自己的定位是 agent 工程平台。一个装完就能聊，一个得自己写代码。

怎么分辨哪个是真引擎？看它自己有没有做检索这件事：ragflow 自称是 RAG 引擎，open-webui 自称是界面，awesome-llm-apps 自称是合集。这行最大的误读，就是把界面当引擎。

打个比方：引擎是发动机，界面是方向盘。开车两样都得有，但没有发动机，方向盘转得再顺也白搭。

给你的选型清单。要搭一套能用的本地知识库，照着上面那张分组图对着自己的需求挑：哪一段该由谁来做，图上分得清清楚楚，缺哪一块补哪一块。要给自己的代码库做问答，先看 graphify。要让 agent 记得住昨天说过的话，看 claude-mem 这一类记忆层。

缺哪块补哪块，别一锅端。

来源：GitHub Search API 同一批快照（2026-10-22）；用途归类为本号依据各仓库公开 README 描述所做的判断。

03

RAG 到底该怎么做

先想清楚：RAG 解决的是哪一类问题？它解决的是「答案必须来自这批资料」，不是「让模型更聪明」。我个人觉得，答案公开就能查到的问题，本来就不该上 RAG；凡是出了错要能追回某一份文档、每句话都要带出处的地方，才值得搭这套东西。

真正需要投入的是数据那一端。crawl4ai 8.6 万星、PaddleOCR 9.2 万星，两个加起来 17.8 万星，都在解决「把非结构化数据变成干净文本」。这才是 RAG 的工作量所在——模型调得再好，前面喂进去的是垃圾，答案就是垃圾！

怎么自己把榜首那个跑起来。先说清楚：open-webui 是聊天界面，不是 RAG 引擎。装完你得到的是一个本地聊天窗口，模型和检索还要另配——模型接本机 Ollama 或 OpenAI API，检索那一环要靠 ragflow 这类真引擎，界面本身不带。

装它最省事的是 pip（上游要求 Python 3.11，缺了装不上）：

pip install open-webui

装完跑 open-webui serve，浏览器开 http://localhost:8080 能看到对话框，就算装成了！

想跑容器就用官方镜像（两行是同一条命令，整段复制）：

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

这条是「Ollama 装在本机」那一版（上游 README 原话），浏览器开 http://localhost:3000；本机没装 Ollama 就改用 OpenAI API 那版，加 -e OPENAI_API_KEY=your_secret_key。不想碰命令行的，图形界面装法见上游 README；要拿源码就 git clone https://github.com/open-webui/open-webui。

最后提一个容易被带偏的预期。RAG 不会让模型变得更聪明，它只是让模型看到对的材料。

所以效果不好的时候，先别急着换模型，先检查三件事：切块策略对不对、检索召回的是不是相关内容、生成阶段有没有被塞进太多无关片段。

这三步的排查顺序，比反复换嵌入模型有效得多。

来源：本段为方法建议，依据 GitHub Search API 2026-10-22 快照的项目构成；未对各方案做效果横评。

作者：六六爸比。

总结：先想清楚哪一段缺人，再补哪一块。界面是方向盘，引擎是发动机，别拿方向盘当发动机使。下期见。