Карта: 18 понятий в семи группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Курс идёт по семи группам. Сначала — окно: что модель вообще знает. Потом — сдвиг от формулировки промпта к сборке контекста. Дальше — из чего собрано окно, и три силы, которые его портят: нерелевантность, бюджет и гниение со временем. В конце — практика: строить окно нарочно и мерить результат.

Как читать каждое понятие

Паспорт: одинаковые поля у всех, поэтому их легко сравнивать.

У каждого понятия дальше одно и то же: английское название (запомни его — так это называют в документации и статьях), образ из жизни, схема и карточка с полями вроде проблема, идея, пример, цена и связи. Главная мысль курса: качество LLM решается тем, что ты кладёшь в окно, а не хитрой формулировкой.

Stateless Model — модель не помнит ничего между вызовами

Блестящий консультант с полной амнезией — на каждой встрече ты заново вручаешь ему все документы, потому что с прошлого раза он не помнит ничего.

Языковая модель без состояния — это и есть понятие Stateless Model: она не держит ничего между запросами. Иллюзия чат-бота, что помнит твой разговор, — это просто вся история, переотправляемая каждый раз. Сама модель стартует с чистого листа в каждом вызове, зная лишь то, что прямо перед ней.

Так что «что модель знает?» — это никогда не про модель, а целиком про то, что ты выбрал включить на этот раз.

Context Window — её единственная рабочая память

Работник, что может действовать только по заметкам, приколотым к доске перед ним, — сотри доску, и будто ничего и не было.

Окно контекста (context window) — это блок текста, что модель видит в вызове: твои инструкции, разговор, любые данные, инструменты. Это вся её рабочая память, и у него конечный размер. Если факта, правила или прошлого сообщения нет в окне, модель его просто не знает.

Всё, о чём модель может рассуждать, она рассуждает из окна — что делает окно тем, что ты на самом деле инженеришь.

Так что качество решается тем, что ты кладёшь

Гений, отвечающий только из той единственной папки, что ты ему вручил, — дай нужную папку, и ответ блестящ; дай не ту, и он уверенно бесполезен.

Поскольку модель работает только из окна, качество её вывода в основном решается до того, как модель запустится, — тем, что ты собрал. Одна и та же модель даёт отличный ответ или безнадёжный целиком в зависимости от того, был ли нужный контекст перед ней. Это переосмысляет всю работу: ты не выманиваешь интеллект из модели, ты курируешь то, что ей дают увидеть. Это курирование и есть инженерия контекста.

Prompt Engineering vs Context Engineering — формулировка против сборки

Юрист побеждает не хитрой фразой, а вручая судье ровно нужные документы, в нужном порядке, без ничего лишнего, — дело в бумагах, а не в речи.

Инженерия промптов (prompt engineering) — это про то, как ты формулируешь инструкцию. Инженерия контекста (context engineering) — бо́льшая работа: собрать всю информацию, что нужна модели, — нужные факты, историю, примеры, инструменты — в окно на каждый вызов.

По мере роста приложений формулировка значит меньше, а сборка — больше. Большинство моментов «AI дал плохой ответ» — это не плохая фраза, а модель, которой не хватило контекста, что ей ни разу не дали.

Missing Context — большинство проблем качества это проблемы контекста

Ассистент, что даёт неверный ответ, потому что ты забыл упомянуть одно ограничение, что меняло всё, — не глупый, просто неосведомлённый.

Когда LLM-фича недорабатывает, инстинкт — подкрутить формулировку промпта или винить модель. Куда чаще настоящая причина — отсутствующий или неверный контекст (missing context): нужный документ не извлёкся, ключевое правило не включили, устаревшая история запутала.

Прежде чем что-то переформулировать, спроси, что у модели реально было перед ней. Починка контекста чинит больше багов, чем починка формулировки когда-либо.

Модель хороша ровно настолько, насколько её вход

Лучший повар может готовить только из ингредиентов на столе — вручи ему не те, и мастерство не спасёт блюдо.

Способная модель с плохим контекстом проигрывает слабой модели с отличным контекстом. Поэтому инженерия контекста, а не выбор модели, обычно самое рычажное место тратить усилия: вывод той же модели дико колеблется с тем, что ты ей скармливаешь. Ты не получаешь ответ лучше, требуя сильнее, — ты получаешь его, кладя в окно лучший, острее, релевантнее материал. Вход — это рычаг.

System Prompt — постоянное поведение против разового запроса

Постоянная политика ресторана — «мы вегетарианские, закрываемся в десять» — против конкретного заказа на сегодня. Одно обрамляет всё; другое — это просьба.

Системный промпт (system prompt) держит долговечные инструкции, что применяются ко всему взаимодействию: роль модели, правила, которым следовать, тон, формат вывода. Пользовательское сообщение (user message) — это конкретный запрос.

Положить персону, guardrails и постоянные правила в системный промпт держит их стабильными, пока вопросы пользователя меняются. Это разница между тем, кто модель есть в каждом вызове, и тем, о чём её просят в этот раз.

Few-shot Prompting — покажи, а не только скажи

Научить кого-то формату, показав три готовых примера, быстрее и яснее, чем описывать словами и надеяться, что он верно вообразит.

Часто самый надёжный способ получить нужную форму вывода — включить пару примеров ввода и идеального вывода прямо в контекст. Это паттерн few-shot prompting. Модель сопоставляет примеры по шаблону куда лучше, чем следует абстрактному описанию.

Два-три острых примера могут побить абзац инструкций, и они часто самая быстрая починка, когда модель почти делает то, что ты хочешь, но не совсем.

Context Assembly — собирай окно из частей

Упаковать портфель на встречу: повестка, два релевантных отчёта, заметка об ограничениях — выбрано нарочно, а не весь твой шкаф документов, опрокинутый внутрь.

Реальное окно контекста собирается из кусков на каждый вызов: системный промпт, релевантная история, извлечённые факты (RAG), примеры, доступные инструменты и наконец запрос пользователя. Это и есть сборка контекста (context assembly): решать, нарочно и каждый раз, какие куски входят, а какие остаются снаружи.

Думать об окне как о том, что ты строишь из частей, а не просто как о промпте, что печатаешь, — вот ментальный сдвиг, после которого всё остальное щёлкает.

Relevance over Completeness — больше контекста не значит лучше

Брифинг в одну острую страницу бьёт свалку в 200 страниц — читатель находит сигнал вместо того, чтобы в нём тонуть, и решает быстрее и лучше.

Соблазнительно напихать в окно всё возможно релевантное «на всякий случай». Но больше — не лучше, обычно хуже. Принцип relevance over completeness — релевантность важнее полноты: каждый токен соревнуется за внимание модели, и нерелевантный материал разбавляет сигнал.

Навык — выбрать те немногие вещи, что важны, а не включить всё, что может.

Context Dilution — шум поднимает шанс неверного ответа

Спрячь один релевантный факт внутри горы в основном нерелевантной бумаги — и даже внимательный читатель начнёт цитировать не ту страницу: шум сам и вызывает ошибку.

Длинный, набитый контекст не просто тратит место; он активно ухудшает качество. Это разбавление контекста (context dilution): погребённое в нерелевантном материале, внимание модели размазывается, и в длинных контекстах это измеримо поднимает долю галлюцинаций и ошибок — она уверенно использует то, что и не задумывалось ответом.

Добавление контекста «на всякий случай» может быть ровно тем, что вызывает сбой. Меньше, острее контекст — это надёжнее контекст.

Curation — курируй безжалостно под этот вызов

Хороший редактор не добавляет — он режет, вручая тебе лишь те строки, что отрабатывают своё место на этой странице.

Дисциплина — безжалостное курирование (curation): для этого конкретного вызова включи те немногие вещи, что модели правда нужны, и оставь всё остальное снаружи. Это значит извлекать только самые релевантные чанки, обрезать историю до важного, выбрасывать контекст, что сделал своё дело.

Context Budget — окно конечно, и каждый токен стоит

Чемодан с пределом веса и платой за килограмм — ты пакуешь то, что реально понадобится, а не весь гардероб, потому что есть жёсткий потолок и цена.

У окна контекста максимальный размер, и каждый токен в нём стоит задержки и денег — бо́льшие контексты медленнее и дороже на каждом вызове. Так что контекст — не свободное место для заполнения; это бюджет контекста (context budget), который ты тратишь.

Фича, что набивает окно на каждый запрос, медленна и дорога в масштабе, ещё до того как страдает качество. Окно — это ресурс для распределения, а не пустота для заполнения.

Trim & Summarize — трать окно на то, что отрабатывает место

Тесный бюджет поездки вынуждает реальные выборы — ты тратишь на то, что важно для поездки, и пропускаешь остальное, и поездка лучше от этой дисциплины.

Относиться к окну как к бюджету меняет то, как ты строишь: ты обрезаешь (trim) историю разговора, суммируешь (summarize) старые ходы вместо того, чтобы нести их дословно, и извлекаешь только релевантное сейчас, а не всё, что у тебя есть. Каждый токен должен заработать свой слот.

Это та же дисциплина, что производительность или кэширование, — трать скудный ресурс нарочно, на то, что реально двигает исход.

Long Context Windows — окно побольше не кончает дисциплину

Аренда грузовика побольше не значит, что надо набить его хламом, — больше ёмкости это место для большего числа полезных вещей, а не лицензия перестать паковать аккуратно.

Модели продолжают выпускать бо́льшие окна контекста (long context windows) — миллион токенов, больше, — и соблазнительно думать, что проблема бюджета уходит. Не уходит. Окно побольше всё равно стоит дороже и медленнее на токен, и, что критично, более полное окно всё равно разбавляет внимание и приглашает ошибки.

Больше ёмкости — не разрешение вываливать; это просто больше места, что тебе всё равно надо тратить с умом. Дисциплина курирования окна переживает любой рост размера.

Context Rot — длинные контексты копят устаревшее и противоречивое

Игра в испорченный телефон вдоль длинной цепочки — к концу сообщение тихо мутировало, и все уверенно повторяют что-то слегка неверное.

За долгий разговор или многошаговую задачу агента окно наполняется историей: ранние ходы, выводы инструментов, недоделанное рассуждение. Со временем эта куча становится неряшливой — устаревшие факты сидят рядом со свежими, противоречия накапливаются, исходная цель уплывает из фокуса.

Индустрия зовёт получающийся распад качества гниением контекста (context rot): та же модель становится менее надёжной по мере того, как её собственный накопленный контекст становится шумнее.

Compaction — сжимай по ходу

Хороший конспектист не держит каждое слово долгого совещания — он дистиллирует его до решений и открытых вопросов, неся вперёд вывод, а не транскрипт.

Лекарство — активно сжимать контекст по мере роста. Это compaction: суммировать завершённые шаги в короткое текущее состояние вместо того, чтобы тащить вперёд весь транскрипт, выбрасывать выводы инструментов, как только извлёк важное, держать тугую рабочую сводку, а не сырую историю.

Модель несёт вывод, а не каждое слово, что его произвело. Так долгоиграющие агенты остаются связными — они управляют своим контекстом, а не дают ему копиться.

Goal Re-anchoring — переякоривай цель

На долгом, извилистом походе ты регулярно перепроверяешь карту и пункт назначения — иначе дрейфуешь, по одному разумно выглядящему повороту за раз, прочь оттуда, куда метил.

За много шагов исходная задача размывается под весом всего, что случилось с тех пор. Так что ты её переякориваешь (re-anchoring): переформулируй цель и ключевые ограничения в окне на каждом шаге, чтобы модель оставалась нацелена на настоящую мишень, а не дрейфовала с разговором.

Окно побольше делает это хуже, а не лучше, — оно даёт дрейфу больше места копиться. Активное управление, а не сырая ёмкость, — вот что держит долгую задачу на курсе.

Deliberate Assembly — строй окно нарочно, а не случайно

Повар выкладывает блюдо нарочно — каждый элемент помещён по причине — вместо того, чтобы наскрести на тарелку что попало со стола.

Ключевая привычка — намеренная сборка (deliberate assembly): относиться к окну как к тому, что ты конструируешь нарочно. Реши, что держит системный промпт, какую историю оставить или суммировать, что извлечь, какие примеры показать, какие инструменты выставить.

Многие LLM-приложения собирают контекст случайно — что попало под руку, то и шлётся. Строить его нарочно, с обоснованной каждой частью, — вот бо́льшая часть того, что отделяет надёжную фичу от флакающей.

Context Evals — меряй контекст, как меряешь код

Ты не гадаешь, помогло ли изменение, — ты тестируешь. То же и с тем, что кладёшь в окно: ответ стал лучше или хуже, и ты должен знать какой.

Изменения контекста — реальные изменения, так что проверяй их: когда подстраиваешь, что идёт в окно — больше примеров, другое извлечение, обрезанная история, — проверь эффект эвалами (evals), не просто окинь глазом один вывод.

Инженерия контекста без измерения — это настройка на ощупь, и так «безобидное» добавление тихо ухудшает качество. Относись к содержимому окна как к тому, что тестируешь, — та же дисциплина, что курс об эвалах.

Как всё связано

Схема метро целиком: теперь видно, где линии пересекаются.

Модель без состояния → значит, всё решает окно → значит, окно надо инженерить. Окно собирается из частей (системный промпт, примеры, факты). Три силы его портят: нерелевантность, бюджет и гниение со временем. У каждой — своя практика: курирование, обрезка и резюме, сжатие с переякориванием. А эвалы проверяют, что каждое изменение помогло.