kalshi-weather-markets

Kalshi 天气市场 — 每日最高 / 最低温度

Kalshi 为美国约 20 个城市的每日最高和最低温度提供二元合约，结算结果为 YES（$1.00）或 NO（$0.00）。本技能涵盖市场结构、从预报到概率的映射、精确的结算机制，以及经过实践总结出的注意事项。它构建在交易所层之上——有关 Kalshi API 的机制（主机、身份验证、订单、订单簿、蜡烛图），请参阅 kalshi-api 技能；有关策略、仓位规模和回测，请参阅 prediction-market-strategy。

合约类型

区间 — B<center>

区间代码 B<center> 表示一个宽度为 2°F、两端均包含的范围。

• B74.5 覆盖两个整数 {74, 75}°F。
• 结算温度恰好为 74 或 75 时，YES 才成立。
• 同一事件中的区间互斥；加上两个开放尾部市场后，它们共同构成完备集合。
• 它们的 YES 价格之和为超额价差（公允值 = 1.0；> 1.0 = 总体定价过高）。

阈值 — T<strike>

阈值代码 T<strike> 表示单边二元合约。

• greater → cli >= strike + 1 时 YES 才成立
• less → cli <= strike - 1 时 YES 才成立
• **重要：**无法从代码推断 strike_type（"greater" / "less"）。每次都要从 API 的 strike_type 字段读取。

代码格式

KXHIGH<CITY>-<YYMONDD>-B<center>     # bracket high
KXLOW<CITY>-<YYMONDD>-T<strike>      # threshold low

日期编码在代码中，无法从 close_time 推导。
KXHIGHNY-26JUN21 的结算日期为 2026-06-21 LST。close_time 是次日 UTC（约为 ET 时间 00:59）。按 close_time 关联会导致所有标签偏移一天——请使用代码中的日期。

---

预报 → P(YES)

给定当天极值的预报分布 N(μ, σ)，应用半整数连续性校正（必需——结算值为整数，而非连续刻度）：

# Bracket B<center>, covering integers {floor, cap}
P(YES) = Φ((cap + 0.5 − μ) / σ) − Φ((floor − 0.5 − μ) / σ)

# Threshold "greater":
P(YES) = 1 − Φ((T + 0.5 − μ) / σ)

# Threshold "less":
P(YES) =     Φ((T − 0.5 − μ) / σ)

Φ(x) = 0.5 · (1 + erf(x / √2))   # stdlib only, no scipy needed

±0.5 的偏移不可省略。省略该偏移会使每个区间都产生偏差。将 2°F 区间视为 1°F 的半开区间，曾在一个项目中产生**+1640% 的虚假回测收益**。

可参阅 scripts/weather_brackets.py，其中提供了全部四个函数的可运行实现。

---

从集合预报分位数推导 (μ, σ)

sigma_raw = max((p90 − p10) / 2.56, 0.5) · sigma_scale · sigma_mult
mu        = p50                          # or nowcast-blended (see forecasting.md)
sigma     = max(sigma_raw, 0.1)          # hard floor against degeneracy

2.56 这个除数是标准正态分布第 10 至第 90 百分位数之间的跨度（2 × 1.28σ）。

---

CLI 空间偏差校正

结算值（NWS CLI 整数 °F，LST 日期）不等同于原始 ASOS/METAR 逐小时最高 / 最低值——CLI 会应用质量控制、备用站点回退和 LST 汇总。计算 P(YES) 前应先调整 μ：

mu_cli = mu_metar + bias_city_season     # bias = oracle_extreme − asos_extreme, fit per city + season

按城市拟合 bias_max / bias_min 的季节性（周期性）曲线。跳过此步骤会系统性地错误定价存在结构性 CLI/METAR 差异的城市的所有区间。

---

结算规则

Kalshi

• **数据来源：**NWS 气候报告（CLI）——由各 WFO 发布的官方每日气候摘要。
• **备用来源：**IEM ASOS 每日下载数据与 CLI 完全一致，且可通过程序获取。
• **时段：****LST（当地标准时间），不调整夏令时。**全年均按 LST 午夜至午夜计算一天。
• **数值：**该 LST 日期的整数 °F 最高温度（HIGH）或最低温度（LOW）。
• 区间：cli ∈ {floor, cap} 时 YES 才成立（两端均包含）。
• 阈值 greater：cli >= strike + 1 时 YES 才成立。
• 阈值 less：cli <= strike - 1 时 YES 才成立。

结算来源参考资料

**在评分或交易前，请阅读每个市场自己的规则手册。**结算来源、站点和日期时段均为各市场的合约条款，可能发生变化。

资源	URL
Kalshi 市场规则 / 规则手册	https://docs.kalshi.com（每个市场的“Rulebook”）
NWS 气候报告（CLI）	https://www.weather.gov/wrh/Climate
IEM ASOS 每日下载	https://mesonet.agron.iastate.edu/request/daily.phtml
Polymarket 结果认定（WU）	https://www.wunderground.com
Polymarket 争议（UMA）	https://docs.uma.xyz

---

跨平台差异

同一日期的同一座城市，在不同平台上的结算值可能不同——原因既包括气象站，也包括春季／秋季的夏令时窗口。

维度	Kalshi	Polymarket
数据源	NWS CLI / IEM ASOS	Weather Underground
日期窗口	LST（无夏令时）	当地时间（有夏令时）
NYC 气象站	KNYC（中央公园）	KLGA（拉瓜迪亚机场）
舍入方式	整数 °F，t ∈ {floor, cap}	根据 WU 历史数据

任何跨平台分析都必须根据各自的数据源结算每一方。

---

预报融合（当日路径）

有日内观测值后，将 μ 向实际情况调整，并缩小 σ：

• **最高温：**将 μ 限制在 [obs, obs + drift · hours_remaining] 范围内
• **最低温：**将 μ 限制在 [obs − drift · hours_remaining, obs] 范围内
• σ 按 sigma_raw · sqrt(hours_remaining / 24) 缩小，下限为 sigma_floor（≈ 0.5）
• drift 默认约为 3.0°F/hr

可选的 NWP 先验融合：new_p50 = w · hrrr + (1−w) · p50（w ≈ 0.5），然后使用经过校准的 σ 重建对称分位数。

---

校准后模型表现（参考数据）

按城市统计的样本外 Brier 分数，涵盖 22 个最高温和 22 个最低温（v1.5，2026-06-17 基线）：

指标	范围
按城市统计的样本外 Brier 分数	0.07 – 0.14（越低越好；0.25 = 气候基准）
按城市统计的准确率	65–85%（区间分类）

预报能力 ≠ 交易优势。 相比气候基准高出 0.05 Brier 分数的校准模型，并不保证在市场价格下具有正 EV——市场已经纳入了 NWP。实际优势在于做市方对定价错误的冷门区间进行反向交易（热门—冷门偏差），而非原始方向预测。

---

天气数据注意事项

1. 结算数据源错误。 使用与平台结算结果相关但不一致的推导值评分，会导致约 10% 的结果反转。应使用平台自身的 result 结算。

2. 区间边界差一位（虚构的 +1640%）。 将 2°F 含端点区间 {floor, cap} 当作 1°F 左闭右开区间 [floor, cap)，会制造出巨大的虚构回测优势。区间两端均包含。

3. 无法从 ticker 推断 strike_type。 低温市场中的 T74 可能是 greater，也可能是 less。始终从 API 读取 strike_type。切勿猜测。

4. 使用 ticker 中的日期，而非 close_time。 合并结算日期时，应使用 ticker 字符串中嵌入的日期，而不是 close_time（其时间为次日 UTC）。

5. LST ≠ 当地时间。 Kalshi 按 LST 结算（无夏令时）。在春季／秋季，LST 窗口相对于当地时间会发生偏移。在夏令时转换日，将使用当地时间的 WU 数据与 CLI 交叉比对会产生不匹配。

6. CLI ≠ METAR。 原始 ASOS 每小时最高／最低值并非结算值。CLI 会进行质量控制、在必要时使用备用气象站，并按 LST 汇总。计算 P(YES) 前，应先拟合各城市的季节性偏差修正。

7. UTC 与当地日期的特征聚合。 按 UTC 日期而非 LST 日期聚合预报特征会造成标签错位——一项研究中因此损失了约 14 个百分点的准确率。

8. 时钟不匹配导致前视偏差。 在 18:00Z 的订单簿快照中成交，却使用截至 14:00 LST 的特征，会使非东部时区城市的交易利用未来信息。应使用各城市自身的当地决策时间。

9. 虚假的 1 美分卖价。 1¢ 卖价档位经常是虚假挂单；假设能在这些价位成交，会使 PnL 高估约 23 倍。只统计在多个快照中持续存在且有成交记录佐证的深度。

10. 将 overround 用作诊断指标。 汇总一个事件完整区间组中所有 YES 价格。overround > 1.0 属于正常情况（平台优势）；overround >> 1.1 则表示事件定价错误（或数据错误）。

---

文件

参考资料

• references/brackets-and-settlement.md — 区间／阈值结构、P(YES) 公式、结算规则、跨平台差异表、overround
• references/forecasting.md — 集成分位数 → (μ, σ)、预报融合、CLI 空间偏差修正、模型能力数据、预报 ≠ 优势

脚本

• scripts/weather_brackets.py — 高斯区间／阈值 P(YES)、结算判定和分位数→(μ,σ) 函数（仅使用标准库，可离线运行）