将作为裁判的大型语言模型视为动态生产系统进行管理
了解 Netflix 的四阶段生命周期——真实数据、基于评分标准的训练、安全发布以及持续监控——是如何在大规模应用中保持大型语言模型评估工具的准确性的。
大型语言模型如今已处于日益扩展的任务范畴的核心：生成文本、回答问题、编写代码、调用工具，以及代表用户做出决策。
这种发展引出了一个关键问题：
谁来检查人工智能的工作成果？
对于传统的分类任务，质量检测相对简单——只需将预测结果与标注过的示例进行对比即可。但生成式人工智能打破了这一模式：一个提示词就能产生数千甚至数百万条看似合理的回应，而准确性、BLEU或ROUGE等标准指标往往无法判断这些答案是否真正有用、基于事实、安全、相关或可信。
人工审核仍是目前最可靠的检测方式，但其速度根本无法跟上生产量增长的速度。
正是由于这一缺陷，LLM作为评判者才成为当今人工智能评估中最广泛采用的模式之一：无需将所有输出都交给人类评审员，只需让另一个LLM来评估第一个LLM的输出即可。
不过这种方法也带来了自身的困境：
当评判者本身也开始出错时该怎么办？
Netflix发表了相关研究，介绍了其如何设计并维护此类自动化评判系统以评估推荐内容附带解释的质量，该研究也为这一问题提供了详细的解答。
其核心观点虽然简单，但却意义深远：
LLM评判者不应被视为固定的评估工具，而应被当作需要持续发展的生产系统来管理。
该论文提出了构建和运行此类“评判者”的四阶段生命周期：
┌───────────────────────┐
│ I. BIRTH │
│ Human Ground Truth │
│ Labels + Rationales │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ II. TRAINING │
│ RART │
│ Rubric Optimization │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ III. DEPLOYMENT │
│ Quality Gate + Critic │
│ Self-Reflection │
└───────────┬───────────┘
↓
┌───────────────────────┐
│ IV. MONITORING │
│ HITL + Drift │
└───────────┬───────────┘
│
└──────→ Retrain
根据论文所述，Netflix在部署时每周要评估数十万条推荐理由，该系统还通过涵盖数千万用户的为期五周的A/B测试进行了验证。
1. 为何需要以大语言模型作为评判者？
想象一下，某个推荐引擎会输出类似这样的内容：
“因为您喜欢《老友记》，您可能会喜欢这部喜剧。”
要判断这样的解释是否真正合理，需要检查几项内容：
- 其内容在事实层面是否准确？
- 它是否反映了用户实际观看过的内容？
- 所推荐的标题与参考标题之间是否有实质性的关联？
以Netflix的规模而言，为每一条解释都手动回答这些问题是不现实的——论文指出该系统每周会生成数十万条独特的单项级解释 这正是自动评判系统所要填补的空白： 从理论上讲，这套机制看起来很完善。但实际上，评判系统也有可能出错。 假设某位人工审核员将某条解释标记为： 而大型语言模型评判系统却独立得出了相同的结论： Generated Explanation
│
▼
┌───────────────┐
│ LLM-as-Judge │
└───────┬───────┘
│
┌──────┴──────┐
↓ ↓
PASS FAIL
│ │
↓ ↓
Serve Revise
2. 评判系统也可能出错
FAIL
FAIL
乍看之下，这一一致似乎证明了法官的判断是正确的。但最终标签的一致性并不能保证法官是基于合理原因才拒绝该解释的。请看这种不一致：
Human:
FAIL
Reason:
The explanation incorrectly claims
that the two titles share a genre.Judge:
FAILReason:
The explanation is too verbose.
标签虽然一致，但背后的推理却完全不同。
为什么这种差异很重要？因为在这种架构中，法官并不局限于事后对输出结果进行评分——它还可以充当指导生成器如何修改其响应的批评者。这意味着有缺陷的推理可能会继续传递下去：
Wrong Judge Reason
↓
Wrong Revision Instruction
↓
Generator
↓
Another Bad Explanation
这一点实际上是该论文论点的核心：法官必须出于正确的理由做出正确判决。仅凭偶然的正确结果是不够的，因为即便表面上的裁决看似正确，错误的推理仍可能悄悄将系统引向错误的方向。
3. 生命周期由四个阶段构成
Netflix将整个系统划分为四个不同的阶段：
- 诞生
- 训练
- 部署
- 监控
下面将详细介绍每个阶段。
4. 第一阶段——诞生：建立真实基准
这一初始阶段几乎完全依赖人类判断。
领域专家负责确定：
- 用于评估的标准
- 标注指南
随后由人工审核员评估这些示例解释并生成：
Example
+
PASS / FAIL
+
Rationale
每个标签背后的推理过程与标签本身同样重要。
而非仅记录：
Example → FAIL
系统会捕获：
Example → FAIL → Why it failed
这为审核员提供的远不止一个简单的二元信号——它实现了对**推理过程本身的监督**。
根据论文所述，最初的基准数据包含约900条由人工标注的解释，各类别比例几乎均衡，其中约54%被标记为失败。
5. 为何不直接从生产环境数据中抽样？
这里一个值得注意的选择是，该基准数据刻意避免反映实际生产环境中的数据分布。
假设现实世界中的流量情况如下：
99.5% PASS
0.5% FAIL
一个总是预测为“通过”的评估器其得分将是：
99.5% accuracy
仅基于准确率——而实际上并未检测到任何故障。
这样的结果在实践中毫无价值。
正因如此，该基准测试刻意增加复杂案例和故障的占比。
它主要基于三个来源：
Benchmark
│
┌────────────┼────────────┐
↓ ↓ ↓
Expert Cases Boundary Production
Cases Samples
最终得到的是一个包含大量复杂示例的基准测试，而非仅仅反映各种结果在实际应用中的出现频率。
这体现了人工智能评估工作中的一个更广泛原则：
根据你关注的故障模式来设计评估集——不要直接复制生产环境中的原始数据分布。
6. 第二阶段——训练：与推理相一致的评分标准调整
该论文提出的核心技术思想是：
RART——与推理相一致的评分标准调整
RART并非反复微调评判模型的权重，而是专注于优化评判模型所遵循的评分标准。
其工作流程大致如下：
Initial Rubric
↓
LLM Judge
↓
Predictions + Rationales
↓
Compare Against Humans
↓
Identify Errors
↓
Reasoning Meta-Judge
↓
Reflector LLM
↓
Improved Rubric
↓
Repeat
本质上，这是一种针对文本而非数字进行的优化。
不同于常见的循环结构：
Loss
↓
Gradient
↓
Weights
RART采用的是：
Evaluation Errors
↓
Reflection
↓
Rubric Update
该论文将RART归类为那些能够直接用自然语言优化提示词或评分标准的方法范畴。
7. RART实际上试图解决什么问题？
RART针对两类不同的问题。
错误类型1：标签不匹配
Human = PASS
Judge = FAIL
或者相反的情况：
Human = FAIL
Judge = PASS
这些都是简单的评估错误。
错误类型2：标签正确，推理有误
Human = FAIL
Judge = FAIL
然而：
Human rationale ≠ Judge rationale
第二类情况则更为有趣。
会使用一个推理元评判器来检查评判者的推理过程是否与人类评分员的推理一致。
通过这种方式发现的差异会反馈给反思机制，进而用于优化评分标准。
8. RART算法的工作原理
从概念层面来看，其运行流程如下：
R₀ = Initial Rubric
for each iteration: predictions = Judge(Rₜ) evaluate predictions find:
X = label mismatches N = human FAIL + judge FAIL N× = agreed FAIL
but wrong rationale focus = X ∪ N× Rₜ₊₁ = Reflector(Rₜ, focus)return best rubric
关键要点是：
Judge Error
≠
Only Wrong Label
法官不仅会因为给出错误的标签而出错——即便最终判决是正确的，如果其根本推理有误，同样会导致错误。
所描述的算法将这两种错误类型视为同等需要纠正的。
9. 决定法官质量的三个指标
在评估法官自身时，有三个指标最为重要。
9.1 精确性
精确性体现的是法官识别出真正错误解释的可靠性。
换言之，它相当于专门为“失败”类别计算的召回率。
为何这一指标值得特别关注？
因为漏掉错误解释的表现如下：
Bad Explanation
↓
Judge says PASS
↓
User sees it
这种遗漏属于严重且危险的错误模式。
正因如此，本文将特异性视为最需要追踪的关键指标。
10. 召回率
召回率用于衡量评估者避免拒绝真正优质解释的能力。
召回率 = 正确通过的优秀解释数量除以所有经人工标注为优秀的解释总数。
如果评估者不加区分地拒绝所有解释，虽然特异性数值会很高，但召回率却会很差。
其后果如下：
Good explanation
↓
Judge FAIL
↓
Revision
↓
More inference
↓
Potentially dropped
这就是为什么系统需要同时平衡这两个指标，而非单独优化其中一个。
11. 推理一致性
第三个指标RA_neg考察的比简单通过/失败准确率更为微妙：当系统标记某项解释为错误时，其识别的根本原因是否与人工评估者一致？
从概念上讲，当人类将某项解释标记为“失败”，原因定为A，而裁判也因原因A判定为失败时，这即视为推理一致：
Human → FAIL → Reason A
Judge → FAIL → Reason A
↓ Reasoning Agreement
但如果裁判虽同意“失败”的判定，却指出了不同的根本原因，即原因B而非A，那就属于推理不一致：
Human → FAIL → Reason A
Judge → FAIL → Reason B
↓ Reasoning Mismatch
这种区别在实践中非常重要，因为裁判给出的推理依据往往会直接作为修正信号反馈给生成器。如果“原因”有误，生成器尝试进行的修复很可能会出错。
在已报告的实验中，经过测试的300对推理案例中，专门的推理质量裁判有98.6%的时间能与人类对推理质量的评估结果相符。
12. 具有业务意识的目标函数
为何特异性会被置于其他指标之上？答案在于非对称风险。
设想情况A：
Case A:
生成了错误的解释，审核员正确地将其标记为“失败”，这样系统就有机会在内容呈现给用户之前进行修正。
Bad explanation
↓
Judge FAIL
↓
Revision
现在设想情况B：
Case B:
生成了错误的解释，但审核员错误地将其标记为“通过”。在这种情况下就没有第二次机会了，有缺陷的解释会原样被使用。
Bad explanation
↓
Judge PASS
↓
User sees it
这种非对称性引出了一个明确的原则：错误的“通过”所带来的后果远比错误的“失败”严重。这说明了在设计评估指标时应当以实际的业务和产品风险为依据，而非仅仅追求通用的准确率分数。
13. 第三阶段：正式上线
一旦法官模型被调整好并校准完毕，它就会进入实际应用阶段，在那里承担两项不同的任务。
第一项任务：充当质量关卡。生成器首先产生一个解释，法官会对该解释进行评估，随后给出通过或失败的判定。
Generator
↓
Judge
↓
PASS → Serve
FAIL → Revise
第二项任务：充当评审者。除了给出判定结果外，法官还会说明特定输出为何失败，从而为生成器提供可依据的改进方向。
Generator
↓
Judge
↓
FAIL + Reason
↓
Generator
↓
Revised Explanation
通过生成、评估和评审的结合，形成了一个闭环，使得评估者从被动的评分者转变为参与生成最终输出的主动角色。
Generate
↓
Judge
↓
Reflect
↓
Generate Again
14. 反射需要限制
允许系统无限次地对自己的输出进行评审和重新生成，会带来明显风险：无限制的重试意味着成本也会无限上升。那么有什么机制来控制这一点呢？
Generate
↓
Judge
↓
Revise
↓
Judge
↓
Revise
↓
Judge
↓
Revise
↓
...
生产环境通过设定固定的重试次数——最多3次——来解决此问题，超过75%的解析结果能在该次数限制内完成。相应的架构如下：
Attempt 1
↓
Judge
↓ FAIL
Attempt 2
↓
Judge
↓ FAIL
Attempt 3
↓
Judge
↓ FAIL
DROP
核心原则是，反射式修正循环必须在明确的成本和延迟限制下运行，而不能无限制地持续执行。
15. 安全失败处理：放弃而非发布
如果某个解析在用尽所有重试机会后仍失败，有两种处理方式。它可以选择继续输出有问题的结果：
FAIL → Serve anyway
或者直接放弃该输出：
FAIL → Drop
更安全且此处采用的方式就是直接放弃该输出，这体现了这样一种理念：任何解析结果都不如正确的结果，尤其是在错误后果严重的AI系统中。
16. 第四阶段：持续监控
将判断器发送出去并不会结束其生命周期，反而会开启一个新的周期。生产环境会持续变化：
Catalog changes
+
Users change
+
Recommendation models change
+
Generator changes
+
Language changes
↓
Distribution Shift
因此，判断器可能会逐渐与人类的判断标准出现偏差。为了解决这个问题，会通过人工干预的校准流程每周收集大约300个新的解释供人类评分，从而形成如下循环：
Production
↓
Sample
↓
Human Evaluation
↓
Judge vs Human
↓
Drift?
/ \
No Yes
│ │
│ ▼
│ RART
│ │
└───────┘
这本质上是对评估者本身的持续评估。
17. 完整的闭环系统
将各个阶段结合起来，所得到的成果远比单纯的评估流程更为复杂：
HUMAN EXPERTS
│
▼
┌──────────────┐
│ Benchmark │
│ Labels + │
│ Rationales │
└──────┬───────┘
│
▼
┌──────────────┐
│ RART │
│ Rubric │
│ Optimization │
└──────┬───────┘
│
▼
┌──────────────┐
│ LLM Judge │
└──────┬───────┘
│
┌─────────┴─────────┐
│ │
▼ ▼
QUALITY GATE CRITIC
│ │
│ ▼
│ Self-Reflection
│ │
└─────────┬─────────┘
▼
PRODUCTION
│
▼
HITL Sampling
│
▼
Drift Detection
│
┌────┴────┐
│ │
Stable Drift
│ │
│ ▼
│ RART
│ │
└─────────┘
这实际上构成了对整个人工智能系统的真正控制循环。
18. 这在Netflix之外的意义
尽管这篇论文是以解释推荐系统为核心展开的，但它所描述的模式其实可以应用于更广泛的场景。
以实际的生产级RAG流程为例。
不必只使用一个评估器，可以并行部署多个：
RAG Response
│
┌───────────┼───────────┐
↓ ↓ ↓
Faithfulness Relevance Citation
Judge Judge Judge
│ │ │
└───────────┼───────────┘
↓
Final Gate
当某个答案未通过评估时：
Judge
↓
Reason
↓
Retriever / Generator
↓
Retry
同样的整体设计可直接应用。
19. 在智能体AI中的应用
引入自主智能体后，这一概念更具吸引力。
想象一下企业级智能体工作流程：
User
↓
Planner
↓
Tool Selection
↓
Tool Execution
↓
Answer
现在在之上再叠加评估层：
Agent
│
┌───────────┼────────────┐
↓ ↓ ↓
Safety Correctness Policy
Judge Judge Judge
│ │ │
└───────────┼────────────┘
↓
Gate
而当某个响应失败时：
Judge
↓
Reason
↓
Agent Reflection
↓
New Plan
↓
Tool Call
↓
Judge
本质上这与之前描述的生成 → 评估 → 反思 → 再生成循环相同。
20. 与RAG评估的关联
针对RAG系统，可以定义一组专门的评估器：
Judge 1 → Retrieval relevance
Judge 2 → Context sufficiency
Judge 3 → Faithfulness
Judge 4 → Answer relevance
Judge 5 → Citation correctness
Judge 6 → Safety
它们以这样的方式相互连接：
RAG Pipeline
│
▼
Evaluation Layer
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Retrieval Generation Safety
Judge Judge Judge
│ │ │
└─────────────┼─────────────┘
↓
Gate
这里的关键要点是：
评估应被视为核心架构组件，而非事后添加的附加内容。
21. 与RLHF及RLAIF的关系
这与训练后的优化技术也存在显著的相似之处。
传统的RLHF遵循一种常见的流程：
Human Preferences
↓
Reward Model
↓
Policy Optimization
↓
LLM
RLAIF则在人类输入之外加入（或补充）人工智能生成的反馈。
Netflix采用的路径则有所不同：
Human Labels + Rationales
↓
LLM Judge
↓
Rubric Optimization
↓
Production
↓
Human Feedback
↓
Re-tuning
值得注意的是，基础大语言模型本身无需重新训练。
相反，发生变化的是评估标准。
正因如此，当重新训练核心模型成本过高或根本不可行时，这一策略尤为实用。
22. 为何仅靠准确率不够
该论文最明确的警示之一就是：
仅凭高准确率评分并不足以判定系统已具备上线条件。
假设你观察到：
Judge Accuracy = 95%
这个数字在纸面上看起来很理想。
但请考虑如果剩余的5%错误集中在以下情况会怎样：
Safety violations
或者：
Hallucinations
又或者：
Incorrect financial advice
在这种情况下，系统仍可能不适合部署。
面向生产环境的评估需要综合考虑：
Accuracy
+
Error asymmetry
+
Reasoning alignment
+
Risk
+
Business impact
这是一种更为精细的评判LLM评估质量的方法。
23. 记住：评分系统本身也是一种模型
还有一个容易忽视的相关要点。
团队通常会投入大量精力去审查生成模型：
How good is our LLM?
却很少会问：
How good is our evaluator?
在封闭的反馈循环中，评估器本身便成为至关重要的基础设施。
这意味着你需要：
Generator Monitoring
+
Judge Monitoring
理想情况下还需：
Judge Drift Detection
这就引出了一个递归性问题：
谁来评估评估器？
该论文的答案是综合了以下几方面：
Human Ground Truth
+
Rationale Meta-Judge
+
Continuous HITL Sampling
24. 引入元评估器
从概念上讲，这会在结构中增加另一层：
Generator
↓
Judge
↓
Judge Rationale
↓
Meta-Judge
↓
Reasoning Agreement
从而形成类似如下的结构：
LLM
↓
LLM Judge
↓
LLM Meta-Judge
不过至关重要的是，最终的参考标准依然是人类判断。
该系统并非仅仅是：
LLM → LLM → LLM
实际上它是：
Human
↓
LLM Judge
↓
LLM Meta-Judge
↓
Human Audit
这种差异绝非微不足道的小问题。
25. 一个重要的实际经验：反馈可能会放大错误
请考虑以下场景：
Generator makes mistake
↓
Judge detects it
↓
Judge gives correct reason
↓
Generator improves
那是理想的情况。
现在来看看这种情况：
Generator makes mistake
↓
Judge detects it
↓
Judge gives WRONG reason
↓
Generator follows wrong instruction
↓
Output becomes worse
在这里，裁判并非只是旁观系统运行。
它实际上在操控系统。
正因如此，当裁判的裁决被反馈到系统生成过程中时，其可靠性就显得更为重要。这是该框架中最精辟的架构见解之一。
26. 裁判成为控制平面
整个架构可以这样描绘：
AI APPLICATION
│
▼
┌────────────────┐
│ JUDGE │
│ │
│ Evaluate │
│ Explain │
│ Gate │
│ Critique │
└───────┬────────┘
│
┌───────────┴───────────┐
↓ ↓
Serve Revise
│
▼
Generate
基于此，裁判更像是一个AI控制平面，而非单纯的评分工具。
27. 当世界发生变化时会发生什么？
这正是生命周期框架发挥作用的关键所在。
想象一下推荐系统在不断演变。或者思考：
New catalog
New genres
New users
New recommendation model
New generator model
New product requirements
任何这样的移位都会改变生成器的输出分布。其结果是：
P_{production}(x)
随着时间推移会出现漂移。但评估器是针对以下情况进行调优的：
P_{train}(x)
最终两者会出现分歧：实际数据不再与评估器训练时所用的数据一致。这就是典型的分布漂移现象。
因此，评估器需要持续维护，而非仅构建一次即可。这正是生命周期管理不可或缺的原因。
28. 最重要的概念转变
传统观点如下：
Build Judge
↓
Benchmark
↓
Accuracy
↓
Deploy
↓
Done
而生命周期视角则表现为：
Build
↓
Align
↓
Deploy
↓
Monitor
↓
Detect Drift
↓
Re-align
↓
Deploy
↓
Monitor
↓
...
简单来说：
Evaluate→Deploy→Monitor→Learn→Re−evaluate
评估器不再是一个固定的工具，而变成了一个动态运行的系统。
29. 企业级人工智能的实际架构
对于企业级LLM平台而言，合理的评估层可能如下所示：
┌──────────────────────┐
│ AI Application │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ LLM Generator │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Evaluation Layer │
│ │
│ Quality Judge │
│ Safety Judge │
│ Grounding Judge │
│ Policy Judge │
└──────────┬───────────┘
│
┌──────────┴──────────┐
↓ ↓
PASS FAIL
│ │
▼ ▼
Serve Reflect
│
▼
Retry
│
▼
Judge
与之并行运行的部分为：
Production
↓
Sampling
↓
Human Evaluation
↓
Judge Alignment
↓
Drift Detection
↓
Rubric Optimization
这两者共同构成了整个AI平台的评估基础设施。
30. 面试视角
如果你正在准备LLM架构师、高级机器学习工程师或AI平台相关的面试，这一框架可为你提供出色的系统设计思路。
一个扎实的回答可能如下：
“我不会将作为评判器的大型语言模型当作固定的一次性评估工具来使用。我会将其视为具有独立生命周期的组件。首先需要构建特定领域的人工真实数据，包括相应的标签和推理依据。接着根据标签错误与推理错误的情况调整评判标准。系统上线后，该评判器将同时承担两个角色：一方面把控内容质量，另一方面在有限的自我反思循环中起到反馈作用。最后，要持续抽取实际输出结果供人工审核，追踪评判器与人工判断的一致性以发现偏差，并在一致性下降时重新训练或调整该评判器。”
这样的回答表明了在评估设计、提示词优化、人机协同工作流程、自我反思机制、生产级机器学习实践、数据漂移检测、反馈循环设计、安全考量、成本与延迟权衡以及整体系统架构等方面的熟练程度。
值得牢记的五大核心原则
如果只能从该框架中提取五个要点，那就选这五个。
评分标准绝非一成不变的固定事物。应将其视为一个需要全生命周期管理的系统，与它所评估的产品一同持续发展。
Judge = Lifecycle-managed system
简单的标签无法说明全部情况。仅给出通过或失败的结论而不解释得出该结论的原因，是远远不够的。
PASS / FAIL
+
WHY
决策依据与最终结果具有同等的重要性。
得到正确答案与出于正确原因得出该答案并非同一回事。法官即便推理过程有误，也有可能给出正确的判断，而这种差异至关重要。
Right answer
≠
Right reason
自我反思循环需要设定严格限制。生成、判断、修正，再再次判断的循环
Generate
→ Judge
→ Revise
→ Judge
必须设定最大重试次数，否则循环可能会无限运转而无法收敛。
评估器本身也需要持续监督。通过人工抽样处理生成结果，将人工判断与模型判断进行对比，并以这种对比作为检测偏差的早期预警信号。
Production
↓
Human Sampling
↓
Judge Alignment
↓
Drift
↓
Re-tune
宏观视角
这里真正的贡献并非RART技术本身，而是该领域在将评估视为一门独立学科时的思维方式转变。
旧有的思路是探讨如何评估某个特定的大语言模型。而更好的思路则是思考如何在底层人工智能不断变化的情况下，构建一个始终可靠的评估系统。这其实是两个截然不同的问题。
现代人工智能产品已不再是单一的静态模型，而是由多个动态组件构成的整体：
Models
+
Prompts
+
Retrievers
+
Tools
+
Agents
+
Memory
+
Evaluators
+
Human Feedback
一旦这些组件中的任何一部分发生变化，评估层也必须随之改变。正因如此，评估工作本身需要相应的架构设计，而不仅仅是评分脚本。
Evaluation itself needs an architecture.
简而言之：
LLM-as-a-Judge is not a model. It is an evaluation lifecycle.
总结
这一框架的应用范围远不止于推荐系统。同样的模式——真实标准、评分规则调整、双角色部署、持续监控——可以构成一种可重复使用的架构：
HUMAN GROUND TRUTH
│
▼
DOMAIN BENCHMARK
│
▼
RART / TUNING
│
▼
LLM JUDGE
│
┌──────┴──────┐
↓ ↓
GATE CRITIC
│ │
│ SELF-REFLECTION
│ │
└──────┬──────┘
↓
PRODUCTION
│
▼
HUMAN SAMPLING
│
▼
DRIFT DETECTION
│
▼
RART
│
└──────→ CONTINUOUS LOOP
它适用于RAG系统、智能体AI、训练后处理流程、安全评估、代码生成、企业级协同助手、客服代理、工具使用及多智能体系统，以及更广泛的LLM质量评估平台。
其核心理念很简单：随着AI系统日益具备自主性，评估不能再只是偶尔进行的离线操作，而必须成为系统本身中持续运行的组成部分。