我在黑客松评审工具里找到两个 Bug，但都不能解释我为什么落选
来源：dev.to — 2026-09-14
📋 概述
作者为 Africa Deep Tech Challenge 2026 做了 StacksNG：一个离线编码助手，用四个尼日利亚金融科技 API（Paystack、Flutterwave、Monnify、Termii）的文档做检索增强，780 个文档分片全部在设备上经 llama.cpp 运行，不联网、无密钥、不编造接口。他没进半决赛，也没有任何反馈，于是自己去查。他发现自己的 submission.json 里 accuracy 字段是一个空数组——占评分公式 50% 的分数被静默地记成零。想补齐这项指标时又撞上两个 Bug：评审工具把 base_url 写成 local 而不是合法 URL；lm-eval-harness 的 GGUF 后端仍期待旧的 echo 行为，而现行 llama-server 只对新生成的 token 返回 logprobs。
🔑 核心要点
- StacksNG 用 780 个文档分片做检索增强，全部在本地经 llama.cpp 运行，不依赖云、不填 API Key，也不编造支付接口。
- 作者主动在报告里写了消融实验：换成更小的 1.5B 模型能在评分公式上多得约 35 分，但那个模型会凭空写出不存在的 flutterwave 库。
- 他克隆了全部 20 个入围作品并以 git 历史存档，发现每一个都对基座模型做过 LoRA、蒸馏或合并，只有 StacksNG 用原版模型。
- 真正的失分点是 submission.json 里 accuracy 为空数组，不是低分而是没有数字——生成它的分析器要么跳过了准确率关卡，要么当时没装 lm_eval。
- 他确认了评审工具两个真实缺陷：base_url=local 不是合法 URL，以及 lm-eval 的 GGUF 后端依赖已被 llama-server 取消的 echo 行为。
- 绕开缺陷后他跑出 arc_easy acc_norm = 0.74 的真实成绩，说明问题不在模型而在评分链路的静默失败。
💡 金句
我选择了正确性而不是评分公式，并且在报告里写明了理由——结果证明我防守错了地方。
👍 0
👎 0
← 返回 dev.to 首页