TimelineAgent: сборка хронологии событий из многих документов через стадии, набор мини-навыков и маршрутизацию

ВХОД: пачка документов + запрос + тип запроса (Entity / Aspect / Seed-event)

СТАДИЯ 1. Фильтр предложений    → оставить предложения, связанные с запросом (с запасом, high recall)
СТАДИЯ 2. Поиск событий         → список кандидатов-событий (без «был», «есть» и прочих пустых глаголов)
СТАДИЯ 3. Релевантность запросу → события, подходящие под ТИП запроса
СТАДИЯ 4. Привязка к датам      → дата YYYY-MM-DD («X» там, где не знаем) 
СТАДИЯ 5. Фильтр допустимости   → убрать отрицания, слухи, условные «если», нужные диапазоны дат
СТАДИЯ 6. Склейка дублей        → одно реальное событие = одна запись со ссылками на все источники

ПРОТОКОЛ: (стадия, тип запроса) → какие навыки включить и с какими настройками

В оригинале каждая стадия — отдельный агент. Для чата это отдельные сообщения или один промпт с жёсткими стадиями.

Задача: аналитик в пресс-службе маркетплейса собирает хронологию по теме «как менялись условия для продавцов» из 8 новостных статей (РБК, Ведомости, Коммерсантъ, VC.ru). Нужны даты, без дублей и без «планов, которые так и не случились». Это Aspect-запрос: событие определяется по теме («условия для продавцов»), а не по конкретному человеку.

Промпт:

Ты — аналитик-хронолог. Построй хронологию событий по документам ниже.

Тип запроса: ASPECT (тема)
Запрос: «Изменения условий работы для продавцов маркетплейса: комиссии, штрафы, правила приёмки, ПВЗ»
Дата публикации каждого документа указана в его заголовке — используй её как точку отсчёта для слов «вчера», «на прошлой неделе», «с 1 числа».

Работай строго по стадиям, результат каждой стадии показывай:

СТАДИЯ 1. Отбери предложения, связанные с запросом. Лучше взять лишнее, чем пропустить.
СТАДИЯ 2. Выпиши события-кандидаты (действия и изменения, не «был/есть»).
СТАДИЯ 3. Оставь события, которые относятся к теме запроса. Для каждого — тип (комиссии / штрафы / приёмка / ПВЗ / другое). Если событие — причина темы (например, решение, после которого выросли штрафы), тоже оставь и пометь «причина».
СТАДИЯ 4. Для каждого события определи дату в формате ГГГГ-ММ-ДД. Неизвестные части — «X» (например 2024-09-XX). Покажи, из чего посчитал: время глагола, выражение времени, дата документа.
СТАДИЯ 5. Убери: события, которые не произошли (отрицание), слухи и предположения, условные («если примут…»). Запланированные события с твёрдой датой оставь, пометь «запланировано».
СТАДИЯ 6. Склей описания одного и того же события из разных документов: совпадает тип, участники и дата. Один пункт — все источники в скобках.

Итог: список «дата — событие — источники», отсортированный по дате.

ДОКУМЕНТЫ:
{тексты статей с заголовками и датами}

Результат: модель покажет шесть блоков по стадиям: сначала широкий отбор предложений, потом список кандидатов, затем сужение по теме с типами. На стадии 4 видно расчёт дат («опубликовано 12.03, "в прошлую пятницу"» → дата). На стадии 5 видно, что убрано и почему. В конце — чистая хронология с источниками. Промежуточные списки позволяют проверить, где модель потеряла или выдумала событие.

Слабость. В одном промпте у модели много разнородных задач сразу: поиск событий, оценка релевантности, арифметика дат, оценка достоверности, сравнение источников. Ошибка на ранней стадии (не то событие, не та дата) тихо портит всё дальше. Если дать модели ещё и длинный список всех возможных правил, она отвлекается и «загрязняет» контекст: авторы прямо называют это причиной не показывать агенту всю библиотеку навыков.

Сильная сторона. Модель хорошо делает одну узкую операцию с чёткой инструкцией: определить время глагола, выделить участников события, решить, реально ли оно произошло. Результаты шагов можно передавать дальше текстом.

Как метод это использует. Разделяет задачу на стадии и даёт на каждую короткий набор правил. Правила выбирает таблица «стадия + тип запроса». Например, для запроса про человека нужно искать, кто участвует в событии, и связывать упоминания («глава компании» = он). Для запроса про тему нужно классифицировать тип события и искать предшествующие причины. Для запроса «что было после события X» нужно проверять причинную связь и совпадение участников.

Рычаги управления промптом: - Тип запроса — главный переключатель. Меняйте блок критериев в стадии 3 под ваш случай. - Широта стадии 1 — «лучше лишнее, чем пропуск» повышает полноту, но удлиняет работу. Для длинных архивов добавьте жёсткий лимит. - Правила фактичности (стадия 5) — решите заранее, что считать фактом: в статье «будет» с твёрдой датой считали фактом, а условные конструкции исключали. Подберите под себя. - Дата документа — единственный якорь для относительных дат. Нет даты — модель начнёт угадывать. - Стадия 6 — добавьте критерии склейки (участники, место, сумма), если в данных много похожих, но разных событий.

В статье полные промпты вынесены в приложение, которого в тексте нет. Ниже реконструкция по описанию стадий и протокола. Структура сохранена: стадии, навыки, таблица маршрутизации.

Ты — аналитик-хронолог. Строишь хронологию событий из нескольких документов по запросу. Работаешь по стадиям, на каждой используешь только указанные для неё навыки.



Запрос: {запрос}
Тип запроса: {ENTITY | ASPECT | SEED_EVENT}
  ENTITY — события с участием {сущность}
  ASPECT — события определённого типа внутри темы: {список_аспектов}
  SEED_EVENT — события, вызванные или связанные с исходным событием: {исходное_событие}
Период: {начало} — {конец}  (или «без ограничений»)
Документы (у каждого указана дата публикации): {документы}



S_TENSE: определи время глагола и признак завершённости.
S_TIME_EXPR: найди выражения времени («в марте», «через неделю»).
S_DATE_CALC: посчитай дату относительно даты документа, запиши как ГГГГ-ММ-ДД, неизвестное — «X».
S_ARGS: выдели участников события (кто, кому, что, где).
S_COREF: свяжи упоминания одной сущности («компания», «она», «глава»).
S_TYPE: определи тип события из списка аспектов.
S_CAUSE: найди события-причины и события-следствия.
S_POLARITY: событие произошло или отрицается?
S_CERTAINTY: факт, слух, предположение?
S_CONDITION: условное ли событие («если…, то…»)?
S_SAME_EVENT: совпадают ли два описания по типу, участникам и времени?



Цель = (стадия, тип запроса) → какие навыки включить:

(1 Фильтр предложений, любой)      → только S_COREF для ENTITY; иначе поиск по ключевым словам. Широко, с запасом.
(2 Поиск событий, любой)           → выдели действия и изменения; пропусти «быть», «являться», «стать» без содержания.
(3 Релевантность, ENTITY)          → S_ARGS + S_COREF: участвует ли сущность запроса в событии?
(3 Релевантность, ASPECT)          → S_TYPE + S_CAUSE: нужный ли тип? Это причина такого события?
(3 Релевантность, SEED_EVENT)      → S_TYPE + S_CAUSE + S_ARGS: связано ли с исходным событием и по участникам?
(4 Привязка к датам, любой)        → S_TENSE + S_TIME_EXPR → затем S_DATE_CALC от даты документа.
(5 Допустимость, любой)            → S_POLARITY + S_CERTAINTY + S_CONDITION; проверь период.
(6 Склейка дублей, любой)          → S_TYPE + S_ARGS + даты → S_SAME_EVENT.



Выполняй стадии 1→6 строго по порядку. После каждой стадии выведи результат списком:
событие — документ — (при необходимости) пометка. На следующую стадию передавай только результат предыдущей. Не применяй навыки, не указанные в Protocol для текущей стадии.



Итог: список «ГГГГ-ММ-ДД — событие — [источники]», по возрастанию даты.
Отдельно: события с неполной датой и события, в которых ты не уверен.

Что подставлять: {запрос} и {тип} — цель хронологии; {список_аспектов} — 4–7 типов событий вашей темы (комиссии, штрафы, увольнения); {исходное_событие} — для типа SEED_EVENT; {документы} — тексты с датами в заголовках.

🚀 Быстрый старт — вставь в чат:

Вот шаблон TimelineAgent-lite для сборки хронологии из нескольких документов. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про тип запроса (человек/компания, тема, последствия события), про период, про набор типов событий и про то, что в твоей работе считать «фактом». Эти поля определяют, какие навыки включаются на каждой стадии, и без них маршрутизатор не работает.

⚠️ Качество невысокое даже у авторов: лучшие результаты — около 30–40% по F1 (сводная метрика точности и полноты). Хронология от агента — черновик, а не истина. Проверяйте даты и пропуски.

⚠️ Сложнее всего — запросы «что было после события X»: релевантных событий в документах мало, модель путается чаще всего. Темы и сущности даются легче.

⚠️ Оригинал — код: в статье стадии подкреплены внешними словарями и базами знаний (PropBank, FrameNet, ConceptNet, словарь Collins) и скриптами. В чате этого нет, нужна самостоятельная адаптация. В моём шаблоне эти ресурсы заменены текстовыми правилами, их эффект отдельно не проверялся.

⚠️ Не проверено на чат-моделях: тестировали DeepSeek-V3 и Qwen3-32B. Выводы о стадиях и навыках общие, но цифры для ChatGPT, Claude, Gemini не измерены.

⚠️ Длинные архивы: сотни документов не влезут в контекст, нужна автоматизация с пакетной обработкой. Для чата — не более десятка статей за раз.

⚠️ Неполный текст: в доступной версии обрезан раздел абляций, поэтому вклад каждой отдельной части (навыки, протокол, стадии) по цифрам не виден. Известно лишь, что удаление навыков и протокола сильно ухудшило результат.

Авторы взяли три типа запросов и под каждый нашли данные. Для Entity — готовый датасет SemEval-2015 с новостными таймлайнами про людей, компании и продукты. Для двух других готовых датасетов не было, и они доразмечали вручную существующие корпусы: Aspect — по кризисным темам (землетрясения, побеги, пожары), Seed-event — по политическим обещаниям и действиям властей. Размечали два лингвиста, согласие между ними высокое. Всего получилось 26–42 таймлайна на тип.

Сравнивали на двух моделях: DeepSeek-V3 и Qwen3-32B. Против TimelineAgent выставили классический пайплайн, обычный промпт с примерами (ICL), дообученную модель (SFT) и универсальную многоагентную схему TDAG. Метрика — официальная метрика SemEval: она строит граф из событий и дат и оценивает всё вместе: отбор событий, даты и склейку дублей.

Результат: TimelineAgent лучше всех. На DeepSeek-V3 F1 по Entity — 37,9 против 17,5 у обычного промпта, по Seed-event — 33,1 против 12,5, то есть в 2–3 раза. Универсальная агентная схема TDAG при этом заметно слабее специализированной. Любопытно, что Qwen3-32B со специализированной схемой обогнала более крупную DeepSeek-V3 с универсальной TDAG. Вывод для практики: хорошо продуманная организация шагов под задачу важнее, чем «взять модель побольше». Абляции показали, что без навыков и протокола качество сильно падает на всех типах запросов.

🔧 Техника: стадии в отдельных сообщениях → меньше накопленных ошибок

Вместо одного длинного промпта запускайте стадии по одной в чате: «Сделай только стадию 1 и покажи результат». Проверьте, поправьте, потом: «Теперь стадия 2 на основе этого списка». Вы ловите ошибки до того, как они «протекут» дальше. Это ближе к оригиналу, где каждая стадия — отдельный агент.

🔧 Техника: навыки → отдельные файлы для агента

В Claude Code, Cursor или кастомном агенте положите каждый навык в отдельный файл-скилл, а в CLAUDE.md напишите таблицу маршрутизации:

Copy

Хронология событий. Выполняй стадии 1–6 по порядку.
На стадии 4 подключай только скиллы: tense, time-expr, date-calc.
На стадии 5 — только polarity, certainty, condition.
Не загружай остальные скиллы: лишнее ухудшает точность.

Экстраполяция: статья не тестировала файлы инструкций, но принцип «выдавай навык по цели, а не весь набор» прямо следует из дизайна протокола.

• Работа: TimelineAgent: An LLM-based Framework for Query-Centric Event Timeline Extraction Across Multiple Documents
• Авторы: Qingkai Min, Yunxin Bao, Yifeng Lu, Zhenyu Feng, Yulong Chen, Andreas Vlachos, Yue Zhang
• Организации: Zhejiang University; Westlake University; Saarland University; University of Cambridge; University of Aberdeen
• Код и данные: https://github.com/taolusi/QUEST
• Использованные наборы данных: SemEval-2015 Task 4, EventStoryLine, ECB+, PledgeTracker
• Сравнение: TDAG (универсальная многоагентная схема)