2 篇博文 含有标签「LLM」

学习计划来源：AI_QA_Learning_Plan.md
进度判断：已完成 Day 1（LLM Basics）/ Day 2（Prompt Engineering）/ Day 3（ToT & ReAct），因此今天推进至 Day 4。
今日主题：让大模型“像接口一样”稳定输出：结构化输出约束（JSON Mode 与 Regex Constraint）

0. 今日目标（你学完应该能做到什么）​

1. 说清楚：为什么 LLM 输出经常“不好测/不好接入”，结构化约束能解决什么问题。
2. 分清楚两类约束手段：
   • JSON Mode / JSON Schema / Function Calling（偏“结构约束”）
   • Regex Constraint（偏“格式约束”）
3. 从测开视角落地：
   • 写一个 Python 用例生成器：强制模型输出 JSON 格式测试用例
   • 用 Pydantic 做合同校验（contract test）
   • 给出一套可回归的质量指标（解析成功率、字段完整率、覆盖率）

1. 核心理论知识讲解​

1.1 为什么“结构化输出”是 AI QA 的第一块基建​

在传统软件里，最稳定、最可测的交互通常长这样：

• 请求：固定协议（HTTP/JSON）
• 响应：固定 schema（字段存在性、类型、枚举、约束）
• 验证：断言 + 解析 + 兼容性策略

但 LLM 天生输出自由文本，常见问题包括：

• 不可解析：夹杂解释性文字、markdown、代码块、中文引号、末尾多逗号
• 字段漂移：expected 变成 expectation，steps 变成 step_list
• 类型漂移：本该是数组却输出字符串；布尔值输出 "true"
• 语义漂移：字段齐了，但内容不满足业务约束（例如：优先级枚举写成 P3）

所以对测开而言，结构化约束的意义是：

把 LLM 从“写作文”拉回“写接口响应”。

当输出可解析、可校验，你才能：

• 做自动化回归（CI 门禁）
• 做差异比对（diff）
• 做统计指标（解析成功率 / 缺字段率 / 类别覆盖率）
• 做故障定位（到底是模型问题、Prompt 问题、还是工具链问题）

1.2 JSON Mode：让模型“只说 JSON”​

JSON Mode（不同平台叫法不同）通常指：

• 你在请求中声明：输出必须是合法 JSON
• 服务端在解码/采样时对输出做约束（或者做后处理）

它解决的是：

• 输出中夹杂自然语言解释
• 结构不闭合 / 不合法

但要注意：JSON Mode 通常只能保证“语法合法”，并不保证：

• 字段齐全
• 类型正确
• 枚举合法
• 语义正确

因此工程上常见组合是：

• JSON Mode + JSON Schema（或 Pydantic）校验
• 校验失败 → 自动修复（repair）或二次追问（self-heal）

1.3 JSON Schema / Function Calling：让结构更“像合同”​

如果平台支持 Function Calling（工具调用） 或 JSON Schema 输出约束，它们的核心价值是：

• 模型不是“随便写一段 JSON”
• 而是“填一个你给定的结构模板”

对 QA 的启发是：

你可以把 LLM 的输出当作一个“外部依赖接口”，给它定义契约（Contract），然后像测接口一样测它。

常见测试点：

• Schema 合法率（必须达到阈值，例如 ≥ 99%）
• 必填字段缺失率
• 枚举越界率（例如 priority 只能 P0/P1/P2）
• 长度约束越界率（steps 最多 30 条）

1.4 Regex Constraint：用“格式规则”卡住最关键的部分​

Regex Constraint 可以理解为：

• 你不一定能把所有结构都约束死
• 但你可以把“最容易漂移、最影响解析/执行”的部分卡住

适用场景举例：

• 用例 ID 必须符合 TC-\d{4}
• 时间戳必须符合 ISO 8601
• 错误码必须符合 ^[A-Z_]+$
• 输出必须以 { 开头、以 } 结尾（最小可行版本）

Regex 的边界：

• 它不擅长表达深层 JSON 结构（正则不是解析器）
• 更适合作为“第一道闸门”：先保证能被下游接住

工程上推荐使用：

• Regex 做“入口过滤”（挡住明显不合格输出）
• Schema 做“深度校验”（类型、字段、枚举、约束）

2. 测开视角：把 LLM 输出变成“可回归的产物”​

今天我们把目标定得非常具体：

让大模型输出标准 JSON 测试用例，并且像接口一样被自动化校验。

你可以把它直接落成三类资产：

1. prompts/：Prompt 模板（像代码一样版本化）
2. schemas/：输出 Schema（合同）
3. tests/：合同测试（contract tests），作为 CI 门禁

3. 工程实践：Python 强制输出 JSON 用例 + Pydantic 校验​

实践目标：

1. 让模型输出“只包含 JSON”
2. 用 Pydantic 校验结构、枚举、长度
3. 若失败：自动触发一次“修复回合”（可选）

3.1 先定义“测试用例输出合同”（Pydantic Schema）​

# file: case_schema.py
from __future__ import annotations
from typing import Dict, List, Literal, Optional
from pydantic import BaseModel, Field

Priority = Literal["P0", "P1", "P2"]
Category = Literal["happy_path", "boundary", "negative", "auth", "idempotency", "concurrency"]

class APIInfo(BaseModel):
    name: str = Field(..., min_length=1)
    method: Literal["GET", "POST", "PUT", "DELETE"]
    path: str = Field(..., pattern=r"^/.*")

class Request(BaseModel):
    headers: Dict[str, str] = Field(default_factory=dict)
    query: Dict[str, object] = Field(default_factory=dict)
    body: Dict[str, object] = Field(default_factory=dict)

class Expected(BaseModel):
    http_status: int = Field(..., ge=100, le=599)
    body_contains: List[str] = Field(default_factory=list)
    error_code: Optional[str] = Field(default=None, pattern=r"^[A-Z_]+$")

class TestCase(BaseModel):
    id: str = Field(..., pattern=r"^TC-\d{4}$")
    title: str = Field(..., min_length=4)
    priority: Priority
    category: Category
    precondition: str = ""
    steps: List[str] = Field(..., min_length=2, max_length=30)
    request: Request
    expected: Expected

class CaseGenOutput(BaseModel):
    api: APIInfo
    testcases: List[TestCase] = Field(..., min_length=6)

为什么先写 Schema（而不是先写 Prompt）？

• QA 思维：先定义“可验收标准”，再让模型去满足它
• 工程效果：后续 Prompt 迭代时，你可以用这份 Schema 当回归门禁

3.2 Prompt：把“只输出 JSON”写成硬约束​

你是一名资深测试开发工程师（Test Dev）。

【任务】
根据输入的 API 契约信息，生成接口测试用例。

【强制输出格式】
1) 你只能输出 JSON（纯 JSON 文本），禁止输出 Markdown、代码块标记、解释性文字。
2) JSON 顶层必须只有两个字段：api、testcases。
3) 每条用例必须包含字段：id、title、priority、category、precondition、steps、request、expected。
4) 字段约束：
   - id 必须符合：TC-\d{4}
   - priority 只能是：P0/P1/P2
   - category 只能是：happy_path/boundary/negative/auth/idempotency/concurrency
   - steps 必须是数组，元素是字符串
   - expected.http_status 必须是 100~599
5) 用例必须覆盖：happy_path、boundary、negative、auth、idempotency。

【输入】
{{API_CONTRACT_JSON}}

这里已经混合使用了两类约束：

• 结构约束：只能 JSON、顶层字段固定
• Regex 约束：id 必须 TC-\d{4}

3.3 校验与“自愈”：Pydantic 校验失败就触发修复回合​

现实里最常见的失败不是“完全乱写”，而是 JSON 语法合法，但字段缺失/类型不对，或枚举写错（P3）。 因此推荐：校验失败 → 让模型根据错误信息修复输出。

# file: generate_and_validate.py
import json
from case_schema import CaseGenOutput
from llm_client import call_llm_json

def validate_or_raise(output_str: str) -> CaseGenOutput:
    data = json.loads(output_str)
    return CaseGenOutput.model_validate(data)

def repair_prompt(bad_json: str, err: str) -> str:
    return f"""你之前输出的 JSON 不符合合同，请你只修复 JSON 本身，不要输出任何解释性文字。

【校验错误】\n{err}

【待修复 JSON】\n{bad_json}

【输出要求】
- 只能输出修复后的 JSON（纯 JSON 文本）
- 必须保持顶层字段 api/testcases
"""

def generate_cases(api_contract_json: str, base_prompt: str, max_repair: int = 1) -> CaseGenOutput:
    prompt = base_prompt.replace("{{API_CONTRACT_JSON}}", api_contract_json)
    out = call_llm_json(prompt)

    for _ in range(max_repair + 1):
        try:
            return validate_or_raise(out)
        except Exception as e:
            out = call_llm_json(repair_prompt(out, str(e)))

    raise RuntimeError("unreachable")

QA 点评：为什么这是“工程化”的关键一步？

• 你不再把 LLM 当成“必须一次成功的黑盒”
• 而是像对待不稳定依赖一样：给它错误信息 -> 让它自我修复 -> 直到满足合同

4. 工程实践补充：Go 侧如何接住（适合你们 Go 测试体系）​

如果你们后端主要是 Go，建议至少做两层：

1. JSON 能否 Unmarshal（语法 + 字段类型基础）
2. 业务合同校验（枚举/长度/覆盖）

// file: casegen/contract_test.go
package casegen

import (
	"encoding/json"
	"os"
	"testing"
)

type Output struct {
	API struct {
		Name   string `json:"name"`
		Method string `json:"method"`
		Path   string `json:"path"`
	} `json:"api"`
	Testcases []struct {
		ID       string   `json:"id"`
		Priority string   `json:"priority"`
		Category string   `json:"category"`
		Expected struct {
			HTTPStatus int `json:"http_status"`
		} `json:"expected"`
	} `json:"testcases"`
}

func TestCaseGenContract(t *testing.T) {
	b, _ := os.ReadFile("../snapshots/day4_casegen.json")
	var out Output
	json.Unmarshal(b, &out)

	if len(out.Testcases) < 6 {
		t.Fatalf("want >= 6 cases, got %d", len(out.Testcases))
	}
    // ... 补充自定义枚举与范围断言 ...
}

5. 常见坑与 QA 对策（经验总结）​

5.1 “只输出 JSON”仍然会失败，怎么办？​

常见现象：模型输出 Here is the JSON: + JSON，或者用 ```json 包裹。 对策（从轻到重）：

1. Prompt 强约束：明确禁止解释、禁止代码块
2. 入口 Regex 过滤：例如只截取第一个 { 到最后一个 }
3. JSON Mode / Function Calling：平台级约束
4. 修复回合（repair）：把错误扔回模型让它改

5.2 你应该监控哪些指标？​

把 LLM 输出质量做成可观测指标：

• json_parse_success_rate：JSON 解析成功率
• schema_valid_rate：Schema 校验成功率
• repair_needed_rate：需要修复回合的比例（越低越好）
• required_category_coverage_rate：必选类别覆盖率

6. 课后小思考（建议写进你的学习资产）​

1. 在你的业务里，哪些 LLM 输出属于“必须可执行”的产物？测试用例？测试数据？SQL？发布单检查项？你会优先把哪一类纳入 JSON Schema + 合同测试？
2. 如果把这条流水线放进 CI：你会选择 固定模型 + 回归 Prompt，还是 固定 Prompt + 回归模型？哪个对你们团队更现实？

（明日预告 Day 5：如何评测 Prompt 的稳定性？构建一个 Python/Go 的批量 Prompt 自动化测试脚本，让“回归”真正跑起来。）

学习目标：建立一套“能用于测试设计”的心智模型：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 示例）​

今天的实践目标：

1. 用同一 Prompt，在不同 Temperature / Top-p 下采样多次
2. 计算“波动性”指标，形成可纳入 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) 课后小思考（建议写进你的学习博客/飞书笔记）​

1. 你的业务里哪些输出必须稳定？（例如：生成配置、生成测试用例、生成 SQL/脚本）哪些可以发散？（例如：文案、建议）
2. 如果把 Agent 拆成：输入解析 → 规划 → 工具调用 → 汇总输出，你认为 哪一段最需要固定 temperature/top_p？哪一段必须引入“结构化校验”？
3. 在你当前的自动化体系（Ginkgo / Playwright / K8s SDK）里，你会把“LLM 探针”放在哪一层？
   • 单测（Prompt 单测）
   • 集成测试（带工具调用）
   • E2E（端到端工作流）