企业大模型选型怎么做？从Glean 37模型评测到可复现的评估流程

大模型选型模型评测RAG

于 2026-08-29 04:08:20 修改

·本内容遵循CC 4.0 BY-SA版权协议

如果只看各家大模型的在线排行榜，企业很难做出选型决策。Glean 这次把 37 个模型放到企业真实任务场景里做对照分析，思路比单纯刷分更值得关注。Glean 本身做企业知识检索和内部智能问答，它的评测标准更接近工作流里的实际使用方式：检索增强问答、长文档总结、结构化抽取、意图分类，这些任务直接决定了模型能不能放进系统里产生价值。对于正在做大模型选型的企业团队来说，这套分析的价值不在具体模型排名，而是它把"性价比"落到了任务权重、延迟、成本和准确率的综合判断上。

本文不打算逐条搬运报告里的分数表，模型版本更新太快，一次快照只能代表当时的结果。重点是把报告背后的评测方法论展开，给出一套可以在自己环境里复现的企业级模型评估流程：任务怎么设计、环境怎么准备、批量评测怎么做、API 怎么并发调用、成本怎么统计、坑在哪里。适合正在做模型选型、准备从单模型演示走向多模型评估的算法工程师和技术负责人。

1. 核心能力速览

Glean 的 37 模型企业任务性价比分析，核心不是"哪个模型最强"，而是"哪个模型在指定任务组合下最值得花钱"。综合评估框架，可以提炼出以下通用能力维度：

能力项	说明
评估对象	约 37 个市场主流模型，同时覆盖通用旗舰模型和轻量任务模型
评估任务	以企业工作流常见任务为主，包括检索问答、文档总结、信息抽取、意图分类等
核心指标	任务准确率、端到端延迟、每百万 token 成本、单位任务成本
关键链路	结合 RAG 上下文回答企业专属问题，考察模型对长上下文的利用能力
结果输出	按任务类型拆分对比，便于按业务权重二次加权
适用场景	企业大模型选型、成本控制、任务-模型匹配、供应商谈判参考
边界说明	评测是一次性快照，模型版本更新、提示词变化、评测集差异都会影响排名

这套框架对企业最有用的地方在于：它把成本放进任务维度看，而不是只看供应商给的 token 单价。同一个模型在简单分类任务上可能轻松达标，在复杂法律文本总结上却会频繁出错；另一个参数更小的模型在分类任务上准确率接近，价格却便宜一个量级。这种差距，只有用真实任务集去跑一遍才能发现。

2. 适用场景与使用边界

企业模型性价比评估的核心适用人群分成三类：

第一类是算法团队，需要在多个模型之间做横向对比，确定主模型和备用模型；第二类是技术负责人，需要根据任务权重和成本预算做决策，回答"哪套方案能支撑当前业务规模"；第三类是平台或 Infra 团队，需要把评测流程固化成工具，让后续新模型发布时能自动跑一遍评估。

适用场景非常明确：企业在做模型选型、模型替换、供应商合同续签、私有化部署预算评估时，都适合用这套任务驱动的方法。它解决的核心问题不是"谁的跑分高"，而是"在同样的业务目标下，谁的单位成本更低、产出更稳定"。

不适合的场景也要说清楚。如果只是做产品原型验证，单个模型跑通即可，不需要投入成本做 37 模型全量对比；如果业务任务非常单一，比如只做短文本情感判断，直接针对这一个任务测试就够了，不需要设计完整评测矩阵。学术研究里追求泛化性指标的做法在这里也不适用，企业更关心特定任务上的稳定性。

合规边界是重中之重。企业评测必然涉及业务数据，测试集如果包含真实用户信息、交易记录或未公开的业务文档，必须确认数据脱敏；用云端 API 评测时，要确认数据是否被供应商用于模型训练；企业内部部署开源模型则要审查开源许可证和商用条款。涉及人脸、语音、个人信息等敏感数据时，先过法务和隐私评估再进入测试流程。所有输出结果在进入生产环境前，需要人工复核和内容安全过滤。

3. 环境准备与前置条件

要在自己环境里复现一套企业模型评测流程，需要准备的环境和工具如下。先说通用依赖，再给一份可直接落地的目录结构。

操作系统建议 Linux 或 macOS。Windows 也能跑，但自托管推理和并发脚本的兼容性需要额外处理。Python 版本建议 3.10 以上，部分推理框架对版本有要求，统一环境能减少问题。如果使用云端模型 API，需要准备供应商的 API Key；如果自托管开源模型，需要准备 GPU 服务器，显存大小取决于模型尺寸。

核心组件清单：

组件	用途	说明
Python 3.10+	评测脚本运行环境	建议用 venv 或 conda 隔离
openai SDK 或等价客户端	调用 OpenAI 兼容接口	同时覆盖云端 API 和本地 vLLM 服务
pandas	结果汇总与统计	按任务、模型、指标聚合
requests	异步请求与日志	配合并发测试使用
vLLM（可选）	本地多模型推理服务	用于开源模型自托管评测
评测数据集	企业任务真实或脱敏样本	每个任务建议 100 条以上
日志目录	记录每次请求状态	排查超时、限流、解析失败

建议在工作目录下按以下结构组织：

TEXT

llm_eval/

├── datasets/ # 评测任务数据集

│ ├── rag_qa.jsonl # 检索问答任务

│ ├── summarization.jsonl # 文档总结任务

│ ├── extraction.jsonl # 信息抽取任务

│ └── classification.jsonl # 分类任务

├── scripts/ # 评测脚本

├── results/ # 评测结果

│ ├── raw/ # 原始响应

│ └── summary/ # 聚合汇总

├── logs/ # 运行日志

└── .env # API Key 等敏感配置

创建虚拟环境：

BASH

python -m venv llm_eval_env

source llm_eval_env/bin/activate

pip install openai pandas requests python-dotenv scikit-learn

如果是自托管模型，还需要准备推理服务。vLLM 是常见选择，它提供 OpenAI 兼容的 API 服务，同样一套 openai SDK 就能叫通，切换成本最低。

4. 安装部署与启动方式

评测脚本本身不需要复杂的部署，核心工作是在本地跑一套批量评测流程。如果你要评测云端 API 模型，准备好 Key 之后直接写脚本调用；如果你要评测本地开源模型，需要先启动一个兼容接口的推理服务。

4.1 本地推理服务启动（可选）

以 vLLM 为例，启动一个 OpenAI 兼容的本地 API 服务：

BASH

python -m vllm.entrypoints.openai.api_server \

--model meta-llama/Llama-3.1-8B-Instruct \

--host 0.0.0.0 \

--port 8000 \

--max-model-len 8192

注意，这里 --model 参数需要替换成实际要评测的模型名称，路径和端口按实际环境调整。启动成功后，会看到服务监听在 http://127.0.0.1:8000 的提示，此时本地的 /v1/chat/completions 接口已经可用。

用 curl 验证服务是否就绪：

BASH

curl http://127.0.0.1:8000/v1/chat/completions \

-H "Content-Type: application/json" \

-d '{"model": "meta-llama/Llama-3.1-8B-Instruct", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 50}'

如果返回包含 choices 字段的 JSON 数据，说明服务正常。显存占用以实际模型大小和推理参数为准，启动前先用 nvidia-smi 查看可用显存。

4.2 评测脚本基础结构

评测脚本的工作流程是：读取评测数据集 -> 按任务构造提示词 -> 请求模型接口 -> 保存原始响应 -> 按规则判定结果 -> 汇总统计。这个流程对云端 API 和本地服务完全一致，唯一的区别是 base_url 和 api_key。

PYTHON

import json

import os

import time

from openai import OpenAI

from dotenv import load_dotenv

load_dotenv()

client = OpenAI(

api_key=os.getenv("OPENAI_API_KEY", "EMPTY"),

base_url=os.getenv("OPENAI_BASE_URL", "http://127.0.0.1:8000/v1"),

)

def chat(model: str, user_prompt: str, system_prompt: str = None, max_tokens: int = 512):

messages = []

if system_prompt:

messages.append({"role": "system", "content": system_prompt})

messages.append({"role": "user", "content": user_prompt})

start = time.time()

try:

response = client.chat.completions.create(

model=model,

messages=messages,

max_tokens=max_tokens,

temperature=0.0,

)

latency = time.time() - start

return response.choices[0].message.content, latency

except Exception as exc:

return f"ERROR: {exc}", None

temperature=0.0 是为了让评测结果尽量可复现。实际请求时，要记录状态码、延迟、返回内容、使用的 token 数，避免只留文字结果而没有过程数据。

5. 功能测试与效果验证

Glean 这类企业任务评测的常见任务类型，可以抽象为四类：检索增强问答、文档总结、信息抽取、意图分类。下面分别给出测试设计、评估方式和判断标准。

5.1 检索增强问答（RAG QA）

RAG 问答是企业里最典型的大模型任务。评测数据不是简单的问题答案对，而是给模型一段上下文、一个基于上下文的问题，要求模型只依据给定上下文回答。这样可以观察模型是否忠实于材料，而不是依赖记忆。

评测输入示例：

JSON

{

"id": "rag_001",

"context": "公司内部报销流程要求员工在出差结束后 5 个工作日内提交差旅报销单，发票需为增值税普通发票或电子发票，超过 30 天未提交需说明原因。",

"question": "员工出差结束后多长时间内必须提交报销单？",

"reference_answer": "5 个工作日内"

}

构造提示词时，把上下文放在问题之前，并明确要求模型只依据上下文回答。判断标准可以从两个维度看：答案是否包含正确信息，回答是否引入了上下文以外的内容。后者在 RAG 场景里同样致命，因为幻觉答案会直接误导业务。

评估方式：对每一题，用规则匹配或人工标注判断回答是否正确，汇总后计算准确率。100 条样本可以先用规则粗筛，再用抽样人工复核。

5.2 长文档总结

企业场景里，会议纪要、合同条款、项目复盘都需要总结。这个任务的评测难点在于，总结没有唯一解，需要同时看内容准确性和格式规范性。

评测输入示例：

JSON

{

"id": "sum_001",

"document": "本次项目周会主要讨论了三项内容：第一，客户端 2.3 版本已经完成内测，计划下周一灰度发布；第二，服务端接口文档需要在本周五前补充完整，特别是支付回调部分；第三，客服反馈上周共收到 23 个订单状态查询问题，建议优化订单详情页展示。",

"instruction": "用 3 条要点总结上述会议内容，每条不超过 30 字。"

}

评估时，先看模型是否遵循输出格式，再看三个要点是否齐全，最后看是否出现原文没有的信息。这一步建议做少量人工复核，因为自动指标容易误判。你可以统计：格式正确率、要点完整率、幻觉出现次数。

5.3 信息抽取

信息抽取是企业工具型场景的基础能力，比如从邮件中抽取客户名称、合同金额、截止日期，从工单中提取问题分类和优先级。这个任务适合做严格自动判定，因为输出有明确的结构。

评测输入示例：

JSON

{

"id": "ext_001",

"text": "请于 2025 年 6 月 30 日前将合同修改意见发送至张三，涉及金额约 15 万元，逾期未反馈视为同意。",

"instruction": "从文本中抽取以下字段：截止日期、联系人、金额、逾期规则。以 JSON 格式输出。"

}

预期输出：

JSON

{

"截止日期": "2025-06-30",

"联系人": "张三",

"金额": "15万元",

"逾期规则": "逾期未反馈视为同意"

}

评估重点是 JSON 可解析率和字段准确率。字段准确率可以逐字段比较，统计每个字段的命中情况。这类任务里，小模型和大模型差距不一定明显，反而是提示词稳定性影响更大，这也是性价比评估的重要发现：简单任务上不一定要用最贵的模型。

5.4 意图分类

意图分类用于客服机器人和工单自动流转。输入一段用户描述，输出预定义的意图标签。这类任务适合直接用准确率评估，也可以顺带对比不同模型的成本差异。

评测输入示例：

JSON

{

"id": "cls_001",

"text": "我上周买的订单到现在还没发货，能帮我查一下吗？",

"label": "查订单进度"

}

评估方式：要求模型输出意图标签，然后与标准标签比对。可以设计一个类目稍多的标签体系，看模型在细分类目上的区分能力。分类任务对模型大小不敏感，但这类任务在企业调用中占比往往很高，成本影响反而最大。

5.5 多模型横向对比

有了分任务的数据集后，就可以按 Glean 思路做多模型对比。将四个任务的数据集分别跑同一个模型，得到该模型的分任务准确率和平均延迟；再换下一个模型，重复整个过程。最后汇总成一张对比表。

PYTHON

import json

from pathlib import Path

tasks = ["rag_qa", "summarization", "extraction", "classification"]

def run_eval(model, datasets_dir="datasets", results_dir="results/raw"):

for task in tasks:

data_path = Path(datasets_dir) / f"{task}.jsonl"

for line in data_path.open():

sample = json.loads(line)

# 构造任务对应的 prompt，这里按任务类型分发

# 请求模型并保存响应

pass

实际实现时需要按任务类型写不同的 prompt 构造和判定函数。保存原始响应时，文件名建议包含模型名、任务名、样本 ID，方便后续复查。

判断评测成功的标准：全部分任务跑完，结果文件完整，每条样本有响应记录，汇总指标可计算。如果某个模型在特定任务上大量超时或返回空内容，需要在汇总表里标注，不能直接去掉，因为稳定性本身就是选型因素。

6. 接口 API 与批量任务

企业评测和单次 demo 最大的区别是批量任务管理。37 个模型、4 个任务、每个任务 100 条样本，意味着上万次请求，必须有并发控制和失败重试机制。

6.1 并发控制

直接 for 循环串行调用，遇到上百条样本就会非常慢。可以用异步客户端做并发，但要同时控制最大并发数，避免触发云端限流，也避免本地服务被打满。

PYTHON

import asyncio

import json

from openai import AsyncOpenAI

async def worker(semaphore, client, model, sample, task, save_path):

async with semaphore:

prompt = build_prompt(task, sample)

try:

response = await client.chat.completions.create(

model=model,

messages=[{"role": "user", "content": prompt}],

max_tokens=512,

temperature=0.0,

)

record = {

"model": model,

"task": task,

"sample_id": sample["id"],

"output": response.choices[0].message.content,

"model_resp": response.model_dump(),

}

with open(save_path, "w", encoding="utf-8") as f:

json.dump(record, f, ensure_ascii=False)

except Exception as exc:

record = {

"model": model,

"task": task,

"sample_id": sample["id"],

"error": str(exc),

}

with open(save_path, "w", encoding="utf-8") as f:

json.dump(record, f, ensure_ascii=False)

async def run_batch(model, samples, task, max_concurrency=8):

semaphore = asyncio.Semaphore(max_concurrency)

client = AsyncOpenAI(api_key="EMPTY", base_url="http://127.0.0.1:8000/v1")

tasks = []

for idx, sample in enumerate(samples):

save_path = f"results/raw/{model}_{task}_{sample['id']}.json"

tasks.append(worker(semaphore, client, model, sample, task, save_path))

await asyncio.gather(*tasks)

并发数先设小一点，比如 8，看服务稳定后再逐步加大。本地推理服务并发过高会拖慢单请求响应，甚至导致 OOM；云端 API 并发过高则容易触发限流，需要参考供应商的速率限制文档。

6.2 结果汇总与成本统计

每一条样本的原始响应里都包含 token 使用量，汇总后可以计算总输入 token、总输出 token、单任务平均 token 数。结合供应商的每百万 token 价格，就能估算各模型的分任务成本。

这套统计的一个关键价值是：找出不同任务的成本差异。同样是处理 1000 条工单，模型 A 可能因为输出更长、需要更多重试而实际成本远高于模型 B，这个数字只看 token 单价是看不出来的。

PYTHON

import json

from pathlib import Path

raw_dir = Path("results/raw")

summary = {}

for raw_file in raw_dir.glob("*.json"):

record = json.loads(raw_file.read_text())

model = record["model"]

task = record["task"]

prompt_tokens = record["model_resp"]["usage"]["prompt_tokens"]

completion_tokens = record["model_resp"]["usage"]["completion_tokens"]

key = (model, task)

if key not in summary:

summary[key] = {"prompt_tokens": 0, "completion_tokens": 0, "count": 0}

summary[key]["prompt_tokens"] += prompt_tokens

summary[key]["completion_tokens"] += completion_tokens

summary[key]["count"] += 1

for (model, task), usage in sorted(summary.items()):

print(model, task, usage)

6.3 失败重试设计

批量任务一定会遇到偶发失败，原因包括网络抖动、云端限流、服务重启、上下文超长。建议在脚本里加两层重试：第一层是网络层快速重试，间隔 2 秒；第二层是整体任务失败后的人工重跑。所有失败样本要单独记录到失败目录，避免混在成功结果里影响统计。

PYTHON

import time

def request_with_retry(client, model, messages, max_retries=3):

for attempt in range(max_retries):

try:

return client.chat.completions.create(

model=model,

messages=messages,

max_tokens=512,

temperature=0.0,

)

except Exception as exc:

if attempt == max_retries - 1:

raise exc

time.sleep(2 * (attempt + 1))

7. 资源占用与性能观察

企业评测不仅要看准确率，还要看资源消耗和响应速度。Glean 这类分析把延迟放进性价比公式是有道理的，因为延迟直接影响用户体验和系统吞吐。

7.1 显存与推理资源

如果使用本地推理，显存是核心瓶颈。同一个模型在不同量化精度下占用的显存差异很大。显存占用可以用 nvidia-smi 观察，重点关注 Memory-Usage 和 GPU-Util 两项。

BASH

watch -n 1 nvidia-smi

启动推理服务后，多跑几条请求，观察显存曲线是否稳步上升后趋于平稳。如果批量并发过程中出现 CUDA out of memory 错误，需要降低并发数、缩短 max_tokens、或者换用更小的量化版本。具体数值依赖模型和量化方案，需要以实际测试为准。

7.2 延迟与吞吐

评测时记录两个时间指标：单请求延迟和端到端吞吐。单请求延迟决定用户体验，端到端吞吐决定批量任务完成时间。对同一模型，测试不同并发数下的吞吐变化，可以找到最佳并发区间，这对后续生产环境参数设置非常关键。

一个常见的性能观察方法是：固定样本集，用不同并发数各跑一轮，记录总耗时和失败率。然后绘制并发数与吞吐的关系曲线。并发过低，GPU 利用率不足；并发过高，延迟急剧增加、失败率上升。这个平衡点就是建议的生产并发参数。

7.3 成本测算

成本测算分为两部分。云端 API 成本按 token 计费，用汇总表的 token 总量乘以单价即可。本地部署成本则包括 GPU 采购或租用费用、电力费用、运维人工成本。评测本身也会产生费用，尤其是反复调试提示词阶段，建议单独记录调试轮次的 token 消耗，避免把评测成本误算入生产预估。

7.4 降低资源占用的通用思路

如果评测过程中遇到显存不足或成本超预算，可以按以下顺序调整：

降低单请求 max_tokens，限制输出长度
缩短输入上下文，去除无关历史消息
降低并发数，避免资源争抢
使用量化版本模型，减少显存占用
先跑小样本集验证流程，再扩展到全量评测集

8. 常见问题与排查方法

企业评测脚本跑起来后，会遇到的问题集中在下面几类。提前准备好排查思路，能省去大量调试时间。

问题现象	可能原因	排查方式	解决方案
本地服务启动失败	端口被占用或模型路径错误	查看启动日志，检查端口占用	更换端口或确认模型路径
API 请求返回 401	API Key 或 base_url 配置错误	检查 .env 文件和环境变量	重新配置 Key，确认接口地址
请求频繁超时	并发数过高或网络问题	查看日志中的超时时间	降低并发数，增加超时时间
批量任务卡住	单条请求没有超时上限	检查是否有请求长时间无响应	为请求设置 timeout，加入重试机制
显存不足	模型过大或并发过高	查看 nvidia-smi 显存占用	降低并发，换用量化模型
输出格式不稳定	提示词约束不够明确	检查模型的原始返回内容	加强格式约束，增加解析后校验
相同输入得到不同结果	采样参数设置不一致	检查 temperature 和 top_p	评测统一设为 temperature=0.0
评测成本超预期	重试次数过多或 context 过长	查看 token 汇总统计	精简提示词，限制上下文长度
结果文件缺失	脚本中途崩溃或有异常未捕获	对比样本数量和结果文件数量	加断点续跑逻辑，记录失败样本
模型输出大量空内容	max_tokens 设置过低	查看原始响应内容	调高 max_tokens

9. 最佳实践与使用建议

企业模型评测不是一次性工作，而应该固化成可重复执行的流程。下面这些建议都来自实际踩坑经验。

第一次跑评测时，先用小样本集验证流程，比如每个任务 10 到 20 条样本，确认脚本、接口、汇总逻辑都正确，再扩展到 100 条以上的完整评测集。不要一上来就跑全量，万一提示词构造有问题，会浪费大量时间和成本。

保留一套最小可运行配置，包括脚本、数据集和启动命令，方便新模型发布时快速跑一轮基线测试。评测数据集要受版本管理，每次调整数据集都要记录变更，否则不同轮次的评测结果没有可比性。

模型文件、评测数据集、原始结果和汇总报告要分目录管理。原始响应是最有价值的数据，不要轻易覆盖；汇总报告是决策依据，需要附带模型版本号、评测日期、数据集版本和提示词版本。

批量任务运行前先检查磁盘空间和日志目录权限。长时间运行的评测任务建议用 nohup 或后台任务方式执行，避免终端关闭导致任务中断。每次运行前记录日志文件路径，出错时便于追溯。

接口服务要限制访问范围，尤其是本地推理服务，不要直接暴露在公网。可以用防火墙限制只允许内网访问，或加一层 API 网关做鉴权。评测脚本里的 API Key 放在环境变量或 .env 文件中，不要硬编码进代码仓库。

企业在评测阶段就要把 AI 内容安全和合规章节纳入流程。如果模型会产生面向客户的输出，需要评估输出内容的合规风险，增加关键词过滤和专业性校验。涉及人脸、声音等个人敏感信息时必须确认授权，涉及版权材料的生成必须控制使用边界。

10. 总结与下一步

Glean 的 37 模型分析提供的核心思路是：企业任务不该用统一的跑分排名去选模型，而应该把任务、成本、延迟三者绑在一起评估。这个思路的价值在于让模型选型从"选最强的"变成"选最合适的"。

如果你准备在企业内部落地这套评估流程，建议按下面的顺序行动：

先定义自己的核心任务列表，不要照搬公开评测集，优先覆盖业务最高频的 3 到 5 个任务类型
每个任务准备 100 条脱敏样本，标注好标准答案或评估规则
选 3 到 5 个候选模型，搭建批量评测脚本，同时记录准确率、延迟、token 消耗
跑完小样本后先看结果，确认任务提示词和判定逻辑没有明显问题，再扩展全量
最后，把评测结果沉淀成一份带版本号的选型报告，作为后续模型更新的对比基线

下一步值得投入的方向是：把评测脚本做成自动化流水线，每次新模型发布或供应商更新版本时自动跑一遍；把成本统计接入企业现有的预算报表，动态追踪不同模型的实际支出。这两件事做好了，企业的大模型选型才算真正从手动测试变成持续可迭代的工程能力。