# Модель знает только то, что в окне Экспресс-курс об инженерии контекста — дисциплине собирать ровно нужный текст в окно контекста модели. 18 понятий — Stateless Model, Context Window, Context Engineering, System Prompt, Few-shot, Context Dilution, Context Budget, Context Rot, Compaction, Context Evals и другие — у каждого английское название, схема, карточка и пример. В конце — шпаргалка по всем понятиям на одной странице. - **Author:** Фёдор Чищин - **Level:** intermediate - **Reading time:** ~35 минут чтения - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/ru/learn/context-engineering-express --- ## 1. Окно — это всё, что она знает Всё в этом курсе следует из одного факта о том, как работает языковая модель: у неё нет памяти, и вся её осведомлённость в любом вызове — это текст, что ты ей шлёшь. Пойми это, и остальное очевидно. ### Карта: 18 понятий в семи группах > Карта метро: сначала видишь линии целиком, потом едешь по станциям. Курс идёт по семи группам. Сначала — **окно**: что модель вообще знает. Потом — **сдвиг** от формулировки промпта к сборке контекста. Дальше — **из чего собрано окно**, и три силы, которые его портят: **нерелевантность**, **бюджет** и **гниение со временем**. В конце — **практика**: строить окно нарочно и мерить результат. _Diagram: Семь групп понятий — по ним идут главы 1–7._ ### Как читать каждое понятие > Паспорт: одинаковые поля у всех, поэтому их легко сравнивать. У каждого понятия дальше одно и то же: **английское название** (запомни его — так это называют в документации и статьях), образ из жизни, **схема** и **карточка** с полями вроде _проблема_, _идея_, _пример_, _цена_ и _связи_. Главная мысль курса: **качество LLM решается тем, что ты кладёшь в окно, а не хитрой формулировкой.** ### Stateless Model — модель не помнит ничего между вызовами > Блестящий консультант с полной амнезией — на каждой встрече ты заново вручаешь ему все документы, потому что с прошлого раза он не помнит ничего. Языковая модель **без состояния** — это и есть понятие **Stateless Model**: она не держит ничего между запросами. Иллюзия чат-бота, что помнит твой разговор, — это просто вся история, переотправляемая каждый раз. Сама модель стартует с чистого листа в каждом вызове, зная лишь то, что прямо перед ней. Так что «что модель знает?» — это никогда не про модель, а целиком про то, что ты выбрал включить на этот раз. _Diagram: Stateless: в каждом вызове приложение заново шлёт всю историю. «Память» чат-бота живёт в твоём коде, а не в модели._ #### Stateless Model (модель без состояния) - **Что это:** Модель не хранит ничего между запросами: каждый вызов — с чистого листа. - **Как работает:** Чат «помнит» разговор только потому, что приложение заново отправляет всю историю в каждом вызове. - **Пример:** Третий вопрос в чате уходит в модель вместе с первыми двумя вопросами и двумя ответами. - **Подвох:** Ждать, что модель «помнит» правило из прошлой сессии, — если его нет в этом вызове, его нет. - **Связи:** Поэтому всё решает **Context Window**; растущая история ведёт к **Context Budget** и **Context Rot**. ### Context Window — её единственная рабочая память > Работник, что может действовать только по заметкам, приколотым к доске перед ним, — сотри доску, и будто ничего и не было. **Окно контекста** (**context window**) — это блок текста, что модель видит в вызове: твои инструкции, разговор, любые данные, инструменты. Это вся её рабочая память, и у него конечный размер. Если факта, правила или прошлого сообщения нет в окне, модель его просто не знает. Всё, о чём модель может рассуждать, она рассуждает из окна — что делает окно тем, что ты на самом деле инженеришь. _Diagram: Окно — это всё, что видит модель. То, что лежит снаружи (старый чат, вики компании, забытое правило), для неё не существует._ #### Context Window (окно контекста) - **Что это:** Весь текст, который модель видит в одном вызове: инструкции, история, данные, инструменты. - **Как работает:** Модель рассуждает только из окна. У окна есть максимальный размер в токенах. - **Пример:** Бот поддержки не знает правил возврата, если их текст не положили в окно этого вызова. - **Подвох:** «Модель должна это знать» — нет: если этого нет в окне, для модели этого нет. - **Связи:** Окно собирают через **Context Assembly**; его размер — это **Context Budget**. ### Так что качество решается тем, что ты кладёшь > Гений, отвечающий только из той единственной папки, что ты ему вручил, — дай нужную папку, и ответ блестящ; дай не ту, и он уверенно бесполезен. Поскольку модель работает только из окна, качество её вывода в основном решается _до_ того, как модель запустится, — тем, что ты собрал. Одна и та же модель даёт отличный ответ или безнадёжный целиком в зависимости от того, был ли нужный контекст перед ней. Это переосмысляет всю работу: ты не выманиваешь интеллект из модели, ты **курируешь то, что ей дают увидеть.** Это курирование и есть инженерия контекста. _Diagram: Та же модель: с нужным контекстом — отличный ответ, без него — уверенно бесполезный. Рычаг — вход, а не модель._ > **Вопрос рамки:** «Всё ли, что нужно модели, чтобы ответить хорошо, реально в окне прямо сейчас — или я жду, что она будет знать то, что я ни разу перед ней не положил?» > Модель без состояния и знает только своё окно контекста. Качество вывода решается тем, что ты собираешь в это окно, — так что окно, а не модель, ты и инженеришь. ## 2. Промпт против контекста Люди говорят об «инженерии промптов», но по мере того как приложения становятся серьёзными, настоящее ремесло переезжает в другое место — от формулировки запроса к сборке нужной информации вокруг него. Этот сдвиг — сердце курса. ### Prompt Engineering vs Context Engineering — формулировка против сборки > Юрист побеждает не хитрой фразой, а вручая судье ровно нужные документы, в нужном порядке, без ничего лишнего, — дело в бумагах, а не в речи. **Инженерия промптов** (**prompt engineering**) — это про то, как ты формулируешь инструкцию. **Инженерия контекста** (**context engineering**) — бо́льшая работа: собрать _всю_ информацию, что нужна модели, — нужные факты, историю, примеры, инструменты — в окно на каждый вызов. По мере роста приложений формулировка значит меньше, а сборка — больше. Большинство моментов «AI дал плохой ответ» — это не плохая фраза, а модель, которой не хватило контекста, что ей ни разу не дали. _Diagram: Prompt engineering — одна часть окна (формулировка). Context engineering — все входы, собранные на каждый вызов._ #### Context Engineering (инженерия контекста (против prompt engineering)) - **Проблема:** Качество «подкручивают» формулировкой промпта, а модели не хватает самих фактов. - **Идея:** Инженерить всё окно: системные правила, факты, историю, примеры, инструменты — на каждый вызов. - **Пример:** Вместо «ответь подробно и точно!» — положить в окно нужный документ и ключевое правило. - **Цена:** Нужен код, который собирает окно, и дисциплина решать, что входит. - **Когда брать:** Как только LLM-фича выходит за пределы одного демо-промпта. - **Связи:** Prompt engineering — его часть; на практике это **Context Assembly** и **Deliberate Assembly**. ### Missing Context — большинство проблем качества это проблемы контекста > Ассистент, что даёт неверный ответ, потому что ты забыл упомянуть одно ограничение, что меняло всё, — не глупый, просто неосведомлённый. Когда LLM-фича недорабатывает, инстинкт — подкрутить формулировку промпта или винить модель. Куда чаще настоящая причина — **отсутствующий или неверный контекст** (**missing context**): нужный документ не извлёкся, ключевое правило не включили, устаревшая история запутала. Прежде чем что-то переформулировать, спроси, что у модели реально было перед ней. Починка контекста чинит больше багов, чем починка формулировки когда-либо. _Diagram: Плохой ответ? Инстинкт — переписать промпт. Правильный первый шаг — посмотреть, что было в окне: документ не извлёкся, правило не включили, история устарела._ #### Missing Context (нехватка или ошибка контекста) - **Проблема:** Модель отвечает плохо, и команда переписывает промпт снова и снова — без толку. - **Идея:** Сначала смотреть, что было в окне на плохом вызове, и только потом трогать формулировку. - **Пример:** Бот советует старый тариф: в окне лежала устаревшая история, а нового прайса не было. - **Типичные причины:** Документ не извлёкся, правило не включили, устаревшая история запутала. - **Связи:** Лечится **Context Assembly** и **Curation**; проверяется **Context Evals**. ### Модель хороша ровно настолько, насколько её вход > Лучший повар может готовить только из ингредиентов на столе — вручи ему не те, и мастерство не спасёт блюдо. Способная модель с плохим контекстом проигрывает слабой модели с отличным контекстом. Поэтому инженерия контекста, а не выбор модели, обычно самое рычажное место тратить усилия: вывод той же модели дико колеблется с тем, что ты ей скармливаешь. Ты не получаешь ответ лучше, требуя сильнее, — ты получаешь его, кладя в окно лучший, острее, релевантнее материал. Вход — это рычаг. > **Вопрос ремесла:** «Я пытаюсь починить это переформулировкой промпта — когда настоящая проблема в том, какая информация попала или не попала в контекст?» > Инженерия промптов — это формулировка; инженерия контекста — это сборка нужной информации. Вторая — где живёт качество, а большинство плохих ответов это нехватка контекста, а не плохая фраза. ## 3. Системный промпт и примеры Часть того, что идёт в окно, долговечна, а часть — на каждый запрос, и несколько конкретных ингредиентов делают бо́льшую часть работы. Знать, что это, делает сборку контекста конкретной. ### System Prompt — постоянное поведение против разового запроса > Постоянная политика ресторана — «мы вегетарианские, закрываемся в десять» — против конкретного заказа на сегодня. Одно обрамляет всё; другое — это просьба. **Системный промпт** (**system prompt**) держит долговечные инструкции, что применяются ко всему взаимодействию: роль модели, правила, которым следовать, тон, формат вывода. **Пользовательское сообщение** (**user message**) — это конкретный запрос. Положить персону, guardrails и постоянные правила в системный промпт держит их стабильными, пока вопросы пользователя меняются. Это разница между тем, кто модель _есть_ в каждом вызове, и тем, о чём её просят _в этот_ раз. _Diagram: Системный промпт одинаков в каждом вызове (роль, правила, тон, формат). Пользовательское сообщение меняется каждый раз._ #### System Prompt (системный промпт vs user message) - **Что это:** Долговечные инструкции на всё взаимодействие: роль, правила, тон, формат вывода. - **Против чего:** **User message** — конкретный запрос этого раза. - **Пример:** Система: «Ты бот поддержки магазина, отвечай кратко, не обещай скидок». Пользователь: «Где мой заказ?» - **Подвох:** Смешать постоянные правила с запросом — и они будут «плавать» от вопроса к вопросу. - **Связи:** Первый кусок в **Context Assembly**; формат вывода часто лучше показать через **Few-shot**. ### Few-shot Prompting — покажи, а не только скажи > Научить кого-то формату, показав три готовых примера, быстрее и яснее, чем описывать словами и надеяться, что он верно вообразит. Часто самый надёжный способ получить нужную форму вывода — **включить пару примеров** ввода и идеального вывода прямо в контекст. Это паттерн **few-shot prompting**. Модель сопоставляет примеры по шаблону куда лучше, чем следует абстрактному описанию. Два-три острых примера могут побить абзац инструкций, и они часто самая быстрая починка, когда модель _почти_ делает то, что ты хочешь, но не совсем. _Diagram: Слева — описать формат словами и получить «почти то». Справа — показать пары «вход → идеальный выход», и новый вход получает ту же форму._ #### Few-shot Prompting (обучение на примерах в контексте) - **Проблема:** Модель почти делает нужное, но форма вывода «плывёт». - **Идея:** Положить в окно 2–3 пары «вход → идеальный выход» — модель повторит шаблон. - **Пример:** Три примера «отзыв → JSON с тональностью и темой», потом новый отзыв — и ответ в том же JSON. - **Цена:** Примеры занимают токены в каждом вызове — это часть **Context Budget**. - **Когда брать:** Когда важна форма, а абзац инструкций не помогает. - **Связи:** Один из кусков **Context Assembly**; дополняет **System Prompt**. ### Context Assembly — собирай окно из частей > Упаковать портфель на встречу: повестка, два релевантных отчёта, заметка об ограничениях — выбрано нарочно, а не весь твой шкаф документов, опрокинутый внутрь. Реальное окно контекста собирается из кусков на каждый вызов: системный промпт, релевантная история, извлечённые факты (**RAG**), примеры, доступные инструменты и наконец запрос пользователя. Это и есть **сборка контекста** (**context assembly**): решать, нарочно и каждый раз, какие куски входят, а какие остаются снаружи. Думать об окне как о том, что ты _строишь_ из частей, а не просто как о промпте, что печатаешь, — вот ментальный сдвиг, после которого всё остальное щёлкает. _Diagram: Твой код на каждый вызов выбирает куски — системный промпт, историю, факты, примеры, инструменты, запрос — и собирает из них окно._ #### Context Assembly (сборка окна из частей) - **Проблема:** Окно — это «просто промпт», и в нём оказывается что попало. - **Идея:** Собирать окно кодом из частей: system prompt, история, RAG-факты, примеры, инструменты, запрос. - **Пример:** Вопрос о заказе: правила бота + последние 3 сообщения + данные этого заказа + вопрос. Без всего каталога. - **Цена:** Каждую часть надо выбрать и обосновать — это работа, а не магия. - **Связи:** Части — **System Prompt**, **Few-shot**; фильтр — **Curation**; привычка — **Deliberate Assembly**. > **Вопрос сборки:** «Каковы части этого окна — системные правила, история, извлечённые факты, примеры, инструменты — и каждая ли тянет свой вес или просто катается за компанию?» > Системный промпт задаёт долговечное поведение; пользовательское сообщение — это запрос; few-shot-примеры показывают нужную форму. Окно собирается из этих частей, нарочно, на каждый вызов. ## 4. Релевантность важнее полноты Крупнейшая ошибка новичка в инженерии контекста — думать, что больше лучше. Верно обратное: каждый нерелевантный токен, что ты добавляешь, активно делает ответ хуже. ### Relevance over Completeness — больше контекста не значит лучше > Брифинг в одну острую страницу бьёт свалку в 200 страниц — читатель находит сигнал вместо того, чтобы в нём тонуть, и решает быстрее и лучше. Соблазнительно напихать в окно всё возможно релевантное «на всякий случай». Но больше — не лучше, обычно хуже. Принцип **relevance over completeness** — **релевантность важнее полноты**: каждый токен соревнуется за внимание модели, и нерелевантный материал **разбавляет** сигнал. Навык — выбрать те немногие вещи, что важны, а не включить всё, что может. _Diagram: Слева — всё «на всякий случай»: сигнал тонет в шуме. Справа — только то, что нужно этому вызову: острый ответ._ #### Relevance over Completeness (релевантность важнее полноты) - **Проблема:** В окно кладут всё подряд «на всякий случай». - **Идея:** Цель — не дать модели всё, а дать ей ровно достаточно. - **Пример:** Вместо всей базы знаний — три абзаца, которые реально отвечают на этот вопрос. - **Цена:** Нужно уметь отбирать: хороший поиск, обрезка, решения «что выкинуть». - **Связи:** Почему — **Context Dilution**; как — **Curation**; ещё и экономит **Context Budget**. ### Context Dilution — шум поднимает шанс неверного ответа > Спрячь один релевантный факт внутри горы в основном нерелевантной бумаги — и даже внимательный читатель начнёт цитировать не ту страницу: шум сам и вызывает ошибку. Длинный, набитый контекст не просто тратит место; он активно ухудшает качество. Это **разбавление контекста** (**context dilution**): погребённое в нерелевантном материале, внимание модели размазывается, и в длинных контекстах это измеримо **поднимает долю галлюцинаций и ошибок** — она уверенно использует то, что и не задумывалось ответом. Добавление контекста «на всякий случай» может быть ровно тем, что вызывает сбой. Меньше, острее контекст — это надёжнее контекст. _Diagram: Внимание модели размазано по шуму — и она цепляется за то, что рядом, но неверно, а не за нужный факт._ #### Context Dilution (разбавление контекста шумом) - **Что это:** Нерелевантные токены разбавляют внимание модели к нужному сигналу. - **Чем грозит:** В длинных контекстах растёт доля галлюцинаций и ошибок: модель берёт не тот кусок. - **Пример:** В окне 20 похожих документов — модель цитирует соседний договор вместо нужного. - **Подвох:** Контекст «на всякий случай» кажется безвредным — а может быть самой причиной сбоя. - **Связи:** Лечится **Curation**; окно побольше (**Long Context Windows**) его не отменяет. ### Curation — курируй безжалостно под этот вызов > Хороший редактор не добавляет — он режет, вручая тебе лишь те строки, что отрабатывают своё место на этой странице. Дисциплина — **безжалостное курирование** (**curation**): для _этого_ конкретного вызова включи те немногие вещи, что модели правда нужны, и оставь всё остальное снаружи. Это значит извлекать только самые релевантные чанки, обрезать историю до важного, выбрасывать контекст, что сделал своё дело. _Diagram: Воронка курирования: из всего, что может пригодиться, — только верхние чанки, важная часть истории и ничего отработанного._ #### Curation (курирование контекста) - **Проблема:** Окно растёт само: всё, что попало под руку, уходит в модель. - **Идея:** На каждый вызов: только самые релевантные чанки, обрезанная история, ничего отработанного. - **Пример:** Поиск находит 50 кусков, в окно идут лучшие 3; вывод инструмента, который уже разобран, — выбрасывается. - **Цена:** Можно отрезать нужное — поэтому изменения проверяют **Context Evals**. - **Связи:** Воплощает **Relevance over Completeness**; родня **Trim & Summarize** и **Compaction**. > **Вопрос релевантности:** «Каждый ли кусок в этом окне реально релевантен ответу — или я набиваю его „на всякий случай“ и тихо делаю модель хуже?» > Больше контекста — не лучше: нерелевантные токены разбавляют внимание и поднимают галлюцинации. Курируй безжалостно: дай модели ровно то, что нужно этому вызову, и ничего больше. ## 5. Окно — это бюджет Помимо качества, окно — конечный, оплачиваемый ресурс. Относиться к нему как к скудному бюджету, а не бесконечной свалке, — вот что отделяет игрушку от продукта. ### Context Budget — окно конечно, и каждый токен стоит > Чемодан с пределом веса и платой за килограмм — ты пакуешь то, что реально понадобится, а не весь гардероб, потому что есть жёсткий потолок и цена. У окна контекста максимальный размер, и каждый токен в нём стоит **задержки и денег** — бо́льшие контексты медленнее и дороже на каждом вызове. Так что контекст — не свободное место для заполнения; это **бюджет контекста** (**context budget**), который ты тратишь. Фича, что набивает окно на каждый запрос, медленна и дорога в масштабе, ещё до того как страдает качество. Окно — это ресурс для распределения, а не пустота для заполнения. _Diagram: Окно имеет жёсткий потолок, а каждый токен в нём оплачивается задержкой и деньгами — в каждом вызове._ #### Context Budget (бюджет контекста) - **Что это:** Окно — конечный и платный ресурс: потолок по размеру и цена за каждый токен. - **Чем платишь:** Задержкой и деньгами — на каждом вызове, умноженном на трафик. - **Пример:** Фича шлёт в каждый запрос всю историю и весь справочник — медленно и дорого ещё до проблем с качеством. - **Когда думать:** С первого дня, как фича идёт к реальным пользователям. - **Связи:** Тратится с умом через **Trim & Summarize**; не отменяется **Long Context Windows**. ### Trim & Summarize — трать окно на то, что отрабатывает место > Тесный бюджет поездки вынуждает реальные выборы — ты тратишь на то, что важно для поездки, и пропускаешь остальное, и поездка лучше от этой дисциплины. Относиться к окну как к бюджету меняет то, как ты строишь: ты **обрезаешь** (**trim**) историю разговора, **суммируешь** (**summarize**) старые ходы вместо того, чтобы нести их дословно, и извлекаешь только релевантное сейчас, а не всё, что у тебя есть. Каждый токен должен заработать свой слот. Это та же дисциплина, что производительность или кэширование, — трать скудный ресурс нарочно, на то, что реально двигает исход. _Diagram: Восемь ходов дословно → короткое резюме первых шести плюс два последних хода как есть. Меньше токенов, тот же смысл._ #### Trim & Summarize (обрезать и суммировать историю) - **Проблема:** История разговора растёт, и каждый ход едет в окне дословно. - **Идея:** Старые ходы — коротким резюме, свежие — как есть; извлекать только то, что нужно сейчас. - **Пример:** Вместо 40 сообщений чата — резюме «клиент хочет вернуть заказ №…, уже прислал фото» + 2 последних сообщения. - **Цена:** Резюме может потерять деталь — проверяй на эвалах. - **Связи:** Тратит **Context Budget** с умом; в долгих задачах переходит в **Compaction**. ### Long Context Windows — окно побольше не кончает дисциплину > Аренда грузовика побольше не значит, что надо набить его хламом, — больше ёмкости это место для большего числа полезных вещей, а не лицензия перестать паковать аккуратно. Модели продолжают выпускать бо́льшие окна контекста (**long context windows**) — миллион токенов, больше, — и соблазнительно думать, что проблема бюджета уходит. Не уходит. Окно побольше всё равно стоит дороже и медленнее на токен, и, что критично, более полное окно всё равно разбавляет внимание и приглашает ошибки. Больше ёмкости — не разрешение вываливать; это просто больше места, что тебе всё равно надо тратить с умом. Дисциплина курирования окна переживает любой рост размера. _Diagram: Полезного одинаково мало в обоих окнах. Большое окно просто даёт больше места для шума — и за каждый токен всё равно платишь._ #### Long Context Windows (большие окна, 1M+ токенов) - **Что это:** Модели с окнами в миллион токенов и больше. - **Соблазн:** Думать, что раз всё влезает, курировать больше не нужно. - **Пример:** Залить весь репозиторий в окно «потому что влезает» — дорого, медленно, и модель путается. - **Подвох:** Полнее окно — сильнее **Context Dilution** и больше места для **Context Rot**. - **Связи:** Расширяет потолок **Context Budget**, но не отменяет **Relevance over Completeness**. > **Вопрос бюджета:** «Я трачу токены этого окна на то, что правда улучшает ответ, — или наполняю его, потому что есть место, платя задержкой, деньгами и разбавленным вниманием?» > Окно конечно, и каждый токен стоит задержки и денег. Трать его как бюджет — обрезай, суммируй, извлекай только нужное — и не дай окну побольше кончить дисциплину. ## 6. Гниение контекста и дрейф В длинных, многошаговых взаимодействиях контекст не просто лежит — он накапливается и распадается. Управлять этим распадом — самая трудная и важная часть инженерии контекста в масштабе. ### Context Rot — длинные контексты копят устаревшее и противоречивое > Игра в испорченный телефон вдоль длинной цепочки — к концу сообщение тихо мутировало, и все уверенно повторяют что-то слегка неверное. За долгий разговор или многошаговую задачу агента окно наполняется историей: ранние ходы, выводы инструментов, недоделанное рассуждение. Со временем эта куча становится неряшливой — устаревшие факты сидят рядом со свежими, противоречия накапливаются, исходная цель уплывает из фокуса. Индустрия зовёт получающийся распад качества **гниением контекста** (**context rot**): та же модель становится менее надёжной по мере того, как её собственный накопленный контекст становится шумнее. _Diagram: С каждым шагом окно растёт: выводы инструментов, устаревшие факты, противоречия. Цель тонет внизу, надёжность падает._ #### Context Rot (гниение контекста, дрейф) - **Что это:** Распад качества по мере того, как накопленный контекст становится шумнее. - **Как выглядит:** Устаревшие факты рядом со свежими, противоречия, исходная цель уплывает из фокуса. - **Пример:** Агент на 30-м шаге опирается на версию файла, которую сам же переписал на 10-м. - **Подвох:** Окно побольше делает хуже: даёт гнили больше места копиться. - **Связи:** Лечится **Compaction** и **Goal Re-anchoring**. ### Compaction — сжимай по ходу > Хороший конспектист не держит каждое слово долгого совещания — он дистиллирует его до решений и открытых вопросов, неся вперёд вывод, а не транскрипт. Лекарство — активно **сжимать** контекст по мере роста. Это **compaction**: суммировать завершённые шаги в короткое текущее состояние вместо того, чтобы тащить вперёд весь транскрипт, выбрасывать выводы инструментов, как только извлёк важное, держать тугую рабочую сводку, а не сырую историю. Модель несёт вывод, а не каждое слово, что его произвело. Так долгоиграющие агенты остаются связными — они управляют своим контекстом, а не дают ему копиться. _Diagram: Сырой транскрипт (рассуждения + выводы инструментов) сжимается в рабочую сводку: цель, принятые решения, открытые вопросы, текущий шаг._ #### Compaction (сжатие контекста по ходу) - **Проблема:** Долгий агент тащит за собой весь транскрипт и начинает путаться. - **Идея:** Завершённые шаги — в короткое текущее состояние; отработанные выводы инструментов — выбросить. - **Пример:** Вместо 200 строк лога тестов — «тесты падают в `auth.ts`, причина: истёкший токен». - **Цена:** Сжатие может выкинуть важное — сводку надо делать аккуратно. - **Связи:** Продолжение **Trim & Summarize** для агентов; в паре с **Goal Re-anchoring** против **Context Rot**. ### Goal Re-anchoring — переякоривай цель > На долгом, извилистом походе ты регулярно перепроверяешь карту и пункт назначения — иначе дрейфуешь, по одному разумно выглядящему повороту за раз, прочь оттуда, куда метил. За много шагов исходная задача размывается под весом всего, что случилось с тех пор. Так что ты её **переякориваешь** (**re-anchoring**): переформулируй цель и ключевые ограничения в окне на каждом шаге, чтобы модель оставалась нацелена на настоящую мишень, а не дрейфовала с разговором. Окно побольше делает это хуже, а не лучше, — оно даёт дрейфу больше места копиться. Активное управление, а не сырая ёмкость, — вот что держит долгую задачу на курсе. _Diagram: Без якоря каждый шаг выглядит разумно, а сумма уводит в сторону. С якорем цель заново кладётся в окно на каждом шаге._ #### Goal Re-anchoring (переякоривание цели) - **Проблема:** За много шагов цель размывается, и модель дрейфует вместе с разговором. - **Идея:** Заново класть цель и ключевые ограничения в окно на каждом шаге. - **Пример:** Каждый шаг агента начинается с блока «Цель: перенести API на v2, не меняя публичных методов». - **Цена:** Пара строк токенов на шаг — дёшево по сравнению с дрейфом. - **Связи:** Работает вместе с **Compaction**; первая строка рабочей сводки — это цель. > **Вопрос дрейфа:** «В этом длинном взаимодействии окно всё ещё острая, текущая картина цели — или оно сгнило в устаревшее, противоречивое состояние, над которым модель теперь рассуждает?» > Длинные контексты гниют — устаревшее, противоречивое состояние накапливается и качество распадается. Сжимай завершённые шаги в текущую сводку и переякоривай цель, потому что окно побольше лишь даёт дрейфу больше места. ## 7. Применять хорошо Инженерия контекста, сделанная хорошо, — это намеренная сборка, измеренная, как и всё остальное. Вся практика сводится к тому, чтобы строить окно нарочно и проверять, что это помогло. ### Deliberate Assembly — строй окно нарочно, а не случайно > Повар выкладывает блюдо нарочно — каждый элемент помещён по причине — вместо того, чтобы наскрести на тарелку что попало со стола. Ключевая привычка — **намеренная сборка** (**deliberate assembly**): относиться к окну как к тому, что ты _конструируешь_ нарочно. Реши, что держит системный промпт, какую историю оставить или суммировать, что извлечь, какие примеры показать, какие инструменты выставить. Многие LLM-приложения собирают контекст случайно — что попало под руку, то и шлётся. Строить его нарочно, с обоснованной каждой частью, — вот бо́льшая часть того, что отделяет надёжную фичу от флакающей. _Diagram: Случайно — что попало под руку (вся история, все инструменты, старые логи). Нарочно — у каждой части есть решение и причина._ #### Deliberate Assembly (намеренная сборка окна) - **Проблема:** Контекст собирается случайно — и фича работает через раз. - **Идея:** По каждой части принять решение: system prompt, история, извлечение, примеры, инструменты. - **Пример:** Агенту дают 5 нужных инструментов вместо всех 40 — и короткую сводку вместо всей истории. - **Цена:** Время на проектирование окна — окупается надёжностью. - **Связи:** Привычка поверх **Context Assembly**; проверяется **Context Evals**. ### Context Evals — меряй контекст, как меряешь код > Ты не гадаешь, помогло ли изменение, — ты тестируешь. То же и с тем, что кладёшь в окно: ответ стал лучше или хуже, и ты должен знать какой. Изменения контекста — реальные изменения, так что проверяй их: когда подстраиваешь, что идёт в окно — больше примеров, другое извлечение, обрезанная история, — проверь эффект **эвалами** (**evals**), не просто окинь глазом один вывод. Инженерия контекста без измерения — это настройка на ощупь, и так «безобидное» добавление тихо ухудшает качество. Относись к содержимому окна как к тому, что тестируешь, — та же дисциплина, что курс об эвалах. _Diagram: Цикл: поменял контекст → прогнал эвалы → сравнил счёт → оставил или откатил. А не «глянул на один ответ и понадеялся»._ #### Context Evals (эвалы для изменений контекста) - **Проблема:** Изменение окна «на глаз» выглядит лучше — а на деле тихо ухудшило качество. - **Идея:** Каждое изменение контекста — прогон на фиксированном наборе тестов и сравнение счёта. - **Пример:** Обрезали историю до 5 сообщений — прогнали 100 тестовых диалогов и увидели, стало лучше или хуже. - **Цена:** Нужно собрать набор тестов и гонять его — это работа. - **Связи:** Проверяет **Curation**, **Trim & Summarize**, **Compaction**; подробно — курс об эвалах. #### Прежде чем выкатывать LLM-фичу - **Всё ли, что нужно модели, в окне** — или ты ждёшь, что она будет знать то, что ты ей не дал? - **Системное против пользовательского** — долговечные правила в системном промпте, запрос в пользовательском сообщении? - **Помогут ли примеры** — это случай, где few-shot бьёт больше инструкций? - **Каждый ли кусок релевантен** — или набивка разбавляет внимание и поднимает ошибки? - **В бюджете ли ты** — обрезаешь и суммируешь, а не вываливаешь всё? - **Для долгих задач — сжимаешь ли и переякориваешь ли** против гниения контекста? #### Признаки, что ты инженеришь контекст хорошо - Ты чинишь плохие ответы, **проверяя, что в окне**, прежде чем переформулировать промпт. - Долговечные правила живут в **системном промпте**; ты тянешься к **few-shot-примерам**, когда важна форма. - Ты **курируешь безжалостно** — релевантность важнее полноты — вместо набивки окна. - Ты относишься к окну как к **бюджету**, обрезая и суммируя, а не вываливая. - Для долгих задач ты **сжимаешь и переякориваешь** и **меряешь** изменения контекста вместо гадания. ### Как всё связано > Схема метро целиком: теперь видно, где линии пересекаются. Модель без состояния → значит, всё решает окно → значит, окно надо инженерить. Окно собирается из частей (системный промпт, примеры, факты). Три силы его портят: **нерелевантность**, **бюджет** и **гниение со временем**. У каждой — своя практика: **курирование**, **обрезка и резюме**, **сжатие с переякориванием**. А **эвалы** проверяют, что каждое изменение помогло. _Diagram: Цепочка понятий курса: от модели без состояния к инженерии окна, три силы, что его портят, практики против них и эвалы как проверка._ ## Шпаргалка: все 18 понятий ### Окно - **Stateless Model** (модель без состояния): Ничего не помнит между вызовами; «память» чата — это переотправка истории. - **Context Window** (окно контекста): Весь текст вызова — единственная рабочая память модели. Нет в окне — нет вообще. ### Сдвиг - **Context Engineering** (против prompt engineering): Не формулировка запроса, а сборка всей нужной информации в окно. - **Missing Context** (нехватка контекста): Большинство плохих ответов — не плохая фраза, а то, чего не было в окне. ### Сборка окна - **System Prompt** (vs user message): Долговечные роль, правила, тон, формат — против разового запроса. - **Few-shot Prompting** (примеры в контексте): Покажи 2–3 пары «вход → выход» — модель повторит форму. - **Context Assembly** (сборка из частей): Окно собирается кодом на каждый вызов: правила, история, факты, примеры, инструменты, запрос. ### Релевантность - **Relevance over Completeness** (релевантность важнее полноты): Дать модели не всё, а ровно достаточно. - **Context Dilution** (разбавление шумом): Нерелевантные токены размазывают внимание и поднимают галлюцинации. - **Curation** (курирование): Только лучшие чанки, обрезанная история, ничего отработанного. ### Бюджет - **Context Budget** (бюджет контекста): Окно конечно; каждый токен стоит задержки и денег в каждом вызове. - **Trim & Summarize** (обрезать и суммировать): Старые ходы — резюме, свежие — как есть; каждый токен зарабатывает место. - **Long Context Windows** (окна 1M+ токенов): Больше места — не разрешение вываливать; шум и цена остаются. ### Гниение и дрейф - **Context Rot** (гниение контекста): Долгий контекст копит устаревшее и противоречивое — качество падает. - **Compaction** (сжатие по ходу): Завершённые шаги — в короткую рабочую сводку вместо транскрипта. - **Goal Re-anchoring** (переякоривание цели): Заново класть цель и ограничения в окно на каждом шаге. ### Практика - **Deliberate Assembly** (намеренная сборка): У каждой части окна есть решение и причина — не «что попало под руку». - **Context Evals** (эвалы контекста): Каждое изменение окна проверяется тестами, а не на глаз. > Инженерия контекста — это намеренная сборка окна: нужные правила, нужные факты, нужные примеры, скурированные до релевантности, удержанные в бюджете и управляемые против гниения, — построенные нарочно и измеренные, а не напечатанные и понадеянные. Конец экспресс-курса · 7 глав · 18 понятий Дальше — практика: возьми LLM-фичу, что иногда даёт плохие ответы, и, прежде чем трогать формулировку промпта, залогируй ровно то, что было в окне на плохом вызове, — обычно найдёшь отсутствующий, устаревший или нерелевантный контекст, а не плохую фразу. Потом почини сборку: добавь недостающий факт, вырежь шум, суммируй историю. Дисциплина щёлкает в тот миг, как лучше построенное окно бьёт более хитрый промпт. Но держи одну мысль выше прочих: модель знает только то, что в окне. Перестань выманивать из неё интеллект и начни инженерить то, что ей дают увидеть, — там качество и было всё это время.