Компоненты контекста

Короткая версия

Шесть основных компонентов контекста:

Запрос: «Почему заказ задерживается?»

Контекст:
- instructions: support policy
- retrieval: краткая статья о сроках доставки
- state: последние 2 сообщения
- memory: язык и тип аккаунта
- tool result: order_status=pending_carrier
- output constraint: JSON для support UI

Что чаще всего путают

• retrieval и tool results не одно и то же;
• conversation state и memory не одно и то же;
• output constraints тоже часть контекста, а не отдельная тема “после prompt engineering”;
• runtime metadata полезны, но это скорее вложенный вспомогательный слой, а не самостоятельная большая категория наравне с retrieval или tools.

1. Instructions

Instructions — это system prompt, policy blocks, guardrails и output-level указания. Они отвечают за то, как модель должна себя вести.

Сюда обычно входят:

• роль модели;
• стиль и тон;
• правила uncertainty и refusal;
• запреты и policy boundaries;
• format hints и safety contract.

Этот слой чаще всего:

• наиболее стабилен между запросами;
• должен быть коротким и непротиворечивым;
• хорошо подходит для prompt caching.

2. Retrieval

Retrieval нужен тогда, когда модель должна опираться на ваши внешние знания, а не только на pretraining.

Типичные источники:

• help center;
• policy docs;
• product catalog;
• codebase fragments;
• tickets, contracts, SOPs.

Практически retrieval отвечает за два вопроса:

1. Какие именно документы нужно подмешать в текущий вызов?
2. Сколько retrieved context реально стоит включать?

Ключевая мысль: retrieval полезен не количеством найденных chunks, а их relevance contribution.

3. Conversation State

Conversation state — это рабочее состояние текущего диалога. Не “вся история навсегда”, а то, что нужно модели прямо сейчас для continuity.

Обычно сюда входят:

• последние сообщения;
• активная задача;
• открытые вопросы;
• текущая стадия workflow;
• последний важный tool result.

Если история длинная, healthy pattern почти всегда такой:

• свежие turns передаются как есть;
• старые turns compact-ятся в summary/state object;
• мусорные или завершённые ветки выкидываются.

4. Durable Memory

Durable memory хранит факты, которые живут дольше одной сессии.

Примеры:

• предпочтительный язык;
• имя или роль пользователя;
• account tier;
• постоянные предпочтения по output;
• важные long-term facts.

Memory отличается от conversation state так:

Если смешать их в один слой, вы быстро получите либо перегруженный context, либо потерю continuity.

5. Tool Results

Tool results — это live data, полученные от систем во время выполнения: API, database, search, calculators, workflow tools.

Они отличаются от retrieval тем, что:

• retrieval обычно подмешивается до ответа;
• tool results возникают в ходе выполнения или после tool call;
• tool results чаще всего более “grounded”, потому что это свежий structured output системы.

Типовые примеры:

• статус заказа;
• баланс и billing events;
• SQL aggregation;
• web search results;
• результат browser/computer action.

6. Output Constraints

Output constraints — это JSON schema, structured outputs, strict tool arguments, UI contracts и другие формальные ограничения на то, в каком виде модель должна вернуть результат.

Этот слой часто недооценивают, хотя он критичен для:

• automation;
• agent loops;
• frontend rendering;
• data extraction;
• machine-readable responses.

Без него модель может “понять задачу правильно”, но вернуть ответ в форме, которую приложение не сможет использовать.

7. Куда деть дату, язык, timezone и прочие метаданные

Runtime metadata никуда не исчезли. Просто в зрелой taxonomy их полезнее считать не отдельным огромным компонентом, а вспомогательным атрибутом внутри других слоёв:

• дата и timezone часто живут рядом с instructions;
• язык пользователя может приходить из durable memory;
• session flags могут быть частью conversation state;
• locale и UI-mode могут входить в output contract.

Это делает контекст чище и помогает не создавать искусственный “седьмой слой”, который на деле редко является главным носителем смысла.

8. Как эти компоненты работают вместе

Обычно здоровая последовательность такая:

1. Instructions задают рамку.
2. Retrieval даёт внешние знания.
3. Conversation state держит текущую continuity.
4. Durable memory добавляет долгоживущие user facts.
5. Tool results приносят свежие данные.
6. Output constraints фиксируют форму результата.

Это не универсальные проценты, а mental model: разные слои выполняют разные функции, и у каждого должен быть собственный budget и priority.

Простой layered assembler

from dataclasses import dataclass, field


@dataclass
class ContextLayers:
    instructions: str
    retrieval: list[str] = field(default_factory=list)
    recent_messages: list[dict] = field(default_factory=list)
    memory_facts: list[str] = field(default_factory=list)
    tool_results: list[dict] = field(default_factory=list)
    output_contract: str | None = None


def build_messages(layers: ContextLayers) -> list[dict]:
    system_parts = [layers.instructions]

    if layers.memory_facts:
        system_parts.append(
            "Known facts:\n- " + "\n- ".join(layers.memory_facts)
        )

    if layers.output_contract:
        system_parts.append(
            f"Output contract:\n{layers.output_contract}"
        )

    messages = [
        {"role": "system", "content": "\n\n".join(system_parts)}
    ]

    if layers.retrieval:
        messages.append(
            {
                "role": "system",
                "content": "Retrieved context:\n\n"
                + "\n\n---\n\n".join(layers.retrieval[:4]),
            }
        )

    messages.extend(layers.recent_messages[-4:])

    for result in layers.tool_results[-2:]:
        messages.append(
            {"role": "tool", "content": str(result)}
        )

    return messages

Смысл этого кода не в синтаксисе, а в разделении слоёв:

• retrieval не прячется внутри instructions;
• memory не смешивается с transcript-history;
• tool results ограничиваются по объёму;
• output contract живёт отдельно от business facts.