Netflix 每周要生成几十万条「为什么推荐这部剧」的解释，人类根本审不过来。…

Netflix 每周要生成几十万条「为什么推荐这部剧」的解释，人类根本审不过来。于是他们把 LLM-as-a-Judge 真正放进了生产系统。 这篇论文记录了 Netflix 如何搭建一套 Judge 的完整生命周期：建立人工标准、训练 Judge、上线拦截，再持续监控和更新。 其中一个设计叫 RART。Judge 除了要判断一条解释能不能通过，还要和人工评审在「为什么失败」这件事上对齐。因为上线后，Judge 给出的失败理由会直接交给生成模型，让它重新修改答案。理由判断错了，下一轮修改也会被带偏。 上线后，每条解释都会经过「生成 → Judge → 修改」的循环，最多重试 3 次；同时每周再抽取约 300 条结果交给人工复查，用来监测 Judge 有没有随着内容变化逐渐漂移。 最终他们做了 5 周、覆盖数千万 Netflix 用户的 A/B 测试。加入这套 Judge 之后，用户观看未看过内容的比例提升 0.2%，成功从浏览进入播放的 session 提升 0.3%。数字看起来不大，但在 Netflix 这个规模下已经很有意义。 现在我开始愿意把 LLM-as-a-Judge 看成一种长期运行的基础设施。上线时对齐一次远远不够。数据会变、用户会变、生成模型也会变，Judge 自己也需要持续被检查和校准。未来 Agent 系统里的 evaluator，可能也会逐渐拥有自己的「生命周期」。 论文地址：arxiv.org/abs/2608.18300 这是一个非常有价值的实践案例，把LLM-as-a-Judge从概念推向了可落地的生产系统，为做AI开发的朋友提供了很好的参考方案。