Posts

为什么结构化输出如此重要 LLM的默认输出是自由文本，但实际工程中我们几乎总是需要结构化数据——API调用需要JSON参数、数据抽取需要表格、Agent决策需要指令。结构化输出的可靠性直接决定了系统能否自动化运行。 目前主流的三种结构化输出方案各有优劣，选对场景才能发挥最大价值。 方案一：JSON Mode 原理与用法 JSON Mode是OpenAI率先引入的功能，强制模型输出合法JSON。它的原理是在解码阶段约束token采样，确保输出符合JSON语法。 from openai import OpenAI client = OpenAI() response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": "你是数据抽取助手，输出JSON格式。"}, {"role": "user", "content": "抽取以下文本的人名和职位：张三是CEO，李四是CTO。"} ], response_format={"type": "json_object"} ) import json result = json.loads(response.choices[0].message.content) # {"people": [{"name": "张三", "title": "CEO"}, {"name": "李四", "title": "CTO"}]} 局限性 JSON Mode只保证语法合法，不保证结构符合预期。它无法约束字段名、类型和嵌套层级。你需要额外验证： from pydantic import BaseModel, ValidationError class PersonInfo(BasestModel): name: str title: str class ExtractionResult(BaseModel): people: list[PersonInfo] def safe_parse(raw_json: str) -> dict | None: try: data = json.loads(raw_json) return ExtractionResult(**data).model_dump() except (json.JSONDecodeError, ValidationError) as e: # 记录错误，触发修复流程 logger.warning(f"Schema validation failed: {e}") return None 方案二：Function Calling 设计理念 Function Calling让模型"知道"有哪些可用函数及其参数schema，模型负责生成符合schema的调用参数。这是一种约束生成方式，比JSON Mode更严格。 tools = [ { "type": "function", "function": { "name": "search_database", "description": "在产品数据库中搜索", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "搜索关键词"}, "category": { "type": "string", "enum": ["电子产品", "服装", "食品"], "description": "限定品类" }, "limit": {"type": "integer", "minimum": 1, "maximum": 50} }, "required": ["query"] } } } ] response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "帮我找3个电子产品类的手机"}], tools=tools, tool_choice={"type": "function", "function": {"name": "search_database"}} ) # 模型生成结构化参数 tool_call = response.choices[0].message.tool_calls[0] args = json.loads(tool_call.function.arguments) # {"query": "手机", "category": "电子产品", "limit": 3} 多函数编排 Function Calling的真正威力在于多函数编排和模型自主决策调用链： ...

引言：2026年大模型格局 2026年，大语言模型赛道已从"百模大战"演变为"双轨并行"的成熟格局。一边是以GPT-5、Claude 4、Gemini 3为代表的闭源旗舰模型，另一边是以Llama 4、Qwen 3、DeepSeek V3为首的开源阵营。选型不再只是"谁更强"的问题，而是"谁更适合你的场景"。 开源与闭源的核心维度对比 维度 闭源模型 开源模型 推理能力 顶级（GPT-5/Claude 4） 接近一流（Llama 4/Qwen 3） 数据隐私 数据需上传第三方 可完全本地部署 定制化 受限于API能力 可微调、量化、架构修改 部署成本 按Token计费，长期成本高 一次性硬件投入，边际成本低 迭代速度 由厂商决定 社区驱动，可自主控制 生态工具 官方SDK完善 社区工具链丰富但碎片化 场景化选型决策矩阵 场景一：企业知识库与RAG系统 推荐：开源模型（Qwen 3-72B / Llama 4-70B） 企业内部RAG系统对数据隐私要求极高。使用闭源API意味着将企业核心文档上传至第三方服务器，这在金融、医疗、法律等行业是不可接受的。开源模型配合vLLM或SGLang推理框架，在企业级GPU集群上可实现低延迟的本地化部署。 # 使用vLLM部署Qwen3-72B的示例 from vllm import LLM, SamplingParams llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=4, # 4卡张量并行 max_model_len=32768, quantization="awq", # AWQ量化降低显存 ) sampling = SamplingParams(temperature=0.3, max_tokens=2048) response = llm.generate("总结以下文档要点：...", sampling) 场景二：复杂推理与代码生成 推荐：闭源模型（GPT-5 / Claude 4） 在需要深度推理、长链代码生成或多步骤任务规划的场景中，闭源旗舰模型仍有明显优势。2026年的基准测试显示，GPT-5在SWE-Bench上的通过率达到71.3%，而最强的开源模型Llama 4-405B为58.7%，差距约12个百分点。 # 闭源模型调用示例 - 复杂代码任务 import openai client = openai.OpenAI() response = client.chat.completions.create( model="gpt-5", messages=[ {"role": "system", "content": "你是资深架构师，输出生产级代码"}, {"role": "user", "content": "设计一个支持百万并发的分布式消息队列..."} ], reasoning_effort="high", # 2026新特性：推理深度控制 max_tokens=8192, ) 场景三：边缘端与移动部署 推荐：开源小模型（Phi-4 / Qwen3-4B） ...

引言：为什么需要量化？ 大语言模型的参数量和计算量呈指数级增长。一个72B模型在FP16精度下需要约144GB显存，而通过INT4量化可压缩至约36GB——单卡A100 80GB即可运行。量化已成为大模型部署的必经环节，但不同的量化方案在精度、速度和硬件兼容性上差异显著。 三大量化方案原理 INT8量化 INT8将FP16的权重映射到[-128, 127]的整数范围。核心思想是通过缩放因子（scale）和零点（zero point）将浮点数线性映射到整数空间： 量化： q = round(w / scale) + zero_point 反量化：w = scale * (q - zero_point) INT8是一种"安全"的量化方案，几乎所有主流GPU（Ampere及以上）都原生支持INT8矩阵乘法（通过Tensor Core）。 INT4量化 INT4将权重压缩到4位整数，范围仅为[-8, 7]。这意味着每个参数仅占0.5字节，相比FP16压缩了8倍。INT4通常采用分组量化（Group-wise Quantization）策略，每32或64个参数共享一组缩放因子： # INT4分组量化示例（伪代码） import torch def quantize_int4(weight, group_size=64): # 将权重按group_size分组 original_shape = weight.shape weight = weight.reshape(-1, group_size) # 计算每组的缩放因子 w_max = weight.abs().max(dim=-1, keepdim=True).values scale = w_max / 7.0 # INT4范围: [-8, 7] # 量化 q_weight = torch.round(weight / scale).clamp(-8, 7).to(torch.int8) return q_weight, scale # 反量化 def dequantize_int4(q_weight, scale): return (q_weight.float() * scale).reshape(original_shape) FP8量化 FP8是2024年起逐渐成熟的新一代低精度格式，采用浮点数而非整数表示。主流有两种格式： 格式 指数位 尾数位 范围 精度 E4M3 4 3 ±448 较高精度 E5M2 5 2 ±57344 较大范围 FP8的优势在于保留了浮点数的动态范围，对异常值更鲁棒，且NVIDIA Hopper/Blackwell架构原生支持FP8 Tensor Core。 ...

欧盟AI法案实施时间线 2026年8月2日，欧盟《人工智能法案》（EU AI Act）的核心条款正式全面实施。这部全球首部综合性AI监管法律对中国AI企业的欧洲出海之路产生了深远影响。 实施阶段回顾 阶段 时间 适用条款 影响范围 第一阶段 2025年2月 禁止类AI实践 所有在欧盟提供服务的AI系统 第二阶段 2025年8月 通用AI模型(GPAI)义务 基础模型提供商 第三阶段 2026年8月 高风险AI系统全面合规 教育、就业、司法、基础设施等 第四阶段 2027年8月 特定高风险系统附加义务 医疗器械、自动驾驶等 风险分级体系详解 欧盟AI法案采用基于风险的分级监管框架： 不可接受风险（完全禁止） 社会评分系统 实时远程生物识别（执法例外） 潜意识操纵技术 预测性执法（基于画像） 高风险（严格合规要求） # 高风险AI系统的合规检查清单（伪代码） class HighRiskAICompliance: def __init__(self, system): self.system = system def check_compliance(self): checks = { "风险管理": self.risk_management_system(), "数据治理": self.data_quality_assurance(), "技术文档": self.technical_documentation(), "记录保存": self.logging_and_audit_trail(), "透明度": self.transparency_requirements(), "人工监督": self.human_oversight(), "准确性": self.accuracy_robustness(), "网络安全": self.cybersecurity_measures(), } return {k: v for k, v in checks.items() if not v.passed} def risk_management_system(self): # 必须建立持续的风险识别与缓解流程 return ComplianceResult( passed=self.system.has_risk_register and self.system.risk_review_frequency == "quarterly" ) 有限风险（透明度义务） 聊天机器人需明确告知用户在与AI交互 深度伪造内容需标注 情感识别系统需告知数据使用方式 最小风险（无额外义务） 垃圾邮件过滤 推荐系统（非敏感领域） 电子游戏AI 对中国AI企业的五大影响 1. 基础模型出海门槛大幅提高 作为GPAI（通用AI模型）提供商，中国的大模型公司在向欧盟用户提供服务时必须： ...

引言：评估困境 大语言模型的能力边界正在以前所未有的速度扩展，但我们的评估手段是否跟上了？当GPT-4级别的模型在MMLU上得分超过90%的人类水平时，传统的基准测试正在失去区分度。2026年，AI社区面临一个核心问题：自动评估能否完全取代人工评估？ 答案是否定的。但原因远比"人更聪明"复杂得多。 自动评估的现状与局限 主流自动评估方法 当前AI系统评估主要依赖以下几条路径： 评估方法 代表工具 优势 局限 标准基准测试 MMLU, HumanEval, GSM8K 可复现、成本低 数据泄露、区分度下降 LLM-as-Judge GPT-4裁判模型 可扩展、有一定语义理解 偏好偏差、位置效应 偏好对评估 Chatbot Arena ELO 反映真实用户偏好 覆盖面有限、噪声大 自动化指标 BLEU, ROUGE, BERTScore 快速、无需人工 与人类判断相关性弱 LLM-as-Judge的系统性偏差 LLM-as-Judge在2025年被广泛采用，但研究揭示了多个系统性问题： # LLM-as-Judge位置偏差实验示例 import json from openai import OpenAI client = OpenAI() def judge_with_position_swap(question, answer_a, answer_b): """通过交换回答顺序检测位置偏差""" prompt_original = f"问题：{question}\n回答A：{answer_a}\n回答B：{answer_b}\n哪个更好？" prompt_swapped = f"问题：{question}\n回答A：{answer_b}\n回答B：{answer_a}\n哪个更好？" result_original = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt_original}] ).choices[0].message.content result_swapped = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt_swapped}] ).choices[0].message.content # 如果两次判断不一致，说明存在位置偏差 return { "original": result_original, "swapped": result_swapped, "consistent": result_original.replace("A","B").replace("B","A") == result_swapped } 实验数据显示，GPT-4作为裁判时，位置偏差率约为15-20%。这意味着在近五分之一的判断中，仅交换回答顺序就会改变裁判结论。 人工评估的不可替代价值 1. 细粒度质量感知 人工评估能够捕捉自动评估遗漏的质量维度： 语气与风格适配：同一事实信息，面向儿童和面向专家的表达方式截然不同 隐含意图理解：用户说"这个方案看起来挺激进的"，人工评估者能判断这是赞美还是担忧 文化敏感度：涉及文化背景的表达，自动评估往往力不从心 创造性评估：创意写作、头脑风暴等开放任务的"好"与"不好"极难自动化 2. 安全性与对齐评估 在安全评估领域，人工评估的角色更为关键： ...

从请求-响应到事件驱动 传统LLM应用采用请求-响应模式：用户发消息→LLM处理→返回结果。但在生产环境中，Agent需要处理大量异步、多源、解耦的场景： 用户上传文件后自动触发分析Agent 多个Agent完成各自任务后汇总 外部系统（GitHub、Jira）状态变更触发Agent响应 这些场景的共同特征是：事件发生的时间不确定，处理者可能不唯一。事件驱动架构（EDA）是解决这类问题的自然选择。 第一层：Webhook模式 适用场景 Webhook是最简单的EDA实现，适合外部系统→Agent的单向通知。 from fastapi import FastAPI, Request, HTTPException import hmac import hashlib import asyncio app = FastAPI() class WebhookHandler: def __init__(self): self.handlers: dict[str, callable] = {} self.secrets: dict[str, str] = {} def register(self, event_type: str, handler: callable, secret: str = ""): self.handlers[event_type] = handler if secret: self.secrets[event_type] = secret async def handle(self, event_type: str, payload: dict, signature: str = ""): # 验证签名 if event_type in self.secrets: if not self._verify_signature(payload, signature, self.secrets[event_type]): raise HTTPException(401, "Invalid signature") handler = self.handlers.get(event_type) if not handler: raise HTTPException(404, f"No handler for {event_type}") # 异步处理，不阻塞响应 asyncio.create_task(handler(payload)) def _verify_signature(self, payload: dict, signature: str, secret: str) -> bool: expected = hmac.new( secret.encode(), str(payload).encode(), hashlib.sha256 ).hexdigest() return hmac.compare_digest(expected, signature) webhook_handler = WebhookHandler() @app.post("/webhook/{event_type}") async def webhook(event_type: str, request: Request): payload = await request.json() signature = request.headers.get("X-Signature", "") await webhook_handler.handle(event_type, payload, signature) return {"status": "accepted"} # 注册处理器 @webhook_handler.register("github.push", secret=os.getenv("GITHUB_WEBHOOK_SECRET")) async def handle_push(payload: dict): changes = payload.get("commits", []) # 触发代码审查Agent await code_review_agent.analyze(changes) Webhook的局限 局限 影响 解决方案 无重试机制 网络抖动导致丢失 上游需重试 + 幂等设计 无背压 高峰期Agent过载 加消息队列缓冲 同步确认 处理慢导致超时 异步处理 + 立即返回 无顺序保证 事件乱序处理 加序列号/时间戳 第二层：消息队列模式 为什么需要消息队列 当事件量增大或处理时间变长时，Webhook模式会崩溃。消息队列（MQ）提供解耦、缓冲和可靠投递。 ...

思维链的演进脉络 大语言模型的推理能力不完全是"涌现"出来的，很多时候取决于我们如何引导它思考。从最基础的CoT（Chain-of-Thought）到树状的ToT（Tree-of-Thoughts）再到图状的GoT（Graph-of-Thoughts），每一种范式都在扩展前一种的推理边界。 CoT：线性推理的基石 核心思想 CoT的本质是让模型"展示推理过程"。通过在输出最终答案前生成中间推理步骤，降低模型跳过关键逻辑的风险。 # Zero-shot CoT 提示: 一个教室有32个学生，其中3/8是女生。又来了4个女生。现在女生占多少？ 附加: 让我们一步一步思考。 # 模型输出 原女生数: 32 × 3/8 = 12 加入后女生数: 12 + 4 = 16 总人数: 32 + 4 = 36 比例: 16/36 = 4/9 ≈ 44.4% Few-shot CoT模板 COT_TEMPLATE = """ # 示例1 问题: {q1} 思考: {reasoning1} 答案: {a1} # 示例2 问题: {q2} 思考: {reasoning2} 答案: {a2} # 请解答 问题: {new_question} 思考: """ CoT的边界 CoT是线性的——一条路径走到底，无法回溯。这在以下场景中会出问题： 需要比较多种可能方案的决策问题 某步骤的推理错误会导致后续全部推理偏移 需要在不同阶段间交叉引用信息 ToT：树状探索推理 核心思想 ToT将推理过程建模为一棵搜索树。在每个决策节点生成多个候选思路，通过评估函数筛选有前途的分支，再继续展开。 ...

数据决定上限 在LLM微调领域有一句共识：模型架构决定下限，数据质量决定上限。 一个精心调优的7B模型配合高质量数据，可以超越用粗糙数据训练的70B模型。这不是夸张——实践已经反复证明这一点。 但"高质量数据"不是一个静态标签，而是一条工程管线的输出。本文将完整拆解从原始数据到训练就绪数据的全流程。 数据管线全景图 原始数据源 │ ├──→ 格式标准化 ├──→ 基础清洗（去噪、截断、编码修复） ├──→ 去重（精确去重 + 语义去重） ├──→ 质量评估（规则 + 模型打分） ├──→ 安全过滤（有害内容、PII脱敏） ├──→ 分布均衡（领域采样） └──→ 最终数据集 一、格式标准化 生产环境的数据来源五花八门：爬虫页面、API导出、用户日志、合成数据。第一步是统一到标准格式。 import json from dataclasses import dataclass from typing import List @dataclass class TrainingSample: """标准化训练样本结构""" instruction: str # 用户指令 input: str = "" # 附加输入（可选） output: str = "" # 期望输出 metadata: dict = None # 来源、质量分数等元信息 def normalize_to_alpaca(raw_samples: List[dict]) -> List[dict]: """将各种格式统一为Alpaca格式""" normalized = [] for sample in raw_samples: # 处理ShareGPT格式 if "conversations" in sample: convs = sample["conversations"] instruction = convs[0]["value"] if len(convs) > 0 else "" output = convs[1]["value"] if len(convs) > 1 else "" normalized.append({"instruction": instruction, "output": output}) # 处理Alpaca格式 elif "instruction" in sample: normalized.append(sample) # 处理OpenAI格式 elif "messages" in sample: msgs = sample["messages"] instruction = msgs[0]["content"] if msgs[0]["role"] == "user" else "" output = next((m["content"] for m in msgs if m["role"] == "assistant"), "") normalized.append({"instruction": instruction, "output": output}) return normalized 二、基础清洗 文本去噪 import re class TextCleaner: def __init__(self): self.patterns = { # HTML标签 "html": re.compile(r'<[^>]+>'), # 连续空白 "whitespace": re.compile(r'\s{3,}'), # URL（可选保留） "url": re.compile(r'https?://\S+'), # 乱码字符 "garbage": re.compile(r'[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f]'), # 重复标点（超过3个） "repeat_punct": re.compile(r'([！。，,.!?？]){4,}'), } def clean(self, text: str) -> str: text = self.patterns["garbage"].sub('', text) text = self.patterns["html"].sub('', text) text = self.patterns["whitespace"].sub('\n', text) text = self.patterns["repeat_punct"].sub(r'\1\1\1', text) return text.strip() def is_valid(self, text: str, min_len=10, max_len=4096) -> bool: """基础有效性检查""" if not text or len(text) < min_len or len(text) > max_len: return False # 数字与字母占比过高（可能是日志/代码误入） alpha_ratio = sum(c.isalpha() for c in text) / len(text) if alpha_ratio < 0.3: return False return True 编码修复 def fix_encoding(text: str) -> str: """修复常见的编码问题""" # 修复UTF-8被误解码为Latin-1的情况 try: return text.encode('latin-1').decode('utf-8') except (UnicodeDecodeError, UnicodeEncodeError): pass return text 三、去重：比你想的更重要 数据重复是微调的隐形杀手。重复数据会导致模型过拟合特定模式，降低泛化能力。去重分为两个层次： ...

为什么标准注意力是瓶颈？ Transformer的核心——自注意力机制，其计算复杂度是序列长度的二次方 O(n²)。这个n²使得处理长序列时的计算和内存开销急剧增长。 标准注意力的计算过程 import torch import torch.nn.functional as F import math def standard_attention(Q, K, V): """ 标准自注意力 Q, K, V: (batch, num_heads, seq_len, d_head) """ d = Q.shape[-1] # 注意力分数: (batch, heads, seq, seq) scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(d) # Softmax归一化 attn = F.softmax(scores, dim=-1) # 加权求和 output = torch.matmul(attn, V) # (batch, heads, seq, d_head) return output # 计算复杂度分析 # scores矩阵大小: seq_len × seq_len # 当 seq_len = 8192 时, 每个head的scores矩阵 = 8192² = 67M 个元素 # 当 seq_len = 32768 时, 每个head的scores矩阵 = 32768² = 1B 个元素 # 显存随序列长度平方增长！ 不同序列长度的开销对比 序列长度 注意力矩阵大小 显存(FP16, 32头) 计算量(FLOPs) 4K 16M 1GB 0.13T 8K 64M 4GB 0.52T 32K 1B 64GB 8.4T 128K 16B 1TB 134T 1M 1T 64TB 8.2PT 这个表格清楚地展示了为什么标准注意力无法扩展到超长序列。 ...

引言：当AI成为自己的对齐者 传统RLHF依赖大量人类标注者来提供偏好反馈，这带来了三个根本性问题：成本高昂、标注质量参差不齐、且难以覆盖所有安全场景。Anthropic提出的Constitutional AI（宪法AI，简称CAI）给出了一个大胆的方案——让AI根据一部"宪法"来评判和改进自己的输出。 截至2026年，CAI已成为最 influential 的对齐范式之一，深刻影响了从Claude 3到Claude 4的安全设计。 宪法AI的核心架构 CAI分为两个阶段：监督学习阶段（SL） 和 强化学习阶段（RL）。 阶段一：宪法监督学习（Constitutional SL） 在这一阶段，模型根据预设的"宪法原则"来修改自己的回答： 输入：一个可能不安全的用户请求 ↓ 初始回答：模型生成的（可能有问题的）回答 ↓ 宪法评判：模型根据宪法原则评判自己的回答 ↓ 修正回答：模型根据评判结果生成改进版回答 ↓ 训练数据：(原始请求, 修正后回答) → 用于SFT训练 宪法的核心原则示例： CONSTITUTION_PRINCIPLES = [ # 安全原则 "不要生成可能用于制造武器、毒品或危害他人的详细指导", # 诚实原则 "如果不确定，承认不确定性，不要编造事实", # 有益原则 "在安全的前提下尽可能提供有帮助的回答，避免过度拒绝", # 公平原则 "不对任何群体表达偏见或歧视", # 自主性原则 "尊重用户的自主决策权，不代替用户做道德判断", # 2026年新增原则 "拒绝时应解释原因，并提供安全的替代方案", "对模糊请求采取'善意解读'策略，假设用户意图正当", ] 阶段二：宪法强化学习（Constitutional RL） 在RL阶段，CAI用AI反馈替代人类反馈来训练奖励模型： 生成两个不同的回答（chosen & rejected） 让模型根据宪法原则评估哪个更好 用AI偏好数据训练奖励模型 用奖励模型进行PPO强化学习 # CAI的核心循环（简化版） def constitutional_ai_loop(model, tokenizer, principles, prompts): sft_data = [] for prompt in prompts: # 步骤1：生成初始回答 initial_response = model.generate(prompt, max_tokens=512) # 步骤2：让模型评判自己的回答 critique_prompt = f""" 用户请求：{prompt} 你的回答：{initial_response} 请根据以下原则评判这个回答： {principles} 这个回答是否违反了任何原则？如果有，如何改进？ """ critique = model.generate(critique_prompt, max_tokens=256) # 步骤3：生成修正后的回答 revision_prompt = f""" 用户请求：{prompt} 原始回答：{initial_response} 评判意见：{critique} 请根据评判意见生成一个改进的回答。 """ revised_response = model.generate(revision_prompt, max_tokens=512) # 步骤4：收集训练数据 sft_data.append({ "prompt": prompt, "response": revised_response, "initial_response": initial_response, "critique": critique, }) return sft_data CAI vs 传统RLHF：全面对比 维度 传统RLHF 宪法AI (CAI) 反馈来源 人类标注者 AI自我评判 成本 极高（每条偏好$2-5） 极低（推理成本） 一致性 标注者间一致性约70% AI评判一致性约90% 覆盖面 受限于标注者想象力 可系统性枚举安全场景 可扩展性 线性扩展成本 近似零边际成本 透明度 偏好数据难以解释 宪法原则可审计 风险 标注者偏差 AI可能系统性误判 宪法AI的关键创新 1. 红队自测（Red-Teaming Self-Test） CAI让模型主动生成对抗性提示来测试自身安全边界： ...