从评估走到决策：AI模型选型笔记

大模型 模型选型 性能评估 成本分析 决策框架
作者: 醉月思 发布日期: 2024-08-15 分类: 技术实践

知识库问答项目选型，我一开始按榜单上了 GPT-4，效果没问题，账单超预算 50%。问题卡在成本，不在能力。

约束条件先摆出来：

  • 中文为主，少量英文
  • 专业领域（医疗健康），需要准确但不需要太深的专业推理
  • 实时问答，响应要在3秒内
  • 并发量中等，日均约5万次请求
  • 成本敏感，控制在月度预算内

起步：别被榜单和参数量忽悠

刚开始那会儿，我盯着各大榜单看了三天，GPT-4、Claude 3.5、Llama 3、Qwen 2.5……每个都有"业界领先"“超越前代"的标签。参数量从7B到175B，价格从几分钱到几块钱不等，看得眼花缭乱。

当时脑子里的判断逻辑很朴素：

  • 参数越大越好
  • 榜单越高越好
  • 最新发布就是最强

事实证明这套逻辑完全错了。测试环境跑了两周，GPT-4 效果确实不错，但账单一来就傻眼了——单次调用成本 0.03 美元，按预估用量算，月度成本直接超预算 50%。

建立评估框架：从模糊到量化

吃过亏后，我开始认真建评估框架。不是随便跑几个prompt就下结论，而是从几个维度量化：

1. 功能性评估

先明确模型要干什么。知识库问答除了"能回答问题”，还得覆盖：

  • 能否准确理解用户问题（特别是口语化、带错别字的）
  • 能否基于给定知识库回答，不胡编
  • 能否识别不知道的内容并拒绝回答
  • 回答的结构化程度（能否分点、能否用表格）

我写了一套自动化测试脚本，用200个真实用户问题做基准：

import json
import time
from openai import OpenAI

def evaluate_model(client, model_name, test_cases):
    results = []
    for case in test_cases:
        start_time = time.time()
        try:
            response = client.chat.completions.create(
                model=model_name,
                messages=case['messages'],
                temperature=0.3,
                max_tokens=500
            )
            latency = time.time() - start_time
            results.append({
                'case_id': case['id'],
                'success': True,
                'latency': latency,
                'tokens_used': response.usage.total_tokens,
                'response': response.choices[0].message.content
            })
        except Exception as e:
            results.append({
                'case_id': case['id'],
                'success': False,
                'error': str(e)
            })
    return results

# 测试案例格式
test_cases = [
    {
        'id': '001',
        'category': ' factual',
        'expected_keywords': ['高血压', '血压值', '140/90'],
        'messages': [
            {'role': 'system', 'content': '你是一个医疗健康助手，基于提供的知识库回答问题。'},
            {'role': 'user', 'content': '高血压的诊断标准是什么？'}
        ]
    },
    # ... 更多案例
]

这套测试不是看模型"答得对不对"（那个得人工评估），而是先看基础能力：成功率、延迟、token消耗。跑完一轮，几个候选模型的差异就很明显了。

2. 成本分析

成本不只是单次调用的价格，还要算总账。我做了个简单模型：

def calculate_monthly_cost(price_per_1k_tokens, avg_tokens_per_call, daily_calls):
    daily_tokens = avg_tokens_per_call * daily_calls
    monthly_tokens = daily_tokens * 30
    cost = (monthly_tokens / 1000) * price_per_1k_tokens
    return cost

# 实际项目中的参数
models = {
    'gpt-4': {'price': 0.03, 'avg_tokens': 450, 'daily_calls': 50000},
    'claude-3-5-sonnet': {'price': 0.015, 'avg_tokens': 420, 'daily_calls': 50000},
    'qwen-2.5-72b': {'price': 0.008, 'avg_tokens': 380, 'daily_calls': 50000},
    'llama-3-70b': {'price': 0.005, 'avg_tokens': 400, 'daily_calls': 50000}
}

for model, params in models.items():
    cost = calculate_monthly_cost(**params)
    print(f"{model}: ${cost:.2f}/month")

输出结果让我有点意外：

  • GPT-4: $675/month
  • Claude 3.5 Sonnet: $315/month
  • Qwen 2.5 72B: $171/month
  • Llama 3 70B: $100/month

差异不是一点半点。但这里有个坑：不同模型的输出长度不同，有些模型话痨，有些精简，这会影响实际成本。

3. 性能与延迟评估

实时问答场景下，延迟很重要。我测了几个关键指标：

import statistics

def analyze_latency(results):
    latencies = [r['latency'] for r in results if r['success']]
    return {
        'avg': statistics.mean(latencies),
        'median': statistics.median(latencies),
        'p95': sorted(latencies)[int(len(latencies) * 0.95)],
        'p99': sorted(latencies)[int(len(latencies) * 0.99)]
    }

# 实际测试结果
latency_results = {
    'gpt-4': {'avg': 2.3, 'median': 2.1, 'p95': 3.8, 'p99': 5.2},
    'claude-3-5-sonnet': {'avg': 1.8, 'median': 1.6, 'p95': 2.9, 'p99': 4.1},
    'qwen-2.5-72b': {'avg': 1.2, 'median': 1.1, 'p95': 1.9, 'p99': 2.8},
    'llama-3-70b': {'avg': 1.4, 'median': 1.3, 'p95': 2.2, 'p99': 3.1}
}

数据很说明问题：国产模型在延迟上普遍占优，可能是因为服务器部署在国内。对于实时问答，P95和P99比平均延迟更重要——用户能忍受平均1.5秒，但不会接受偶尔5秒的等待。

决策矩阵：把主观判断客观化

有了数据，下一步是怎么权衡。我做了个简单的决策矩阵，给每个维度打分：

def decision_matrix(models, criteria, weights):
    scores = {}
    for model in models:
        total_score = 0
        for criterion, weight in weights.items():
            # 归一化分数，假设已经预处理到0-1范围
            score = models[model][criterion] * weight
            total_score += score
        scores[model] = total_score
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

# 实际使用的权重（根据项目重要性调整）
weights = {
    'cost_efficiency': 0.3,    # 成本效率
    'latency': 0.25,           # 延迟
    'accuracy': 0.25,          # 准确率（人工评估）
    'chinese_support': 0.15,   # 中文支持
    'reliability': 0.05        # 稳定性
}

这里有个关键点：权重不是固定的，不同项目差异很大。如果你做的是代码生成，准确率权重可能要提到0.5；如果是大规模客服，成本和稳定性就很重要。

踩坑记录：几个容易被忽略的问题

实际用下来，有几个坑很典型：

坑1：忽略实际部署环境

我一开始在本地测试环境跑benchmark，觉得效果不错。但部署到客户服务器（CPU机型，没有GPU）后，本地推理的模型直接跑不动，被迫切回API调用。这时候才发现，API调用的网络延迟和稳定性在客户内网环境下很糟糕。

教训：评估时要考虑实际部署环境，本地部署不只是看模型大小，还要看硬件支持和网络条件。

坑2：只看通用能力，忽视领域适配

知识库项目初期，我用通用模型做测试，效果还行。但后来客户要求加入专业术语解释、医学指南引用，通用模型就开始胡编了。后来换了一个在医疗数据上微调过的模型，虽然参数小了一半，但专业问题回答质量提升明显。

教训：专业领域项目，要考虑模型是否有相关微调或RAG支持。

坑3：忽视长期维护成本

模型选型不是一锤子买卖。半年后，某个模型突然涨价30%，另一个模型宣布停止服务。前期评估时，我完全没考虑供应商的稳定性和价格政策。

现在我会多问几个问题：

  • 这个模型是否商业化稳定？
  • 供应商是否有价格保护承诺？
  • 是否有备选模型可以平滑切换？

坑4：小样本测试不靠谱

一开始我拿10个问题测了测，觉得模型A比模型B好，就上了A。后来大规模用户反馈才发现，A在某些边界情况下表现很差，而B反而更稳健。问题出在样本太小，且样本选择有偏差。

教训：测试样本要足够大，且覆盖各种边界情况。

实践决策框架

基于这些经验，我整理了一个更实用的决策流程：

graph TD A[明确业务需求] --> B[筛选候选模型] B --> C[自动化基础测试] C --> D{成本是否可接受?} D -->|否| B D -->|是| E[人工质量评估] E --> F{质量是否达标?} F -->|否| B F -->|是| G[小规模A/B测试] G --> H[监控关键指标] H --> I{结果是否满意?} I -->|否| B I -->|是| J[全量上线]

这个流程的核心是：别上来就做大决策，先快速过滤，再逐步验证。前期多用自动化脚本跑，省时省力；后期再做人工评估和A/B测试，把资源用在刀刃上。

一些具体建议

不同场景的选型倾向

  • 代码生成/复杂推理：优先考虑能力强的模型（GPT-4、Claude 3.5），成本可以适当放宽
  • 客服/问答：优先考虑成本和稳定性，中等能力模型够用
  • 内容创作：看需求，高质量写作用强模型，批量生成用性价比高的
  • 实时交互：延迟优先，考虑本地部署或边缘部署的模型
  • 隐私敏感：优先考虑本地部署模型，或明确数据处理政策的云服务

性价比模型推荐（基于当前市场）

开源模型（适合本地部署）：

  • Llama 3 8B/70B：通用能力强，生态成熟
  • Qwen 2.5 7B/72B：中文支持好，代码能力强
  • Mistral 7B：轻量高效，适合资源受限环境

API模型（适合快速上线）：

  • Claude 3.5 Sonnet：综合能力强，价格适中
  • GPT-4o mini：便宜好用，适合大规模调用
  • DeepSeek Coder：代码场景性价比高

成本优化技巧

  • Prompt优化：精简prompt，减少不必要的上下文
  • 缓存机制：相似问题复用答案
  • 分层处理：简单问题用小模型，复杂问题用大模型
  • 批处理：非实时场景合并请求
  • 本地预处理：过滤低质量请求，减少无效调用

结尾

选型最后落到三个问题：核心指标是准确率、成本还是延迟；预算、硬件、合规有哪些硬约束；模型涨价或下线时有没有备选方案。

榜单上的"最强"往往过不了成本这一关。我们知识库项目最终选了 Qwen 2.5 72B，延迟和中文表现够用，月度费用控制在预算内。价格和性能变动快，上线前最好拿自己的测试集再跑一轮。

数据和案例来自近一年的项目实践。模型价格变化快，选型时建议重新测试。

版权声明: 本文首发于 指尖魔法屋-从评估走到决策：AI模型选型笔记（https://blog.thinkmoon.cn/post/168-ai-model-selection-evaluation-decision-guide/） 转载或引用必须申明原指尖魔法屋来源及源地址！

相关阅读

根据标签、分类和主题为你挑选的相近文章