Сжатие документов

Эта глава — operator practice для человека и coding/knowledge agent: как переписывать требования, handoff и knowledge artifacts без необъяснённой потери смысла. Context compaction внутри production runtime использует похожие инварианты, но имеет отдельный state/projection contract в Context engineering.

Смыслосохраняющее сжатие требует контракта и проверки покрытия, а не одного удачного промпта.

Исходная формулировка:

Compress this document as much as possible without losing any information.

Грамматически правильно losing, не loosing. Но основная проблема не в английском: «максимально сократить» и «ничего не потерять» конфликтуют, пока не определено, что считается информацией и как проверяется её сохранность.

Lossless бывает разным

Побайтовое

Архиватор восстанавливает точный исходный файл. Перефразированный документ этого не делает.

Структурное

Сохраняются разделы, порядок, ссылки, таблицы и отношения между ними. Формулировки могут измениться.

Семантическое

Сохраняются утверждения, ограничения, решения, исключения и причинные связи, необходимые заданному читателю. Тон, примеры и повторения могут быть сокращены.

Целевое

Сохраняется всё, что нужно для конкретной последующей операции: выполнить процедуру, принять решение, ответить на вопросы или восстановить контекст.

Без выбранного уровня нельзя честно обещать «без потерь».

Семантические инварианты

До переписывания перечислите, что нельзя потерять:

• факты и числа;
• имена, даты, версии и ссылки;
• принятые решения и их основания;
• требования и запреты;
• scope и non-goals;
• исключения и edge cases;
• causal links: почему одно следует из другого;
• степень уверенности и provenance;
• открытые вопросы и несогласия;
• условия, при которых решение нужно пересмотреть.

Список зависит от назначения. Для юридического текста формулировка может быть инвариантом; для handoff важнее состояние и решения.

Процесс: inventory → compress → verify

1. Определить читателя и задачу

Reader: инженер, который продолжит работу завтра.
Use: восстановить состояние и выполнить следующий шаг.
Allowed loss: приветствия, повторные объяснения, хронология неудачных чтений.
Must preserve: goal, decisions, changed files, checks, blockers, risks.

2. Составить atomic-claim inventory

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

C1. Production работает на Node 18.
C2. Docusaurus 3.10 требует Node 20+.
C3. Wrangler 4 требует Node 22+.
C4. Выбран Node 24 LTS.
C5. Старые routes должны сохраниться.

Inventory временно увеличивает объём, но превращает расплывчатое «ничего не потерять» в проверяемый контракт.

3. Классифицировать содержимое

Класс	Действие
Уникальный обязательный смысл	Сохранить явно
Повтор	Объединить, оставив сильнейшую формулировку
Пример	Сохранить, если без него правило неоднозначно
Background	Сжать или вынести по ссылке
Устаревшее	Пометить или удалить с объяснением
Неопределённость	Сохранить как open question, не превращать в факт

4. Выбрать новую структуру

Чаще всего краткость появляется из структуры, а не из удаления слов:

• общий принцип один раз;
• детали в таблице;
• длинные доказательства по ссылке;
• summary и complete reference раздельно;
• определения перед использованием;
• исключения рядом с правилом.

5. Написать сжатую версию

Удаляйте:

• одинаковую мысль разными словами;
• метатекст «в этом разделе мы рассмотрим»;
• пустые усилители «очень важно понимать»;
• примеры, не добавляющие новой границы;
• хронологию действий, если нужен только итог.

Не удаляйте только ради длины:

• отрицания;
• условия;
• степень уверенности;
• автора решения;
• последствия и trade-offs.

6. Построить coverage matrix

| Claim | Где сохранён | Статус |
|---|---|---|
| C1 | Раздел «Исходное состояние» | exact |
| C2 + C3 | Таблица требований runtime | merged |
| C4 | Decision | exact |
| C5 | Constraints | exact |

merged допустим, если объединение не меняет отношения и область действия.

7. Выполнить retrieval test

До сжатия составьте вопросы, затем отвечайте только по новой версии:

• Какая версия Node выбрана и почему?
• Какие альтернативы рассматривались?
• Какой инвариант защищает старые страницы?
• Что осталось непроверенным?

Если ответ требует догадки или исходника, покрытие неполно.

Небольшой пример

Исходник:

Мы решили использовать Node 24. Node 24 является LTS-версией. Это решение было принято потому, что Docusaurus 3.10 требует минимум Node 20, а актуальный Wrangler требует минимум Node 22. Использование Node 24 позволяет удовлетворить оба этих требования. При этом старые страницы сайта не должны исчезнуть после обновления, поэтому перед изменениями нужно сохранить список существующих маршрутов.

Сжатая версия:

Runtime: Node 24 LTS — он удовлетворяет требованиям Docusaurus 3.10 (20+) и Wrangler 4 (22+). Перед обновлением зафиксировать route manifest; после него каждый старый route обязан сохраниться.

Потеряно: хронологическое повторение решения. Сохранено: версия, статус LTS, две причины, требование baseline и инвариант.

Три готовых контракта

Быстрое сокращение

Подходит для низкорискового текста, когда исходник остаётся рядом.

Сократи текст примерно в [N] раз. Удали повторы, метатекст и примеры,
не добавляющие нового ограничения. Сохрани факты, числа, решения,
условия, исключения, открытые вопросы и степень уверенности.
Не добавляй новую информацию. В конце перечисли возможные смысловые потери.

Проверяемое смыслосохраняющее сжатие

Подходит для требований, handoff и решений.

Цель: получить более компактную версию для [читатель/операция].

До переписывания:
1. Составь atomic inventory всех фактов, решений, ограничений,
   исключений, причинных связей и открытых вопросов.
2. Покажи inventory и предложи структуру сжатой версии.

После согласования:
3. Перепиши документ, удаляя redundancy, а не уникальный смысл.
4. Дай coverage matrix: каждый элемент inventory → новое место.
5. Ответь на контрольные вопросы только по сжатой версии.
6. Перечисли всё, что не удалось сохранить или пришлось обобщить.

Если дальнейшее сокращение требует потери инварианта — остановись.

Два слоя: summary + reference

Подходит, когда краткость нужна ежедневно, а полнота — иногда.

Создай два слоя:

A. Executive summary — только решения, последствия, риски и next actions.
B. Complete reference — все уникальные факты, ограничения, исключения,
   источники и открытые вопросы без повторов.

Summary должен ссылаться на соответствующие разделы reference.
Reference должен проходить coverage audit исходника.

Как сжимать agent context

Для продолжения работы обычно нужны:

• task contract;
• decisions и причины;
• фактические изменения;
• результаты проверок;
• текущие blockers/risks;
• next safe action.

Обычно не нужны:

• каждое сообщение о прогрессе;
• повторные листинги одного файла;
• уже опровергнутые гипотезы без исторической ценности;
• необязательные вежливые переходы.

Context compaction — частный случай document compression. Anthropic также рекомендует очищать или компактно пересобирать накопившийся контекст агентного цикла, сохраняя релевантное состояние: Effective context engineering.

Предел сжатия

После удаления redundancy остаётся информационная плотность. Дальше возможны только trade-offs:

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

Если модель продолжает обещать сокращение без потерь, попросите указать следующий удаляемый элемент и доказать, что он выводим из оставшегося текста.

Failure modes

• Гладкий summary — читается хорошо, но теряет исключения и uncertainty.
• Скрытая дедупликация — похожие, но не одинаковые требования объединены.
• Fact upgrade — гипотеза превратилась в факт.
• Causal loss — решение сохранено, причина удалена; пересмотр становится невозможен.
• Reference rot — summary ссылается на раздел, который позже изменился.
• Coverage theater — matrix перечисляет заголовки, а не atomic claims.
• Compression by jargon — текст короче только потому, что стал непонятен читателю.

Checklist

• Определены читатель и последующая операция.
• Выбран смысл lossless для этой задачи.
• Atomic inventory создан до rewrite.
• Facts отделены от hypotheses и opinions.
• Decisions сохранили основания и revisit conditions.
• Coverage matrix отображает каждый claim.
• Retrieval questions разрешимы по новой версии.
• Потери и обобщения перечислены явно.
• Дальнейшее сокращение останавливается на границе инвариантов.