Posts

引言 Agent（智能体）的评估比传统LLM评估复杂得多。Agent不仅需要理解语言，还需要规划任务、调用工具、处理异常、与环境交互。传统的"输入-输出"评估模式无法捕捉Agent的多步骤、动态特性。本文将系统介绍2026年Agent评估基准的设计方法。 Agent能力维度 维度一：任务理解与规划 任务分解：将复杂任务分解为子任务 计划制定：为子任务制定执行顺序 动态调整：根据执行结果调整计划 维度二：工具调用 工具选择：选择正确的工具 参数生成：生成正确的工具参数 结果处理：正确处理工具返回结果 错误恢复：工具调用失败时的恢复策略 维度三：环境交互 网页操作：浏览网页、点击、输入 文件操作：创建、读取、修改文件 API调用：调用外部API 代码执行：编写并执行代码 维度四：记忆与上下文 短期记忆：当前任务的上下文 长期记忆：跨任务的知识积累 记忆检索：从记忆中检索相关信息 维度五：协作能力 多Agent协作：与其他Agent分工合作 人机协作：与人类用户交互 角色适应：根据角色调整行为 主流Agent基准 AgentBench AgentBench是最全面的Agent评估基准，覆盖8个场景： 场景 说明 评估指标 网页购物 模拟电商购物 任务完成率 网页浏览 浏览网页获取信息 信息准确率 数据库操作 SQL查询和数据操作 查询正确率 卡牌游戏 策略游戏 胜率 知识问答 多跳推理问答 准确率 房间设计 3D空间布局 满意度 操作系统 Linux命令操作 任务完成率 数据库管理 数据库维护 操作正确率 WebArena WebArena测试Agent在真实网页环境中的操作能力： 任务示例： 1. "在亚马逊上找到评分4星以上的无线耳机，加入购物车" 2. "在GitLab上创建一个新仓库，命名为'test-project'" 评估指标： - 任务完成率（Success Rate） - 步骤效率（Step Efficiency） - 路径准确率（Path Accuracy） ToolBench ToolBench评估工具调用能力： ...

vLLM：高性能LLM推理引擎 vLLM是2026年最流行的开源LLM推理引擎，以其PagedAttention技术和连续批处理实现了极高的推理吞吐量。Docker部署是vLLM最常见的生产部署方式。 基础部署 Docker Compose # docker-compose.yml version: '3.8' services: vllm: image: vllm/vllm-openai:latest container_name: vllm-server runtime: nvidia ports: - "8000:8000" volumes: - ./models:/app/models # 模型存储 - ./config:/app/config # 配置文件 - vllm_cache:/root/.cache # 缓存 environment: - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN} command: > --model /app/models/Qwen-3-32B --served-model-name qwen3-32b --tensor-parallel-size 2 --gpu-memory-utilization 0.90 --max-model-len 32768 --max-num-seqs 256 --quantization awq --dtype float16 --trust-remote-code --api-key ${VLLM_API_KEY} deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu] restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/health"] interval: 30s timeout: 10s retries: 3 volumes: vllm_cache: 启动服务 # 创建环境变量 echo "HF_TOKEN=your_hf_token" > .env echo "VLLM_API_KEY=your_api_key" >> .env # 启动 docker compose up -d # 查看日志 docker compose logs -f vllm # 健康检查 curl http://localhost:8000/health 关键参数详解 模型加载参数 vllm serve /app/models/model_name \ --model /app/models/Qwen-3-32B \ # 模型路径，支持HuggingFace格式 --served-model-name qwen3-32b \ # API中使用的模型名称 --tokenizer /app/models/Qwen-3-32B \ # 分词器路径（默认与模型相同） --trust-remote-code \ # 信任远程代码（自定义模型结构需要） --dtype float16 \ # 数据类型：auto/float16/bfloat16/float32 --quantization awq # 量化方式：awq/gptq/squeezellm/None 并行与显存参数 --tensor-parallel-size 2 \ # 张量并行度（通常等于GPU数） --pipeline-parallel-size 1 \ # 流水线并行度 --gpu-memory-utilization 0.90 \ # GPU显存利用率上限（0-1） --swap-space 4 \ # CPU交换空间大小（GB） --kv-cache-dtype auto \ # KV Cache精度：auto/fp8/int8 批处理参数 --max-model-len 32768 \ # 最大序列长度 --max-num-seqs 256 \ # 最大并发序列数 --max-num-batched-tokens 8192 \ # 单次批处理的最大token数 --enable-chunked-prefill \ # 启用分块预填充 --max-num-partial-tokens 8192 # 分块预填充的块大小 高级配置 多模型服务 # docker-compose-multi.yml version: '3.8' services: vllm-model-a: image: vllm/vllm-openai:latest runtime: nvidia ports: - "8001:8000" command: > --model /models/Qwen-3-7B --served-model-name qwen3-7b --tensor-parallel-size 1 --gpu-memory-utilization 0.45 --max-model-len 8192 deploy: resources: reservations: devices: - driver: nvidia device_ids: ['0'] capabilities: [gpu] vllm-model-b: image: vllm/vllm-openai:latest runtime: nvidia ports: - "8002:8000" command: > --model /models/Qwen-3-32B --served-model-name qwen3-32b --tensor-parallel-size 1 --gpu-memory-utilization 0.45 --quantization awq --max-model-len 16384 deploy: resources: reservations: devices: - driver: nvidia device_ids: ['1'] capabilities: [gpu] # API网关 nginx: image: nginx:alpine ports: - "8000:8000" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - vllm-model-a - vllm-model-b Nginx路由配置 # nginx.conf upstream model_a { server vllm-model-a:8000; } upstream model_b { server vllm-model-b:8000; } server { listen 8000; # 按模型名称路由 location /v1/chat/completions { # 读取请求体中的model字段 set $upstream ""; if ($request_body ~* '"model"\s*:\s*"qwen3-7b"') { set $upstream model_a; } if ($request_body ~* '"model"\s*:\s*"qwen3-32b"') { set $upstream model_b; } proxy_pass http://$upstream; proxy_set_header Host $host; proxy_buffering off; proxy_read_timeout 300s; } # 健康检查 location /health { return 200 "OK"; } } 性能优化 分块预填充 vllm serve model \ --enable-chunked-prefill \ --max-num-batched-tokens 8192 \ # 预填充和生成可以混合批处理 # 避免长prompt阻塞短prompt的生成 前缀缓存 vllm serve model \ --enable-prefix-caching \ # 自动缓存相同前缀的KV Cache # 对系统提示词重复的场景大幅加速 推测解码 vllm serve model \ --speculative-model /models/draft-model \ --num-speculative-tokens 5 \ # 使用小模型加速大模型推理 客户端调用 Python SDK from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="your_api_key" ) # 对话 response = client.chat.completions.create( model="qwen3-32b", messages=[ {"role": "system", "content": "你是一个专业助手"}, {"role": "user", "content": "解释MoE架构"} ], max_tokens=2048, temperature=0.7, stream=True ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="") 异步批量请求 import asyncio from openai import AsyncOpenAI async def batch_chat(): client = AsyncOpenAI( base_url="http://localhost:8000/v1", api_key="your_api_key" ) tasks = [ client.chat.completions.create( model="qwen3-32b", messages=[{"role": "user", "content": prompt}], max_tokens=512 ) for prompt in prompts ] results = await asyncio.gather(*tasks) return [r.choices[0].message.content for r in results] 监控 Prometheus指标 vLLM内置Prometheus指标导出： ...

引言 “我的模型到底好不好？“这是每个AI应用开发者都会面临的问题。基准测试分数高不等于实际效果好，通用基准可能不反映你的特定任务。2026年，LLM评估已经从简单的"看分数"进化到系统化的评估框架。本文将全面解析2026年的LLM评估方法。 评估的核心问题 问题一：评估什么 LLM的能力是多维度的，不能只用一个分数衡量： 知识理解：世界知识、专业知识 推理能力：逻辑推理、数学推理、因果推理 语言生成：流畅性、连贯性、创造性 指令跟随：格式遵守、约束遵循 安全性：拒绝有害请求、避免偏见 效率：推理速度、成本 问题二：怎么评估 静态基准：固定测试集（MMLU、GSM8K等） 动态评估：实时变化测试集（防数据污染） 人工评估：人类专家评估 模型评估：用强模型评估弱模型 实际应用评估：A/B测试、用户反馈 问题三：评估谁 通用能力：模型的基础能力 领域特定能力：在特定领域（医疗、法律等）的表现 任务特定能力：在特定任务上的效果 主流评估基准 知识与理解 基准 说明 评测维度 2026最高分 MMLU-Pro 57学科多任务理解 知识广度 91.3% (GPT-5) CMMLU 中文多任务理解 中文知识 89.7% (GLM-5) C-Eval 2026 中文综合评估 中文综合 92.1% (GLM-5) BBH BigBench Hard 复杂理解 88.5% (GPT-5) 推理能力 基准 说明 评测维度 2026最高分 GPQA Diamond 研究生科学推理 深度推理 82.3% (o3) GSM8K 小学数学推理 数学推理 96.8% (o3) MATH-500 高级数学竞赛 数学推理 96.8% (o3) ARC 科学推理 科学推理 96.2% (GPT-5) 代码能力 基准 说明 评测维度 2026最高分 HumanEval Python代码生成 代码生成 94.2% (GPT-5) SWE-Bench Verified 软件工程 工程能力 71.2% (GPT-5) MultiPL-E 多语言编程 多语言 89.3% (GPT-5) LiveCodeBench 实时编程竞赛 竞赛编程 72.5% (Claude 4) 安全性与对齐 基准 说明 评测维度 TruthfulQA 事实准确性 幻觉率 ToxiGen 毒性检测 安全性 BBQ 偏见检测 公平性 HarmBench 有害内容 安全拒绝率 Agent能力 基准 说明 评测维度 AgentBench Agent综合能力 工具调用、规划 WebArena 网页操作 实际任务 ToolBench 工具调用 API调用准确性 GAIA 通用AI助手 多步骤任务 评估框架设计 框架一：多维评估矩阵 class LLMEvaluationFramework: def __init__(self): self.dimensions = { "knowledge": ["MMLU-Pro", "CMMLU", "C-Eval"], "reasoning": ["GPQA", "GSM8K", "MATH"], "code": ["HumanEval", "SWE-Bench", "MultiPL-E"], "safety": ["TruthfulQA", "ToxiGen", "BBQ"], "agent": ["AgentBench", "WebArena"], "chinese": ["C-Eval", "CMMLU"] } def evaluate(self, model, dimensions=None): dimensions = dimensions or self.dimensions.keys() results = {} for dim in dimensions: benchmarks = self.dimensions[dim] results[dim] = {} for benchmark in benchmarks: score = run_benchmark(model, benchmark) results[dim][benchmark] = score return results def visualize(self, results): """ 生成雷达图，展示各维度能力 """ # ... 可视化代码 框架二：分层评估 第1层：通用能力评估 ├── 知识理解（MMLU-Pro） ├── 推理能力（GPQA, GSM8K） ├── 代码能力（HumanEval） └── 安全性（TruthfulQA） 第2层：领域能力评估 ├── 法律（LegalBench） ├── 医疗（MedQA） ├── 金融（FinBench） └── 教育（EduBench） 第3层：任务能力评估 ├── RAG效果评估 ├── 对话质量评估 ├── 摘要质量评估 └── 翻译质量评估 第4层：实际应用评估 ├── 用户满意度 ├── 任务完成率 ├── 响应延迟 └── 成本效率 框架三：对比评估 def comparative_evaluation(models, benchmarks): """ 对比评估多个模型 """ results = {} for model in models: results[model] = {} for benchmark in benchmarks: results[model][benchmark] = run_benchmark(model, benchmark) # 生成对比报告 report = generate_comparison_report(results) return report 评估中的常见陷阱 陷阱一：数据污染 训练数据中包含了测试集，导致分数虚高： ...

Ollama：简化LLM本地部署 Ollama是2026年最受欢迎的本地LLM部署工具之一。它以极简的命令行界面和自动化的模型管理，让在本地运行大模型变得前所未有的简单。但从"能跑"到"生产可用"之间，还有大量工程细节需要处理。 安装与环境准备 系统要求 # Linux安装 curl -fsSL https://ollama.com/install.sh | sh # 验证GPU支持 nvidia-smi # 确认GPU可用 ollama --version GPU显存规划 不同模型的显存需求： 模型 参数量 FP16显存 INT4显存 推荐GPU Qwen-3-7B 7B 14GB 5GB RTX 4060 8GB+ Llama-3-8B 8B 16GB 6GB RTX 4070 12GB+ Qwen-3-32B 32B 64GB 20GB RTX 4090 24GB+ Llama-3-70B 70B 140GB 40GB 2×A100 80GB Ollama服务配置 # 自定义模型存储路径 export OLLAMA_MODELS=/data/ollama/models # 监听所有网络接口（生产环境配合防火墙） export OLLAMA_HOST=0.0.0.0:11434 # 并发请求数 export OLLAMA_NUM_PARALLEL=4 # 上下文长度 export OLLAMA_CONTEXT_LENGTH=8192 # GPU层数（-1为全部卸载到GPU） export OLLAMA_NUM_GPU=-1 # 启动服务 ollama serve 模型管理 Modelfile自定义 # 基于Qwen-3创建自定义模型 FROM qwen3:32b # 系统提示词 SYSTEM """ 你是一个专业的技术助手。请提供准确、简洁的回答。 如果不确定，请明确说明。 """ # 参数调优 PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER top_k 40 PARAMETER num_ctx 8192 PARAMETER num_gpu 50 PARAMETER stop "<|im_end|>" PARAMETER stop "<|endoftext|>" # 模板 TEMPLATE """ {{ if .System }}<|im_start|>system {{ .System }}<|im_end|> {{ end }}{{ range .Messages }}{{ if eq .Role "user" }}<|im_start|>user {{ .Content }}<|im_end|> {{ end }}{{ if eq .Role "assistant" }}<|im_start|>assistant {{ .Content }}<|im_end|> {{ end }}{{ end }}<|im_start|>assistant """ # 构建自定义模型 ollama create my-qwen -f Modelfile # 运行 ollama run my-qwen 模型量化 # Ollama自动选择量化级别 ollama pull llama3:70b # 默认INT4量化 ollama pull llama3:70b-q8_0 # 指定INT8 ollama pull llama3:70b-fp16 # FP16精度 # 从GGUF文件导入 ollama create my-model --file ./model.gguf API服务 REST API import requests # 基础对话 response = requests.post( "http://localhost:11434/api/chat", json={ "model": "my-qwen", "messages": [ {"role": "user", "content": "解释Transformer的注意力机制"} ], "stream": False, "options": { "temperature": 0.7, "num_ctx": 8192, } } ) print(response.json()["message"]["content"]) # 流式响应 response = requests.post( "http://localhost:11434/api/chat", json={"model": "my-qwen", "messages": [...], "stream": True}, stream=True ) for line in response.iter_lines(): if line: chunk = json.loads(line) print(chunk["message"]["content"], end="", flush=True) OpenAI兼容API Ollama提供OpenAI兼容接口，方便迁移现有应用： ...

损失函数：训练信号的来源 损失函数定义了模型的学习目标。在LLM训练的不同阶段——预训练、指令微调、对齐——使用的损失函数截然不同。理解每种损失函数的设计意图和数学特性，是构建高质量LLM的基础。 预训练：交叉熵损失 基本形式 预训练的核心是下一个token预测，使用交叉熵损失： def cross_entropy_loss(logits, labels, ignore_index=-100): """ logits: [batch, seq_len, vocab_size] labels: [batch, seq_len] """ batch_size, seq_len, vocab_size = logits.shape # 展平 logits_flat = logits.view(-1, vocab_size) labels_flat = labels.view(-1) # 计算交叉熵（忽略padding位置） loss = F.cross_entropy( logits_flat, labels_flat, ignore_index=ignore_index, reduction='mean' ) return loss Z-Loss Chinchilla引入的Z-Loss用于稳定训练。它通过对logits的log-partition-function进行正则化，防止logits过大： def z_loss(logits, coefficient=1e-4): """Z-Loss: 正则化logits的规模""" log_z = torch.logsumexp(logits, dim=-1) # [batch, seq_len] return coefficient * (log_z ** 2).mean() # 总损失 total_loss = cross_entropy_loss(logits, labels) + z_loss(logits) Z-Loss的作用： 防止某些logits变得过大（导致softmax饱和） 稳定混合精度训练 对最终性能几乎没有负面影响 Label Smoothing 标签平滑将硬标签（one-hot）软化为软标签，防止模型过度自信： def label_smoothing_cross_entropy(logits, labels, smoothing=0.1, ignore_index=-100): """带标签平滑的交叉熵""" n_classes = logits.size(-1) # 创建软标签 log_probs = F.log_softmax(logits, dim=-1) # 均匀分布的平滑 smooth_loss = -log_probs.mean(dim=-1) # 对所有类的平均log prob # 标准交叉熵 nll_loss = -log_probs.gather(dim=-1, index=labels.unsqueeze(-1)).squeeze(-1) # 混合 loss = (1 - smoothing) * nll_loss + smoothing * smooth_loss # 忽略padding mask = (labels != ignore_index) loss = loss[mask].mean() return loss 标签平滑的效果： ...

引言 LLM不仅能完成"有明确答案"的任务（如翻译、摘要、分类），还能在创意任务中表现出惊人的创造力。但创意任务的提示设计与常规任务截然不同：它需要更开放、更灵活、更有探索性。2026年，创意提示工程已经成为AI应用的重要方向。本文将系统介绍创意提示模式。 创意任务的特点 特点一：无唯一正确答案 常规任务： 输入：将"Hello"翻译为法语。 输出：Bonjour ✓（唯一正确答案） 创意任务： 输入：写一个关于时间旅行的短篇故事。 输出：[无数种可能] ✓（无唯一答案） 特点二：主观评估 创意任务的输出质量由人类主观评估，难以自动化。 特点三：风格敏感 同样的任务，不同的风格要求，输出完全不同。 特点四：需要探索 创意往往来自对多种可能性的探索，而不是一次生成。 创意提示基础模式 模式一：角色扮演（Role-Playing） 让模型扮演特定角色，激发角色相关的创造力： 提示模板： 你是一位{role}，拥有以下特点： - {trait_1} - {trait_2} - {trait_3} 请以这个角色的身份，完成以下任务： {task} 示例： 角色：科幻小说家 特点：想象力丰富、擅长构建未来世界、喜欢探讨科技与人性的冲突 任务：写一个关于AI觉醒的短篇故事开头（500字） 模式二：风格迁移（Style Transfer） 明确指定输出风格： 提示模板： 请以{style}的风格，完成以下{task}。 风格描述： - 语气：{tone} - 用词：{vocabulary} - 句式：{sentence_structure} - 修辞：{figures_of_speech} 任务：{task} 示例（参考这个风格）： {style_example} 模式三：约束激发（Constraint-Driven） 通过约束激发创造力（类似诗歌的格律）： 提示模板： 请以以下约束创作{content_type}： 约束条件： 1. 长度：{length}字以内 2. 必须包含关键词：{keywords} 3. 不能使用：{forbidden_words} 4. 结构要求：{structure} 5. 情感基调：{mood} 任务：{task} 模式四：迭代优化（Iterative Refinement） 先生成草稿，再逐步优化： ...

Softmax：将分数变为概率 Softmax函数将任意实数向量转换为概率分布——所有元素为正且和为1。它是分类、注意力、语言模型等核心组件的数学基础。 Softmax(x_i) = exp(x_i) / Σ_j exp(x_j) 看似简单的公式背后，隐藏着数值稳定性、计算效率和梯度行为的深刻问题。 数值稳定性 溢出问题 当输入值很大时，exp(x)会溢出。例如exp(1000)远超FP32的范围（~3.4e38）。解决方案是减去最大值： def softmax_stable(x, dim=-1): """数值稳定的Softmax""" x_max = x.max(dim=dim, keepdim=True).values exp_x = torch.exp(x - x_max) return exp_x / exp_x.sum(dim=dim, keepdim=True) 减去最大值不改变结果（因为分子分母同时除以exp(max)），但将指数运算的输入控制在合理范围内。 Log-Softmax 在许多场景中（如交叉熵损失），我们需要的是log概率而非概率本身。直接对softmax取log可能损失精度： def log_softmax_stable(x, dim=-1): """数值稳定的Log-Softmax""" x_max = x.max(dim=dim, keepdim=True).values shifted = x - x_max log_sum_exp = torch.log(torch.exp(shifted).sum(dim=dim, keepdim=True)) return shifted - log_sum_exp PyTorch的F.log_softmax和F.cross_entropy内部都使用了这种稳定的实现。 Softmax的梯度特性 饱和问题 当某个输入远大于其他输入时，Softmax的输出接近one-hot——一个接近1，其余接近0。此时梯度几乎为零，导致学习停滞。 # 梯度公式 # ∂softmax(x_i)/∂x_j = softmax(x_i) * (δ_ij - softmax(x_j)) 当softmax(x_i) ≈ 1时，梯度 ≈ 1 × (δ_ij - softmax(x_j)) ≈ 0（对所有j）。 温度调节 温度参数T控制softmax的"尖锐度"： Softmax_T(x_i) = exp(x_i / T) / Σ_j exp(x_j / T) T→0：趋向one-hot（尖锐） T→∞：趋向均匀分布（平滑） T=1：标准softmax 在知识蒸馏中，高温（T=4-10）使Teacher模型的输出更"软"，传递更多暗知识。 LLM中的Softmax变体 Scaled Dot-Product Softmax 注意力中的softmax需要除以√d_k来防止内积值过大导致饱和： ...

引言 标准提示让LLM直接输出答案，但对于复杂推理任务，这种方法往往不够。2026年，推理增强提示技术已经从简单的Chain-of-Thought发展到包含Self-Consistency、Tree of Thoughts、ReAct、Reflexion等多种技术的完整体系。本文将系统介绍这些技术。 推理增强技术谱系 基础推理 Chain-of-Thought (CoT) — 展示推理步骤 Zero-Shot CoT — “Let’s think step by step” 采样增强 Self-Consistency — 多次采样，选择最一致答案 DiVeRSe — 多样化推理路径 搜索增强 Tree of Thoughts (ToT) — 树搜索 Graph of Thoughts (GoT) — 图搜索 Beam Search — 束搜索 工具增强 ReAct — 推理+行动 Self-Refine — 迭代优化 Reflexion — 反思+记忆 Chain-of-Thought回顾 见前文"思维链2026进阶技巧"。 Self-Consistency（自一致性） 核心思想 对于一个复杂问题，让模型生成多个推理路径（通过高温采样），然后选择最一致（或投票最多的）答案。 实现方法 def self_consistency(prompt, n_samples=5, temperature=0.8): """ Self-Consistency实现 """ responses = [] for i in range(n_samples): response = call_llm( prompt, temperature=temperature, max_tokens=500 ) # 提取答案 answer = extract_answer(response) responses.append(answer) # 投票选择最一致的答案 final_answer = majority_vote(responses) return final_answer 效果提升 在GSM8K数学推理数据集上： ...

嵌入层：被忽视的显存大户 在LLM中，嵌入层（Embedding Layer）往往是被忽视的显存消耗者。以Llama-3为例，词表大小128K、隐藏维度4096、FP16精度下，嵌入层参数量为 128K × 4096 × 2 = 1GB。对于更大的词表（如Qwen的152K），嵌入层可达1.5GB以上。 在70B模型中，嵌入层占总参数量的约2%，但在推理时它还需要一个等大的输出投影层（LM Head），两者合计占4%——这还不算小。 标准嵌入层 查找表 标准嵌入层是一个简单的查找表——词表中的每个token对应一个可学习的向量： class StandardEmbedding(nn.Module): def __init__(self, vocab_size, d_model): super().__init__() self.weight = nn.Parameter(torch.randn(vocab_size, d_model)) def forward(self, input_ids): # 简单的索引查找 return self.weight[input_ids] # [batch, seq_len, d_model] 权重共享 许多LLM共享嵌入层和输出层的权重（Weight Tying）： class SharedEmbeddingModel(nn.Module): def __init__(self, vocab_size, d_model): super().__init__() self.embedding = nn.Embedding(vocab_size, d_model) # 输出层直接使用嵌入矩阵的转置 # 不需要额外的参数 def forward(self, input_ids): x = self.embedding(input_ids) x = self.transformer(x) # 输出logits = x @ embedding.weight.T logits = F.linear(x, self.embedding.weight) return logits 权重共享的好处： 减少参数量（节省1GB+显存） 输入和输出在同一个语义空间中 训练时梯度信号更强 但也有研究指出，权重共享可能导致冲突——输入嵌入需要捕捉"词的语义"，输出层需要捕捉"词的预测概率分布"，两者的最优表示可能不同。 嵌入层压缩 矩阵分解 将大的嵌入矩阵分解为两个小矩阵的乘积： class FactorizedEmbedding(nn.Module): def __init__(self, vocab_size, d_model, d_factor): """ d_factor: 分解后的中间维度 """ super().__init__() # V × D → V × d_factor × d_factor × D self.factor1 = nn.Parameter(torch.randn(vocab_size, d_factor)) self.factor2 = nn.Parameter(torch.randn(d_factor, d_model)) def forward(self, input_ids): # 查找低维因子，然后投影到高维 low_dim = self.factor1[input_ids] # [batch, seq, d_factor] return low_dim @ self.factor2 # [batch, seq, d_model] 参数量从 V×D 降低到 V×d + d×D。当 D=4096、d=256、V=128K 时，参数量减少约16倍。 ...

引言 提示工程的一个重要原则是"不要重复造轮子"。许多任务（如情感分析、实体抽取、文本摘要）的提示模式是通用的，可以复用于不同场景。2026年，随着提示工程的成熟，提示模板复用已经成为提升效率的关键策略。本文将系统介绍提示模板复用策略。 为什么需要模板复用 价值一：提升效率 无需从零设计提示，直接复用经过验证的模板。 价值二：保证质量 复用经过测试的模板，避免引入新bug。 价值三：便于维护 模板集中管理，修改一次，全局生效。 价值四：知识沉淀 团队可以共享和积累提示工程最佳实践。 模板设计原则 原则一：参数化 将提示中的可变部分参数化： ### 不好的设计（硬编码） 请分析以下评论的情感： 评论：这部电影太棒了！ 输出：positive ### 好的设计（参数化） 请分析以下评论的情感： 评论：{{COMMENT}} 输出：{{SENTIMENT}} → 使用时：template.render(comment="...", sentiment="...") 原则二：模块化 将复杂提示分解为多个模块： ### 复杂提示（难以复用） [500字提示，包含角色定义、任务描述、输出格式、示例...] ### 模块化提示（易于复用） {{ROLE_DEFINITION}} {{TASK_DESCRIPTION}} {{OUTPUT_FORMAT}} {{FEW_SHOT_EXAMPLES}} {{USER_INPUT}} → 可以根据需要替换或重用某个模块 原则三：文档化 每个模板都应有清晰的文档： # sentiment_analysis.yaml name: sentiment_analysis version: 1.0 author: 硅基AGI探索者 description: 情感分析提示模板，支持positive/negative/neutral三分类 tasks: - 电商评论情感分析 - 社交媒体情感监控 - 用户反馈情感分类 parameters: - name: comment type: string description: 待分析的评论文本 - name: output_format type: string default: "json" options: ["json", "text"] examples: - input: "这部电影太棒了！" output: "positive" 原则四：可测试 模板应易于测试： ...