报错是这么冒出来的。用 ragas 0.2 跑 500 条评测，把并发调到 16 后一半用例报 429，评测指标出现大量 NaN，串行跑同一批数据则全部成功。
中间走过弯路，把「429 被当成评测失败，指标直接算成 NaN」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。评测会为每条样本发起多次模型调用，请求量被放大。也可能是并发数超过账号 RPM 限制。
另外，重试没有退避，失败样本又被连续重放。
估算单样本会触发多少次调用
python -c "print(500*4, '总调用量，按 RPM 600 算至少 4 分钟')"再往下把并发降到 4 并加 1 秒间隔
python ragas_run.py --dataset eval.jsonl --concurrency 4 --sleep 1接着对 429 做指数退避重试
python -c "print('wait = min(2**n, 30) + random.uniform(0, 1)')"末了统计失败样本并单独补跑
python -c "import json;print(sum(1 for l in open('result.jsonl') if json.loads(l).get('score') is None))"别只看报错消失，验证要多做一步。500 条全部产出有效分数，NaN 数量为 0，总耗时比串行下降一半以上。
这里还有个坑。评测的请求量是样本数的好几倍，并发上限要按实际调用量估，不是按样本数估。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。