技术原理

什么是幻觉？ 幻觉（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： ...

AI视频生成的技术跃迁 2024年OpenAI发布Sora，AI视频生成从"能动"走向"能看"。到2026年，视频生成已经发展出完整的技术栈和商业生态。 技术路线全景 路线一：扩散模型+时空注意力（主流） Sora采用的核心架构是DiT（Diffusion Transformer）： 噪声视频块 → 去噪(迭代) → 清晰视频 关键组件: - 时空Transformer：处理空间和时间维度的联合注意力 - 时空Patch：将视频切分为时空块（类似ViT的patch机制） - 扩散过程：从纯噪声逐步去噪到清晰视频 核心创新是"时空Patch"机制： 将视频分解为时空立方体 每个patch作为token输入Transformer 类比：文本token→视频时空token 好处：统一的框架，可处理不同分辨率和时长 路线二：自回归模型 将视频帧序列视为token序列，用next-token prediction方式生成： 每帧量化为离散token 自回归生成帧序列 代表：VideoPoet、Kinetix 优势：天然支持文本条件 劣势：时间一致性不如扩散模型 路线三：掩码建模 类似MAE（Masked Autoencoder），随机遮蔽部分帧后重建： 训练：随机遮蔽视频帧，学习重建 推理：从部分帧"补全"完整视频 优势：速度快（只需1-2次forward而非50步去噪） Sora架构深度分析 时空Patch化 输入视频被切分为时空patch： 空间维度：每16×16像素为一个patch 时间维度：每4帧为一个时间块 每个patch编码为一个向量 这种设计让模型天然支持不同分辨率和长宽比——不需要裁剪到固定尺寸。 扩散Transformer 去噪过程在patch token空间中进行： x_t = 噪声视频tokens t = 扩散时间步 c = 文本条件(text encoding) ε = DiT(x_t, t, c) # 预测噪声 x_{t-1} = 去噪一步(x_t, ε) DiT使用大规模Transformer（数十亿参数），支持长序列的时空建模。 ...

AI算力市场的变与不变 过去三年，AI芯片市场经历了前所未有的变化。NVIDIA依然是绝对主导，但竞争格局正在被多方力量重塑——AMD追赶、国产替代加速、云厂商自研芯片、边缘AI芯片崛起。 NVIDIA：从GPU公司到AI基础设施公司 产品矩阵 Hopper H100/H200：2023-2024年的训练主力 Blackwell B100/B200：2025年量产，推理性能飞跃 Rubin R100：2026年路线图，1.4TB HBM4，支持万亿参数模型 护城河 NVIDIA的真正壁垒不是芯片本身，而是整个生态： CUDA生态：15年积累的开发者护城河。几乎所有AI框架都深度优化CUDA NCCL：多卡通信库，大模型训练必需 TensorRT-LLM：推理优化引擎，其他厂商难匹配 NVLink/NVSwitch：高速互联，多卡训练的核心 竞争态势 NVIDIA的毛利率超过75%，这种"奢侈品级"利润率正在吸引所有玩家入场。但短期内其生态优势难以撼动。 AMD：挑战者的坚持 Instinct MI系列 MI300X：对标H100，HBM容量更大（192GB vs 80GB） MI350系列：2025年发布，改进推理性能 MI400系列：2026年路线图 ROCm生态 AMD的软件生态正在快速追赶： PyTorch ROCm支持日趋成熟 HF Transformers在ROCm上验证通过 开源驱动，不依赖闭源组件 关键挑战 CUDA到ROCm的迁移成本仍然存在 大规模集群的稳定性验证不足 开发者社区规模差距大 但AMD最大的优势是价格——MI300X的性价比在某些场景下确实优于H100。 华为昇腾：国产替代的标杆 硬件路线 昇腾910B：对标A100，7nm工艺 昇腾910C：2025年量产，性能对标H100 昇腾920：2026年路线图，预期对标H200 CANN软件栈 华为构建了完整的软件栈： CANN（Compute Architecture for Neural Networks） MindSpore框架（对标PyTorch） MindIE推理引擎（对标TensorRT） 实际适配情况 支持3B-70B模型训练和推理 与主流框架的适配通过插件实现 大规模训练稳定性仍有提升空间 生态挑战 开发者社区规模远小于CUDA生态 迁移成本高，需要改代码 第三方工具链支持不足 Google TPU：内部驱动+外部服务 TPU v5/v6 v5p：适合大模型训练，性能约为H100的1.5倍 v6：2025-2026部署，推理性能大幅提升 软件生态 JAX/XLA：Google力推的ML框架 PaxML：大模型训练框架 Triton后端支持 特点 TPU是面向大模型的专用芯片： ...

多模态的意义 真实世界的信息本就是多模态的——文字、图像、声音、视频。纯文本大模型只能理解被"文字化"的世界，而多模态模型直接感知原始信号，能力上限更高。 技术演进路线 阶段一：双塔模型（CLIP时代） CLIP开创了图文对齐的标准范式： 图像 → Image Encoder → 图像向量 I ∈ R^d 文本 → Text Encoder → 文本向量 T ∈ R^d 对比损失: 最大化匹配对的相似度，最小化不匹配对的相似度 CLIP的核心贡献是证明了"大规模弱监督预训练"的有效性——用4亿图文对训练，不需要精细标注。 但双塔模型有根本限制：图文交互只在最终向量层发生，无法做细粒度的图文理解（如"图片左上角的红色物体是什么"）。 阶段二：桥接模型（BLIP/LLaVA时代） 桥接模型用一个适配层将视觉特征"翻译"到语言空间： 图像 → ViT → 视觉特征 → MLP Projector → 语言特征 tokens ↓ 文本 prompt + 视觉tokens → LLM → 回答 LLaVA的关键创新： 用GPT-4生成图文指令数据 两阶段训练：先训projector，再SFT 证明了"视觉编码器+投影层+LLM"的简洁架构有效 局限： 视觉token数量固定，不能动态调整 投影层能力有限，可能丢失视觉信息 训练分阶段，无法端到端优化 阶段三：原生多模态（GPT-4V/Qwen-VL时代） 原生多模态模型将视觉编码器和语言模型在预训练阶段就联合训练： 关键设计： 视觉编码器提取多分辨率特征 视觉token可变长（根据图像复杂度动态生成不同数量token） 在预训练阶段就混合图文数据 支持任意位置插入图像token Qwen-VL的技术细节： 图像 → ViT(变体) → 图像token序列 → 位置感知的adapter → 与文本token拼接 → Qwen LLM处理 Qwen-VL支持动态分辨率：大图像生成更多token，小图像生成更少token。通过这种方式保留了图像细节。 ...

为什么需要对齐？ 大模型在预训练阶段从海量互联网文本中学习了知识和语言能力，但也继承了人类文本中的偏见、有害信息和不良价值观。对齐（Alignment）的目标是让模型的行为符合人类期望——有用（helpful）、诚实（honest）、无害（harmless）。 RLHF：经典三阶段 阶段一：SFT（监督微调） 用人类标注的高质量对话数据微调基座模型，让模型学会"怎么回答"。这一步不改变模型的知识储备，主要塑造输出格式和交互方式。 阶段二：奖励模型训练 训练一个奖励模型（Reward Model, RM）来评估回答质量： 对同一个prompt，让模型生成多个回答 人类标注员对这些回答做偏好排序（A>B>C） 训练RM，使其对人类偏好的排序准确率最大化 奖励模型的目标函数： L = -E[log(σ(r(x,y_w) - r(x,y_l)))] 其中y_w是偏好回答，y_l是不偏好回答，r是RM的标量输出。 阶段三：PPO强化学习 用RM的分数作为奖励信号，通过PPO算法优化模型策略： r_total = r_RM(x,y) - β·KL[π_new(y|x) || π_ref(y|x)] KL惩罚项防止模型偏离参考模型太远（避免"奖励黑客"问题——模型钻RM的漏洞产生高奖励但无意义的输出）。 RLHF的痛点 成本高：需要大量人类标注，RM训练和PPO训练各需一轮 不稳定：PPO对超参数敏感，训练容易崩溃 奖励黑客：模型学会欺骗RM而非真正提升质量 DPO：简化路线 Direct Preference Optimization（DPO）的核心洞察是：RLHF的最优策略可以用闭式解表示，不需要显式训练奖励模型和强化学习。 DPO直接从偏好数据中优化模型，目标函数： L_DPO = -E[log σ(β·(log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x)))] DPO的优势 无需训练独立的奖励模型 无需PPO，训练稳定 计算成本约为RLHF的1/3 效果接近甚至优于RLHF DPO的变体 方法 改进 IPO 引入正则化，防止过拟合偏好数据 KTO 不需要成对比较，只需二元标注 ORPO 将SFT和对齐合并为一步训练 SimPO 去除参考模型，更简单高效 Constitutional AI：自我对齐 Anthropic提出的Constitutional AI（CAI）路线，核心思想是让AI自己监督自己： 用少量人类编写的规则（“宪法”）作为准则 模型生成回答后，用模型自己评估回答是否违反规则 模型自我修正后，用修正后的数据做SFT 用模型生成的偏好对训练奖励模型 宪法规则示例 规则1：不要生成歧视性内容 规则2：拒绝有害请求但不生硬 规则3：当不确定时，承认不确定性 CAI的流程 用户prompt → 模型生成回答A → 模型自我评估(按宪法) → 修正为回答B → (A, B)作为偏好对 → 训练RM → RLHF/PPO CAI的最大优势是减少对人类标注的依赖，可扩展性更好。Claude系列模型的对齐核心就是CAI。 ...

MCP是什么？为什么需要它？ Model Context Protocol（MCP）是Anthropic在2024年底提出的开放协议，目标是标准化AI模型与外部工具/数据源的连接方式。在MCP之前，每个Agent框架都自定义工具调用接口——LangChain有tools格式，OpenAI有function calling schema，AutoGPT又是一套——导致工具开发者需要为每个框架写适配层。 MCP的价值主张很简单：一次开发，处处可用。写一个MCP Server，任何支持MCP的客户端都能调用。 协议架构 客户端-服务器模型 MCP采用客户端-服务器架构： [Host App (Claude Desktop)] ├── MCP Client A ←→ [MCP Server A: 文件系统] ├── MCP Client B ←→ [MCP Server B: 数据库] └── MCP Client C ←→ [MCP Server C: GitHub] Host：集成MCL客户端的应用（如Claude Desktop、IDE、Agent框架） MCP Client：在Host内部，每个连接维护一个客户端实例 MCP Server：提供工具、资源、提示的独立进程 传输层 MCP支持两种传输方式： stdio：标准输入输出，适合本地工具（文件系统、本地数据库） SSE（Server-Sent Events）：HTTP+SSE，适合远程服务 JSON-RPC 2.0作为消息格式，请求和响应都是标准的JSON-RPC消息。 消息类型 MCP定义了三种核心原语： 原语 方向 用途 Tools 模型→Server 执行操作（查询数据库、调API） Resources Server→模型 提供数据（文件内容、配置） Prompts Server→用户 提供预设提示模板 工具定义格式 MCP Server通过tools/list端点声明可用工具： ...

朴素RAG的局限性 标准RAG流程很简单：文档分块→向量化→检索top-k→拼接到prompt→生成回答。但在实际场景中，朴素RAG面临几个核心问题： 检索不准：用户查询与文档语义空间不匹配 排序不佳：向量相似度高≠回答有用 上下文冗余：top-k中可能包含大量无关内容 无法自纠错：检索不到就硬编答案 检索层优化 混合检索 纯向量检索擅长语义匹配但弱于精确关键词。BM25等稀疏检索正好互补。混合检索的实践方案： 向量检索（Dense）：召回语义相关段落 关键词检索（Sparse/BM25）：召回精确匹配段落 融合排序：RRF（Reciprocal Rank Fusion）算法合并两路结果 def rrf_fusion(dense_results, sparse_results, k=60): scores = {} for rank, doc in enumerate(dense_results): scores[doc.id] = scores.get(doc.id, 0) + 1/(k + rank) for rank, doc in enumerate(sparse_results): scores[doc.id] = scores.get(doc.id, 0) + 1/(k + rank) return sorted(scores.items(), key=lambda x: -x[1]) 查询改写 用户的原始query往往不是最佳检索query。通过LLM对查询进行改写： 查询扩展：生成多个语义变体query，分别检索后合并 HyDE：先让LLM生成一个假设性回答，用该回答的embedding去检索（对长尾问题效果显著） 子问题分解：复杂问题拆成多个子问题分别检索 重排序（Reranking） 向量检索的召回质量参差不齐。在召回后加一个cross-encoder重排层： 向量检索召回top-50（宽召回） Cross-encoder（如bge-reranker-v2）对每对(query, doc)打分 按分数取top-5（精排序） Cross-encoder比bi-encoder准确率高20-30%，但速度慢，所以做两阶段检索。 生成层优化 上下文压缩 检索回来的文档可能很长，需要压缩到LLM能高效处理的篇幅： 提取式：用小模型抽取关键句子 摘要式：LLM对每个文档生成精简摘要 LLMLingua：基于困惑度删除低信息token，可压缩到原长的1/10 引用标注 高质量RAG需要可溯源。实现方式： 在prompt中要求模型标注引用段落编号 后处理时验证引用的段落确实支持该陈述 不支持的引用标记为"未验证" 自适应RAG：让模型决定怎么检索 Self-RAG Self-RAG让模型学会自主决定： 是否需要检索（通过特殊token [Retrieve]/[No Retrieve]） 检索到的段落是否相关（[Relevant]/[Irrelevant]） 回答是否被段落支持（[Supported]/[Partially Supported]） 这种方式将检索决策内化为模型能力，需要通过强化学习训练。 CRAG（Corrective RAG） CRAG在检索后增加一个"检索评估器"： 评估检索结果质量：Correct / Ambiguous / Incorrect 如果Incorrect，触发web搜索补充 如果Ambiguous，将检索结果与web结果合并 对最终结果重排序后生成 Adaptive-RAG 根据查询复杂度自适应选择策略： 简单查询→单次检索 复杂查询→多跳检索+推理 分类器判断查询类型，路由到对应处理流水线 工程实践要点 评估体系 RAG系统必须有量化评估。推荐使用RAGAS框架，四个核心指标： ...