Event Schemas: структурированные ограничения для извлечения фактов из текста

ШАГ 1: Определи схему события для домена
→ Список типов событий + роли для каждого типа

ШАГ 2: Найди триггеры (ключевые слова событий)
→ Слово/фраза + тип события

ШАГ 3: Извлеки аргументы для каждого триггера
→ Заполни роли: кто (агент), что (объект), где (место), когда (время)

ШАГ 4: Свяжи события (опционально)
→ Временные связи (до/после), причинные (вызвало), кореференция (одно событие)

Все шаги можно выполнить в одном промпте (как таблицу/JSON) или отдельными запросами (если текст большой).

⚠️ Зона применения: Тексты с плотной фактурой — новостные сводки, протоколы встреч, медицинские записи, деловая переписка. НЕ работает для субъективных описаний без чётких фактов.

Задача: Извлечь цепочку событий из новостной заметки для мониторинга репутации компании в медиа.

Текст: "Вчера Сбербанк объявил о запуске нового сервиса SberPay для малого бизнеса. Анонс состоялся на конференции в Москве. Греф подчеркнул, что сервис упростит приём платежей для 2 миллионов предпринимателей. Релиз запланирован на декабрь 2024."

Промпт:

Извлеки события из текста по схеме:

**События:**
Для каждого события заполни:
- Тип: [Product.Launch / Business.Announce / Executive.Statement]
- Триггер: [ключевое слово]
- Агент: [кто]
- Объект: [что]
- Место: [где]
- Время: [когда]

**Связи:**
Какое событие вызвало другое? Какие события об одном факте?

Выдай в таблице.

ТЕКСТ:
[текст новости]

Результат:

Модель выдаст таблицу с 2-3 событиями: анонс продукта (триггер "объявил", агент "Сбербанк", объект "SberPay"), публичное выступление (триггер "на конференции", место "Москва"), заявление руководителя (триггер "подчеркнул", агент "Греф"). Покажет связь: все три события описывают один факт (кореференция). Укажет время релиза отдельно как атрибут главного события.

Слабость LLM: Модель генерирует текст последовательно, слово за словом, полагаясь на вероятности. Когда задача — извлечь факты, модель может "додумать" связь между событиями или пропустить важную деталь, потому что нет механизма верификации — не с чем сверить. В длинных текстах внимание размывается, и ранние факты забываются к концу генерации.

Сильная сторона LLM: Модель отлично заполняет структуры — если дать явный шаблон с полями, она методично пройдётся по каждому элементу. Это как разница между "напиши эссе" (можно уйти в сторону) и "ответь на 5 конкретных вопросов" (каждый вопрос — якорь внимания).

Механика метода: Event schema превращает извлечение фактов из генерации в классификацию + заполнение слотов. Сначала модель находит триггеры (слова-кандидаты событий) — это проще чем сразу пересказывать. Потом для каждого триггера заполняет роли — это уже не "придумай", а "найди в тексте подходящее". Схема задаёт явные ограничения: поле "агент" должно быть персоной/организацией, поле "время" — датой. Модель не может "додумать" — только выбрать из текста или сказать "не указано".

Рычаги управления:

• Детализация схемы: Больше полей (причина, последствия, модальность) → точнее факты, но дольше. Минимум (триггер + агент + объект) → быстрее, но меньше контекста.
• Формат вывода: JSON строже (машиночитаемо), таблица нагляднее, список проще. Под задачу: если дальше обработка кодом — JSON, если читать глазами — таблица.
• Связи событий: Временные отношения (ДО/ПОСЛЕ) полезны для timeline, причинные (ВЫЗВАЛО) — для анализа, кореференция (ОДНО И ТО ЖЕ) — чтобы не дублировать. Можно убрать связи если нужны только факты, не цепочка.
• Открытая vs закрытая схема: Закрытая (список типов событий заранее) быстрее и точнее, если домен узкий. Открытая ("определи тип сам") гибче, но модель может путаться в названиях типов.

Извлеки события из текста по схеме:

СХЕМА СОБЫТИЯ:
- Тип: [{список типов для твоего домена, например: Product.Launch, Executive.Change, Partnership.Announce}]
- Триггер: [ключевое слово события]
- Роли:
  • Агент: [кто действует]
  • Объект: [на что направлено действие]
  • Место: [где произошло]
  • Время: [когда]
  • {дополнительные роли под твою задачу}

СВЯЗИ (опционально):
- Временные: [событие A до/после события B]
- Причинные: [событие A вызвало событие B]
- Кореференция: [события об одном факте]

ФОРМАТ ВЫВОДА: {таблица / JSON / список}

ТЕКСТ:
{твой_текст}

Плейсхолдеры: - {список типов} — определи заранее: какие события важны в твоём домене? Для бизнес-аналитики: запуски, партнёрства, смены руководства. Для медицины: диагноз, лечение, выписка. Можно писать "определи тип сам" если схема открытая. - {дополнительные роли} — под задачу: "Бюджет", "Причина", "Результат", "Источник информации". - {формат вывода} — JSON для кода, таблица для глаз, список для простоты. - {твой_текст} — вставь текст для разбора.

Если нужна открытая схема (типы событий заранее неизвестны):

Замени строку "Тип: [список]" на:

- Тип: [определи сам, назови глаголом: что произошло?]

Модель будет выводить типы как "Announce", "Launch", "Resign" — свои слова. Потом можешь нормализовать вручную.

⚠️ Длинные тексты: В статьях на 10+ абзацев модель начинает терять фокус — пропускает события из середины текста. Разделяй текст на части (по 2-3 абзаца) → извлекай события из каждой → потом соедини и убери дубли.

⚠️ Неявные события: Если событие не выражено глаголом/существительным (триггером), а подразумевается по контексту ("Через год компания обанкротилась" — пропущено что именно привело к банкротству), схема не поможет — модель не может извлечь то, чего нет в тексте явно.

⚠️ Субъективные тексты: Схемы работают для фактов (кто, что, когда). Для мнений, эмоций, аргументации (эссе, рецензии, блоги) event extraction избыточен — там нет чётких событий с участниками.

⚠️ Вложенные события: "Анонс запуска продукта" — это два события (анонс + запуск) или одно? Модель путается. Нужно заранее решить: либо дробить на атомарные события (один триггер = одно событие), либо разрешить композитные типы и описать в схеме.

Это обзорная статья (survey), которая систематизирует 30+ лет исследований по извлечению событий из текста. Авторы из университетов Сингапура, США, Китая и Великобритании проследили эволюцию методов: от ранних правил и регулярных выражений (1990-е) через классическое машинное обучение и глубокие нейросети до современных LLM.

Ключевой тезис работы: с приходом LLM область Event Extraction не умирает, а меняет роль — из "задачи" превращается в "cognitive scaffold" (когнитивный каркас) для LLM-систем. То есть структурированные схемы событий помогают решить три боли LLM:

1. Надёжность: Free-form генерация → галлюцинации. Event schemas задают явные ограничения (поля, типы ролей) → модель работает как заполнение формы, не сочинение.

2. Рассуждения: Цепочки событий (что → вызвало что → привело к чему) работают как Chain-of-Thought для фактов — дробят нарратив на дискретные шаги, каждый проверяем отдельно.

3. Долгая память: События и связи между ними (временные, причинные) можно хранить как граф, не как сплошной текст. Это даёт relation-aware RAG: ищешь не по похожести эмбеддингов, а по связям (что произошло ДО, что ВЫЗВАЛО). Для агентов это эпизодическая память без переполнения контекста.

Авторы разобрали декомпозицию задачи на подзадачи: trigger detection (найти ключевое слово события) → argument extraction (извлечь участников и роли) → coreference (понять что два упоминания об одном событии) → event relations (связать события в цепочку). Показали как каждая подзадача решалась в разные эпохи (правила → SVM → BERT → GPT), какие датасеты использовались (ACE, ERE, MAVEN), как оценивается качество (F1 на совпадение спанов или строгое совпадение триггер+роли).

Практический инсайт: даже в эпоху "напиши мне всё одним промптом", структурированные промежуточные представления (события как записи с полями) дают контроль, верификацию и память. Без этого LLM — мощный, но хрупкий генератор текста. Со структурой — надёжная система с проверяемой логикой.

🔧 Техника: Два прохода → проверка полноты

Первый проход: извлеки события по схеме.

Второй проход: вот список событий — что пропущено? есть ли в тексте события, не попавшие в схему?

Эффект: модель на втором проходе ловит пропущенные факты, особенно те, что описаны косвенно.

🔧 Техника: Агент-критик для проверки ролей

После извлечения событий добавь шаг:

"Проверь каждую роль: точно ли агент — тот, кто действует? Не перепутаны ли агент и объект? Проверь по тексту."

Эффект: модель переключается в режим верификации (как Chain-of-Verification), меньше путаницы в ролях.

🔧 Техника: Открытая схема + нормализация

Если типы событий заранее неизвестны (новый домен), проси модель:

1) Извлеки события, назови типы своими словами

2) Вот список извлечённых типов — сгруппируй похожие, дай канонические названия

Эффект: ты получаешь схему снизу вверх, из данных, без заранее заданной онтологии.

Комбинация: Event Extraction + Graph RAG

Event extraction для длинных документов можно комбинировать с graph-based retrieval. Вместо "раздели документ на чанки → эмбеддинги → поиск по косинусу" делаешь:

1. Извлекаешь события из каждой части документа
2. Строишь граф: события — узлы, отношения (вызвало, до/после, участник общий) — рёбра
3. При запросе ищешь релевантные события (не чанки), идёшь по рёбрам графа (находишь связанные события)

Пример применения: база знаний компании. Документы описывают проекты, решения, встречи. Вместо "найди похожий кусок текста" делаешь "найди все решения, которые вызвали изменение в проекте X" — граф событий даёт точные причинно-следственные связи.

Event Extraction in Large Language Model: A Holistic Survey of Method, Modality, and Future

Bobo Li, Xudong Han, Jiang Liu, Yuzhe Ding, Liqiang Jing, Zhaoqi Zhang, Jinheng Li, Xinya Du, Fei Li, Meishan Zhang, Min Zhang, Aixin Sun, Philip S. Yu, Hao Fei

National University of Singapore, University of Sussex, Wuhan University, University of Texas at Dallas, Nanyang Technological University, Harbin Institute of Technology (Shenzhen), University of Illinois at Chicago

GitHub: https://github.com/unikcc/AwesomeEventExtraction