能列举下做benchmark的是哪200个pr吗

[voidmanun]

能列举下做benchmark的是哪200个pr吗，我们内部也要做接专属模型评测，看看效果

[lizhengfeng101]

AACR-Bench

[lizhengfeng101]

AACR-Bench 数据集的数据是公开的，你可以网络上检索一下。这个数据集来自人工评论+多个工具使用不同模型生成的答案汇总清洗得出的，因此被测工具自然会召回率偏低。

[voidmanun]

人工评论+多个工具使用不同模型生成的答案汇总清洗得出和偏低我感觉没有什么因果关系啊，我想问的是召回率低是工具的问题还是评测集的问题

[lizhengfeng101]

补充一下因果关系，之前可能没说清楚：

AACR-Bench 的标准答案（ground truth）是把人工评论和多个工具 × 不同模型各自发现的问题取并集再清洗得到的，本质上是一个刻意做全的「超集」。

召回率 = 单个工具命中数 / 标准答案总数。分母是「所有工具 + 人工」的并集，而任何单一工具只能覆盖其中一个子集——它天然发现不了别的模型、别的工具、以及人工才能发现的那部分问
题。并集越全，分母越大，单个工具的召回率自然就越低。这是评测设计决定的必然结果，不是某个工具坏了。所以你会看到所有工具召回率都偏低，而不是个别工具。

回到你的问题「是工具的问题还是评测集的问题」：

• 不是评测集有问题。它是故意构造成一个全面超集，衡量的是「相对于人机协同能发现的全部问题，单个工具能覆盖多少」——即覆盖度，而非正确性。
• 也不能简单归为某个工具的问题。低召回率真实反映的是：目前没有任何单一工具能独立覆盖整个问题空间，这是当前所有工具的共性局限。

换句话说，如果换一种构造方式（比如只用人工评论做 ground truth），召回率数字会明显变化，但就无法体现工具之间的覆盖差异了。这个指标本来就是为了做横向对比而设计的。

[voidmanun]

我最近也在找合适的benchmark，但是这份数据被领导批了，原因就是召回率太低
我用本地LLM分析了这些数据集的评论，他给的评论是
总体判断
生产级问题：361 / 1505，约 24.0%
边界/证据不足：424 / 1505，约 28.2%
非生产级建议：720 / 1505，约 47.8%

下面是一些LLM反馈的摘要信息：

B1 安全加固，但缺少攻击链

来源	评论大意	为什么不适合做召回
sample 18, comment 3，[PowerShell PR 25780](https://github.com/PowerShell/PowerShell/pull/25780)，`RunspaceConnectionInfo.cs:2238`	执行外部进程前，建议校验 filePath 不要被软链接/ junction 指到异常位置。	是安全加固提醒，但没说明攻击者能否控制这个路径，也没给出可利用链路。
sample 37, comment 1，[OpenCV PR 26815](https://github.com/opencv/opencv/pull/26815)，`HoughLines_Demo.cpp:75`	从 sprintf 改成 snprintf 后，建议确认旧 MSVC 兼容性、头文件、甚至改用更安全的 C++ 字符串。	更像后续 hardening/checklist，不是当前 PR 明确引入的漏洞。
sample 63, comment 1，[spring-ai-alibaba PR 869](https://github.com/alibaba/spring-ai-alibaba/pull/869)，`AliTranslateProperties.java:34`	环境变量 ACCESS_KEY_ID/SECRET 应加业务前缀，避免命名冲突。	有配置风险，但没有证明会读错密钥、泄露密钥或造成实际越权。

B2 性能/扩展性建议

来源	评论大意	为什么不适合做召回
sample 0, comment 0，[FreeCAD PR 19411](https://github.com/FreeCAD/FreeCAD/pull/19411)，`DrawProjGroup.cpp:1123`	循环里重复调用 getDirsFromFront(t)，建议缓存。	没有性能数据，也不知道这个循环是否是热点路径。
sample 3, comment 0，[FreeCAD PR 20612](https://github.com/FreeCAD/FreeCAD/pull/20612)，`DrawViewPart.cpp:1502`	std::string 参数建议改成 const std::string&，减少拷贝。	这是常见微优化，很多场景收益很小，不应算缺陷漏报。
sample 7, comment 4，[FreeCAD PR 20825](https://github.com/FreeCAD/FreeCAD/pull/20825)，`ModelLibrary.cpp:75`	tuple 里的 QString 建议用 const auto&，避免复制。	可能更高效，但没证明现有复制造成卡顿、内存问题或用户可见退化。

B3 边界/假设型风险

来源	评论大意	为什么不适合做召回
sample 0, comment 7，[FreeCAD PR 19411](https://github.com/FreeCAD/FreeCAD/pull/19411)，`DrawViewPart.cpp:1385`	注释掉 error handling 分支后，未知 projection 类型可能没有 fallback。	需要确认未知类型是否真的可能进入；评论本身也说“确认是否有意”。
sample 2, comment 2，[FreeCAD PR 22744](https://github.com/FreeCAD/FreeCAD/pull/22744)，`Parameter.cpp:1913`	把 std::endl 改成 \n 可能导致错误日志没及时 flush。	这是可能性判断，没有证明这里必须立即刷新。
sample 7, comment 5，[FreeCAD PR 20825](https://github.com/FreeCAD/FreeCAD/pull/20825)，`ModelLibrary.cpp:75`	models shared pointer 可能为空，建议判空。	要先证明这个路径会拿到空指针；否则只是防御式编程建议。

B4 弱证据代码缺陷

来源	评论大意	为什么不适合做召回
sample 1, comment 9，[FreeCAD PR 21257](https://github.com/FreeCAD/FreeCAD/pull/21257)，`PartFeature.cpp:1328`	数组里重复了 TopAbs_SHELL，导致 TopAbs_EDGE 没检查。	看起来像 bug，但还需要确认这个数组是否真的要求完整枚举覆盖。
sample 3, comment 2，[FreeCAD PR 20612](https://github.com/FreeCAD/FreeCAD/pull/20612)，`DrawViewPart.h:242`	新增函数不应是 static，应作为实例方法。	这是设计判断，缺少“当前 static 会导致什么错误行为”的证据。
sample 7, comment 6，[FreeCAD PR 20825](https://github.com/FreeCAD/FreeCAD/pull/20825)，`ModelLibrary.cpp:83`	path.split("/") 可能产生空段，建议跳过空段。	要看输入是否允许连续斜杠、首尾斜杠，以及空段是否真的破坏结果。

S1 可读性/风格/重构建议

来源	评论大意	为什么不适合做召回
sample 0, comment 1，[FreeCAD PR 19411](https://github.com/FreeCAD/FreeCAD/pull/19411)，`DrawProjGroup.cpp:1127`	删除注释掉的代码块。	代码整洁建议，不影响运行行为。
sample 0, comment 4，[FreeCAD PR 19411](https://github.com/FreeCAD/FreeCAD/pull/19411)，`DrawProjGroup.h:133`	enum 建议按值传递，变量命名也要一致。	风格和可读性问题，不是生产缺陷。
sample 0, comment 9，[FreeCAD PR 19411](https://github.com/FreeCAD/FreeCAD/pull/19411)，`CommandCreateDims.cpp:2383`	变量名 Geometrys 拼写应改成 Geometries。	拼写问题可以修，但不应算模型漏报。

S2 测试/CI/文档覆盖建议

来源	评论大意	为什么不适合做召回
sample 13, comment 1，[typescript-go PR 1446](https://github.com/microsoft/typescript-go/pull/1446)，`convertFourslash.mts:26`	测试名处理逻辑不一致，可能影响 manual test 过滤。	影响的是测试转换脚本，不是产品运行时缺陷。
sample 13, comment 3，[typescript-go PR 1446](https://github.com/microsoft/typescript-go/pull/1446)，`convertFourslash.mts:70`	manualTests.txt 和脚本里的测试名格式可能不一致。	属于测试基础设施质量问题，适合单独统计。
sample 13, comment 9，[typescript-go PR 1446](https://github.com/microsoft/typescript-go/pull/1446)，`makeManual.mts:18`	脚本移动文件前应确认目标是 _test.go。	是测试脚本防误操作建议，不能和生产缺陷召回混算。

核心判断标准：评论如果只能说“更安全、更快、更清晰、可能出问题”，但说不清“什么输入/状态会导致什么错误结果”，就不适合作为 must-recall 指标。

[lizhengfeng101]

建议你可以重新找合适的评测集，或者参与到 AACR-Bench 的建设上，提供一个基于原始数据的、更加贴合你们关注的数据子集