做LLM预测LLM Forecasting之前我一直低估了评估指标的力量——一个Proper Scoring Rules正确评分规则的选型直接决定了模型在预测任务上长成什么样。这两年我陆续在几个预测类产品里用大模型做概率判断、趋势估计和风险打分踩了很多评估上的坑之后才明白不是模型不会预测而是你用什么尺子去量它它就会朝什么方向长。这篇文章就把这块经验完整梳理一遍从评分规则的原理到它对LLM训练和推理的隐性影响再到完整的实操流程和排错清单希望对正在做预测类LLM应用的同学有实际帮助。1. 为什么LLM预测绕不开评分规则1.1 准确率不是万能的预测问题需要概率化评估我们做LLM应用时习惯性用准确率来评判模型效果预测涨了结果真涨了就算对预测跌了结果涨了就算错。但真实场景里LLM预测很少是一个二选一的判断题它通常要求模型输出一个概率比如明日指数上涨的可能性是68%未来三个月需求波动超过20%的概率为四成。这时候用准确率去评估就完全失真了——你只会得到一个二值化的判定而模型输出里最关键的概率信息被彻底丢弃。举个直观的例子模型A预测某事件发生概率为51%模型B预测为99%如果事件确实发生了用准确率看两者都是正确但显然模型B的判断质量远高于模型A。反过来如果事件没有发生模型A预测51%可能只是轻微偏差模型B预测99%就是极端置信下的巨大失误准确率却一视同仁地把两者都判为错误。这种粗糙的评估方式无法区分蒙对的预测和真正理解不确定性的预测也就没法指导你下一步该怎么优化模型。所以做预测类应用第一步就是抛弃准确率思维换成能对概率质量打分的评估指标。这也是我在实际项目里踩过最大的坑一开始用Accuracy衡量模型结果模型越调越极端输出概率全部往0和1两端挤因为这样做更容易猜对。后来换成了Proper Scoring Rules正确评分规则来做评估模型的概率分布才变得合理起来。1.2 Brier Score与Log Loss最基础的两个正确评分规则Proper Scoring Rules是一类评分函数的统称核心性质是当预测者真实相信某个概率p时按照p来报告预测才能拿到最优的期望分数。也就是说诚实报告是最好的策略任何虚报、极端化、保守化的报告都会在期望上吃亏。这个性质对LLM尤其重要因为它给了模型一个说真话的数学激励。实操中最常用的两个评分规则是Brier Score和Log Loss对数损失。Brier Score的计算方式是预测概率与实际结果之差的平方公式很简单[ Brier \frac{1}{N} \sum_{i1}^{N} (p_i - y_i)^2 ]其中p_i是模型给出的概率y_i是实际结果发生为1不发生为0。Brier Score的范围是0到1越小越好。Log Loss则是取实际发生结果对应的预测概率的负对数[ LogLoss -\frac{1}{N} \sum_{i1}^{N} [y_i \cdot log(p_i) (1 - y_i) \cdot log(1 - p_i)] ]两者性质上有些微妙差别指标对极端错误的惩罚对中间概率的偏好适用场景Brier Score温和按平方惩罚相对友好一般分类、比赛评估、业务风控Log Loss极强概率趋近0/1时损失趋近无穷鼓励概率不要过于极端需要避免过度自信的场景CRPS连续值扩展版对分布整体打分销量预测、天气预测、量化交易Log Loss对模型在完全错误方向上的极端自信比如预测99%结果却错了惩罚极其猛烈这是比Brier Score更敏感的诊断工具也是为什么很多前沿预测竞赛选择用它做最终排名的原因。1.3 用错评分规则的代价模型会学会钻空子我不止一次看到团队在评估LLM预测时用了一套不合适的规则导致模型的预测行为被带偏。最有名的案例逻辑是这样的如果评估只看预测概率是否超过50%这个阈值那么模型只要把概率尽量往极值推就能最大化命中率——反正超过50%就算赢。结果就是模型输出的概率严重失真看起来预测很自信实际上完全经不起校准检验。Proper Scoring Rules之所以proper在于它天然杜绝了这种钻空子行为。如果你真实认为概率是70%虚报到90%并不能提高你的期望得分因为Brier Score和Log Loss都惩罚过度自信虚报到50%也同样吃亏因为这会损失你在正确方向上的一部分正收益。这种机制保证了诚实报告的期望收益最大化。再往深一层想评分规则不只是事后评估工具它本质上是优化目标的载体。无论你是在做RLHF奖励模型还是在下游任务里微调LoRA只要损失函数里隐含了对预测行为的衡量评分规则就在悄悄改变模型的策略空间。所以选对评分规则本质上是在给模型立规矩——这也是Proper Scoring Rules Shape LLM Forecasting这句话背后最核心的机制。2. 评分规则如何反向塑造LLM的预测行为2.1 交叉熵损失LLM从出生就在被评分规则训练聊到LLM工作原理很多人第一反应是预测下一个token但很少有人在预测下一个token和Proper Scoring Rules之间画等号。事实上LLM预训练阶段的损失函数——交叉熵损失就是Log Loss的广义版本。模型每预测一个token都是在给整个词表上的每个候选词分配一个概率分布然后用真实token对应位置的负对数似然作为损失。所以严格来说LLM在训练阶段已经经历了海量的评分规则优化它被反复训练成尽可能准确地用概率表达下一个token的可能性。这带来一个有意思的推论——大模型的底层表征对概率预测是有先天敏感度的它天生被训练为不撒谎的概率预测器。但问题是这个训练目标是在token空间里而不是在用户问的事件空间里。当你问模型你觉得明天涨的概率有多少时模型需要把它在海量文本里学到的统计规律转化成一个具体领域的概率数值。这个过程容易出错原因有两个第一事件空间的边界模糊用户说上涨到底指涨幅超过多少第二模型在文本生成过程中受语气、上下文、角色设定的影响太大容易被带偏。所以虽然底层机制在诚实预测但表层输出却容易出现各种偏差。2.2 对齐阶段的隐性信号奖励函数也在用评分逻辑到了RLHF基于人类反馈的强化学习阶段评分规则的影响就更加直接了。RLHF的核心是训练一个奖励模型来模拟人类偏好然后用强化学习让LLM的输出拿到更高奖励。如果你希望LLM在预测任务上表现好那么奖励模型的构建方式、评估数据的标注方式本质上就是在定义一个评分规则。我做预测类产品时观察到一个很典型的例子人类标注员在评估LLM预测质量时天然倾向于结果对了就打高分结果错了就打低分而不是去评估模型给出的概率是否合理。这样一来奖励模型就变成了一个二值化的马后炮评判器模型在RLHF阶段学到的策略就会变成要么给出模糊的、难以证伪的预测要么在内部自我确认后给出极端概率尽量规避被打低分的风险。这就解释了为什么很多通用LLM在零样本预测任务上表现不理想——它被对齐成了让人满意而非预测准确。想纠正这一点要么在提示词层面设计更精细的评估框架要么在微调阶段直接用Brier Score或Log Loss这类Proper Scoring Rules作为奖励函数的一部分。后者已经有研究论文在探索核心思想是让强化学习的奖励信号来自校准的预测质量而不是人类的事后主观判断。2.3 置信度与校准模型的概率输出值不值得信评估LLM预测时我特别看重一个概念校准度Calibration。校准度指的是当模型说某事有70%概率发生时这件事在现实中是否真的以接近70%的频率发生。一个高度校准的模型它的概率输出与真实频率高度吻合而一个校准差的模型可能说70%但实际只有40%也可能说60%但实际到80%。用生活化的方式理解校准一个天气预报员如果说明天降雨概率70%那么一周之内他给出70%预报的日子应该有大约7成真的下雨。如果实际只有3天下雨那这个预报员就严重过度自信了。LLM也是如此我见到太多模型在回答预测类问题时倾向于输出80%到95%的高概率区间无论问题多难、信息多不充分。这种过度自信本质上是模型生成听起来合理文本的副作用而不是真实的不确定性表达。校准度与评分规则的关系非常密切Brier Score和Log Loss都可以分解为校准误差和锐度两部分。校准误差衡量的是预测概率与实际频率的系统性偏差锐度衡量的是预测分布的尖锐程度——一个总是输出50%的模型校准可能很好但锐度很差因为它没有提供任何有效区分信息。Proper Scoring Rules同时惩罚校准误差和锐度的不均衡所以它评估的不只是准不准还有有没有信息量。2.4 输出空间的选择文本、JSON、还是多次采样在真实系统里LLM预测的输出形式直接影响评分质量。我建议预测类应用尽量不要让模型自由发挥输出一段包含概率的文字描述因为解析成本高、概率容易缺失、语义模糊。更务实的做法是定义严格的输出schema让模型结构化的输出JSON比如{ event: stock_index_up, probability: 0.68, confidence_interval: [0.55, 0.80], reasoning: 基于近期流动性改善和情绪修复 }不过要注意一点很多LLM平台比如接入LLM时常用的dify或自研框架在配置模型输出时默认会让模型附带思考过程或推理链路这在对话场景里很有用但用在预测打分场景里就是灾难——思考过程会占用token预算导致schema输出被截断甚至把概率值挤到被忽略的位置。所以接入时一定要显式关闭输出思考过程或者设置合理的max_tokens让模型优先保证结构化字段的完整性。另外单个采样得到的概率值方差很大。同一个prompt在temperature1.0下跑十次可能得到0.4、0.5、0.7、0.35这样跳来跳去的结果。一个很有效的工程技巧是多次采样取均值或者对多个采样结果做整体分布统计把模型平均概率作为最终输出。这本质上是在用蒙特卡洛方法平滑单次生成的随机性得到更稳定的概率估计。3. 实操给LLM搭一套评分与校准的完整流程3.1 任务定义与数据准备先确定你要预测什么完整流程的第一步是明确定义预测任务。我以一个很常见的场景为例预测某只股票未来五个交易日的涨跌概率。这类任务有两个好处一是结果可验证五天后数据自然出结果二是能持续积累测试集方便做长期的评分追踪。数据准备阶段要注意把历史数据切成独立的样本避免数据泄漏。比如你计划用过去两年的数据进行回测就要把数据集按时间顺序划分训练窗口在时间上严格早于测试窗口。预测日期、预测事件涨跌幅阈值、实际结果是三个核心字段。不要用模型已经见过的未来信息去提示它哪怕你只是在prompt里无意中提到了本周市场已经上涨了3%这都会干扰测试的有效性。3.2 设计Prompt模板与输出Schema提示词模板的质量直接影响预测效果。我的经验是预测类Prompt应该包含四部分任务背景、输入数据、预测要求、输出格式。任务背景要讲清楚你是一个资深策略分析师之类角色设置但不建议过度渲染角色因为过度角色化会让模型倾向于输出有观点而不是有概率的结论。输入数据部分尽量用简洁的表格或列表呈现避免大段文字把模型的注意力带偏。预测要求部分要显式写清楚请基于给定信息给出严谨的概率判断不要为了立场而极端化概率如果信息不足请适当降低置信度。这类句子能一定程度上抑制模型的过度自信。输出格式部分用JSON Schema描述得越具体越好同时附上最少一个示例模型对few-shot格式的学习能力远强于对纯描述的遵循能力。一个我在项目中反复调优后的Prompt模板大致长这样你是一位严格遵循贝叶斯思维的概率预测助手。请根据以下历史数据和市场背景 预测目标事件发生的概率。注意概率必须是校准的即你认为有70%把握时 事件实际发生频率应接近70%。 [数据输入] 股票X近20个交易日收盘价 [...] 近期成交量变化 [...] [任务] 预测3个交易日内股票X收盘价上涨超过1%的概率是多少 请输出JSON格式{probability: 0到1之间的小数, reasoning: 不超过50字的依据} [要求] 1. 严格输出JSON不要输出其他内容。 2. probability必须是0到1之间的数字不要使用百分比字符串。3.3 采样、解析与评分计算拿到模型的输出后先做解析和过滤。我会用JSON解析库读取probability字段如果解析失败就把该样本标记为异常如果reasoning字段缺失但不影响概率解析也可以保留。多做一步很值得对同一个预测任务重复采样3到5次把多次概率取平均后作为最终预测值。实测下来多次采样平均能把单次生成的随机噪声大幅降低校准表现更稳定。接下来就是评分环节。这里给出一个可直接复制的Python实现用来计算Brier Score和Log Lossimport numpy as np from sklearn.metrics import brier_score_loss, log_loss # predictions和outcomes是平行数组 # predictions是0到1之间的概率outcomes是0或1的实际结果 predictions np.array([0.68, 0.42, 0.90, 0.31, 0.75]) outcomes np.array([1, 0, 1, 0, 1]) brier brier_score_loss(outcomes, predictions) ll log_loss(outcomes, predictions, labels[0, 1]) print(fBrier Score: {brier:.4f}) print(fLog Loss: {ll:.4f}) # 对比baseline预测长期基准频率比如样本中正类占比 base_rate outcomes.mean() baseline_pred np.full_like(predictions, base_rate) brier_base brier_score_loss(outcomes, baseline_pred) ll_base log_loss(outcomes, baseline_pred, labels[0, 1]) print(fBaseline Brier: {brier_base:.4f}) print(fBaseline Log Loss: {ll_base:.4f})如果模型的Brier Score和Log Loss比baseline好不了太多说明模型并没有真正学到预测信号只是在输出感觉上合理的概率。这个对比基准是很多团队最容易漏掉的一步——不做baseline对比你根本不知道模型的绝对分数是优秀还是不及格。3.4 校准检查与温度调节评分计算完之后一定要做校准检查。最简单高效的诊断手段是可靠性图Reliability Diagram把预测概率分为几个区间比如0-0.1、0.1-0.2……0.9-1.0然后统计每个区间的实际结果频率看两者是否接近对角线。如果点都落在对角线下方说明模型整体过度自信落在线下方说明预测概率系统性偏高。修正校准偏差有几种常用手段。第一种是温度缩放Temperature Scaling把模型的logits除以一个常数温度T后再做softmaxT越大预测概率越趋于平滑。对LLM而言temperature参数不仅影响生成多样性也直接影响概率输出的锐度降低temperature能让输出概率更保守、更集中。第二种是经验校准Empirical Calibration收集模型在历史测试集上的预测结果拟合一个从模型概率到实际频率的映射函数然后再对后续预测做映射修正。这个方法在工程上最实用等于是给模型加了一层事后的诚实化校正。第三种是用提示词引导告诉模型如果你的预测过度自信请降低概率之类的话效果存在但不如前两种稳定。我在一个实际项目里用温度缩放做了一组对比测试temperature0.2时模型的Brier Score比temperature1.0时改善了约30%主要原因是极端概率的出现频率明显下降校准曲线更贴近对角线。但温度过低也会导致预测丧失区分度所以最终参数通常需要通过验证集调优而不是盲目取低。4. 常见问题与排查技巧实录4.1 请求超时与模型无响应预测类应用经常遇到LLM请求超时报错信息是llm request timed out. the model did not produce a response before the deadline。这类问题的根因通常不是网络而是模型在生成长篇思考过程或reasoning字段时消耗了过多token导致响应时间超过网关设置的阈值。排查思路很直接先看调用日志里实际生成的token数再看max_tokens配置是否过小最后看prompt是否触发了模型输出大量分析文本。我的做法是预测类任务统一设置max_tokens在200到500之间并显式要求模型不要输出除JSON外的任何解释性内容。如果任务本身需要复杂的逻辑推理就把推理拆到单独一个prompt里完成再让另一个prompt基于推理结果输出预测。这样能避免一个请求干太多事导致的超时问题代价是增加了调用次数但胜在稳定可控。4.2 模型不按Schema输出接入LLM平台时经常遇到provider rejected the request schema or tool payload这类错误。出现这个问题的原因通常是输出schema定义过于复杂或者使用了平台不支持的类型标签。文档里说得清楚但实际踩坑时才发现很多平台只支持部分JSON Schema特性。我的建议是schema尽量扁平不要嵌套太深boolean类型能不用就不用统一用0/1或字符串替代数组元素类型保持一致避免混合类型。另外就是容错解析。即便schema定义正确模型偶尔也会输出残缺的JSON尤其当token预算吃紧时。我习惯在解析层做三层兜底第一层直接json.loads第二层用正则提取probability字段第三层如果提取失败就把这条样本标记为预测失败让它不参与评分。千万不要让解析失败拖垮整个评分流程记录好失败率本身也是一个重要的质量指标。4.3 预测概率输出不稳定同一个prompt同一个模型连续跑三次得到完全不同的概率这是概率输出不稳定问题。模型生成存在随机性这是常识但对预测类应用来说这种不稳定是致命的因为用户会质疑系统的专业性。最有效的治理手段是多次采样平均。我在工程里会把采样次数设为5逐个请求再合并结果计算平均概率和标准差。标准差本身也能提供额外信息如果某个预测问题的标准差特别大说明模型对这个问题没有一致的意见这个预测本身就更值得怀疑。这一招在金融预测类场景里尤其好用可以把模型不确定变成产品的一个卖点。另外很多推理框架支持设置随机种子固定seed能让同一输入得到稳定输出适合A/B测试对齐场景。4.4 模型过度自信输出永远在90%以上我遇到最多的预测质量问题就是LLM无论什么问题都给出80%以上的高概率似乎什么事件都很有把握。这类问题光看Brier Score不容易发现因为它有时甚至能拿到不错的分数但要叠加可靠性图就原形毕露——预测90%的样本实际准确率可能只有60%。诊断方法把多次预测结果按概率分箱统计各箱的实际频率。如果预测概率和实际频率的系统偏差很规律首选温度缩放如果偏差集中在某个概率段考虑用经验校准映射。我见过一个比较离谱的case模型因为系统提示词里写了你是专家级分析师结果把专家理解成必须自信所有预测都往90%以上走。把角色设定改成严谨、承认不确定性的科研人员后概率分布立刻恢复正常。所以排查时先看提示词的角色设定是否在诱导模型极端输出这一条往往被人忽略但其实改动成本最低、效果最直接。最后做个小结之外的经验分享做LLM预测评估别把目光只盯在猜得对不对上。我个人的体会是一套靠谱的评分体系加上校准检查比换更大的模型、调更长的prompt带来的提升都明显。评估规则设计好了模型自然会被引导着输出更诚实、更有区分度的预测——这个先有尺子再量长度的思路比你反复试各种提示词技巧重要得多。如果你也在做类似的预测应用建议从Log Loss加可靠性图的组合开始先跑通再优化这个基础打牢之后后续的模型微调和提示词工程才有可靠的标尺。