LLM-as-a-Judge 生产级实现模式从结构化流水线到置信度校准Agent-Skills-for-Context-Engineering 实战指南【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering本篇技术指南以 implementation-patterns.md 为核心骨架系统讲解 LLM-as-a-Judge 评估系统的五大生产级实现模式结构化流水线、分层评估、多模型评审团、置信度校准、结构化输出、错误处理与测试模式。本指南适用于在本仓库中构建 LLM 评估流水线、将 LLM 评审接入 CI/CD或排查评估结果不一致等场景。读完你将掌握可直接落地的分层架构代码、位置偏差消除协议、评审团聚合算法以及配套的单元/集成/偏差测试写法并能与本仓库的 TypeScript 工具实现direct-score.ts、pairwise-compare.ts和 Python 示例脚本evaluation_example.py一一对应。一、模式文档的定位为什么需要实现模式这一层在 advanced-evaluation SKILL.md 中技能明确了核心洞察LLM-as-a-Judge 不是单一技术而是一族方法每种方法适配不同的评估场景。该技能还给出了两条方法论主线评估分类学Evaluation Taxonomy有客观标准事实准确性、指令遵循、毒性检测时用Direct Scoring直接评分无客观标准、属于主观偏好语气、风格、说服力时用Pairwise Comparison两两比较后者在主观任务上往往与人类偏好相关性更高对应仓库主张 claim-advanced-evaluation-position-swap。偏差全景Bias Landscape位置偏差、长度偏差、自我增强偏差、冗长偏差、权威偏差五大系统性偏差必须在每个评估系统中主动缓解。implementation-patterns.md正是把上述方法论转译为可复制代码的实现层它定义了稳定的流水线骨架、每一层的职责边界、以及从输入校验到输出格式化的完整契约。SKILL.md 中明确标注该参考文档的阅读时机从零搭建评估流水线或把 LLM 评审接入 CI/CD 时。这意味着本文档是所有模式代码的母本仓库中所有示例实现均围绕它展开。二、模式一结构化评估流水线Structured Evaluation Pipeline最可靠的评估系统遵循一个关注点分离separation of concerns的流水线Input Validation → Criteria Loading → Scoring → Bias Mitigation → Output Formatting每一层只做一件事层与层之间通过明确的数据结构解耦这使整个系统可单独调试、替换或回滚任意一层。下面按层讲解。2.1 输入校验层Input Validation Layer在评估开始前必须校验四类输入Response presence待评估的响应非空Prompt presence原始提示词存在为评分提供上下文Criteria validity至少有一个含名称与描述的评估标准Weight normalization权重之和归一化为 1.0或显式归一化。def validate_input(response, prompt, criteria): if not response or not response.strip(): raise ValueError(Response cannot be empty) if not prompt or not prompt.strip(): raise ValueError(Prompt cannot be empty) if not criteria or len(criteria) 0: raise ValueError(At least one criterion required) # Normalize weights total_weight sum(c.get(weight, 1) for c in criteria) for c in criteria: c[weight] c.get(weight, 1) / total_weight注意两个实现细节其一校验使用strip()判定空白字符串避免纯空格输入绕过检查其二c.get(weight, 1)允许调用方省略权重字段缺省视为 1再统一除以总和完成归一化从而兼容权重和为 1与权重随意填写两种调用习惯。这一逻辑在 TypeScript 实现中同样存在——direct-score.ts 在计算加权分时用totalWeight做除法归一化并通过 Zod 的CriterionSchema约束每个 criterion 必须包含name、description权重范围限定在 01。2.2 标准装载层Criteria Loading Layer评估标准应从配置加载而非硬编码这是评估系统可维护性的关键rubric 的迭代不应要求重新发布代码。class CriteriaLoader: def __init__(self, rubric_pathNone): self.rubrics self._load_rubrics(rubric_path) def get_criteria(self, task_type): return self.rubrics.get(task_type, self.default_criteria) def get_rubric(self, criterion_name): return self.rubrics.get(criterion_name, {}).get(levels, [])该类的两个查询方法分别服务于两种使用场景get_criteria(task_type)按任务类型如 factual、creative、summarization返回整套标准未命中时回退到默认标准get_rubric(criterion_name)按单个标准名返回其分级描述levels供评分层构造带分级锚点的提示词。这种标准外置 回退默认的设计对应 evaluation-pipeline.md 中流水线图的第一个阶段Criteria Loader从 Rubrics、weights 配置中加载。2.3 评分层Scoring Layer评分层负责真正的 LLM 调用。核心要点是通过系统提示词携带标准与 rubric通过用户提示词携带待评估内容并压低采样温度保证一致性async def score_response(response, prompt, criteria, rubric, model): system_prompt build_system_prompt(criteria, rubric) user_prompt build_user_prompt(response, prompt, criteria) result await generate_text( modelmodel, systemsystem_prompt, promptuser_prompt, temperature0.3 # Lower temperature for consistency ) return parse_scores(result.text)temperature0.3是本仓库所有评分实现的统一取值direct-score.ts 与 pairwise-compare.ts 均使用temperature: 0.3而 rubric 生成generate-rubric.ts因为是创意性任务取稍高的0.4。这一细节体现了评分求一致、生成求多样性的工程直觉。2.4 偏差缓解层Bias Mitigation Layer对于两两比较必须执行位置交换position swapping这是本文档与 SKILL.md 共同强调的最重要纪律——单次比较会被位置偏差污染。核心实现如下async def compare_with_bias_mitigation(response_a, response_b, prompt, criteria, model): # First pass: A first pass1 await compare_pair(response_a, response_b, prompt, criteria, model) # Second pass: B first pass2 await compare_pair(response_b, response_a, prompt, criteria, model) # Map pass2 winner back pass2_mapped map_winner(pass2.winner) # A→B, B→A, TIE→TIE # Check consistency if pass1.winner pass2_mapped: return { winner: pass1.winner, confidence: (pass1.confidence pass2.confidence) / 2, consistent: True } else: return { winner: TIE, confidence: 0.5, consistent: False }该协议的要点可拆解为三步两次独立评估第一次 A 在前第二次 B 在前第二次结果映射由于第二轮中 A 实际出现在第二位置需要把 winner 标签做A→B, B→A, TIE→TIE的逆映射才能与第一轮对齐一致性检查两轮判定一致则取平均置信度作为最终结果不一致则说明位置偏差真实存在强制返回 TIE 并将置信度压到 0.5。值得注意的是不一致被降级为平局而不是取多数票——这是本文档与 bias-mitigation.md 的一致选择当判断受位置影响时模型给出的胜负本身已不可信与其输出一个可疑的赢家不如诚实地报告不确定性并标记bias_detected: True。bias-mitigation.md 还记录了该偏差的实证背景研究表明 GPT 存在轻微的首位偏好在平局场景中约 55% 偏好第一位Claude 表现类似而较小的模型偏差通常更强。在 TypeScript 落地版 pairwise-compare.ts 中这一协议被实现为swapPositions开关开启时自动执行两轮evaluatePair、映射第二轮赢家、计算consistent并把不一致时的判定写死为TIE 0.5置信度关闭时则退化为单轮比较测试与线上调试都可通过该开关对比位置偏差的影响。此外它还把逐标准比较也做了交换映射合并——某个标准上两轮赢家不一致同样降级为 TIE。三、模式二分层评估Hierarchical Evaluation对于复杂评估单一模型打全场既不经济也不可靠。分层评估用成本递增、精度递增的漏斗结构替代一刀切Quick Screen (cheap model) → Detailed Evaluation (expensive model) → Human Review (edge cases)3.1 快速筛选层Quick Screen用便宜模型以temperature0做确定性筛查快速过滤明显通过/明显失败async def quick_screen(response, prompt, threshold0.7): Fast, cheap screening for obvious passes/fails. result await generate_text( modelgpt-5.2, # Cheaper model promptfRate 0-1 if this response adequately addresses the prompt:\n\nPrompt: {prompt}\n\nResponse: {response}, temperature0 ) score float(result.text.strip()) return score, score threshold注意该层刻意不加载完整 rubric只用一句自然语言问句 0-1 分数把单次调用的 token 成本压到最低。threshold0.7是筛选灵敏度旋钮调高则更多样本进入昂贵评估更保守调低则更多样本被快速放行更激进。3.2 详细评估层Detailed Evaluation边界样本或高价值样本进入完整评估使用更强的模型与完整提示词模板async def detailed_evaluation(response, prompt, criteria): Full evaluation for borderline or important cases. result await generate_text( modelgpt-5.2, # More capable model systemDETAILED_EVALUATION_PROMPT, promptbuild_detailed_prompt(response, prompt, criteria), temperature0.3 ) return parse_detailed_scores(result.text)说明代码中的模型名gpt-5.2来自仓库文档中的示例占位实际选型应替换为你可用的模型并遵循 SKILL.md 中生成模型与评估模型异族的自我增强偏差缓解建议。3.3 分层策略的规模化意义SKILL.md 的扩展评估Scaling Evaluation一节将这种思路归纳为三类规模化策略Panel of LLMs (PoLL)多模型作评审团并聚合投票降低单个模型的偏差成本更高但适合高利害决策分层评估Hierarchical便宜模型筛、贵模型判边缘样本前提是筛选阈值必须经过校准对应上面threshold参数的调优人机协同Human-in-the-loop自动化处理明确样本低置信度样本转人工并设计反馈回路持续改进自动评估。分层评估正是第二种策略的代码化表达快速筛选层的输出score, is_pass直接决定样本流向详细评估还是直接出结论形成完整的成本控制闭环。四、模式三多模型评审团Panel of LLM Judges, PoLL高利害评估场景下单一模型可能带有不可预测的偏好此时用多个模型投票以稀释个体偏差async def poll_evaluation(response, prompt, criteria, models): Aggregate judgments from multiple LLM judges. results await asyncio.gather(*[ score_with_model(response, prompt, criteria, model) for model in models ]) # Aggregate scores aggregated aggregate_scores(results) # Calculate agreement agreement calculate_agreement(results) return { scores: aggregated, agreement: agreement, individual_results: results } def aggregate_scores(results): Aggregate scores using median (robust to outliers). scores {} for criterion in results[0][scores].keys(): criterion_scores [r[scores][criterion] for r in results] scores[criterion] { score: statistics.median(criterion_scores), std: statistics.stdev(criterion_scores) if len(criterion_scores) 1 else 0 } return scores三个关键设计点asyncio.gather并发多个评审模型并行打分避免串行调用导致的延迟线性累加中位数聚合median相对均值对离群评审更稳健——某个评审模型的极端打分不会拉偏最终结果同时返回标准差std与agreement聚合分数只是结果的一半评审团分歧度本身是重要的质量信号。当std偏大或 agreement 偏低时说明该样本在模型间存在系统性分歧值得人工介入——这与分层评估的第三级Human Review形成自然衔接。五、模式四置信度校准Confidence Calibration高置信度的错误判断比低置信度的判断危害更大这一点被 SKILL.md 列入 Gotchas 第 5 条。因此置信度不能直接采信模型输出而必须结合多个信号校准def calibrate_confidence(raw_confidence, position_consistent, evidence_count): Calibrate confidence based on multiple signals. # Base confidence from model output calibrated raw_confidence # Position consistency is a strong signal if not position_consistent: calibrated * 0.6 # Significant reduction # More evidence higher confidence evidence_factor min(evidence_count / 3, 1.0) # Cap at 3 pieces calibrated * (0.7 0.3 * evidence_factor) return min(calibrated, 0.99) # Never 100% confident校准逻辑包含三条可解释的规则位置不一致 → 置信度 ×0.6两轮位置交换的判定不一致position_consistentFalse是偏差介入的强信号大幅折减置信度证据数量 → 置信度上浮证据越多越可信但证据数在 3 条后封顶min(evidence_count / 3, 1.0)上浮幅度被限制在 0.71.0 的区间内即最多上浮 30%硬上限 0.99永远不输出 100% 置信度为不确定性留出余量。该函数与 2.4 节的偏差缓解层形成完整的置信度体系偏差缓解层决定判定是否可信一致 → 平均置信度不一致 → 0.5 并判 TIE置信度校准层决定可信到什么程度。SKILL.md 的置信度校准指导Confidence Calibration明确给出了映射规则两轮一致时置信度取两轮各自置信度的平均值不一致时置信度固定为 0.5、判定固定为 TIE。这正是compare_with_bias_mitigation与calibrate_confidence配合使用的完整语义。六、模式五结构化输出格式Output Formatting评估结果必须使用一致的结构化 schema 返回——这是评估结果可被下游CI 门禁、报告、监控消费的前提dataclass class ScoreResult: criterion: str score: float max_score: float justification: str evidence: List[str] improvement: str dataclass class EvaluationResult: success: bool scores: List[ScoreResult] overall_score: float weighted_score: float summary: Dict[str, Any] metadata: Dict[str, Any] def format_output(scores, metadata) - EvaluationResult: Format evaluation results consistently. return EvaluationResult( successTrue, scoresscores, overall_scoresum(s.score for s in scores) / len(scores), weighted_scorecalculate_weighted_score(scores), summarygenerate_summary(scores), metadatametadata )该 schema 的设计语言与 TypeScript 侧的 Zod 定义高度一致DirectScoreOutputSchema 同样包含success、逐标准scores含maxScore、justification、evidence、improvement、overallScore、weightedScore、summaryassessment / strengths / weaknesses / priorities与metadata评估耗时、模型、标准数。两套实现Python dataclass 与 TypeScript Zod共享同一份结果契约说明输出格式模式的价值在于跨语言约定一致overall_score 各标准原始分数的算术平均简单、无偏weighted_score 按标准权重加权后的分数当标准重要性不均时与 overall 的差异本身就是诊断信号evidence字段强制要求评分附带可追溯的证据引用呼应 SKILL.md 第一条准则Always require evidence before scores。七、错误处理模式生产环境必然面对限流、解析失败、瞬时故障评估系统的鲁棒性取决于错误处理策略。7.1 优雅降级Graceful Degradation不同错误类型采取不同降级策略async def evaluate_with_fallback(response, prompt, criteria): try: return await full_evaluation(response, prompt, criteria) except RateLimitError: # Fall back to simpler evaluation return await simple_evaluation(response, prompt, criteria) except ParseError as e: # Return partial results with error flag return { success: False, partial_results: e.partial_data, error: str(e) }RateLimitError→ 简化评估限流时换用更省 token 的简单评估保住吞吐ParseError→ 返回部分结果 错误标志模型输出无法解析时不丢弃已解析出的部分数据而是连同错误信息一起返回方便上层决定是否重试或标记失败。这种失败也要返回结构化结果的思路在 TypeScript 实现中同样贯彻direct-score.ts 的 catch 分支返回success: false、空 scores、并在 summary.assessment 中携带错误信息而不是抛异常中断调用方。7.2 重试逻辑Retry Logic对瞬时错误使用指数退避重试async def evaluate_with_retry(response, prompt, criteria, max_retries3): for attempt in range(max_retries): try: result await evaluate(response, prompt, criteria) if is_valid_result(result): return result except TransientError: await asyncio.sleep(2 ** attempt) # Exponential backoff raise EvaluationError(Max retries exceeded)asyncio.sleep(2 ** attempt)生成 1s → 2s → 4s 的退避序列避免重试风暴且重试前还会用is_valid_result校验结果有效性——结果无效但不抛异常如空结果、schema 不符同样是触发重试的条件。超过max_retries3后抛出EvaluationError把最终失败显式暴露给上层而不是无限静默重试。八、测试模式评估系统的测试分层与普通软件相同单元测试验证解析逻辑集成测试验证真实流水线专门测试验证偏差缓解行为。8.1 解析逻辑单元测试def test_score_parsing(): raw_output {scores: [{criterion: Accuracy, score: 4}]} result parse_scores(raw_output) assert result.scores[0].criterion Accuracy assert result.scores[0].score 4 def test_malformed_output(): raw_output Invalid JSON with pytest.raises(ParseError): parse_scores(raw_output)两个用例一正一反正常 JSON 能被解析为结构化分数畸形输出必须抛ParseError该异常正是 7.1 节优雅降级所捕获的对象确保解析失败是可预期、可捕获的显式行为而不是静默产生空结果。8.2 真实 API 集成测试pytest.mark.integration async def test_full_evaluation_pipeline(): result await evaluate( responseWater boils at 100°C at sea level., promptAt what temperature does water boil?, criteria[{name: Accuracy, description: Factual correctness, weight: 1}] ) assert result.success assert len(result.scores) 1 assert result.scores[0].score 4 # Should score high for accurate response集成测试用常识性事实100°C 沸点验证端到端流水线不仅断言success与 scores 数量还断言分数下限≥4即对明显准确的回答应给出高分——这是对评分校准的冒烟测试。8.3 偏差检测测试async def test_position_bias_mitigation(): # Same response in both positions should tie result await compare( response_aSame response, response_bSame response, promptTest prompt, criteria[quality], swap_positionsTrue ) assert result.winner TIE assert result.consistent True这是最巧妙的偏差测试用完全相同的两个响应做两两比较。一个无位置偏差的评审系统理应判定 TIE——两轮交换后结果必然映射回平局、必然一致。如果该测试失败判出非 TIE 的赢家就说明模型存在位置偏差且未被缓解协议消除。这一用例在本仓库的 Vitest 测试套件中有直接对应evaluation.test.ts 的 should handle similar responses appropriately 用MEDIUM_RESPONSE对自身比较并断言winner TIE。仓库 READMEexamples/llm-as-judge-skills/README.md记录的 19 个测试全部通过其中偏差相关测试的结论与本文档预测完全一致相同响应返回 TIE、质量差距明显的响应赢家在两轮交换中保持一致。九、从模式到可运行代码仓库落地印证模式文档是母本仓库中能直接运行/测试的代码均可在其中找到对应关系模式/层参考实现直接评分含加权分计算evaluation_example.py、direct-score.ts位置交换 一致性检查pairwise_comparison_example、pairwise-compare.tsRubric 生成分级/特征/边界rubric_generation_example、generate-rubric.ts完整流水线架构图evaluation-pipeline.md偏差缓解细化协议多轮 shuffle、长度归一化、匿名化、事实核查bias-mitigation.md指标选择与评审质量监控metrics-guide.md其中 evaluation_example.py 以伪代码风格 预期输出的形式把三个核心模式串成可直接运行的主程序python skills/advanced-evaluation/scripts/evaluation_example.py无需任何外部依赖即可演示输入结构、提示词模板与结果 schema。该脚本还体现了两个值得注意的细节证据先于分数直接评分示例要求每个 criterion 先给evidenceCorrectly uses analogy再给分数与 SKILL.md 的Evidence-first准则一致期望值注释而非断言脚本用expected_output字典展示预期 JSON方便读者对照理解而非依赖网络调用。需提醒一点脚本 docstring 提到rubrics cut variance by 40-60%但 SKILL.md 明确告诫除非在目标评估集上实测否则把精确方差缩减视为负载相关的结论——因此该数字只应作为动机性描述具体收益必须在你自己的评估集上测量。十、落地自检清单将本指南付诸实施前对照以下检查项综合 SKILL.md 的 Guidelines 与 Gotchas证据先于分数评分提示词必须要求先引用具体证据再输出分数杜绝无依据打分两两比较必换位单次比较即出结论会被位置偏差污染两次交换 一致性检查是底线量表粒度匹配 rubric 精度1-10 分制必须有逐级详细描述否则评分校准难度陡增客观/主观标准分离客观用直接评分、主观用两两比较不要混用置信度必须校准结合位置一致性、证据数量等信号且永远不输出 100% 置信度边界情况显式定义含糊场景是评估方差的最大来源rubric 必须含 edge case 与处理规则使用领域专属 rubric代码可读性 rubric 应提及变量、函数、注释医学准确性 rubric 应使用临床术语对照人类判断验证自动化评估只有与人类评估相关才真正有价值指标参考 metrics-guide.md如 Spearmans ρ、加权 κ、位置一致性监控系统性偏差按标准、响应类型、模型跟踪分歧模式可用 bias-mitigation.md 的BiasMonitor做 z-score / Spearman 检测为迭代而设计评估提示词应版本化管理Gotchas 第 7 条警示提示词措辞的细微改动可能引起显著分数波动rubric 应定期对照新的人工标注样本重新锚定防止 rubric drift。以上十点逐条落实后你的评估系统就同时具备了模式文档要求的正确性偏差缓解与可维护性分层解耦、结构化输出、完整测试可以直接作为生产质量门禁或 CI/CD 集成的一部分投入使用。【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LLM-as-a-Judge 生产级实现模式：从结构化流水线到置信度校准（Agent-Skills-for-Context-Engineering 实战指南）
LLM-as-a-Judge 生产级实现模式从结构化流水线到置信度校准Agent-Skills-for-Context-Engineering 实战指南【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering本篇技术指南以 implementation-patterns.md 为核心骨架系统讲解 LLM-as-a-Judge 评估系统的五大生产级实现模式结构化流水线、分层评估、多模型评审团、置信度校准、结构化输出、错误处理与测试模式。本指南适用于在本仓库中构建 LLM 评估流水线、将 LLM 评审接入 CI/CD或排查评估结果不一致等场景。读完你将掌握可直接落地的分层架构代码、位置偏差消除协议、评审团聚合算法以及配套的单元/集成/偏差测试写法并能与本仓库的 TypeScript 工具实现direct-score.ts、pairwise-compare.ts和 Python 示例脚本evaluation_example.py一一对应。一、模式文档的定位为什么需要实现模式这一层在 advanced-evaluation SKILL.md 中技能明确了核心洞察LLM-as-a-Judge 不是单一技术而是一族方法每种方法适配不同的评估场景。该技能还给出了两条方法论主线评估分类学Evaluation Taxonomy有客观标准事实准确性、指令遵循、毒性检测时用Direct Scoring直接评分无客观标准、属于主观偏好语气、风格、说服力时用Pairwise Comparison两两比较后者在主观任务上往往与人类偏好相关性更高对应仓库主张 claim-advanced-evaluation-position-swap。偏差全景Bias Landscape位置偏差、长度偏差、自我增强偏差、冗长偏差、权威偏差五大系统性偏差必须在每个评估系统中主动缓解。implementation-patterns.md正是把上述方法论转译为可复制代码的实现层它定义了稳定的流水线骨架、每一层的职责边界、以及从输入校验到输出格式化的完整契约。SKILL.md 中明确标注该参考文档的阅读时机从零搭建评估流水线或把 LLM 评审接入 CI/CD 时。这意味着本文档是所有模式代码的母本仓库中所有示例实现均围绕它展开。二、模式一结构化评估流水线Structured Evaluation Pipeline最可靠的评估系统遵循一个关注点分离separation of concerns的流水线Input Validation → Criteria Loading → Scoring → Bias Mitigation → Output Formatting每一层只做一件事层与层之间通过明确的数据结构解耦这使整个系统可单独调试、替换或回滚任意一层。下面按层讲解。2.1 输入校验层Input Validation Layer在评估开始前必须校验四类输入Response presence待评估的响应非空Prompt presence原始提示词存在为评分提供上下文Criteria validity至少有一个含名称与描述的评估标准Weight normalization权重之和归一化为 1.0或显式归一化。def validate_input(response, prompt, criteria): if not response or not response.strip(): raise ValueError(Response cannot be empty) if not prompt or not prompt.strip(): raise ValueError(Prompt cannot be empty) if not criteria or len(criteria) 0: raise ValueError(At least one criterion required) # Normalize weights total_weight sum(c.get(weight, 1) for c in criteria) for c in criteria: c[weight] c.get(weight, 1) / total_weight注意两个实现细节其一校验使用strip()判定空白字符串避免纯空格输入绕过检查其二c.get(weight, 1)允许调用方省略权重字段缺省视为 1再统一除以总和完成归一化从而兼容权重和为 1与权重随意填写两种调用习惯。这一逻辑在 TypeScript 实现中同样存在——direct-score.ts 在计算加权分时用totalWeight做除法归一化并通过 Zod 的CriterionSchema约束每个 criterion 必须包含name、description权重范围限定在 01。2.2 标准装载层Criteria Loading Layer评估标准应从配置加载而非硬编码这是评估系统可维护性的关键rubric 的迭代不应要求重新发布代码。class CriteriaLoader: def __init__(self, rubric_pathNone): self.rubrics self._load_rubrics(rubric_path) def get_criteria(self, task_type): return self.rubrics.get(task_type, self.default_criteria) def get_rubric(self, criterion_name): return self.rubrics.get(criterion_name, {}).get(levels, [])该类的两个查询方法分别服务于两种使用场景get_criteria(task_type)按任务类型如 factual、creative、summarization返回整套标准未命中时回退到默认标准get_rubric(criterion_name)按单个标准名返回其分级描述levels供评分层构造带分级锚点的提示词。这种标准外置 回退默认的设计对应 evaluation-pipeline.md 中流水线图的第一个阶段Criteria Loader从 Rubrics、weights 配置中加载。2.3 评分层Scoring Layer评分层负责真正的 LLM 调用。核心要点是通过系统提示词携带标准与 rubric通过用户提示词携带待评估内容并压低采样温度保证一致性async def score_response(response, prompt, criteria, rubric, model): system_prompt build_system_prompt(criteria, rubric) user_prompt build_user_prompt(response, prompt, criteria) result await generate_text( modelmodel, systemsystem_prompt, promptuser_prompt, temperature0.3 # Lower temperature for consistency ) return parse_scores(result.text)temperature0.3是本仓库所有评分实现的统一取值direct-score.ts 与 pairwise-compare.ts 均使用temperature: 0.3而 rubric 生成generate-rubric.ts因为是创意性任务取稍高的0.4。这一细节体现了评分求一致、生成求多样性的工程直觉。2.4 偏差缓解层Bias Mitigation Layer对于两两比较必须执行位置交换position swapping这是本文档与 SKILL.md 共同强调的最重要纪律——单次比较会被位置偏差污染。核心实现如下async def compare_with_bias_mitigation(response_a, response_b, prompt, criteria, model): # First pass: A first pass1 await compare_pair(response_a, response_b, prompt, criteria, model) # Second pass: B first pass2 await compare_pair(response_b, response_a, prompt, criteria, model) # Map pass2 winner back pass2_mapped map_winner(pass2.winner) # A→B, B→A, TIE→TIE # Check consistency if pass1.winner pass2_mapped: return { winner: pass1.winner, confidence: (pass1.confidence pass2.confidence) / 2, consistent: True } else: return { winner: TIE, confidence: 0.5, consistent: False }该协议的要点可拆解为三步两次独立评估第一次 A 在前第二次 B 在前第二次结果映射由于第二轮中 A 实际出现在第二位置需要把 winner 标签做A→B, B→A, TIE→TIE的逆映射才能与第一轮对齐一致性检查两轮判定一致则取平均置信度作为最终结果不一致则说明位置偏差真实存在强制返回 TIE 并将置信度压到 0.5。值得注意的是不一致被降级为平局而不是取多数票——这是本文档与 bias-mitigation.md 的一致选择当判断受位置影响时模型给出的胜负本身已不可信与其输出一个可疑的赢家不如诚实地报告不确定性并标记bias_detected: True。bias-mitigation.md 还记录了该偏差的实证背景研究表明 GPT 存在轻微的首位偏好在平局场景中约 55% 偏好第一位Claude 表现类似而较小的模型偏差通常更强。在 TypeScript 落地版 pairwise-compare.ts 中这一协议被实现为swapPositions开关开启时自动执行两轮evaluatePair、映射第二轮赢家、计算consistent并把不一致时的判定写死为TIE 0.5置信度关闭时则退化为单轮比较测试与线上调试都可通过该开关对比位置偏差的影响。此外它还把逐标准比较也做了交换映射合并——某个标准上两轮赢家不一致同样降级为 TIE。三、模式二分层评估Hierarchical Evaluation对于复杂评估单一模型打全场既不经济也不可靠。分层评估用成本递增、精度递增的漏斗结构替代一刀切Quick Screen (cheap model) → Detailed Evaluation (expensive model) → Human Review (edge cases)3.1 快速筛选层Quick Screen用便宜模型以temperature0做确定性筛查快速过滤明显通过/明显失败async def quick_screen(response, prompt, threshold0.7): Fast, cheap screening for obvious passes/fails. result await generate_text( modelgpt-5.2, # Cheaper model promptfRate 0-1 if this response adequately addresses the prompt:\n\nPrompt: {prompt}\n\nResponse: {response}, temperature0 ) score float(result.text.strip()) return score, score threshold注意该层刻意不加载完整 rubric只用一句自然语言问句 0-1 分数把单次调用的 token 成本压到最低。threshold0.7是筛选灵敏度旋钮调高则更多样本进入昂贵评估更保守调低则更多样本被快速放行更激进。3.2 详细评估层Detailed Evaluation边界样本或高价值样本进入完整评估使用更强的模型与完整提示词模板async def detailed_evaluation(response, prompt, criteria): Full evaluation for borderline or important cases. result await generate_text( modelgpt-5.2, # More capable model systemDETAILED_EVALUATION_PROMPT, promptbuild_detailed_prompt(response, prompt, criteria), temperature0.3 ) return parse_detailed_scores(result.text)说明代码中的模型名gpt-5.2来自仓库文档中的示例占位实际选型应替换为你可用的模型并遵循 SKILL.md 中生成模型与评估模型异族的自我增强偏差缓解建议。3.3 分层策略的规模化意义SKILL.md 的扩展评估Scaling Evaluation一节将这种思路归纳为三类规模化策略Panel of LLMs (PoLL)多模型作评审团并聚合投票降低单个模型的偏差成本更高但适合高利害决策分层评估Hierarchical便宜模型筛、贵模型判边缘样本前提是筛选阈值必须经过校准对应上面threshold参数的调优人机协同Human-in-the-loop自动化处理明确样本低置信度样本转人工并设计反馈回路持续改进自动评估。分层评估正是第二种策略的代码化表达快速筛选层的输出score, is_pass直接决定样本流向详细评估还是直接出结论形成完整的成本控制闭环。四、模式三多模型评审团Panel of LLM Judges, PoLL高利害评估场景下单一模型可能带有不可预测的偏好此时用多个模型投票以稀释个体偏差async def poll_evaluation(response, prompt, criteria, models): Aggregate judgments from multiple LLM judges. results await asyncio.gather(*[ score_with_model(response, prompt, criteria, model) for model in models ]) # Aggregate scores aggregated aggregate_scores(results) # Calculate agreement agreement calculate_agreement(results) return { scores: aggregated, agreement: agreement, individual_results: results } def aggregate_scores(results): Aggregate scores using median (robust to outliers). scores {} for criterion in results[0][scores].keys(): criterion_scores [r[scores][criterion] for r in results] scores[criterion] { score: statistics.median(criterion_scores), std: statistics.stdev(criterion_scores) if len(criterion_scores) 1 else 0 } return scores三个关键设计点asyncio.gather并发多个评审模型并行打分避免串行调用导致的延迟线性累加中位数聚合median相对均值对离群评审更稳健——某个评审模型的极端打分不会拉偏最终结果同时返回标准差std与agreement聚合分数只是结果的一半评审团分歧度本身是重要的质量信号。当std偏大或 agreement 偏低时说明该样本在模型间存在系统性分歧值得人工介入——这与分层评估的第三级Human Review形成自然衔接。五、模式四置信度校准Confidence Calibration高置信度的错误判断比低置信度的判断危害更大这一点被 SKILL.md 列入 Gotchas 第 5 条。因此置信度不能直接采信模型输出而必须结合多个信号校准def calibrate_confidence(raw_confidence, position_consistent, evidence_count): Calibrate confidence based on multiple signals. # Base confidence from model output calibrated raw_confidence # Position consistency is a strong signal if not position_consistent: calibrated * 0.6 # Significant reduction # More evidence higher confidence evidence_factor min(evidence_count / 3, 1.0) # Cap at 3 pieces calibrated * (0.7 0.3 * evidence_factor) return min(calibrated, 0.99) # Never 100% confident校准逻辑包含三条可解释的规则位置不一致 → 置信度 ×0.6两轮位置交换的判定不一致position_consistentFalse是偏差介入的强信号大幅折减置信度证据数量 → 置信度上浮证据越多越可信但证据数在 3 条后封顶min(evidence_count / 3, 1.0)上浮幅度被限制在 0.71.0 的区间内即最多上浮 30%硬上限 0.99永远不输出 100% 置信度为不确定性留出余量。该函数与 2.4 节的偏差缓解层形成完整的置信度体系偏差缓解层决定判定是否可信一致 → 平均置信度不一致 → 0.5 并判 TIE置信度校准层决定可信到什么程度。SKILL.md 的置信度校准指导Confidence Calibration明确给出了映射规则两轮一致时置信度取两轮各自置信度的平均值不一致时置信度固定为 0.5、判定固定为 TIE。这正是compare_with_bias_mitigation与calibrate_confidence配合使用的完整语义。六、模式五结构化输出格式Output Formatting评估结果必须使用一致的结构化 schema 返回——这是评估结果可被下游CI 门禁、报告、监控消费的前提dataclass class ScoreResult: criterion: str score: float max_score: float justification: str evidence: List[str] improvement: str dataclass class EvaluationResult: success: bool scores: List[ScoreResult] overall_score: float weighted_score: float summary: Dict[str, Any] metadata: Dict[str, Any] def format_output(scores, metadata) - EvaluationResult: Format evaluation results consistently. return EvaluationResult( successTrue, scoresscores, overall_scoresum(s.score for s in scores) / len(scores), weighted_scorecalculate_weighted_score(scores), summarygenerate_summary(scores), metadatametadata )该 schema 的设计语言与 TypeScript 侧的 Zod 定义高度一致DirectScoreOutputSchema 同样包含success、逐标准scores含maxScore、justification、evidence、improvement、overallScore、weightedScore、summaryassessment / strengths / weaknesses / priorities与metadata评估耗时、模型、标准数。两套实现Python dataclass 与 TypeScript Zod共享同一份结果契约说明输出格式模式的价值在于跨语言约定一致overall_score 各标准原始分数的算术平均简单、无偏weighted_score 按标准权重加权后的分数当标准重要性不均时与 overall 的差异本身就是诊断信号evidence字段强制要求评分附带可追溯的证据引用呼应 SKILL.md 第一条准则Always require evidence before scores。七、错误处理模式生产环境必然面对限流、解析失败、瞬时故障评估系统的鲁棒性取决于错误处理策略。7.1 优雅降级Graceful Degradation不同错误类型采取不同降级策略async def evaluate_with_fallback(response, prompt, criteria): try: return await full_evaluation(response, prompt, criteria) except RateLimitError: # Fall back to simpler evaluation return await simple_evaluation(response, prompt, criteria) except ParseError as e: # Return partial results with error flag return { success: False, partial_results: e.partial_data, error: str(e) }RateLimitError→ 简化评估限流时换用更省 token 的简单评估保住吞吐ParseError→ 返回部分结果 错误标志模型输出无法解析时不丢弃已解析出的部分数据而是连同错误信息一起返回方便上层决定是否重试或标记失败。这种失败也要返回结构化结果的思路在 TypeScript 实现中同样贯彻direct-score.ts 的 catch 分支返回success: false、空 scores、并在 summary.assessment 中携带错误信息而不是抛异常中断调用方。7.2 重试逻辑Retry Logic对瞬时错误使用指数退避重试async def evaluate_with_retry(response, prompt, criteria, max_retries3): for attempt in range(max_retries): try: result await evaluate(response, prompt, criteria) if is_valid_result(result): return result except TransientError: await asyncio.sleep(2 ** attempt) # Exponential backoff raise EvaluationError(Max retries exceeded)asyncio.sleep(2 ** attempt)生成 1s → 2s → 4s 的退避序列避免重试风暴且重试前还会用is_valid_result校验结果有效性——结果无效但不抛异常如空结果、schema 不符同样是触发重试的条件。超过max_retries3后抛出EvaluationError把最终失败显式暴露给上层而不是无限静默重试。八、测试模式评估系统的测试分层与普通软件相同单元测试验证解析逻辑集成测试验证真实流水线专门测试验证偏差缓解行为。8.1 解析逻辑单元测试def test_score_parsing(): raw_output {scores: [{criterion: Accuracy, score: 4}]} result parse_scores(raw_output) assert result.scores[0].criterion Accuracy assert result.scores[0].score 4 def test_malformed_output(): raw_output Invalid JSON with pytest.raises(ParseError): parse_scores(raw_output)两个用例一正一反正常 JSON 能被解析为结构化分数畸形输出必须抛ParseError该异常正是 7.1 节优雅降级所捕获的对象确保解析失败是可预期、可捕获的显式行为而不是静默产生空结果。8.2 真实 API 集成测试pytest.mark.integration async def test_full_evaluation_pipeline(): result await evaluate( responseWater boils at 100°C at sea level., promptAt what temperature does water boil?, criteria[{name: Accuracy, description: Factual correctness, weight: 1}] ) assert result.success assert len(result.scores) 1 assert result.scores[0].score 4 # Should score high for accurate response集成测试用常识性事实100°C 沸点验证端到端流水线不仅断言success与 scores 数量还断言分数下限≥4即对明显准确的回答应给出高分——这是对评分校准的冒烟测试。8.3 偏差检测测试async def test_position_bias_mitigation(): # Same response in both positions should tie result await compare( response_aSame response, response_bSame response, promptTest prompt, criteria[quality], swap_positionsTrue ) assert result.winner TIE assert result.consistent True这是最巧妙的偏差测试用完全相同的两个响应做两两比较。一个无位置偏差的评审系统理应判定 TIE——两轮交换后结果必然映射回平局、必然一致。如果该测试失败判出非 TIE 的赢家就说明模型存在位置偏差且未被缓解协议消除。这一用例在本仓库的 Vitest 测试套件中有直接对应evaluation.test.ts 的 should handle similar responses appropriately 用MEDIUM_RESPONSE对自身比较并断言winner TIE。仓库 READMEexamples/llm-as-judge-skills/README.md记录的 19 个测试全部通过其中偏差相关测试的结论与本文档预测完全一致相同响应返回 TIE、质量差距明显的响应赢家在两轮交换中保持一致。九、从模式到可运行代码仓库落地印证模式文档是母本仓库中能直接运行/测试的代码均可在其中找到对应关系模式/层参考实现直接评分含加权分计算evaluation_example.py、direct-score.ts位置交换 一致性检查pairwise_comparison_example、pairwise-compare.tsRubric 生成分级/特征/边界rubric_generation_example、generate-rubric.ts完整流水线架构图evaluation-pipeline.md偏差缓解细化协议多轮 shuffle、长度归一化、匿名化、事实核查bias-mitigation.md指标选择与评审质量监控metrics-guide.md其中 evaluation_example.py 以伪代码风格 预期输出的形式把三个核心模式串成可直接运行的主程序python skills/advanced-evaluation/scripts/evaluation_example.py无需任何外部依赖即可演示输入结构、提示词模板与结果 schema。该脚本还体现了两个值得注意的细节证据先于分数直接评分示例要求每个 criterion 先给evidenceCorrectly uses analogy再给分数与 SKILL.md 的Evidence-first准则一致期望值注释而非断言脚本用expected_output字典展示预期 JSON方便读者对照理解而非依赖网络调用。需提醒一点脚本 docstring 提到rubrics cut variance by 40-60%但 SKILL.md 明确告诫除非在目标评估集上实测否则把精确方差缩减视为负载相关的结论——因此该数字只应作为动机性描述具体收益必须在你自己的评估集上测量。十、落地自检清单将本指南付诸实施前对照以下检查项综合 SKILL.md 的 Guidelines 与 Gotchas证据先于分数评分提示词必须要求先引用具体证据再输出分数杜绝无依据打分两两比较必换位单次比较即出结论会被位置偏差污染两次交换 一致性检查是底线量表粒度匹配 rubric 精度1-10 分制必须有逐级详细描述否则评分校准难度陡增客观/主观标准分离客观用直接评分、主观用两两比较不要混用置信度必须校准结合位置一致性、证据数量等信号且永远不输出 100% 置信度边界情况显式定义含糊场景是评估方差的最大来源rubric 必须含 edge case 与处理规则使用领域专属 rubric代码可读性 rubric 应提及变量、函数、注释医学准确性 rubric 应使用临床术语对照人类判断验证自动化评估只有与人类评估相关才真正有价值指标参考 metrics-guide.md如 Spearmans ρ、加权 κ、位置一致性监控系统性偏差按标准、响应类型、模型跟踪分歧模式可用 bias-mitigation.md 的BiasMonitor做 z-score / Spearman 检测为迭代而设计评估提示词应版本化管理Gotchas 第 7 条警示提示词措辞的细微改动可能引起显著分数波动rubric 应定期对照新的人工标注样本重新锚定防止 rubric drift。以上十点逐条落实后你的评估系统就同时具备了模式文档要求的正确性偏差缓解与可维护性分层解耦、结构化输出、完整测试可以直接作为生产质量门禁或 CI/CD 集成的一部分投入使用。【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考