Posts

对齐问题的紧迫性 当AI能力接近或超越人类水平时，传统的对齐方法（RLHF、DPO）面临根本性挑战：人类评估者能否准确判断超人类能力的输出？我们能否理解模型的内部推理过程？这些开放问题将决定AGI是否安全可控。 可扩展监督 人类评估的天花板 RLHF依赖于人类对模型输出的偏好判断。当模型能力超过人类评估者时，这种监督机制失效： 代码生成：人类评估者无法判断复杂算法的正确性 数学推理：人类评估者可能无法验证高级数学证明 科学研究：人类评估者无法评估前沿科学假设 Scalable Oversight方案 AI辅助人类评估：用AI帮助人类评估AI输出： class ScalableOversight: def __init__(self, target_model, assistant_model, human_evaluator): self.target = target_model # 被评估的强模型 self.assistant = assistant_model # 辅助评估的模型 self.human = human_evaluator # 人类评估者 def evaluate(self, question, answer): # 1. 强模型生成回答 # 2. 辅助模型生成评估报告 critique = self.assistant.generate(f""" 评估以下回答的正确性和质量： 问题：{question} 回答：{answer} 重点检查： - 事实准确性 - 逻辑一致性 - 是否遗漏重要信息 """) # 3. 人类基于AI评估报告做最终判断 human_decision = self.human.evaluate( question, answer, critique ) return human_decision Debate方法：两个AI辩论，人类裁判判断谁对： AI-A: 主张X是正确的，理由是... AI-B: 反对，X忽略了这个因素... AI-A: 这个因素不重要，因为... AI-B: 但数据显示... 人类裁判: B的论点更有说服力 Recursive Reward Modeling：分层递进地训练奖励模型： ...

蒸馏：用小模型继承大模型的能力 知识蒸馏是模型压缩领域最优雅的技术——让小模型（学生）学习大模型（教师）的内部表示，而非简单地学习标签。一个好的蒸馏方案可以让7B模型逼近70B模型的效果。 Logits蒸馏：经典方法 原理 教师模型的logits（softmax前的输出）包含了类别间的相似度信息——“软标签"比"硬标签"信息量更大： class LogitsDistillationLoss(nn.Module): def __init__(self, temperature=2.0, alpha=0.5): self.temperature = temperature self.alpha = alpha # 蒸馏loss与CE loss的权重比 def forward(self, student_logits, teacher_logits, labels): # 蒸馏损失：KL散度 soft_teacher = F.log_softmax( teacher_logits / self.temperature, dim=-1 ) soft_student = F.log_softmax( student_logits / self.temperature, dim=-1 ) distill_loss = F.kl_div( soft_student, soft_teacher.exp(), reduction="batchmean" ) * (self.temperature ** 2) # 标准交叉熵损失 ce_loss = F.cross_entropy(student_logits, labels) return self.alpha * distill_loss + (1 - self.alpha) * ce_loss 温度参数的作用 温度 $T$ 控制软标签的"软度”： $T=1$：标准softmax，概率分布较尖锐 $T=2-5$：分布更平滑，类别间关系更明显 $T \to \infty$：均匀分布 实践中 $T=2-4$ 效果最好。温度的平方项补偿了梯度缩放——高温softmax的梯度会被 $1/T^2$ 缩小。 在线蒸馏vs离线蒸馏 离线蒸馏：先训练好教师模型，再蒸馏学生模型。简单稳定但教师的错误会被继承。 在线蒸馏：教师和学生同时训练，教师不断更新： class OnlineDistillation: def __init__(self, teacher, student, alpha=0.5): self.teacher = teacher self.student = student self.alpha = alpha def train_step(self, batch): # 教师前向（不更新梯度） with torch.no_grad(): teacher_logits = self.teacher(batch) # 学生前向 student_logits = self.student(batch) # 蒸馏损失 distill_loss = self._distill_loss(student_logits, teacher_logits) ce_loss = F.cross_entropy(student_logits, batch["labels"]) loss = self.alpha * distill_loss + (1 - self.alpha) * ce_loss loss.backward() 特征蒸馏：学习中间表示 原理 Logits蒸馏只利用了最终输出，特征蒸馏还利用了中间层的表示： ...

规划：Agent的核心能力 AI Agent与聊天机器人的本质区别在于规划能力——将复杂目标分解为可执行步骤并动态调整的能力。从简单的ReAct循环到复杂的树搜索规划，Agent规划算法经历了快速演进。 ReAct：推理与行动的交错 基本循环 ReAct（Reasoning + Acting）是Agent规划的基石，核心思想是交错推理和行动： Thought: 用户要查北京天气，我需要调用天气API Action: search_weather(city="北京") Observation: 北京今天晴，25°C Thought: 获取到天气信息，可以回答用户了 Answer: 北京今天天气晴朗，气温25°C，适合外出活动。 实现细节 class ReActAgent: def __init__(self, llm, tools, max_steps=10): self.llm = llm self.tools = tools self.max_steps = max_steps def run(self, task): trajectory = [] for step in range(self.max_steps): # 生成下一步思考和行为 prompt = self._build_prompt(task, trajectory) response = self.llm.generate(prompt) thought, action = self._parse(response) trajectory.append({"thought": thought, "action": action}) if action["type"] == "finish": return action["answer"] # 执行工具 if action["type"] == "tool": result = self.tools[action["name"]](**action["params"]) trajectory.append({"observation": result}) return "达到最大步数限制" def _build_prompt(self, task, trajectory): prompt = f"""任务：{task} 可用工具：{list(self.tools.keys())} 历史： """ for item in trajectory: if "thought" in item: prompt += f"Thought: {item['thought']}\n" prompt += f"Action: {item['action']}\n" elif "observation" in item: prompt += f"Observation: {item['observation']}\n" prompt += "Thought:" return prompt ReAct的局限 无记忆反馈：失败的经验不会影响后续尝试 线性思维：无法回溯到之前的选择点尝试其他路径 容易陷入循环：在复杂任务中反复尝试相同的失败方案 Reflexion：从失败中学习 核心改进 Reflexion在ReAct基础上增加了自我反思机制。当任务执行失败时，Agent会生成反思并存储到长期记忆中： ...

软件工程的AI重构 软件开发正在经历自敏捷革命以来最大的范式转变。AI不再只是编码助手，而是正在重新定义从需求分析到部署运维的完整软件生命周期。 AI介入开发全流程 需求分析与规格编写 传统流程中，产品经理写PRD，开发者理解后翻译为技术方案。AI正在桥接这个鸿沟： def ai_assisted_requirements(user_description, codebase_context): # 1. AI解析用户需求 prd = llm.generate(f""" 基于以下用户描述，编写产品需求文档： {user_description} 输出格式： - 功能需求列表 - 非功能需求（性能、安全、可用性） - 验收标准 - 技术约束 """) # 2. AI分析现有代码库 impact_analysis = llm.generate(f""" 分析以下代码库，评估新需求的影响范围： 代码库结构：{codebase_context} 新需求：{prd} 输出： - 需要修改的模块 - 需要新增的模块 - 潜在风险点 - 建议的技术方案 """) return prd, impact_analysis 架构设计 AI可以基于需求生成多种架构方案并评估trade-off： 需求：设计一个支持百万并发的实时消息系统 AI生成方案A：基于WebSocket + Redis Pub/Sub - 优势：实现简单，延迟低 - 劣势：水平扩展受限 AI生成方案B：基于gRPC + Kafka - 优势：高吞吐，可扩展 - 劣势：实现复杂度高 AI生成方案C：基于MQTT + 消息队列 - 优势：适合IoT场景，带宽效率高 - 劣势：生态较小 AI推荐：方案B，理由是... 编码实现 AI驱动的编码已经从"补全"进化到"描述→完整实现"： ...

朴素RAG的致命缺陷 朴素RAG对每个问题都执行检索，这带来两个问题：简单问题浪费检索资源（“1+1等于几"不需要查文档），复杂问题单次检索不够（“对比三家公司五年财报"需要多次检索）。自适应RAG的核心思想是让模型自己决定：是否需要检索、检索几次、检索什么。 Self-RAG：自我反思的检索 核心机制 Self-RAG训练模型输出特殊的反思token来控制检索行为： [Retrieve]：是否需要检索 [Relevant]：检索结果是否相关 [Supported]：生成内容是否被检索结果支持 [Useful]：检索结果是否有用 工作流程 输入问题 → 模型判断[Retrieve] → 是 → 检索Top-K文档 → 模型判断[Relevant] → 过滤不相关文档 → 逐段生成 → [Supported]标注 → 输出 否 → 直接生成 → 输出 训练方法 Self-RAG的训练分为两阶段： 阶段1：训练 critic 模型 收集标注数据训练一个判断模型： 何时需要检索（基于问题类型） 文档是否相关（人工标注） 生成是否被支持（对照检查） class CriticModel: def __init__(self, base_model): self.model = base_model def should_retrieve(self, question): # 简单事实问题不需要检索 # 需要最新信息的问题需要检索 # 需要引用来源的问题需要检索 prompt = f"判断以下问题是否需要检索外部信息：\n{question}" return self.model.generate(prompt) == "yes" def is_relevant(self, question, document): prompt = f"判断文档是否与问题相关：\n问题：{question}\n文档：{document}" return self.model.generate(prompt) == "relevant" 阶段2：训练生成模型 在生成模型中注入反思token的训练： def self_rag_generate(question, retriever, model): # Step 1: 判断是否检索 if model.should_retrieve(question): docs = retriever.search(question, top_k=5) # 过滤不相关文档 relevant_docs = [d for d in docs if model.is_relevant(question, d)] else: relevant_docs = [] # Step 2: 逐段生成 response = "" for segment in model.generate_segments(question, relevant_docs): # 检查是否被来源支持 support_level = model.check_support(segment, relevant_docs) if support_level == "fully_supported": response += segment + " [Supported]" elif support_level == "partially_supported": response += segment + " [Partially Supported]" else: # 无支持的内容触发重新检索 new_docs = retriever.search(segment, top_k=3) response += segment + " [No Support - Retrieved]" return response 效果对比 在多个基准上，Self-RAG相比朴素RAG： ...

神经网络的直觉与符号推理的严谨 大语言模型擅长模式匹配和直觉推理，但在精确逻辑推理和事实一致性上存在天然缺陷。知识图谱作为结构化的符号知识表示，恰好互补了LLM的短板。两者的融合——神经符号AI——正在成为构建可靠AI系统的重要方向。 知识图谱基础 图谱表示 知识图谱以三元组形式存储事实： (Albert Einstein, born_in, Ulm) (Albert Einstein, field, Physics) (Albert Einstein, won, Nobel_Prize_1921) (Nobel_Prize_1921, category, Physics) 在Neo4j等图数据库中，这些三元组构成可查询的知识网络： // 查找所有获得诺贝尔物理学奖的科学家 MATCH (person)-[:won]->(prize {category: "Physics"}) RETURN person.name, prize.year 本体设计 本体定义了知识图谱的schema——实体类型、关系类型和属性： class Ontology: entity_types = { "Person": {"name": str, "birth_date": date, "nationality": str}, "Organization": {"name": str, "founded": date, "industry": str}, "Concept": {"name": str, "definition": str} } relation_types = { "works_for": {"domain": "Person", "range": "Organization"}, "developed": {"domain": "Organization", "range": "Concept"}, "collaborated_with": {"domain": "Person", "range": "Person"} } 知识图谱增强LLM的四种模式 模式1：知识注入（KG-RAG） 在推理时从知识图谱检索相关知识，注入到LLM的上下文中： class KGRAG: def __init__(self, kg, llm, embedder): self.kg = kg # 知识图谱 self.llm = llm self.embedder = embedder def query(self, question): # 1. 实体链接 entities = self._extract_entities(question) # 2. 子图检索 subgraph = self._retrieve_subgraph(entities, hops=2) # 3. 路径排序 paths = self._rank_paths(question, subgraph) # 4. 文本化 context = self._serialize_paths(paths) # 5. LLM生成 prompt = f"""基于以下知识图谱信息回答问题： 知识： {context} 问题：{question} """ return self.llm.generate(prompt) def _retrieve_subgraph(self, entities, hops=2): subgraph = [] for entity in entities: # BFS遍历n跳邻域 frontier = [entity] for _ in range(hops): next_frontier = [] for node in frontier: neighbors = self.kg.get_neighbors(node) for neighbor, relation in neighbors: subgraph.append((node, relation, neighbor)) next_frontier.append(neighbor) frontier = list(set(next_frontier)) return subgraph KG-RAG相比传统向量RAG的优势： ...

搜索的第三次革命 第一次革命是Google的PageRank——用链接投票排序网页。第二次革命是移动搜索——随时随地获取信息。第三次革命正在进行——AI驱动的语义搜索，从"给链接"到"给答案"。 AI搜索的技术架构 传统搜索引擎的局限 传统搜索的流程：爬虫索引→关键词匹配→排序→返回结果页。用户需要自己从多个网页中提取需要的信息。这在简单事实查询中效率尚可，但在复杂问题面前力不从心。 AI搜索的架构 用户查询 → 查询理解与改写 → 多源检索（Web+知识库）→ 相关性筛选 → 内容提取 → LLM综合生成 → 引用标注 → 返回答案 查询理解 AI搜索的第一步是理解用户的真实意图： def query_understanding(query, conversation_history): # 1. 意图分类 intent = classify_intent(query) # informational / navigational / transactional / comparative # 2. 查询改写 rewritten = llm.rewrite(query, context=conversation_history) # "最好用的AI模型" → "2026年大语言模型性能对比评测" # 3. 子查询分解 sub_queries = decompose_query(rewritten) # "对比Llama和Qwen" → ["Llama 4性能评测", "Qwen3性能评测", "Llama vs Qwen对比"] return { "intent": intent, "rewritten": rewritten, "sub_queries": sub_queries } 多源检索 AI搜索不限于网页索引，还整合结构化知识库： Web搜索：实时获取最新信息 知识图谱：实体关系查询 计算引擎：数学计算和单位转换 垂直数据源：股票、天气、航班等 内容提取与去重 从多个网页中提取相关段落，去除重复内容： ...

为什么Agent评测比模型评测难 评估一个大语言模型可以给一道选择题，评估一个Agent需要给它一个完整任务并观察其行为序列。Agent评测面临三个独特挑战：任务开放性、行为多路径、环境依赖性。 评测维度框架 五维评估模型 我们提出五维Agent评估框架： 任务完成率：能否完成给定任务 路径效率：完成任务用了多少步 工具使用质量：工具调用是否恰当、参数是否正确 错误恢复能力：遇到错误能否自主恢复 自主决策能力：在模糊指令下的判断质量 任务完成率评测 任务分层设计 L1 - 简单任务（1-3步） 例：查询今天的天气 L2 - 中等任务（4-8步） 例：查找北京到上海的机票并比较三个航班的价格 L3 - 复杂任务（9-20步） 例：分析竞品网站并生成包含定价和功能对比的报告 L4 - 开放任务（20+步，目标模糊） 例：帮我规划一个提升产品用户体验的方案 评测协议 class AgentEvaluator: def __init__(self, tasks, criteria): self.tasks = tasks # 分层任务集 self.criteria = criteria # 评分标准 def evaluate(self, agent, n_runs=3): results = {} for level, tasks in self.tasks.items(): level_results = [] for task in tasks: run_results = [] for run in range(n_runs): # 执行任务 trajectory = agent.execute(task) # 评估 score = self._score_task(task, trajectory) run_results.append(score) level_results.append({ "task": task, "scores": run_results, "mean": np.mean(run_results), "std": np.std(run_results) }) results[level] = level_results return results def _score_task(self, task, trajectory): # 任务是否完成 completion = self._check_completion(task, trajectory) # 过程是否正确 process = self._check_process(task, trajectory) # 输出质量 quality = self._check_quality(task, trajectory) return 0.5 * completion + 0.3 * process + 0.2 * quality 通过率基线 基于主流Agent的测试基线（2026年）： ...

MoE：用稀疏激活突破密集模型的效率瓶颈 混合专家模型（Mixture of Experts）通过稀疏激活机制，让模型总参数量巨大但每次推理只激活一小部分。DeepSeek-V3的671B参数中每次只激活37B，Llama 4的500B+参数只激活30B——这就是MoE的效率魔法。 MoE的数学基础 标准MoE层 给定输入 $x$，MoE层的计算过程： $$y = \sum_{i=1}^{N} g_i(x) \cdot f_i(x)$$ 其中 $f_i$ 是第 $i$ 个专家（一个FFN），$g_i$ 是路由函数： $$g_i(x) = \text{softmax}(W_g \cdot x)_i$$ Top-K路由只保留 $K$ 个最大的 $g_i$，其余置零： $$g_i(x) = \begin{cases} \frac{\exp(W_g \cdot x)i}{\sum{j \in \text{TopK}} \exp(W_g \cdot x)_j} & i \in \text{TopK} \ 0 & \text{otherwise} \end{cases}$$ 专家容量因子 为防止所有token路由到同一专家（路由崩塌），每个专家有一个容量上限： $$\text{capacity} = \frac{T \cdot K}{N} \times \text{capacity_factor}$$ 其中 $T$ 是token数，$K$ 是Top-K，$N$ 是专家数。超出容量的token被丢弃或传递到下一层。 路由机制设计 标准Top-K路由 最简单的路由方式。每个token独立选择Top-K个专家： class TopKRouter(nn.Module): def __init__(self, dim, n_experts, top_k=2): self.gate = nn.Linear(dim, n_experts) self.top_k = top_k def forward(self, x): # x: [batch * seq_len, dim] logits = self.gate(x) scores = F.softmax(logits, dim=-1) # Top-K选择 topk_scores, topk_indices = scores.topk(self.top_k, dim=-1) topk_scores = topk_scores / topk_scores.sum(dim=-1, keepdim=True) return topk_scores, topk_indices 专家选择路由 DeepSeek-V3使用了一种"专家选择"的反向路由：每个专家选择Top-K个token，而非token选择专家。这平衡了专家负载： ...

AI视频生成：从科幻到生产工具 2024年Sora的发布震惊世界，2026年的AI视频生成技术已经从"令人惊叹的Demo"进化为可用的生产工具。开源与商业方案并驾齐驱，视频长度从4秒扩展到分钟级。 技术架构演进 扩散模型路线 当前主流视频生成模型基于扩散模型，但在具体架构上有显著差异。 Sora的DiT架构 Sora使用Diffusion Transformer（DiT）架构，将视频表示为时空token序列： 输入视频 → Patch化 → 时空token序列 → DiT块（自注意力+MLP）→ 去噪 → 解码为视频 Sora的关键创新： 时空Patch：将视频切分为包含时间和空间信息的Patch 联合训练图像和视频：图像视为单帧视频 文本条件注入：通过交叉注意力注入文本描述 Kling（可灵）的架构选择 快手的Kling采用了3D VAE + Diffusion的路线： class KlingVideoGenerator: def __init__(self): self.vae = VAE3D() # 3D VAE压缩视频 self.dit = DiT3D() # 3D DiT去噪 self.text_encoder = T5Encoder() def generate(self, text_prompt, duration=5): # 1. 文本编码 text_emb = self.text_encoder(text_prompt) # 2. 生成压缩空间中的噪声 latent = torch.randn(*self._compute_shape(duration)) # 3. 迭代去噪 for t in reversed(range(T)): latent = self.dit(latent, t, text_emb) # 4. 解码为视频 video = self.vae.decode(latent) return video 自回归路线 Meta的VideoPoet和Google的VideoLLaMA探索了自回归视频生成： 文本token + [视频token序列] → 自回归生成 → 解码为视频 自回归路线的优势是天然支持长视频生成（逐帧生成），但帧间一致性控制较难。 核心技术挑战 时空一致性 视频生成最大的挑战是保持帧间的一致性——人物不能在帧之间突然变样，场景不能无故变换。 解决方案1：3D注意力：在注意力计算中同时关注空间和时间维度，但这导致计算复杂度 $O(n^2)$ 中的n包含时间维度，显存需求巨大。 ...