Контекстное окно - жёсткий бюджет, а не файловое хранилище

Модель получает только содержимое конкретного вызова: инструкции, сообщения, определения tools, документы и другие элементы. Всё конкурирует за конечное окно. Даже если лимит велик, длинный input стоит дороже, обрабатывается дольше и может ухудшать поиск важного среди шума.

Context engineering - это выбор минимального набора информации, достаточного для следующего правильного действия. История приложения может быть полной, но inference context всегда является собранным представлением.

1
контекст на вызов
6
слоёв с отдельным бюджетом
0
случайных обрезаний

Сначала вычислите usable input

Номинальное окно нельзя целиком занять историей. Зарезервируйте место для ожидаемого output, tool calls, reasoning и сериализационного overhead. Точные правила подсчёта зависят от модели и API - используйте официальный tokenizer или usage telemetry и оставляйте запас.

usable_input = model_context_limit
  - reserved_output
  - reserved_reasoning_or_internal_budget
  - tool_schema_and_protocol_overhead
  - safety_margin

Reject or compact before usable_input is exceeded.
Record estimated and actual tokens in the trace.

Разделите контекст на слои с разной ценностью

СлойСодержимоеСтратегия
PolicySystem rules, права, запретыСохранять полностью
Task stateЦель, план, approvals, открытые шагиTyped state
Verified factsПодтверждённые значения и источникиКомпактная таблица
Recent dialogueПоследние релевантные turnsSliding window
EvidenceRetrieved chunks и артефактыTop relevant under budget
Tool resultsОтветы внешних системМинимальный typed output

Приоритет должен быть явным и детерминированным

Когда места не хватает, runtime применяет заранее заданную политику, а не просит модель решить, что удалить из собственных инструкций. Policy и актуальный task state имеют гарантированный резерв; evidence и история конкурируют только внутри своих квот.

P0: system policy and current authorization - never summarize
P1: task objective, approvals, constraints - preserve typed
P2: verified facts and open decisions - preserve with provenance
P3: latest user turns - keep verbatim within cap
P4: retrieved evidence - rank, deduplicate, cap per source
P5: old dialogue and verbose tool output - compact or reference
On overflow: fail explicitly if P0 - P2 do not fit.

Typed state надёжнее пересказа всей переписки

Цель, выбранные параметры, обязательства, approvals и незавершённые действия должны жить в состоянии workflow. Тогда после десятков turns не нужно надеяться, что модель найдёт решение в старом сообщении.

Goal

Текущая цель и definition of done.

Decisions

Принятые варианты и источник.

Open work

Зависимости, status и deadline.

Не путайте transcript, state, memory и context

ОбъектНазначениеПопадает в модель
TranscriptПолный журнал событийТолько выбранные turns
Workflow stateАвторитетное состояние задачиКомпактное представление
Long-term memoryРазрешённые устойчивые фактыПо retrieval и scope
ArtifactsДокументы и результатыФрагменты или ссылки
Inference contextInput текущего вызоваУже собранный пакет

Sliding window сохраняет свежесть, но теряет решения

Оставлять последние N сообщений просто, но старое важное решение исчезнет раньше свежей болтовни. Используйте sliding window только для локальной связности, а durable facts и decisions переносите в state. При каждом turn определяйте, изменились ли цель, ограничения или открытые обязательства.

  • Последние user/assistant turns остаются verbatim.
  • Tool chatter не занимает весь window.
  • Решение переносится с actor и timestamp.
  • Отменённое решение помечается superseded.
  • Скрытые reasoning traces не считаются state.

Compaction - контролируемая миграция информации

Compaction заменяет набор старых элементов компактным артефактом. Он должен иметь schema, source range, версию алгоритма, timestamp и проверку. Исходный transcript остаётся в storage для аудита, если это разрешает retention policy.

summary_id: sum_...
source_event_range: evt_120..evt_188
summary_schema: ConversationSummaryV3
contains: goals, decisions, constraints, commitments, unresolved_items
excludes: secrets, redundant tool payloads, superseded drafts
source_refs: [...]
generator_version: ...
validator_status: passed
created_at: ...

Хороший summary сохраняет не темы, а операционные инварианты

Пересказ «обсуждали запуск сайта» бесполезен. Нужны конкретные решения, значения, возражения, незавершённые вопросы и ссылки. Summary не должен превращать предположение в факт или скрывать конфликт.

Summary schema
  1. Текущая цель.
  2. Definition of done.
  3. Подтверждённые факты с sources.
  4. Решения и кто их принял.
  5. Жёсткие ограничения.
  6. Действующие approvals и scope.
  7. Открытые задачи и blockers.
  8. Конфликты, которые нельзя сгладить.
  9. Superseded решения.
  10. Ссылки на исходные события.

Summary остаётся недоверенным производным артефактом

LLM может пропустить отрицание, перепутать число или принять injection за инструкцию. Валидируйте schema и критичные поля детерминированно, сверяйте с source events и храните confidence только как сигнал маршрутизации, а не как доказательство.

  • Approvals извлекаются из authoritative store.
  • Деньги, даты и IDs проверяются отдельно.
  • Policy никогда не переписывается summary.
  • Unresolved conflict сохраняется явно.
  • Низкая уверенность вызывает human review или больший verbatim window.

Retrieval заменяет постоянную загрузку всего корпуса

Документацию, архив и прошлые кейсы храните вне prompt и выбирайте под текущий вопрос. Query включает цель и проверенные сущности, но доступ ограничивается trusted tenant context. Каждый chunk имеет source, version, timestamp и data class.

K
релевантных chunks
1
обязательный access scope
evidence token cap

Бюджет retrieval распределяется по источникам

Если один длинный документ занял весь лимит, контекст может потерять разнообразие evidence. Дедуплицируйте похожие chunks, задавайте cap на source, добавляйте соседний фрагмент только когда он нужен для связности и сохраняйте место для контраргумента.

ПроблемаЗащитаМетрика
Один source доминируетPer-source capSource diversity
ПовторыSemantic dedupDuplicate token ratio
Обрезан смыслBoundary-aware chunksContext sufficiency
Устаревшие данныеVersion и freshnessStale retrieval rate
Чужие данныеPre-filter + post-checkIsolation failures

Tool output должен быть минимальным и типизированным

Не возвращайте модели полный API response, HTML или таблицу из тысяч строк. Tool формирует поля, необходимые для следующего решения, и ссылку на полный immutable artifact. Большие результаты агрегируются кодом.

Return:
status, requested fields, bounded items, pagination state, provenance, artifact_ref

Do not return:
raw credentials, unrelated fields, entire database rows, duplicated payload, hidden policy

If result is large:
store artifact → compute deterministic summary → return reference + verified aggregates.

Prompt caching оптимизирует повторный префикс

Кэширование контекста может уменьшать стоимость и задержку повторной обработки стабильных инструкций или большого общего материала. Оно не расширяет окно и не решает relevance. Структурируйте стабильную часть в начале, динамическую - после неё; измеряйте cached tokens по telemetry.

Механизм, минимальный размер, TTL, тариф и совместимость с data-retention controls зависят от API. Проверяйте текущую официальную документацию перед архитектурным решением.

Truncation должна быть наблюдаемым событием

Некоторые API умеют автоматически удалять старые элементы при переполнении. Это удобно, но продукт должен знать, что исчезло. Отключите неявную обрезку для критичных workflows либо задайте controlled retention policy и событие, после которого запускается compaction.

РежимПлюсРиск
Hard errorНичего не теряется скрытоНужно обработать overflow
Drop oldestПростоТеряются решения
Retention ratioРеже ломается cache prefixНужна проверка сохранённого
Semantic compactionСохраняет смыслОшибки summary
Typed state + retrievalКонтролируемоСложнее архитектура

Порядок частей влияет на устойчивость

Стабильные system instructions и общие материалы обычно размещают в согласованном префиксе для cache reuse. Текущую задачу и ключевые ограничения формулируют явно; evidence размечают границами и provenance. Не надейтесь, что важный факт будет найден в произвольной позиции длинного input.

  • Один authoritative блок policy.
  • Явная задача и output contract.
  • Typed state перед необязательной историей.
  • Evidence с source labels.
  • Последний user turn без пересказа.
  • Нет противоречивых дубликатов instructions.

Context manifest делает вызов воспроизводимым

Для каждого model call сохраняйте не обязательно весь чувствительный payload, а manifest сборки: версии, IDs элементов, token estimates, причины включения и удаления, compaction version и retrieval query. Это позволяет расследовать потерянный факт.

call_id, trace_id
model_and_context_limit
policy_version, task_state_version
summary_ids, message_range
retrieved_chunk_ids_and_scores
tool_schema_version, tool_result_refs
tokens_by_layer_estimated_and_actual
items_dropped_with_reason
cache_read_tokens, cache_write_tokens
assembler_version

Безопасность: данные не могут стать инструкциями

Retrieved documents, tool outputs, old messages и summaries считаются untrusted data. Маркировка XML или JSON помогает структуре, но не является границей безопасности. Runtime ограничивает tools, права и side effects независимо от prompt.

Context security
  1. Tenant scope применяется до retrieval.
  2. Секреты удаляются до model call.
  3. Data и instructions разделены.
  4. Summary не меняет policy.
  5. Tool results имеют provenance.
  6. Каждый side effect повторно авторизуется.
  7. Compaction тестируется на indirect injection.
  8. Trace payload редактируется.

Evals должны воспроизводить длинную сессию

Короткий single-turn eval не обнаружит, что после compaction потерялась сумма, отрицание или approval. Создайте сценарии с десятками turns, несколькими сжатиями, конфликтами, tool errors и критичным фактом в начале, середине и конце.

МетрикаЧто измеряет
Task successДостигнут итог задачи
Preservation recallСохранены обязательные факты и решения
Unsupported carryoverSummary не придумал факт
Retrieval sufficiencyEvidence достаточно для ответа
Tokens per successЭффективность контекста
Compaction recoveryМожно продолжить после сжатия
Injection resistanceДанные не меняют policy

Rollout context policy проводится как изменение кода

  1. Зафиксируйте current assembler и eval baseline.
  2. Соберите распределение tokens по слоям.
  3. Добавьте typed state без удаления истории.
  4. Запустите новый compactor в shadow.
  5. Сравните summaries и downstream task success.
  6. Canary на стабильной cohort.
  7. Следите за overflow, latency, cost и escalations.
  8. Храните старую policy как rollback target.

Не меняйте одновременно модель, prompt, retrieval и compaction: иначе причину регрессии невозможно изолировать.

Production-чек-лист управления контекстом

Перед запуском
  1. Usable input рассчитан с резервом.
  2. У каждого слоя есть приоритет и cap.
  3. Policy не подвергается summary.
  4. Task state типизирован и авторитетен.
  5. Recent dialogue ограничен отдельно.
  6. Retrieval имеет access scope и provenance.
  7. Tool outputs минимальны.
  8. Compaction schema версионируется.
  9. Critical facts проверяются по source.
  10. Truncation создаёт наблюдаемое событие.
  11. Context manifest сохраняется в trace.
  12. Cache условия и retention проверены.
  13. Long-session evals включены в CI.
  14. Canary и rollback policy готовы.
Что такое управление контекстом LLM?
Это контролируемая сборка input для каждого модельного вызова: выбор инструкций, состояния задачи, истории, evidence и tool results в пределах токен-бюджета с правилами приоритета, сжатия и проверки.
Зачем сжимать контекст, если окно модели очень большое?
Большой input увеличивает стоимость и задержку и добавляет шум. Кроме того, нужно резервировать место под output и tools. Важна не максимальная загрузка, а task success при минимально достаточном контексте.
Чем summary отличается от памяти агента?
Summary - производное представление диапазона событий с provenance. Память - отдельное хранилище разрешённых устойчивых фактов с областью доступа, TTL и lifecycle. Не каждый элемент summary должен становиться памятью.
Можно ли просто удалять самые старые сообщения?
Для некритичного чата иногда можно, но в workflow так теряются решения и approvals. Надёжнее вынести их в typed state, оставить свежий sliding window и сжимать остальное по явной schema.
Как распределить token budget?
Сначала вычтите резерв под output, tools и safety margin, затем гарантируйте место policy и task state. Остаток распределите между recent dialogue и retrieved evidence по измерениям на eval-наборе.
Что даёт prompt caching?
Он позволяет переиспользовать обработку стабильного префикса и может снижать стоимость или задержку. Он не увеличивает контекстное окно и не заменяет retrieval, compaction или проверку релевантности.
Как проверить качество compaction?
Используйте длинные сценарии с известными фактами, решениями, отрицаниями и конфликтами. Измеряйте preservation recall, unsupported carryover, task success после нескольких сжатий и устойчивость к injection.
Какие данные сохранять для расследования?
Context manifest с версиями policy, state, summaries, chunk IDs, token usage и причинами исключения. Полные payload храните только по правилам безопасности и retention, с redaction и контролем доступа.
← Все статьи блога