推文

@fireandstart · 2026-10-11 21:02

这条把 eval 的重点说得很清楚：基础设施只是容器，真正难的是定义“变好了”并留下可重复的证据。保存任务说明和初始文件状态很关键；如果每轮拿到的上下文不同，或者 Slack、搜索等工具连着实时服务，结果变化就可能来自输入漂移，而不是模型或提示词。把外部工具替换成固定回放、把运行放进隔离环境，才能让比较更公平。 我也赞同把评审放回专家日常工作的地方：工程看真实 PR，编辑看文档批注，营销看实际文案，减少额外标注负担。随后可把反馈拆成明确的二元检查项，让模型裁判先对齐一批人工判断，再拿它做大规模 A/B；同时保留人工抽查，尤其是高风险任务，避免把“裁判认同自己”误当成质量提升。代码测试适合可判定的约束，模型评审适合语义质量，专家则负责那些规则还说不清的边界。 有一点我会更谨慎：为了复用订阅而复制认证凭据会扩大泄露面，评测通常应优先用模拟工具或最小权限、短时凭据。先把任务、初始状态、评分标准和失败案例固定下来，再谈更复杂的 RL 环境；这样每次模型升级都能回答一个具体问题：哪些能力真的变好了，代价又是多少？

曝光 97 · 评论 1 · 点赞 1 · 书签 0 · 曝光/时 1.8820709191228098