Вы открываете чат. Загружаете договор на 80 страниц или корпоративный регламент на 200. Пишете: «Добавь в раздел 4.2 новый пункт про порядок согласования».
AI читает весь документ целиком. Находит (или не находит) нужное место. Что‑то вставляет. Иногда попадает, иногда — нет. Иногда ломает форматирование соседних таблиц. Иногда забывает, что этот же раздел нужно синхронизировать с приложением.
Дело не в мощности модели. Дело в том, что она работает вслепую: нет карты документа, нет правил редактирования, нет понимания что с чем связано или неприкосновенно.
Распад контекста (context rot) и итеративный дрейф: два симптома одной болезни
Первая реакция на подобные жалобы обычно: «просто возьми модель с большим контекстным окном». Кто пробовал, тот знает — не поможет.
Проблема называется context rot. Исследование Chroma (2025) протестировало 18 frontier-моделей и обнаружило: каждая деградирует при каждом шаге увеличения контекста – включая GPT-4.1, Claude Opus 4 и Gemini 2.5. Это не баг конкретной модели, это архитектурное свойство трансформеров. Stanford показал механику: точность падает более чем на 30%, когда нужная информация оказывается в середине контекста, а не в начале или конце. Есть статья на Хабре BABILong – команда AIRI/МФТИ о том, посвященная той же тематике.
С документами это проявляется в двух режимах. Первый – разовый: модель читает весь документ, но при редактировании промахивается мимо нужного раздела или не все нужные для манипуляций фрагменты. Второй – накопительный, итеративный дрейф: первая правка проходит чисто, вторая – почти чисто, к пятой модель начинает переформулировать то, чего не просили, переставлять абзацы, переписывать таблицы в своей интерпретации. Каждая итерация добавляет в контекст всё больше истории – и модель теряет ориентир, что является правильным состоянием документа, а что промежуточным артефактом. Приходится адаптировать, уточнять промты, начинать новые чаты.
Как AI сейчас работает с .docx в чате
Когда вы отдаёте AI документ Word, происходит примерно следующее:
1. Распаковать .docx (потому что это - ZIP с XML внутри)2. Извлечь текст из word/document.xml3. Передать всё в контекст4. Попросить модель найти нужное место5. Сгенерировать правку6. Запаковать, отдать в чат
У этого подхода три фундаментальных проблемы.
Первая: навигация вслепую. Модель сканирует тысячи параграфов последовательно. Нет карты. Нет закладок. Нет понятия о том, что параграф 847 – это начало раздела «Приложение Б», а таблица после него имеет строго фиксированную структуру колонок. Модель формирует это понимания исходя из структуры документа, накопленного контекста, все это не добавляет определенности.
Вторая: нет правил редактирования. Модель не знает, что в этом документе нельзя менять заголовки колонок таблиц. Не знает, что если обновить пороговые значения в одном разделе, их нужно синхронизировать с другим. Она не знает ничего – кроме того, что вы напишете в промпте прямо сейчас.
Третья: нет верификации. После правки никто не проверяет, что закладки Word не разъехались, что таблица не потеряла строку, что XML-структура осталась валидной.
Существующие решения обходят это по-разному. Кто-то режет документ на чанки и делает RAG. Кто-то использует шаблонизаторы вроде docxtpl (Jinja2 + python-docx) – это все рабочие методы, но для эпизодической работы с большими документами выглядит сложно для большинства пользователей.
Что если пойти в другую сторону?
Идея: документ должен сам учить агента работать с собой
Эта идея пришла из мира разработки. Владимир Иванов (@turboplanner) создал методологию GRACE (Graph-RAG Anchored Code Engineering) именно для борьбы с context rot в кодовых базах: каждый модуль получает контракт до написания кода, каждый блок кода маркируется семантически, граф знаний держит актуальную карту всего проекта. Агент работает не вслепую – он читает граф, находит нужный модуль, следует контракту, верифицирует результат. Репозиторий методологии: osovv/grace-marketplace.
Я взял ту же логику и применил её к .docx.
Идея: вместо того чтобы каждый раз объяснять агенту структуру документа в промпте, зашить эти знания прямо внутрь файла. Один раз. Так, чтобы любой агент, открывший этот файл, сразу понял:
-
какие разделы существуют и где они находятся
-
что можно трогать, что нельзя
-
что нужно синхронизировать при правке
-
как верифицировать, что ничего не сломалось
Я назвал этот подход GRACE-DOCX (Governed, Recoverable, Autonomous, Contract-based Editing).
Один промт – и документ становится умным
Ссылка на волшебный промт. Промпт инструктирует агента выполнить несколько простых, но важных шагов:
Шаг 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.
Весь процесс – одна команда, один файл, несколько минут.
“До” и “после”
Разница принципиальная: агент не угадывает. Он следует протоколу, который сам же и составил.
Что это решает и чего не решает
Решает:
-
Навигацию и “хирургические правки” в больших документах
-
Итеративный дрейф – агент не переписывает то, чего не просили
-
Синхронизацию связанных разделов при правке
-
Воспроизводимость: разные сессии, разные агенты – одинаковое поведение, документ несёт правила с собой
-
Снижает затраты на токенов (в некоторых случаях до 80%) и требования к размеру контекстного окна, а также утилизацию контекстного окна модели
Не решает:
-
Семантическое понимание содержимого (за это отвечает сама LLM)
-
Версионирование самого содержимого – отдельная задача. Но факт изменений фиксируется
Открытые вопросы:
-
Расширение подхода на
.xlsx(листы как модули) и.pptx(слайды, объекты как модули) – подход универсальный, теория говорит о том, что работать должно но я пока не проверял -
Работа с изображениями и диаграммами, вложенными DOM-объектами, более тонкая работа с таблицами.
-
Расширение функционала, интеграция с MCP – чтобы агент мог вызывать этот как инструмент
Репозиторий
github.com/xronofag/grace-docx
Pull requests приветствуются. Особенно интересны кейсы нестандартных документов и реализации для других форматов.
Автор: Xronofag
