Transcription
В настоящее время среди разработчиков идет постоянный спор о том, насколько хороши на самом деле кодирующие агенты, и этот спор обычно имеет две стороны. Есть сторона, которая говорит: "Нет, кодирующие агенты — это отстой. Я ненавижу ИИ-кодирование". И другая сторона спора говорит: "Нет, вы просто неправильно их используете. Это проблема навыков".
Я могу понять обе стороны этого спора, но если есть проблема с навыками, которую я вижу чаще всего у разработчиков, то это недостаточное внимание к контекстному окну. Контекстное окно — это основное ограничение, с которым сталкиваются большинство ИИ-кодирующих агентов в наши дни. И, честно говоря, большинство разработчиков даже не знают, что это такое, или как это влияет на использование этих кодирующих агентов. Если это про вас, вы пришли в нужное место. Мы объясним все, что вам нужно знать как пользователю кодирующих агентов о том, что такое контекстное окно и как оно влияет на производительность кодирующих агентов.
Итак, давайте сразу начнем с того, что на самом деле составляет контекстное окно. Контекстное окно — это весь набор входных и выходных токенов, которые видит LLM. Входные токены — это то, что вы передаете LLM. Вы можете передать ему системный промпт, который содержит некоторые инструкции, чтобы сказать LLM, что он должен делать, и, возможно, сообщение пользователя для начала разговора, а затем, как только вы это отправите, LLM начнет потоково передавать обратно некоторые сообщения ассистента, которые являются выходными токенами, и входные плюс выходные токены составляют все контекстное окно.
По мере того как разговор становится длиннее, скажем, вы общаетесь с Claude или ChatGPT, в этом контекстном окне будет все больше и больше входных и выходных токенов. Поэтому мы обычно говорим о том, что контекстное окно как бы растет, или количество токенов, которые вы используете в этом контекстном окне, растет, и в конечном итоге оно станет настолько длинным, что вы достигнете предела.
Каждая модель имеет жестко заданный предел, установленный поставщиком модели. И давайте предположим, что вы передали слишком много входных токенов. У вас есть системное сообщение, сообщение пользователя и еще 100 сообщений. Скажем, хорошо, вы получите ошибку от поставщика LLM, говорящую, что вы достигли предела контекстного окна. Вы можете даже столкнуться с этим с одним супердлинным сообщением. Скажем, вы загружаете какие-то документы или просите LLM транскрибировать видео или огромное изображение. И этот предел контекстного окна обычно описывается в токенах. Если вы не знаете, что такое токен, вы можете посмотреть мое видео на YouTube о токенах, ссылку на которое я оставлю здесь.
Теперь вы можете фактически достичь предела и при генерации токенов. Например, вы можете просто общаться с системой вот так, и она, возможно, выдаст вам чрезвычайно длинный вывод, который выходит за пределы ее контекстного окна, и она просто остановится, потому что контекстное окно было достигнуто.
Вы можете зайти на models.dev, чтобы проверить различные пределы контекстного окна и много другой информации о различных моделях. Например, Claude Haiku 4.5. Если мы увеличим масштаб здесь, мы увидим предел контекстного окна в 200 000 токенов. Ниже мы видим предел в 2 миллиона токенов. Давайте посмотрим на это. Бум, бум, бум, бум, бум. И у нас есть Gemini 2.5 Pro. Gemini, как бы, в качестве своего преимущества имеет действительно большие контекстные окна. Но, как мы увидим через секунду, больше — не всегда лучше. Мы также увидим, что здесь есть некоторые модели, такие как Quen Math Plus, которые имеют всего около 4000 токенов. Так что меньшие модели и старые модели тоже часто имеют гораздо меньшие пределы контекстного окна.
Так почему же эти модели вообще налагают ограничения на контекстное окно? Почему бы просто не разрешить передавать бесконечное количество текста через модель? Ну, отчасти это связано с ограничениями архитектуры модели. Обработка LLM дорога, и поэтому добавление большего количества текста и большего контекстного окна означает, что вы используете больше памяти на процесс. Но также, чем больше контекстное окно, тем больше снижается производительность. Другими словами, чем больше информации вы даете модели, тем хуже она будет работать. Это верно для крошечных моделей вплоть до очень, очень больших моделей.
И причина этого в том, что все модели страдают от проблемы извлечения информации из своего собственного контекста. Это классическая проблема "иголки в стоге сена". Если у вас есть один фрагмент информации в огромном, раздутом контексте, и вы пытаетесь заставить LLM уточнить это и сделать с этим что-то, то ей будет очень трудно. Это особенно верно для информации, которая находится в середине разговора. Например, я поместил этот очень ненаучный график здесь, где у нас есть влияние на вывод и позиция в разговоре. Что происходит, так это то, что для действительно длинных чатов, где каждое отдельное сообщение представлено этим маленьким кружком, информация в середине чата будет менее приоритетной для LLM. Так что материал в начале и в конце считается наиболее важным механизмом внимания, который использует LLM.
Это не совсем намеренное поведение. Это просто эмерджентное свойство того, как спроектированы эти системы. Так что это действительно очень важно, когда вы занимаетесь ИИ-кодированием. Материал в начале разговора будет иметь наибольшее влияние, и материал в конце будет иметь наибольшее влияние. Но весь большой, раздутый материал в середине не обязательно будет сильно влиять на результат. Он все еще оказывает влияние, конечно, но гораздо меньше, чем материал в начале и в конце. И это тоже имитирует человеческое поведение, если вы когда-либо слышали о первичном и недавнем смещении. Вы, вероятно, лучше запомните начало этого видео и конец видео, чем болтовню в середине.
Однако, чем короче контекстное окно, тем меньше проблем с "потерей в середине" вы встретите. Модели просто лучше работают с меньшим, более сфокусированным объемом информации, как и люди. Это означает, что регулярная очистка ваших чатов с кодирующими агентами освежит память агента и очистит его контекстное окно, обеспечивая гораздо лучшую производительность, когда вы фактически начнете его использовать.
Давайте фактически погрузимся в кодирующего агента, которого я использую, Claude Code. Я выполнил команду под названием "context", и мы можем увидеть использованное нами контекстное использование. Мы использовали 95 тысяч токенов из 200 тысяч. Это на Claude 4.5, который имеет предел контекстного окна в 200 тысяч. Почти 8% приходится только на системный промпт, а 40% — на эти сообщения. Итак, 77 тысяч токенов — это содержание разговора, который я провел до сих пор. Теперь, если бы у меня была какая-то работа, связанная с нитью чата, которую я только что проделал, которая, как я думаю, заключается в переработке некоторой документации, то 105 тысяч токенов свободного пространства — это кажется мне довольно хорошо. Но я определенно начал бы беспокоиться, когда у меня осталось бы всего около, скажем, 50 тысяч токенов, после чего я бы запустил "clear", который очищает историю разговора и освобождает контекстное окно.
У вас есть альтернатива в Claude Code здесь, которая заключается в сжатии разговора. Если я запущу это, это очистит историю разговора и создаст резюме того, что произошло. Другими словами, он берет все эти сообщения и просто создает из них одно меньшее сообщение. Теоретически, это отодвинет нас дальше от предела контекстного окна, и у нас будет меньше проблем с "потерей в середине". Однако это занимает некоторое время, и, конечно, вы используете LLM для создания резюме. Так что вы тратите токены здесь. Это уже заняло около минуты, и наконец-то закончилось. И мы можем нажать Ctrl+0, чтобы увидеть полное резюме. Мы видим, что оно создало довольно длинное резюме разговора, который мы только что провели, без каких-либо файлов, которые оно загрузило, или чего-то подобного, но оно сохраняет некоторое намерение, некоторые настроения, и это своего рода мини-файл правил только для этого разговора.
Если мы снова запустим "context", мы увидим, что у нас теперь 90% свободного пространства, а сообщения вместо, скажем, 70 тысяч токенов, сколько бы их ни было раньше, теперь всего 4 тысячи. Так что сжатие полезно, когда вы хотите сохранить настроение разговора. Но "clear" должен быть вашим выбором по умолчанию, когда вы просто хотите его очистить. Вернуться к чистому листу и продолжить оттуда.
Всякий раз, когда вы работаете с кодирующим агентом, вам действительно нужна полная прозрачность, полное понимание того, что происходит в вашем контекстном окне в любое время. Я хочу дать вам здесь предупреждение о MCP-серверах. MCP-серверы очень привлекательны, потому что они позволяют вам подключать и использовать различные готовые наборы инструментов в экосистеме, но они могут невероятно быстро раздуть ваш контекст. У вас может быть разговор, где, скажем, треть его — это системный промпт. Знаете, большая часть — это MCP-инструменты просто от пары MCP-серверов, а затем лишь немного дополнительного — это сообщения. Поэтому я склонен быть чрезвычайно, чрезвычайно осторожным при добавлении MCP-серверов в мою настройку, потому что я знаю, насколько важно иметь компактное контекстное окно. Я также не склонен писать очень, очень большие правила курсора или правила Claude, потому что опять же, я просто так боюсь этих проблем с "потерей в середине". И в результате я действительно наслаждаюсь работой с ИИ-кодирующими агентами и, я думаю, получаю из них действительно приличную производительность. И надеюсь, если вы примете этот паранойю, которую я развил, вы тоже получите отличные результаты.
Итак, это то, что такое контекстное окно. Это входные и выходные токены, которые составляют все, что LLM может видеть в любой момент времени. Каждая LLM поставляется с ограничением контекстного окна, жестко заданным ограничением, установленным поставщиком модели, которое, по сути, является количеством токенов, которые, по их мнению, LLM может разумно обработать. Все LLM подвержены проблемам "потери в середине", когда материал в середине контекстного окна оказывается менее приоритетным. Поэтому, когда вы оцениваете LLM, вы не должны просто смотреть на то, насколько велико контекстное окно. Вы должны смотреть на то, насколько хорошо она извлекает информацию из своего контекстного окна.
Например, в апреле Meta анонсировала Llama 4 Scout, которая, если я скрою себя, находится прямо здесь, и имеет предел контекстного окна в 10 миллионов, но оказалось, что после того, как люди действительно поиграли с ней, она страдала от очень плохих проблем с "потерей в середине". И даже несмотря на то, что вы могли бы передать ей эту информацию, она на самом деле ничего с ней не делала.
Итак, я надеюсь, у вас появилось лучшее понимание ограничений этих моделей и того, как вы можете обойти эти ограничения и лучше их понять, чтобы получить лучшие результаты. Если вы хотите углубиться в LLM, то я только что выпустил экспресс-курс по AISDK. Это экспресс-курс по AIDK от Vercel, который, я думаю, является идеальным способом начать работу с LLM, если ваш основной язык — TypeScript. Но всего за несколько дней вы можете получить его за 99 долларов. Так что переходите на aihero.dev, если хотите узнать больше.
Большое спасибо за то, что следили за мной. Я люблю говорить об этих вещах и действительно считаю, что это ценная информация. Если есть что-то, связанное с LLM, что вы хотите, чтобы я осветил, особенно говоря об этом в контексте TypeScript, дайте мне знать в комментариях. Так что спасибо за просмотр, и я увижу вас очень скоро.