01
有据可依性 (Groundedness)
核查回答中的陈述是否有提供的上下文或参考答案作为支撑。
判定结果
同一个回答可能在三个不同维度上出现问题
保持评估维度的独立性，以便团队明确回答通过或未通过的具体原因。
02
相关性 (Relevance)
区分“真正有用的回答”与“看似自信却偏离问题”的回答。
03
完整性 (Completeness)
判断回答是否涵盖了所有要点，而非简单地将其归为单一标签。
更安全的评估闭环
在信任评分之前，先验证评估器本身的可靠性
从存在分歧的案例入手，分析失败模式，再确定自动化评估的阈值。
构建小型评估集. 包含明确通过、明确失败以及难以判定的案例。
与人工评估对比. 按评估维度分析分歧，而非简单地取平均值掩盖差异。
分流不确定案例. 将低置信度或高风险的判定结果发送至人工复核队列。
回答 + 参考上下文
“回答引用了相关政策，但遗漏了退款期限信息。”
回答 + 参考上下文
→
分类判定case 18
使用自定义评估标准
并行评估
保留评估依据
01
输入回答
将生成的答案、问题和参考资料作为一个“状态”整体发送。
02
为各项检查命名
针对每个质量维度，提出明确的“是/否”、选择题或评分题。
03
关联结果
将判定结果、置信度和审核决定与评估运行记录一并存储。
单次请求中包含评估标准
单次请求中包含评估标准
从存在分歧的案例入手，分析失败模式，再确定自动化评估的阈值。
单次请求中包含评估标准
POST /v1/evaluate{
"state": {
"question": "Can I get a refund?",
"answer": "Refunds are available within 30 days.",
"policy": "Refunds are available within 14 days."
},
"questions": {
"grounded": { "type": "noul", "instructions": "Is the answer supported by policy?" },
"complete": { "type": "score", "instructions": "How complete is the answer?", "criteria": ["missing", "partial", "complete"] }
}
}常见问题
评估前先提问
这和让大语言模型（LLM）打分是一回事吗？+
该工作流保持各项标准的独立明确，并返回带有概率的结构化答案。您的应用程序可以决定如何组合这些结果以及何时引入人工介入。
我可以使用自己的评估标准吗？+
可以。标准和答案选项均包含在请求中，因此评估标准可以适配您的产品或审核策略。
所有结果都应自动化处理吗？+
不必。利用典型示例设定阈值，并将模棱两可或影响重大的案例转交人工审核。
