大模型产品评估，别把调用量当成效果
1. 实验室评测偏差与真实生产环境的工程痛点
在大模型应用的产品化落地过程中，离线评估指标与在线生产表现之间常常存在偏差。例如在离线测试中，意图识别准确率或 RAG 检索匹配度达到较高指标，但在真实生产环境中，用户满意度却不如预期，频繁反馈回答偏离实际业务诉求。
造成离线与在线指标失真的主因在于：传统评测数据集往往基于结构完整、标准且无歧义的文本样本，而生产环境中的真实用户请求通常夹杂着口语化表达、多诉求混合以及错别字。此外，若仅将“大模型成功输出文本”作为任务完成的评估标准，容易忽略业务层面的单任务完成率（Task Success Rate）。
在大模型产品化推进中，必须构建包含格式拦截、成本控制与语义打分的离线评测集与数据评估体系。
2. 指标拆解维度：从 Token 成本效率比到单任务完成率（Task Success Rate）
大模型应用落地评估需要由纯学术指标（如 BLEU、ROUGE）转向工程与商业双轮驱动的量化体系。评估指标可拆解为三个核心层级：
第一层是北极星指标：单任务完成率（Task Success Rate, TSR）。指用户发起的一次会话中，AI 是否在无需人工客服接入的情况下完整执行了业务动作（如成功提交退款单、重置密码或完成预订）。若核心业务任务未成功闭环，则文本生成的流畅度不能单独作为成功依据。
第二层是成本效率比指标：Cost Per Successful Task (CPST)。评估时需综合考量效果与计算成本，计算公式为：
$$\text{CPST} = \frac{\text{周期内 API 总消耗成本}}{\text{周期内成功完成的业务任务总数}}$$
若模型升级导致单次任务消耗的 Token 费用大幅增加，而 TSR 指标提升极小，则该升级从商业 ROI 视角看属于负向收益。
第三层是工程鲁棒性指标：格式合规率与防御成功率。包括 JSON 工具调用的 Schema 匹配率、对非法违规问题的拦截准确率以及 Prompt 注入攻击的防御成功率。
3. 生产级 Python 离线评测与 ROI 自动化计算框架
以下是一套用于 CI/CD 流水线的 Python 自动化离线评测脚本。集成了基于规则的 Schema 强校验、LLM-as-a-Judge 语义打分以及 CPST 成本计算逻辑：
import json import os import time from typing import List, Dict, Any from dataclasses import dataclass @dataclass class TestCase: case_id: str input_prompt: str expected_action: str gold_answer_keywords: List[str] class LLMRoiEvaluator: def __init__(self, prompt_cost_per_1k: float = 0.0015, completion_cost_per_1k: float = 0.002): self.prompt_cost_per_1k = prompt_cost_per_1k self.completion_cost_per_1k = completion_cost_per_1k def mock_llm_app_call(self, prompt: str) -> Dict[str, Any]: """模拟待测试的大模型应用链条返回""" return { "output_text": "已为您成功发起退款申请，退款工单号：RF-20260818-092。请在 3 个工作日内查看账户。", "executed_action": "refund_order", "prompt_tokens": 450, "completion_tokens": 85, "latency_ms": 1240 } def evaluate_rule_based(self, response: Dict[str, Any], test_case: TestCase) -> float: """规则维度评估：动作匹配度与关键词命中率""" score = 0.0 # 1. 业务动作匹配 if response.get("executed_action") == test_case.expected_action: score += 0.5 # 2. 核心关键词命中检查 output_text = response.get("output_text", "") hit_count = sum(1 for kw in test_case.gold_answer_keywords if kw in output_text) if test_case.gold_answer_keywords: score += 0.5 * (hit_count / len(test_case.gold_answer_keywords)) return score def calculate_cost(self, prompt_tokens: int, completion_tokens: int) -> float: """计算单次 API 调用的成本(元)""" cost = (prompt_tokens / 1000.0 * self.prompt_cost_per_1k) + \ (completion_tokens / 1000.0 * self.completion_cost_per_1k) return round(cost, 6) def run_eval_suite(self, test_cases: List[TestCase]) -> Dict[str, Any]: total_cases = len(test_cases) successful_tasks = 0 total_cost_yuan = 0.0 total_latency_ms = 0.0 results = [] for case in test_cases: resp = self.mock_llm_app_call(case.input_prompt) score = self.evaluate_rule_based(resp, case) cost = self.calculate_cost(resp["prompt_tokens"], resp["completion_tokens"]) total_cost_yuan += cost total_latency_ms += resp["latency_ms"] is_success = score >= 0.8 if is_success: successful_tasks += 1 results.append({ "case_id": case.case_id, "score": score, "is_success": is_success, "cost_yuan": cost, "latency_ms": resp["latency_ms"] }) tsr = (successful_tasks / total_cases) * 100.0 if total_cases > 0 else 0.0 cpst = (total_cost_yuan / successful_tasks) if successful_tasks > 0 else 0.0 avg_latency = total_latency_ms / total_cases if total_cases > 0 else 0.0 return { "summary": { "total_cases": total_cases, "successful_tasks": successful_tasks, "task_success_rate_percent": round(tsr, 2), "total_cost_yuan": round(total_cost_yuan, 4), "cost_per_successful_task_yuan": round(cpst, 4), "avg_latency_ms": round(avg_latency, 2) }, "details": results } if __name__ == "__main__": benchmark_dataset = [ TestCase( case_id="TC-001", input_prompt="我不想要这个商品了，赶紧退款", expected_action="refund_order", gold_answer_keywords=["退款", "工单号"] ), TestCase( case_id="TC-002", input_prompt="怎么修改收货地址？", expected_action="update_address", gold_answer_keywords=["修改", "地址"] ) ] evaluator = LLMRoiEvaluator() report = evaluator.run_eval_suite(benchmark_dataset) print(json.dumps(report, indent=2, ensure_ascii=False))4. 数据口径收口：剔除无效重试与防御性 Prompt 的统计噪音
评估大模型 ROI 时，需统一数据统计口径，避免数据统计失真。
数据流水线中需执行三项清洗约束：
第一，剔除无效重试导致的 Token 膨胀。因网络超时或 JSON 格式错误引发的二次重试，其消耗的 Token 属于工程故障损耗，不应计入业务任务的有效 Token 投入。在计算 CPST 时，该部分成本需归类至故障损耗池单独监控。
第二，防范 System Prompt 膨胀统计陷阱。当向 System Prompt 不断追加规则约束时，每次 Prompt 的冷启动 Token 显著增加。若仅统计 Completion Token，会掩盖整体成本上涨。统计口径需包含 Prompt Token 的全量复用开销。
第三，建立黄金评测集的更新机制。离线评测集需要动态维护。定期从生产日志中脱敏抽样失败 Case（即 Task Success Rate 为 0 的会话），经校验审核后标记入库，确保 Benchmark 数据能够反映真实应用场景。
5. ROI 优化法则：效果与成本平衡策略
大模型产品化的核心在于寻找效果与成本的科学平衡点。工程实践中包含三项优化策略：
- 模型分级路由（Model Routing）：针对简单意图与结构化提取任务，采用轻量级模型或较低成本的 API；仅在检测到复杂逻辑推理需求时，才切流至高阶大模型。
- Prompt 瘦身与语义缓存：利用 Redis 或 Milvus 对高频常见问题构建 Semantic Cache（语义缓存）。当输入问题的向量相似度高于设定的阈值（如 0.96）时，直接返回缓存结果，降低 API 调用开销。
- 发布门禁集成：将 Task Success Rate 和 CPST 纳入 CI/CD 发布门禁。当新版本未能满足设定的成本降低或完成率提升目标时，禁止自动上线部署。
