Posts

朴素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包含时间维度，显存需求巨大。 ...

数字人：从CG到AI驱动的范式转变 传统数字人依赖昂贵的动作捕捉和关键帧动画，制作一个高质量的3分钟视频需要数周。AI驱动的数字人将这个时间压缩到分钟级，且质量持续逼近真实人类。 技术栈全景 数字人技术栈可以拆解为五个核心模块：文本到语音（TTS）、唇形同步、表情生成、身体动作生成、实时渲染。 TTS：从自然到富有表现力 2026年TTS技术格局 传统方案：VITS、Tacotron系列已逐渐被淘汰，自然度和表现力不足。 当前主流： CosyVoice 2：阿里开源，支持跨语言克隆和情感控制 F5-TTS：基于Flow Matching的TTS，零样本克隆效果好 OpenAI TTS-2：商用方案，延迟低，API调用简单 ElevenLabs V3：表现力最强，支持笑声、停顿等非语言声音 关键技术突破 零样本声音克隆：只需3-10秒参考音频即可克隆说话人音色。F5-TTS使用Flow Matching替代扩散模型，推理速度提升5倍： from f5_tts import F5TTS tts = F5TTS.from_pretrained("F5-TTS") tts.synthesize( text="大家好，欢迎来到硅基AGI频道", ref_audio="reference.wav", # 3秒参考音频 ref_text="这是参考音频对应的文字", output_path="output.wav" ) 情感控制：CosyVoice 2通过情感标签控制语音情感： from cosyvoice import CosyVoice2 model = CosyVoice2.from_pretrained("CosyVoice2-0.5B") model.instruct_tts( text="太好了，我们成功了！", instruct_text="用激动和兴奋的语气说话", output="excited.wav" ) 流式合成：逐句甚至逐词合成，首字延迟可控制在200ms内，满足实时对话需求。 唇形同步：让数字人"说话"自然 Wav2Lip时代已过去 早期的Wav2Lip方案虽然开创了音频驱动唇形的先河，但存在分辨率低、边缘模糊等问题。 当前最优方案 SadTalker / MuseTalk： MuseTalk在实时性和质量之间取得了很好的平衡： from musetalk import MuseTalk musetalk = MuseTalk( avatar_path="avatar.png", fps=30 ) # 实时驱动 musetalk.realtime_drive( audio_input=mic_stream, # 麦克风输入 output=screen # 屏幕输出 ) 3D方案：GeneFace++： 对于3D数字人，GeneFace++通过3DMM（3D Morphable Model）实现更精确的唇形控制： # 提取3DMM参数 coefficients = geneface.extract_3dmm(audio) # coefficients包含: 身份参数、表情参数、唇形参数 # 唇形参数直接驱动3D面部模型 评估指标 唇形同步质量的评估使用LSE-C（Lip Sync Error - Confidence）和LSE-D（Lip Sync Error - Distance）： ...

超越零样本的推理增强 Prompt工程已从简单的指令编写进化为一门系统化的方法论。在需要复杂推理的任务中，恰当的推理增强技术可以将模型准确率提升30-50%。 思维链（Chain-of-Thought） 基本CoT 思维链的核心思想是让模型"展示推理过程"。通过在prompt中加入"让我们一步步思考"或提供推理示例： Q: 一个商店有23个苹果，卖了17个后又进了8个，现在有多少苹果？ A: 让我们一步步思考。 初始数量：23 卖出17个后：23 - 17 = 6 又进了8个后：6 + 8 = 14 答案：14 CoT对数学推理、逻辑推理和多步规划任务效果显著。在GSM8K数学基准上，CoT将GPT-4的准确率从约75%提升到92%。 Zero-shot CoT 最简单的CoT只需在prompt末尾添加： 让我们一步步思考。 这五个字的魔力在于：它激活了模型在预训练阶段学到的"推理模式"，使模型生成中间推理步骤而非直接跳到答案。 Few-shot CoT 提供2-4个带有推理过程的示例，效果更好但消耗更多token。关键是示例的推理过程要正确且简洁——过长的推理链反而会降低性能。 自一致性（Self-Consistency） 核心思想 CoT的一个问题是：同一条推理路径可能系统性偏向错误答案。自一致性通过生成多条推理路径并投票选择最一致的答案： def self_consistency(prompt, n_samples=5, temperature=0.7): responses = [] for _ in range(n_samples): response = llm.generate( prompt + "\n让我们一步步思考。", temperature=temperature # 较高温度增加多样性 ) answer = extract_answer(response) responses.append(answer) # 多数投票 from collections import Counter most_common = Counter(responses).most_common(1)[0] return most_common[0] 在GSM8K上，自一致性将准确率从92%进一步提升到96%+。代价是推理成本增加5倍。 采样策略 温度：0.5-0.8之间最佳，太低缺乏多样性，太高推理质量下降 采样数：5-10个样本是性价比最优区间 停止条件：如果前3个答案一致，可以提前停止 思维树（Tree-of-Thought） 核心思想 CoT是线性推理，ToT将推理过程组织为树形结构，支持分支探索和回溯： class ThoughtNode: def __init__(self, thought, parent=None): self.thought = thought self.parent = parent self.children = [] self.value = 0 评估值 self.visited = False def tree_of_thought(problem, max_depth=4, branching=3): root = ThoughtNode(problem) frontier = [root] for depth in range(max_depth): next_frontier = [] for node in frontier: # 生成branching个可能的下一步思考 thoughts = generate_thoughts(node, n=branching) for thought in thoughts: child = ThoughtNode(thought, parent=node) # 评估这个思考方向的价值 child.value = evaluate_thought(thought, problem) node.children.append(child) next_frontier.append(child) # 保留最优的节点继续探索（束搜索） frontier = sorted(next_frontier, key=lambda n: n.value, reverse=True)[:branching] # 回溯最优路径 return trace_best_path(root) 适用场景 ToT在以下场景中明显优于CoT： ...

Agent框架的核心问题 构建AI Agent需要解决三个核心问题：任务规划与分解、工具调用与执行、多Agent协作。不同的Agent框架对这些问题的回答各不相同，形成了截然不同的编程范式。 LangGraph：图驱动的精确控制 设计哲学 LangGraph将Agent工作流建模为有向图：节点是处理步骤，边是控制流。这种设计赋予了开发者对Agent行为的精确控制。 核心概念 from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: list tool_results: list next_step: str # 定义图 graph = StateGraph(AgentState) # 添加节点 graph.add_node("planner", plan_task) graph.add_node("executor", execute_tools) graph.add_node("reviewer", review_results) # 添加边（控制流） graph.add_edge("planner", "executor") graph.add_conditional_edges( "executor", lambda state: "reviewer" if state["tool_results"] else END, {True: "reviewer", False: END} ) graph.add_conditional_edges( "reviewer", lambda state: "planner" if not state["success"] else END ) 优势 精确控制：图的拓扑结构让Agent的执行路径完全可见和可预测。这在需要审计和合规的场景中至关重要。 状态管理：LangGraph内置了检查点（checkpoint）机制，可以在任何节点暂停和恢复执行。这对于长时间运行的Agent任务非常有用。 人机协作：interrupt_before和interrupt_after参数允许在特定节点暂停，等待人类反馈： graph.compile( checkpointer=MemorySaver(), interrupt_before=["executor"] # 执行前等待人类确认 ) 局限 学习曲线陡峭，图思维需要适应 简单任务显得过度工程化 调试复杂图流程需要可视化工具辅助 AutoGen：多Agent对话的原生范式 设计哲学 AutoGen（微软研究院）将多Agent协作建模为对话。每个Agent有角色定义，通过消息传递完成协作。 核心模式 from autogen import AssistantAgent, UserProxyAgent, GroupChat # 创建Agent planner = AssistantAgent( name="Planner", system_message="你负责分析用户需求并制定执行计划", llm_config=llm_config ) coder = AssistantAgent( name="Coder", system_message="你负责根据计划编写代码", llm_config=llm_config ) reviewer = AssistantAgent( name="Reviewer", system_message="你负责审查代码质量", llm_config=llm_config ) user_proxy = UserProxyAgent( name="User", human_input_mode="NEVER", code_execution_config={"work_dir": "workspace"} ) # 创建群聊 group_chat = GroupChat( agents=[user_proxy, planner, coder, reviewer], messages=[], max_round=15 ) manager = GroupChatManager(groupchat=group_chat, llm_config=llm_config) user_proxy.initiate_chat(manager, message="实现一个用户注册API") 优势 对话式协作自然：多Agent之间的协作就像团队会议，每个Agent专注于自己的职责。 ...

AI芯片市场的格局之变 NVIDIA在AI训练芯片领域占据了超过80%的市场份额，但2026年的竞争格局正在发生深刻变化。从AMD的MI400到华为的昇腾910C，挑战者们正在从不同角度发起冲击。 NVIDIA Blackwell：延续统治地位 Blackwell架构核心创新 B200 GPU的Blackwell架构带来了几项关键突破： 第二代Transformer Engine：原生支持FP4精度，在保持训练精度的同时将推理吞吐量提升到Hopper的30倍。FP4的实现在于新的缩放因子机制，每个tensor块附带一个FP8缩放因子，动态调整表示范围。 576TB/s的NVLink域：Blackwell支持576个GPU的全互联，形成巨大的NVLink域。这意味着大规模训练任务可以在单一互联域内完成，减少跨节点通信开销。 确定性计算：Blackwell引入了确定性计算模式，相同输入始终产生相同输出。这对大规模训练中的调试和复现至关重要。 实际性能表现 在Llama-3-70B推理场景下： B200 vs H100：吞吐量提升约15倍（FP4量化） B200 vs H100：延迟降低约8倍 单卡可支持1000+并发用户 但B200的功耗也达到1000W，对数据中心供电和散热提出了极高要求。 AMD MI400：紧追不舍的挑战者 MI400的差异化优势 AMD在2026年推出的MI400系列（Instinct MI400X）在几个维度上对NVIDIA构成了真正的竞争压力： 显存容量：MI400X配备288GB HBM3E显存，超过B200的192GB。这使得单卡可以加载更大的模型，减少多卡并行的通信开销。 统一编程模型：ROCm 7.0终于成熟到可以与CUDA生态正面竞争。HIP（Heterogeneous-Compute Interface for Portability）提供了CUDA到ROCm的自动转换工具： // CUDA代码 __global__ void kernel(float* data) { ... } // 转换为ROCm代码 __global__ void kernel(float* data) { ... } // 几乎无需修改 性价比：MI400X的定价策略比B200低约30-40%，在推理场景下的性价比优势明显。 生态差距 AMD最大的挑战仍然是软件生态： PyTorch对ROCm的支持已基本完善，但边缘case仍有问题 Triton等编译器对MI400的支持落后于NVIDIA 深度学习框架的最新优化通常先在CUDA上实现 华为昇腾910C：国产之光 架构设计 昇腾910C采用达芬奇架构3.0，核心特点： Cube+Vector双引擎：Cube引擎负责矩阵运算（GEMM），Vector引擎负责元素级运算。两个引擎可以并行工作，提高计算单元利用率。 片上互联：采用HCCS（Huawei Cache Coherent System）互联，单服务器内8颗910C的互联带宽达392GB/s。 CANN软件栈 华为的CANN（Compute Architecture for Neural Networks）软件栈日趋成熟： # 使用MindSpore + CANN import mindspore as ms from mindspore import nn class Model(nn.Cell): def construct(self, x): return self.dense(x) # 自动编译为昇腾可执行文件 model = Model() model.compile(target="ascend") # 编译到Ascend 910C 实际能力 昇腾910C在Llama-3-70B推理上的性能约为A100的70-80%。虽然在绝对性能上与B200有差距，但在国产替代场景下已经可以满足大部分需求。 ...