Новый навык в области ИИ — не подсказка, а проектирование контекста ( philschmid.de )
Я немного писал об этом на днях: https://simonwillison.net/2025/Jun/27/context-engineering/
Дрю Бреуниг написал несколько замечательных статей на эту тему — по совпадению, в то же время, когда появилось модное словечко «контекстная инженерия», но на самом деле не имеющее отношения к этому мему.
Как длинные контексты терпят неудачу – https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-ho… – рассказывает о различных способах, которыми более длинные контексты могут начать вызывать проблемы (также известные как «гниение контекста»)
Как исправить контекст – https://www.dbreunig.com/2025/06/26/how-to-fix-your-context…. – дает названия множеству методов решения этих проблем, включая загрузку инструментов, карантин контекста, обрезку контекста, суммирование контекста и выгрузку контекста.
Посты Дрю Бреунига на эту тему обязательны к прочтению. Это важно не только для написания собственных агентов, но и критически важно при использовании агентного кодирования прямо сейчас. Эти ограничения/поведения будут с нами еще некоторое время.
Они могут быть хорошими чтивами по теме, но Дрю допускает некоторые существенные этимологические ошибки. Например, loadout происходит не из игровой, а из военной терминологии. По сути, это то же самое, что kit или gear.
> Создание мощных и надежных агентов ИИ становится все менее и менее значимым занятием — поиском волшебной подсказки или обновлений модели.
Хорошо, я могу это купить.
> Речь идет о проектировании контекста и предоставлении правильной информации и инструментов в правильном формате в правильное время.
когда «правильный» формат и «правильное» время по сути, а может быть, даже обязательно, не определены, то разве вы все еще не ищете «волшебного» решения?
Если определение “правильной” информации – это “информация, которая приводит к достаточно точному ответу из языковой модели”, то я не вижу, как вы делаете что-то принципиально иное, чем инженерия подсказок. Поскольку это недетерминированные машины, я не вижу никакой надежной эвристики, которая была бы принципиально неотличима от “попытки и наблюдения” с подсказками.
Современные теоретические рамки обычно разделяют их на две отдельные фазы: исследовательскую и исследовательскую. Первую фазу, которая является исследовательской, лучше всего концептуализировать как использование устройства атмосферной дисперсии. Легко идентифицируемый маркерный материал, обычно различные фекалии, метафорически вводится на высокой скорости. Затем фаза открытия концептуализируется как анализ моделей рассеивания исследовательской фазы. Эти две фазы лучше всего суммировать, соответственно, как «Fuck Around», за которым следует «Find Out».
Поиск волшебной подсказки никогда не был «инжинирингом подсказок», это всегда был «контекстный инжиниринг» — множество «хочу стать гуру ИИ» подавали это именно так, но они никогда не знали ничего лучшего.
RAG не был изобретен в этом году.
Правильный инструментарий, который оборачивает эзотерические знания, такие как использование вложений, векторных баз данных или графовых баз данных, становится более распространенным. Крупные игроки улучшают свои инструменты, чтобы больше материала было доступно.
> Заключение Создание мощных и надежных агентов ИИ становится все менее и менее волшебным поиском подсказки или обновлений модели. Речь идет о проектировании контекста и предоставлении правильной информации и инструментов в правильном формате в правильное время. Это кросс-функциональная задача, которая включает в себя понимание вашего бизнес-варианта использования, определение ваших выходов и структурирование всей необходимой информации, чтобы LLM мог «выполнить задачу».
На самом деле это справедливо и для людей: чем больше контекста (то есть нужной информации в нужное время) вы предоставляете, тем лучше вы решаете задачи.
Да… Я всегда прошу своих специалистов по UX и продукту предоставить мне макеты, требования, критерии приемки, примеры входных и выходных данных, почему нас интересует эта функция и т. д.
Пока мы не сможем просканировать ваш мозг и понять, чего вы на самом деле хотите, необходимо будет на самом деле описать, что именно вы хотите построить, а не просто полагаться на вибрации.
Определенно отражает мой опыт. Одна эвристика, которую я часто использовал при предоставлении контекста для модели, это «достаточно ли этой информации для человека, чтобы решить эту задачу?». Создавая некоторые продукты text2SQL в прошлом, было очень интересно наблюдать, как часто, когда модель давала сбой, настоящий аналитик данных отвечал что-то вроде «о да, это старая таблица, которую мы больше не используем, правильная таблица — это…». Это означает, что модель, вероятно, допускала ошибку, которую настоящий аналитик-человек допустил бы без надлежащего контекста.
В этом списке не хватает одного: оценок!
Я в шоке, как часто я все еще вижу, как большие проекты ИИ запускаются без учета оценок. Оценки важнее для проектов ИИ, чем наборы тестов для традиционных инженерных. Вам даже не нужен большой набор оценок, достаточно того, который достаточно хорошо охватывает поверхность вашей проблемы. Однако без него вы по сути просто «угадываете», а не итерируете свою проблему, и вы даже не угадываете таким образом, чтобы каждая догадка была улучшением предыдущей.
Задавая вопросы, на которые можно ответить «да-нет», вы в 50% случаев получите ложь.
Мне любопытно, как это применимо к таким системам, как ChatGPT, которые теперь имеют два типа памяти: настраиваемую пользователем память (список фактов или предпочтений) и непрозрачную память истории чата. Если контекст является основной единицей взаимодействия, кажется важным дать пользователям больше контроля или, по крайней мере, видимости в обоих.
Я знаю, что контекстная инженерия имеет решающее значение для агентов, но интересно, полезна ли она также для формирования личности и улучшения общей релевантности? Мне интересно, думал ли кто-нибудь еще об этом.
Один мысленный эксперимент, над которым я размышлял недавно, касался минимального контекста, необходимого для определения задачи (для LLM, человека или кого-то еще). В программном обеспечении есть целая дисциплина человеко-центрированного дизайна, которая направлена на раскрытие нюансов задачи. Я работал с несколькими замечательными дизайнерами, и они невероятно ценны для разработки программного обеспечения. Они разрабатывают карты пути, пользовательские истории, собирают требования и создают множество проектных документов. Я не думаю, что вы можете успешно строить большие проекты без этого контекста.
Я видел много демонстраций ИИ, которые предлагают “создать мне приложение TODO”, делают вид, что этого достаточно, а затем заявляют, что вывод соответствует их потребностям. Без надлежащего контекста вы не можете сказать, является ли вывод правильным.
Контекстная инженерия — это всего лишь фраза, которую karpathy произнес впервые 6 дней назад, а теперь все относятся к ней так, будто это новая область науки и техники.
Я чувствовал себя несколько разочарованным из-за того, что я воспринимаю как широкую тенденцию очернять “оперативную разработку” как устаревший подход к любой новой отраслевой методике в отношении построения тела запроса для API модели. Будь то RAG много лет назад, нюанс в схеме запроса модели за пределами простого текста (вызовы инструментов, структурированные выходные данные и т. д.) или концепции агентных знаний и памяти в последнее время.
Хотя пару лет назад модели были менее мощными, в то время ничто не мешало вам использовать весьма динамичный подход к тому, что вы от них требовали как «оперативный инженер»; вы просто были более уязвимы к неопределенности в контракте с моделями на каждом этапе.
Контекстные окна стали больше; теперь вы можете вместить больше, отбросить необходимость в тонкой настройке и стать более амбициозным с тем, что вы вкладываете, чтобы помочь направить LLM. Но я не уверен, какие требования к навыкам здесь принципиально меняются. Вы просто получаете больше ресурсов в свое распоряжение и можете меньше беспокоиться о подсчете токенов.
Мне понравилось, что сказал по этому поводу Андрей Карпати:
https://twitter.com/karpathy/status/1937902205765607626
> [..] в каждом приложении LLM промышленного уровня, контекстная инженерия — это тонкое искусство и наука заполнения контекстного окна только нужной информацией для следующего шага. Наука, потому что правильное выполнение этого включает в себя описания и объяснения задач, несколько примеров, RAG, связанные (возможно, мультимодальные) данные, инструменты, состояние и историю, сжатие… Слишком мало или неправильной формы, и LLM не имеет нужного контекста для оптимальной производительности. Слишком много или слишком нерелевантно, и затраты LLM могут вырасти, а производительность может упасть. Сделать это хорошо — весьма нетривиально. И искусство, потому что руководящая интуиция вокруг психологии LLM человеческих душ.
Что забавно, потому что все уже смотрят на ИИ как: у меня есть 30 ТБ дерьма, которое по сути является “моей компанией”. Могу ли я сбросить это в ваш ИИ и получить еще одного, волшебного, всезнающего, коллегу?
Нет необходимости развивать этот «навык». Все это можно автоматизировать как этап предварительной обработки перед запуском основного запроса. Тогда у вас могут быть агенты с бесконечным контекстом и т. д.
Я с нетерпением жду 5 миллионов сообщений в LinkedIn, повторяющих это
Claude 3.5 был выпущен год назад. Текущие LLM не намного лучше его в кодировании. Конечно, они более блестящие и отполированные, но не намного лучше. Я думаю, что пришло время умерить наш энтузиазм.
Я почти всегда переписываю написанные AI функции в своем коде через несколько недель. Неважно, есть ли у них больше контекста или лучший контекст, они все равно не могут написать код, понятный людям.
Claude 3.5 был замечательно хорош в написании кода. Если Claude 3.7 и Claude 4 — это просто постепенные улучшения, то это даже лучше!
На самом деле я думаю, что они гораздо более чем постепенные. В версии 3.7 появился режим «мышления», а в версии 4 на него сделали ставку еще больше, и мышление/рассуждение/называйте как хотите, особенно хорошо подходит для задач по коду.
Как всегда, если вы не получаете отличных результатов от написания кода для LLM, скорее всего, вы не потратили несколько месяцев на отработку методов подсказок, чтобы выяснить, что лучше всего подходит для вашего стиля разработки.
Это неправильно. Новый/старый навык — это обратная разработка.
Если большая часть кода генерируется ИИ, вам все равно понадобятся люди с техническими знаниями, чтобы разобраться в нем.
Увидел это на днях и подумал, что слишком много усилий и доверия уделяется этой идее создания идеальной среды для процветания LLM. Что, по-моему, противоречит тому, как должны функционировать мощные системы ИИ. Нам не нужно так сильно держать его за руку.
Очевидно, нам нужно укротить версию LLM, которая у нас есть сейчас, и этот тип мышления — шаг в правильном направлении. Я не согласен с тем, как это мышление преподносится как революционная серебряная пуля.
Напоминает мне чатботов первого поколения, где пользователю приходилось прилагать усилия, чтобы составить фразу таким образом, чтобы получить ожидаемый результат. Это форма враждебности пользователя.
Мы не должны этого делать, но это аналогично тому, как раньше работало использование ЦП. В 8-битные дни можно было делать какие-то волшебные вещи, которые были совершенно невозможны до появления микрокомпьютеров. Но нужно было иметь всевозможные трюки и эвристики, чтобы обойти ограниченные возможности. Сейчас мы находимся в том же положении с LLM. Когда-нибудь у нас будет эквивалент того, чем сейчас являются гигабайты или ОЗУ для современного ЦП, но пока мы все еще застряли в 80-х (что было революционным в то время).
Это также напоминает мне о времени, когда можно было структурировать поисковый запрос в Интернете и найти именно то, что нужно. Нужно было просто задать вопрос на языке машины.
Я надеюсь, что обобщенное будущее этого не будет похоже на обобщенное будущее того. Сейчас чертовски почти невозможно найти что-то конкретное в интернете, потому что поисковые системы будут игнорировать любые “операторы”, которые вы попытаетесь использовать, если они выдадут “слишком мало” результатов (под которыми они, похоже, подразумевают “достаточно мало, чтобы никто не заплатил нам за показ вам рекламы по этому поиску”). Я умеренно опасаюсь, что способность получать полезные результаты от ИИ будет абстрагирована до какого-то наименьшего общего знаменателя спамного мусора, который люди захотят “потреблять” вместо того, чтобы использовать для чего-то.
Мне все еще гораздо легче сказать
“вот где найти информацию для решения задачи”
чем мне вручную вводить код, в 99% случаев
Хороший пример того, почему я полностью игнорировал людей, которые твердили о необходимости развивать навыки взаимодействия с моделями. «Учиться подсказывать» уже мертво? Конечно, истинные верующие просто назовут это эволюцией подсказок или чем-то вроде перемещения ворот.
Лично мои ворота до сих пор не сдвинулись: я буду инвестировать в использование ИИ, когда мы закончим этот грандиозный спор о его полезности. Полезность калькулятора очевидна. Полезность LLM требует 30 тыс. слов объяснений и нюансных оговорок. Я просто больше не могу даже читать рекламные тексты.
На этом этапе мы уже должны были бы давно закончить «великие дебаты о его полезности».
Если вы думаете, что это все еще дискуссия, то, возможно, вы прислушиваетесь к небольшой группе очень громких людей, которые утверждают, что с момента выпуска GPT-4 ничего не улучшилось.
Это приключение интеграции. Вот почему многие ИИ терпят неудачу на предприятии. MS Copilot умеренно интересен для данных в MS Office, но забудьте о том, что он получает доступ к 90% ваших данных, которые находятся в других системах.
Я думаю, что контекстная инженерия, как она описана, является своего рода подмножеством «инженерии среды». Золотой стандарт — это когда результат, достигнутый с помощью инструментов, может быть проверен как правильный и улучшен с помощью RL. Большая часть инженерных усилий направлена на создание среды и верификатора, в то время как азы обучения grpo/ppo и модели с использованием инструментов с открытым весом являются товарами.
Никакой инженерии в использовании ИИ нет. Оскорбительно называть попрошайничество LLM “инженерией”.
«Ух ты, ИИ заменит языки программирования, позволив нам писать код на естественном языке!»
«На самом деле, вам нужно спроектировать подсказку, которая будет очень точной в отношении того, что вы хотите, чтобы сделал ИИ».
«На самом деле, вам также нужно добавить кучу «контекста», чтобы он мог прояснить ваши намерения».
«На самом деле английский язык не является хорошим способом выражения намерений и требований, поэтому мы ввели протоколы для структурирования ваших подсказок и различные ключевые слова, чтобы привлечь внимание к определенным фразам».
«На самом деле, эти метаязыки могли бы использовать больше функций и синтаксиса, чтобы мы могли лучше выражать намерения и требования без двусмысленности».
«На самом деле… подождите, мы просто заново изобрели идею языка программирования».
Только без всего этого надоедливого детерминизма и воспроизводимости.
(Тот, кто собирается сказать «ну, температура, конечно, ноль», не надо этого делать.)
См. также: https://ai.intellectronica.net/context-engineering для обзора.
Source: news.ycombinator.com