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 — це не «зробили менше токенів і все». Він впливає на спостережуваність (observability). Ви більше не можете прочитати, що саме «пам'ятає» агент після компакшну, а значить зростає роль тестів, регресійних сценаріїв і телеметрії якості. У 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 — консультацію проведу особисто я, Вадим Нагорний, і запропоную схему впровадження з урахуванням якості, безпеки та майбутньої переносимості.