AI-порталAI-портал

Evidence Freshness Policies в 2026: когда старое доказательство уже нельзя считать достаточным

Evidence freshness policies в 2026: как задавать сроки годности для citations, retrieval items и tool confirmations, чтобы decision и answer quality не опирались на устаревший evidence.

Evidence freshness policies в 2026 нужны потому, что одно и то же доказательство имеет разную "срок годности" в зависимости от контекста. Политика возвратов месячной давности может быть нормальным reference. Остаток на счёте пятиминутной давности — уже подозрителен. Screenshot из браузера час назад может быть useless для текущего action. Если система не различает свежесть evidence, она начинает одинаково верить слишком разным по актуальности опорам.

Freshness policy — это правило, насколько свежим должен быть источник, citation или tool confirmation для конкретного типа ответа или действия. Это не просто timestamp, а operational threshold.
Самый вредный anti-pattern - считать любое evidence допустимым, если оно "вообще существует". Для production систем stale evidence часто опаснее полного отсутствия evidence, потому что создаёт ложную уверенность.

Короткая версия

Хорошая evidence freshness policy в 2026 обычно определяет:

  1. Какие evidence types есть в системе
  2. Какой max age допустим для каждого типа
  3. Что делать при stale evidence
  4. Когда нужен re-check или re-retrieval
  5. Как stale status влияет на answer/action policy

Что особенно важно

  • freshness threshold должен быть type-aware;
  • citation freshness и tool-confirmation freshness — это не одно и то же;
  • stale evidence должно менять routing, а не только UI label;
  • без freshness policy RAG и agents легко опираются на красивые, но устаревшие доказательства.
Без техники
Агент использует вчерашний billing snapshot как основание для сегодняшнего risky action.
С техникой
Policy помечает snapshot как stale для action support, требует новый tool check и не даёт системе коммитить действие на старом evidence.
ПромптFreshness intuition
Почему stale evidence иногда опаснее, чем его отсутствие?
Ответ модели

Потому что старое доказательство выглядит как основание для уверенного решения, хотя в реальности уже не отражает текущее состояние.

1. Свежесть зависит от типа evidence

Полезно различать:

  • policy document;
  • knowledge-base article;
  • tool confirmation;
  • browser screenshot;
  • external web result;
  • human note.

У каждого типа своя operational актуальность.

2. Freshness должен зависеть от decision context

Один и тот же источник может быть:

  • достаточно свежим для explanation;
  • недостаточно свежим для action;
  • достаточным для low-risk summary;
  • недостаточным для compliance-sensitive answer.
Не спрашивайте "источник свежий или нет" в вакууме. Спрашивайте "достаточно ли он свежий для этого решения".

3. Stale evidence должен менять system behavior

Например:

  • trigger re-retrieval;
  • force new tool lookup;
  • downgrade confidence;
  • disallow commit action;
  • require human review.

Если stale status только рисуется в UI, но не влияет на routing, policy почти не работает.

4. Freshness полезно связывать с provenance

Команде важно знать:

  • кто отвечает за обновление evidence source;
  • когда источник последний раз проверяли;
  • stale он из-за ingest lag или из-за owner neglect;
  • есть ли более свежий alternative path.

Так freshness policy помогает не только answer quality, но и content operations.

5. Что особенно часто ломают команды

One TTL for everything

Все evidence types живут по одному threshold.

Stale only as label

Никакого routing impact.

No forced re-check

Система видит stale evidence, но всё равно идёт дальше.

Timestamp without semantics

Есть updated_at, но непонятно, что он значит для decision quality.

No distinction between answer and action

Старое evidence одинаково используется для summary и for commit.

6. Какие метрики полезны

Минимальный dashboard обычно включает:

  • stale-evidence usage rate;
  • forced re-check rate;
  • actions blocked by freshness policy;
  • freshness violations by source type;
  • average evidence age by route;
  • incidents tied to stale support.

Плюсы

  • Freshness policy уменьшает решения на устаревшем evidence
  • Type-aware thresholds делают governance реалистичнее
  • Связка freshness и routing повышает reliability
  • Полезно для RAG, tools и human review одновременно

Минусы

  • Нужно отдельно поддерживать thresholds по source type и route
  • Слишком строгая freshness policy может повышать latency и cost
  • Без provenance трудно понять причину stale evidence
  • Команды часто недооценивают operational значение timestamps

Пример freshness policy

evidence_types:
  billing_snapshot:
    max_age_for_action_seconds: 120
  kb_article:
    max_age_for_answer_days: 30
  browser_screenshot:
    max_age_for_action_seconds: 30

Простой freshness check

def is_fresh(age_seconds, limit_seconds):
    return age_seconds <= limit_seconds

Практический совет: evidence freshness policy становится полезной в тот момент, когда stale evidence перестаёт быть "лучше, чем ничего" и начинает честно блокировать решения, для которых оно уже недостаточно актуально.

Проверьте себя

1. Почему freshness threshold нельзя делать одинаковым для всех evidence types?

2. Что особенно важно делать при stale evidence?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI API Docs - Evaluation best practices
  2. Ragas Docs - Evaluate and Improve a RAG App
  3. OpenTelemetry - GenAI semantic conventions
  4. LangChain Docs - Retrievers
Предыдущая
Evals 2.0: новое поколение оценки LLM-приложений
Следующая
Evidence Pack Design в 2026: как собирать decision-ready набор доказательств для человека и автоматики