issue-rag - 面向真实开源仓库 issue tracker 的可审计检索增强问答系统

issue-rag 是一个面向真实开源仓库 issue tracker 的检索增强问答（RAG）系统，由维护者 zaxiu88888 开发。据项目自述，它的重点不只是「能问答」，而是把评测做扎实，并且审计自己的评分器：问题取自真实 issue 标题，参考答案取自关闭该 issue 的维护者回复，再对检索配置与判分器本身做多轮对照。它适合想研究 RAG 评测方法、或想在自己仓库的 issue 语料上搭一套可复现问答流水线的开发者。

维护者与状态

仓库由 zaxiu88888 维护，创建于 2026-11-01，最后提交时间为 2026-11-04。截至 2026-11-10，项目获得 202 个星标。事实表显示该项目尚无正式 release，因此目前只能从仓库源码使用，没有可引用的版本号。

主要能力

以下能力均据项目 README 自述，未经本站独立验证：

• 语料采集与切分：通过 GitHub REST API 抓取 issue 标题与正文、以及 issue 评论中的维护者回答，将 issue 正文块与评论块分别切分，并各自加上所属 issue 标题作为前缀。
• 评测集挖掘：以 issue 标题作为问题、以维护者采纳的回复作为参考答案，生成候选后由人工逐条保留或剔除，最终评测集随仓库提交。
• 多种检索配置：README 列出 BM25、稠密向量检索、RRF 混合检索以及带 cross-encoder 重排的混合检索四种配置，并支持本地 Qwen2.5 或任意 OpenAI 兼容端点生成答案。
• 带 rubric 的判分与接地审计：判分器按 rubric 对照参考答案打分，并单独做一次接地（grounding）审计；README 称判分器本身也经过换模型、同模型重复运行、换 rubric 版本与人工盲评四个轴的审计。
• 结果可复现：评测输出为 results.md 与 results.json，README 称数字由脚本生成、非手工编辑，HTTP 响应与向量嵌入均缓存到磁盘，重跑任一阶段不额外消耗。

README 还给出了在 vitejs/vite 上的评测结果表，包括闭卷与检索两种设置下的判定比例与加权准确率，以及各检索配置的对比。这些数字来自项目自述的评测流程，本站未复现，引用时请以仓库内数据文件为准。

使用入口

项目仓库地址：issue-rag。

据 README 的 Quickstart，典型流程为：先创建虚拟环境并安装依赖，再依次执行抓取 issue、抓取评论、构建检索语料、挖掘并人工复核评测集、下载模型或配置 API，最后运行评测矩阵。README 给出的命令形式如下（多行命令以代码块呈现）：

python -m venv .venv && source .venv/bin/activate
pip install -e ".[models,dev]"
python -m issue_rag.fetch issues --preset vite --months 12 --allow-wait
python -m issue_rag.fetch comments --preset vite --mode per-issue --max-comment-issues 120
python -m issue_rag.corpus --preset vite
python -m issue_rag.evalset --preset vite
python -m issue_rag.evaluate --preset vite --systems closed_book,bm25,dense,hybrid,hybrid_rerank

README 说明 --provider 支持 local、deepseek、openai、siliconflow、ollama，其他 OpenAI 兼容服务可通过 --endpoint 指定；凭据从 .env 读取。抓取阶段可匿名运行，设置 GITHUB_TOKEN 后配额从每小时 60 次提升到 5000 次。

许可与限制

项目采用 MIT 许可证。

README 中明确写出的边界与前置条件包括：

• 检索只支持英文：语料、BM25 分词与 embedding 模型均为英文，用中文提问会检索到噪声并得到拒答，README 将这一点列为评测集的设计漏洞并写入 Limitations。
• 目标仓库需要先筛选：README 建议在把流水线指向自己的仓库前先读数据质量文档，因为机器人账号占比过高或 PR 评论混入 issue 评论的仓库会显著降低可用样本量。
• 抓取受 GitHub 配额约束：匿名状态下每小时仅 60 次请求，评论需按 issue 逐个抓取，仓库级评论列表虽更省配额但会混入 PR 评论。
• 检索配置之间难以区分：README 自述四种检索配置的差距落在判分器自身噪声附近，更换判分器后排序会翻转，因此只主张「闭卷最差」与增益区间，不主张某一配置最优。
• 检索会抬高编造率：README 报告检索设置下被判为编造的比例高于闭卷设置，这是项目自述的反直觉结果之一。

由于项目尚无正式 release，接口与目录结构可能随提交变动，使用前建议以仓库当前代码与文档为准。