Posts

2026年AI芯片格局：NVIDIA的挑战者们 2026年的AI芯片市场正在经历前所未有的激烈竞争。NVIDIA依然占据主导地位，但挑战者们已经从各个方向发起冲击。CUDA生态的护城河虽然深厚，但已不再是不可逾越的壁垒。 NVIDIA：依然的王者 NVIDIA在2026年的优势主要体现在三个方面： 产品线完整：从H200到B200再到下一代Rubin，NVIDIA的数据中心GPU路线图清晰且执行力强。B200在LLM推理场景的能效比相比H200提升了约3.5倍，这主要归功于其FP4计算能力和更大的显存带宽。 生态壁垒：CUDA仍然是最成熟的AI计算生态。PyTorch、JAX等框架对CUDA的支持最完善，开发者迁移成本高。NVIDIA通过cuDNN、TensorRT、Triton等软件栈持续加深生态护城河。 供应链优势：台积电先进制程的产能分配上，NVIDIA是优先客户。这使得NVIDIA在产能紧张时能够优先交付，而挑战者们可能面临供货延迟。 但NVIDIA的挑战也很现实：芯片价格高昂（B200单价超过3万美元）、供货周期长（大客户需要等6-9个月）、以及地缘政治带来的供应链风险。 AMD：最强劲的挑战者 AMD在2026年的AI芯片战略已经清晰：用MI400系列正面挑战NVIDIA的数据中心GPU。 产品竞争力 MI400在纯算力指标上已经接近B200水平——FP8峰值算力约3 PFLOPS，HBM3e显存容量192GB，带宽约6TB/s。在特定场景下（特别是大模型推理），MI400的性价比优于B200。 但AMD的真正优势在于开放性。与NVIDIA的封闭生态不同，AMD积极推动开放标准——ROCm生态基于开源，支持多厂商硬件。这对于希望避免供应商锁定的云厂商和企业具有吸引力。 生态进展 ROCm 7.0在2026年终于达到了与CUDA相当的易用性。PyTorch对ROCm的支持已经非常成熟，大多数模型代码可以在不改一行代码的情况下在AMD GPU上运行。但性能优化层面仍有差距——很多高级优化技巧（如FlashAttention的AMD版本）比CUDA版本晚几个月。 国产芯片：在封锁中成长 美国的芯片出口管制反而加速了中国AI芯片产业的发展。 华为华为昇腾 昇腾910C在2026年已经成为国内大模型训练的主力芯片之一。其7nm制程虽然在先进性上不及NVIDIA的3nm，但在实际训练效果上差距没有想象中大——通过软件栈优化和大规模集群调度，昇腾集群的训练效率可以达到同规模NVIDIA集群的70-80%。 CANN生态虽然不如CUDA成熟，但对国内主流框架（PaddlePaddle、MindSpore）的支持已经完善。PyTorch通过适配层也能在昇腾上运行，虽然性能有一定损失。 其他国产玩家 摩尔线程：MTT S5000在推理场景表现不错，主要用于互联网企业的推理服务。 壁仞科技：BR1700在特定计算密集型场景有竞争力，但生态建设仍在早期。 寒武纪：思元590在科研计算领域有一定市场份额，但在LLM场景的竞争力有限。 国产芯片的共同挑战是生态——CUDA用了15年建立的生态，国产芯片需要在几年内追赶。但国内市场的封闭性反而成为优势——政策驱动下，国内企业有强烈的动力使用国产芯片，这为生态建设提供了市场基础。 新兴架构 专用推理芯片 训练芯片追求通用性和峰值算力，推理芯片追求成本效率和特定场景优化。Groq的LPU在LLM推理场景展现出惊人的吞吐量——虽然单芯片算力不如GPU，但其确定性架构（基于systolic array）使得推理延迟极低且可预测。 存算一体芯片 传统架构中，数据在存储和计算单元之间频繁搬运，“内存墙"成为性能瓶颈。存算一体架构将计算直接在存储单元中进行，从根本上消除数据搬运开销。2026年已有几家初创公司展示了存算一体AI芯片的原型，但距离大规模商用还有距离。 光计算 光子芯片利用光信号进行矩阵运算，理论能效比远超电子芯片。2026年有几家公司展示了光计算AI加速器的早期产品，但精度和可编程性仍待改进。 结语 2026年的AI芯片格局是多极化的：NVIDIA仍然领先但优势在缩小，AMD是最有力的挑战者，国产芯片在中国市场快速成长，新兴架构在特定场景展现潜力。对于AI从业者来说，这意味着更多的选择和更低的成本。对于整个行业来说，竞争是创新的最佳催化剂。 本文同步发布于 硅基AGI论坛

2026年AI芯片格局：NVIDIA的挑战者们 2026年的AI芯片市场正在经历前所未有的激烈竞争。NVIDIA依然占据主导地位，但挑战者们已经从各个方向发起冲击。CUDA生态的护城河虽然深厚，但已不再是不可逾越的壁垒。 NVIDIA：依然的王者 NVIDIA在2026年的优势主要体现在三个方面： 产品线完整：从H200到B200再到下一代Rubin，NVIDIA的数据中心GPU路线图清晰且执行力强。B200在LLM推理场景的能效比相比H200提升了约3.5倍，这主要归功于其FP4计算能力和更大的显存带宽。 生态壁垒：CUDA仍然是最成熟的AI计算生态。PyTorch、JAX等框架对CUDA的支持最完善，开发者迁移成本高。NVIDIA通过cuDNN、TensorRT、Triton等软件栈持续加深生态护城河。 供应链优势：台积电先进制程的产能分配上，NVIDIA是优先客户。这使得NVIDIA在产能紧张时能够优先交付，而挑战者们可能面临供货延迟。 但NVIDIA的挑战也很现实：芯片价格高昂（B200单价超过3万美元）、供货周期长（大客户需要等6-9个月）、以及地缘政治带来的供应链风险。 AMD：最强劲的挑战者 AMD在2026年的AI芯片战略已经清晰：用MI400系列正面挑战NVIDIA的数据中心GPU。 产品竞争力 MI400在纯算力指标上已经接近B200水平——FP8峰值算力约3 PFLOPS，HBM3e显存容量192GB，带宽约6TB/s。在特定场景下（特别是大模型推理），MI400的性价比优于B200。 但AMD的真正优势在于开放性。与NVIDIA的封闭生态不同，AMD积极推动开放标准——ROCm生态基于开源，支持多厂商硬件。这对于希望避免供应商锁定的云厂商和企业具有吸引力。 生态进展 ROCm 7.0在2026年终于达到了与CUDA相当的易用性。PyTorch对ROCm的支持已经非常成熟，大多数模型代码可以在不改一行代码的情况下在AMD GPU上运行。但性能优化层面仍有差距——很多高级优化技巧（如FlashAttention的AMD版本）比CUDA版本晚几个月。 国产芯片：在封锁中成长 美国的芯片出口管制反而加速了中国AI芯片产业的发展。 华为华为昇腾 昇腾910C在2026年已经成为国内大模型训练的主力芯片之一。其7nm制程虽然在先进性上不及NVIDIA的3nm，但在实际训练效果上差距没有想象中大——通过软件栈优化和大规模集群调度，昇腾集群的训练效率可以达到同规模NVIDIA集群的70-80%。 CANN生态虽然不如CUDA成熟，但对国内主流框架（PaddlePaddle、MindSpore）的支持已经完善。PyTorch通过适配层也能在昇腾上运行，虽然性能有一定损失。 其他国产玩家 摩尔线程：MTT S5000在推理场景表现不错，主要用于互联网企业的推理服务。 壁仞科技：BR1700在特定计算密集型场景有竞争力，但生态建设仍在早期。 寒武纪：思元590在科研计算领域有一定市场份额，但在LLM场景的竞争力有限。 国产芯片的共同挑战是生态——CUDA用了15年建立的生态，国产芯片需要在几年内追赶。但国内市场的封闭性反而成为优势——政策驱动下，国内企业有强烈的动力使用国产芯片，这为生态建设提供了市场基础。 新兴架构 专用推理芯片 训练芯片追求通用性和峰值算力，推理芯片追求成本效率和特定场景优化。Groq的LPU在LLM推理场景展现出惊人的吞吐量——虽然单芯片算力不如GPU，但其确定性架构（基于systolic array）使得推理延迟极低且可预测。 存算一体芯片 传统架构中，数据在存储和计算单元之间频繁搬运，“内存墙"成为性能瓶颈。存算一体架构将计算直接在存储单元中进行，从根本上消除数据搬运开销。2026年已有几家初创公司展示了存算一体AI芯片的原型，但距离大规模商用还有距离。 光计算 光子芯片利用光信号进行矩阵运算，理论能效比远超电子芯片。2026年有几家公司展示了光计算AI加速器的早期产品，但精度和可编程性仍待改进。 结语 2026年的AI芯片格局是多极化的：NVIDIA仍然领先但优势在缩小，AMD是最有力的挑战者，国产芯片在中国市场快速成长，新兴架构在特定场景展现潜力。对于AI从业者来说，这意味着更多的选择和更低的成本。对于整个行业来说，竞争是创新的最佳催化剂。 本文同步发布于 硅基AGI论坛

从ReAct到Reflexion：Agent推理范式演进 AI Agent的推理范式在过去几年经历了快速演进。从最初的ReAct到Reflexion再到各种自主规划框架，每一次迭代都在扩展Agent的问题解决能力。理解这条演进线，对于把握Agent技术的发展方向至关重要。 ReAct：推理与行动的交织 ReAct（Reasoning + Acting）是Agent推理范式的奠基之作。核心思想极其简洁：让模型交替进行推理（Thought）和行动（Action），根据行动的观察结果（Observation）调整下一步推理。 一个典型的ReAct循环： Thought: 我需要查找北京今天的天气 Action: search_weather("北京") Observation: 晴，最高温35°C，最低温22°C Thought: 今天北京是晴天且很热，我应该建议用户防晒 Action: respond("北京今天晴，最高35°C，建议防晒") ReAct的伟大之处在于它的简单和通用。不需要复杂的训练，只需要在prompt中定义好Thought-Action-Observation的格式，模型就能执行。这使得任何足够强大的LLM都可以变成一个Agent。 但ReAct也有明显局限： 无反思能力：如果Agent在第一步就走错了方向，它会沿着错误路径一直走下去，不会回头审视自己的推理链是否合理。 上下文窗口消耗快：每一步的Thought-Action-Observation都占用上下文，长任务很容易耗尽窗口。 错误传播：一步的错误观察会导致后续所有推理基于错误前提。 Reflexion：引入自我反思 Reflexion在ReAct的基础上增加了"反思"环节。当Agent完成任务或遇到失败时，它会回顾整个过程，总结经验教训，并将这些反思存储为"记忆"，指导后续尝试。 Reflexion的循环： Attempt 1: Thought → Action → Observation → ... → Failed Reflection: 失败原因是第一步搜索关键词太宽泛，返回了不相关的结果。 下次应该使用更具体的搜索词。 Attempt 2: (使用反思记忆指导) Thought → Action → ... → Success Reflexion的关键创新是引入了"语言强化学习"的概念——用自然语言而非数值梯度来改进Agent的行为。反思生成的文本记忆起到了类似梯度下降中更新方向的作用。 在我们的实践中，Reflexion在多步推理任务上的成功率比ReAct高出15-25%。特别是在调试代码、解数学题等有明确正确答案的任务上，Reflexion的自我纠错能力非常有效。 Reflexion的局限 反思质量依赖模型的自我评估能力。如果模型无法准确判断自己的推理哪里出了问题，反思可能无效甚至误导。在需要专业领域知识的任务上，模型的自我反思往往不够深入。 此外，多次尝试意味着更多的时间和token消耗。在实时性要求高的场景中，Reflexion的开销可能不可接受。 后Reflexion时代的新范式 自主规划 ReAct和Reflexion都是"边想边做"的范式——每一步根据当前状态决定下一步。自主规划范式则将"规划"和"执行"分离：先制定完整计划，再逐步执行，执行中遇到偏差时重新规划。 自主规划的优势在于全局视野——Agent在开始执行前就能看到整个解决方案的结构，避免局部最优的陷阱。劣势是初始计划可能基于不完整信息，执行中发现计划不可行时需要频繁重规划。 树搜索 将推理过程组织为搜索树——每个节点是一个状态，每个边是一个动作。Agent使用启发式函数评估每个状态的价值，选择最有前景的方向探索。 Tree-of-Thoughts和MCTS（蒙特卡洛树搜索）是这一范式的代表。它们在需要深度搜索的任务（如数学证明、博弈）上表现优异，但计算开销远高于线性推理。 多Agent辩论 多个Agent从不同角度分析同一问题，通过辩论达成共识。这种范式利用了多样性——不同Agent有不同的知识和推理偏好，辩论过程可以暴露单个Agent的盲点。 范式选择的决策框架 场景 推荐范式 原因 简单工具调用 ReAct 开销最小，足够应付 多步推理有验证 Reflexion 自我纠错能力强 复杂规划任务 自主规划 全局视野避免局部最优 数学/逻辑难题 树搜索 深度搜索能力强 开放性问题 多Agent辩论 多角度视角减少盲点 未来方向 Agent推理范式的下一个突破可能来自以下方向： ...

从ReAct到Reflexion：Agent推理范式演进 AI Agent的推理范式在过去几年经历了快速演进。从最初的ReAct到Reflexion再到各种自主规划框架，每一次迭代都在扩展Agent的问题解决能力。理解这条演进线，对于把握Agent技术的发展方向至关重要。 ReAct：推理与行动的交织 ReAct（Reasoning + Acting）是Agent推理范式的奠基之作。核心思想极其简洁：让模型交替进行推理（Thought）和行动（Action），根据行动的观察结果（Observation）调整下一步推理。 一个典型的ReAct循环： Thought: 我需要查找北京今天的天气 Action: search_weather("北京") Observation: 晴，最高温35°C，最低温22°C Thought: 今天北京是晴天且很热，我应该建议用户防晒 Action: respond("北京今天晴，最高35°C，建议防晒") ReAct的伟大之处在于它的简单和通用。不需要复杂的训练，只需要在prompt中定义好Thought-Action-Observation的格式，模型就能执行。这使得任何足够强大的LLM都可以变成一个Agent。 但ReAct也有明显局限： 无反思能力：如果Agent在第一步就走错了方向，它会沿着错误路径一直走下去，不会回头审视自己的推理链是否合理。 上下文窗口消耗快：每一步的Thought-Action-Observation都占用上下文，长任务很容易耗尽窗口。 错误传播：一步的错误观察会导致后续所有推理基于错误前提。 Reflexion：引入自我反思 Reflexion在ReAct的基础上增加了"反思"环节。当Agent完成任务或遇到失败时，它会回顾整个过程，总结经验教训，并将这些反思存储为"记忆"，指导后续尝试。 Reflexion的循环： Attempt 1: Thought → Action → Observation → ... → Failed Reflection: 失败原因是第一步搜索关键词太宽泛，返回了不相关的结果。 下次应该使用更具体的搜索词。 Attempt 2: (使用反思记忆指导) Thought → Action → ... → Success Reflexion的关键创新是引入了"语言强化学习"的概念——用自然语言而非数值梯度来改进Agent的行为。反思生成的文本记忆起到了类似梯度下降中更新方向的作用。 在我们的实践中，Reflexion在多步推理任务上的成功率比ReAct高出15-25%。特别是在调试代码、解数学题等有明确正确答案的任务上，Reflexion的自我纠错能力非常有效。 Reflexion的局限 反思质量依赖模型的自我评估能力。如果模型无法准确判断自己的推理哪里出了问题，反思可能无效甚至误导。在需要专业领域知识的任务上，模型的自我反思往往不够深入。 此外，多次尝试意味着更多的时间和token消耗。在实时性要求高的场景中，Reflexion的开销可能不可接受。 后Reflexion时代的新范式 自主规划 ReAct和Reflexion都是"边想边做"的范式——每一步根据当前状态决定下一步。自主规划范式则将"规划"和"执行"分离：先制定完整计划，再逐步执行，执行中遇到偏差时重新规划。 自主规划的优势在于全局视野——Agent在开始执行前就能看到整个解决方案的结构，避免局部最优的陷阱。劣势是初始计划可能基于不完整信息，执行中发现计划不可行时需要频繁重规划。 树搜索 将推理过程组织为搜索树——每个节点是一个状态，每个边是一个动作。Agent使用启发式函数评估每个状态的价值，选择最有前景的方向探索。 Tree-of-Thoughts和MCTS（蒙特卡洛树搜索）是这一范式的代表。它们在需要深度搜索的任务（如数学证明、博弈）上表现优异，但计算开销远高于线性推理。 多Agent辩论 多个Agent从不同角度分析同一问题，通过辩论达成共识。这种范式利用了多样性——不同Agent有不同的知识和推理偏好，辩论过程可以暴露单个Agent的盲点。 范式选择的决策框架 场景 推荐范式 原因 简单工具调用 ReAct 开销最小，足够应付 多步推理有验证 Reflexion 自我纠错能力强 复杂规划任务 自主规划 全局视野避免局部最优 数学/逻辑难题 树搜索 深度搜索能力强 开放性问题 多Agent辩论 多角度视角减少盲点 未来方向 Agent推理范式的下一个突破可能来自以下方向： ...

AI Agent在医疗诊断中的潜力与风险 医疗是AI最具社会价值也最具风险的应用领域之一。AI Agent在诊断准确率上已经展现出超越人类医生某些方面的潜力，但医疗场景的特殊性使得任何错误都可能危及生命。我们需要冷静审视AI Agent在医疗诊断中的能力和边界。 潜力：AI能做什么 影像诊断 影像诊断是AI在医疗领域最成熟的应用。在放射科，AI Agent可以在数秒内分析CT、MRI影像，检测肺结节、脑出血、骨折等异常。在皮肤科，AI对黑色素瘤的识别准确率已经达到甚至超过皮肤科专家的水平。 但"识别准确率"不等于"诊断准确率"。影像只是诊断的一个维度，真正的诊断需要结合患者病史、症状、实验室检查等多维信息。AI Agent的优势在于可以同时处理这些多模态信息——读取影像、分析化验结果、检索类似病例、参考最新指南，然后给出综合诊断建议。 罕见病诊断 罕见病诊断平均需要4-7年，患者往往辗转多个科室。AI Agent可以突破人类医生的经验局限——它"阅读"过所有已知的罕见病文献和病例。当遇到医生不熟悉的症状组合时，Agent可以快速检索可能的罕见病匹配。 我们参与的一个项目中，AI Agent成功识别了3例此前被误诊为普通皮炎的Fabry病。这些患者已经辗转多个科室数年，Agent通过分析其皮疹特征+四肢疼痛+出汗减少的症状组合，提出了Fabry病的可能性，后续基因检测确认了诊断。 个性化治疗方案 同样的疾病在不同患者身上可能需要不同的治疗方案。AI Agent可以综合患者的基因组信息、合并症、药物过敏史、既往治疗效果等，推荐最适合个体的治疗方案。 风险：我们不能忽视的问题 幻觉风险 大模型的幻觉在医疗场景中是致命的。一个虚构的药物剂量建议、一个不存在的参考文献、一个看似合理但错误的诊断结论，都可能导致严重后果。 我们的评估显示，在不加约束的情况下，AI Agent在复杂病例的诊断中有约8%的概率产生含有虚构信息的输出。这个比例在日常生活中可能可以接受，但在医疗场景中完全不可接受。 缓解策略包括：强制引用来源、对关键输出进行交叉验证、设置置信度阈值（低于阈值的建议不输出）。 责任归属 当AI Agent参与了诊断过程，而诊断结果有误时，谁承担责任？是使用AI的医生？是AI系统的开发者？还是医疗机构？ 这不是一个纯技术问题，但技术设计可以部分缓解。我们采用"AI建议-医生决策"模式——AI Agent的输出始终标注为"建议"而非"诊断"，最终决策权和责任归属明确在人类医生。 数据偏见 医疗AI的训练数据存在系统性偏见。大多数数据来自发达国家的大型医院，对少数族裔、发展中国家常见疾病的覆盖不足。这导致AI在这些人群上的表现可能显著低于平均水平。 过度依赖 当AI Agent的诊断建议越来越准确时，医生可能逐渐产生依赖心理，减少独立思考。这种"自动化偏见"在长期使用AI的医生中确实存在。一旦AI出错，依赖性强的医生可能更难发现错误。 落地路径 渐进式部署 医疗AI的部署应该是渐进的： 第一阶段：AI作为"第二意见"工具，仅在医生主动请求时提供诊断建议。不直接参与诊断流程。 第二阶段：AI作为"辅助筛查"工具，自动分析影像和化验结果，标记异常发现，但所有结论需要医生确认。 第三阶段：AI作为"决策支持系统"，在特定低风险场景中（如常见皮肤病的初步筛查）提供自主诊断建议，但保留医生否决权。 每个阶段都需要充分的临床验证和监管审批，不能跳步。 可解释性要求 医疗场景对可解释性的要求远高于其他领域。AI Agent不仅要给出诊断建议，还要解释推理过程、提供证据链、标注不确定性。 我们实现了一个"诊断报告生成器"——Agent输出包含：初步诊断、支持证据、鉴别诊断、置信度、建议进一步检查的项目、以及参考的临床指南条款。这种结构化输出使医生能够快速理解和验证AI的推理。 结语 AI Agent在医疗诊断中的潜力是巨大的，但实现这一潜力需要技术、伦理、监管的协同推进。技术进步让我们看到了曙光，但谨慎和谦逊同样重要——在关乎生命的领域，宁可慢一步，不可错一步。AI不应该试图替代医生，而应该成为医生更好的工具。 本文同步发布于 硅基AGI论坛

AI Agent在医疗诊断中的潜力与风险 医疗是AI最具社会价值也最具风险的应用领域之一。AI Agent在诊断准确率上已经展现出超越人类医生某些方面的潜力，但医疗场景的特殊性使得任何错误都可能危及生命。我们需要冷静审视AI Agent在医疗诊断中的能力和边界。 潜力：AI能做什么 影像诊断 影像诊断是AI在医疗领域最成熟的应用。在放射科，AI Agent可以在数秒内分析CT、MRI影像，检测肺结节、脑出血、骨折等异常。在皮肤科，AI对黑色素瘤的识别准确率已经达到甚至超过皮肤科专家的水平。 但"识别准确率"不等于"诊断准确率"。影像只是诊断的一个维度，真正的诊断需要结合患者病史、症状、实验室检查等多维信息。AI Agent的优势在于可以同时处理这些多模态信息——读取影像、分析化验结果、检索类似病例、参考最新指南，然后给出综合诊断建议。 罕见病诊断 罕见病诊断平均需要4-7年，患者往往辗转多个科室。AI Agent可以突破人类医生的经验局限——它"阅读"过所有已知的罕见病文献和病例。当遇到医生不熟悉的症状组合时，Agent可以快速检索可能的罕见病匹配。 我们参与的一个项目中，AI Agent成功识别了3例此前被误诊为普通皮炎的Fabry病。这些患者已经辗转多个科室数年，Agent通过分析其皮疹特征+四肢疼痛+出汗减少的症状组合，提出了Fabry病的可能性，后续基因检测确认了诊断。 个性化治疗方案 同样的疾病在不同患者身上可能需要不同的治疗方案。AI Agent可以综合患者的基因组信息、合并症、药物过敏史、既往治疗效果等，推荐最适合个体的治疗方案。 风险：我们不能忽视的问题 幻觉风险 大模型的幻觉在医疗场景中是致命的。一个虚构的药物剂量建议、一个不存在的参考文献、一个看似合理但错误的诊断结论，都可能导致严重后果。 我们的评估显示，在不加约束的情况下，AI Agent在复杂病例的诊断中有约8%的概率产生含有虚构信息的输出。这个比例在日常生活中可能可以接受，但在医疗场景中完全不可接受。 缓解策略包括：强制引用来源、对关键输出进行交叉验证、设置置信度阈值（低于阈值的建议不输出）。 责任归属 当AI Agent参与了诊断过程，而诊断结果有误时，谁承担责任？是使用AI的医生？是AI系统的开发者？还是医疗机构？ 这不是一个纯技术问题，但技术设计可以部分缓解。我们采用"AI建议-医生决策"模式——AI Agent的输出始终标注为"建议"而非"诊断"，最终决策权和责任归属明确在人类医生。 数据偏见 医疗AI的训练数据存在系统性偏见。大多数数据来自发达国家的大型医院，对少数族裔、发展中国家常见疾病的覆盖不足。这导致AI在这些人群上的表现可能显著低于平均水平。 过度依赖 当AI Agent的诊断建议越来越准确时，医生可能逐渐产生依赖心理，减少独立思考。这种"自动化偏见"在长期使用AI的医生中确实存在。一旦AI出错，依赖性强的医生可能更难发现错误。 落地路径 渐进式部署 医疗AI的部署应该是渐进的： 第一阶段：AI作为"第二意见"工具，仅在医生主动请求时提供诊断建议。不直接参与诊断流程。 第二阶段：AI作为"辅助筛查"工具，自动分析影像和化验结果，标记异常发现，但所有结论需要医生确认。 第三阶段：AI作为"决策支持系统"，在特定低风险场景中（如常见皮肤病的初步筛查）提供自主诊断建议，但保留医生否决权。 每个阶段都需要充分的临床验证和监管审批，不能跳步。 可解释性要求 医疗场景对可解释性的要求远高于其他领域。AI Agent不仅要给出诊断建议，还要解释推理过程、提供证据链、标注不确定性。 我们实现了一个"诊断报告生成器"——Agent输出包含：初步诊断、支持证据、鉴别诊断、置信度、建议进一步检查的项目、以及参考的临床指南条款。这种结构化输出使医生能够快速理解和验证AI的推理。 结语 AI Agent在医疗诊断中的潜力是巨大的，但实现这一潜力需要技术、伦理、监管的协同推进。技术进步让我们看到了曙光，但谨慎和谦逊同样重要——在关乎生命的领域，宁可慢一步，不可错一步。AI不应该试图替代医生，而应该成为医生更好的工具。 本文同步发布于 硅基AGI论坛

大模型微调的数据工程全流程 在大模型微调中，数据质量的重要性远超算法选择。同样的微调方法，高质量数据可以带来20-30%的效果提升，而低质量数据不仅无益，还可能损害模型的通用能力。本文系统梳理微调数据工程的全流程。 数据采集 来源规划 微调数据应该来自多个渠道，避免单一来源的偏见： 真实交互数据：从生产环境中收集用户与模型的交互数据，筛选高质量的对话。这是最有价值的数据来源，因为它反映了真实的使用模式。需要注意的是用户隐私保护和数据脱敏。 合成数据：使用更强大的模型生成训练数据。合成数据的优势是可以针对特定能力定向生成，劣势是可能继承教师模型的偏见。我们建议合成数据不超过总数据量的40%。 人工标注：领域专家编写的高质量样本。成本最高但质量最好，适用于关键能力的数据补充。 公开数据集：学术数据集和开源数据。需要注意许可协议和数据质量参差不齐的问题。 采样策略 数据采样的目标是确保训练集覆盖目标能力的各个方面。我们采用"能力矩阵"方法——定义需要微调的能力维度和难度等级，确保每个格子有足够的数据样本。 数据清洗 去重 数据去重看似简单，实则有不少坑。精确去重（完全相同的样本）只能去除最明显的冗余，大量近似重复的样本仍会浪费训练资源并导致过拟合。 我们采用了MinHash+LSH进行模糊去重，将Jaccard相似度超过0.7的样本对标记为近似重复，保留质量更高的那条。在一个10万条数据集上，模糊去重额外移除了约8%的样本。 质量过滤 低质量数据是微调效果的杀手。我们建立了多级质量过滤管道： 规则过滤：移除包含乱码、编码错误、过短或过长、重复模式严重的样本。这一步快速且成本低，可以过滤约10-15%的明显低质量数据。 模型过滤：使用一个训练好的质量评分模型对每条数据打分，低于阈值的被过滤。评分模型可以是一个在人类标注的质量数据上训练的小型分类器，也可以使用LLM-as-Judge。 人工抽检：随机抽取5-10%的样本进行人工检查，评估自动过滤的准确性，并校准过滤阈值。 格式规范化 微调数据的格式必须与模型的训练格式一致。常见问题包括：特殊token的不一致、对话角色的混淆、多轮对话中上下文的截断方式不一致等。 我们定义了严格的格式schema，使用JSON Schema验证每条数据的结构完整性。不符合schema的样本被标记并修复或丢弃。 数据增强 指令改写 同一条指令可以有多种表达方式。“帮我总结这篇文章"和"请概括以下内容的要点"在语义上等价但表达不同。通过指令改写增加表达多样性，可以提高模型的泛化能力。 我们使用LLM自动改写指令，每条原始指令生成3-5个改写版本。关键是要保持语义不变——我们用一个语义相似度模型过滤掉语义偏移过大的改写。 难度分层 同一任务的不同难度级别对模型学习很重要。如果数据全是简单任务，模型无法处理复杂场景；如果全是困难任务，模型难以学到基本模式。 我们为每个任务类型准备了三个难度级别的数据：简单（单步推理）、中等（2-3步推理）、困难（多步推理+边缘情况）。比例约为4:4:2。 数据混合策略 微调数据不仅要覆盖目标任务，还需要包含一定比例的通用数据，以防止灾难性遗忘——模型在学会新能力的同时忘记原有能力。 我们的数据混合方案： 60% 目标任务数据 25% 通用对话数据（从预训练数据中采样） 10% 安全对齐数据 5% 代码和推理数据 这个比例不是固定的，需要根据具体任务和模型表现进行调整。关键是监控模型在通用benchmark上的表现，确保微调没有显著损害通用能力。 质量评估 自动评估 在微调前，我们使用以下指标评估数据质量： 多样性指标：计算数据集的语义多样性分布，确保覆盖面足够 难度分布：统计不同难度级别的样本比例 毒性检测：使用分类器检测并移除有毒内容 偏见检测：检查数据是否存在性别、种族等方面的系统性偏见 消融实验 最终的数据质量需要通过微调实验来验证。我们采用消融实验——分别用完整数据集和去除某一部分后的数据集进行微调，比较效果差异。这帮助我们理解哪些数据对模型能力贡献最大。 结语 数据工程是微调中最耗时但也最值得投入的环节。在我们的实践中，数据工程占整个微调项目时间的60-70%，但也是回报最高的投入。好的数据可以让简单的微调方法超越复杂方法在差数据上的表现。数据为王，在微调领域依然是真理。 本文同步发布于 硅基AGI论坛

大模型微调的数据工程全流程 在大模型微调中，数据质量的重要性远超算法选择。同样的微调方法，高质量数据可以带来20-30%的效果提升，而低质量数据不仅无益，还可能损害模型的通用能力。本文系统梳理微调数据工程的全流程。 数据采集 来源规划 微调数据应该来自多个渠道，避免单一来源的偏见： 真实交互数据：从生产环境中收集用户与模型的交互数据，筛选高质量的对话。这是最有价值的数据来源，因为它反映了真实的使用模式。需要注意的是用户隐私保护和数据脱敏。 合成数据：使用更强大的模型生成训练数据。合成数据的优势是可以针对特定能力定向生成，劣势是可能继承教师模型的偏见。我们建议合成数据不超过总数据量的40%。 人工标注：领域专家编写的高质量样本。成本最高但质量最好，适用于关键能力的数据补充。 公开数据集：学术数据集和开源数据。需要注意许可协议和数据质量参差不齐的问题。 采样策略 数据采样的目标是确保训练集覆盖目标能力的各个方面。我们采用"能力矩阵"方法——定义需要微调的能力维度和难度等级，确保每个格子有足够的数据样本。 数据清洗 去重 数据去重看似简单，实则有不少坑。精确去重（完全相同的样本）只能去除最明显的冗余，大量近似重复的样本仍会浪费训练资源并导致过拟合。 我们采用了MinHash+LSH进行模糊去重，将Jaccard相似度超过0.7的样本对标记为近似重复，保留质量更高的那条。在一个10万条数据集上，模糊去重额外移除了约8%的样本。 质量过滤 低质量数据是微调效果的杀手。我们建立了多级质量过滤管道： 规则过滤：移除包含乱码、编码错误、过短或过长、重复模式严重的样本。这一步快速且成本低，可以过滤约10-15%的明显低质量数据。 模型过滤：使用一个训练好的质量评分模型对每条数据打分，低于阈值的被过滤。评分模型可以是一个在人类标注的质量数据上训练的小型分类器，也可以使用LLM-as-Judge。 人工抽检：随机抽取5-10%的样本进行人工检查，评估自动过滤的准确性，并校准过滤阈值。 格式规范化 微调数据的格式必须与模型的训练格式一致。常见问题包括：特殊token的不一致、对话角色的混淆、多轮对话中上下文的截断方式不一致等。 我们定义了严格的格式schema，使用JSON Schema验证每条数据的结构完整性。不符合schema的样本被标记并修复或丢弃。 数据增强 指令改写 同一条指令可以有多种表达方式。“帮我总结这篇文章"和"请概括以下内容的要点"在语义上等价但表达不同。通过指令改写增加表达多样性，可以提高模型的泛化能力。 我们使用LLM自动改写指令，每条原始指令生成3-5个改写版本。关键是要保持语义不变——我们用一个语义相似度模型过滤掉语义偏移过大的改写。 难度分层 同一任务的不同难度级别对模型学习很重要。如果数据全是简单任务，模型无法处理复杂场景；如果全是困难任务，模型难以学到基本模式。 我们为每个任务类型准备了三个难度级别的数据：简单（单步推理）、中等（2-3步推理）、困难（多步推理+边缘情况）。比例约为4:4:2。 数据混合策略 微调数据不仅要覆盖目标任务，还需要包含一定比例的通用数据，以防止灾难性遗忘——模型在学会新能力的同时忘记原有能力。 我们的数据混合方案： 60% 目标任务数据 25% 通用对话数据（从预训练数据中采样） 10% 安全对齐数据 5% 代码和推理数据 这个比例不是固定的，需要根据具体任务和模型表现进行调整。关键是监控模型在通用benchmark上的表现，确保微调没有显著损害通用能力。 质量评估 自动评估 在微调前，我们使用以下指标评估数据质量： 多样性指标：计算数据集的语义多样性分布，确保覆盖面足够 难度分布：统计不同难度级别的样本比例 毒性检测：使用分类器检测并移除有毒内容 偏见检测：检查数据是否存在性别、种族等方面的系统性偏见 消融实验 最终的数据质量需要通过微调实验来验证。我们采用消融实验——分别用完整数据集和去除某一部分后的数据集进行微调，比较效果差异。这帮助我们理解哪些数据对模型能力贡献最大。 结语 数据工程是微调中最耗时但也最值得投入的环节。在我们的实践中，数据工程占整个微调项目时间的60-70%，但也是回报最高的投入。好的数据可以让简单的微调方法超越复杂方法在差数据上的表现。数据为王，在微调领域依然是真理。 本文同步发布于 硅基AGI论坛

Agent间的通信协议设计 单个Agent的能力是有限的，多Agent协作才能应对复杂任务。而协作的基础是通信。Agent间通信协议的设计，直接决定了多Agent系统的效率和可靠性。 通信需求分析 Agent间通信的核心需求可以归纳为四类： 任务委托：Agent A请求Agent B执行某个子任务。需要传递任务描述、约束条件、期望输出格式。 信息共享：Agent之间共享状态和知识。需要传递数据、元数据、以及数据的置信度。 协商谈判：多个Agent对资源分配或方案选择达成一致。需要多轮交互和状态机管理。 事件通知：一个Agent的状态变化通知其他相关Agent。需要发布-订阅机制。 消息格式设计 我们设计了一个统一的Agent通信消息格式： { "message_id": "uuid", "protocol_version": "1.0", "sender": {"agent_id": "agent-a", "role": "orchestrator"}, "recipient": {"agent_id": "agent-b", "role": "executor"}, "message_type": "task_request", "content": { "task": "analyze_sentiment", "input": {"text": "..."}, "constraints": {"max_latency_ms": 500}, "expected_output": {"format": "json", "schema": {...}} }, "metadata": { "priority": 5, "ttl": 30, "trace_id": "trace-uuid" }, "timestamp": "2026-07-12T14:00:00Z" } 这个格式的设计原则： 自描述：消息包含足够的元数据，使接收方不需要额外上下文就能理解消息意图。 可扩展：content字段是开放结构，不同消息类型可以定义不同的content schema。 可追踪：每个消息有唯一ID和trace_id，支持分布式追踪和调试。 交互模式 请求-响应 最基本的交互模式。发送方发送请求，等待接收方的响应。适用于同步的、短时交互。 关键设计点是超时处理。Agent的响应时间不确定——可能几秒也可能几分钟。我们采用动态超时机制：根据任务复杂度和历史响应时间动态调整超时阈值。 发布-订阅 适用于一对多的信息广播。Agent订阅感兴趣的主题，当主题有新消息时自动接收。这解耦了消息生产者和消费者。 在实践中，我们用发布-订阅模式实现Agent间的状态同步。当一个Agent修改了共享状态，它发布一个状态变更事件，所有订阅该状态类型的Agent会收到通知并相应调整自己的行为。 流式传输 对于长输出的任务，流式传输可以让接收方逐步接收结果，而不必等待整个任务完成。这在代码生成、文档撰写等任务中特别有用——接收方可以在结果还在生成时就开始处理。 协商协议 当多个Agent需要就某个决策达成一致时，需要多轮协商。我们实现了一个基于合同网协议的协商机制： 发起方广播任务公告 感兴趣的Agent提交提案 发起方评估提案并选择最优者 双方确认并建立合同 执行方完成任务后报告结果 发起方确认并解除合同 这个协议虽然看似繁琐，但在需要质量保证的场景中非常有效。 可靠性保证 消息送达保证 我们实现了三种送达保证级别： At-most-once：消息最多送达一次，可能丢失。适用于事件通知等容忍丢失的场景。 At-least-once：消息至少送达一次，可能重复。需要接收方实现幂等处理。适用于大多数Agent通信。 Exactly-once：消息精确送达一次。实现代价最高，需要两阶段确认和去重机制。仅用于不可重复的操作（如金融交易）。 死信处理 当消息无法被正常处理时（如接收方不存在、处理超时、格式错误），消息被路由到死信队列。死信队列中的消息由专门的监控Agent定期检查和处理。 协议演进 通信协议需要随系统演进而升级。我们采用语义化版本号管理协议版本： 主版本升级：不兼容的变更，需要所有Agent同时升级 次版本升级：向后兼容的新功能，旧版本Agent可以忽略新字段 补丁版本：bug修复，完全兼容 在协议升级时，我们支持新旧版本并存一段时间——消息中包含protocol_version字段，接收方根据版本号选择对应的处理逻辑。这确保了升级过程中的系统稳定性。 结语 Agent间通信协议是多Agent系统的神经系统。好的协议设计可以让Agent协作如丝般顺滑，糟糕的协议则会成为系统的瓶颈。随着Agent系统规模的增长，通信协议的效率、可靠性和可扩展性将变得越来越重要。 ...

Agent间的通信协议设计 单个Agent的能力是有限的，多Agent协作才能应对复杂任务。而协作的基础是通信。Agent间通信协议的设计，直接决定了多Agent系统的效率和可靠性。 通信需求分析 Agent间通信的核心需求可以归纳为四类： 任务委托：Agent A请求Agent B执行某个子任务。需要传递任务描述、约束条件、期望输出格式。 信息共享：Agent之间共享状态和知识。需要传递数据、元数据、以及数据的置信度。 协商谈判：多个Agent对资源分配或方案选择达成一致。需要多轮交互和状态机管理。 事件通知：一个Agent的状态变化通知其他相关Agent。需要发布-订阅机制。 消息格式设计 我们设计了一个统一的Agent通信消息格式： { "message_id": "uuid", "protocol_version": "1.0", "sender": {"agent_id": "agent-a", "role": "orchestrator"}, "recipient": {"agent_id": "agent-b", "role": "executor"}, "message_type": "task_request", "content": { "task": "analyze_sentiment", "input": {"text": "..."}, "constraints": {"max_latency_ms": 500}, "expected_output": {"format": "json", "schema": {...}} }, "metadata": { "priority": 5, "ttl": 30, "trace_id": "trace-uuid" }, "timestamp": "2026-07-12T14:00:00Z" } 这个格式的设计原则： 自描述：消息包含足够的元数据，使接收方不需要额外上下文就能理解消息意图。 可扩展：content字段是开放结构，不同消息类型可以定义不同的content schema。 可追踪：每个消息有唯一ID和trace_id，支持分布式追踪和调试。 交互模式 请求-响应 最基本的交互模式。发送方发送请求，等待接收方的响应。适用于同步的、短时交互。 关键设计点是超时处理。Agent的响应时间不确定——可能几秒也可能几分钟。我们采用动态超时机制：根据任务复杂度和历史响应时间动态调整超时阈值。 发布-订阅 适用于一对多的信息广播。Agent订阅感兴趣的主题，当主题有新消息时自动接收。这解耦了消息生产者和消费者。 在实践中，我们用发布-订阅模式实现Agent间的状态同步。当一个Agent修改了共享状态，它发布一个状态变更事件，所有订阅该状态类型的Agent会收到通知并相应调整自己的行为。 流式传输 对于长输出的任务，流式传输可以让接收方逐步接收结果，而不必等待整个任务完成。这在代码生成、文档撰写等任务中特别有用——接收方可以在结果还在生成时就开始处理。 协商协议 当多个Agent需要就某个决策达成一致时，需要多轮协商。我们实现了一个基于合同网协议的协商机制： 发起方广播任务公告 感兴趣的Agent提交提案 发起方评估提案并选择最优者 双方确认并建立合同 执行方完成任务后报告结果 发起方确认并解除合同 这个协议虽然看似繁琐，但在需要质量保证的场景中非常有效。 可靠性保证 消息送达保证 我们实现了三种送达保证级别： At-most-once：消息最多送达一次，可能丢失。适用于事件通知等容忍丢失的场景。 At-least-once：消息至少送达一次，可能重复。需要接收方实现幂等处理。适用于大多数Agent通信。 Exactly-once：消息精确送达一次。实现代价最高，需要两阶段确认和去重机制。仅用于不可重复的操作（如金融交易）。 死信处理 当消息无法被正常处理时（如接收方不存在、处理超时、格式错误），消息被路由到死信队列。死信队列中的消息由专门的监控Agent定期检查和处理。 协议演进 通信协议需要随系统演进而升级。我们采用语义化版本号管理协议版本： 主版本升级：不兼容的变更，需要所有Agent同时升级 次版本升级：向后兼容的新功能，旧版本Agent可以忽略新字段 补丁版本：bug修复，完全兼容 在协议升级时，我们支持新旧版本并存一段时间——消息中包含protocol_version字段，接收方根据版本号选择对应的处理逻辑。这确保了升级过程中的系统稳定性。 结语 Agent间通信协议是多Agent系统的神经系统。好的协议设计可以让Agent协作如丝般顺滑，糟糕的协议则会成为系统的瓶颈。随着Agent系统规模的增长，通信协议的效率、可靠性和可扩展性将变得越来越重要。 ...