企业官网建设流程全解析

Glean 分析 37 个模型在企业任务上的性价比，这件事之所以在企业 AI 圈里引起讨论，不是因为它列出了一张排行榜，而是因为它把模型选型从“谁的分数高”拉回到“谁在真实业务里更划算”。企业场景里，无论你是做文档问答、客服工单自动分类，还是构建内部知识搜索，都会遇到同样的问题：几十个模型摆在面前，质量、速度、成本、上下文长度都不一样，到底该选哪一个？本文不依赖 Glean 的内部数据，而是从工程实践的角度，把这套评估方法拆解成可复现的流程。读完你会得到一套能直接落地的评估框架：如何构造企业任务评测集、如何定义质量分、如何算性价比、如何批量跑完几十个模型、如何根据结果做选型。

1. 企业任务为什么不能直接照搬公开榜单选模型

很多团队选模型时，第一反应是打开某个公开基准榜单，按分数从高到低选。这种做法在个人项目里没有问题，但放到企业任务上，往往会在上线第一周就暴露出各种问题。

1.1 公开基准和企业任务的目标不一致

公开基准如 MMLU、HumanEval、GPQA 等，衡量的是模型在知识问答、数学推理、代码生成上的通用能力。这些题目通常有明确答案，评测方式也比较直接。企业任务则完全不一样，它们是窄而具体的：从合同里抽取付款周期，把客服工单分到二十个业务类别里，从企业知识库中检索再生成一段可发布的摘要，甚至在收到用户指令后调用 CRM 系统完成一次查询。

这些任务对三件事极度敏感：输出格式、业务术语、交互流程。榜单分数高不代表模型能在你的数据上稳定输出合法 JSON，也不代表它的延迟能满足客服系统几秒内的体验要求。比如一个模型在通用问答上表现很好，但给定一段包含大量公司缩写和内部产品名称的文本时，可能把字段名抽错，或者把金额和日期混在一起。这类问题只有用真实业务样本才能发现。

1.2 性价比评估要同时看四个维度，而不是只看价格

企业场景里选模型，至少要从质量、延迟、成本、上下文与能力边界四个维度一起看。

这四个维度会互相制约。一个支持 200K 上下文的长文本模型可能价格更高，但如果它能一次处理完整合同，就省去拆分成多段、多次调用和拼接的工程成本。一个速度快的小模型如果在新术语抽取上频繁出错，就会把节省下来的模型成本转移到人工修正上。因此，性价比不是“最便宜的模型得分最高”，而是“在满足质量阈值和延迟约束的前提下，单位成本带来的有效质量提升”。

1.3 评测候选集要分层，不必一开始就让 37 个模型全部跑完

实际评测时，先按硬性条件做一轮粗筛，能显著节约时间和 API 费用。第一轮按上下文长度过滤，输入任务最长的样本超过模型窗口的，直接排除。第二轮按结构化输出能力过滤，不支持 JSON、工具调用或返回格式不稳定的模型，要慎重评估。第三轮按单次调用成本过滤，如果某个模型处理单任务的预估成本已经高于人工处理费用，除非质量有压倒性优势，否则没有必要进入完整评测。

粗筛之后，通常能剩 10 到 15 个模型，再进入完整评测。Glean 这类平台在分析 37 个模型时，覆盖范围很大，但落到具体业务选型时，深度评测的模型数量往往会少很多。用分类筛选代替一次性穷举，既可以让结果表格更聚焦，也可以让每一笔评测费用都花在真正有希望的候选模型上。

2. 准备评测环境和测试集：先定义“企业任务”是什么

评测环境不需要复杂，但数据集和记录字段要提前设计好。否则模型跑完一轮后，手里只有一堆原始输出，很难继续聚合和分析。

2.1 按业务场景拆解评测任务类型

同一个模型在不同任务上的表现差异可能很大，所以评测集不能只有一种任务。比较常见的任务类型包括：

• 文本分类：意图识别、工单分类、内容安全审核。
• 信息抽取：合同要素抽取、简历字段抽取、实体识别。
• 结构化生成：将用户指令转换为 JSON、SQL 或查询条件。
• 问答与检索增强生成：基于企业内部知识库回答，要求答案有依据。
• 工具调用：根据对话内容决定是否调用某个 API，并生成正确的参数。
• 文本摘要与改写：生成周报摘要、会议纪要和对外回复。

实际项目中，可以从每个任务类型里抽 30 到 50 条真实样本，至少覆盖 5 到 8 个任务类型。样本不足会导致结果波动很大，一次跑分跑完，换个批次数据结论就变了。不要在一开始追求样本量大，先把任务覆盖面做起来。

2.2 评测数据集使用 JSONL 格式，保持字段可扩展

一条评测样本通常包含任务标识、输入内容、期望结果和可选约束。下面是两个示例：

{"task": "intent_classification", "input": "我要查一下上个月的发票", "expected": "invoice_query"} {"task": "contract_extraction", "input": "合同编号 HT-2025-001，甲方为北京某科技有限公司，付款周期为收到发票后 30 个工作日", "expected": {"contract_id": "HT-2025-001", "payment_terms": "30 work days"}}

把 expected 字段和 input 字段分开，后续可以做自动比对。如果需要判断模型是否遵守格式要求，还可以增加required_format字段，比如json、plain_text、single_label。评测程序读入这个 JSONL 文件后，会按照 task 字段切分数据集，再逐个模型运行。

2.3 环境准备：使用 LiteLLM 统一调用多个模型

常见模型接入方式有两种：一是针对每个模型单独安装官方 SDK，二是使用 LiteLLM 这类统一调用层。推荐后者，因为评测脚本可以保持同一套接口，切换模型只改配置，不用重写代码。环境准备命令如下：

python -m venv .venv source .venv/bin/activate pip install "litellm>=1.40" pandas python-dotenv

创建.env文件，把不同服务商的 API Key 放进去，LiteLLM 会自动读取：

OPENAI_API_KEY=sk-xxx ANTHROPIC_API_KEY=sk-xxx TOGETHER_API_KEY=xxx

这里要注意一点：不同模型提供商的 API 兼容程度不一样，即使使用 LiteLLM，也需要在评测脚本里记录上报的 usage 字段是否完整。如果某个 provider 不返回 token 数，就必须用其他方式补全，否则成本计算会失真。

2.4 每条评测记录要留下这些字段，后面聚合才不返工

评测过程中把原始输出和计算指标一起落盘，是最容易被忽略的基础设施。推荐每次调用返回后记录以下字段：

把这些字段写入 CSV 或 JSONL 文件，后续用 Pandas 聚合时会非常方便。如果一开始只保存 output，后面再想统计 token 消耗，就不得不重新调用模型，既浪费钱又浪费时间。

3. 定义质量评分和性价比公式：指标先于测试运行

跑分之前，先定义清楚“好”和“划算”是什么。没有评分标准，模型把 JSON 字段抽错、但文本上看起来相似时，你无法判断它算对还是算错。

3.1 质量评分使用三种方式组合，不要只用一种

质量评分可以分成自动评分和人工评分两层。对于分类、抽取这类有确定性答案的任务，使用精确匹配或规则匹配。

def is_exact_match(expected, output): if isinstance(expected, dict): try: parsed = json.loads(output) return parsed == expected except json.JSONDecodeError: return False return str(output).strip() == str(expected).strip()

对于摘要、问答这类没有唯一答案的任务，可以使用 LLM-as-judge，让一个强大的评审模型按评分规则打分。评分 Prompt 需要说明任务定义、期望输出、评分维度和分数范围。

你是一个评分员。请根据以下任务定义判断模型输出是否满足要求。 任务：从合同文本中抽取合同编号和付款周期。 输出必须是 JSON，包含 contract_id 和 payment_terms。 评分规则： - 5分：两个字段都正确，格式合法 - 3分：字段基本正确，但格式不完整或值有轻微偏差 - 1分：字段缺失或抽取明显错误 - 0分：无法解析或完全没有抽取

自动评分跑完后，每类任务还要抽 20 条左右做人工复核。人工复核的主要目的是检查自动评分是否公平。比如模型输出把“30 个工作日”写成了“30 workdays”，自动匹配可能判错，但对业务来说可能是可以接受的等价表达。用抽检结果修正评分口径后，再回到自动评分脚本里更新规则。

3.2 成本计算不能只比单价，要比“单次任务的实际成本”

模型按 token 计费，价格通常以每百万 token 为单位。单次任务成本需要结合输入长度、输出长度、缓存命中和重试次数一起估算。

cost_per_task = ( (prompt_tokens_avg * input_price + completion_tokens_avg * output_price) / 1000000 ) cost_per_1k_calls = cost_per_task * 1000

为什么用千次调用而不是单次？因为单次成本数值太小，不同模型之间的差距不够直观。按千次调用计算，便于直接对比预算影响。下面是一个价格示例，实际价格会随接入渠道和时间变化，评测前要以当前账单为准：

如果平台提供 prompt 缓存，命中缓存的输入 token 单价可能只有普通输入的五分之一。评测脚本里要区分prompt_tokens_cached和prompt_tokens_uncached，否则成本可能被高估。重试请求的成本也要计入，不能只看成功请求。

3.3 性价比公式要包含质量阈值和延迟约束

性价比不能直接写成“分数除以价格”然后排序，因为一个质量特别差的模型可能因为极低的成本排到第一名。推荐先按业务要求设定质量阈值和延迟阈值，再计算性价比。

quality_score = 100 * correct_cases / total_cases cost_per_1k_calls = 实际成本模型聚合结果 latency_p95 = 对延迟数据取 95 百分位 if quality_score < quality_threshold: # 例如 80 value_score = 0 elif latency_p95 > latency_threshold: # 例如 3000ms value_score = 0 else: value_score = quality_score / cost_per_1k_calls

这个公式把不达标模型的性价比直接置 0，避免它们出现在候选列表里干扰决策。质量阈值和延迟阈值需要业务方和研发方一起定，不能只由算法团队拍脑袋。质量阈值定低了，模型错误会被业务放大；阈值定高了，可能会排除掉成本优势明显、只需要少量规则兜底就足够好的模型。

3.4 关键参数调整对照表

这些参数不是一次性固定的。随着业务语料变化、模型升级，评测参数和阈值需要重新审视。评测本身不是一次性的项目，而是一条持续运行的流水线。

4. 批量跑懂 37 个模型：搭建最小可复现的评测脚本

完成数据集和指标定义后，接下来是让评测脚本跑起来。核心目标不是写出复杂的分布式框架，而是用一个稳定、可复现的脚本完成几十个模型的批量评测。

4.1 候选模型清单使用 YAML 管理

把候选模型按统一配置文件管理，脚本读配置后逐个执行。这样新增模型时不需要改代码，只改 YAML。

models: - name: gpt-4o provider: openai context_window: 128000 max_output_tokens: 4096 - name: claude-3-5-sonnet provider: anthropic context_window: 200000 max_output_tokens: 4096 - name: llama-3.1-70b-instruct provider: together context_window: 128000 max_output_tokens: 2048

这里的模型名称只是示例，实际评测时要换成当前可用的模型标识。注意 context_window 和 max_output_tokens 会影响评测策略：输入样本不能超过窗口，输出上限也不能太小，否则长摘要任务会截断。

4.2 评测脚本核心实现：逐模型、逐样本运行并记录结果

Python 脚本核心逻辑如下。它使用 LiteLLM 统一调用，自动记录延迟、token 和输出内容。

import json import time from pathlib import Path import litellm PROMPTS = { "intent_classification": "请判断用户的意图，只输出一个标签。标签范围：invoice_query, refund_request, other。", "contract_extraction": "请从合同文本中抽取合同编号和付款周期，输出 JSON，包含 contract_id 和 payment_terms 两个字段。" } def system_prompt_for(task): return PROMPTS.get(task, "请根据用户输入完成指定任务。") def load_jsonl(path): with open(path, "r", encoding="utf-8") as f: return [json.loads(line) for line in f if line.strip()] def evaluate_model(model_name, dataset): records = [] for sample in dataset: start = time.time() try: resp = litellm.completion( model=model_name, messages=[ {"role": "system", "content": system_prompt_for(sample["task"])}, {"role": "user", "content": sample["input"]}, ], temperature=0, max_tokens=1024, ) latency_ms = (time.time() - start) * 1000 records.append({ "model": model_name, "task": sample["task"], "expected": json.dumps(sample["expected"], ensure_ascii=False), "output": resp.choices[0].message.content, "prompt_tokens": resp.usage.prompt_tokens, "completion_tokens": resp.usage.completion_tokens, "latency_ms": latency_ms, "error_type": "", }) except Exception as exc: records.append({ "model": model_name, "task": sample["task"], "expected": json.dumps(sample["expected"], ensure_ascii=False), "output": "", "prompt_tokens": 0, "completion_tokens": 0, "latency_ms": -1, "error_type": type(exc).__name__, }) return records

这段代码有几个关键点。temperature 固定为 0，是为了让评分可复现。latency_ms 是在客户端计算的，包含网络和排队时间，能比较真实地反映调用体验。error_type 记录异常类型，后续可以区分是限流、超时还是 provider 返回错误。

实际公司内部评测通常不会一个文件跑全 37 个模型，因为耗时太长、成本也高。可以加一个--models参数，只跑本轮需要验证的模型集合。推荐把评测脚本做成命令行工具，支持传入模型列表、数据集路径和输出路径。

4.3 聚合结果：计算准确率、成本、延迟和性价比

评测得到原始记录后，下一步是聚合。Pandas 可以快速完成按模型、按任务的聚合。

import pandas as pd def aggregate_results(records, pricing): df = pd.DataFrame(records) df["quality_pass"] = df.apply( lambda r: is_exact_match( json.loads(r["expected"]), r["output"] ), axis=1 ) quality = df.groupby("model")["quality_pass"].mean() * 100 total_tokens = df.groupby("model").agg( prompt_tokens=("prompt_tokens", "mean"), completion_tokens=("completion_tokens", "mean"), ) latency_p95 = df.groupby("model")["latency_ms"].quantile(0.95) summary = pd.DataFrame({ "quality": quality, "p95_latency_ms": latency_p95, }).join(total_tokens) summary["cost_per_1k_calls"] = ( ( summary["prompt_tokens"] * pricing["input_price"] + summary["completion_tokens"] * pricing["output_price"] ) / 1000000 ) * 1000 summary["value_score"] = summary.apply( lambda r: r["quality"] / r["cost_per_1k_calls"] if r["quality"] >= 80 and r["p95_latency_ms"] <= 3000 else 0, axis=1 ) return summary.sort_values("value_score", ascending=False)

这段代码里的 is_exact_match 需要根据任务类型做扩展，否则 JSON 字段顺序不同就可能误判。聚合结果导出到 CSV，再用 Excel 或 BI 工具查看即可。

4.4 结果表格怎么读：不要只看一个综合排序

聚合后你会得到类似下面的结果，这里只是说明结构，数据是模拟的：

按照 value_score 排序，model-f 排在前面，但它的质量只有 87，如果业务要求必须在 90 分以上，它就不能被选为默认模型。因此结果表要保留质量、延迟、成本三个字段，而不是只输出一个性价比列。决策时，先根据业务约束把不达标模型删掉，再在达标集合里选择性价比最高的。

5. 结果分析和选型：从 37 个模型收敛到 5 个以内

跑完评测只是第一步，更关键的是从结果中提炼出可以执行的选型结论。

5.1 先设质量红线，再按性价比排序

推荐做法是画一条质量红线。比如分类任务准确率低于 85% 的模型直接不进入候选，抽取任务解析失败率高于 10% 的模型直接不进入候选。通过红线筛选后，剩下的模型通常不会太多。这样做的好处是避免“一个综合分数很高的模型，在关键字段上偏偏总是抽错”这样的陷阱。

在没有质量红线的情况下，一个成本极低的模型很容易因为性价比公式排到前面，但它可能在 5% 的关键任务上出现严重错误。对企业系统来说，5% 的错误率放到每天十万次调用里就是五千次故障，会造成大量人工干预或客诉。所以性价比排序只适用于“已经通过质量红线”的模型。

5.2 按任务维度分模型，避免一刀切

单一模型很难在每个任务上都做到最佳。实际评测常常会出现这种情况：模型 A 在分类任务上准确率最高，模型 B 在抽取任务上格式最稳定，模型 C 在摘要任务上人工评分最高。如果只选一个默认模型，会导致一部分任务长期运行在次优状态。

生产系统可以采用模型路由：根据任务类型把请求分发到不同模型。路由规则可以写得很简单，先用 YAML 配置支持矩阵，再让网关根据 task_type 选择模型。评测的粒度越细，路由规则就越有依据。

5.3 从 37 个模型得到 5 个候选的典型过程

一个典型的收敛路径是：初始 37 个模型，按上下文长度过滤掉 8 个，按结构化输出能力过滤掉 6 个，按成本过滤掉 7 个，剩余 16 个进入完整评测。完整评测后，质量红线筛掉 7 个，延迟约束筛掉 3 个，最后剩余 6 个。在这 6 个里，按性价比排序取前 5 个形成候选池，再根据任务维度细分到不同业务线。

这个过程说明，评测结果不是简单的“第一名赢家通吃”，而是给你一份候选池和一套约束条件。最终选型时要结合团队运维能力、模型供应商稳定性、数据合规要求做进一步判断。

5.4 长尾任务对综合性价比的影响

汇总到模型维度时，长尾任务往往会拉低平均分。比如某个模型在主流任务上表现很好，但处理几十条样本里只出现一次的特殊格式时结构化输出失败，平均分就被拖下来。这时候不要急着否定它，而是看长尾任务是否可以通过少量提示词优化或规则修正兜底。如果主流任务带来的成本节省远大于长尾任务的处理成本，这个模型仍然有选型价值。反过来，如果长尾任务出现在核心链路，且没有兜底方案，那么即使综合性价比很高，也要谨慎使用。

6. 常见问题排查：评测结果不可信时从哪一层查起

模型评测会踩很多坑。这里列出四个高频问题，每个问题都按现象、原因、检查方式、解决方案展开。

6.1 模型返回格式不稳定，JSON 解析经常失败

现象是同一个模型有时候返回完整 JSON，有时候返回带说明文字的文本，导致评测脚本中json.loads报错。

原因通常是模型本身能力不足，或者是 System Prompt 没有明确指定输出格式，又或者温度设置太高导致格式漂移。检查方式是打印原始输出，统计解析失败样本，看是否集中在某些任务类型上。解决方案是把格式要求写进 Prompt，优先使用模型厂商提供的 JSON Mode 或结构化输出能力。评测脚本里还要实现降级解析，比如用正则截取第一个{到最后一个}之间的内容，尽量提升格式兼容性。

6.2 LLM-as-judge 评分不稳定，重复评测结果不同

现象是同一个模型输出，让评审模型连续打两次分，分数差异很大。原因通常是评审 Prompt 不清晰，或者评审模型 temperature 不为 0。检查方式是固定评审模型版本、温度设为 0，再对同一批样本跑两次，观察分数波动。解决方案是增加评分尺度的说明，提供正面和负面示例，并引入多数投票观点。评审模型分数无法作为最终结论时，人工抽检就是最后一道防线。

6.3 token 统计误差导致成本计算偏低或偏高

现象是评测得出的成本与月底账单对不上。原因可能是某些 provider 未返回 usage 字段，也可能是 prompt 缓存命中导致实际计费低于普通输入，又或者是评测脚本没有统计重试请求。检查方式是打印每个 provider 返回的 usage 原始结构，和账单里的 token 消耗对比。解决方案是在代码里区分缓存 token 和普通 token，并统一记录所有重试请求。对于不返回 usage 的模型，需要在配置中手动估计 token 数，或者接入网关侧的统一计量。

6.4 评测集泄露或评测集过拟合，线上效果不及预期

现象是评测时模型分数很高，上线后面对真实流量效果明显变差。原因可能是评测样本与训练数据重叠，也可能是团队反复用同一批评测样本调 Prompt，把指标调到虚高。检查方式是核对评测样本是否来自公开数据集，确认是否被反复使用。解决方案是保留一个独立的 hold-out 集，只在最终验证时使用一次。生产上线后，定期从线上日志抽取新样本回流评测集，让评测集持续更新。

7. 最佳实践与可复用清单

7.1 评测上线前检查清单

每次启动一轮完整评测前，按下面的清单过一遍，能避免大多数返工：

• 每个任务类型至少准备 20 条真实样本，优先从线上日志和业务标注数据中抽取。
• 明确每条样本的expected字段，区分精确答案和开放性答案。
• 固定 Prompt 模板和评分规则版本，代码仓库里保留配置文件的提交记录。
• 固定生成参数，尤其是 temperature、max_tokens。
• 记录原始输出、解析结果、token 数、延迟和异常类型。
• 确认各模型的价格配置与当前账单一致，含缓存计费规则。
• 明确质量阈值和延迟 SLA，并把它们写进聚合脚本。
• 先在小样本上跑通脚本，确认字段完整后再扩展全量任务。

7.2 做性价比评估最容易踩的 3 个坑

第一个坑是只比较模型单价，不看 token 消耗差异。同一个任务，模型 A 可能平均输出 300 token，模型 B 输出 600 token。模型 B 单价低但输出更长，总成本可能反而更高。正确做法是用评测结果里的平均 token 消耗乘以单价，计算单次任务实际成本。

第二个坑是把平均准确率当成唯一质量指标，忽略格式错误率。企业任务里，一次 JSON 解析失败意味着需要重试、人工修正或丢弃，真实成本远高于一次普通错误。质量指标里必须包含parse_success和execution_success，而不是只看内容匹配。

第三个坑是评测集太小或分布失衡。只用 10 条样本判断一个模型，或者 90% 样本来自同一个任务类型，都会让排序结果不可靠。建议每类任务至少 30 条样本，并通过多次运行观察模型的分数波动范围。

7.3 生产环境模型路由的落地建议

评测选型完成后，不一定要把全部流量切到一个模型。可以在生产系统中加入简单的模型路由，按任务类型分发请求，同时保留备用模型。路由配置可以放在 YAML 文件里，示例：

routing: intent_classification: primary: model-f fallback: model-d contract_extraction: primary: model-d fallback: model-f summarization: primary: model-a fallback: model-d

路由规则上线前，要先对每个路由组合做一次小流量回归，确认目标模型的输出格式、延迟和错误率与评测时一致。当主模型发生故障或响应超时时，自动切到备用模型。这样可以兼顾质量和成本，也可以降低单一模型供应商带来的风险。

7.4 从一次性评测升级为持续评测

模型能力更新速度很快，评测结果的有效期通常只有几个月。建议把评测脚本接入 CI/CD 流水线：每当有新的模型版本上线，或者新增业务任务时，自动跑一轮关键任务评测。评测结果写入内部看板，供算法团队和业务方一起决策。持续评测的意义不只是省掉重复劳动，更是让模型选型从“凭感觉”变成“看数据”。当系统积累几轮评测结果后，你会更清楚哪些模型变化会带来影响，以及哪些任务需要设置更高的质量底线。

如果下一次又有一个新的模型版本发布，或者看到一份新的多模型评测报告，完全不需要重头开始。你只需要把新模型加入候选配置，跑一遍已经定义好的评测集，更新成本单价，新的性价比表格就会自动生成，所有选型决策也就有了新的依据。