为云应用程序构建对话式可观测性
现代云应用程序通常构建为一组松散耦合的微服务,运行在 Amazon Elastic Kubernetes(容器编排平台) Service(Amazon EKS)、Amazon Elastic Container Service(Amazon ECS)或 AWS Lambda 等服务上。这种架构为工程团队提供了灵活性和可扩展性,但其固有的分布式特性也使得故障排查更加困难。当出现问题时,工程师往往需要翻阅分散在不同可观测性层中的日志、事件和指标。以 Kubernetes 为例,如果对服务缺乏深入理解,故障排查可能会变成一项耗时的工作,需要手动关联来自不同来源的信息。 在本文中,我们将介绍如何为 Kubernetes 构建一个由生成式 AI 驱动的故障排查助手。
Google DeepMind 与 DOE 合作开展 Genesis:AI for Science
Pushmeet Kohli 和 Tom Lue 我们正处在一个拐点,先进 AI 与科学研究的融合有望开启一个新的发现黄金时代。认识到这一点,我们很高兴支持白宫的 Genesis Mission——一项历史性的国家行动,旨在利用 AI 变革科学研究的方式,并加速美国科学的发展速度。Genesis Mission 将动员美国能源部(DOE)的 17 个国家实验室、产业界和学术界,共同构建一个集成发现平台,加速在能源、科学发现和国家安全等国家最紧迫挑战上的突破。 在 Google DeepMind,我们的使命是负责任地构建 AI,以造福人类。也许没有比将 AI 应用于科学更能清晰体现这一点的了。
基于Token计数的批处理:更快、更经济的查询嵌入推理
在服务大量短请求时,嵌入模型推理往往难以兼顾效率——这是搜索、检索和推荐系统中的常见模式。在 MongoDB 旗下的 Voyage AI,我们将这些短请求称为查询(queries),其他请求则称为文档(documents)。查询通常必须以极低延迟(通常为 100–300 毫秒)提供服务。 查询通常较短,其 token 长度分布高度偏斜。因此,查询推理往往受内存限制而非计算限制。查询流量波动很大,因此自动扩缩容过于缓慢。总之,顺序服务大量短请求的效率极低。 在这篇博客文章中,我们探讨如何利用批处理(batching)来更高效地服务查询。我们首先讨论现代推理引擎中的填充移除(padding removal),这是一项实现有效批处理的关键技术。然后,我们介绍形成批次和选择合适批次大小的实用策略。
深化与英国AI安全研究所(AISI)的AI安全研究合作
William Isaac 和 Owen Larter 今天,我们宣布通过一份新的谅解备忘录扩大与英国人工智能安全研究所(UK AI Security Institute,AISI)的合作关系,聚焦基础安全与安保研究,以帮助确保人工智能安全发展并惠及所有人。 与 AISI 的研究合作是我们与英国政府在加速安全且有益的人工智能进展方面更广泛合作的重要组成部分。 人工智能在帮助治疗疾病、加速科学发现、创造经济繁荣和应对气候变化方面具有造福人类的巨大潜力。要实现这些益处,我们必须将安全和责任置于开发的核心。针对广泛潜在风险对我们的模型进行评估,仍然是我们安全战略的关键部分,而外部合作是这项工作的重要元素。 正因如此,自英国 AISI 于 2023 年 11 月成立以来,我们一直与其合作测试我们最强大的模型。
改进的 Gemini 音频模型,实现强大的语音交互
产品管理总监 杰出研究科学家 您的浏览器不支持音频元素。 本周早些时候,我们通过升级 Gemini 2.5 Pro 和 Flash 文本转语音模型,引入了对音频生成更强的控制能力。 但生成富有表现力的语音只是对话的一方面。今天,我们发布了面向实时语音智能体的更新版 Gemini 2.5 Flash Native Audio。此次更新提升了模型处理复杂工作流、遵循用户指令以及进行自然对话的能力。 Gemini 2.5 Flash Native Audio 现已在 Google 产品中上线,包括 Google AI Studio、Vertex AI,并已开始在 Gemini Live 和 Search Live 中逐步推出,首次将原生音频的自然感带入 Search Live。
Gemma Scope 2:帮助 AI 安全社区深入理解复杂语言模型行为
语言模型可解释性团队 发布一套全新的、开放的语言模型可解释性工具套件 大语言模型(LLM(大语言模型))具备惊人的推理能力,然而其内部决策过程在很大程度上仍然是不透明的。如果系统未按预期运行,缺乏对其内部工作机制的可见性会使我们难以准确定位其行为的确切原因。去年,我们通过 Gemma Scope 推进了可解释性科学,这是一个旨在帮助研究人员理解 Gemma 2(我们的轻量级开放模型系列)内部工作机制的工具包。 今天,我们发布 Gemma Scope 2:一套全面的、开放的可解释性工具套件,适用于所有 Gemma 3 模型规模,从 270M 到 27B 参数。这些工具使我们能够追踪模型整个“大脑”中的潜在风险。 据我们所知,这是迄今为止 AI 实验室在可解释性工具方面规模最大的一次开源发布。
Gemini 3 Flash:为速度而生的前沿智能
Gemini 3 Flash 是我们最新的模型,具备为速度打造的前沿智能,帮助每个人更快地学习、构建和规划任何事情。 产品管理高级总监,代表 Gemini 团队 您的浏览器不支持音频元素。 今天,我们通过发布 Gemini 3 Flash 扩展了 Gemini 3 模型系列,它以极低的成本提供为速度打造的前沿智能。通过此次发布,我们让 Gemini 3 的下一代智能通过 Google 产品惠及所有人。 上个月,我们以 Gemini 3 Pro 和 Gemini 3 Deep Think 模式开启了 Gemini 3 的序幕,反响令人难以置信。自发布之日起,我们的 API(应用程序编程接口) 每天处理超过 1T tokens。
谷歌年度回顾:2025年取得研究突破的8个领域
这是智能体、推理与科学发现的一年。 Google DeepMind 首席执行官 研究、实验室、技术与社会高级副总裁 您的浏览器不支持音频元素。 2025 年是研究取得非凡进展的一年。借助人工智能,我们可以看到其轨迹正从工具转向实用:从人们使用的东西,变成人们可以投入工作的东西。如果说 2024 年是为这个时代奠定多模态基础,那么 2025 年就是 AI 开始真正思考、行动,并与我们一同探索世界的一年。在量子计算方面,我们朝着现实世界应用取得了进展。而在各个方面,我们都帮助将研究转化为现实,以更强大、更有用的产品和工具,对当今人们的生活产生积极影响。 下面回顾一下在这一年不懈进展中,定义 Google、Google DeepMind 和 Google Research 工作的一些突破、产品和科学里程碑。
为什么大语言模型不会数数?
IBM 研究人员提出了一种对流行大语言模型(LLM(大语言模型))架构的改进方案,以提升其记忆和逻辑推理能力,并使某些类型的数学问题更加直观。 支撑当今大语言模型的 Transformer(深度学习中的注意力模型架构) 架构挑战了我们对 AI 能力的既有认知。编写代码、语言翻译、从网络各个角落综合信息——这些任务如今的大语言模型似乎都能轻松应对。短短几年间,它已经改变了我们的工作方式。 但基于 Transformer 的模型存在固有局限,研究人员在试图扩展其能力并降低计算成本时不断遭遇这些瓶颈。Transformer 的核心缺陷之一——至少在理论上——在于其对序列数据建模的能力有限。这会使某些计数问题变得出奇地困难——比如统计“strawberry”中有几个“r”。
IBM 的软件工程智能体在 Java 排行榜上位居榜首
iSWE-Agent(智能体) for Java 在 GitHub issue 解决任务中占据了排行榜前两名。第一个条目使用前沿模型的单次运行,第二个条目使用开放模型的推理扩展。 就像汽车机械师的天赋最好花在修理发动机上,而不是整天修补漏气的轮胎,软件工程师的价值在于他们创造性的问题解决能力。不幸的是,工作日很容易被调试、编码和文档编写所吞噬。IBM Research 的一款新智能体 AI 工具旨在分担软件工程师工作中较为单调的部分,而两个新版本正引领潮流。 IBM 的软件工程(iSWE)-Agent for Java 目前在 Multi-SWE-Bench 的 Java 类别中占据第一和第二名。一个条目基于前沿模型 Claude 4.5 Sonnet,位居排行榜榜首,另一个基于开源模型,位列第二。
IBM Granite 被评为全球最透明的模型
斯坦福大学基础模型透明度指数今年将 IBM Granite 评为第一名——创下该指数历史最高分。 如今,基础模型无处不在,为聊天机器人、代码助手和地理空间模型等各种 AI 工具提供支持。但随着基础模型改变越来越多的商业领域和我们的日常生活,值得一问的是:我们真的了解它们是如何构建的吗? 这正是斯坦福大学基础模型研究中心所关注的问题,该中心今天发布了第三份年度基础模型透明度指数(FMTI)报告。IBM 于 2024 年将其 Granite 模型开源,但仅靠开放并不总能等同于对开发者和终端用户的透明。FMTI 根据 100 项不同指标对主流基础模型的透明度进行评分,包括数据来源、风险评估、开放权重、外部可复现性、事件报告协议和数据使用政策。
提升你的工具:介绍 ToolOps,ALTK 中的工具生命周期扩展
随着企业开发者开始部署智能体,他们面临一个共同的挑战:所依赖的工具并不总是为智能体使用做好准备。我们最近推出了 Agent(智能体) lifecycle Toolkit (ALTK),其中包含可以稳定工具调用和后处理的组件,但许多故障的根源要早得多。工具可能描述不清,或元数据稀疏,导致智能体难以可靠地选择和调用它们。这会导致工具选择错误、参数格式错误,以及难以大规模诊断的脆弱智能体行为。 为弥补这一差距,我们推出 ToolOps,这是一组新的构建时 ALTK 组件,帮助团队为企业级智能体工作流构建、准备和验证工具。ToolOps 专注于改进工具语义、生成测试场景,并在部署前验证智能体与工具交互的方式。 即使是简单的 Python 工具,如果没有清晰的语义,智能体也可能难以使用。
基准到基准的比较变得更简单
为了帮助 AI 开发者更准确地评估模型能力,IBM Research 与圣母大学正在开源一个模板和自动化工具,用于大规模创建 LLM(大语言模型) 基准卡片。 如今 AI 的许多进展都可归功于基准测试——这些严谨、标准化的测试旨在揭示大语言模型能做什么、不能做什么,并推动进一步的创新。 基准测试提供了一种结构化方式,用于并排比较模型,并评估其偏见、风险以及对特定任务的适用性。一个 LLM 的受欢迎程度可能因其基准分数而上升或下降。那么,为什么这些人人共享的成败攸关的考试,其文档却如此糟糕? IBM Research 的高级技术员工 Elizabeth Daly 在审视基准文档不一致、往往不完整的状态时,一直这样问自己。 “我开始看到可用信息与测试框架中信息表示方式之间存在巨大的脱节,”她说。
识别和分析有问题的 MySQL 查询 — PlanetScale
Ben Dicken [ @ BenjDicken ] | 2024 年 3 月 29 日 尽管我们尽力避免,但性能不佳的查询很容易在我们的工作负载中悄然出现,对数据库系统的性能产生负面影响。在大规模数据库环境中尤其如此,这些环境拥有数 GB 或数 TB 的数据、数百张表,以及每天执行的数千种查询模式。 幸运的是,MySQL 能够收集可用于识别有问题的查询的数据,并且还可以对这些查询进行分析,以深入了解其性能不佳的原因。在本文中,我将介绍几种在原生 MySQL 中实现此目的的内置技术。如果你使用 PlanetScale,则可以使用 PlanetScale Insights 仪表板更轻松、更直观地收集此类信息。我将在后文简要讨论此功能。 在本文中,我将使用以下 schema 作为示例。
PlanetScale 如何进行架构变更 — PlanetScale
Mike Coutermarsh | 2024年4月4日 工程团队的开发速度是 PlanetScale 的首要任务之一,无论是对我们自己的团队,还是对所有使用我们构建的工具的开发者而言。 在构建 PlanetScale 时,我们的早期目标之一就是为工程团队打造绝对最佳的模式变更流程。过去 3 年里我们一直在迭代优化,对于如今更改应用程序模式的便捷程度,我们越来越感到满意。 我们的主 API(应用程序编程接口) 是一个 Ruby on Rails 应用程序,连接了两个 PlanetScale 数据库。其中一个数据库包含我们大部分的业务和用户数据。另一个是更大的分片数据库,用于处理支撑 PlanetScale Insights 所需的大规模负载。 我们的团队几乎每天都会对这些数据库进行模式变更。
使用Vitess构建数据管道 — PlanetScale
博客 | 工程 | Vitess Matt Lord | 2024年7月29日 Vitess 是一个广受欢迎的 CNCF 项目,被 Slack、Square、Shopify 和 GitHub 等公司用于扩展全球最大规模的 MySQL 部署。它提供了分片、连接池以及许多其他功能,使 MySQL 的水平扩展变得简单易行。 Vitess 和 MySQL 非常适合用作在线事务处理(OLTP)系统——在这种系统中,最终用户直接与系统交互,快速响应时间至关重要,用户获取产品和服务信息,生成订单、用户档案等关键业务记录。它们并未针对在线分析处理(OLAP)工作负载以及随着产品、公司和数据需求增长而遇到的其他用例和需求进行优化。
PB级零停机迁移 — PlanetScale
博客 | 工程 | Vitess Matt Lord | 2024年8月13日 扩展挑战、频繁的维护任务、时刻担心系统何时会崩溃,以及快速上升的成本——这些都是团队为了回避迁移一个已经超出其承载能力的数据库而宁愿忍受的常见问题。 而且理由充分。从一个数据库服务器或系统迁移到另一个存在很多风险:长时间停机、数据丢失、版本不兼容,以及无人能够预料的错误。 但如果我告诉你,这件事不必如此困难呢?在 PlanetScale,我们经常将 TB 级甚至 PB 级的数据库迁移到我们的平台——全程零停机。我们的流程允许我们在切换前使用生产流量进行大量测试,必要时甚至可以将迁移回退到外部数据库。
节流器剖析,第1部分 — PlanetScale
Shlomi Noach | 2024 年 8 月 29 日 限流器是一种服务或组件,它会对传入的请求流进行反压,以确保系统有能力处理所有收到的请求而不至于过载。在本系列文章中,我们将阐述数据库系统限流器的设计考量,其目的是保持数据库系统的整体健康。我们将讨论指标选择、粒度、行为、影响、优先级以及其他话题。 在数据库中对请求进行限流有多种不同的方法。我们关注的是对非时间关键的异步、批量和海量操作进行限流。例如 ETL、数据导入、在线 DDL 操作、大规模数据清除、重新分片等等。限流器会对那些可能持续数分钟、数小时甚至数天的操作进行反压。其他形式的限流可能会对 OLTP 生产流量进行反压。本讨论对两者同样适用。 举例说明,假设有一个任务需要向数据库导入 1000 万行数据。
宣布 Vitess 21 — PlanetScale
博客 | 产品 | Vitess Vitess 工程团队 | 2024 年 10 月 29 日 我们很高兴地宣布 Vitess 21 发布,同时发布 Vitess Kubernetes(容器编排平台) Operator 2.14.0 版本。 版本 21 专注于增强查询兼容性、改进集群管理以及扩展 VReplication 功能,并实验性支持原子分布式事务和递归 CTE。主要特性包括引用表物化、多指标限流器支持以及增强的在线 DDL 功能。备份和恢复流程受益于新的 mysqlshell 引擎,而 vexplain 现在提供详细的执行跟踪和模式分析。
节流器剖析,第 3 部分 — PlanetScale
Shlomi Noach | 2024 年 11 月 19 日 这是三部分博客系列的最后一部分。如果您错过了之前的文章,可以通过阅读第一部分和第二部分来了解。在这篇结论中,我们将讨论节流器客户端及其身份、协作、优先级和约束问题。 我们的关注点继续放在异步、批量和海量操作上,例如 ETL、数据导入和模式变更。调用这些操作的组件就是节流器的客户端。这些组件需要将操作分解为合理的小子任务,并定期向节流器请求继续执行的许可。这是一种协作模型,客户端请求许可,我们稍后会讨论另一种设计。但首先,我们建议客户端应向节流器表明自己的身份。 即使只是为了分析或调查事件或能够生成指标的高层次目的,您通常也想知道哪些操作在什么时间被节流。您希望能够判断出每日聚合 ETL 作业在 07:00 到 07:25 之间大部分时间被节流。