arag
Ayanami0730/arag加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象这样一个场景：你向一个知识库问答系统提问：「特斯拉CEO马斯克收购的那家公司，后来又卖给了谁？」这类多跳问题需要先找到马斯克收购的公司，再追踪它的去向。传统RAG系统就像一个只会翻书的图书管理员——你告诉他要找什么，他就机械地翻到对应页码。但面对需要多步推理的问题，这种「一次性检索」的模式往往力不从心。
A-RAG（Agentic RAG）正是为解决这个痛点而生。这个2026年2月刚刚发布在arXiv上的研究框架，由来自中国的研究团队开发，首次将Agent能力引入RAG检索流程，让大模型真正成为信息检索的「指挥官」——它可以自主决定用什么策略检索、检索几次、什么时候停止检索。
图1：三种RAG范式对比。传统Graph RAG和Workflow RAG都无法让模型真正参与检索决策，只有A-RAG实现了完全的Agent化自主控制。
要理解A-RAG的创新，先得看清现有RAG系统的局限。作者在论文中指出了两个主流范式的根本问题：
Graph RAG（图谱RAG）：预先设计好检索算法，一次性地把所有相关段落拉取出来拼接到模型输入中。这种方式的弊端在于，检索策略是「写死」的，模型只能被动接受，无法根据中间结果动态调整策略。比如在多跳问题中，第一跳检索到的信息可能不足以回答问题，但Graph RAG并不会意识到这一点。
Workflow RAG（工作流RAG）：通过提示词让模型按照预定义的步骤执行——「先搜索关键词，再搜索相关概念，最后读取段落」。看起来有步骤，但本质上是把固定流程硬编码，模型只是在执行命令，而非真正「思考」检索策略。
两种范式都有一个共同缺陷：模型没有参与检索决策。当模型能力越来越强（GPT-5、Claude 3之后），这种「检索端和模型端割裂」的架构就成了瓶颈——模型的推理能力被白白浪费了。
A-RAG的思路极为优雅：不替模型决定怎么检索，而是把检索工具直接暴露给模型，让它自己决策。
项目提供了三个粒度由粗到细的检索工具：
| 检索工具 | 粒度 | 原理 | 适用场景 |
|---|---|---|---|
| keyword_search | 关键词级 | 精确词汇匹配（大小写不敏感），计算关键词在每个段落出现的次数加权 | 专有名词、人名、技术术语 |
| semantic_search | 句子级 | 稠密向量检索，用Qwen3-Embedding-0.6B对句子做嵌入，cosine相似度排序 | 概念查询、语义相关但措辞不同的情况 |
| chunk_read | 段落级 | 直接读取指定段落内容，并自动读取相邻段落补充上下文 | 已知段落ID，需要深入阅读的场景 |
模型可以在ReAct循环中自由调用这些工具：执行一个检索动作→获得观察结果→推理→决定下一步。当模型认为已有足够信息时，直接输出最终答案。整个过程无需人工预设工作流。
图2：A-RAG框架总览。Agent在ReAct循环中迭代调用keyword_search、semantic_search、chunk_read三种检索工具，自主决定何时停止并输出答案。
A-RAG的实验结果相当亮眼。在GPT-5-mini作为骨干模型的情况下，A-RAG（Full）在MuSiQue多跳问答数据集上达到74.1%的准确率，比GraphRAG高出近26个百分点，比HippoRAG2高出12个百分点。更难得的是，A-RAG不仅准确率更高，消耗的检索token也更少——这意味着它更「聪明」，而不是简单地「多检索」。
核心发现是测试时扩展（Test-Time Scaling）：当给模型更多推理步数（max_loops）和上下文容量（max_token_budget）时，A-RAG的性能持续提升。这与模型能力增长是正相关的——模型越强，A-RAG用它越有效。这正是「让模型参与决策」这一设计理念带来的红利。
项目代码结构简洁实用，以src/arag/为核心包，划分为三个子模块：
core/ —— 基础设施层
config.py：通过YAML配置文件管理LLM、Embedding、Agent参数，支持temperature、max_tokens、reasoning_effort等细粒度控制context.py：管理Agent执行状态和上下文追踪，记录已访问段落防止重复读取llm.py：统一的LLM客户端封装，内置token计费和成本追踪agent/ —— 决策执行层
base.py：实现BaseAgent，运行ReAct主循环（action→observation→reasoning），支持max_loops和max_token_budget控制prompts/：系统提示词模板，控制Agent的检索策略选择行为tools/ —— 检索工具层
keyword_search.py：轻量级关键词搜索，无需预索引，实时计算匹配分数semantic_search.py：基于sentence-transformers的稠密向量检索，需要预先用build_index.py构建Faiss索引read_chunk.py：段落读取工具，带上下文追踪器，记录已读chunk ID避免重复消费token依赖管理采用现代Python项目规范，核心依赖仅5个（requests、tiktoken、pyyaml、tqdm、numpy），可选依赖full组额外引入sentence-transformers和pandas/pyarrow用于向量检索。
A-RAG目前定位为研究工具和CLI框架，没有Web界面。使用流程为：准备语料（JSON格式）→ 构建Embedding索引 → 编写YAML配置 → 通过batch_runner.py批量运行问题 → eval.py评估结果。
需要注意的是，semantic_search依赖Qwen3-Embedding-0.6B模型做向量编码，需要NVIDIA GPU和CUDA 11.8+环境，显存需求约6GB以上。keyword_search则是纯CPU友好的轻量工具，无需GPU。
Python API层面，项目提供了简洁的链式调用接口：初始化LLMClient→注册ToolRegistry→创建BaseAgent→调用.run()方法即可，支持流式输出和成本追踪。对于想将A-RAG集成到自有系统的开发者来说，上手门槛并不高。
论文坦诚列出了当前不足：仅支持OpenAI兼容API（不支持Claude、Gemini）；测试基准脚本尚未公开（仅提供了A-RAG本身）；可视化分析工具还在路线图上。更重要的是，作为一个2026年2月才发布的新项目，生产环境的使用案例和稳定性验证还相当有限。
不过，核心创新已经足够扎实。将Agent能力引入RAG检索决策，解决了Graph RAG和Workflow RAG的核心痛点，Test-Time Scaling特性让框架可以充分利用未来更强的大模型能力。这条「模型自主控制检索」的技术路线，值得持续关注。
项目信息