可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载在 Phoenix 的 LLM 评估体系中评判模型Judge Model的选型往往被误当成换个大模型就能解决一切的捷径。本文以 Phoenix 官方技能文档.agents/skills/phoenix-evals/references/fundamentals-model-selection.md为骨架结合packages/phoenix-evals与packages/phoenix-client的源码实现系统讲解一套可落地的评判模型选型方法论先用错误分析定位真实问题再决定是否需要更换模型以及如何用 TPR/TNR 等指标量化模型变更的效果。读完本文你将掌握何时该换模型、何时该改提示词的判断标准并能直接在 Phoenix 中写出可验证的评判模型配置。一、核心原则错误分析优先模型变更殿后文档开篇就给出了整个选型流程的指导思想——Error analysis first, model changes last错误分析优先模型变更殿后。这条原则源于一个朴素的事实多数评估表现不佳的问题根源并不在模型本身而在提示词、检索链路或工具调用上。官方文档用一个决策树把判断过程固化下来Performance Issue? │ ▼ Error analysis suggests model problem? NO → Fix prompts, retrieval, tools YES → Is it a capability gap? YES → Consider model change NO → Fix the actual problem这个决策树可以拆成三步先确认存在性能问题通过实验experiment的聚合分数、线上 trace 的错误率或用户反馈发现表现下滑用错误分析判断问题归属参考.agents/skills/phoenix-evals/references/error-analysis.md采样 100 条 trace错误样本、负反馈样本与随机样本各取一部分逐条写笔记、按失败类别归组、再按频率 × 严重度排序。如果归类结果显示答非所问上下文没被使用这类问题说明是提示词或检索链路的问题而不是模型能力不够只有确认是能力缺口capability gap时才考虑换模型例如推理、数学计算、代码生成这类硬能力短板才是模型本身的边界。这套方法与 Phoenix 技能库中Build from your failures从失败中构建评估器的理念一脉相承error-analysis→axial-coding轴编码归类失败模式→ 构建针对性评估器是一条完整的正向链路见 .agents/skills/phoenix-evals/SKILL.md 中的 Workflows 章节。二、评判模型的选型三原则在确认确实需要或至少需要开始搭建LLM 评判器之后官方文档给出了三条选型原则原则行动Start capable先用能力强的先用 gpt-4o 这类强模型起步Optimize later稳定后再优化评估标准稳定后再测试更便宜的模型Same model OK同模型可以评判器与应用模型做的是不同任务用同一个模型没问题2.1 先用强模型稳定后再降级# Start with capable model judge ClassificationEvaluator( llmLLM(provideropenai, modelgpt-4o), ... ) # After validation, test cheaper judge_cheap ClassificationEvaluator( llmLLM(provideropenai, modelgpt-4o-mini), ... ) # Compare TPR/TNR on same test set这里的ClassificationEvaluator与LLM都来自phoenix.evals包。从源码看LLM封装类位于 packages/phoenix-evals/src/phoenix/evals/llm/wrapper.py其构造函数支持provider、model、client可选指定该 provider 下使用哪个 SDK 客户端、initial_per_second_request_rate初始每秒请求速率用于限流以及sync_client_kwargs/async_client_kwargs分别给同步/异步 SDK 客户端单独传参例如不同的超时时间llm LLM( provideropenai, modelgpt-4o, api_keyyour-api-key, sync_client_kwargs{timeout: 60.0}, async_client_kwargs{timeout: 120.0}, )LLM构造时必须同时指定provider与model否则会抛出ValueError。可用 provider 由当前环境已安装的 SDK 决定Phoenix 内置了 OpenAI、Anthropic、Google、LangChain、LiteLLM 等适配器对应目录为 packages/phoenix-evals/src/phoenix/evals/llm/adapters可以用show_provider_availability()查看当前可用的 provider 列表。2.2 为什么建议同模型做评判器可行Same model OK这条原则容易被误解。它想说明的是评判模型judge与应用模型generator承担的是完全不同的任务——前者判断这条输出是否符合既定标准后者负责生成这条输出。评判任务通常远简单于生成任务因此哪怕应用侧换用了其他模型评判器保留原模型或反之并不会造成逻辑冲突。真正需要警惕的是评判标准漂移只要切换了评判模型就必须在同一份测试集上重新对比 TPR/TNR详见第五节。2.3 评判器配置的完整形态ClassificationEvaluator的完整签名位于 packages/phoenix-evals/src/phoenix/evals/evaluators.py其choices参数支持三种形态List[str]仅标签列表如[positive, negative]score 为NoneDict[str, float|int]标签映射数值分数如{helpful: 1, not_helpful: 0}推荐使用Dict[str, Tuple[float|int, str]]标签映射(分数, 描述)元组源码注释明确提示不推荐因为 LLM 难以稳定遵循这种 schema。此外ClassificationEvaluator默认include_explanationTrue会自动要求 LLM 输出分类理由且要求底层 LLM 具备 tool calling 或结构化输出能力。一个完整的先强后廉对比实验可以这样组织from phoenix.evals import ClassificationEvaluator, LLM from phoenix.evals import evaluate_dataframe from sklearn.metrics import classification_report, confusion_matrix judge ClassificationEvaluator( namefaithfulness, llmLLM(provideropenai, modelgpt-4o), prompt_templateFAITHFULNESS_TEMPLATE, # 包含 {{input}} / {{context}} / {{output}} choices{faithful: 1.0, unfaithful: 0.0}, ) judge_cheap ClassificationEvaluator( namefaithfulness, llmLLM(provideropenai, modelgpt-4o-mini), prompt_templateFAITHFULNESS_TEMPLATE, choices{faithful: 1.0, unfaithful: 0.0}, ) for name, ev in [(gpt-4o, judge), (gpt-4o-mini, judge_cheap)]: preds evaluate_dataframe(dataframegolden_df, evaluators[ev])[label] # 与人工标注 golden_labels 对比输出 TPR/TNR print(name, classification_report(golden_labels, preds))提示词模板的写法可参考仓库内置的官方评判器配置例如 packages/phoenix-evals/src/phoenix/evals/generated/classification_evaluator_configs/_faithfulness_classification_evaluator_config.py其中用query{{input}}/query、context{{context}}/context、response{{output}}/response的 XML 标签包裹变量并要求模型只输出faithful或unfaithful单个词。同目录下还有_correctness_...、_retrieval_relevance_...、_hallucination_...等 14 个预置配置是学习评判提示词结构的最佳范本。三、不要货比三家式地盲目换模型Dont Model Shop最典型的反模式是把模型选型做成跑分循环在同一个数据集上把候选模型逐个跑一遍实验然后挑分数最高的那个。官方文档用一段代码明确标出了这种做法的错误from phoenix.client import Client client Client() # BAD for model in [gpt-4o, claude-3, gemini-pro]: results client.experiments.run_experiment( datasetdataset, tasklambda input, _modelmodel: task(input, model_model), evaluatorsevaluators, )这种模型超市式做法的三个问题成本高昂且不可控每个候选模型都要在完整数据集上跑一遍生成任务加评判任务Token 消耗线性放大无法定位根因分数差异可能来自提示词对某些模型的适配程度、输出格式差异甚至随机性而不是能力差距换模型掩盖了真实缺陷不可复现、不可解释没有错误分析支撑的模型替换无法回答为什么这个模型更好。对照run_experiment的源码签名见 packages/phoenix-client/src/phoenix/client/experiments/init.pyrun_experiment本质上是在一个数据集上执行一个任务并用评估器衡量其行为它适合用来验证假设而不是用来扫雷。其关键参数包括task对数据集每条示例执行的函数可按参数名绑定input、expected/reference、metadata、example等特殊字段evaluators单个评估器或列表/字典repetitions重复执行次数默认 1retries失败重试次数默认 3dry_run是否试运行rate_limit_errors限流错误处理策略。正确姿势是把run_experiment用在有明确假设的场景例如怀疑 gpt-4o-mini 在长上下文忠实度上不行那么在同一数据集上、用同一组评估器只对比 gpt-4o 与 gpt-4o-mini 两个版本即可而不是一次性铺开多个模型。四、什么情况下更换模型是合理的官方文档给出了三条换模型正当性标准三者应当同时满足才动手Failures persist after prompt optimization提示词已经按失败模式优化过例如补充了判断标准、正反例、XML 标签包裹变量同类失败依旧出现Capability gaps (reasoning, math, code)错误分析明确指向能力缺口例如多步推理断裂、数值计算错误、代码语法/逻辑错误——这些是提示词无法弥补的硬边界Error analysis confirms model limitation错误分类结果一致指向模型本身而不是提示词、检索或工具问题。结合文档中的GOOD示例正确流程是先分析错误类型再决策# GOOD failures analyze_errors(results) # Ignores context → Fix prompt # Cant do math → Maybe try better model其中analyze_errors对应的是 Phoenix 的错误分析工作流采样 trace → 写注释 → 轴编码归类 → 量化优先级具体方法见 .agents/skills/phoenix-evals/references/error-analysis.md。归类时可参考其建议的类别模板例如factual_inaccuracy事实错误、hallucination凭空捏造、tone_mismatch语气不符、tool_issues工具调用问题、retrieval检索问题——其中hallucination与retrieval更常指向检索/上下文链路而纯推理错误才指向模型能力。五、用验证指标把换模型变成可量化决策更便宜/更贵的模型不能靠感觉取舍官方文档反复强调要在同一份测试集上对比 TPR/TNR。这正好落在 Phoenix 的验证validation工作流中其核心要求见 .agents/skills/phoenix-evals/references/validation.md包括要求目标测试集规模100 条示例正负样本平衡约 50/50 pass/fail准确率80%TPR / TNR两者都 70%指标计算可直接复用 sklearnfrom sklearn.metrics import classification_report, confusion_matrix, cohen_kappa_score print(classification_report(human_labels, evaluator_predictions)) print(fKappa: {cohen_kappa_score(human_labels, evaluator_predictions):.3f}) cm confusion_matrix(human_labels, evaluator_predictions) tn, fp, fn, tp cm.ravel() tpr tp / (tp fn) tnr tn / (tn fp)使用这些指标时需要注意TPR召回率用于质量保障场景漏判FN代价高时重点关注TNR特异度用于安全敏感场景误报FP代价高时重点关注Cohens Kappa用于横向比较多个候选评判器与人工标注的一致程度超出随机水平的协议一般认为 Kappa 0.6 是红灯换模型后若 TPR/TNR 出现一升一降的大缺口说明模型对某类样本的系统性偏差变了需要回到错误分析看是提示词还是能力问题。此外验证工作流中还提供了用已知 TPR/TNR 修正线上观测通过率的工具函数见 .agents/skills/phoenix-evals/references/validation-evaluators-python.md用于在部署后估算真实通过率def correct_estimate(observed, tpr, tnr): Adjust observed pass rate using known TPR/TNR. return (observed - (1 - tnr)) / (tpr - (1 - tnr))这也意味着切换评判模型属于重大变更必须重新验证。按验证文档的Re-Validate When清单提示词模板变更、评判模型变更、评估标准变更都属于必须重新验证的触发条件。六、落地清单把模型选型做成流程而非玄学综合官方文档与源码一套可复制的评判模型选型流程如下定位问题在 Phoenix 中对项目做 trace 采样错误样本 负反馈样本 随机样本逐条写注释并归组参考 .agents/skills/phoenix-evals/references/error-analysis.md判断归属按决策树判断是提示词/检索/工具问题还是模型能力缺口前者先修提示词后者才进入模型选型搭建评判器先用强模型如 gpt-4o配置ClassificationEvaluator提示词模板可参考内置的 14 个官方配置目录见上文LLM封装支持 provider/model/客户端级参数provider 适配器覆盖 OpenAI、Anthropic、Google、LangChain、LiteLLM 等建立黄金数据集100 条、正负约各半、由专家标注参考 .agents/skills/phoenix-evals/references/validation.md验证强模型在黄金数据集上确认 TPR/TNR 双双 70%同集对比降级在同一份黄金数据集上测试更便宜的模型如 gpt-4o-mini用classification_report、confusion_matrix与cohen_kappa_score对比只有 TPR/TNR 达标才允许降级用run_experiment验证假设带着明确假设而非扫雷心态在完整数据集上运行实验参数细节见 packages/phoenix-client/src/phoenix/client/experiments/init.py持续监控评判模型、提示词模板或评估标准任何一项变更都触发重新验证部署后可用correct_estimate修正观测通过率并用聚合指标门禁而非单条结果做 CI 判定。一句话总结在 Phoenix Evals 中评判模型的选型本质上是错误分析驱动的决策而不是跑分驱动的赌博——先用强模型把评估标准定准再用验证指标把模型变更做定量对比最后用实验体系把结论沉淀为可复现的证据。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐模型选择决策树基于simple-evals结果的选型指南模型选择决策树基于simple evals结果的选型指南 在人工智能快速发展的今天选择合适的语言模型已成为开发者和研究者的重要决策。simple evals模型评测选择翻译模型的智慧translation-model-opus的优势分析选择翻译模型的智慧translation model opus的优势分析 在当今全球化时代翻译服务已经成为连接不同语言和文化的重要桥梁。对于开发者而言选择lllyasviel/Annotators模型选择指南根据任务选择最优模型lllyasviel/Annotators模型选择指南根据任务选择最优模型 引言 在计算机视觉和图像处理领域选择合适的预训练模型是项目成功的关键因素。lll人工智能计算机视觉深度学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Phoenix Evals 评判模型（Judge Model）选择指南：错误分析优先，模型变更殿后
可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载在 Phoenix 的 LLM 评估体系中评判模型Judge Model的选型往往被误当成换个大模型就能解决一切的捷径。本文以 Phoenix 官方技能文档.agents/skills/phoenix-evals/references/fundamentals-model-selection.md为骨架结合packages/phoenix-evals与packages/phoenix-client的源码实现系统讲解一套可落地的评判模型选型方法论先用错误分析定位真实问题再决定是否需要更换模型以及如何用 TPR/TNR 等指标量化模型变更的效果。读完本文你将掌握何时该换模型、何时该改提示词的判断标准并能直接在 Phoenix 中写出可验证的评判模型配置。一、核心原则错误分析优先模型变更殿后文档开篇就给出了整个选型流程的指导思想——Error analysis first, model changes last错误分析优先模型变更殿后。这条原则源于一个朴素的事实多数评估表现不佳的问题根源并不在模型本身而在提示词、检索链路或工具调用上。官方文档用一个决策树把判断过程固化下来Performance Issue? │ ▼ Error analysis suggests model problem? NO → Fix prompts, retrieval, tools YES → Is it a capability gap? YES → Consider model change NO → Fix the actual problem这个决策树可以拆成三步先确认存在性能问题通过实验experiment的聚合分数、线上 trace 的错误率或用户反馈发现表现下滑用错误分析判断问题归属参考.agents/skills/phoenix-evals/references/error-analysis.md采样 100 条 trace错误样本、负反馈样本与随机样本各取一部分逐条写笔记、按失败类别归组、再按频率 × 严重度排序。如果归类结果显示答非所问上下文没被使用这类问题说明是提示词或检索链路的问题而不是模型能力不够只有确认是能力缺口capability gap时才考虑换模型例如推理、数学计算、代码生成这类硬能力短板才是模型本身的边界。这套方法与 Phoenix 技能库中Build from your failures从失败中构建评估器的理念一脉相承error-analysis→axial-coding轴编码归类失败模式→ 构建针对性评估器是一条完整的正向链路见 .agents/skills/phoenix-evals/SKILL.md 中的 Workflows 章节。二、评判模型的选型三原则在确认确实需要或至少需要开始搭建LLM 评判器之后官方文档给出了三条选型原则原则行动Start capable先用能力强的先用 gpt-4o 这类强模型起步Optimize later稳定后再优化评估标准稳定后再测试更便宜的模型Same model OK同模型可以评判器与应用模型做的是不同任务用同一个模型没问题2.1 先用强模型稳定后再降级# Start with capable model judge ClassificationEvaluator( llmLLM(provideropenai, modelgpt-4o), ... ) # After validation, test cheaper judge_cheap ClassificationEvaluator( llmLLM(provideropenai, modelgpt-4o-mini), ... ) # Compare TPR/TNR on same test set这里的ClassificationEvaluator与LLM都来自phoenix.evals包。从源码看LLM封装类位于 packages/phoenix-evals/src/phoenix/evals/llm/wrapper.py其构造函数支持provider、model、client可选指定该 provider 下使用哪个 SDK 客户端、initial_per_second_request_rate初始每秒请求速率用于限流以及sync_client_kwargs/async_client_kwargs分别给同步/异步 SDK 客户端单独传参例如不同的超时时间llm LLM( provideropenai, modelgpt-4o, api_keyyour-api-key, sync_client_kwargs{timeout: 60.0}, async_client_kwargs{timeout: 120.0}, )LLM构造时必须同时指定provider与model否则会抛出ValueError。可用 provider 由当前环境已安装的 SDK 决定Phoenix 内置了 OpenAI、Anthropic、Google、LangChain、LiteLLM 等适配器对应目录为 packages/phoenix-evals/src/phoenix/evals/llm/adapters可以用show_provider_availability()查看当前可用的 provider 列表。2.2 为什么建议同模型做评判器可行Same model OK这条原则容易被误解。它想说明的是评判模型judge与应用模型generator承担的是完全不同的任务——前者判断这条输出是否符合既定标准后者负责生成这条输出。评判任务通常远简单于生成任务因此哪怕应用侧换用了其他模型评判器保留原模型或反之并不会造成逻辑冲突。真正需要警惕的是评判标准漂移只要切换了评判模型就必须在同一份测试集上重新对比 TPR/TNR详见第五节。2.3 评判器配置的完整形态ClassificationEvaluator的完整签名位于 packages/phoenix-evals/src/phoenix/evals/evaluators.py其choices参数支持三种形态List[str]仅标签列表如[positive, negative]score 为NoneDict[str, float|int]标签映射数值分数如{helpful: 1, not_helpful: 0}推荐使用Dict[str, Tuple[float|int, str]]标签映射(分数, 描述)元组源码注释明确提示不推荐因为 LLM 难以稳定遵循这种 schema。此外ClassificationEvaluator默认include_explanationTrue会自动要求 LLM 输出分类理由且要求底层 LLM 具备 tool calling 或结构化输出能力。一个完整的先强后廉对比实验可以这样组织from phoenix.evals import ClassificationEvaluator, LLM from phoenix.evals import evaluate_dataframe from sklearn.metrics import classification_report, confusion_matrix judge ClassificationEvaluator( namefaithfulness, llmLLM(provideropenai, modelgpt-4o), prompt_templateFAITHFULNESS_TEMPLATE, # 包含 {{input}} / {{context}} / {{output}} choices{faithful: 1.0, unfaithful: 0.0}, ) judge_cheap ClassificationEvaluator( namefaithfulness, llmLLM(provideropenai, modelgpt-4o-mini), prompt_templateFAITHFULNESS_TEMPLATE, choices{faithful: 1.0, unfaithful: 0.0}, ) for name, ev in [(gpt-4o, judge), (gpt-4o-mini, judge_cheap)]: preds evaluate_dataframe(dataframegolden_df, evaluators[ev])[label] # 与人工标注 golden_labels 对比输出 TPR/TNR print(name, classification_report(golden_labels, preds))提示词模板的写法可参考仓库内置的官方评判器配置例如 packages/phoenix-evals/src/phoenix/evals/generated/classification_evaluator_configs/_faithfulness_classification_evaluator_config.py其中用query{{input}}/query、context{{context}}/context、response{{output}}/response的 XML 标签包裹变量并要求模型只输出faithful或unfaithful单个词。同目录下还有_correctness_...、_retrieval_relevance_...、_hallucination_...等 14 个预置配置是学习评判提示词结构的最佳范本。三、不要货比三家式地盲目换模型Dont Model Shop最典型的反模式是把模型选型做成跑分循环在同一个数据集上把候选模型逐个跑一遍实验然后挑分数最高的那个。官方文档用一段代码明确标出了这种做法的错误from phoenix.client import Client client Client() # BAD for model in [gpt-4o, claude-3, gemini-pro]: results client.experiments.run_experiment( datasetdataset, tasklambda input, _modelmodel: task(input, model_model), evaluatorsevaluators, )这种模型超市式做法的三个问题成本高昂且不可控每个候选模型都要在完整数据集上跑一遍生成任务加评判任务Token 消耗线性放大无法定位根因分数差异可能来自提示词对某些模型的适配程度、输出格式差异甚至随机性而不是能力差距换模型掩盖了真实缺陷不可复现、不可解释没有错误分析支撑的模型替换无法回答为什么这个模型更好。对照run_experiment的源码签名见 packages/phoenix-client/src/phoenix/client/experiments/init.pyrun_experiment本质上是在一个数据集上执行一个任务并用评估器衡量其行为它适合用来验证假设而不是用来扫雷。其关键参数包括task对数据集每条示例执行的函数可按参数名绑定input、expected/reference、metadata、example等特殊字段evaluators单个评估器或列表/字典repetitions重复执行次数默认 1retries失败重试次数默认 3dry_run是否试运行rate_limit_errors限流错误处理策略。正确姿势是把run_experiment用在有明确假设的场景例如怀疑 gpt-4o-mini 在长上下文忠实度上不行那么在同一数据集上、用同一组评估器只对比 gpt-4o 与 gpt-4o-mini 两个版本即可而不是一次性铺开多个模型。四、什么情况下更换模型是合理的官方文档给出了三条换模型正当性标准三者应当同时满足才动手Failures persist after prompt optimization提示词已经按失败模式优化过例如补充了判断标准、正反例、XML 标签包裹变量同类失败依旧出现Capability gaps (reasoning, math, code)错误分析明确指向能力缺口例如多步推理断裂、数值计算错误、代码语法/逻辑错误——这些是提示词无法弥补的硬边界Error analysis confirms model limitation错误分类结果一致指向模型本身而不是提示词、检索或工具问题。结合文档中的GOOD示例正确流程是先分析错误类型再决策# GOOD failures analyze_errors(results) # Ignores context → Fix prompt # Cant do math → Maybe try better model其中analyze_errors对应的是 Phoenix 的错误分析工作流采样 trace → 写注释 → 轴编码归类 → 量化优先级具体方法见 .agents/skills/phoenix-evals/references/error-analysis.md。归类时可参考其建议的类别模板例如factual_inaccuracy事实错误、hallucination凭空捏造、tone_mismatch语气不符、tool_issues工具调用问题、retrieval检索问题——其中hallucination与retrieval更常指向检索/上下文链路而纯推理错误才指向模型能力。五、用验证指标把换模型变成可量化决策更便宜/更贵的模型不能靠感觉取舍官方文档反复强调要在同一份测试集上对比 TPR/TNR。这正好落在 Phoenix 的验证validation工作流中其核心要求见 .agents/skills/phoenix-evals/references/validation.md包括要求目标测试集规模100 条示例正负样本平衡约 50/50 pass/fail准确率80%TPR / TNR两者都 70%指标计算可直接复用 sklearnfrom sklearn.metrics import classification_report, confusion_matrix, cohen_kappa_score print(classification_report(human_labels, evaluator_predictions)) print(fKappa: {cohen_kappa_score(human_labels, evaluator_predictions):.3f}) cm confusion_matrix(human_labels, evaluator_predictions) tn, fp, fn, tp cm.ravel() tpr tp / (tp fn) tnr tn / (tn fp)使用这些指标时需要注意TPR召回率用于质量保障场景漏判FN代价高时重点关注TNR特异度用于安全敏感场景误报FP代价高时重点关注Cohens Kappa用于横向比较多个候选评判器与人工标注的一致程度超出随机水平的协议一般认为 Kappa 0.6 是红灯换模型后若 TPR/TNR 出现一升一降的大缺口说明模型对某类样本的系统性偏差变了需要回到错误分析看是提示词还是能力问题。此外验证工作流中还提供了用已知 TPR/TNR 修正线上观测通过率的工具函数见 .agents/skills/phoenix-evals/references/validation-evaluators-python.md用于在部署后估算真实通过率def correct_estimate(observed, tpr, tnr): Adjust observed pass rate using known TPR/TNR. return (observed - (1 - tnr)) / (tpr - (1 - tnr))这也意味着切换评判模型属于重大变更必须重新验证。按验证文档的Re-Validate When清单提示词模板变更、评判模型变更、评估标准变更都属于必须重新验证的触发条件。六、落地清单把模型选型做成流程而非玄学综合官方文档与源码一套可复制的评判模型选型流程如下定位问题在 Phoenix 中对项目做 trace 采样错误样本 负反馈样本 随机样本逐条写注释并归组参考 .agents/skills/phoenix-evals/references/error-analysis.md判断归属按决策树判断是提示词/检索/工具问题还是模型能力缺口前者先修提示词后者才进入模型选型搭建评判器先用强模型如 gpt-4o配置ClassificationEvaluator提示词模板可参考内置的 14 个官方配置目录见上文LLM封装支持 provider/model/客户端级参数provider 适配器覆盖 OpenAI、Anthropic、Google、LangChain、LiteLLM 等建立黄金数据集100 条、正负约各半、由专家标注参考 .agents/skills/phoenix-evals/references/validation.md验证强模型在黄金数据集上确认 TPR/TNR 双双 70%同集对比降级在同一份黄金数据集上测试更便宜的模型如 gpt-4o-mini用classification_report、confusion_matrix与cohen_kappa_score对比只有 TPR/TNR 达标才允许降级用run_experiment验证假设带着明确假设而非扫雷心态在完整数据集上运行实验参数细节见 packages/phoenix-client/src/phoenix/client/experiments/init.py持续监控评判模型、提示词模板或评估标准任何一项变更都触发重新验证部署后可用correct_estimate修正观测通过率并用聚合指标门禁而非单条结果做 CI 判定。一句话总结在 Phoenix Evals 中评判模型的选型本质上是错误分析驱动的决策而不是跑分驱动的赌博——先用强模型把评估标准定准再用验证指标把模型变更做定量对比最后用实验体系把结论沉淀为可复现的证据。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐模型选择决策树基于simple-evals结果的选型指南模型选择决策树基于simple evals结果的选型指南 在人工智能快速发展的今天选择合适的语言模型已成为开发者和研究者的重要决策。simple evals模型评测选择翻译模型的智慧translation-model-opus的优势分析选择翻译模型的智慧translation model opus的优势分析 在当今全球化时代翻译服务已经成为连接不同语言和文化的重要桥梁。对于开发者而言选择lllyasviel/Annotators模型选择指南根据任务选择最优模型lllyasviel/Annotators模型选择指南根据任务选择最优模型 引言 在计算机视觉和图像处理领域选择合适的预训练模型是项目成功的关键因素。lll人工智能计算机视觉深度学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考