Вы открываете чат. Загружаете договор на 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 – чтобы агент мог вызывать этот как инструмент
Репозиторий
https://github.com/xronocode/grace-docx
Pull requests приветствуются. Особенно интересны кейсы нестандартных документов и реализации для других форматов.
Комментарии (19)
atomlib
07.04.2026 18:07Во-первых
Зачем нужны эти промпты для редактирования, если представлена вот такая примитивная задача?
Добавь в раздел 4.2 новый пункт про порядок согласования
Открыть документ, дойти до нужного фрагмента и дописать его — это легче и быстрее, чем создавать для большой языковой модели инструкции с помощью особого промпта с Хабра, описывать собственно сами изменения, а потом перепроверять и исправлять работу за роботом. Думаю, в случаях, когда у промпта есть название, ситуация по определению переусложнена.
Во-вторых
Зачем редактировать тексты с помощью больших языковых моделей? На выходе получается какой-то однотипный кошмар, в котором немедленно угадывается искусственный интеллект.
Просто посмотрите, как тут всё ужасно с ритмом, везде рублёные предложения:
Вы открываете чат. Загружаете договор на 80 страниц или корпоративный регламент на 200. Пишете: «Добавь в раздел 4.2 новый пункт про порядок согласования».
AI читает весь документ целиком. Находит (или не находит) нужное место. Что‑то вставляет. Иногда попадает, иногда — нет.
«Это не А, это Б», где желательно как можно сильнее обозначить паузу между фрагментами:
Это не баг конкретной модели, это архитектурное свойство трансформеров.
Дело не в мощности модели. Дело в том, что она работает вслепую
Агент работает не вслепую – он читает граф, находит нужный модуль, следует контракту, верифицирует результат.
Разница принципиальная: агент не угадывает. Он следует протоколу, который сам же и составил.
В тексте 2 длинных тире, шириной с букву M (em-dash), и 26 коротких тире, шириной с букву N (en-dash). Em-dash только в первых четырёх абзацах, кстати.
Откровенная ошибка:
Исследование Chroma (2025) протестировало 18 frontier-моделей и обнаружило: каждая деградирует при каждом шаге увеличения контекста – включая GPT-4.1, Claude Opus 4 и Gemini 2.5. Это не баг конкретной модели, это архитектурное свойство трансформеров.
У вас ссылка на статью Chroma некликабельна.
В статье Chroma есть предложение, которое буквально утверждает обратное: «We also do not explain the mechanisms behind this performance degradation». То есть работа не может объяснить механизмы деградации. Слова «architecture» в той статье вообще нет.
В-третьих
У меня такое впечатление, что либо я сошёл с ума, либо половина Интернета рехнулась. Сначала языковую модель либо просят написать текст с нуля, либо что-то подровнять в полуготовом черновике, и БЯМ выдаёт много этого машинного текста. Полученное всегда выглядит как слоп: одни и те же языковые обороты, раздражающий темп речи, характерные однотипные привычки в использовании форматирования (выделения италиком и полужирным) и знаков препинания (избыток тире, дефисов). Затем это всё публикуется от своего имени, будто так и должно быть, будто никто не видит, что это машинный текст этого неприятного стиля.
В отдельных случаях бывает так, что у автора уже есть отличный черновик, в котором достаточно просто подровнять опечатки и убрать ошибки пунктуации. Но при этом автор зачем-то вставляет текст в языковую модель, чтобы получить оттуда этот неудобоваримый слоп. Вот типичный пример: статья и оригинальный черновик.
Вы мне поверьте: сами создатели искусственного интеллекта не имеют вкуса и чувства красоты. Вот самый типичный пример: эта картинка была продемонстрирована в качестве улучшения работы модели генерации картинок DALL·E 3 относительно второй версии. Здесь в промпте просили изобразить экспрессивную картину маслом печенья с шоколадной крошкой в молоке, и вариант слева якобы хуже.
Не ждите, что ИИ улучшит ваш текст, он его только испоганит.
Вы могли бы поспорить, что можно доверить языковым моделям что-то нудное и нехудожественное — договоры и юридические документы, например. Но погодите, есть целая страница, где собирают случаи обнаружения галлюцинаций искусственного интеллекта в судебных документах. Там сейчас уже 1277 случая, и некоторые юристы за свою лень поплатились. Не думаю, что есть смысл рисковать даже с каким-то корпоративным регламентом.
Не представляю, зачем доверять ИИ тексты. Если они предназначены для людей, то читать неприятно, если для юристов — опасно; если правок мало — легче вручную, если много — нужно тратить время на перепроверку. Уловка-22 работает по всем фронтам.
Pilotv
07.04.2026 18:07Исключая традиционные стенания про то как нехорошо пользоваться ИИ, от которых уже тошнит ей Богу, у Вас в логике дыра с Марианскую впадину. "есть целая страница, где собирают случаи обнаружения галлюцинаций искусственного интеллекта в судебных документах. Там сейчас уже 1277 случая, и некоторые юристы за свою лень поплатились." Вам любой юрист с опытом накидает не 1277 а 122 777 случаев галлюцинаций вполне естественного юридического интеллекта за которые поплатились и сами авторы и их клиенты - некоторые даже лет по 30 отсидели. Мы какой вывод из этого должны будем сделать ? Что не надо пользоваться юристами ? "Не представляю, зачем доверять ИИ тексты." Я ежедневно читаю тексты написанные людьми и для людей, иногда прям моими сотрудниками и вот лучше бы они ИИ пользовались хоть читать можно будет без головной боли.
Xronofag Автор
07.04.2026 18:07Спасибо, я указал в статье, что сама семантика (содержание) за рамками статьи. контент, конечно нужно проверять и вычитывать. Согласен.
Xronofag Автор
07.04.2026 18:07Спасибо. Ссылку поправил. Надеюсь вы оставили голос - "Не пользуюсь ИИ для редактирования текстов"? Если нет, проголосуйте, пожалуйста.
PereslavlFoto
07.04.2026 18:07Хотелось бы ИИ, который сможет прочитать и рассказать. Например, прочитать 10 000 страниц и рассказать, что там написано про Ивана Ивановича.
Человек с этой задачей не справляется, у человека не хватает времени и внимания.
Xronofag Автор
07.04.2026 18:07В целом это вполне посильная задача современным агентским системам. Нет проблемы заспавнить несколько сотен агентов которые прошерстят и соберут все про Иван Иваныча на всех 10тыс страниц.
PereslavlFoto
07.04.2026 18:07А зачем сотни агентов? Надо разрезать книгу на сто кусков, что ли?
Xronofag Автор
07.04.2026 18:07Так эффективнее. Можно и не резать.
PereslavlFoto
07.04.2026 18:07Что-то я туплю. Как сотня агентов сможет дать 1 текст с обзором всего, что сказано про Ивана Ивановича в этой толстенной книге, или даже в двух книгах?
AppCrafter
07.04.2026 18:07Не знаю как у автора получилось запихнуть в ИИ документы по 80 и 200 страниц. Однажды попытался проверить чисто ошибки в тексте на 60 страниц с помощью ChatGPT, так он его просто не осилил. Выдал страниц 5 и спекся. А резать и скармливать кусками тот ещё гемор.
Xronofag Автор
07.04.2026 18:07На скрине живой скриншот с реального документа на 80 страниц в Claude. Первый раз ему его действительно тяжело переварить. После разметки работает с ним шустрее.
nihil-pro
07.04.2026 18:07Да кто же вам генерирует эти дурацкие заголовки?! Каждая третья статья с тем же паттерном в заголовке [я/мы/он/она] [чё-то там] — и вот [как/почему/зачем]
Xronofag Автор
07.04.2026 18:07:) это классический копирайтерский приём «проблема - решение», он работает потому что сразу отвечает на вопрос «а мне это вообще надо читать?». Но согласен, когда каждая третья статья так называется – замыливается, может вызывать и раздражение.
Если есть вариант как назвать эту конкретную тему лучше – возьму на заметку на будущее.
rex1234
07.04.2026 18:07Не пробовали использовать LaTeX вместо word? Эта штука поможет решить 90% проблем с форматированием и пересчётом значений. Да и проблема с колличеством токенов уменьшится, т.к. xml максимально не экономный формат
Xronofag Автор
07.04.2026 18:07Пробовал, когда дипломную писал ;)
Я разбирал в подходе не профессиональный, а массовый кейс. Со стандартными «бытовыми» инструментами.
Kenya-West
Спасибо за статью! Ссылка на репо битая, 404 отдаёт.
Xronofag Автор
Пожалуйста и спасибо. Ссылку поправил. https://github.com/xronocode/grace-docx