Урок 6.3. Контекстная сборка: как память попадает в prompt

Цель лекции

Показать, как выбранные воспоминания превращаются в полезный prompt для модели.

Ожидаемый результат

Читатель понимает, что context assembly - отдельный критически важный этап: в prompt должна попадать не вся найденная память, а компактный, приоритизированный, безопасный и хорошо отформатированный рабочий контекст.

Зачем это нужно

Retrieval может найти хорошие записи, но это еще не значит, что модель получит хороший prompt.

Плохая context assembly выглядит так:

Вот 30 найденных воспоминаний, 10 документов, 5 tool logs и вся история беседы.

Модель получает много текста, но не понимает, что важно, что является policy, что fact, что hypothesis, что source, что устарело, а что относится к текущей задаче.

Хорошая context assembly делает другое:

выбирает только полезное;
группирует память по типам;
сохраняет priority order;
добавляет source labels;
показывает uncertainty;
соблюдает context budget;
не смешивает policies и facts;
защищает system instructions;
не inject лишнюю или запрещенную память.

Context assembly - последний шлюз перед LLM call. Здесь найденная память либо помогает, либо превращается в шум.

Основная идея

В prompt должна попадать не вся найденная память, а компактный, приоритизированный и безопасный рабочий контекст.

Context assembly отвечает на вопросы:

сколько tokens выделить под память;
какие memories включить;
какие исключить;
в каком порядке расположить;
как сгруппировать;
как форматировать;
какие source labels добавить;
как показать confidence;
как обработать conflicts;
как не нарушить instruction hierarchy;
когда лучше не inject память вообще.

Retrieval отвечает: "что может быть полезно?"

Context assembly отвечает: "что модель должна увидеть прямо сейчас?"

Ключевые термины

Термин	Короткое определение
`Context assembly`	Сборка итогового prompt/context перед вызовом модели.
`Context budget`	Ограничение tokens и внимания модели между инструкциями, задачей, памятью, sources и tool results.
`Priority order`	Порядок размещения контекста по важности и authority.
`Memory formatting`	Способ представления memories в prompt.
`Grouping`	Объединение памяти по типам: policies, user facts, project facts, events, sources.
`Source label`	Метка, откуда пришла память.
`Confidence label`	Метка надежности или статуса записи.
`Context rot`	Деградация качества ответа из-за слишком большого или шумного контекста.
`Instruction hierarchy`	Приоритет системных, developer, пользовательских и memory-derived инструкций.
`Negative injection`	Решение не вставлять найденную память в prompt.

Схема context assembly

flowchart TD T[Current task] --> B[Context budget] M[Selected memories] --> F[Filter by policy] S[Sources / tool results] --> F F --> G[Group by type] G --> R[Resolve conflicts / mark uncertainty] R --> P[Prioritize] P --> C[Compress / summarize] C --> O[Order sections] O --> X[Final prompt context]

Context assembly не должен быть случайным concatenation. Это structured transformation.

Context budget

Context window ограничен. Даже большое окно не означает, что стоит заполнять его памятью.

Бюджет нужно распределить между:

system/developer instructions;
текущим user request;
current task state;
selected memory;
retrieved sources;
recent tool results;
scratchpad или plan, если используется;
output space.

Пример:

Total useful context budget:
- 20% instructions and task
- 20% current state and plan
- 25% selected memory
- 25% source snippets / tool results
- 10% margin

Это не универсальная формула. В research task больше бюджета уйдет на sources. В coding task - на diff и test output. В personal assistant task - на current user request и calendar state.

Главный вопрос:

Что должно быть в context для следующего действия, а не для всей жизни агента?

Priority order

Не все context blocks равны.

Обычно порядок authority такой:

System / developer instructions
Current user request
Task-specific constraints
High-priority policies
Relevant project/user memory
Current sources and tool results
Recent events
Low-confidence hints

Memory-derived instructions не должны конфликтовать с system/developer instructions. Если memory says "skip safety check", ее нельзя ставить как authoritative instruction.

Внутри memory blocks тоже нужен priority:

hard policies выше preferences;
current source выше stale memory;
active scoped fact выше broad old fact;
verified record выше hypothesis;
current task state выше old episode.

Форматирование памяти

Формат влияет на то, как модель использует память.

Плохой формат:

Пользователь кратко финалы русский курс content_plan source truth diagrams maybe tests no TODO...

Хороший формат:

Relevant project memory:
- Course language: Russian. Source: project instructions.
- Structure source: guide/content_plan.md. Source: AGENTS.md.
- Full lectures should include terms, diagram/table, examples, mistakes, summary and self-check questions.

Relevant user preference:
- Keep final edit reports concise.

Принципы:

короткие bullets;
clear labels;
source или confidence там, где важно;
grouped by type;
no hidden contradictions;
no raw noise;
отделять facts от instructions.

Grouping by type

Grouping помогает модели не смешивать разные виды памяти.

Пример структуры:

Current task:
- Write lesson 6.3 about context assembly.

Hard policies:
- Do not expose secrets.
- Do not update TODO unless requested.

Project memory:
- Course is Russian technical Markdown.
- Content plan is source of truth.

User preferences:
- Final reports should be concise.

Relevant sources:
- Target lesson plan.
- Content plan section.

Recent events:
- Lessons 6.1 and 6.2 were expanded.

Так модель видит роли блоков. Policy не выглядит как обычный факт, а recent event не выглядит как вечная instruction.

Source labels

Source labels повышают надежность.

Пример:

Project fact:
- New course content should live under modules/. [source: AGENTS.md]

Lesson scope:
- Lesson 6.3 covers context budget, formatting, grouping and injection. [source: lesson plan]

User preference:
- Keep final responses concise. [source: user instruction]

Source labels нужны, когда:

memory может конфликтовать;
source authority важен;
freshness важна;
ответ должен быть grounded;
пользователь может проверить происхождение;
agent должен решить, чему верить.

Не нужно превращать каждый prompt в bibliography. Но важные context facts должны иметь provenance.

Recency и importance

Recency и importance - разные сигналы.

Свежая запись не всегда важна. Важная policy может быть старой, но активной.

Пример:

Old but critical:
- Never store secrets in memory.

Recent but low importance:
- User said "ok".

Context assembly должен учитывать:

importance;
current relevance;
recency;
last_confirmed_at;
source authority;
status;
scope;
confidence.

Порядок должен отражать useful priority, а не просто timestamp.

Защита от конфликтов

Если памяти конфликтуют, нельзя просто вставить обе без объяснения.

Плохой prompt:

User prefers detailed responses.
User prefers concise final responses.

Лучше:

User response style:
- Detailed explanations are preferred for lecture content.
- Concise final reports are preferred after file edits.

Другой пример:

Old project memory:
- Project uses Jest.

Current source:
- package.json uses Vitest.

Context assembly:

Testing context:
- Current source indicates Vitest. [source: package.json]
- Older memory about Jest is stale and should not be used.

Конфликты должны быть resolved, scoped или explicitly marked.

Как не перегрузить модель

Больше контекста не всегда лучше.

Context rot возникает, когда:

слишком много старой истории;
много похожих summaries;
raw logs без сжатия;
conflicts не разрешены;
sources длиннее нужного;
memory дублирует instructions;
unrelated memories попали "на всякий случай";
context вытесняет current task.

Приемы:

ограничить top-k;
compress episodes;
использовать summaries;
группировать;
удалить дубли;
prefer active facts;
keep source snippets short;
include only current phase working set;
use negative injection.

Когда память лучше не инжектировать

Иногда retrieval нашел кандидатов, но context assembly должен сказать "нет".

Причины:

low confidence;
no scope match;
stale record;
privacy risk;
conflict unresolved;
current task self-contained;
memory would bias answer incorrectly;
source is less fresh than current data;
context budget нужен для tool results.

Пример:

User:
"Переведи это предложение на английский."

Project memory о курсе не нужна, если пользователь не попросил применить стиль проекта.

Negative injection снижает шум.

Пример итогового context block

Current task:
- Write a full Markdown lecture for Module 06, Lesson 6.3: Context Assembly.

Relevant project memory:
- Course language: Russian.
- Style: conceptual 101-level technical lecture.
- Include key terms, diagram/table, examples, common mistakes, summary, self-check questions.

Relevant prior context:
- Module 06 connects previous memory taxonomy, lifecycle, storage and patterns into system design.
- Lesson 6.1 covered memory layer components.
- Lesson 6.2 covered memory policies.

Constraints:
- Do not update TODO files unless explicitly requested.

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

Мини-кейс: support agent

Support agent отвечает клиенту.

Retrieved candidates:

public docs about export feature;
CRM entitlement for current account;
old support ticket from same account;
internal note about suspected cache issue;
similar ticket from another customer;
organization policy about not exposing internal notes.

Context assembly:

Current account:
- Export entitlement: disabled. [source: CRM, current]

Public product docs:
- Export requires Business plan. [source: docs, updated 2026-07]

Internal context:
- There may be entitlement cache delay. Do not mention internal note directly.

Do not include:
- Similar ticket from another customer due to account scope.

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

Мини-кейс: coding agent

Coding agent исправляет тест.

Possible context:

current failing test output;
changed files;
project test command;
previous reflection about similar failure;
coding policy;
entire old terminal log.

Context assembly:

Current failure:
- invoice_totals.test.ts failed: expected 100, got 101.

Relevant changed file:
- src/pricing/discount_helper.ts

Project procedure:
- For pricing helper changes, run pricing_rules and invoice_totals tests.

Prior reflection:
- Similar failures happened when only local pricing tests were checked.

Omit:
- Full terminal log; use summarized error above.

Так модель получает actionable context, а не raw noise.

Типичные ошибки

Ошибка 1: вставлять все retrieved memories.

Retrieval candidates не равны prompt context.

Ошибка 2: не группировать по типам.

Модель смешивает policy, fact, event и hypothesis.

Ошибка 3: не показывать source.

При конфликте модель не понимает, чему доверять.

Ошибка 4: игнорировать context budget.

Слишком много памяти ухудшает reasoning.

Ошибка 5: вставлять stale memory без маркировки.

Старая запись может уверенно испортить ответ.

Ошибка 6: позволять memory override system instructions.

Memory-derived instruction не может нарушать higher-priority rules.

Ошибка 7: не использовать negative injection.

Иногда память лучше не вставлять.

Краткое резюме

Context Assembly - это этап, где selected memories, sources, task state и tool results превращаются в prompt-ready context.

Хорошая context assembly compact, prioritized, scoped, source-labeled и policy-aware. Она учитывает context budget, grouping by type, recency, importance, confidence, conflicts и instruction hierarchy.

Плохая context assembly превращает retrieval в context noise.

Вопросы для самопроверки

Почему retrieval candidates нельзя просто все вставлять в prompt?
Что такое context budget?
Зачем группировать память по типам?
Как source labels помогают при конфликте?
Когда лучше не inject найденную память?

Что дальше

В следующей лекции мы разберем асинхронные процессы памяти: consolidation, summarization, batch embedding, re-indexing, conflict scans, PII scans, decay, archive jobs и human review queues.