硅基流动博客发布一篇LLM评估方法文章，建议以应用任务、真实失败案例和接受运行率、每次成功任务成本等指标对比模型，并给出模型对比中需保持一致的变量清单。
硅基流动（SiliconFlow）官方博客发布一篇关于LLM评估指标的指南，主张用应用实际执行的任务来比较模型，而非依赖公开基准决定选型。文章称，公开基准可以帮助建立候选名单，但无法判断模型是否遵循你的指令、处理你的边缘案例、满足延迟目标或实现最低的每次成功任务成本。
按应用类型选择指标
文章按应用类型列出主指标、辅助指标和常见错误。分类任务看准确率、精确率、召回率或F1，类别高度不平衡时不应只看准确率；结构化抽取看字段级准确率、Schema有效性和缺字段率，仅通过合法JSON校验不代表字段值正确；问答任务看任务成功率或评分量表，词重叠不能等同于正确性。
文章还列出摘要、RAG、编码、Agent和创意内容的主指标：摘要看覆盖度和事实一致性，RAG看答案正确性、有据性和检索召回率，编码看测试通过率和回归率，Agent看最终状态成功、工具调用有效性、策略合规、恢复率、延迟和成本。文章称，如果改进某个指标不会让应用更有用、更安全、更快或更便宜，它可能不该作为发布指标。
接受运行率与评分量表
对于确定性任务，文章给出计算公式：接受运行率 = 被接受的运行次数 ÷ 尝试运行总次数。文章明确，不应因为格式错误、超时或工具失败难以评分就将其排除在分母之外；如果用户会将其视为任务失败，通常应计入。
开放式任务需要评分量表。文章建议按正确性、完整性、相关性、指令遵循、有据性、语气或风格、安全等维度分别定义通过条件或评分锚点，并说明什么证据区分 3 分与 4 分，以及哪些错误导致直接失败。对于Agent工作流，文章建议同时检查执行轨迹和最终结果，因为Agent可能声称已退款或已更新文件，而底层状态并未改变。
测试集来源与评分方式
文章建议测试集从四类来源构建：有实际使用量的常见生产任务、与收入或信任相关的高影响工作流、涉及异常格式或冲突指令的边缘案例，以及来自工单、日志和人工测试的已知失败。每个测试用例应包含足够信息以复现和评分。
评分方法按成本和适用性组合：精确匹配或正则用于标签和固定格式，Schema校验用于JSON结构，单元或集成测试用于代码和状态变更，规则检查用于长度和禁用内容，LLM评审用于相关性、完整性和风格，人工复核用于模糊、高风险和专家依赖的任务。文章建议先跑确定性检查，无效JSON或未通过单元测试的输出不必再交给LLM评审。
文章提醒LLM评审可能存在位置偏差，重要的成对比较应交换顺序各跑一次，并调查顺序改变后结论反转的结果。人工评审应用于校准自动评分，上线后继续抽样，尤其是新失败类别和高影响任务。
公平对比与成本口径
文章列出公平对比中应保持一致的要素：系统和用户提示词、提供的上下文、工具定义、检索结果、最大输出限制、超时策略、重试策略、测试用例顺序、评分逻辑、试验次数和并发条件。文章称，应使用硅基流动模型列表接口返回的ID填充评估配置，因为模型名称、支持的参数和可用版本可能因上游开发者、硅基流动、其他API提供商和自托管部署而异。
文章建议不要为了请求体一致而强迫所有模型使用不支持的参数，应保持受支持的设置一致，并记录必要的模型特定差异。由于输出不确定，应运行多次试验，并交错运行不同模型，而非跑完一个模型再跑下一个。文章还提醒SDK级自动重试可能把多次物理请求藏在一条记录背后，受控测试中应禁用自动重试或逐次记录。
成本方面，文章给出按百万token计价时的单次请求成本公式，以及每次接受任务成本 = 所有尝试运行的总成本 ÷ 被接受的运行次数。总成本应包含失败尝试、重试、无效输出、评分调用、检索和付费工具使用；若没有一次运行被接受，该指标为未定义，应报告总花费和零次接受，而非写成零成本。
发布阈值与重跑条件
文章建议在查看最终模型对比前定义发布门槛，示例包括：关键任务失败为零、总体接受运行率达到产品目标、已知回归案例零失败、p95端到端延迟在应用限制内、每次接受任务成本在运营预算内、人工与LLM评审一致率达到校准目标、安全或策略违规在批准风险限内。文章反对把严重回归藏进一个加权总分，也建议按任务组分别报告胜负、平局、失败和未评分案例的数量。
文章列出触发重跑评估的变更：模型或部署、系统提示词、用户提示词模板、采样或推理设置、检索流程、工具定义、输出Schema、护栏、SDK或编排代码、重试超时或路由逻辑。文章还区分能力测试集与回归测试集，前者包含困难任务以发现改进空间，后者保护已有行为并通常采用更严格的发布阈值。