文章摘要
Anthropic近日推出Claude Haiku 5.5,该模型新增自适应推理机制,支持百万级上下文,多项核心评测成绩较上一代大幅提升,计算机操作、知识工作能力进步明显,但复杂编程场景仍与同系列Sonnet 5.5存在较大差距。它采用分层定价,已在多平台上线,原有应用迁移需调整适配,企业落地需验证实际表现与成本。

Anthropic近日正式推出Claude Haiku 5.5版本,此次更新的升级幅度超出预期,不仅在多项核心评测中取得显著进步,还新增了自适应推理机制与百万级上下文支持,同时优化了使用成本结构。此前Haiku系列主要面向摘要、分类、信息提取等轻量高频任务,凭借速度快、成本低的优势占据市场份额,而此次更新后,其可处理的任务复杂度大幅提升,部分评测成绩已接近同系列的Sonnet 5.5,但在复杂编程场景下,两者仍存在明显差距。接下来我们将从性能表现、推理机制、定价规则以及落地迁移四个维度,详细拆解这款新模型的细节。

性能提升的核心场景与边界

在计算机操作能力上,Haiku 5.5的进步尤为突出。在OSWorld 2.1离线子集测试中,其完成率从上一代的15.7%跃升至72.4%,而同系列的Sonnet 5.5则达到83.9%。OSWorld测试主要评估模型通过计算机界面完成长链路任务的能力,包括界面理解、操作执行以及根据环境反馈调整后续动作,相比普通文本问答,这类任务存在更强的状态依赖——每次点击或输入后页面状态都会变化,模型需要基于最新界面调整操作,若操作失败还需判断当前环境是否符合任务要求。此次Haiku 5.5在该测试中的大幅提升,说明其处理连续操作任务的能力有了质的飞跃,但需要注意的是,72.4%的完成率仅针对特定测试集,无法直接代表真实业务中所有浏览器或桌面任务的实际成功率,企业在落地时仍需在对应环境中单独测试。

在知识工作场景中,Haiku 5.5的表现同样亮眼。在GDPval-AA v2.1评测中,其得分达到1620分,而上一代Haiku 4.5仅为735分,Sonnet 5.5则为1840分;该评测涵盖44类职业的实际工作任务,涉及材料分析、信息整合和工作成果生成。在另一项AA-Briefcase v1.1评测中,Haiku 5.5的得分从614分提升至1578分。多学科推理测试Humanity's Last Exam的数据显示,其无工具成绩达到45.9%,接入工具后提升至57.4%,均显著高于上一代版本。这类复杂任务要求模型理解多个信息源之间的关联,处理材料中的限制条件,并基于已有内容生成结果,工具的引入还增加了信息获取和结果整合的环节,Haiku 5.5在这类场景中的进步,证明其处理复杂知识工作的能力已经大幅增强。

不过在编程评测场景中,Haiku 5.5的表现仍有局限。在FrontierCode 1.1主测试中,其得分为46.4%,与Sonnet 5.5的52.1%差距较小;但在Terminal-Bench 4.0测试中,Haiku 5.5仅取得39.2%的得分,而Sonnet 5.5的得分达到70.6%。Terminal-Bench主要评估命令行环境下的复杂多步骤任务,模型需要完成读取文件、执行命令、处理错误并根据测试反馈调整操作等动作,对持续规划和执行状态维护的要求较高。Anthropic在发布材料中也明确提到,Sonnet 5.5和Opus 5.5更适合复杂智能体编程任务,Haiku 5.5仍主要面向范围明确的子任务、摘要和上下文压缩等工作。

部分企业的早期测试也提供了具体数据参考。Asana在AI Teammates相关测试中报告,Haiku 5.5的任务完成延迟相比现有模型降低超过30%,单轮推理速度最高提升2.5倍;HubSpot在模拟CRM环境中测得三次运行的平均成绩为92.8%;AlphaSense在400次文档问答测试中,Haiku 5.5的得分为0.84,而上一代版本为0.76。需要注意的是,这些结果均来自不同企业的内部测试,各自采用了不同的任务与评估标准,仅能作为特定业务场景的表现参考,无法直接作为统一的模型能力排名。

自适应推理机制的革新

除了性能提升,Haiku 5.5还成为首个支持可调节推理强度的Haiku系列模型。此前Haiku 4.5使用扩展思考功能时,开发者需要提前设置固定的内部推理预算,无论任务是简单的信息查找还是多条件复杂分析,模型可使用的推理空间都受预先设置的数值限制。而Haiku 5.5改用Adaptive Thinking自适应推理机制,模型可以根据任务内容自主决定是否启用内部推理以及投入的计算资源,开发者则通过Effort参数设置整体推理强度。例如,提取文档中的日期通常不需要长时间分析,而比较多个合同版本的条款差异则需要处理更多条件和关联信息,自适应推理允许模型在这两类任务中采用差异化的计算投入。

这种机制能够优化推理时的计算资源分配:复杂任务通过增加内部推理处理更多中间步骤,但会提升Token消耗和响应时间;简单任务则可以减少内部推理,降低不必要的计算开销。Anthropic在发布页面展示了不同推理强度下,Haiku 5.5在OSWorld、GDPval-AA和Humanity's Last Exam中的成本与性能关系,但不同任务对额外推理计算的反应并不一致,无法简单将提高推理档位等同于固定幅度的性能提升。

在API层面,Haiku 5.5也带来了多项需要调整的变化。首先,其不再沿用Haiku 4.5手动指定固定思考Token数量的方式,原有推理配置需要进行适配调整;其次,内部推理会占用模型的输出Token预算,如果原有程序仅根据最终答案长度设置输出上限,升级后可能出现内部推理占用过多空间,导致正文无法完整生成的情况;另外,启用自适应推理后,模型响应可能包含独立的思考数据块,应用需要正确区分内部推理内容和最终输出,不能再假设返回内容的开头一定是答案。对于持续使用工具的智能体,推理数据与对话历史之间还存在一致性要求,若开发者在后续请求中修改了已有的历史消息,可能影响原有推理状态的有效性。此外,Haiku 5.5对部分采样参数增加了限制,此前依靠这些参数调整输出行为的应用,需要检查接口兼容性。这些变化主要影响已经使用Haiku 4.5扩展思考功能的项目,迁移时除了替换模型版本,还需要重新检查推理预算、响应解析和多轮消息处理方式。

分层定价与上下文管理

Haiku 5.5支持100万Token上下文和12.8万Token输出,可以处理较长的文档、大型代码内容以及持续运行的工具记录,但Anthropic并未为整个上下文窗口设置统一的低价。对于不超过10万Token的提示词,每百万输入Token收费0.10美元,每百万输出Token收费0.50美元;当提示词超过10万Token后,输入价格提高至0.50美元,输出价格提高至2.50美元。缓存费用也采用分层模式:较短提示词的每百万Token缓存读取价格为0.01美元,较长提示词为0.05美元,相比重复传入完整内容,缓存更适合复用系统指令、工具定义和公共资料。

Anthropic表示,Haiku 4.5约90%的请求长度位于10万Token以内,这部分请求在新定价下获得了较大的价格降幅,但实际成本还会受到Token使用量变化的影响。Haiku 5.5更新了分词器,相同内容对应的Token数量可能与上一代不同,因此即使输入文本没有变化,升级后的实际计费数量也可能发生变化,需要重新测量。对于长时间运行的智能体,上下文管理会进一步影响成本,例如一个编程任务可能连续产生文件检索结果、代码分析记录和测试日志,如果每次调用都携带完整历史,输入长度会随着任务推进持续增加。Prompt Caching可以降低重复内容的读取费用,而Compaction可以将已经完成的操作整理成更短的任务状态,减少后续调用需要处理的历史信息。

Anthropic在发布材料中将上下文压缩列为Haiku 5.5的主要应用场景之一,具体部署案例包括:Rogo使用Haiku子智能体从企业10-K文件中提取收入数据,再由更大的模型负责后续演示文稿制作;Cognition将Haiku 5.5用作Devin Fusion的辅助模型,在Opus 5.5主导的配置下,FrontierCode得分达到66.2%,并报告成本与延迟有所下降。不过这些案例采用了不同模型处理不同任务的方式,发布材料并未提供完整的调用次数、Token分布和成本明细,因此无法据此计算一般业务采用相同架构后的成本节省幅度。此外,Anthropic还将Sonnet 5.5的缓存读取价格降低50%,从每百万Token 0.20美元调整为0.10美元,按照Anthropic的统计,这使Sonnet 5.5在多数智能体任务中的运行成本下降约20%,不过这一调整仅涉及缓存读取费用,输入和输出Token的标准价格并未同步按相同比例下降。

落地迁移的注意事项

目前Claude Haiku 5.5已经通过Claude API、AWS、Google Cloud和Microsoft Azure等平台提供,Anthropic同时更新了Python和TypeScript SDK,为计算机操作与浏览器操作增加了测试版支持。从目前公布的数据来看,Haiku 5.5在计算机操作、知识工作和多学科推理评测中的成绩明显高于上一代,但在复杂终端编程场景下仍与Sonnet 5.5存在较大差距。价格方面,较短提示词能够获得更明显的成本优势,超过10万Token后则适用另一档收费标准。

对于已有的Haiku 4.5应用,迁移过程涉及推理配置、Token计算和响应解析等具体修改;如果原本使用Sonnet处理部分高频任务,也可以依据相同测试集比较Haiku 5.5的完成率、响应时间和调用费用。Anthropic已经公布了模型能力、接口变化和定价信息,但实际业务中的成本改善仍需要通过对应工作负载验证,尤其在多轮工具调用场景中,模型单次请求的价格、任务失败后的重试次数以及上下文增长情况,需要放在同一次完整任务中进行综合核算。

以上内容不代表本平台立场,仅供读者参考