论文

给模型定日期:System Prompt 中隐藏的日期影响 LLM 评测

给模型定日期:System Prompt 中隐藏的日期影响 LLM 评测

可复现性 是科学研究的基础,但已有工作表明 LLM 的输出会随硬件和批处理方式而变化。本文指出一个被忽视的因素:当前日期会被隐蔽地注入 system prompt,用户无法控制,且每天都在变化。 作者在 9 个近期 LLM 和 6 个数据集 上进行实验,覆盖多项选择问答(MCQA)、数学推理、代码生成和机器翻译,发现模型性能仅随当前日期就发生变化: - MCQA 上差异最高达 6% - 数学推理最高达 14% - 代码生成最高达 7% - 机器翻译最高达 2.84 BLEU 此外,模型排名 也会随之改变,进而影响排行榜。该日期效应超过批次大小、数值精度等其他非确定性来源。Chain-of-thought 与 few-shot prompting 等标准提示技术并不能降低这种敏感性,chain-of-thought 甚至会放大它。 这些发现凸显了制定严谨评测协议的必要性,以确保 LLM 研究的可复现性与公平比较。

论文精读

TL;DR 论文发现 LLM 系统提示中被隐藏注入的当前日期会显著影响模型性能,最大波动达 14%,导致排行榜变化,威胁评估可重复性。

问题

问题背景

LLM 评估的可重现性愈发受到关注,已知硬件差异、批量大小等因素会导致输出非确定性。本文指出一个此前被忽视的因素:系统提示中隐藏注入的当前日期,该日期由服务方自动添加,用户无法控制且每天变化,从而影响模型行为。

现有方法局限

现有评测协议通常固定 prompt、解码参数、随机种子等,致力于消除确定性差异,但普遍未考虑时间元数据。系统提示中的日期戳可能被模型捕获为上下文线索,因其在预训练语料中频繁出现,会微妙改变生成分布。由于该变量不可见、日更且无固定“最优日期”,传统调参方式无法规避。作者在 9 个近期 LLM、6 个数据集上验证,性能随日期波动高达 6%(MCQA)、14%(数学推理)、7%(代码生成)、2.84 BLEU(机器翻译),且模型排名随之改变。更关键的是,标准提示技术如 CoT 和 few-shot 无法降低敏感性,CoT 甚至放大波动。

为什么这个问题难/重要

技术挑战在于日期注入发生在服务端,用户无法观测或干预,导致实验者无法通过提示工程固定变量;且影响是非单调的,不同日期表现无规律可循。这对依赖公共 leaderboard 的模型比较构成直接威胁:同一模型在不同日期提交可能得到不同分数,排名不稳定会误导技术选型与研究结论。此外,LLM 输出非确定性的既有认知多聚焦于硬件或并行计算,时间维度未进入标准评估协议,相关工具链也缺乏监测机制。

行业类比

这类似于软件持续集成测试中,构建环境注入当前日期导致测试结果微小漂移,而 CI 系统未将该环境变量纳入版本控制,最终影响发布决策。

核心洞察

  • 系统提示中隐藏注入的当前日期是一个被忽视且用户不可控的非确定性来源,其逐日变化会直接改变 LLM 评测结果,最大偏差可达 14%(数学推理)和 6%(MCQA),甚至导致模型排名反转。这一发现区别于此前聚焦硬件、批处理、数值精度等可控因素的研究,指出评测基础设施本身在默认配置下就会引入每日漂移,对可复现性和榜单公平性构成系统性威胁。
  • Chain-of-thought 和 few-shot 等标准提示策略不但不能缓解日期敏感性,CoT 反而放大了这种效应,表明模型在生成推理路径时更容易暴露内部表征对日期元数据的依赖。这提示评测协议不能仅靠提示工程修补,而需要从系统提示模板中显式移除或固定日期字段,或将其作为控制变量纳入消融实验,才能实现真正可比的模型间对比。

方法

实验输入

论文采用 受控评测 范式。输入为 6 个公开数据集,覆盖 多选问答(MCQA)、数学推理、代码生成、机器翻译 四类任务。每个样本的系统提示中注入一个日期变量,该日期来自评测当天的真实日期或人为遍历的日期集合,用户无法显式控制。

关键模块

  • 模型侧:选择 9 个近期 LLM,涵盖开源与专有模型;推理时保持权重、解码策略、硬件配置一致,仅改变系统提示中的日期字符串。
  • 提示变体:分别测试 标准提示、chain-of-thought、few-shot 三种格式,判断敏感性是否可被提示工程缓解。
  • 对比基线:同时改变 batch size 与数值精度,测量其对性能的影响,作为非确定性来源的参照。
  • 评估指标:MCQA 与数学使用准确率,代码生成使用执行通过率,机器翻译使用 BLEU。

输出与分析

输出为各任务在多个日期下的性能分布,计算最大值与最小值的 delta,并观察模型排名是否随日期翻转。实验结果显示 delta 可高达 6%(MCQA)、14%(数学)、7%(代码)和 2.84 BLEU(翻译),且 CoT 反而放大敏感性。

与同类非确定性研究不同,本文首次将 系统提示中的隐藏日期 作为独立变量进行系统性量化,证明其影响超过 batch size 与数值精度,为评测协议提出“固定日期或显式屏蔽时间元数据”的工程建议。

实验

实验设计

论文在 9 个近期 LLM 上,使用 6 个数据集(具体名称未在提供的材料中列出,覆盖 MCQA、数学推理、代码生成、机器翻译)评估系统提示中隐藏日期对性能的影响。通过控制仅系统提示中的日期字符串变化(其他条件固定),测量不同日期下模型输出的性能差异。

关键发现

  • MCQA 性能波动最高达 6%,数学推理 波动最高达 14%,代码生成 波动最高达 7%,机器翻译 BLEU 波动最高达 2.84。
  • 模型排名随日期变化而改变,直接影响 leaderboard 稳定性。
  • 日期效应超过 batch size 和 数值精度 等常见的非确定性来源。
  • Chain-of-Thought(CoT) 不仅未能降低敏感性,反而放大了日期效应;few-shot prompting 同样无助于稳定输出。

与基线对比

作者将日期效应与已知的推理非确定性因素(batch size、数值精度)进行对比,发现隐藏日期是更显著的非确定性来源。这揭示当前 LLM 评估存在一个被忽略的系统性偏差:即使用户固定所有可控参数,评估结果仍会因日期变化而不可复现。因此,建立更严格的评估协议(如显式固定或随机化日期、报告日期分布)对确保可复现性和公平比较至关重要。

行业影响

落地场景

论文揭示的日期效应直接影响所有依赖 LLM 稳定输出的生产系统。例如,电商平台 的商品描述生成、内容平台 的自动摘要与审核、教育科技 的数学解题助手、金融风控 的文本分析,都可能因系统提示中隐藏的日期变化导致输出质量波动,造成用户可见的性能时好时坏。

具体 use case:某电商推荐系统 使用 LLM 生成个性化商品文案,若模型在特定日期数学推理能力下降(最高 14%),可能导致价格计算或优惠规则解释错误;某企业服务 SaaS 的代码生成助手,日期敏感可能使生成代码在月末通过率下降 7%,引发客户投诉。

商业价值

识别并控制日期效应可带来直接成本节约:避免因性能波动导致的错误输出、人工复核和客户支持开销。在模型选型和评估中,排除日期干扰可做出更准确决策,选用在跨日期测试中稳定的模型,降低上线后性能漂移风险。对于提供 LLM API 的厂商,确保日期注入透明可控,可提升企业客户信任度,减少 SLA 违约纠纷。

与现有产品 / 工作流的接口

  • 在 CI/CD 评估流水线 中增加日期敏感性测试:固定多种日期运行基准,计算性能方差,将方差阈值纳入模型发布门禁。
  • 开发轻量级中间件,在请求 LLM 前拦截并统一处理系统提示中的日期字段(例如替换为固定日期或移除),适用于使用第三方 API 的场景。
  • 在监控系统中加入日期相关性指标,当模型输出分布随日期发生显著变化时触发告警,定位潜在问题。

局限

  • 论文未深入探究日期影响模型行为的机制,仅报告了现象。虽然观察到性能随日期变化,但没有分析模型内部表征、注意力模式或训练数据中日期相关模式,因此无法解释为何某些日期表现更好或更差。这限制了从该发现中提炼可操作的缓解策略,例如通过提示工程或微调来消除日期敏感性。
  • 实验覆盖的日期范围和模型数量可能不足以全面揭示日期效应的普遍性。虽然测试了 9 个近期 LLM 和 6 个数据集,但日期跨度、季节变化、年份等维度未系统考察;同时系统提示中其他隐藏元数据(如时间戳、用户代理)未控制,可能混淆结果。此外,对专有模型的测试可能受 API 版本和内部更新的影响,难以完全归因于日期本身。
  • 该工作指出了问题但未提出解决方案,对评估协议的具体改进建议较宏观。例如,如何设计日期无关的系统提示、如何固定虚拟日期、或构建更鲁棒的评估框架,均未给出实验验证。与已有非确定性研究相比,缺乏可操作的工程缓解措施,限制了其直接指导实践的价值。
论文Mario Sanz-Guerrero2026-09-29原文

相关内容