要系统地进行AI测试,首先需要理解被测试对象——大语言模型(LLM)的基本原理、能力边界和行为特性。

LLM的工作原理

大语言模型的核心原理可以概括为"下一Token预测":给定一段文本(Prompt),模型逐Token地预测最可能的下一个Token,然后将新预测的Token加入输入,继续预测下一个,直至达到终止条件。

推理流程可视化

理解LLM的推理过程是设计有效测试方案的前提。以下是一个完整的推理流程示意:

📥 输入阶段
User Prompt
"解释量子计算"
🔢 分词阶段
Tokenization
["解释","量子","计算"]
🧠 推理阶段
Transformer × N层
自注意力 + FFN
🎲 采样阶段
Token采样
Temperature/Top-P过滤
📤 输出阶段
逐Token生成
循环直到EOS

▲ 每个生成的Token都会被追加到输入中,形成自回归生成循环

核心参数详解

理解以下推理参数的含义和影响,是设计测试用例和控制模型行为的基础:

参数含义取值范围低值效果高值效果测试建议
temperature控制输出的随机性/创造性0.0 ~ 2.0输出确定、保守、重复性高,适合事实性任务输出多样、有创意、但也更容易跑偏和产生幻觉评测时设为0以获得可复现结果;创造性任务设0.7~1.0
top_p核采样:只从累积概率≥p的最小Token集合中采样0.0 ~ 1.0只考虑最高概率的少数Token,输出更集中考虑更多候选Token,输出更丰富通常与temperature配合使用;典型值为0.9~0.95
max_tokens限制生成的最大Token数量1 ~ 模型上下文窗口输出被截断,可能不完整允许更长输出,但Token消耗和延迟更高根据任务预估输出长度;测试时注意验证截断行为
top_k仅从概率最高的K个Token中采样1 ~ 词表大小输出非常确定(如top_k=1即为贪心解码)考虑更多候选,增加多样性不常用;部分模型不支持;典型值40~100
frequency_penalty惩罚已出现Token的重复,降低其后续概率-2.0 ~ 2.0允许甚至鼓励重复抑制重复,输出用词更多样测试长文本生成时关注;正值可减少循环重复
presence_penalty惩罚已出现Token(无论频率),鼓励引入新话题-2.0 ~ 2.0倾向于聚焦已有话题倾向于引入新词汇和新话题多轮对话测试时关注;值过高可能导致跑题
stop指定停止序列,遇到该字符串时立即终止生成字符串或字符串列表用于控制输出结构(如"###"、"END");测试格式输出时必设
🔬 参数测试要点 在AI测试中,这些参数本身也是测试对象。例如:temperature=0时同一输入的多次输出是否完全一致?max_tokens不足时模型如何截断(是否保留语义完整性)?不同参数组合下的安全护栏是否依然有效?

核心能力与边界

能力维度LLM的表现测试关注点
语言理解能够理解复杂的自然语言指令指令遵循能力、歧义处理
知识问答能回答广泛领域的知识性问题准确性、时效性、幻觉率
推理能力能够进行逻辑推理、数学计算推理准确率、步骤合理性
代码生成能生成多种编程语言的代码语法正确性、功能正确性、安全性
文本生成能生成文章、报告、创意内容连贯性、相关性、风格一致性
多轮对话能维持上下文进行多轮交互上下文保持、一致性

主流大模型对比

不同大模型在能力侧重、性能表现和适用场景上存在显著差异。了解这些差异有助于在测试中制定针对性的评测策略:

模型系列代表版本核心优势突出特点上下文窗口适用场景测试注意点
GPT
OpenAI
GPT-4o / 4.1综合能力均衡,指令遵循能力强,生态完善多模态(文本+图像+语音),Function Calling成熟,长上下文稳定128K通用对话、代码生成、复杂推理、企业级应用成本较高;API版本更新可能导致行为变化;多模态场景需覆盖图文混合测试
Claude
Anthropic
Claude 4 / 3.5长文本理解能力突出,安全护栏完善200K上下文窗口,代码和推理能力强,拒答机制精细200K长文档分析、代码审查、安全敏感场景、研究辅助安全限制较严格,可能过度拒答;需测试安全与可用性的平衡点
DeepSeek
DeepSeek
DeepSeek-V3 / R1性价比极高,中文能力强,开源友好MoE架构效率高,推理链透明(R1),API价格低128K中文场景、代码生成、数学推理、成本敏感型应用服务稳定性需持续监控;R1的CoT可能暴露内部推理;中文评测基准需本地化
Qwen
阿里通义
Qwen3 / Qwen2.5中文理解和生成能力顶尖,多尺寸覆盖全场景0.5B~235B多尺寸可选,支持29+语言,工具调用能力强128K中文应用、企业私有化部署、多语言场景、Agent开发不同尺寸能力差异大,需按场景选型;工具调用格式需与生态对齐
Gemini
Google
Gemini 2.5 Pro多模态原生支持,推理能力强原生多模态(非后期拼接),超长上下文(1M),深度思考模式1M多模态理解、超长文档处理、视频分析、科学推理API稳定性一般;多模态测试需覆盖跨模态一致性;输出风格偏学术
🏦 银行业选型建议 金融场景优先关注三点:数据安全(私有化部署能力)、合规性(安全护栏有效性)、稳定性(版本锁定与行为一致性)。DeepSeek和Qwen的私有化部署方案在银行业已有多例落地实践。

LLM的特有行为特性

🫥 幻觉

模型会生成看似合理但实际错误的内容,是LLM测试中最核心的问题之一。

📎 上下文遗忘

长对话中,模型倾向于"忘记"早期信息,影响多轮交互质量。

🎯 引导敏感性

Prompt的微小变化可能导致输出显著不同,Prompt工程至关重要。

🔓 越狱风险

通过精心构造的Prompt可以绕过模型的安全限制。

📊 位置偏差

模型对输入中不同位置的信息关注程度不同,通常更关注开头和结尾。

🔄 重复与自洽

同一问题的多次回答可能不一致,需要评估输出的稳定性。

Prompt的作用机制

在AI测试中,Prompt是测试的"输入",其质量直接影响测试结果的可靠性:

💡 测试启示Prompt本身也是需要测试的对象。在AI测试中,我们需要关注"测试Prompt的质量"和"通过Prompt来测试模型"两个层面。

实战:Python调用大模型API

以下示例演示如何通过OpenAI兼容接口调用大模型,涵盖基础调用、System Prompt构建和流式输出三个关键场景——这也是AI测试中最常用的交互模式。

场景一:基础API调用(评测模型输出质量)

from openai import OpenAI

# ============================================
# 初始化客户端(兼容任意OpenAI兼容接口)
# ============================================
client = OpenAI(
    base_url="https://api.deepseek.com/v1",  # 可替换为任意兼容服务
    api_key="your-api-key"
)

# ============================================
# System Prompt:定义模型角色与行为约束
# ============================================
system_prompt = """你是一个银行客服质量评估专家。你的职责是:
1. 评估客服回复的礼貌程度(1-5分)
2. 判断是否解决了用户问题(是/否/部分)
3. 检测是否存在合规风险(如误导性陈述、隐私泄露)
4. 输出严格的JSON格式,不要包含任何额外文本

评估标准:
- 礼貌程度:语气是否尊重、专业、得体
- 问题解决:是否准确理解并有效回应用户诉求
- 合规风险:是否存在违规承诺、信息泄露、不当引导"""

# ============================================
# User Prompt:携带待评估的具体内容
# ============================================
user_prompt = """请评估以下银行客服回复:

用户问题:我的信用卡昨天被盗刷了3000元,怎么办?
客服回复:尊敬的客户您好,非常理解您焦急的心情。请您立即拨打某银行24小时客服热线
95555进行挂失,我们将启动争议交易调查流程。同时建议您关注「银行APP-信用卡-
交易记录」确认是否有其他异常交易。调查期间该笔交易暂不计入账单,请您放心。

请按JSON格式返回评估结果。"""

# ============================================
# 调用模型
# ============================================
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_prompt}
    ],
    temperature=0.0,      # 评估任务需要确定性
    max_tokens=500,
    response_format={"type": "json_object"}  # 约束JSON输出
)

# 解析结果
result = response.choices[0].message.content
usage = response.usage

print(f"评估结果: {result}")
print(f"Token消耗: 输入={usage.prompt_tokens}, 输出={usage.completion_tokens}, "
      f"总计={usage.total_tokens}")
print(f"模型: {response.model}")

场景二:流式输出处理(模拟用户交互体验)

流式输出(Streaming)让用户无需等待完整回复即可看到逐Token生成的内容,是评估用户体验的关键测试点。以下代码展示如何正确处理流式响应:

from openai import OpenAI
import time

client = OpenAI(
    base_url="https://api.deepseek.com/v1",
    api_key="your-api-key"
)

# ============================================
# 流式调用:stream=True
# ============================================
stream = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "你是一个专业的性能测试专家,擅长解答性能测试相关问题。"},
        {"role": "user", "content": "请简要介绍银行核心系统的性能测试策略,控制在200字以内。"}
    ],
    temperature=0.7,
    max_tokens=500,
    stream=True  # 开启流式输出
)

# ============================================
# 逐块接收并处理
# ============================================
full_text = ""
token_count = 0
start_time = time.time()
first_token_time = None

print("📡 开始接收流式响应...\n")
for chunk in stream:
    # 获取当前Token的文本增量(delta)
    delta = chunk.choices[0].delta

    # 记录首Token到达时间(TTFT — Time To First Token)
    if first_token_time is None and delta.content:
        first_token_time = time.time() - start_time
        print(f"⏱️ 首Token延迟: {first_token_time:.3f}s\n")

    # 累积输出
    if delta.content:
        full_text += delta.content
        token_count += 1
        print(delta.content, end="", flush=True)  # 实时打印

    # 检查终止原因
    if chunk.choices[0].finish_reason:
        print(f"\n\n✅ 完成原因: {chunk.choices[0].finish_reason}")

# ============================================
# 统计指标(性能测试的核心关注点)
# ============================================
total_time = time.time() - start_time
print(f"\n{'='*50}")
print(f"📊 流式输出统计:")
print(f"  总耗时: {total_time:.3f}s")
print(f"  首Token时间 (TTFT): {first_token_time:.3f}s" if first_token_time else "  无输出")
print(f"  输出Token数: {token_count}")
print(f"  平均每Token时间: {total_time/token_count*1000:.1f}ms" if token_count > 0 else "")
print(f"  输出速率: {token_count/total_time:.1f} tokens/s" if total_time > 0 else "")
print(f"  输出长度: {len(full_text)} 字符")

场景三:批量评测与结果比对

在实际AI测试中,我们通常需要对大量测试用例进行批量评测。以下代码展示了一个精简的批量评测框架:

from openai import OpenAI
import json
import time
from concurrent.futures import ThreadPoolExecutor, as_completed

client = OpenAI(base_url="https://api.deepseek.com/v1", api_key="your-api-key")

# ============================================
# 评测数据集(模拟银行客服场景)
# ============================================
test_cases = [
    {"id": 1, "query": "我的账户被冻结了,如何解冻?",
     "expected_intent": "账户解冻", "difficulty": "easy"},
    {"id": 2, "query": "为什么我的转账被限额了?我要投诉!",
     "expected_intent": "投诉+转账限额", "difficulty": "medium"},
    {"id": 3, "query": "我收到短信说我的银行卡在境外消费了5万,但我没出国,这是诈骗吗?",
     "expected_intent": "欺诈识别+安全咨询", "difficulty": "hard"},
]

SYSTEM_PROMPT = """你是银行客服意图识别器。分析用户消息,返回JSON:
{"intent": "分类", "sentiment": "正面/中性/负面/紧急", "complexity": "低/中/高"}"""

# ============================================
# 单条评测函数
# ============================================
def evaluate_single(case):
    start = time.time()
    try:
        resp = client.chat.completions.create(
            model="deepseek-chat",
            messages=[
                {"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": case["query"]}
            ],
            temperature=0.0,
            max_tokens=200,
        )
        elapsed = time.time() - start
        return {
            "id": case["id"],
            "query": case["query"],
            "expected": case["expected_intent"],
            "result": resp.choices[0].message.content,
            "latency_s": round(elapsed, 2),
            "tokens": resp.usage.total_tokens,
            "difficulty": case["difficulty"],
            "status": "success"
        }
    except Exception as e:
        return {"id": case["id"], "status": "error", "error": str(e)}

# ============================================
# 并发执行评测(最多3个并发)
# ============================================
results = []
with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {executor.submit(evaluate_single, c): c for c in test_cases}
    for future in as_completed(futures):
        results.append(future.result())

# ============================================
# 汇总统计
# ============================================
success = [r for r in results if r["status"] == "success"]
print(f"总用例: {len(test_cases)}, 成功: {len(success)}, 失败: {len(results)-len(success)}")
if success:
    avg_latency = sum(r["latency_s"] for r in success) / len(success)
    total_tokens = sum(r["tokens"] for r in success)
    print(f"平均延迟: {avg_latency:.2f}s, 总Token消耗: {total_tokens}")
    for r in success:
        print(f"  #{r['id']} [{r['difficulty']}] {r['query'][:30]}... → {r['latency_s']}s")
🔑 代码中的测试关注点 以上三个示例覆盖了AI测试中的关键可观测指标:TTFT(首Token时间)衡量用户感知响应速度、Token消耗影响成本估算、延迟抖动反映服务稳定性。在性能测试场景中,这些指标需要配合并发、长连接、Token长度梯度等变量进行系统化采集。

案例:银行测试团队快速上手大模型

📋 背景

某银行性能测试团队接到任务:需要对行内即将上线的智能客服系统(基于大模型)进行性能测试方案设计。团队成员精通JMeter、LoadRunner等传统压测工具,但对大模型的工作原理和API交互方式缺乏了解。团队需要在2周内建立大模型的基础认知,并完成初步的测试方案框架。

🎯 实践路径:从零开始的4步法

1
第1天:亲手调用API,建立直观感受

使用Python + OpenAI SDK调用DeepSeek API,执行一个最简单的对话请求(5行代码即可跑通)。然后用Postman直接发HTTP请求,理解底层的RESTful交互协议。关键收获:大模型就是一个接受JSON、返回JSON的HTTP服务——这对性能测试工程师来说是最自然的理解方式。

2
第2-3天:理解关键参数,设计参数矩阵

系统学习temperature、top_p、max_tokens等参数的含义。设计一个参数矩阵(temperature=0/0.5/1.0 × max_tokens=100/500/2000),对比同一输入在不同参数下的输出差异和延迟变化。关键发现:temperature=0时输出稳定但单一,适合做基线测试;temperature=1.0时输出多样但延迟抖动更大

3
第4-7天:学会评测输出质量

编写简单的评测脚本,用另一个大模型(LLM-as-Judge)对智能客服的输出进行自动评分。评测维度包括:准确性(回答是否正确)、完整性(是否遗漏关键信息)、安全性(是否包含违规内容)。同时收集延迟、Token消耗等性能指标。关键认知:大模型的输出评测本身就是一个需要精心设计的过程——评测Prompt的质量直接决定了评测结果的信度

4
第8-14天:落地性能测试方案

将第1-7天积累的经验转化为可执行的性能测试方案:

  • 用JMeter的HTTP Sampler模拟多用户并发调用大模型API
  • 设计Token长度梯度测试(短/中/长输入),观察延迟的非线性增长
  • 对比temperature=0和temperature=1.0下的QPS差异
  • 建立性能基线:TTFT P50/P95/P99、并发QPS上限、Token吞吐量
  • 制定流式输出的压测方案(SSE长连接对服务器连接池的压力)

✅ 实践心得

阶段认知突破对测试的启示
API调用"大模型就是HTTP服务"传统压测工具完全可用,只需适配请求体格式
参数理解"参数是性能的调节阀"temperature/max_tokens直接影响延迟和吞吐量,需纳入压测变量
输出评测"评测是测试的核心难点"不能只看QPS,更要关注输出质量——需要建立自动化质量评测流水线
方案落地"性能测试+质量评测二合一"大模型测试需要同时关注「跑得快不快」和「答得对不对」
🚀 快速入门路径总结 对于测试团队来说,理解大模型最快的方式是亲手调用API(而非泛读论文)。建议路径:写5行代码调用API → 系统性调整参数观察输出变化 → 用LLM-as-Judge评估输出质量 → 将API调用封装为压测脚本。整个过程可以在1-2周内完成从0到可用的能力建设。

📋 案例研究:测试团队快速掌握大模型API调用

背景

某银行测试团队长期从事传统功能测试(手工用例、自动化回归),在行内启动大模型应用项目后,被要求承担模型效果评测工作。团队成员此前对LLM仅有概念性了解,从未实际调用过任何大模型API。

过程

  1. 第1-2天:从零学习API调用 — 通过官方文档和5行Python代码,完成第一次API请求并拿到回复,理解请求/响应的JSON结构
  2. 第3-5天:系统性理解参数 — 逐一调整temperature、top_p、max_tokens等参数,观察输出变化,总结出「参数-效果对照表」
  3. 第6-9天:搭建批量评测脚本 — 将单次调用扩展为批量处理框架,支持并发调用、结果持久化、异常重试
  4. 第10-14天:构建评测数据集与自动化流水线 — 整理行内业务场景的评测用例(200+条),引入LLM-as-Judge进行自动打分,形成可复用的评测能力

结果

评测维度学习前学习后(2周)
API调用能力完全不会可独立编写调用脚本,支持3个主流模型
参数调优不理解参数含义能根据场景选择合适的temperature/top_p组合
批量评测仅能手动单条测试可批量运行200+用例,自动生成评测报告
质量评估纯人工判断LLM-as-Judge自动化打分 + 人工抽检复核
评测效率约2小时/条(含讨论)约5秒/条,整体效率提升1000倍+

启示

  • API化降低了AI测试门槛:大模型通过标准HTTP API提供服务,测试团队无需成为AI专家,利用已有的接口测试经验即可快速上手。
  • 参数理解是性能与效果的关键:temperature、max_tokens等参数直接影响模型的延迟、吞吐和输出质量,是测试中必须掌握的核心变量。
  • 评测需要工程化思维:从「能不能调通」到「答得好不好」,需要构建数据集、评分标准和自动化流水线,这是测试团队发挥专业优势的领域。
  • 2周即可建立可用能力:实践证明,有经验的测试团队可以在短时间内从零构建大模型评测能力,关键在于动手实践而非理论堆砌。