R2R-Application
R2R 框架的官方可视化管控台,一站式管理文档、测试 RAG 效果、监控管道性能
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
R2R 框架的官方可视化管控台,一站式管理文档、测试 RAG 效果、监控管道性能
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下:你的 RAG 应用已经跑起来了,但你只能靠 curl 命令和日志文件来管理文档上传、查看检索效果、调试查询结果。这种场景对于 AI 开发者而言并不陌生——后端 API 足够强大,但前端交互界面几乎是空白。R2R Dashboard 正是为了解决这个痛点而生:它为 R2R 框架提供了一套完整的 Web 可视化管控台,让 RAG 管道的运维从"命令行炼狱"升级为"仪表盘自由"。
R2R(Retrorieve and Render)是 SciPhi-AI 团队开源的生产级 AI 检索系统,主打多模态内容摄入、混合搜索和知识图谱构建能力。而 R2R Dashboard 则是这个强大后端框架的官方可视化前端,用 React + Next.js 构建,定位是让开发者能够直观地管理文档、测试 RAG 效果、监控管道运行状态。
RAG(检索增强生成)系统的开发链路相当复杂:文档摄入 → 分块处理 → 向量化存储 → 语义检索 → LLM 生成。在这条链路中,每一个环节都有大量参数需要调试——分块策略、嵌入模型、检索权重、重排序参数、LLM 选择……
传统的开发模式下,这些参数调整和结果查看都依赖 API 调用和日志分析。这种方式的问题在于:无法直观看到检索结果与原始文档的对应关系,也难以系统性地比较不同配置下的效果差异。对于需要持续优化 RAG 管道的研究团队和工程团队而言,这是一个显著的效率瓶颈。
R2R Dashboard 正是为了弥合这一差距而设计的。它不是简单的 API 封装,而是一套针对 RAG 工作流深度定制的前端系统,涵盖了从文档管理到效果评估的完整流程。
R2R Dashboard 的文档管理模块支持上传、更新和删除文档及其元数据。用户可以通过拖拽方式批量上传文件,系统自动完成分块和向量化处理。
图1:文档管理界面,支持批量上传和元数据编辑
该模块与 R2R 后端深度集成,能够实时显示文档处理状态(待处理/处理中/已完成),并提供文档级别的元数据查看和编辑功能。
Playground 是整个 Dashboard 最核心的模块之一。开发者可以在此选择不同的 LLM 模型、调整 RAG 参数配置,然后以对话形式实时测试检索和生成效果。系统支持流式输出(Streaming),让用户能够即时看到 LLM 的推理过程。
这个功能的价值在于:开发者在正式部署之前,可以在一个隔离环境中反复调试检索策略和提示词工程,而不需要反复调用 API 或编写测试脚本。
Dashboard 内置了完整的统计分析模块,基于 Chart.js 和 Visx(高性能数据可视化库)实现latency 分布直方图、检索命中率、查询量趋势等核心指标的可视化展示。
这些指标对于生产环境的性能优化至关重要——通过 Analytics 面板,团队可以快速识别出查询延迟异常、检索质量下降等问题的早期信号。
日志模块提供了完整的查询审计能力,包括用户原始查询、检索返回结果、LLM 最终回答的全链路记录。开发者可以回放任意历史查询,查看每一步的中间结果,从而精确定位检索失败或生成质量问题的根本原因。
Dashboard 内置了开发服务器启动、代码格式化(Prettier)和 Lint 检查(ESLint)的快捷入口,配合 Husky + lint-staged 实现了提交前自动检查的 CI 友好工作流。
R2R Dashboard 采用典型的前后端分离架构:前端基于 Next.js 14(App Router),通过 r2r-js 客户端 SDK 与 R2R 后端 REST API 通信。这种设计确保了前端界面与后端检索引擎的解耦——用户可以在不修改 Dashboard 的情况下,自由切换底层 RAG 引擎的版本或部署方式。
值得注意的是,Dashboard 本身是无状态前端,所有业务数据(文档、向量、配置)都存储在后端 R2R 系统和可选的 Supabase 数据库中。
项目大量使用了 Radix UI 作为基础组件库(对话框、选择器、开关、滑块、下拉菜单等),这些组件基于 Radix Primitive 模式构建,在可访问性(ARIA 支持)和定制灵活性之间取得了很好的平衡。配合 Tailwind CSS 进行样式定制,以及 CVA(Class Variance Authority)管理组件变体,整个 UI 的开发效率和维护性都相当高。
Framer Motion 为整个 Dashboard 提供了流畅的微交互动画——对话框弹出、侧边栏滑入、消息气泡淡入等。动画不只是视觉装饰,更重要的是降低认知负荷:用户能够通过动画轨迹理解界面状态变化的方向和逻辑。
Dashboard 集成了 Sentry 的 Next.js 监控方案,覆盖客户端(sentry.client.config.ts)、边缘函数(sentry.edge.config.ts)和服务端(sentry.server.config.ts)三个层面,实现了 RAG 应用异常的端到端追踪。
项目集成了 PostHog 自托管分析,用户行为数据(包括 Playground 使用频率、文档上传热度等)完全由用户自己掌控,不依赖第三方数据分析平台。这对于重视数据隐私的企业用户来说尤为重要。
R2R Dashboard 提供了一套成熟的多阶段 Dockerfile,基于 node:22-alpine 镜像构建,最终产出为 Next.js standalone 输出(精简的 Node.js 服务而非完整 Next.js 运行时)。整个镜像体积控制在较小范围内。
部署流程极为简洁:
# 克隆并构建
git clone git@github.com:SciPhi-AI/R2R-Application.git
cd R2R-Application
pnpm install
pnpm build
pnpm start
# 访问 http://localhost:3000
Dashboard 依赖 R2R 后端服务运行(API 地址可配置),默认开发服务器监听端口 3005。配合反向代理(如 Nginx)和 R2R 后端,可在任意 Linux 环境中一键部署。
虽然项目没有提供官方的 docker-compose.yml,但由于 Dockerfile 采用了标准的 Next.js standalone 模式,用户完全可以自行编写 docker-compose.yml 将 Dashboard 和 R2R 后端打包为一键启动的服务。
| 维度 | 评分 | 说明 |
|---|---|---|
| 代码质量 | ★★★★☆ | TypeScript 全面覆盖,ESLint + Prettier 双重质量门禁 |
| 文档完整性 | ★★★★☆ | README 包含完整的安装、开发和功能说明 |
| 测试覆盖 | ★★★☆☆ | 项目配置了 GitHub Actions CI/CD,但源码中未发现明确的单元测试文件 |
| 架构设计 | ★★★★☆ | 模块化组件架构,组件职责清晰,可扩展性良好 |
| 部署体验 | ★★★★☆ | 多阶段 Dockerfile,standalone 构建,开箱即用 |
缺少官方 docker-compose:Dashboard 需要配合 R2R 后端才能正常工作,但项目没有提供官方的 docker-compose 配置。新用户需要自行研究两个服务如何联动,增加了初次部署的学习成本。
Supabase 集成复杂度:部分功能(如认证)依赖 Supabase,这对只是想快速体验 Dashboard 的用户而言引入了额外的配置步骤和环境依赖。
仅支持 R2R 后端:Dashboard 的客户端 SDK(r2r-js)是与 R2R 后端深度绑定的,无法直接用于其他 RAG 框架(如 LangChain RAG、LlamaIndex)。如果你已经在使用其他 RAG 框架,这个 Dashboard 无法直接复用。
随着 RAG 技术在企业级 AI 应用中的广泛落地,RAG 系统的可视化运维工具正在成为一个独立的赛道。R2R Dashboard 代表了一种趋势:不是用通用监控工具覆盖 RAG 场景,而是从 RAG 工作流本身出发,设计专门的交互界面。
从 GitHub 数据来看,该项目在 2024 年 2 月首次在 Hacker News 上发布,获得了 167 个 Points 和 57 条讨论,反映出社区对这类工具的强烈需求。项目由 SciPhi-AI 商业公司维护,配套有 SciPhi Cloud 商业服务和完整的文档体系(r2r-docs.sciphi.ai),具有较强的长期维护保障。
如果你正在使用 R2R 框架构建 RAG 应用,R2R Dashboard 是一个值得投入时间熟悉的生产力工具;如果你使用的是其他 RAG 框架,它也是一个优秀的前端架构参考,展示了如何将 RAG 工作流中的关键环节进行可视化呈现。