TL;DR
LLM страдает от "дрейфа в сторону свежего": когда информация в разговоре обновляется, модель постепенно "забывает" старые состояния и цепляется за последние. Спросишь что было до третьего обновления — модель расскажет про текущее. Это не случайный глюк, а системная особенность: все протестированные системы показали среднюю точность 27.9% на задачах с обновляющейся информацией.
Хуже всего модели справляются с двумя типами запросов: "что было ДО этого обновления" (точность ~21%) и "сколько раз менялось / в каком порядке / агрегируй изменения" (точность ~26.5%). Зато текущее состояние после апдейтов модели восстанавливают сносно (~47.5%). Причина — у модели нет временного якоря: когда контекст длинный и информация перезаписывается, модель конструирует "память" жадно сливая всё в одну кучу, а потом не может разобрать кто кого перезаписал.
Главный виновник — не ответ, а конструкция памяти: исследователи разложили ошибки на два этапа. Потери при построении памяти из контекста дают 41.7% падения точности, потери при ответе по готовой памяти — ещё 25.2%. То есть основная проблема не в том, что модель глупо отвечает, а в том, что она неправильно укладывает информацию при чтении длинного контекста. Плюс системы жёстко предпочитают дописывать новое (76.8% операций — вставка), а удалять и обновлять почти не умеют.
Схема проблемы и антидоты
СЦЕНАРИЙ: длинный разговор с обновляющейся инфой
Тип запроса Как работает LLM Твой риск
────────────────────────────────────────────────────────
Текущее состояние ✅ ~47% точность Низкий
"Что сейчас?"
Исторический lookback ❌ ~21% точность ВЫСОКИЙ
"Что было ДО правки 3?"
Агрегация изменений ❌ ~26.5% точность ВЫСОКИЙ
"Сколько раз / в каком
порядке / сравни v1 и v3"
Антидоты — в одном промпте или в структуре разговора:
АНТИДОТ 1: Явный временной якорь
→ "Используй только информацию ДО [момент]. Всё после — игнорируй."
АНТИДОТ 2: Заморозка истории
→ Явно зафиксируй снапшот: "ВЕРСИЯ 1: [текст]. ВЕРСИЯ 2: [текст]. ТЕКУЩАЯ: [текст]"
АНТИДОТ 3: Пошаговое агрегирование
→ Не "сколько раз менялось", а: "1) Найди все упоминания X 2) Запиши каждое с меткой момента 3) Посчитай"
Пример применения
Задача: Ты ведёшь переписку с командой о фичах продукта. За 20 сообщений требования несколько раз менялись. Хочешь спросить: "Что решили по онбордингу на третьем митинге, ДО того как Петя переиграл решение?"
❌ Опасный запрос:
Что мы решили по онбордингу?
Модель выдаст последнее решение, потеряв историю.
✅ С временным якорем:
Ниже — лог наших обсуждений. Найди решение по онбордингу,
которое было актуально ПОСЛЕ сообщения [3] и ДО сообщения [7].
Всё, что написано после [7] — игнорируй полностью.
Отвечай пошагово:
1. Процитируй момент, где это решение принималось
2. Назови его содержание
3. Подтверди что решения после [7] ты не использовал
[лог переписки]
Результат: Модель покажет конкретное историческое решение с цитатой и подтверждением что не "съехала" на более свежие данные. Без явного якоря она почти гарантированно вернёт последнюю версию.
Почему это работает
Слабость LLM при работе с обновляемой информацией — у модели нет настоящей "памяти со временными метками". Она читает текст линейно и конструирует внутреннее представление на ходу. Более поздний текст физически перезаписывает влияние более раннего при генерации ответа. Это как читать документ где новые правки вклеены поверх старых — если не следить специально, помнишь только то что видел последним.
Сильная сторона LLM — она хорошо следует явным инструкциям про то что читать и какую часть контекста использовать. Когда ты явно говоришь "смотри только на блок [3]-[7]", модель ограничивает область поиска. Когда ты просишь "процитируй момент решения" — она вынуждена найти конкретное место, а не реконструировать по общему впечатлению.
Как обойти — три рычага:
- Явные метки версий (
ВЕРСИЯ 1: ... ВЕРСИЯ 2: ...) устраняют неоднозначность — модель видит структуру вместо каши - Запрет на определённый диапазон ("игнорируй всё после [N]") создаёт искусственный временной барьер
- Пошаговая инструкция для агрегации ("найди все → запиши → посчитай") разбивает провальную задачу на мелкие, с которыми модель справляется
Шаблон промпта
Ниже — контекст с {описание_что_меняется: требования / решения / факты}.
Информация в нём обновлялась {число} раз.
Мне нужно:
{твой_вопрос}
Правила:
- Используй ТОЛЬКО информацию из {временной_диапазон: "блока [N] до блока [M]" / "до момента X"}
- Всё до/после этого диапазона — не используй
- Отвечай пошагово:
1. Найди все релевантные упоминания в нужном диапазоне
2. Процитируй каждое (кратко)
3. Дай финальный ответ
{контекст}
Плейсхолдеры:
- {описание_что_меняется} — что именно эволюционирует: требования, цены, договорённости, факты
- {временной_диапазон} — явно укажи границы: "сообщений 5-12", "до 15 января", "до правки #3"
- {твой_вопрос} — конкретный запрос с явным указанием временной точки
🚀 Быстрый старт — вставь в чат:
Вот шаблон для работы с обновляющейся информацией в длинном контексте.
Адаптируй под мою задачу: {опиши свою ситуацию}.
Задавай вопросы чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про структуру контекста и что именно менялось — потому что ей нужно понять тип обновлений (перезапись vs накопление) чтобы правильно выстроить временны́е барьеры.
Ограничения
⚠️ Агрегация через много обновлений: Даже с явными метками версий, задачи типа "сколько раз менялось / упорядочи все изменения / сравни версии 2 и 5" остаются сложными. Чем больше обновлений — тем хуже. Лучше разбивать на отдельные запросы по каждой версии.
⚠️ Сжатые/пересказанные контексты: Если ты попросил модель "кратко запомни" или "сделай summary" длинного разговора — историческая провенанс (что когда было актуально) скорее всего потеряна. Агрессивная компрессия убивает историю. Для важных исторических снапшотов — сохраняй оригиналы, не только summary.
⚠️ Работает для структурированных контекстов: Техника временных якорей лучше работает, когда у текста есть видимая структура (сообщения с номерами, версии, явные разделители). В сплошном тексте без меток сложнее указать точную границу.
⚠️ Не универсальное решение: Это workaround, не fix. Фундаментальная проблема (модели плохо строят память при чтении) остаётся. Лучший инструмент — не пытаться запихнуть всю историю в один контекст, а структурировать разговор заранее.
Как исследовали
Исследователи из UNC Chapel Hill задались вопросом: а реально ли все эти "продвинутые системы памяти" работают в условиях, приближённых к реальным? Взяли 4 типа сред где информация по-настоящему эволюционирует: простые базы фактов (bAbI), длинные диалоги с накапливающимися предпочтениями, историю правок Wikipedia-статей, и историю коммитов GitHub-репозиториев. Итого ~15.6k вопросов с контекстами от 0.3k до 1.8M токенов — серьёзный масштаб.
Сравнивали 7 систем: от "просто дать модели весь контекст" до специально обученных агентов с памятью (MemAgent, AtomMem, Mem-α, SimpleMem). Каждую систему гоняли на двух типах вопросов: найди конкретный факт (прошлый или текущий) и агрегируй несколько фактов через обновления.
Результат оказался неутешительным для всей отрасли: лучшая система набрала 33.4%, средняя — 27.9%. Самый неожиданный вывод — SimpleMem с Gemini Flash проиграл более простым методам. Причина: там заложена агрессивная компрессия контекста, которая отлично работает на коротких разговорах, но режет историческую провенанс в длинных. Разработчики систем оптимизировали под лёгкие бенчмарки, а столкнулись с реальной сложностью — и сломались. Для практика это значит: компрессия и summary — не бесплатны, они стоят историей.
Адаптации и экстраполяции
🔧 Техника: "Заморозка снапшота" перед важным решением
Если ты знаешь что сейчас зафиксируешь что-то важное и потом контекст будет дополняться — явно создай снапшот:
СНАПШОТ [дата/номер]: Текущее решение по [теме] — [текст решения].
Этот снапшот зафиксирован и не изменяется последующими сообщениями.
Потом при вопросе "что было решено тогда" — явно ссылайся на снапшот по метке.
🔧 Техника: Разделение "текущее vs историческое" в системном промпте
Если ведёшь длинный рабочий проект в одном чате, добавь в начало:
В этом разговоре информация будет обновляться.
При ответах на вопросы:
- Если спрашивают "сейчас" / "текущее" — используй последнее упоминание
- Если спрашивают "раньше" / "до [события]" / "в версии [N]" — используй только информацию ДО указанного момента
- При агрегации (сколько раз / в каком порядке) — перечисляй все вхождения явно перед финальным ответом
Ресурсы
Работа: LongMINT: Evaluating Memory under Multi-Target Interference in Long-Horizon Agent Systems (2025/2026, препринт)
Авторы: Hyunji Lee, Justin Chih-Yao Chen, Joykirat Singh, Zaid Khan (UNC Chapel Hill), Elias Stengel-Eskin (University of Texas at Austin), Mohit Bansal (UNC Chapel Hill)
Данные и код: github.com/amy-hyunji/LongMINT
Связанные системы из исследования: MemAgent, AtomMem, Mem-α, SimpleMem, HippoRAG