Ваш AI не умеет редактировать большие документы. Вот почему – и как это починить

Вы открываете чат. Загружаете договор на 80 страниц или корпоративный регламент на 200. Пишете: «Добавь в раздел 4.2 новый пункт про порядок согласования».

AI читает весь документ целиком. Находит (или не находит) нужное место. Что‑то вставляет. Иногда попадает, иногда — нет. Иногда ломает форматирование соседних таблиц. Иногда забывает ^[1], что этот же раздел нужно синхронизировать с приложением.

Дело не в мощности модели. Дело в том, что она работает вслепую: нет карты документа, нет правил редактирования, нет понимания что с чем связано или неприкосновенно.

Распад контекста (context rot) и итеративный дрейф: два симптома одной болезни

Первая реакция ^[2] на подобные жалобы обычно: «просто возьми модель с большим контекстным окном». Кто пробовал, тот знает — не поможет.

Проблема называется context rot. Исследование Есть статья на Хабре ^[3] BABILong – команда AIRI/МФТИ о том, посвященная той же тематике.

С документами это проявляется в двух режимах. Первый – разовый: модель читает весь документ, но при редактировании промахивается мимо нужного раздела или не все нужные для манипуляций фрагменты. Второй – накопительный, итеративный дрейф: первая правка проходит чисто, вторая – почти чисто, к пятой модель начинает переформулировать то, чего не просили, переставлять абзацы, переписывать таблицы в своей интерпретации. Каждая итерация добавляет в контекст всё больше истории – и модель теряет ориентир, что является правильным состоянием документа, а что промежуточным артефактом. Приходится адаптировать, уточнять промты, начинать новые чаты.

Как AI сейчас работает с .docx в чате

Когда вы отдаёте AI документ Word, происходит примерно следующее:

1. Распаковать .docx (потому что это - ZIP с XML внутри)
2. Извлечь текст из word/document.xml
3. Передать всё в контекст
4. Попросить модель найти нужное место
5. Сгенерировать правку
6. Запаковать, отдать в чат

У этого подхода три фундаментальных проблемы.

Первая: навигация вслепую. Модель сканирует тысячи параграфов последовательно. Нет карты. Нет закладок. Нет понятия о том, что параграф 847 – это начало раздела «Приложение Б», а таблица после него имеет строго фиксированную структуру колонок. Модель формирует это понимания исходя из структуры документа, накопленного контекста, все это не добавляет определенности.

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

Третья: нет верификации. После правки никто не проверяет, что закладки Word не разъехались, что таблица не потеряла строку, что XML-структура осталась валидной.

Существующие решения обходят это по-разному. Кто-то режет документ на чанки и делает RAG. Кто-то использует шаблонизаторы вроде docxtpl (Jinja2 + python-docx) – это все рабочие методы, но для эпизодической работы с большими документами выглядит сложно для большинства пользователей.

Что если пойти в другую сторону?

Идея: документ должен сам учить агента работать с собой

Эта идея пришла из мира разработки. Владимир Иванов (@turboplanner ^[4]) создал методологию GRACE (Graph-RAG Anchored Code Engineering) именно для борьбы с context rot в кодовых базах: каждый модуль получает контракт до написания кода, каждый блок кода маркируется семантически, граф знаний держит актуальную карту всего проекта. Агент работает не вслепую – он читает граф, находит нужный модуль, следует контракту, верифицирует результат. Репозиторий методологии: osovv/grace-marketplace ^[5].

Я взял ту же логику ^[6] и применил её к .docx.

Идея: вместо того чтобы каждый раз объяснять агенту структуру документа в промпте, зашить эти знания прямо внутрь файла. Один раз. Так, чтобы любой агент, открывший этот файл, сразу понял:

• какие разделы существуют и где они находятся

• что можно трогать, что нельзя

• что нужно синхронизировать при правке

• как верифицировать, что ничего не сломалось

Я назвал этот подход GRACE-DOCX (Governed, Recoverable, Autonomous, Contract-based Editing).

Один промт – и документ становится умным

Ссылка на волшебный промт ^[7]. Промпт инструктирует агента выполнить несколько простых, но важных шагов:

Шаг 1 – Анализ. Распаковать .docx, пройтись по word/document.xml, зафиксировать все H1/H2-заголовки, диапазоны параграфов, количество таблиц в каждом разделе, перекрёстные упоминания между секциями.

Шаг 2 – Карта модулей. Каждому H1-разделу присвоить короткий Module ID (M-PROC, M-APP-A, M-GLOSS…). Зафиксировать точные параграфные диапазоны и подразделы.

Шаг 3 – XML-метаданные. Создать пять файлов внутри .docx архива: манифест (точка входа), граф (карта модулей), контракты (правила редактирования), инструкции (протокол агента), верификация (инварианты структуры).

Шаг 4 – Закладки. Инъецировать w:bookmarkStart/End в каждый H1-параграф document.xml – стандартный механизм Word, визуально не отображается.

Шаг 5 – Регистрация. Прописать новые XML-части в [Content_Types].xml и word/_rels/document.xml.rels.

Шаг 6 – Упаковка. Собрать обратно в .docx.

Шаг 7 – Отчёт. Вывести сводку: N модулей, N закладок, N cross-links, список Module ID.

Весь процесс – одна команда, один файл, несколько минут.

“До” и “после”

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

Что это решает и чего не решает

Решает:

• Навигацию и “хирургические правки” в больших документах

• Итеративный дрейф – агент не переписывает то, чего не просили

• Синхронизацию связанных разделов при правке

• Воспроизводимость: разные сессии, разные агенты – одинаковое поведение ^[8], документ несёт правила с собой

• Снижает затраты на токенов (в некоторых случаях до 80%) и требования к размеру контекстного окна, а также утилизацию контекстного окна модели

Не решает:

• Семантическое понимание содержимого (за это отвечает сама LLM)

• Версионирование самого содержимого – отдельная задача. Но факт изменений фиксируется

Открытые вопросы:

• Расширение подхода на .xlsx (листы как модули) и .pptx (слайды, объекты как модули) – подход универсальный, теория говорит о том, что работать должно но я пока не проверял

• Работа с изображениями и диаграммами, вложенными DOM-объектами, более тонкая работа с таблицами.

• Расширение функционала, интеграция с MCP – чтобы агент мог вызывать этот как инструмент

Репозиторий

github.com/xronofag/grace-docx ^[9]

Pull requests приветствуются. Особенно интересны кейсы нестандартных документов и реализации для других форматов.