AI summarization pipeline в n8n: как делать краткие summary без потери смысла и фактов ¶

Обновлено: 2026-05-29

Короткий ответ ¶

AI summarization pipeline нужен, когда нужно сжать длинный текст до полезного формата: summary тикета, протокол встречи, executive brief, digest писем, recap звонка, карточка клиента или краткий отчёт по инциденту. Надёжный pipeline не просто “делает кратко”, а заранее определяет тип summary, аудиторию, запрещённые потери, source anchors, формат output, проверку фактов и правила human review. Хорошее summary должно быть короче исходника, но не беднее по важным решениям, датам, суммам, рискам и next steps.

Почему summarization сложнее, чем кажется ¶

Суммаризация кажется простой: отправить текст в LLM и попросить “кратко пересказать”. В production это быстро ломается. Модель может опустить важный caveat, перепутать говорящих, обобщить спорное утверждение как факт, скрыть uncertainty или добавить вывод, которого не было в источнике. Для заметок это терпимо. Для поддержки, продаж, юридических документов и инцидентов — нет.

Summary — это не один универсальный формат. Для CEO нужен risk/impact/decision. Для инженера — symptoms/logs/actions. Для менеджера продаж — потребность, бюджет, возражения и next step. Для поддержки — проблема, что уже пробовали, текущий статус и что ответить клиенту. Поэтому pipeline должен начинаться с выбора summary type.

Типы summary ¶

Не смешивайте эти форматы. Если один workflow обслуживает разные каналы, добавьте classifier или явный параметр summary_type.

Архитектура workflow ¶

Production workflow:

1. Trigger: новый тикет, завершённая встреча, email thread, uploaded document, incident log.
2. Source loader: получить текст, transcript, thread или документ.
3. Cleaning: убрать мусор, подписи, дубли, service messages.
4. Segmentation: разделить по сообщениям, говорящим, времени или секциям.
5. Summary type selector: определить аудиторию и формат.
6. Fact extraction: отдельно извлечь даты, суммы, имена, decisions, blockers.
7. Chunk summaries: если текст длинный, сделать summary по chunks.
8. Merge summary: объединить chunks без потери facts.
9. Validation: проверить обязательные поля, forbidden inference и source coverage.
10. Human review: для high-risk summary.
11. Publish/write: CRM, Slack, Notion, Google Docs, email.
12. Log/evaluate: source_id, model, prompt version, summary length, review status.

Факт extraction лучше делать отдельно от creative summary. Так проще проверить, что ключевые даты и суммы не потерялись.

Формат output ¶

Пример schema для support summary:

{
  "type": "object",
  "required": ["issue", "customer_impact", "attempted_steps", "current_status", "next_action"],
  "properties": {
    "issue": { "type": "string" },
    "customer_impact": { "type": "string" },
    "attempted_steps": { "type": "array", "items": { "type": "string" } },
    "current_status": { "type": "string" },
    "next_action": {
      "type": "object",
      "required": ["owner", "action", "deadline"],
      "properties": {
        "owner": { "type": ["string", "null"] },
        "action": { "type": "string" },
        "deadline": { "type": ["string", "null"] }
      }
    },
    "open_questions": { "type": "array", "items": { "type": "string" } },
    "source_refs": { "type": "array", "items": { "type": "string" } }
  }
}

Схема заставляет summary быть пригодным для workflow. Downstream node может создать задачу, заполнить CRM или отправить handover без ручного копирования.

Source anchors и проверяемость ¶

Для важных summary нужно хранить source anchors: message id, timestamp, paragraph id, page number или chunk id. Без anchors невозможно проверить спорное утверждение.

Пример:

{
  "claim": "Клиент сообщил, что оплата прошла, но чек не пришёл",
  "source_anchor": "email_thread_182#message_4",
  "confidence": 0.92
}

Если summary публикуется руководству, не обязательно показывать anchors в тексте. Но они должны быть в логе.

Chunking для длинных документов ¶

Длинный документ нельзя просто обрезать до context window. Нужно разделить текст на смысловые блоки. Для встреч — по темам и говорящим. Для тикетов — по chronology. Для инцидентов — по времени. Для документов — по заголовкам.

Схема map-reduce:

1. Разбить текст на chunks.
2. Для каждого chunk получить local summary + facts + open questions.
3. Объединить local summaries.
4. Сверить global facts с исходными extracted facts.
5. Проверить, что high-priority facts не потеряны.

Плохой merge-summary может стереть детали. Поэтому перед merge задайте “must preserve facts”.

Prompt для точной summarization ¶

Сделай support summary. Не добавляй факты, которых нет в источнике. Если данных нет, пиши null или "не указано". Не скрывай неопределённость. Сохрани даты, суммы, имена систем, error codes и next steps. Не пересказывай эмоциональные фразы, если они не влияют на решение.

Верни JSON по schema:
- issue
- customer_impact
- attempted_steps
- current_status
- next_action
- open_questions
- source_refs

Запрет inference должен быть явным. Иначе модель может “додумать” причину проблемы.

Validation summary ¶

Проверяйте:

• есть ли обязательные поля;
• не превышена ли максимальная длина;
• есть ли source_refs для ключевых claims;
• не появились ли даты/суммы, которых нет в source facts;
• не потерян ли decision/next action;
• нет ли forbidden phrases;
• не скрыта ли uncertainty.

Пример проверки дат:

const sourceDates = new Set($json.source_facts?.dates || []);
const summary = JSON.stringify($json.summary || {});
const foundDates = summary.match(/\b\d{4}-\d{2}-\d{2}\b/g) || [];
const unsupported = foundDates.filter(d => !sourceDates.has(d));

return [{ json: { ...$json, unsupported_dates: unsupported, valid: unsupported.length === 0 } }];

Такой простой тест ловит часть hallucination.

Ошибки summarization ¶

Human review ¶

Review обязателен, если summary будет использоваться для:

• юридического документа;
• финансового решения;
• публичного ответа;
• отчёта руководству по инциденту;
• медицинских/финансовых данных;
• увольнения, штрафов, блокировок;
• автоматического изменения CRM стадии.

Оператор должен видеть исходник, summary, подсвеченные risky claims и список open questions. Review должен быть быстрым: approve, edit, reject.

Evals и метрики ¶

Метрики:

• factual consistency;
• coverage of required facts;
• compression ratio;
• hallucinated claim rate;
• missing next action rate;
• human edit distance;
• time saved;
• user/operator rating.

Eval case:

{
  "case_id": "support_long_thread_receipt_missing",
  "expected_must_include": ["чек не пришел", "payment succeeded", "проверить webhook receipt"],
  "expected_must_not_include": ["возврат выполнен"],
  "summary_type": "support"
}

После изменения prompt прогоняйте старые кейсы. Summary может стать короче, но хуже по фактам.

Production checklist ¶

• [ ] Определены summary types.
• [ ] Есть schema под каждый тип.
• [ ] Long docs обрабатываются через chunking.
• [ ] Facts extraction отделён от final summary.
• [ ] Ключевые claims имеют source anchors.
• [ ] Есть validation против unsupported facts.
• [ ] Есть human review для high-risk summary.
• [ ] Есть eval dataset.
• [ ] Логируются source_id, prompt_version, model.
• [ ] Есть policy: что делать с PII.