Модульная трансформация с внедрением знаний: перевод неструктурированных документов в машиночитаемый формат

PREPARATION:
- Разбить целевой формат на модули (metadata, structure, details, variables)
- Для каждого модуля подготовить фрагмент официальной спецификации

ШАГ 1: Извлечь метаданные
→ Промпт: исходный документ + спецификация раздела "metadata"
→ Вывод: JSON с полями name, description, types

ШАГ 2: Построить скелет структуры
→ Промпт: исходный документ + список всех элементов из Шага 1 + спецификация "structure"
→ Вывод: JSON с идентификаторами, типами элементов, связями

ШАГ 3: Детализировать каждый элемент
→ Промпт: для каждого элемента из Шага 2 + его контекст + спецификация конкретного типа
→ Вывод: JSON с атрибутами элемента (параметры, условия, команды)

ШАГ 4: Извлечь переменные
→ Промпт: полный документ + спецификация раздела "variables"
→ Вывод: JSON со списком переменных, типами, описаниями

ВАЛИДАЦИЯ (после каждого шага):
- JSON-schema checker проверяет вывод
- Если ошибки → формируется список нарушений
- Модель получает: исходный документ + её предыдущий вывод + ошибки + промпт "исправь"
- Повторить до устранения ошибок (максимум 5 итераций)

СБОРКА:
- Объединить все валидные JSON-фрагменты в итоговый документ

Критично: Каждый шаг выполняется отдельным запросом, не в одном промпте. История передаётся минимально — только то, что нужно для текущей подзадачи.

Задача: У вас 50 внутренних регламентов компании в Word/PDF (порядок согласования отпусков, процедура закупок, инструкции для бухгалтерии). Нужно перевести их в структурированный JSON для системы автоматизации, чтобы бот мог автоматически направлять запросы, проверять условия и выполнять шаги без участия человека.

Промпт (адаптация под задачу):

Ты — эксперт по структурированию бизнес-процессов.

Задача: Преобразовать регламент из Word в JSON по схеме workflow_schema.json

КОНТЕКСТ:
[прикрепить Word-файл с регламентом]

ЦЕЛЕВАЯ СХЕМА (извлечение метаданных):
{
 "name": "строка, название регламента",
 "description": "строка, краткое описание",
 "process_type": "строка, тип процесса: approval|procurement|reporting",
 "owner": "строка, ответственный отдел"
}

ИНСТРУКЦИЯ:
1. Прочитай регламент
2. Извлеки метаданные строго по схеме
3. НЕ выдумывай поля, которых нет в схеме
4. Если в документе нет явного значения — используй null

Выведи ТОЛЬКО валидный JSON, без пояснений.

Результат: Модель выдаст JSON с метаданными. Если JSON не проходит валидацию — система покажет список ошибок (например, "поле process_type должно быть одним из: approval|procurement|reporting, а не 'согласование'"). В следующей итерации модель получит: исходный регламент + свой предыдущий JSON + ошибки → исправит. После 2-3 итераций метаданные будут валидны. Затем повторить для других секций: структура шагов, атрибуты каждого шага, переменные процесса.

Важно: Это не одноразовый промпт, а пайплайн из 4-5 запросов. Каждый запрос фокусируется на одной подзадаче и получает только нужный контекст + точный кусок схемы.

Слабость LLM: Модели плохо держат большой контекст и строгие ограничения одновременно. Попытка "переведи сразу весь документ в JSON по 50-страничной спецификации" приводит к:

• Превышению лимита токенов — модель теряет начало или обрезает конец
• Галлюцинациям — выдумывает поля, которых нет в спецификации
• Нарушению вложенности — путается в иерархии, создаёт циклические ссылки
• Лавинообразным ошибкам — одна неточность в структуре ломает всё дерево

Сильная сторона LLM: Модели отлично справляются с узкими, хорошо очерченными задачами, когда:

• Задача помещается в 1-2 экрана промпта
• Есть чёткий шаблон или примеры вывода
• Контекст минимален — только релевантная информация
• Проверка результата тривиальна (JSON-schema валидатор)

Как метод использует сильную сторону:

1. Task Decomposition разбивает сложность на независимые подзадачи. Вместо "переведи 50 страниц" → 4 запроса по 10-15 страниц каждый. Модель не перегружена контекстом и концентрируется на одном аспекте.
2. Direct Knowledge Injection вставляет точный фрагмент спецификации прямо в промпт. Не вся 200-страничная документация, а 5-10 строк JSON-schema для конкретного поля. Это ограничивает пространство возможных ответов и снижает галлюцинации на 80% (по сравнению с RAG, который тащит релевантные, но не обязательно точные куски).
3. Schema Validation + Feedback Loop превращает процесс в итеративное уточнение. После каждого шага валидатор ловит ошибки (несоответствие типов, лишние поля, нарушение структуры) и возвращает конкретный список нарушений обратно в промпт. Модель видит не абстрактное "что-то не так", а точно: "поле 'type' ожидает enum [A, B, C], а получено 'X'". За 3-5 итераций ошибки падают до нуля.

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

• Количество подзадач → больше декомпозиция = точнее, но дороже. Оптимум: 3-5 этапов.
• Размер фрагмента спецификации → больше контекст = меньше галлюцинаций, но выше токены. Оптимум: 50-200 токенов на шаг.
• Число итераций refinement → больше = выше точность, но дороже. Оптимум: 3-5 попыток, дальше diminishing returns.
• Prompt patterns → Template (обязательно, -90% ошибок формата), Persona (+5% accuracy), Zero-shot CoT (+10% для сложной логики, но +8% токенов), Few-Shot (+10% accuracy, но +15% токенов).

Ты — эксперт по {твоя_предметная_область}.

Задача: Преобразовать {исходный_формат} в структурированный JSON по схеме {название_схемы}.

ШАГ {номер}: {что_извлекаем}

КОНТЕКСТ:
[прикрепить исходный документ или его релевантную часть]

ЦЕЛЕВАЯ СХЕМА ({название_секции}):
[точный фрагмент JSON-schema для этой секции — 5-15 строк]

ИНСТРУКЦИЯ:
1. Прочитай документ
2. Извлеки данные строго по схеме
3. НЕ выдумывай поля, которых нет в схеме
4. Если в документе нет явного значения — используй null
5. Давай подумаем шаг за шагом перед ответом

Выведи ТОЛЬКО валидный JSON без пояснений, без markdown-блоков.

Пояснения к плейсхолдерам:

• {твоя_предметная_область} — область знаний: "бизнес-процессы", "юридические документы", "технические регламенты"
• {исходный_формат} — тип документа: "регламент из Word", "договор из PDF", "описание процесса из wiki"
• {название_схемы} — имя вашей целевой схемы: workflow_schema.json, contract_schema.json
• {номер} — номер шага в pipeline: 1 (метаданные), 2 (структура), 3 (детали), 4 (переменные)
• {что_извлекаем} — цель шага: "извлечь метаданные", "построить граф шагов", "детализировать атрибуты"
• {название_секции} — раздел схемы: "metadata", "workflow", "step_attributes", "variables"

После каждого шага:

1. Запусти JSON-schema валидатор на выводе модели
2. Если ошибки → добавь в промпт:

ОШИБКИ ВАЛИДАЦИИ:
[список конкретных нарушений]

Исправь свой предыдущий вывод, учитывая эти ошибки.

3. Повтори до устранения ошибок (максимум 5 итераций)

Итоговая сборка: После прохождения всех шагов объедини валидные JSON-фрагменты в один документ.

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

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

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

Модель спросит:

• Какой у тебя исходный формат и целевая схема?
• На сколько этапов разбить трансформацию?
• Какие поля обязательны, какие опциональны?

Она возьмёт паттерн Task Decomposition + Direct Knowledge Injection и создаст промпты для каждого шага под твою схему.

⚠️ Требует JSON-schema: Метод работает только если у вас есть формальная спецификация целевого формата. Без чёткой схемы внедрять нечего — Direct Knowledge Injection ломается.

⚠️ Много запросов = дорого: 4-5 шагов × 3-5 итераций = 12-25 API-вызовов на один документ. На GPT-4o это $0.50-2 за документ (зависит от размера). Для массовой обработки сотен файлов затраты быстро растут.

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

⚠️ Не работает для свободного текста: Если исходник — это эссе, статья, неструктурированный нарратив — метод бессилен. Нужна хотя бы минимальная структура: разделы, подзаголовки, списки. Полностью "плоский" текст невозможно разложить на модули.

⚠️ Сложность настройки: Нужно вручную определить:

• На сколько этапов декомпозировать задачу
• Какие фрагменты спецификации внедрять на каждом шаге
• Когда останавливать итерации refinement

Это требует понимания целевого формата. Нельзя применить "из коробки" без подготовки.

Команда из Fraunhofer FIT и RWTH Aachen University взяла 40 structured playbooks по кибербезопасности от трёх вендоров (Phantom, Fortinet, Demisto) в разных форматах — JSON, YAML, псевдокод. Эти плейбуки описывают автоматизированные сценарии реагирования на инциденты: условия, циклы, параллельные ветки, вложенные шаги. Задача — перевести в стандарт CACAO 2.0, который представляет собой сложную JSON-схему с 8 типами шагов, метаданными, переменными, агентами.

Для 10 плейбуков исследователи вручную создали эталонные CACAO-переводы — ground truth для семантической оценки. Это позволило измерять не только синтаксическую корректность (проходит ли JSON валидацию по схеме), но и семантическую точность (сохранена ли логика workflow). Для семантики использовали:

• Damerau-Levenshtein distance — для текстовых полей (названия, описания)
• Graph Edit Distance (GED) — для workflow-графов (шаги как узлы, переходы как рёбра)

Протестировали три модели: GPT-4o (128K контекст, $4.38 за 1M токенов), GPT-4o-mini ($0.26), Llama3.1-8B (бесплатно, запускали локально на A100). Сравнили пять техник промптинга: Persona, Template, Reasoning (Zero-shot CoT + Reflection), Direct Knowledge Injection, One-Shot. Измерили их комбинации и индивидуальные эффекты.

Почему результаты получились именно такими:

1. Direct Knowledge Injection победил всё остальное — снижение синтаксических ошибок на 83% для OpenAI моделей. Логика: когда в промпте есть точный кусок официальной спецификации, модель ограничена в вариантах и не может галлюцинировать несуществующие поля. Это работает лучше, чем RAG, который тащит релевантные, но не обязательно точные фрагменты документации, создавая шум.
2. Task Decomposition × 3 снижение ошибок — разбиение на 4 этапа уменьшило синтаксические ошибки втрое по сравнению с "переведи всё сразу". Почему? Модель не превышает лимит контекста, не путается в деталях, каждый шаг независим. Плюс после каждого этапа идёт валидация — ошибки изолированы и не распространяются дальше.
3. GPT-4o >>> GPT-4o-mini >> Llama3.1 — normalized GED 0.15 vs 0.22 vs 0.35. Больший размер модели = лучше понимание вложенных структур. GPT-4o корректно воспроизводит циклы, условные ветвления, параллельные процессы. Mini иногда упрощает логику. Llama путается в сложных dependency-графах.
4. Итеративный refinement почти убрал синтаксические ошибки — за 5 итераций падение с 8-10 до 0-1 ошибки на плейбук. НО семантика просела на 10-20% для метаданных. Почему? Модель любой ценой пытается устранить нарушение схемы. Если валидатор требует поле заполнить, она выдумывает значение вместо корректного null. Это фундаментальный trade-off: синтаксис vs смысл.
5. One-Shot не дал бонуса — добавление одного примера перевода увеличило токены на 15%, но точность выросла лишь на 2-3%. Похоже, для structured output Template + Direct Knowledge Injection уже дают достаточно ограничений, и показывать образец становится избыточным.
6. Reasoning (CoT + Reflection) помог только GPT-4o-mini (+10% для workflow GED) — большие модели уже думают "пошагово" внутри, явное "Let's think step-by-step" не добавляет ценности. Но для меньших моделей это толкает к более глубокому анализу структуры.

Неожиданность: Extracting variables оказалось хуже в baseline, чем с промптингом. Почему? Когда добавляются техники вроде Knowledge Injection, модель начинает путать workflow-переменные (локальные в шаге) и playbook-переменные (глобальные). Чем больше инструкций — тем сложнее провести границу между типами переменных. Это показало, что больше промптинга ≠ всегда лучше — иногда создаёт когнитивную перегрузку для модели.

Контекст: У вас 50 PDF-статей о клинических испытаниях. Нужно извлечь: название препарата, дозировку, результаты, побочные эффекты — в единую таблицу для мета-анализа.

Промпт:

Ты — эксперт по медицинским исследованиям.

Задача: Извлечь данные клинического испытания из PDF в JSON по схеме clinical_trial_schema.json

ШАГ 1: Извлечь метаданные исследования

КОНТЕКСТ:
[прикрепить PDF статьи]

ЦЕЛЕВАЯ СХЕМА (metadata):
{
 "title": "строка, название исследования",
 "year": "число, год публикации",
 "authors": ["массив строк, фамилии авторов"],
 "journal": "строка, название журнала",
 "doi": "строка, DOI или null"
}

ИНСТРУКЦИЯ:
1. Прочитай abstract и первую страницу
2. Извлеки метаданные строго по схеме
3. Если поле отсутствует — используй null
4. Давай подумаем шаг за шагом

Выведи ТОЛЬКО валидный JSON без пояснений.

Повтори для шагов 2-4: drug info, dosage, outcomes, adverse events. После каждого — валидация + refinement.

Когда: У вас нет формальной JSON-schema, но есть 2-3 примера нужного формата.

Что меняем:

Вместо:

ЦЕЛЕВАЯ СХЕМА:
{ "field": "type", "constraints": "..." }

Даём:

ПРИМЕРЫ КОРРЕКТНОГО ВЫВОДА:
Документ 1:
Исходник: ...
Результат: { ... }

Документ 2:
Исходник: ...
Результат: { ... }

Теперь обработай мой документ в таком же формате.

Эффект: +5-10% токенов, но работает без формальной спецификации. LLM выводит паттерн из примеров.

Что меняем: Убрать из шаблона строку "Выведи ТОЛЬКО валидный JSON без пояснений".

Заменить на:

Сначала напиши свои рассуждения:
1. Какие ключевые элементы нашёл в документе
2. Как они соотносятся с целевой схемой
3. Какие поля заполняю уверенно, какие под вопросом

Затем выведи итоговый JSON.

Эффект: Видишь логику модели. Помогает понять где она сомневается, какие данные не нашла. При дебаге invalide outputs — незаменимо. Стоит +20% токенов.

From Legacy to Standard: LLM-Assisted Transformation of Cybersecurity Playbooks into CACAO Format — Mehdi Akbari Gurabi, Lasse Nitz, Radu-Mihai Castravet, Roman Matzutt, Avikarsha Mandal, Stefan Decker (Fraunhofer FIT, RWTH Aachen University, 2025)

Исходный код, промпты, датасет: https://github.com/Fraunhofer-FIT-DSAI/CyberGuard

CACAO Specification 2.0: https://docs.oasis-open.org/cacao/security-playbooks/v2.0/