OpenAI Compaction API: как удержать качество агента и снизить стоимость контекста

Technical Context

Я внимательно посмотрел на документацию OpenAI по compaction в Responses API и увидел сдвиг, который архитектурно важнее очередного «больше контекста». В output после вызова появляется специальный item с type=compaction, внутри — opaque encrypted_content, который, по формулировке OpenAI, “preserves the model’s latent understanding”. Для меня это означает: нам дают не пересказ истории, а перенос внутреннего состояния понимания в компактный контейнер.

Ключевая практическая разница с классической суммаризацией такая: резюме — это текст, который вынужден «дистиллировать» прошлое и почти всегда теряет детали, причинно-следственные связи и тонкие договорённости. Compaction же пытается сохранить именно то, чем модель реально пользуется для продолжения рассуждений, но делает это в форме, которую клиент не может интерпретировать и редактировать.

С точки зрения интеграции есть два основных пути.

• Авто-управление контекстом в /responses: вы задаёте context_management с compact_threshold (например, 0.9). Когда окно контекста приближается к лимиту, платформа во время стрима может эмитить compaction item, «подрезать» историю и продолжить генерацию уже с компактным представлением.
• Ручной прогон через /responses/compact: вы отправляете полный вход (который обязан помещаться в лимит модели на момент компакшна) и получаете «упакованное окно» для следующего /responses.

Что мне бросилось в глаза как архитектору: encrypted_content может быть очень большим (в документации фигурируют значения до ~10M символов), при этом он остаётся непрозрачным. Это не «экономия до пары строк», это другой формат хранения контекстного следа. И ещё момент: OpenAI подчёркивают совместимость с ZDR, что для корпоративных контуров звучит как попытка минимизировать риски хранения/утечек, но без раскрытия деталей ключевого управления и внутренней криптографии я бы не обещал службе безопасности «магической приватности» — я бы просто закладывал это как managed-механизм провайдера.

Важно также понимать, что compaction в их модели мира не обязан заменять все пользовательские сообщения: в описаниях встречается идея, что пользовательский текст может сохраняться более «как есть», а вот слои assistant/tool/reasoning упаковываются. Для агентных систем это логично: именно tool-след и цепочки рассуждений быстрее всего раздувают окно и чаще всего ломаются при примитивном резюмировании.

Business & Automation Impact

На практике я почти всегда упираюсь в одну и ту же боль: «агент умнеет первые 10–20 минут, а потом начинает тупеть». Причина обычно не в модели как таковой, а в том, как команда делает управление контекстом: урезали историю, сделали грубое резюме, потеряли ограничения/цели/исключения — и агент начинает принимать другие решения. Compaction — это попытка провайдера закрыть именно этот класс деградации.

Если я проектирую ИИ автоматизация для продаж, поддержки или инженерных команд, то compaction меняет математику TCO: длинные сессии становятся предсказуемее по стоимости, а качество после «сжатия» потенциально проседает меньше, чем при текстовом summarization. Выигрывают те, у кого есть:

• долгоживущие диалоги (support L2/L3, onboarding, закупки, тендерные переписки);
• tool-heavy агенты (CRM/ERP, каталоги, RPA-оркестрация, code-assist с большим количеством вызовов инструментов);
• процессы, где критична последовательность решений (комплаенс-скрипты, согласования, регламенты).

Проигрывают те, кто рассчитывал на «универсальную переносимость истории» между провайдерами. Оpaque blob — это фактически vendor lock-in на уровне памяти агента. Если завтра вы захотите переехать на другой LLM-стек, этот слой контекста не мигрирует. В своих проектах я бы закладывал простое правило: оригинальные артефакты нужно хранить у себя (пользовательские сообщения, tool inputs/outputs, критичные факты, решения и их обоснование) — иначе вы теряете управляемость и аудит.

Ещё одна бизнес-деталь: compaction — это не «сделали меньше токенов и всё». Он влияет на наблюдаемость. Вы больше не можете прочитать, что именно «помнит» агент после компакшна, а значит растёт роль тестов, регрессионных сценариев и телеметрии качества. В Nahornyi AI Lab я бы включал это в план внедрения искусственного интеллекта как обязательный слой: eval-наборы на ключевые намерения, проверки на сохранение ограничений, и отдельные тесты на «после компакшна».

С архитектурной точки зрения я вижу практичный паттерн: compaction — это «быстрая память» провайдера, а у клиента остаётся «долгая память» в структурированном виде (facts/decisions/constraints) и хранилище первички для аудита. В таком раскладе compaction даёт скорость и устойчивость, а ваш контур — контроль.

Strategic Vision & Deep Dive

Мой прогноз: рынок агентных платформ уйдёт от дискуссии «какое резюме лучше» к дискуссии «какая память лучше». Compaction — это шаг к managed-памяти на стороне модели, где провайдер оптимизирует перенос состояния так же, как оптимизирует inference. И это сильный ход: он убирает у команд необходимость изобретать свой алгоритм компрессии диалогов, который почти всегда получается хрупким.

Но я не покупаю это как универсальное решение. В проектах Nahornyi AI Lab я регулярно вижу два класса требований, которые compaction не закрывает:

• Объяснимость: бизнесу часто нужно понимать, почему агент пришёл к решению. Непрозрачный blob не поможет. Значит, критичные решения я всё равно фиксирую в читаемых логах: «какие факты использованы», «какие правила сработали», «какой инструмент вернул что».
• Управляемое забывание: иногда нужно гарантированно «стереть» часть контекста (PII, коммерческая тайна, ошибочная инструкция). Когда память непрозрачная, вам придётся выстраивать политику: что не допускается в контекст вообще, что проходит через redaction до отправки, и как устроены ретеншн/удаление на вашей стороне.

Я бы использовал compaction как механизм стабилизации рассуждений агента, но не как единственный источник истины. Реальная архитектура ИИ-решений в производстве — это слоёный пирог: событийный лог, структурные «факты», RAG по корпоративным данным, правила безопасности, и только поверх этого — разговорный слой, который может компактиться.

И есть ещё ловушка, в которую легко попасть: «раз всё сохраняется латентно, можно не думать о контексте». Нельзя. Если вы кормите модель мусором (дубли, противоречия, лишние tool-следы), вы рискуете законсервировать этот мусор в более стойкой форме. Польза compaction раскрывается, когда до него вы уже сделали нормальную дисциплину сообщений, типизацию tool-результатов и минимизацию шума.

Дальше будет меньше хайпа про «гигантские окна» и больше инженерии про память, контроль и стоимость. Compaction — мощный инструмент, но выигрывают те, кто внедряет его как часть системы, а не как галочку в SDK.

Если вы строите долгоживущего агента или хотите сделать ИИ автоматизацию без расползания бюджета, я приглашая вас обсудить архитектуру и тестовый план под ваш процесс. Напишите в Nahornyi AI Lab — консультацию проведу лично я, Vadym Nahornyi, и предложу схему внедрения с учётом качества, безопасности и будущей переносимости.