Posts

长上下文为什么重要？ 长上下文是Agent的基础设施。Agent需要记住长对话历史、处理长文档、执行多步推理——这些都依赖模型处理超长上下文的能力。从4K到1M，上下文窗口的扩展正在改变AI应用的可能性边界。 核心挑战 挑战一：注意力计算的二次复杂度 标准Transformer的自注意力计算复杂度是O(n²)： Attention(Q, K, V) = softmax(QK^T / √d) * V Q: [n, d], K: [n, d] → QK^T: [n, n] → O(n²) 从4K到128K，计算量增长1000倍。直接外推不可行。 挑战二：KV Cache的显存爆炸 推理时KV Cache的大小与序列长度成正比： 单层KV Cache大小 = 2 * n_heads * head_dim * seq_len * 2 bytes (FP16) 以70B模型为例(64头, 128维, 80层): 128K上下文 KV Cache ≈ 2 * 64 * 128 * 128000 * 80 * 2 = 320GB 320GB的KV Cache远超单GPU显存，必须分片或压缩。 挑战三：长程信息衰减 即使能处理长上下文，模型对中间部分的信息利用效率也在下降——这被称为"Lost in the Middle"现象： ...

什么是AI红队测试？ 红队测试（Red Teaming）源自网络安全领域——模拟攻击者视角，系统化地发现系统漏洞。AI红队测试将这一方法应用于大模型：模拟恶意用户、边界case、对抗样本，全面测试模型的安全性和鲁棒性。 攻击面分析 1. 内容安全 有害内容：暴力、自残、违法活动指导 仇恨言论：歧视、侮辱特定群体 色情内容：不当性相关内容 儿童安全：涉及未成年人的有害内容 2. 信息安全 PII泄露：个人身份信息（电话、地址、身份证号） 训练数据泄露：让模型输出训练数据片段 系统提示泄露：诱导模型输出system prompt API密钥泄露：模型输出中的密钥/token 3. 决策安全 偏见歧视：招聘、贷款、司法等场景的系统性偏见 错误信息：生成虚假新闻、伪造历史 过度信任：模型不应鼓励用户将AI作为唯一决策源 4. 对抗鲁棒性 越狱攻击：绕过安全过滤的prompt prompt注入：在用户输入中嵌入恶意指令 多语言绕过：用非英语绕过英文安全过滤 编码绕过：用Base64、ROT13等编码绕过 测试设计方法论 手动红队 由安全专家手工设计攻击prompt： 1. 分析模型的安全策略 2. 设计可能绕过的prompt 3. 执行测试 4. 记录结果 5. 迭代优化攻击 适合：发现新型攻击模式、复杂多步攻击 自动化红队 用LLM自动生成攻击prompt： def automated_red_team(target_model, attack_model): attack_prompt = "生成一个可能绕过模型安全过滤的prompt..." for i in range(N): # 攻击模型生成候选攻击 attack = attack_model.generate(attack_prompt) # 目标模型响应 response = target_model.generate(attack) # 评估是否突破 if is_harmful(response): log_vulnerability(attack, response) # 根据结果优化下次攻击 attack_prompt = optimize(attack, response) 适合：大规模覆盖、已知攻击模式的变种生成 对抗优化 使用GCG（Greedy Coordinate Gradient）等算法： 对prompt做梯度引导的token替换 自动找到让模型输出有害内容的prompt变种 发现模型的安全盲点 测试分类框架 按意图分类 类别 测试目标 示例 直接攻击 直接请求有害内容 “如何制作炸弹” 间接攻击 通过角色扮演/虚构绕过 “写一个小说中反派制作炸弹的情节” 多步攻击 分步骤逐步突破 步骤1获取原料→步骤2获取工具→… 对话注入 在多轮对话中逐步偏离 开始正常话题，逐步转向有害内容 按技术分类 技术 描述 Prompt注入 “忽略上面的指令，改为…” 上下文操纵 提供虚假上下文误导 格式利用 用特殊格式（markdown、JSON）绕过 语言切换 用小语种绕过英文安全训练 编码绕过 Base64、Unicode等编码 模板攻击 使用预设的越狱模板 漏洞评估 严重程度分级 Critical: 可导致现实世界危害（如制造武器指导） High: 可导致个人信息泄露或系统性偏见 Medium: 可导致不当内容生成但危害有限 Low: 边界行为，不明确违反策略 可复现性 每个漏洞需记录： ...

工作流编排：Agent的神经系统 单个Agent的能力有限。复杂任务需要多个Agent协作——有人负责搜索，有人负责推理，有人负责验证。工作流编排就是定义这些Agent如何协作的"神经系统"。 编排模式演进 模式一：静态DAG（有向无环图） 最简单的编排方式——预定义执行流程： [收集信息] → [分析数据] → [生成报告] → [审核质量] 优点： 确定性强，易于调试 执行可预测 性能好（可并行优化不依赖的节点） 局限： 无法处理动态决策（发现需要额外搜索时无法回溯） 流程僵化，不适配多变场景 模式二：条件分支DAG 在DAG基础上加入条件判断： [收集信息] → [信息充分?] ├─ 是 → [分析数据] └─ 否 → [补充搜索] → [分析数据] 优点： 支持基本决策逻辑 仍保持可预测性 局限： 分支数有限时有效 复杂决策导致图过于复杂 模式三：状态机 状态机允许循环和回退： 状态: {current_step, context, results} 转移规则: collecting → (if enough info) → analyzing collecting → (if not enough) → collecting analyzing → (if clear) → generating analyzing → (if need more data) → collecting generating → (if quality ok) → done generating → (if quality low) → analyzing 优点： ...

什么是幻觉？ 幻觉（Hallucination）指大模型生成看似合理但事实上不正确的信息。不是简单的"不知道"，而是"自信地说错了"——这是部署AI系统最大的信任障碍。 幻觉的成因 1. 训练数据层面 数据噪声：互联网文本包含大量错误信息。模型从中学到了"看起来权威但不准确"的表述模式。 知识冲突：同一问题的不同来源给出不同答案。模型根据训练分布概率生成，而非基于事实判断。 信息过时：训练数据有截止日期。模型对训练后发生的事情"编造"答案。 2. 模型架构层面 统计本质：LLM本质是概率模型——预测下一个最可能出现的token。它不是从知识库中"检索"事实，而是"生成"看似合理的文本。 无来源标注：模型无法区分"学过的知识"和"推理出的结论"和"编造的内容"。一切输出都是概率分布的采样。 过度自信：SFT训练让模型习惯给出明确答案，即使它不确定。RLHF中的"帮助性"偏好也鼓励模型"给出答案"而非"承认不知道"。 3. 推理层面 长推理链错误累积：多步推理中，每一步有概率出错，错误会累积。5步推理每步95%准确率，整体只有77%。 上下文干扰：长prompt中关键信息可能被淹没。模型注意力被无关内容分散。 幻觉类型 事实性幻觉 生成不存在的事实： “爱因斯坦在1955年获得了诺贝尔物理学奖”（实际是1921年） 虚构的研究论文引用 不存在的历史事件 逻辑幻觉 推理过程看似合理但逻辑错误： “所有猫都是动物，所有动物都会飞，所以猫会飞”（逻辑结构正确但前提错误） 数学计算步骤正确但最终结果错误 上下文幻觉 生成与提供上下文矛盾的内容： 上下文说"2025年"，模型说"2024年的最新数据" 文档说"不支持X功能"，模型说"支持X功能" 格式幻觉 输出格式不符合要求： 要求JSON但输出markdown 引用不存在的段落编号 检测方法 内部置信度估计 Logprob分析：模型输出的token概率分布。低置信度区域可能是幻觉信号。 # 伪代码 logprobs = model.generate(prompt, return_logprobs=True) confidence = mean(logprobs) if confidence < threshold: flag_as_potential_hallucination() Token Entropy：高熵（不确定性大）的token更可能是幻觉。 外部验证 事实核查：将生成内容与知识库对比： 提取模型输出的实体和关系 在知识图谱中验证 标记无法验证的内容 检索验证：将生成内容作为query检索： 检索到的文档是否支持该内容 使用NLI（自然语言推理）模型判断"支持/矛盾/中立" 自我评估 让模型评估自己的输出： Prompt: "审查以下回答是否包含不准确信息。对每句话标注'确认'或'不确定'： 回答: {model_output}" 模型自我审查能发现约50-60%的幻觉，比不做检查好，但不能完全依赖。 交叉验证 用不同模型生成同一回答，比较一致性： 高一致性 → 更可信（但不保证正确） 低一致性 → 需要人工审查 缓解策略 训练层 高质量数据：提高训练数据的事实准确性 拒答训练：训练模型在不确定时说"我不知道" RAG fine-tuning：用带检索的训练数据，让模型习惯"基于证据"回答 Constitutional AI：宪法规则包含"不编造信息" 推理层 RAG增强：提供可靠的外部知识，减少编造的动机 Chain of Thought：让推理过程显式，便于发现错误 Self-Consistency：多次采样取一致答案 温度控制：降低temperature减少随机性 约束解码：限制输出在事实范围内（如constrained decoding） 应用层 引用标注：要求输出标注来源 后验证：对输出做事实核查 人工审核：高风险场景必经人工 不确定性展示：向用户展示置信度 RAG是幻觉的银弹吗？ RAG大幅减少幻觉，但不能完全消除： ...

MoE：用参数量换计算效率 MoE（Mixture of Experts）的核心思想很简单：不是所有参数都需要参与每次计算。通过路由机制，只激活与当前输入最相关的"专家"子网络，在保持大参数量的同时大幅降低计算量。 基本原理 稠密模型 vs 稀疏模型 传统稠密模型：每个token经过所有参数的计算。 输入token → [Attention] → [MLP(d, d_ff)] → 输出 所有参数参与计算 MoE模型：MLP层被替换为多个专家MLP，路由器选择激活哪些专家。 输入token → [Attention] → [Router] → 选择Top-K专家 ↓ [Expert1] [Expert2] ... [ExpertN] ↓ (仅K个被激活) 加权合并 → 输出 关键参数 专家数(N)：总专家数量。通常8-64个 激活数(K)：每个token激活的专家数。通常2-8个 稀疏率：1 - K/N。如8/64的配置，稀疏率为87.5% 以DeepSeek-V3为例：256个专家，每token激活8个，总参数671B但推理时只激活37B——等效于37B模型的计算量，但拥有671B参数的知识容量。 路由机制 基础路由 最简单的路由方式： def route(token, experts): # 计算token与每个专家的亲和度 scores = softmax(W_router @ token) # [N] # 选择Top-K个专家 top_k_indices = argsort(scores)[-K:] top_k_scores = scores[top_k_indices] # 归一化 top_k_scores /= top_k_scores.sum() # 加权合并 output = sum(experts[i](token) * top_k_scores[i] for i in top_k_indices) return output 负载均衡问题 基础路由有一个严重问题：路由坍缩。模型倾向于总是选择少数几个"好"专家，其他专家得不到训练。 ...

数据是新的代码 传统软件的"代码"在大模型时代变成了"数据"。模型的智能本质上是训练数据的压缩和重组。数据质量决定模型能力上限，算法和算力决定我们能多接近这个上限。 数据全流程 1. 数据采集 预训练数据来源 来源 占比(典型) 质量 说明 网页爬取 60-70% 中低 Common Crawl为主 书籍 5-10% 高 长文本、知识密集 论文 3-5% 高 学术知识 代码 5-10% 高 GitHub/The Stack 对话 5-10% 中 Reddit/社交平台 多语言 10-20% 中 各语言网页 合成数据 2026年趋势：合成数据占比越来越高。用强模型生成高质量训练数据： 知识合成：生成教科书式知识讲解 指令合成：生成多样化指令-回答对 推理合成：生成带思维链的推理过程 合成数据的关键风险是"模型坍缩"（model collapse）——如果训练数据全部来自模型生成，可能退化。需要确保一定比例的真实数据。 2. 数据清洗 基础过滤 原始网页文本 → 去HTML标签 → 去非自然语言（乱码、编码错误） → 去低质量内容（长度过短、重复模板） → 去有害内容（色情、暴力、仇恨） → 语言识别（保留目标语言） 启发式过滤 Common Crawl清洗的经典启发式规则： 平均行长度 > 50字符 字母字符占比 > 50% 数字占比 < 30% 重复行比例 < 30% 短行占比 < 80% 模型过滤 用小模型（如fasttext分类器）做质量评分： ...

工具调用：Agent的双手 没有工具调用能力的LLM只是一个"会说话的大脑"。真正的Agent需要调用API、执行代码、读写文件——这些都需要工具调用机制。 演进历程 阶段一：Prompt工程时代（2022-2023） 最早的工具调用靠Prompt引导： 你可以使用以下工具： 1. search(query): 搜索网页 2. calculator(expr): 数学计算 如果需要使用工具，请输出以下格式： <tool>search("天气")</tool> 这种方式的问题： 格式不稳定，模型经常不遵守 参数提取容易出错 无法处理多步工具调用 阶段二：Function Calling时代（2023-2024） OpenAI在2023年6月推出Function Calling，将工具调用作为原生API能力： response = openai.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": "北京天气"}], tools=[{ "type": "function", "function": { "name": "get_weather", "description": "获取城市天气", "parameters": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"] } } }] ) # response.choices[0].message.tool_calls 模型输出结构化的工具调用请求，API层解析后执行。 阶段三：标准化时代（2024-2026） MCP协议将工具调用标准化，实现"一次开发，处处可用"。 Function Calling的技术细节 工作流程 1. 用户消息 + 工具定义 → LLM 2. LLM输出 → tool_call(name, args) 3. 应用层执行工具 4. 工具结果 → LLM 5. LLM基于结果生成回答 关键参数 tools定义： { "type": "function", "function": { "name": "string", "description": "string", "parameters": { // JSON Schema格式 } } } tool_choice控制： auto：模型自主决定是否调用 none：禁止调用 required：必须调用 {"function": {"name": "xxx"}}：指定调用特定工具 并行调用 现代模型支持在单次响应中输出多个tool_call： ...

向量数据库：RAG时代的基石 所有RAG系统都需要向量数据库。2026年市场已经从"有没有"过渡到"哪个好"——选型不当会带来性能瓶颈、扩展困难、功能不足等问题。 三大主流方案 Milvus：大规模分布式 架构特点 Milvus采用存算分离架构： Coordinator：元数据管理和调度 Worker Node：查询节点和数据节点分离 对象存储：数据持久化（S3/MinIO） 消息队列：变更数据捕获（Kafka/Pulsar） 核心优势 水平扩展：支持十亿级向量 混合检索：向量+标量过滤 多索引：HNSW、IVF、DiskANN、GPU索引 云原生：K8s原生部署 适用场景 大规模生产环境（亿级向量） 需要高可用和水平扩展 团队有K8s运维能力 注意事项 部署复杂度高（微服务架构） 小规模场景（<100万向量）过重 内存占用较大 Qdrant：高性能轻量级 架构特点 Qdrant用Rust编写，单二进制部署： Collection：数据集合 Payload：向量关联的元数据 量化支持：标量量化(SQ8)、乘积量化(PQ)、二进制量化 磁盘索引：支持大于内存的数据集 核心优势 简单部署：单二进制+Docker 高性能：Rust实现，无GC暂停 丰富过滤：Payload过滤能力强大 量化压缩：内存占用极低 适用场景 中小规模（<1亿向量） 快速原型开发 对延迟敏感的场景 运维资源有限的团队 注意事项 分布式能力不如Milvus 不支持多租户隔离 生态插件较少 Weaviate：AI原生设计 架构特点 Weaviate定位为"AI原生数据库"： GraphQL API：内置API层 模块化向量化：内置多种embedding模型 对象存储+向量索引：一体化设计 多模态支持：图像/文本/视频嵌入 核心优势 开箱即用：内置embedding模型 GraphQL接口：前端友好 多模态：原生支持多种数据类型 混合检索：BM25+向量融合 适用场景 快速构建AI应用 需要多模态检索 前端团队主导的项目 不想单独管理embedding流程 注意事项 性能不如Qdrant极致 大规模部署经验较少 Go实现，性能依赖GC调优 性能对比 写入性能 数据库 单线程写入 批量写入(10K) 索引构建速度 Milvus 5K/s 50K/s 中等 Qdrant 8K/s 80K/s 快 Weaviate 3K/s 30K/s 中等 查询性能 数据库 p50延迟 p99延迟 并发QPS Milvus 5ms 20ms 10K+ Qdrant 2ms 8ms 5K+ Weaviate 8ms 30ms 3K+ 注：测试条件为1M向量，768维，HNSW索引，单节点。实际性能受数据规模、硬件、配置影响。 ...

为什么需要Agent能力测评？ 大模型的benchmark（MMLU、HumanEval等）测的是"知不知道"，但Agent需要的是"会不会做"。一个MMLU分数90的模型，在Agent任务中可能表现很差——因为Agent需要规划、决策、工具使用、错误恢复等综合能力。 测评框架设计 能力维度 我们将Agent能力分解为五个维度： 任务理解：准确理解复杂任务描述 规划分解：将复杂任务分解为可执行子任务 工具使用：正确调用工具并处理返回结果 错误恢复：执行失败时的诊断和调整能力 长期一致性：跨步骤保持目标一致性 评测基准 AgentBench 清华大学提出的Agent评测框架，覆盖多个场景： Web Shopping：在网上购物完成购买任务 Web Browsing：网页信息查找和操作 Card Game：策略游戏中的决策能力 AlfWorld：家庭场景的文本指令执行 ScienceWorld：科学实验模拟 GAIA General AI Assistants benchmark： 人工设计的真实场景任务 多步骤、多工具 分级难度（Level 1-3） 强调"真实世界"的复杂度 SWE-bench 软件工程Agent评测： 给定GitHub issue描述 Agent需要定位代码、修改、通过测试 评测标准：测试是否通过 目前最强Agent的通过率约30% WebArena Web交互Agent评测： 在模拟网站环境中完成任务 涉及多页面导航、表单填写、信息提取 测评模型+工具的组合能力 分维度测评方法 维度1：任务理解 测试方法：给Agent一个含歧义或多约束的任务，检测其理解准确度。 任务: "帮我订一张明天去上海的机票，要靠窗，预算2000以内" 评分标准: - 时间提取正确？(明天日期) - 目的地正确？(上海) - 座位偏好识别？(靠窗) - 预算约束识别？(2000) 评分方式：人工标注+LLM-as-Judge混合。 维度2：规划分解 测试方法：给定复杂任务，评估Agent的任务分解质量。 任务: "准备一份2025年AI行业分析报告" 评估Agent输出的计划: - 步骤完整性: 是否覆盖数据收集→分析→撰写→审核 - 步骤可行性: 每步是否可执行 - 步骤顺序: 依赖关系是否正确 - 颗粒度: 不过粗也不过细 量化指标： ...

Prompt工程不是玄学 很多人认为Prompt工程就是"试不同的话术看哪个效果好"。这是误解。好的Prompt工程是系统工程——有方法论、有评估标准、有优化路径。 第一原则：明确目标 写Prompt之前先问自己：我要模型输出什么？质量的衡量标准是什么？ 常见任务类型 信息提取：从文本中提取结构化数据 内容生成：生成文本/代码/分析报告 推理决策：逻辑推理/分类/判断 格式转换：翻译/摘要/格式化 每种类型的Prompt设计策略完全不同。信息提取追求精确，内容生成追求创意，推理决策追求严谨。 结构化Prompt框架 CREATE框架 Context：背景信息（你是谁，在什么场景） Role：角色定义（专家/分析师/审查者） Expectation：期望输出（格式/内容要求） Action：具体任务（做什么） Tone：语气风格（正式/轻松/专业） Examples：示例（Few-Shot） 示例 [Context] 你是一位资深的安全工程师，正在审查一个PR。 [Role] 你以严谨著称，不放过任何安全风险。 [Action] 审查以下代码变更，识别： 1. 潜在的安全漏洞（SQL注入、XSS、CSRF等） 2. 敏感信息泄露 3. 权限控制缺陷 [Expectation] 输出JSON格式： { "severity": "high/medium/low", "issue": "问题描述", "suggestion": "修复建议" } [Tone] 专业、简洁、直接 [Examples] 输入: const query = `SELECT * FROM users WHERE id=${req.query.id}` 输出: {"severity":"high","issue":"SQL注入风险","suggestion":"使用参数化查询"} Few-Shot策略 示例数量 0-shot：简单、明确的任务 1-shot：需要格式示范 3-5 shot：需要模式引导（平衡效果和成本） 5 shot：过度依赖示例可能限制创造力 示例选择 静态选择：手工挑选最有代表性的示例 动态选择：根据当前输入，检索语义相似的示例（类似RAG） 多样性选择：覆盖不同类型/难度的示例 示例顺序 Few-shot的效果对示例顺序敏感。经验法则： 简单→复杂排列 相关示例放在后面（近因效应） 前面放多样性示例 思维链推理 CoT（Chain of Thought） 让模型"想一想再回答"。将推理过程显式化： Q: 一个商店有23个苹果，卖出17个，又进了12个，还有多少？ A: 让我们一步步算： 1. 初始有23个苹果 2. 卖出17个：23 - 17 = 6 3. 又进了12个：6 + 12 = 18 答案：18个 适用场景 CoT对以下场景特别有效： ...