narayanaroyalgithub/terminal-bench-rag-incident-response

GitHub: narayanaroyalgithub/terminal-bench-rag-incident-response

该项目是 Terminal-Bench 3 中的一个评测任务,用于考察 AI agent 在医疗保健 RAG pipeline 中诊断并修复多原因检索质量回归问题的能力。

Stars: 0 | Forks: 0

# 医疗保健 RAG 事件响应 ## 概述 此 Terminal-Bench 3 任务要求 agent 修复医疗保健 RAG pipeline 中的生产环境检索质量回归问题。Agent 将接收一个可运行的本地环境,其中包含临床文档、metadata、日志、pipeline 代码、配置和事件查询。没有堆栈跟踪指向答案;必须找到并修复多个独立的检索回归问题。 预期的基准测试行为是: - Oracle 解决方案:通过,奖励为 `1`。 - Nop 解决方案:失败,奖励为 `0`。 - 标准前沿 agent 试验:应失败,因为该任务需要进行多原因的生产环境检索调查,而不是单一的代码更改。 - 对抗性 `/cheat` 试验:应获得奖励 `0`,因为 verifier 会在单独的 verifier 容器中检查声明的 artifacts,并从提交的输出中重新计算一致性。 ## 任务位置 该任务位于: ``` tasks/rag-incident-response ``` 重要文件: ``` tasks/rag-incident-response/ ├── instruction.md ├── task.toml ├── README.md ├── environment/ │ ├── Dockerfile │ ├── configs/ │ ├── documents/ │ ├── logs/ │ ├── metadata/ │ ├── pipeline/ │ ├── queries/ │ └── tools/ ├── solution/ │ ├── solve.sh │ └── repair_pipeline.py └── tests/ ├── Dockerfile ├── test.sh └── test_retrieval.py ``` ## Agent 交付物 Agent 必须准确生成以下文件: ``` /app/output/retrieval_results.json /app/output/evaluation.json /app/output/incident_report.md ``` `retrieval_results.json` 必须包含 `/app/queries/incident_queries.json` 中每个查询的最终排序检索输出。 `evaluation.json` 必须包含恢复后 pipeline 的质量指标和操作检查。 `incident_report.md` 必须总结根本原因、纠正措施和验证证据。 ## 隐藏的根本原因 这些特意未在 `instruction.md` 中列出,但它们定义了 oracle 解决方案和 verifier 预期: - Metadata schema 漂移:文档使用 `dept`,而损坏的 retriever 基于 `department` 进行过滤。 - Chunk 重叠回归:`chunk_overlap` 被减少为 `0`。 - Top-k 回归:`top_k` 被减少为 `2`。 - 重复索引:增量索引重复附加了心力衰竭协议。 - 查询规范化错误:normalizer 从查询中去除了首个首字母大写的 token。 ## Verifier 策略 Verifier 以单独模式运行,仅验证声明的 artifacts。它检查: - 必需的输出文件存在且非空。 - JSON 输出 schema 有效。 - 每个事件查询都存在。 - 必需的临床文档出现在前五名中。 - 排名第一的文档与主要查询意图匹配。 - 移除了重复的文档 ID。 - 返回的文档保留了临床 metadata。 - `evaluation.json` 指标与提交的检索结果一致。 - `incident_report.md` 列出了根本原因、纠正措施和验证证据。 ## 必需的静态检查 从 Terminal-Bench 3 仓库根目录运行这些命令: ``` ./ci_checks/check-canary.sh tasks/rag-incident-response ./ci_checks/check-dockerfile-references.sh tasks/rag-incident-response ./ci_checks/check-dockerfile-platform.sh tasks/rag-incident-response ./ci_checks/check-dockerfile-sanity.sh tasks/rag-incident-response ./ci_checks/check-task-absolute-path.sh tasks/rag-incident-response ./ci_checks/check-test-file-references.sh tasks/rag-incident-response ./ci_checks/check-test-sh-sanity.sh tasks/rag-incident-response ./ci_checks/check-task-fields.sh tasks/rag-incident-response ./ci_checks/check-task-timeout.sh tasks/rag-incident-response ./ci_checks/check-instruction-suffix.sh tasks/rag-incident-response ./ci_checks/check-gpu-types.sh tasks/rag-incident-response ./ci_checks/check-task-slug.sh tasks/rag-incident-response ./ci_checks/check-allow-internet.sh tasks/rag-incident-response ./ci_checks/check-separate-verifier.sh tasks/rag-incident-response ./ci_checks/check-trial-network-fetch.sh tasks/rag-incident-response ./ci_checks/check-pip-pinning.sh tasks/rag-incident-response ./ci_checks/check-nproc.sh tasks/rag-incident-response ``` ## Harbor 验证命令 首先安装并配置 Docker 和 Harbor: ``` docker ps harbor --version ``` 运行 oracle 和 nop 验证: ``` harbor run -p tasks/rag-incident-response --agent oracle --env docker --yes harbor run -p tasks/rag-incident-response --agent nop --env docker --yes ``` 预期结果: - Oracle:奖励 `1` - Nop:奖励 `0` ## 标准 Agent 试验命令 使用当前的 Terminal-Bench 3 CI 默认设置作为事实来源。在编写此任务时,`.github/harbor-run-defaults.yml` 指定了 `trials: 3` 以及以下默认 agent: - 使用 `anthropic/claude-opus-4-8` 的 `claude-code` - 使用 `openai/gpt-5.5` 的 `codex` - 使用 `gemini/gemini-3.1-pro-preview` 的 `terminus-2` 为每个必需的 agent 运行三次有效试验。示例命令: ``` harbor run -p tasks/rag-incident-response \ --agent codex \ --model openai/gpt-5.5 \ --env docker \ --yes \ --ae CODEX_FORCE_AUTH_JSON=1 \ --ak reasoning_effort=xhigh ``` ``` harbor run -p tasks/rag-incident-response \ --agent claude-code \ --model anthropic/claude-opus-4-8 \ --env docker \ --yes \ --ae CLAUDE_FORCE_OAUTH=1 \ --ae CLAUDE_CODE_OAUTH_TOKEN= \ --ak reasoning_effort=max ``` ``` harbor run -p tasks/rag-incident-response \ --agent terminus-2 \ --model gemini/gemini-3.1-pro-preview \ --env docker \ --yes \ --ak reasoning_effort=high ``` 基础设施故障、API 故障、模型速率限制、容器故障和设置错误不计为真正的模型故障。重新运行,直到每个必需的配置都有三次有效试验。 ## 对抗性试验命令 使用当前的 CI 默认设置运行对抗性 `/cheat` 试验。如果通过 GitHub PR 自动化运行,请触发: ``` /cheat ``` 如果在本地运行,请将 `.github/hack-trial-prompt.md` 中当前的仓库对抗性提示添加到任务指令之前,并运行相同的 agent/模型配置。每次对抗性试验都必须获得奖励 `0`。 ## 目前记录的结果 这些是我能够在当前创作环境中运行的结果。 | 检查 | 结果 | 备注 | | --- | --- | --- | | `check-canary.sh` | 通过 | 本地运行。 | | `check-dockerfile-references.sh` | 通过 | 本地运行。 | | `check-dockerfile-platform.sh` | 通过 | 本地运行。 | | `check-dockerfile-sanity.sh` | 通过 | 本地运行。 | | `check-task-absolute-path.sh` | 通过 | 本地运行。 | | `check-test-file-references.sh` | 通过 | 本地运行。 | | `check-test-sh-sanity.sh` | 通过 | 本地运行。 | | `check-task-fields.sh` | 通过 | 本地运行。 | | `check-task-timeout.sh` | 通过 | 本地运行。 | | `check-instruction-suffix.sh` | 通过 | 本地运行。 | | `check-gpu-types.sh` | 通过 | 本地运行。 | | `check-task-slug.sh` | 通过 | 本地运行。 | | `check-allow-internet.sh` | 通过 | 本地运行。 | | `check-separate-verifier.sh` | 通过 | 本地运行。 | | `check-trial-network-fetch.sh` | 通过 | 本地运行。 | | `check-pip-pinning.sh` | 通过 | 本地运行。 | | `check-nproc.sh` | 通过 | 本地运行。 | | Python 编译 | 通过 | Pipeline、oracle 和 verifier Python 文件均可编译。 | | 损坏的基线模拟 | 如预期般通过 | 初始损坏的 pipeline 产生 `recall_at_5 = 0.0`。 | | Oracle 修复模拟 | 通过 | 修复后的本地模拟产生了 `recall_at_5 = 1.0` 和 `precision_at_5 = 1.0`。 | | Verifier 逻辑模拟 | 通过 | `tests/test_retrieval.py` 接受了生成的 oracle artifacts。 | | Docker 构建 | 未在此运行 | 当前环境中未安装 `docker`。 | | Harbor oracle 验证 | 未在此运行 | 当前环境中未安装 `harbor`。 | | Harbor nop 验证 | 未在此运行 | 当前环境中未安装 `harbor`。 | | Codex 标准试验 | 未在此运行 | 需要您的 Codex 身份验证/订阅和 Harbor。 | | Claude Code 标准试验 | 未在此运行 | 需要您的 Claude Code OAuth token 和 Harbor。 | | Gemini 标准试验 | 未在此运行 | 根据作业要求是可选的,但存在于当前的 CI 默认设置中。 | | Codex 对抗性试验 | 未在此运行 | 需要 Harbor 和对抗性设置。 | | Claude Code 对抗性试验 | 未在此运行 | 需要 Harbor 和对抗性设置。 | ## 提交前需填写的最终结果 在运行官方的 Docker/Harbor 检查和模型试验后,替换 `TODO` 值。 | 检查 | 预期 | 实际 | 备注 | | --- | --- | --- | --- | | 静态检查 | 通过 | 通过 | 所有列出的静态检查均在本地通过。 | | Docker 构建 | 通过 | TODO | 使用 Docker/Harbor 运行。 | | Oracle 验证 | 奖励 `1` | TODO | 提交前必须通过。 | | Nop 验证 | 奖励 `0` | TODO | 提交前必须失败。 | | Codex 试验 1 | 奖励 `0` | TODO | 必须是真正的模型故障。 | | Codex 试验 2 | 奖励 `0` | TODO | 必须是真正的模型故障。 | | Codex 试验 3 | 奖励 `0` | TODO | 必须是真正的模型故障。 | | Claude Code 试验 1 | 奖励 `0` | TODO | 必须是真正的模型故障。 | | Claude Code 试验 2 | 奖励 `0` | TODO | 必须是真正的模型故障。 | | Claude Code 试验 3 | 奖励 `0` | TODO | 必须是真正的模型故障。 | | Gemini 试验 1 | 奖励 `0` | TODO | 除非当前的 CI 默认设置有要求,否则为可选项。 | | Gemini 试验 2 | 奖励 `0` | TODO | 除非当前的 CI 默认设置有要求,否则为可选项。 | | Gemini 试验 3 | 奖励 `0` | TODO | 除非当前的 CI 默认设置有要求,否则为可选项。 | | Codex cheat 试验 | 奖励 `0` | TODO | 任何非零奖励都意味着必须加强 verifier。 | | Claude Code cheat 试验 | 奖励 `0` | TODO | 任何非零奖励都意味着必须加强 verifier。 | | Gemini cheat 试验 | 奖励 `0` | TODO | 除非当前的 CI 默认设置有要求,否则为可选项。 | ## 故障分析模板 在标准 agent 试验后填写此模板: ``` Codex trial summary: - Trial 1: - Trial 2: - Trial 3: - Common failure mode: Claude Code trial summary: - Trial 1: - Trial 2: - Trial 3: - Common failure mode: Gemini trial summary: - Trial 1: - Trial 2: - Trial 3: - Common failure mode: Adversarial trial summary: - Codex cheat reward: - Claude Code cheat reward: - Gemini cheat reward: - Verifier hardening notes: ``` 预期的模型故障模式包括部分诊断、仅修复 metadata 漂移、报告指标但未完全恢复排序、遗漏重复索引,或者未能生成所有三个具有内部一致指标的必需 artifacts。 ## 提交说明 提交一个包含此任务及上述已完成结果的 GitHub 仓库。发送给 Klavis 的电子邮件应链接到 GitHub 仓库,而不是仅仅附加一个 zip 文件,除非他们明确要求附件。
标签:DLL 劫持, Homebrew安装, RAG, 人工智能, 医疗, 大语言模型, 故障排查, 用户模式Hook绕过, 自动化评估, 请求拦截, 逆向工具, 防御加固