菲尔兹奖得主、剑桥大学数学家Timothy Gowers近日在个人博客上分享了他使用ChatGPT 5.5 Pro的体验。令他惊讶的是，这款模型在一小时内连续攻克了多个博士级别的数学难题，展现出远超前代的推理能力。

菲尔兹奖得主的实测

Timothy Gowers是当代最有影响力的数学家之一，1998年获得菲尔兹奖，在组合数学和泛函分析领域有重要贡献。他在5月8日发布了一篇详细的博文，记录了自己测试ChatGPT 5.5 Pro推理能力的过程。

据Gowers描述，他给ChatGPT 5.5 Pro提出了多个需要深度推理的数学问题，这些问题的难度大致相当于数学博士资格考试或研究级别。让他印象深刻的是，模型不仅能够给出正确答案，还能提供完整的推理过程，包括：

• 对问题的准确理解
• 合理的解题策略选择
• 严密的逻辑推导链
• 对特殊情况的处理

与前代模型的对比

Gowers在博文中提到，之前版本的ChatGPT在处理类似难度的数学问题时，经常出现以下问题：

• 推理链中途断裂，得出错误结论
• 混淆不同数学概念
• 在计算步骤中出错
• 无法识别问题的关键约束条件

而ChatGPT 5.5 Pro在这些方面有了显著提升。Gowers认为，这一代模型的数学推理能力已经达到了”可以辅助专业数学研究”的水平。

对普通用户意味着什么

虽然菲尔兹奖级别的数学测试看起来离普通人很远，但ChatGPT 5.5 Pro展现出的推理能力提升，对日常使用也有实际影响：

• 编程辅助：更强的逻辑推理能力意味着在代码调试、算法设计等场景下能给出更准确的建议。
• 数据分析：处理复杂的数据分析任务时，模型能更好地理解数据关系和统计方法。
• 技术文档：在撰写技术文档、API文档等需要严密逻辑的内容时，输出质量更高。
• 教育辅导：作为学习辅助工具，能提供更准确的解题思路和步骤讲解。

AI数学能力的里程碑

ChatGPT 5.5 Pro的表现引发了AI社区的广泛讨论。有观点认为，这标志着大语言模型在形式推理领域取得了重要突破。也有研究者持谨慎态度，指出：

• 单一数学家的主观测试不能替代系统性基准评估
• 模型可能在训练数据中见过类似题目
• 真正的数学创新（如提出新定理、发现新证明）仍然是AI的短板

无论如何，AI在数学推理方面的进步速度是实实在在的。对于站长和开发者来说，善用AI的推理能力来辅助技术工作，已经是一个切实可行的选择。

OpenAI在推出实时语音和视频功能时，遇到了一个不大不小的基础设施难题：WebRTC。这个为浏览器实时通信设计的技术栈，在面对OpenAI的规模和需求时，暴露出了不少问题。本文分析OpenAI遇到的WebRTC困境，以及这对整个实时AI通信领域意味着什么。

什么是WebRTC

WebRTC（Web Real-Time Communication）是一套支持浏览器和移动应用进行实时音视频通信的开放标准。它被广泛用于视频会议、直播、在线教育等场景。Zoom、Google Meet、Discord等产品的底层通信都依赖WebRTC或其变体。

当OpenAI推出GPT-4o的实时语音功能时，选择了WebRTC作为客户端与服务端之间的实时音频传输方案。这个选择看起来很自然——WebRTC是浏览器原生支持的、成熟的实时通信方案。但在实际落地过程中，问题逐渐暴露。

OpenAI遇到的WebRTC问题

1. 延迟和抖动

AI实时语音对话对延迟的要求比普通视频会议更高。用户说完一句话后，期望AI能在几百毫秒内开始响应。但WebRTC的网络自适应机制（如抖动缓冲区、丢包重传）在某些场景下反而增加了延迟。

2. NAT穿透问题

WebRTC需要通过ICE（Interactive Connectivity Establishment）框架来处理NAT穿透。在复杂的网络环境（如企业防火墙、运营商级NAT）下，连接建立的成功率和速度都不够理想。

3. 服务端扩展

传统的WebRTC架构中，SFU（Selective Forwarding Unit）或MCU（Multipoint Control Unit）负责媒体流的转发和混合。当需要处理海量并发的AI语音会话时，服务端的扩展成本和复杂度急剧上升。

4. 浏览器差异

虽然WebRTC是W3C标准，但不同浏览器的实现细节存在差异。Chrome、Firefox、Safari在编解码器支持、API行为等方面的不同，给跨平台兼容性带来了额外工作。

替代方案探讨

有开发者提出了几种可能的替代方案：

• WebSocket + 自定义音频流：绕过WebRTC的复杂性，直接通过WebSocket传输PCM或Opus编码的音频数据。实现简单，但需要自行处理网络自适应。
• Media over QUIC (MoQ)：IETF正在标准化的新一代媒体传输协议，基于QUIC协议，目标是替代WebRTC用于大规模实时媒体分发。这也是那篇HN文章的讨论重点。
• gRPC Streaming：Google的gRPC框架支持双向流式传输，可以用于音频数据的实时传输，但浏览器端支持有限。
• 专有协议：像Discord那样，开发针对特定场景优化的专有协议。

对站长和开发者的启示

如果你在开发涉及实时AI语音交互的应用，以下几点建议：

1. 评估实际需求：如果你的应用不需要浏览器端实时音频，WebSocket方案可能更简单可靠。
2. 关注MoQ进展：Media over QUIC是未来方向，但目前标准化和实现都还不成熟。
3. 做好降级方案：即使使用WebRTC，也要准备WebSocket降级方案，确保在WebRTC连接失败时用户仍有基本体验。
4. 测试真实网络环境：在开发环境中的低延迟网络下测试没问题，不代表在用户的4G/WiFi环境下表现良好。

实时AI通信的未来

随着AI语音交互、AI视频通话等功能的普及，实时AI通信基础设施的需求会越来越大。WebRTC虽然是目前最成熟的选择，但确实需要演进才能满足AI场景的特殊需求。

OpenAI遇到的这些问题，其实也是整个行业需要解决的。未来可能会出现专门为AI实时交互优化的通信框架，或者WebRTC本身会针对AI场景进行扩展。