---
layout: post.njk
source: https://yage.ai/share/codex-api-behavior-thermometer-20260724.html
speaker: yage.ai
title: |-
  每天问大模型 100 个无聊问题，能当作 API
  的“温度计”吗？
date: '2026-07-24'
summary: 文章探讨了如何利用向大语言模型连续提问大量无聊问题（如随机数选择）来作为一种低成本的‘温度计’，实时观测API底层推理栈的状态变化。通过分析不同问题的回答分布熵的变化，可以敏锐地捕捉到服务栈的意外漂移，从而在没有官方反馈的情况下提示开发者进行诊断。
area: tech-engineering
category: ai-application
tags:
  - api-monitoring
  - inference-stack
  - distribution-entropy
  - model-behavior
people: []
companies_orgs: []
products_models:
  - gpt-5.6-sol
media_books: []
draft: true
status: evergreen
---

## 先猜一个数字

让大语言模型“在 1 到 10 之间随机选一个数字”，连续问它 20
次，你觉得会发生什么？

很多技术读者的第一反应是：既然模型在生成文本时带有概率采样，即使把采样温度设得很低，20
次回答也应该分散落在好几个不同的数字上，就像连续掷 20 次骰子一样。

不妨先在心里选一个你预测的结果，再看我们实际测到的答案。

日常调用 API
时，开发者早已习惯把大模型当成某种概率系统。当接口偶尔报错或者生成质量下滑时，大家也能猜到基础设施可能出了某种短暂故障。问题在于，除了等待官方状态页面的更新，或者在社区里交流“今天模型是不是变笨了”，开发者手中缺少一种低代价、能长期运行的观测手段，来确认
API 底层的推理栈（inference stack）到底有没有发生改变。

如果有一种观察方法，每天只需要消耗很少的 token，就能像温度计一样感应
API
终点的状态，它会是什么样？答案或许就藏在那些看起来极其无聊的随机数问题里。

## 答案是 20 个 7

在第一天的测试中，我们针对 gpt-5.6-sol 模型的 API
运行了这组实验。结果非常干脆：连续 20 次让它选 1 到 10
之间的随机数，回答清一色全是 7。

为了确认这是否只是某一个特定提问的偶发现象，我们把这种测试扩充为“每天问
100 个小问题”，包含 5 组不同类型的极简提问，每组重复 20 次：

1 到 10 选随机数：20 次回答全部为 7。

选一个随机字母：20 次回答全部为 Q。

1 到 100 选随机数：20 次回答中，有 15 次是 47，4 次是 57，1 次是 73。

最喜欢的数字：20 次回答中，有 19 次是 7，1 次是 42。

抛硬币：20 次回答中，出现 5 次正面（heads）与 15 次反面（tails）。

这 100
个小问题展示了低熵短回答的具体形态。它表明模型在面对看似自由的选择时，其实带着极其强烈的内在偏好，而不是均匀散开。

这里还有一个细节：像 1 到 100 选随机数（出现 47、57、73
三种结果）以及抛硬币（出现正面与反面两种结果），说明完全相同的提示词在多次调用中输出了不同的文本。这一现象削弱了“网关只是简单做
Response Cache
静态缓存”的假说，不过它还没有完全确定服务栈内部的缓存机制到底如何工作。

## 这不是 Codex 的怪癖

这种集中偏好的分布，并不是某一个模型或偶然的特例。

2026 年发表的论文 One
Token Is Enough 测试了 165
个大语言模型。结果显示，在极简短回答下，不同模型回答分布的中位熵（median
entropy）只有约 1.0
bit。也就是说，模型在面对自由选择时，天生就会把大部分概率压在极少数选项上。

当我们每天收集这 100
个问题的回答频率时，要怎么比较前后两天、或者两个时间段的分布变化？论文使用了
Jensen-Shannon
divergence（JSD）这个指标。它其实就是一个衡量两张概率分布表“有多不像”的数字：数值接近
0，说明分布几乎没变；数值变大，说明回答的偏好发生了偏移。

论文进一步验证了这种分布对变化的敏感度：在包含 40
组问题的测试集中，仅凭回答分布来区分不同模型的等错误率（Equal Error
Rate, EER）能低至 7.3%；即使压缩到 8 组问题，错误率也只有 10.6%
左右。不过需要明确的是，论文研究的是用分布指纹来识别不同模型，而我们关注的是另一个方向：在同一个
API 终点上，用这种敏感的分布变化来感应推理栈的行为漂移。

## 为什么每天都要问一次

为什么要每天重复问这 100 个无聊的小问题？

回顾过去的技术事故，例如 Anthropic 曾确认基础设施隐患导致 Claude
模型的错误率上升，当时许多开发者都凭直觉感到“输出质量变差了”。但用户和厂商之间缺少一个公开、低成本且量化的共同观测数据。服务调整发生后，大家只能凭感觉猜，没人能准确说出变化究竟是从哪一天开始的。

大模型 API
的服务栈包含众多环节，从底层的采样参数、路由规则，到上层的安全过滤或推理协议调整，任何微小的改动都有可能改变模型在低熵提问上的输出分布。

每天问 100 个小问题，就像在 API
终点旁挂了一支轻量的温度计。虽然单个小问题的偏好改变无法直接指出底层具体出了什么故障（它提示变化，但不归因），但这种低成本的时间序列能够率先捕获推理栈发生的意外漂移，提示开发者何时需要发起更深度的诊断。

## 把温度计公开出来

为了把论文中揭示的分布特性变成长期持续的观测实践，我们建立了 Codex Behavior
Today 项目，并上线了公开监控看板 Dashboard。

项目的运行方式保持了清晰的隐私与数据分离： -
本地采样器每天自动针对目标终点发起 100
次极简提问，并将包含详细延迟与原始回答的数据保留在本地 SQLite
数据库中，不需要共享凭据或公开私有对话。 -
每次运行只把汇总后的回答计数、延迟摘要与分布差异指标提交到 Git，并通过
GitHub Pages 自动渲染成公开看板。

无论是想复现看板还是扩展观测，整个流程都比较轻量：开发者只需 clone
仓库，使用 uv venv .venv
创建虚拟环境并安装依赖，配置好本地授权 CLI
后即可运行采样与站点构建。即便没有 API
凭据，也可以直接利用仓库中开源的每日 aggregate
数据重新生成站点与校验测试。我也欢迎社区提交
PR，把这套观测机制扩展到更多 API 终点上。

## 它能告诉我们什么

最后，我们需要平和客观地看待这支温度计的边界。

低熵短回答的分布改变，只代表该 API
终点的服务栈行为相比历史基线发生了偏移。它并不等同于“供应商偷偷替换了模型权重”，也不代表模型的能力发生了下降。

Codex Behavior Today
概念图：浅蓝色的研究仪表盘展示部分低熵问题集中在单一答案，旁边保留跨日趋势线

第一天（2026-07-22）的 100
次采样为我们记录下了第一个初始观察点。在接下来的 7 到 14
天里，持续的公开采样实验将逐步建立起稳定的历史基线。只有经过这段时间的观察，我们才能验证这组低成本的无聊问题，能否真正成为大模型
API 领域中敏锐而可靠的探矿金丝雀。