Transcription
Сколько раз сегодня чат GPT вам ответил: "Вы абсолютно правы, давайте исправим"? 5? 10? Если да, то проблема не в модели, проблема в том, как вы с ней работаете.
Привет. Знаете, что меня убивают? Все носятся с размерами модели. О, у GPT триллион параметров, а Клод теперь 200.000 токенов может держать в контексте. Классно, конечно, но знаете что? Это как покупать Ferrari и ездить только на первой передаче.
Сегодня я покажу вам то, что должны понимать все, кто работает с LLM. Готовы? Контекстное окно - это не ограничение, это ваш основной интерфейс работы с моделью. Если вы не умеете им управлять, вы просто сливаете время и деньги в унитаз. Ведущие ML-инженеры из компаний, создающих автономных агентов и разработчиков, называют контекстную инженерию работой номер один. А правильная работа с контекстом - это разница между LLM, который понимает вашу задачу, и LLM, который делает полную чепуху. Качество результата улучшается в разы, и при этом ещё происходит экономия токенов, как приятный бонус.
Четыре концепции, которые я вам сегодня покажу, изменят вашу работу с LLM навсегда, от простых чатов до написания кода. Поехали.
Начну с идеи, которая может показаться спорной. В техсообществе сейчас активно обсуждают новую концепцию, и она меняет всё, к чему мы привыкли. Что если код - это уже не главный актив? Что, если промты и спецификации - это новая интеллектуальная собственность? Не верите? Давайте подумаем вместе.
Ведущие ML-инженеры называют это Software 3.0. Software 1.0 - каждую строчку пишем руками. Software 2.0 - нейросети учатся из данных. Software 3.0 - естественный язык - это есть код, а LLM - это его компилятор. Бред? Давайте посмотрим на цифры. Google 25% нового кода пишет с помощью ИИ, и к апрелю двадцать пятого года уже 30%, то есть треть. GitHub Copilot. В активных файлах 46% кода сгенерированы, при этом 15 млн разработчиков уже им пользуются. Но при этом Simon Wilson, создатель Dataset, говорит: писать код с LLM сложно и неинтуитивно. Если вам говорят, что это легко, вас, скорее всего, намеренно вводят в заблуждение.
Парадокс: все используют LLM, но не все понимают, как это работает. Представьте повара с рецептом и робота-повара. Первый создаёт рецепт, второй готовит по нему. Кто ценнее? Кто может адаптировать блюдо под новые вкусы? Кого легко заменить? Правильно, повар. Пока робот не умеет создавать рецепты сам, повар незаменим. С кодом ИИ-ассистенция становится похожей.
Смотрите, что мы делаем каждый день: разрабатываем инструкции, промты, получаем готовый код, сохраняем код, а инструкции - в корзину. Это как сеть ресторанов, которая разрабатывает уникальные процессы и стандарты, открывает филиал, а потом выкидывает все инструкции, оставляя только то, что работает. Но когда нужно открыть новый филиал или изменить меню, начинает всё заново. Абсурд, конечно. Но погодите, не спешите с выводами. Давайте разберёмся без эмоций: когда это подход работает, а когда нет.
Но перед этим нужно понять базу: как вообще работает контекстное окно и какая ваша роль во всём этом процессе. О'кей, давайте по-честному. LLM - это мощнейший инструмент, но без вашей инженерной работы это просто очень дорогой калькулятор, и вы - дирижёр этого оркестра.
Три факта, которые должен знать каждый.
Факт первый. LLM не помнит между вызовами. Вообще. Каждый новый запрос - это чистый лист. Tabula rasa. Модель получает всю историю заново каждый раз. Нет никакого обучения от использования, только от того, что вы даёте в контексте. LLM - это чистая функция. Вот и всё. Никакой магии, чистая математика. То, что мы получаем на выходе, полностью зависит от того, что мы даём нашей модели. Даём ей ерунду, получаем ерунду.
Факт второй. Контекстное окно - это всё, что видит модель. Attention - это такой интересный механизм. Он как прожектор, который позволяет модели фокусироваться на важных частях. Но чем больше контекст, тем хуже фокус. Это как пытаться осветить футбольное поле карманным фонариком.
Факт номер три. Качество выхода равно качеству входа. LLM - это функция, чистая математика. Мусор на входе, мусор на выходе. Гениальный промт, гениальный результат. Хаотичный контекст, вы получаете полный хаос на выходе.
Теперь о вашей роли. Вы не просто пользователи ИИ-ассистентов, вы - архитектор контекста. Вы решаете, что показать модели, когда это показать, в каком формате и с какими инструкциями. Вы режиссёр процесса: разбиваете большие задачи на сцены, управляете вниманием модели, контролируете качество на каждом этапе. И самое важное, вы хранитель знаний. Ваши промты, спецификации - это накопленная экспертиза. Каждая итерация улучшает инструкции. Код можно перегенерировать за секунду, но понимание системы - оно в ваших спецификациях и в вашей голове.
Давайте ещё раз рассмотрим, что же это такое - контекстное окно. Порисуем и разберёмся. Давайте представим модель. У неё есть контекстное окно, в неё помещается какой-то набор данных. Вы начинаете, вы говорите модели: "Привет". Она вам отвечает: "Привет". Вы говорите: "Посмотри мой код" и загружаете какие-то свои файлы. Она вам отвечает: "Да, какие у вас хорошие файлы. Что мы с этим будем делать?" Вы ей говорите: "Давай, мне надо найти здесь где-то баг". И модель начинает искать в этих файлах и что-то вам отвечает.
При этом, вы видите, размер контекстного окна у нас ограничен. Если изначально у нас в него поместилась какая-то информация, после того, как мы начинаем добавлять новые сообщения, она нам отвечает или добавлять новые файлы, что происходит со старыми? Старые выпадают из контекстного окна, и модель начинает уже отвечать без понимания того, что там было. Модель не помнит начало разговора и может начать что-то выдумывать и принимать те решения, которые вы совсем не ожидаете. Вот почему Claude Code и Cursor автоматически сжимают историю и подбирают релевантный контекст по мере приближения к лимиту или когда это уместно. Модель не имеет памяти между вызовами, но инструменты используют умную фильтрацию и компрессию. И это критически важно понимать.
Теперь, когда вы понимаете свою роль инженера контекста, давайте поговорим о типичных ошибках, которые все делают.
Первая ошибка - загрузка всей документации разом. "Вот тебе 500 страниц доков. Найди ошибку." Это как искать иголку в стоге сена с завязанными глазами. Модель потеряется в этом объёме.
Вторая ошибка - игнорирование "Lost in the middle". Когда у нас самая важная информация попадает в середину контекста. Что это такое, обсудим чуть-чуть позже.
Третья ошибка - отсутствие фильтрации контекста. "На всякий случай добавлю ещё этот файл или этот. А вот этот тоже вроде нужен." Стоп. Каждый лишний токен - это шум, который ухудшает качество. Меньше, но релевантнее. Вот ключ к успеху.
Теперь давайте поговорим о реальных проблемах, которые создаёт неправильная работа с контекстом. Слушайте, неправильное управление контекстом - это не просто неоптимально, это катастрофа. Вам же знакомы эти моменты: "Извините, вы правы. Там действительно была ошибка, давайте исправим." Итак, пять раз подряд. Вы уже кричите на монитор: "Да я же тебе говорил 10 минут назад!" А модель такая: "Вы абсолютно правы. Я что-то упустил." И вы начинаете сомневаться, может, это вы тупой, а не LLM? Нет. Просто контекст забился мусором, и модель потеряла нить разговора.
Где это критично? Везде. В Code-Code и Cursor. Знаете, разница между "перепиши всё заново" и "точечными правками" - это разница между junior и senior разработчиком. И это всё про контекст.
Агенты - это моя любимая тема. Агент может потратить 100 долларов на простую задачу или 1 доллар на сложную. Угадайте, в чём разница? Правильно, контекст.
RAG - Retrieval Augmented Generation. Звучит умно, да? На деле либо система находит нужное, либо захлёбывается в собственной документации, и снова всё решает контекст.
Реальные цифры, пожалуйста. Неоптимизированный промт - 150 токенов, оптимизированный - 45. Главное не экономия, а точность. Модель лучше понимает задачу, даёт точные ответы, а экономия - приятный бонус.
И вот важный момент: когда контекст переполнен, модель начинает терять информацию из середины. Это феномен, известный как "Lost in the middle" из исследования Stanford. Качество = (корректность * полнота) / (размер * шум). Чем больше шума и размер, тем хуже качество. Опять математика.
Разница в структуре контекста. То есть, если мы с вами посмотрим на эту формулу, мы поймём, что если мы добавляем много шума, много ненужных документов или нерелевантной информации для текущего запроса, мы с вами ухудшаем качество ответа. Если у нас будет слишком большой размер, мы также ухудшаем качество ответа. При этом нам надо концентрироваться на полноте той информации, которую мы предоставляем модели, и на её корректности. Поэтому, если у нас будет максимальная корректность с максимальной полнотой при минимальном размере и у нас не будет шума, то мы с вами получим очень хорошее качество результата. Поэтому надо запомнить: чем больше шума и размера, тем хуже качество. А так как существует феномен "Lost in the middle", то чем больше размер, тем хуже может быть корректность и полнота, если она у нас попадёт с вами в середину нашего контекстного окна. И это становится критически важным. Держать контекст не таким большим, какой он может быть.
Как же правильно работать с контекстом, чтобы избежать этих проблем? Два лайфхака, которые сэкономят вам часы.
Правило 10 шагов. Держите агента в пределах десяти шагов на одно окно. Максимум 20. 3-10 шагов - оптимальная производительность. 10-20 - начинается деградация. Больше двадцати - контекст становится неуправляемым.
Refetch данных. Контринтуитивно, но работает. Если знаете, какие данные понадобятся, загрузите их сразу. Обычный подход: модель говорит: "Мне нужна такая-то версия". Происходит вызов инструмента, ожидание, обработка. Это уже четыре шага. При refetch-подходе контекст содержит всё: ноль шагов.
Теперь, когда вы знаете, как избежать ошибок, давайте поговорим о конкретных стратегиях. Управляйте контекстом как оперативной памятью компьютера. Это не метафора, это буквально то, чем вы занимаетесь.
Стратегия первая: Writing, запись в LLM-контекст. Знаете, что делает профи? Они сохраняют промежуточные результаты. Агент читает это вместо всей истории. Экономия 90% токенов.
Стратегия вторая: Selecting, или умный выбор. Типичный подход новичка: "Вот 100 файлов проекта. Найди баг." Знаете, что делает модель? Правильно, теряется. Подход профи: "Вот три файла с авторизацией. Проверь валидацию email." Конкретная задача, конкретный контекст. Точность выполнения намного выше.
А вот это вообще магия: передача знаний через файлы. Агент номер один создаёт research result, который помещает информацию о его ресёрче. Агент номер два читает и сразу работает. Никакой передачи контекста. Чистота.
Реальный кейс - трёхфазная система для больших проектов. И это отдельная методология.
Фаза Research. Агент изучает кодовую базу, записывает всё в research.md: где баг, как данные передаются, какие зависимости. Всё с номерами строк.
Фаза Plan. Новый агент читает research.md, создаёт план: конкретные изменения, тесты, порядок выполнения.
Фаза Implement. Финальный агент читает план и выполняет пункты по очереди. Если надо, то каждый пункт может выполняться в отдельном контекстном окне.
Но самое важное: между фазами - ревью разработчика. Мы в команде делаем так: research, проверяем, корректируем план, отправляем коллеге на ревью. Почему? Делимся знаниями, понимание системы, получаем архитектурное ревью ещё до начала кодирования. Результат: задача на большом проекте решается всего за несколько итераций. Вместо попытки загрузить весь проект и умереть от того, что контекстное окно переполнится.
Стратегия третья: Compression, или сжатие истории. Code-Code делает это автоматически. При 95% заполнения, это 190.000 из 200.000 токенов. Старые сообщения превращаются в summary. Последние пять остаются детально. Если вы дошли до автоматического сжатия, это звоночек, значит, вы не управляете своим контекстом. Лучше это делать осознанно: сохранять план и прогресс, начинать новую фазу с нужной точки.
Стоп, стоп, стоп. Не все задачи требуют сложной системы. Давайте будем честными. Когда не нужна трёхфазная система? Простые правки: исправить опечатку в README, локальные изменения, добавить кнопку на страницу, однофайловые задачи. "Оптимизируй эту функцию." Просто дайте конкретные файлы, задачу, не усложняйте.
Когда нужна: большие рефакторинги и изменения в 10+ файлах, новые фичи, требующие изменения архитектуры, незнакомые кодовые базы, проекты больше 100.000 строчек кода.
Проблема в цифрах: 300.000 строк кода в проекте и 200.000 токенов в контекстном окне Claude. Как вообще это может работать? Сейчас покажу. Каждая фаза - это отдельное окно. Каждая фаза завершается файлом с результатом. Мы ревьюем его глазами. Не нравится, меняем промт и запускаем фазу заново.
Одна плохая строка кода - это один баг. Одна плохая часть плана - это 100 плохих строк кода. Одно неверное понимание системы - это 1.000 с лишним плохих строк кода. Временный research окупается экспоненциально.
Вот смотрите, если у нас есть с вами наш код, одна плохая строчка кода - это будет один баг. Если у нас есть с вами план и один плохой кусок плана, он уже породит здесь сотни строчек плохого кода. Если у нас есть с вами research и в нём у нас есть какой-то плохой кусок, он что, породит намного больший плохой план, который породит ещё больше строчек кода плохого? А если у нас с вами неверное понимание всей системы, то это породит плохую кодовую базу целиком. Поэтому время на research, на понимание системы и на архитектурные принципы очень важно.
Концепция sub-агентов. Правильное использование sub-агентов. Parent: "Найди, где происходит X". Child ищет, анализирует 100 файлов. Child передаёт Parent: "X происходит в файле Y, строка Z". Parent работает без загрузки поиска в контекст. И это не ролевая игра, это изоляция контекста. Если вы не знали, то в Claude Code можно попросить любую задачу делать в отдельном контекстном окне, даже без настройки sub-агентов.
Почему порог в 40-50% размера контекстного окна - это хорошо? Это опыт моей команды и коллег по цеху. Если мы используем контекстные окна больше либо максимальные, то качество у нас сразу же падает.
Практический совет: работа без чёткого плана - это хаос возможных ошибок. Плохая строка в research - тысячи плохих строк кода. Плохая строка в плане - сотни плохих. Проверяйте research и план. Не код. Код перегенерируется легко. План - нет.
Возвращаемся к вопросу из начала. Помните аналогию с поваром и рецептом? Так вот, в некоторых случаях рецепт действительно становится ценнее блюда. Но давайте без крайности. Крайности никогда не работают. Код всегда важен. Но вопрос: на чём сосредоточить максимум усилий? Что проверить досконально? Где можно положиться на ИИ, а где нет - это зависит от вашей инженерной культуры и знаний.
При этом для любого подхода нужна дисциплина. Review research и планов - это обязательно. Мы в команде на сложных фичах всегда отправляем план на ревью коллеги, получаем архитектурное ревью до кодирования. Качество имплементации: тесты должны проходить, метрики качества соответствовать, SAST не должен находить уязвимости. Code review, особенно на критичных секциях. Кстати, процесс ревью сейчас активно автоматизируется через LLM. У нас One-Pass - сотни промтов для разных этапов. Промты - это новая часть рабочего процесса, не менее важная, чем код. И каждый промт - это выверенная инструкция.
Ключевая мысль: мы не выбираем между кодом и спеками. Мы учимся понимать, что ценно в каждом конкретном случае. И да, это требует нового уровня инженерной дисциплины.
Мы разобрали ключевые концепции: для некоторых задач спецификации становятся ключевым активом. LLM не помнит, вы управляете его памятью. Больше контекста не равно лучше результат. Правило 40% размера контекста для больших проектов. Передача знаний через файлы между агентами. Контекстная инженерия - это новый навык разработчика. Контекстное окно - это не баг, а фича. Научитесь им управлять и получите десятикратные результаты вашего труда.
Подписывайтесь, если было полезно. В одном из следующих видео разберём RAG-системы и как правильно их измерять и понимать, что качество в них хорошее. Увидимся.