RAG Arena：开源 RAG 评估擂台，让你的检索系统"打擂台"

一、当 AI 回答质量参差不齐时，我们如何判断谁更好？

想象这样一个场景：你的团队搭建了一套基于 RAG（检索增强生成）的智能问答系统，用户问"特斯拉全自动驾驶 FSD 进展如何"，系统返回的答案有时精准、有时答非所问。你换了向量检索策略、加了重排序模块、接入了知识图谱——但这些改动真的让答案质量提升了吗？

在没有参照系的情况下，这个问题很难回答。你只能凭感觉说"好像更好了"，却拿不出数据。

RAG Arena 正是为解决这个痛点而生。它是一个开源的 RAG 评估平台，通过让真实用户对不同检索策略生成的答案进行"盲投投票"，用 Elo 评分机制量化各检索器的真实表现。换句话说，它把 RAG 检索系统放上了"打擂台"，用真实用户的反馈决定谁才是真正的强者。

图1：RAG Arena 的主界面，用户在匿名投票区对不同检索策略的回答进行比较。

这个项目来自 mendable.ai，由 Caleb Peffer 等开发者维护，目前在 GitHub 拥有 220 颗星、34 个 Fork，采用 MIT 许可证开源。

---

二、为什么需要"投票评估"？现有的 RAG 评估方法有什么局限？

目前主流的 RAG 评估方法主要有两类：基于指标的自动评估（RAGAS、Trulens 等）和人工主观评估。前者依赖 GPT-4 等大模型打分，速度快但存在"评分者本身就是 LLM"的循环依赖问题；后者真实可靠但成本高、难以规模化。

RAG Arena 另辟蹊径：让人类用户在真实问答场景中直接对比两个答案的质量。这种"盲投"机制有几个关键优势：

• 消除权威偏见：用户不知道哪个答案来自哪种检索策略，不会因为"听起来更专业"就偏向某一方。
• 真实使用场景：用户不是为了评估而评估，是真正带着问题来的，答案质量判断更接近实际应用。
• Elo 动态评分：像国际象棋评级一样，每个检索策略的分数会随着与对手的"对战"结果动态调整，能反映综合实力而非单次胜负。

项目在 Supabase 数据库中维护了一个 Leaderboard 表，记录每个检索器的 Elo 分数、总票数、测试次数和完整名称。这个排行榜是实时的，任何人都可以部署自己的 Arena 实例，导入自定义文档集，然后得到一份专属的检索策略排行榜。

---

三、项目架构：前端 Next.js + 后端 Python 微服务

RAG Arena 的技术栈非常有意思：它是一个典型的前后端分离异构架构，前端用 TypeScript/Next.js，后端用 Python/Flask（以及 LlamaIndex），两者通过 RESTful API 通信。

图2：RAG Arena 技术架构概览。

前端：Next.js 14 + TypeScript + LangChain-TS

前端项目位于仓库根目录，基于 Next.js 14 构建，核心依赖包括：

• @langchain/core 和 @langchain/community：TypeScript 端的 LangChain 实现，处理与 LLM 和向量存储的交互。
• @clerk/nextjs：身份认证，支持用户登录和会话管理。
• @supabase/ssr 和 @supabase/supabase-js：通过 Supabase SSR 客户端连接数据库。
• @upstash/ratelimit：Upstash Redis 限流，保护 API 不被滥用。
• Tailwind CSS + Radix UI：现代组件化 UI 开发。
• Framer Motion：动画效果，提升交互体验。
• Zustand：轻量级状态管理。

前端的主要功能模块包括：

• 投票系统（lib/actions/voting-system.ts）：核心逻辑，处理用户投票、更新 Elo 分数。评分公式考虑了"测试次数不均衡"的因素——测试次数越少的检索器，赢了之后获得的分数调整幅度越大。
• 动态检索器路由（app/api/retrievers/dynamic-retriever/route.ts）：根据用户查询路由到不同检索策略，同时实现了限流保护。
• 内容摄入系统（app/api/ingest/route.ts）：使用 LangChain 的 RecursiveCharacterTextSplitter 切分文档，配合 OpenAI Embeddings 生成向量，存入 SupabaseVectorStore。

后端：Python Flask + LlamaIndex

后端项目位于 python_service/ 目录，是一个用 Poetry 管理的 Python 微服务，基于 Flask 框架。它提供了一系列高级检索 API，这些 API 无法在前端 TypeScript 直接实现，必须借助 Python 生态的 LlamaIndex。

后端核心依赖：

• llama-index：核心索引和检索框架，支持多种高级检索策略。
• llama-index-graph-stores-neo4j：Neo4j 知识图谱存储。
• llama-index-retrievers-bm25：BM25 关键词检索。
• flask + flask-cors：HTTP 服务。
• gunicorn / waitress：生产级 WSGI 服务器。

后端支持 10 种检索策略，覆盖了从简单到高级的各种场景：

检索策略	后端实现	说明
Vector Store	vector_retriever	标准向量相似度检索
BM25	bm25_retriever	传统关键词排名检索
Reciprocal Rerank Fusion	reciprocal_rerank_fusion	多检索器结果交叉重排
Auto Merging Retriever	auto_merging_retriever	叶节点递归合并为父节点
Graph RAG	neo4j_retriever	知识图谱增强的 RAG

数据库：Supabase（PostgreSQL + pgvector）

Supabase 承担了两大职责：一是作为向量数据库（通过 pgvector 扩展），存储文档嵌入向量并支持相似度检索；二是作为关系数据库，存储用户投票数据、Elo 评分等业务数据。Leaderboard 表结构如下：

字段	类型	说明
id	主键	唯一标识
retriever	字符串	检索器名称
elo	整数	当前 Elo 分数
votes	整数	获得的总票数
times_tested	整数	被测试次数
full_name	字符串	检索器全名
description	字符串	检索器描述
link	字符串	LangChain/LlamaIndex 文档链接

---

四、核心功能体验：从部署到第一次投票

部署流程

部署 RAG Arena 需要配置两组服务：

1. 前端 Next.js 应用

git clone https://github.com/firecrawl/rag-arena
cd rag-arena
pnpm install
pnpm dev

环境变量需要配置：

• OPENAI_API_KEY：LLM 和 Embedding 调用密钥。
• NEXT_PUBLIC_SUPABASE_URL + NEXT_PUBLIC_SUPABASE_PRIVATE_KEY：Supabase 项目凭证。
• UPSTASH_REDIS_REST_URL + UPSTASH_REDIS_REST_TOKEN：API 限流。
• PYTHON_MICRO_SERVER：Python 后端服务地址（本地开发默认为 http://localhost:5000）。

2. 后端 Python 微服务

cd python_service
poetry install
poetry run flask run --debug

如果需要开启 Graph RAG 能力（Neo4j 知识图谱），还需要：

• 配置 NEO4J_URI 和 NEO4J_PASSWORD 环境变量。
• 运行 create_neo4j_graph_store() 构建图谱索引（首次运行会自动构建，但需要较长时间）。

后端提供了完整的 Docker 支持，通过 python_service/Dockerfile 可以容器化部署：

FROM python:3.10.11
WORKDIR /app
COPY pyproject.toml poetry.lock* /app/
RUN pip install poetry waitress && poetry config virtualenvs.create false && poetry install --no-interaction --no-ansi
COPY . /app
CMD ["python", "waitress_server.py"]

配合 docker-compose.yml，一行命令即可启动完整服务栈（需要配置好环境变量）。

图3：RAG Arena Logo。

核心使用流程

1. 摄入文档：通过前端的内容摄入接口，将你的业务文档（如公司知识库、产品文档）切分并向量化存入 Supabase。
2. 发起提问：用户输入自然语言问题，系统会同时调用多个检索策略生成答案，并以匿名方式展示给用户。
3. 投票打分：用户选择更优的答案。投票提交后，系统揭晓两个答案对应的检索策略。
4. Elo 更新：后端根据投票结果更新排行榜分数。测试次数少的检索器在赢了高频对手时会获得更大的分数加成。
5. 查看排行：Leaderboard 页面实时展示各检索策略的排名变化。

---

五、为什么这个项目值得关注？

代表了 RAG 评估的新方向

RAG 系统的评估一直是工程难题。传统的基于指标的评估容易陷入"用 LLM 评估 LLM"的循环，而 RAG Arena 用人类反馈作为 ground truth，这是一个更接近真实需求的方法论创新。

异构架构的工程参考价值

前端 TypeScript、后端 Python 通过 REST API 协作，这种架构在 AI 应用中非常常见。LangChain-TS 处理前端侧的向量操作，LlamaIndex 处理后端侧的高级检索，两者职责边界清晰。对于需要类似架构的开发者，RAG Arena 是一个很好的参考模板。

支持 10+ 种检索策略的实战对比

项目内置了从基础向量检索到知识图谱 RAG 的完整策略覆盖，开发者无需自行实现就能对比各策略在相同数据集上的表现。配合自定义文档集，可以得出非常具体的策略选型结论。

---

六、局限与挑战

RAG Arena 也不是银弹，使用时需要注意以下几点：

1. 依赖外部 LLM API：整个系统的答案生成依赖 OpenAI API，调用成本不可忽视。如果你的数据涉及隐私合规问题，将数据发送给 OpenAI 可能存在风险。

2. Elo 评分的稳定性问题：在用户量较小时，Elo 分数可能存在较大波动。例如一个检索器只被测试了 2 次且都赢了，Elo 分数会虚高。

3. Python 后端非必需：前端 LangChain-TS 本身已经支持部分检索策略（Vector Store、Contextual Compression、Multi-Query、Parent Document 等），Python 后端提供的 BM25、Graph RAG 等是增强能力。部署时需要权衡是否需要完整的检索策略覆盖。

4. Graph RAG 的 Neo4j 依赖：Graph RAG 功能需要 Neo4j 数据库，增加了运维复杂度。

图4：RAG Arena 项目标识。

---

七、总结

RAG Arena 是一个兼具工程实用性和方法论创新的开源项目。它用"擂台赛"的思路解决了 RAG 评估中最难的问题——如何量化检索质量。通过 220 颗星和活跃的社区，它证明了这一方向确实击中了开发者的痛点。

对于 AI 爱好者而言，它是理解不同 RAG 检索策略差异的绝佳学习工具；对于 AI 开发者而言，它是评估和选型检索方案的数据驱动平台。如果你正在搭建 RAG 系统，不妨先用 RAG Arena 对比一下不同检索策略的实际效果——数据比直觉更可靠。