Posts

多模态的意义 真实世界的信息本就是多模态的——文字、图像、声音、视频。纯文本大模型只能理解被"文字化"的世界，而多模态模型直接感知原始信号，能力上限更高。 技术演进路线 阶段一：双塔模型（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。通过这种方式保留了图像细节。 ...

代码生成的三个时代 第一代：智能补全（2021-2023） GitHub Copilot开创了AI代码补全时代。核心模式是在编辑器中实时预测下一段代码，从单行补全到多行生成。技术上是将光标前后的代码作为上下文送入LLM，生成候选代码。 局限性很明显： 缺乏项目级上下文，只看当前文件 无法理解运行时行为 生成代码质量依赖使用者审查能力 第二代：对话式编程（2023-2025） Cursor、Windsurf等AI IDE引入了对话模式。开发者可以用自然语言描述需求，AI生成完整函数甚至文件。关键改进： 上下文扩展到整个项目（通过embedding检索相关文件） 支持多轮对话迭代修改 自动应用diff编辑到文件 第三代：自主编程Agent（2025-2026） 最新一代代码Agent不再需要人类逐步指导，而是： 理解完整需求描述 自主规划实现步骤 创建/修改多个文件 运行测试验证结果 自主调试修复错误 自主编程Agent的架构 核心组件 [需求理解] → [任务规划] → [代码实现] → [测试执行] → [调试修复] → [完成] ↑ | └──────────────────反馈循环──────────────────────────────┘ 需求理解模块 将自然语言需求转化为结构化的技术规格： 提取功能需求列表 识别技术约束（语言、框架、数据库） 识别非功能需求（性能、安全） 输出：结构化的规格文档 任务规划模块 将规格分解为可执行的子任务序列： 文件创建/修改计划 依赖关系图 每步的验证标准 关键挑战是规划粒度——太粗导致单步过于复杂，太细则浪费token。实践中采用自适应粒度：简单模块整块生成，复杂模块逐步拆解。 代码实现模块 实际生成代码的引擎。关键技术： 1. 上下文构建 不是简单把整个代码库塞进context，而是智能构建： 上下文 = 系统prompt + 项目结构概览(目录树) + 相关文件内容(RAG检索) + 接口定义(类型签名) + 当前任务描述 2. 增量编辑 ...

开源模型的黄金时代 2026年，开源大模型已经不再是闭源模型的"平替"——在很多维度上，顶级开源模型已经追平甚至超越同代闭源模型。三大阵营各有千秋，形成了真正的三足鼎立格局。 Meta Llama系列：生态标杆 技术路线 Llama系列坚持稠密Transformer架构，通过大规模数据+ Scaling Law驱动能力提升。Llama-4引入了原生多模态和长上下文（1M tokens），在推理基准上达到GPT-4级别。 优势 生态最成熟：社区工具链最完整，从训练到部署有完整方案 许可证友好：Llama许可证允许商用（用户量限制逐步放宽） 变体丰富：1B到400B多规格覆盖从边缘到数据中心 量化生态好：GPTQ、AWQ、GGUF格式支持最完整 局限 中文能力相对偏弱（训练语料以英文为主） 大尺寸版本硬件需求高 闭源模型同源技术，可能有OpenAI API兼容性问题 阿里Qwen系列：中文之王 技术路线 Qwen走"多尺寸+多模态+专精化"路线。Qwen-3系列覆盖0.5B到110B，每个尺寸都有Base和Instruct版本，外加专门的Coder、Math、VL变体。 优势 中文能力最强：在C-Eval、CMMLU等中文基准上持续领先 多模态原生：Qwen-VL在视觉理解任务上表现突出 部署友好：提供GGUF、MLX等多种推理格式 全栈覆盖：从文字到代码到数学到视觉，每条线都有专精模型 局限 社区生态不如Llama丰富（西方开发者优先支持Llama） 许可证对大规模商用有一定限制 小尺寸版本能力上限有限 DeepSeek系列：效率之王 技术路线 DeepSeek走技术创新驱动路线，核心创新包括： MoE架构：DeepSeek-V3/V4采用DeepSeekMoE，稀疏激活 MLA注意力：Multi-head Latent Attention大幅压缩KV Cache 多Token预测（MTP）：训练时预测多个未来token，推理时可做投机解码 极致性价比：以远低于同行的训练成本达到同等能力 优势 推理能力突出：在数学和代码基准上持续领先 推理效率极高：MLA+MoE让推理成本远低于同参数稠密模型 API价格极低：DeepSeek API定价远低于竞品 技术创新活跃：不断推出原创架构创新 局限 模型尺寸选择较少（主要集中在大尺寸） 多模态能力起步较晚 社区工具链适配不如Llama 能力对比矩阵 维度 Llama-4 Qwen-3 DeepSeek-V4 英文能力 ★★★★★ ★★★★ ★★★★ 中文能力 ★★★ ★★★★★ ★★★★ 代码能力 ★★★★ ★★★★ ★★★★★ 数学推理 ★★★★ ★★★★ ★★★★★ 多模态 ★★★★ ★★★★★ ★★★ 推理成本 ★★★ ★★★ ★★★★★ 部署便捷性 ★★★★★ ★★★★ ★★★ 选型指南 按场景选型 通用对话助手 ...

为什么需要智能体框架？ 大模型本身只是一个文本生成引擎。要构建能自主完成复杂任务的智能体，需要解决编排、状态管理、工具调用、多Agent协作等问题。智能体框架就是提供这些能力的"操作系统"。 LangGraph：图驱动的精细控制 设计哲学 LangGraph将Agent工作流建模为有向图： 节点：每个节点是一个处理步骤（LLM调用、工具执行、条件判断） 边：定义节点间的转移关系 状态：在图中流转的共享数据结构 核心概念 from langgraph.graph import StateGraph # 定义状态 class AgentState(BaseModel): messages: list = [] tool_results: dict = {} # 创建图 graph = StateGraph(AgentState) graph.add_node("think", think_node) graph.add_node("act", act_node) graph.add_node("observe", observe_node) # 定义边 graph.add_edge("think", "act") graph.add_conditional_edges("act", route_by_result, { "continue": "observe", "done": END }) graph.add_edge("observe", "think") 优势 精细控制：图结构让你明确定义每一步逻辑 状态管理：支持checkpointer持久化状态，可恢复中断的运行 人机协作：内置human-in-the-loop中断点 可视化：图结构天然可可视化，便于调试 劣势 学习曲线较陡，概念抽象 简单任务用图建模略显笨重 与LangChain深度绑定，迁移成本高 适用场景 复杂多步工作流（审批流程、数据处理管道） 需要精确控制每一步的系统 需要状态持久化和恢复的场景 AutoGen：多Agent对话编排 设计哲学 AutoGen（微软出品）采用对话式编排——多个Agent通过对话协作完成任务。核心是将Agent视为对话参与者，而非图节点。 核心概念 from autogen import AssistantAgent, UserProxyAgent coder = AssistantAgent( name="coder", system_prompt="你是一个Python开发者", llm_config=llm_config ) reviewer = AssistantAgent( name="reviewer", system_prompt="你是代码审查专家", llm_config=llm_config ) user = UserProxyAgent( name="user", human_input_mode="TERMINATE" ) # 多Agent对话 user.initiate_chat( coder, message="实现一个排序算法", reviewer作为审查者加入对话 ) 优势 多Agent协作：天然支持多个Agent角色对话 灵活性高：Agent对话模式接近自然，不需要预定义流程 群聊模式：支持多个Agent在群聊中自主决定谁发言 人机混合：UserProxy支持真人参与 劣势 对话难以精细控制，可能进入无意义循环 调试困难，对话历史长 Token消耗大（每个Agent都需完整上下文） 适用场景 需要多角色协作的复杂任务（开发、审查、测试） 创意生成（头脑风暴、方案探索） 模拟社会实验（多视角讨论） CrewAI：角色驱动的团队模拟 设计哲学 CrewAI将Agent协作建模为一个组织/团队，每个Agent有明确的角色、目标和背景。强调"像真实团队一样协作"。 ...

为什么需要对齐？ 大模型在预训练阶段从海量互联网文本中学习了知识和语言能力，但也继承了人类文本中的偏见、有害信息和不良价值观。对齐（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。 ...

微调方法全景 大模型微调主要有三种技术路线，各有适用场景： 全参微调（Full Fine-tuning）：更新所有参数，效果上限最高，但成本最高 LoRA：冻结主干参数，仅训练低秩适配矩阵，性价比极高 QLoRA：在LoRA基础上对基座模型4bit量化，进一步降低显存需求 LoRA技术详解 原理 LoRA（Low-Rank Adaptation）的核心思想是：模型适配过程中的参数变化具有低秩特性。具体做法： 将原始权重矩阵W∈R^(d×d)的更新分解为两个小矩阵的乘积： W' = W + ΔW = W + B × A 其中A∈R^(r×d)，B∈R^(d×r)，r远小于d（通常取8-64）。 参数量从d²降低到2rd，以r=16、d=4096为例，参数量从16.7M降到131K，缩减了127倍。 关键超参数 rank (r)：秩大小。r越大表达能力越强但训练越慢。推荐8-64起步 alpha：缩放系数，实际缩放为α/r。推荐设为r的2倍 target_modules：应用LoRA的层。至少q_proj和v_proj，推荐all-linear 适用场景 风格定制（让模型用特定语气说话） 领域适配（法律、医疗等垂直领域） 任务适配（将通用模型适配到特定任务格式） QLoRA：极致显存优化 QLoRA在LoRA基础上增加了两个优化： 4-bit NormalFloat量化 将基座模型权重量化为4-bit NF4数据类型。NF4是一种正态分布感知的量化方案，比均匀量化精度更高： 原始: W ∈ FP16 (每参数2字节) 量化: W → NF4 (每参数0.5字节) 训练: 仅LoRA参数为FP32 双重量化 对LoRA的适配矩阵本身也进行量化，进一步压缩梯度检查点的显存占用。 页面优化器 将优化器状态在CPU/GPU之间分页，避免显存峰值溢出。 效果对比 方法 7B模型显存 70B模型显存 效果损失 全参 120GB+ 1200GB+ 0% LoRA 20GB 160GB <1% QLoRA 6GB 48GB 1-2% QLoRA让单张消费级显卡（如RTX 3090, 24GB）就能微调7B模型，极大降低了定制化门槛。 ...

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框架，四个核心指标： ...

推理瓶颈在哪里？ 大模型推理的核心瓶颈是自回归生成的串行性：每生成一个token都需要将之前所有token的KV对参与注意力计算。随着序列变长，计算量和显存占用呈线性甚至二次增长。 推理优化的目标可以归纳为三个维度： 降低延迟（首token延迟TTFT + 每token延迟TPOT） 提升吞吐（每秒生成token总数） 减少显存（KV Cache占用） KV Cache：标准但不够 KV Cache是现代推理引擎的标配。在生成阶段，避免重复计算历史token的Key和Value向量，而是缓存复用。但KV Cache的显存占用非常大：以Llama-70B为例，单条请求的KV Cache在4K序列长度下约占2GB显存。 优化方向： PagedAttention（vLLM）：将KV Cache分为固定大小的block，通过页表管理，显著减少碎片 量化KV Cache：将FP16的KV对压缩为INT8甚至INT4，显存减半甚至1/4 稀疏KV Cache：基于注意力分数剪枝，丢弃不重要的KV对 连续批处理（Continuous Batching） 传统static batching需要等待批次内所有请求完成才能释放资源，短请求被长请求拖累。连续批处理（也叫iteration-level batching）在每个forward pass级别动态加入新请求、移除已完成请求： 时间步1: [req_A(token5), req_B(token3), req_C(token1)] 时间步2: [req_A(token6), req_B(token4), req_D(token1)] # C完成，D加入 vLLM和TGI都实现了这一机制，实测吞吐量可提升3-5倍。 投机解码（Speculative Decoding） 投机解码利用一个小模型（draft model）快速生成候选token序列，再由大模型一次性验证。如果小模型的猜测正确率足够高，就能以接近小模型的速度输出大模型质量的token： 小模型生成N个候选token（并行，很快） 大模型对这N个token做一次forward（并行验证） 接受正确的前缀，拒绝处重新采样 Medusa在此基础上扩展，在单次forward中同时预测多个位置的token（多头预测），进一步提升加速比。 量化推理 训练时用FP16/BF16，推理时降低精度： 精度 方法 性能损失 INT8 W8A8 / SmoothQuant <1% INT4 W4A16 / GPTQ / AWQ 1-3% 2-bit BitNet / 1.58bit 训练时需特殊设计 AWQ和GPTQ是目前最流行的4bit权重量化方案，配合Marlin内核可达极高吞吐。需注意，4bit量化在70B以上模型上表现好，但7B级别可能有明显精度下降。 ...

为什么Agent需要记忆？ 传统大语言模型的上下文窗口本质上是"短期工作记忆"，一旦对话超出窗口长度，早期信息就会丢失。而真正的智能体需要在跨会话、跨任务的长周期运作中保持上下文连贯性——这就要求我们构建结构化的记忆系统。 记忆系统的三层架构 1. 工作记忆（Working Memory） 工作记忆对应Agent当前正在处理的上下文，通常映射为LLM的context window。工程实现上需要注意以下几点： 动态裁剪策略：不是简单截断，而是基于注意力权重或摘要压缩来保留关键信息 滑动窗口+摘要：将溢出的历史对话通过小模型生成摘要，注入到新窗口头部 多模态工作区：除文本外，缓存当前任务相关的图片、表格、代码片段 一个典型实现是使用Redis作为热数据存储，配合embedding检索，将相关历史片段动态注入context。 2. 情景记忆（Episodic Memory） 情景记忆记录Agent过去的交互经历，包括时间、场景、行为和结果。实现方式通常是向量数据库存储： 记忆条目结构: { "id": "ep_001", "timestamp": "2026-07-16T10:00:00Z", "task": "数据分析任务", "actions": ["读取CSV", "生成图表", "撰写报告"], "outcome": "成功生成季度销售分析报告", "embedding": [0.12, -0.34, ...], "metadata": {"user_id": "u123", "session_id": "s456"} } 检索时，将当前任务描述编码为向量，在数据库中做kNN查询，召回最相关的N条历史经历。 3. 语义记忆（Semantic Memory） 语义记忆是Agent的"知识库"，存储事实、概念和规则。与RAG系统类似，但更强调知识的结构化组织和增量更新： 本体图谱：使用知识图谱存储实体关系 文档库：向量索引+全文检索双路召回 技能库：Agent掌握的工具调用模式和Prompt模板 记忆的写入与遗忘 记忆系统最关键的不是存储，而是遗忘机制。人脑会自动遗忘无关信息以保持认知效率，Agent同样需要： 衰减权重：每条记忆有一个decay score，随时间递减，长期未被检索的记忆降权 合并压缩：相似记忆条目通过聚类合并，提取共性模式 主动遗忘：低质量记忆（如失败且无参考价值的尝试）直接删除 实践中的策略是设置三层保留周期： 7天内：完整保留所有细节 7-30天：保留摘要和关键决策点 30天以上：仅保留高价值模式和教训 工程实现要点 存储选型 记忆层 推荐存储 理由 工作记忆 Redis / 本地内存 低延迟，频繁读写 情景记忆 Milvus / Pinecone 向量检索为主 语义记忆 Neo4j + 向量库 图查询+向量混合 检索融合 最终注入prompt的记忆来自三层的融合结果。推荐的重排策略： ...