训练数据在训练前需要一个真正的通过/不通过门控[D]

我们有针对代码、基础设施、部署和模型性能的门控。但到了实际的训练工件时，是否继续推进的决定往往仍然分散在笔记本、验证脚本、仪表板和人工判断中。这看起来是一个薄弱环节。我一直在思考一个适当的训练前控制层应该是什么样子。不是另一个只会生成一长串警告的工具，而是一个本地系统，能够审计即将使用的确切工件，并给出可重现的“通过”、“警告”、“不通过”或“不通过_安全”判定。该判定应基于明确的证据和硬性门控：泄漏、矛盾、冗余、覆盖率、来源、证据完整性，以及工件与其声明的训练目标之间的差距。关键区别在于，LLM不会决定判定结果。相同的工件、目标和配置应产生相同的结果。关键失败不应隐藏在体面的总体评分中。该系统还可以生成修复计划，仅对派生副本应用批准的更改，保留原始版本，然后运行第二次审计。所有内容都与清单、校验和及确切执行绑定。在我看来，这像是数据准备与训练之间缺失的一层。但我也能预见到最大的反对意见：训练数据的质量具有上下文相关性，如果系统不够透明，正式的判定可能会造成虚假的信心。因此，我很好奇，实际使用训练管线的人会如何对待这样的系统。你会让它阻止一次训练运行吗？你会相信判定结果，还是只相信背后的证据？在你的团队认真对待它之前，它需要证明什么？