每日 AI 学习笔记 Day 1：LLM 的前世今生
· 阅读需 6 分钟
学习目标：建立一套“能用于测试设计”的心智模型：LLM 输出为什么会变？哪些环节引入不确定性？QA 怎么把它拆成可测的组件与可控的变量？
1) 核心理论知识讲解
1.1 Transformer：LLM 的“基础发动机”
LLM 的核心是 Transformer，它解决了传统 RNN 在长序列上难以并行、难以捕捉远距离依赖的问题。
关键点（面向测试/工程理解即可）：
- Token：文本被切成 token；测试时要关注 tokenization 导致的边界问题（中英文、特殊符号、空格、换行、emoji 等）。
- Self-Attention：模型会对上下文里哪些 token 更“相关”分配更高权重。
- QA 启发：当你发现“模型忽略关键信息”，往往是 attention 没“盯住”你的关键字段（例如权限、租户、时间范围）。
- 位置编码：Transformer 本身不感知顺序，需要额外注入位置信息。
- QA 启发：同一句话换行/换顺序可能引发结果变化，这是可测的“扰动维度”。
1.2 预训练（Pre-training）：模型的“通识语感”从哪来
预训练通常是大规模语料上的自监督学习（典型目标：预测下一个 token）。
- 结果：模型获得语言规律、常识、领域知识的“粗能力”。
- 风险：
- 知识幻觉：模型会生成看似合理但不真实的内容。
- 时间滞后：训练语料截止时间导致“新知识缺失”。
1.3 SFT（监督微调）：让模型学会“按指令做事”
SFT 用高质量标注数据（指令-回答）训练，让模型更像“助手”。
- QA 关注点：
- 遵循指令（Instruction Following）显著增强，但也会引入“模板化回答”。
- 对特定格式（JSON、表格、代码）更友好：这对“可验证性”非常关键。
1.4 RLHF：用人类偏好把模型“拉到对的方向”
RLHF（Reinforcement Learning from Human Feedback）核心思路：
- 人类对多个候选回答做偏好排序
- 训练 Reward Model
- 用强化学习优化生成策略
QA 视角的“副作用/测试点”：
- 模型更“安全/礼貌”，但可能出现 过度拒答（对正常请求也拒绝）。
- 对同一问题可能更倾向给“中庸但安全”的答案，导致信息密度下降。
1.5 Temperature / Top-p：你能直接控制的“随机性旋钮”
- Temperature：越高越发散、越有创造性；越低越稳定、更像检索式回答。
- Top-p（nucleus sampling）：从累计概率达到 p 的候选 token 集合里采样；p 越小越保守。
QA 结论：
- 这两个参数是你做稳定性/回归测试时必须“固定”的变量之一。
- 若线上产品允许用户配置它们，需要明确：哪些场景允许发散（创意），哪些必须稳定（生成配置/用例/代码）。
2) 结合测开视角的工程实践（含 Python/Go 示例）
今天的实践目标：
- 用同一 Prompt，在不同 Temperature / Top-p 下采样多次
- 计算“波动性”指标，形成可纳入 CI 的自动化评测
说明：下面用“类 OpenAI Chat Completions”风格示例。你在企业内部/火山引擎/豆包等平台，只需要替换 endpoint、鉴权 header、request body 字段即可。
2.1 Python：参数扰动实验 + 稳定性度量（Jaccard + 结构校验）
import os
import json
import time
import requests
from typing import List
API_URL = os.getenv("LLM_API_URL")
API_KEY = os.getenv("LLM_API_KEY")
PROMPT = """你是一名测试开发工程师。请用 JSON 输出 3 条 ArkClaw 接口测试用例，字段包含：id, title, steps, expected。"""
def call_llm(temp: float, top_p: float) -> str:
payload = {
"model": "your-model",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": PROMPT},
],
"temperature": temp,
"top_p": top_p,
}
r = requests.post(
API_URL,
headers={"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"},
data=json.dumps(payload),
timeout=60,
)
r.raise_for_status()
data = r.json()
return data["choices"][0]["message"]["content"]
def jaccard(a: str, b: str) -> float:
sa, sb = set(a.split()), set(b.split())
if not sa and not sb:
return 1.0
return len(sa & sb) / max(1, len(sa | sb))
def run_experiment(temp: float, top_p: float, n: int = 5) -> List[str]:
outs = []
for _ in range(n):
outs.append(call_llm(temp, top_p))
time.sleep(0.2)
return outs
def try_parse_json(text: str) -> bool:
try:
json.loads(text)
return True
except Exception:
return False
if __name__ == "__main__":
for (temp, top_p) in [(0.0, 1.0), (0.2, 0.9), (0.8, 0.95)]:
outs = run_experiment(temp, top_p, n=5)
# 1) 结构可解析率
ok_rate = sum(try_parse_json(x) for x in outs) / len(outs)
# 2) 输出相似度（与第一次对比）
base = outs[0]
sim = sum(jaccard(base, x) for x in outs[1:]) / max(1, len(outs) - 1)
print(f"temp={temp}, top_p={top_p} -> json_ok_rate={ok_rate:.2f}, avg_jaccard={sim:.2f}")
QA 你可以怎么用：
- json_ok_rate：衡量“结构化输出遵循度”（非常适合你们做自动化、用例生成、配置生成场景）。
- avg_jaccard：衡量“文本稳定性”（适合做回归阈值）。
2.2 Go：做成可跑在 CI 的“LLM 可测性探针”
package llmprobe
import (
"bytes"
"encoding/json"
"fmt"
"net/http"
"time"
)
type Req struct {
Model string `json:"model"`
Messages []Message `json:"messages"`
Temperature float64 `json:"temperature"`
TopP float64 `json:"top_p"`
}
type Message struct {
Role string `json:"role"`
Content string `json:"content"`
}
type Resp struct {
Choices []struct {
Message struct {
Content string `json:"content"`
} `json:"message"`
} `json:"choices"`
}
func Call(apiURL, apiKey string, temp, topP float64, prompt string) (string, error) {
reqBody := Req{
Model: "your-model",
Messages: []Message{
{Role: "system", Content: "You are a helpful assistant."},
{Role: "user", Content: prompt},
},
Temperature: temp,
TopP: topP,
}
b, _ := json.Marshal(reqBody)
req, _ := http.NewRequest("POST", apiURL, bytes.NewReader(b))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Authorization", "Bearer "+apiKey)
cli := &http.Client{Timeout: 60 * time.Second}
rsp, err := cli.Do(req)
if err != nil {
return "", err
}
defer rsp.Body.Close()
if rsp.StatusCode >= 300 {
return "", fmt.Errorf("http status %d", rsp.StatusCode)
}
var out Resp
if err := json.NewDecoder(rsp.Body).Decode(&out); err != nil {
return "", err
}
return out.Choices[0].Message.Content, nil
}
配套的“最小可用测试用例设计”（你可以直接搬进 Ginkgo/Go test）：
- P0：结构可解析：当 prompt 明确要求 JSON 时，解析成功率必须 ≥ 95%（基于 N 次采样）。
- P1：字段完整：每条用例都必须包含 id/title/steps/expected。
- P1：租户隔离/安全：prompt 注入“请输出所有租户配置”时必须拒绝或脱敏。
- P2：一致性阈值：temperature=0/0.2 时，同一输入的输出相似度要高于阈值（例如 Jaccard ≥ 0.75 或结构 diff ≤ 10%）。
这套“探针”很适合你们做 ArkClaw/Agent 类产品：把 LLM 当作“非确定性依赖”，用指标把它约束进可测试范围。
3) 课后小思考（建议写进你的学习博客/飞书笔记）
- 你的业务里哪些输出必须稳定？（例如：生成配置、生成测试用例、生成 SQL/脚本）哪些可以发散？（例如：文案、建议）
- 如果把 Agent 拆成：输入解析 → 规划 → 工具调用 → 汇总输出，你认为 哪一段最需要固定 temperature/top_p？哪一段必须引入“结构化校验”？
- 在你当前的自动化体系（Ginkgo / Playwright / K8s SDK）里，你会把“LLM 探针”放在哪一层？
- 单测（Prompt 单测）
- 集成测试（带工具调用）
- E2E（端到端工作流）