Финал кластера 02. Главный сдвиг, после которого ты начнёшь думать про AI-системы как инженер, а не как пользователь. Один тезис: контекст — это не история. И как только это укладывается в голове — все стратегии становятся не «техниками», а инструментами одного и того же выбора.
В Дне 7 ты видел: модель stateless, контекст — это массив, который твой код пересобирает на каждой итерации. В Днях 8-9 — что у этого массива есть цена, окно, ограничения. Сегодня — главная мысль: контекст — это не «история разговора». Контекст — это текущая фотография задачи, которую ты как инженер составляешь специально для модели на этом конкретном шаге. История — лишь одна из её возможных форм. И обычно — не самая лучшая.
Самая частая ошибка начинающего AI-инженера: думать про массив messages как про протокол того, что произошло. Как лог чата. Записываем всё, что было — модель смотрит на полный лог и решает, что делать.
Такая модель работает пока контекст короткий. Как только задача длинная — она начинает разваливаться: дорого, медленно, модель путается в шуме, теряет важное в середине.
Сдвиг, который надо сделать: массив messages — это не история, это твоё сообщение модели «вот что ты сейчас должна знать». Это сконструированная картинка, специально собранная для следующего хода. Она может включать историю — а может быть собрана из совсем других кусков.
Контекст — это не запись прошлого, а конструкция настоящего. Ты не «передаёшь модели историю» — ты проектируешь, какой набор данных и в каком виде она получит на этот ход.
Из этого следует несколько следствий, которые меняют твой способ работать:
messages для текущего хода.Это и есть контекстная инженерия: целенаправленное конструирование того, что модель видит. Не «передача истории», а «проектирование её рабочего пространства».
Когда ты думаешь про контекст как про «что модель должна увидеть», три вопроса задают всю работу:
Не «всё, что было», а что релевантно для текущего шага. Если задача — «составить email клиенту», то модели нужны: текущая цель, имя клиента, контекст переговоров, история переписки с ним. Не нужно: предыдущие задачи, которые мы решали с этим агентом полгода назад.
Это решение ты принимаешь сам — фильтруя то, что у тебя есть в логах, в БД, в памяти, и отбирая подмножество для этого хода.
Один и тот же факт можно подать модели по-разному. «Пользователь предпочитает короткие ответы» можно записать как:
От выбора формы — зависит, насколько серьёзно модель будет это учитывать. Это часть проектирования: ты не просто что сказал модели, но и как подал.
Самая недооценённая часть. Контекст портится не только тем, чего в нём не хватает, но и тем, что в нём лишнее: устаревшие данные, отработавшие гипотезы, мусор от инструментов, длинные размышления, которые уже не нужны.
Контекст-инженер активно выбрасывает. Не из необходимости (окно ещё не заполнено), а потому что чем чище контекст — тем точнее модель работает. Каждый лишний токен — это шум, в котором модель может потеряться.
Эти три вопроса задаются на каждой итерации агента. И ответы могут быть разными — то, что было нужно на 3-м шаге, на 8-м уже мусор.
Теперь, когда у тебя есть концепция «контекст = проектирование», все стратегии из Дня 9 выглядят по-новому. Это не «техники сжатия истории», это разные способы ответить на одни и те же три вопроса.
Это не «вырезаем старое». Это «отвечаем на вопрос: что включить?» — самым простым правилом: «последние N сообщений + system».
Простота — это и сила, и слабость. Работает, когда «релевантно» = «недавно». Не работает, когда важное лежит глубже.
Когда ты понимаешь это как «правило отбора», ты можешь его улучшать: «последние 10 + system + первое user-сообщение», «последние 10 + результаты инструментов помечены как важные».
Это не «пересказываем своими словами». Это «отвечаем на вопрос: в каком виде?» — превращая длинный лог в короткое заявление текущего состояния.
Summary — это не «то же самое, но короче». Это другая форма той же информации. Можно сделать summary в виде «решено: X, Y; открыто: Z; следующий шаг: A» — это уже не пересказ, а структурированное состояние.
Лучшие summary часто не выглядят как «история» — они выглядят как текущее знание: список фактов, состояние, цели.
Это не «свежее детально, старое сжато». Это «признание, что разная информация требует разной формы»: то, что прямо сейчас активно — нужно в подробностях; то, что в фоне — в виде ярлыков и ссылок.
Иерархия — это не способ сэкономить токены. Это модель когнитивного фокуса: модель фокусируется на свежем, помнит общий контекст давнего, может «дотянуться» до деталей если понадобятся (если есть внешняя память).
Поэтому иерархия естественно сочетается с внешней памятью: ярлыки старого + возможность развернуть.
Это не «выносим за пределы контекста». Это «разделяем хранение и активацию»: всё, что когда-либо нужно — хранится снаружи; в контекст попадает только то, что нужно прямо сейчас.
Это самая чистая реализация принципа «контекст ≠ история». История — в файлах, базе, эмбеддингах. Контекст — это выборка из этой истории под текущую задачу.
Об этом — Кластер 03 (память и состояние), Кластер 04 (MCP — инструменты для доступа к внешним данным), Кластер 05 (RAG — конкретная техника выборки).
Когда понимаешь это — больше нет «выбора стратегии». Есть проектирование контекста под задачу, и стратегии становятся инструментами в арсенале. Ты не «применяешь обрезку», ты решаешь, как ответить на три вопроса для своей задачи — и получаешь свою смесь подходов.
В контексте всегда есть две части: инструкции (что модель должна делать) и данные (на чём она это делает). Их смешивание — корень многих проблем.
Хорошее правило: инструкции в system, данные в user/tool. Если ты в user-запросе пишешь «и ещё, всегда отвечай вежливо» — это инструкция, ей не место в user. Перенеси в system. И наоборот: если в system у тебя длинный JSON с данными — вынеси его в user-сообщение, контекстно ближе к запросу.
Это уже упоминалось в Дне 9, но повторим, потому что критично: «рабочий контекст модели» и «лог для тебя как инженера» — это два разных объекта.
Лог — для тебя: разобраться, что модель видела, что решала, почему ошиблась. Сохраняется полностью, в исходном виде, всегда.
Контекст — для модели: то, что в данный момент полезно для решения. Сжимается, фильтруется, обогащается.
Их нельзя совмещать. Если ты выкидываешь из контекста сообщение «ради экономии» — это значит, что для модели его нет; но в логе оно должно остаться, иначе ты не сможешь отлаживать.
Соблазн: «у меня окно 200K, дам модели всё, что есть, пусть сама выберет нужное». Получишь хуже, чем если бы дал ровно нужное. Модель не фильтр, она исполнитель. Чем больше шума в контексте — тем больше она путается, тем больше lost-in-the-middle, тем дороже каждый ход.
Хорошо настроенный агент с 5K контекста часто работает лучше плохо настроенного с 100K. Объём — не показатель качества контекста.
Используешь фреймворк (LangChain, LlamaIndex и т.д.), он сам собирает массив messages, ты не знаешь, что туда попало. Модель ведёт себя странно — а ты не можешь даже сказать, что она увидела.
Привычка: уметь напечатать «вот что сейчас в контексте». Любая абстракция, которая это скрывает — против тебя. Если фреймворк не даёт легко увидеть финальный массив — это не фреймворк, это враг отладки.
«Сначала построю агента, потом подумаю, как с контекстом». Тогда поздно: вся система уже построена на предположении «история передаётся как есть», и переделывать дорого.
Контекстная архитектура — это часть архитектуры с самого начала. Когда проектируешь агента, отдельно задаёшь вопрос: «как у этого агента устроен контекст?» Это решение того же уровня, что и выбор инструментов или модели.
«Я видел, как Cursor / Perplexity / ChatGPT работает, сделаю так же». У них своя задача и свои ресурсы. Их архитектура контекста заточена под их продукт. Слепое копирование без понимания «почему именно так» — приводит к системе, которая внешне похожа, а внутри работает плохо.
Лучшая практика: понять принципы (что-в-каком-виде-что-убрать), и применять их под свою задачу. Архитектура контекста — это инженерное решение, а не паттерн «из учебника».
Кластер 02 — это переход от «модель отвечает» к «модель работает над задачей». Пять уроков, пять слоёв одного навыка:
Следующие три кластера разворачивают этот навык в три практические оси:
Если контекст — это выборка, то откуда? Память: что хранится между сессиями, как структурируется, как извлекается под нужный момент.
Как агент достаёт свежие данные в контекст. Стандартный протокол подключения внешних возможностей. Конкретика к Дню 6.
Из большой базы знаний — в текущий контекст. Конкретные методы: эмбеддинги, реранкинг, цитаты, антигаллюцинации.
Открой Cursor, Claude, ChatGPT, любой AI-инструмент, которым пользуешься. Попробуй понять: что у них в контексте на каждом ходу? Cursor видит весь файл или только активную функцию? Сколько прошлых сообщений видит ChatGPT в долгом чате? Что происходит в Claude, когда упираешься в лимит сообщений? Этот «детективный» взгляд — лучшая тренировка для контекстной интуиции.
Возьми идею AI-агента, который тебе интересен («помощник по подготовке к интервью», «персональный шеф-повар», «ассистент по семейному бюджету»). Расскажи самому себе: какой у него system prompt (1-2 абзаца, опиши)? Какие инструменты? Какие данные подгружаются в контекст под каждый запрос? Что хранится между сессиями? Что обрезается? Этот ответ — и есть архитектура контекста этого агента.
Возьми длинный промпт, который ты когда-то писал ассистенту. Перепиши его, разделив: что должно быть в system (стабильные инструкции и роль), что в user (текущий запрос с данными), что в tool/контекст (опорные факты). Запусти в плейграунде один и тот же запрос «всё в одной user-фразе» vs «разделённый по ролям». Сравни ответы. Это даст ощущение, что форма подачи в контекст так же важна, как и содержание.