Prompt 里写着过时的年份,把模型锚在错的 context

2026 年了 prompt 模板里还写 2023。模型按 2023 回答——推荐过时的 API、过时定价、过时的事实。日期 staleness 会复利,怎么让 prompt 常青。

你的 prompt 模板是 2023 年写的,有一句 “Consider the current state of AI in 2023 when answering.”现在是 2026 年。模型老老实实把答案锚到 2023——推荐 GPT-4(已被取代)、引用 2023 定价、提到现在已经过时的框架。模型的事实没旧,但你告诉它一个错的年份。过时年份字符串、硬编码日期、“as of X” 锚点,是长生命周期 prompt 里的静默毒药。

这种 bug 几乎过不了 QA——回复仍然流畅权威。它在用户发现”等等,这个推荐是几年前的”那一刻爆——信任清零。

常见原因

1. instruction 里硬写年份

"You are a helpful AI assistant trained on data up to 2023."3 年前写的,从没更新。模型现在以为还是 2023、不肯提近期事件。

怎么判断:grep prompt 里的 20\d\d。每个年份串都是 staleness 候选。

2. “current year” 没插值进去

模板写 "As of {{current_year}}",但插值引擎没接上,字面 {{current_year}} 字符串直接到模型。模型可能解读成”没指定年份”,更糟时当成 placeholder 自己填。

怎么判断:发请求看模型真正收到了什么。渲染后的 prompt 里看到字面 {{...}} 就是插值断了。

3. few-shot 里带日期

few-shot 例子写 “In 2023, the iPhone 15 released…”。现在 2026 跑现代 query,模型按 2023 的引用模式输出。

怎么判断:审 few-shot 例子里的日期引用。任何具体年份会锁住时间帧。

4. RAG 语料是旧文档

retrieval 系统取出 2023 年写的文档。即使 system prompt 是 2026 的,retrieved content 把模型锚到 2023 的事实。

怎么判断:看 top retrieved chunks 的发布日期。> 2 年的 + 用户问的是当下事——RAG 在喂旧 context。

5. “knowledge cutoff” 行跟任务冲突

system prompt 写 “Your knowledge ends at October 2023”,user 问 2024 发生的事。模型拒答或编造,而不是用你提供的当前 context。

怎么判断:response 出现 “as of my knowledge cutoff” 或 “I don’t have information about”——但这些事实其实在你提供的 context 里。

6. system prompt 里硬写今日日期

写 “Today is March 15, 2024.”从没更新。几个月后模型仍以为今天是 2024 年 3 月 15 日。

怎么判断:搜字面日期串。system prompt 里任何过去的日期都是嫌疑。

7. prompt 里写死定价或版本号

“Our service costs $20/month and runs on GPT-4.”半年后你涨到 $30、切到 GPT-5.5。prompt 里还是旧数字,面向用户的 assistant 还在报 $20。

怎么判断:prompt 里任何具体数字(价格、版本号、模型名)都是 staleness 候选。

最短修复路径

第 1 步:动态注入当前日期

from datetime import datetime
system_prompt = f"""
You are a helpful assistant.
Today's date is {datetime.now().strftime('%B %d, %Y')}.
Treat any context provided below as current information.
"""

永远不硬写年份。从 runtime 注入。

第 2 步:有 RAG 时移除 “knowledge cutoff” 免责

通过 RAG 提供 context 时,模型不应该退回到 “I don’t know recent events”:

You have access to retrieved documents below. Treat them as your
source of truth, even if more recent than your training cutoff.
Do NOT add disclaimers about your knowledge cutoff.

第 3 步:审 few-shot 例子的日期

每个 few-shot 例子里,把具体年份替换成 [YEAR] 或删掉日期:

BEFORE: "In 2023, Apple released the iPhone 15..."
AFTER:  "Apple released the iPhone 15 in [YEAR]..." (或者直接删日期)

日期重要的话,用相对时间或注入当前日期。

第 4 步:季度审 prompt 模板

# prompts/customer-support.yaml
last_reviewed: 2026-05-01
next_review: 2026-08-01
content: |
  ...

CI 在 next_review < today 时挂掉。强制 refresh。

第 5 步:版本控制 + diff prompt 改动

把 prompt 当代码。改 prompt 的 PR 必须高亮变更,reviewer 抓过时的日期 / 版本引用。

第 6 步:RAG 在时间敏感话题上按新鲜度过滤

if is_time_sensitive(query):
    chunks = retrieve(query, filter={"publish_date": {"gte": "2025-01-01"}})
else:
    chunks = retrieve(query)

时事 query 别让 2 年前的文档锚住模型。

第 7 步:用 date-shifted 输入测试

测 prompt 时问不同年份的事件。如果模型死活不能承认固定 cutoff 之后的事,说明 prompt 里藏了 cutoff。

哪些情况可能不是你操作错了

有些模型权重里硬写了 knowledge cutoff——它真的不知道某日期之后的事,新 system prompt 也救不了。那种情况的修复是 RAG 或 web 工具、不是改 prompt。

容易误判的情况

“模型旧了”——直接升级模型。有时模型是最新的、瓶颈是 prompt。升级前永远先看一眼渲染后的 prompt。

预防建议

  • system prompt 里 current_date 永远动态注入、不硬写。
  • 季度(至少)审 prompt 里的日期、版本、价格。
  • prompt 模板当 versioned code 看,PR 必须 diff-aware。
  • RAG 在时间敏感话题上按新鲜度过滤检索。
  • 有 retrieval 层时移除 “knowledge cutoff” 免责。
  • 例子里用 [YEAR] 或相对时间(“last year”)代替硬日期。

FAQ

  • 直接告诉模型 “you’re current as of today” 行吗? 有用——但 prompt 其他地方不能有旧引用打架。
  • 接了 RAG 之后模型训练 cutoff 还重要吗? 弱化了,但检索拿不到内容时仍影响一般推理。带 RAG 的现代模型不该用 knowledge-cutoff 当借口拒答。

相关阅读

标签: #Prompt 工程 #排查 #llm-output #stale-context #prompt-maintenance #evergreen