Transcription
Итак, весь мир все еще бушует из-за ИИ-агентов, и, честно говоря, этот год был отличным для этой области, и мы действительно начинаем получать представление о том, на что способна эта технология. Но в то же время становится ясно, насколько сложно все время делать это правильно на практике. Некоторые из крупнейших компаний в мире все еще испытывают серьезные трудности с внедрением ИИ в свои продукты. Так что же здесь происходит? Как все эти ИИ-агенты могут выглядеть так многообещающе в демонстрациях исследований, но при этом так сильно бороться, когда вы фактически внедряете их в продукты, которыми пользуются реальные люди? И большая часть этого ответа — это контекст. Потому что создание ИИ-агентов по-прежнему очень сложно. И в большинстве случаев проблема не в самой модели. Это также не инструменты. Это даже не сам цикл агента. Обычно мы все просто очень плохо разбираемся в контекстной инженерии в масштабе, что является действительно сложной проблемой для решения. И именно об этом я хочу поговорить в этом видео. И если вы новичок на канале, добро пожаловать. Меня зовут Дейв Абалар. Я основатель Data Luminina, и у меня есть степени бакалавра и магистра в области ИИ. Я работаю в этой области более десяти лет. И последние шесть лет я в основном занимался созданием пользовательских решений для данных и ИИ для наших клиентов, действительно в самых разных отраслях. А помимо этого, я управляю сообществом из сотен фрилансеров-инженеров по данным и ИИ, и я снимаю такие видео, чтобы помочь вам расти как инженеру, чтобы в конечном итоге вы, возможно, захотели присоединиться к нам. Итак, приступим. Теперь, прежде чем мы сможем поговорить о том, как заниматься контекстной инженерией, нам всем нужно прийти к единому мнению о том, что такое контекстная инженерия. Потому что, вероятно, прямо сейчас, если вы спросите 10 разных людей, что такое контекстная инженерия, вы получите 10 разных ответов. И чтобы объяснить это, я хочу использовать формальное определение, представленное entropic здесь, в этом отличном посте в блоге об эффективной контекстной инженерии для ИИ-агентов, на который я буду ссылаться на протяжении всего этого видео. Итак, entropic в основном говорит: контекстная инженерия относится к набору стратегий для курирования и поддержания оптимального набора токенов, которые являются информацией во время инференса LLM, включая всю другую информацию, которая может попасть туда вне промптов. Таким образом, мы видим естественное развитие, когда в прошлом году все было связано с инженерией промптов. В тот момент мы понимали, что очень важно эффективно инструктировать большие языковые модели в форме промптов, чтобы они делали то, что мы хотим, в основном. Но для создания эффективных агентов есть гораздо больше, чем просто инженерия промптов. И эта разница, на мой взгляд, очень хорошо объяснена визуально на этом изображении. Итак, здесь слева вы видите инженерию промптов. Это обычно начинается с некоторого рода системных промптов или высокоуровневых инструкций, а затем есть сообщение пользователя, которое либо пользователь напрямую отправляет в чат-систему, либо поступает из некоторой внешней системы в виде веб-хука, а затем ассистент генерирует сообщение. Это работа с LLM 101. Но затем, если мы перейдем вправо, мы увидим полный объем того, что на самом деле означает контекстная инженерия для агента. Итак, мы видим возможный контекст, который можно предоставить модели в любое время, который может быть комбинацией документов, инструментов, памяти, инструкций, знаний предметной области, файлов памяти, большего количества собак, истории сообщений, практически всего, что будет релевантно для ИИ-агента, для большой языковой модели для обработки во время инференса, может считаться контекстом. И тогда искусство и наука контекстной инженерии действительно заключается в постоянном курировании из всех возможных вариантов, которые у нас есть. Что мы берем и что мы отправляем в большую языковую модель? И тогда мы также должны учитывать, что когда вы используете LLM в сочетании с инструментами, LLM не может просто решить вернуться с сообщением ассистента, которое будет считаться окончательным выводом, но она также может решить использовать инструмент, что означает, что она генерирует входные параметры для использования инструментом, который затем выполняется в вашем приложении, которое затем генерирует вывод, который затем снова подается в контекстное окно для LLM для выполнения еще одной итерации. И это не обязательно должен быть один цикл. Если LLM, например, имеет доступ к нескольким инструментам, она может вызвать один, два, три, возможно, 10 вызовов инструментов, прежде чем решит, что достигла своей цели и вернет окончательное сообщение ассистента. Таким образом, контекстная инженерия может относиться к полному списку инструкций, извлекаемым знаниям, описаниям инструментов, выводам инструментов, памяти и истории разговоров, промежуточным рассуждениям, обратной связи от среды. Все это может считаться контекстом и будет формировать поведение вашего агента. И теперь, несмотря на то, что модели становятся все больше и больше, а контекстные окна — больше, поэтому мы можем отправлять им больше токенов, мы по-прежнему видим проблемы, когда мы просто запихиваем в них слишком много информации. И это очень похоже на людей, верно? У нас ограниченная рабочая память, ограниченное количество информации, которую мы можем обрабатывать одновременно. Поэтому, если вы посмотрите на исследования, где они выполняют так называемые задачи типа "иголка в стоге сена", где вы даете большой языковой модели просто кучу информации и просите ее найти один факт, вы можете четко увидеть снижение производительности, когда контекстные окна раздуваются. Итак, дайте LLM очень ограниченное количество информации, и она сможет идеально извлечь все факты. Дайте ей целую книгу, и результаты станут менее надежными. И теперь, хотя существуют различия в типах больших языковых моделей, например, некоторые имеют более плавную кривую снижения, чем другие, эта характеристика проявляется во всех моделях. И поэтому они рекомендуют рассматривать контекст как конечный ресурс с убывающей предельной полезностью. И поэтому, имея это в виду, контекстная инженерия сводится к поиску наименьшего набора высокосигнальных токенов, который максимизирует вероятность желаемого результата. В основном это означает, что у вас есть цель. Вы хотите, чтобы LLM решила для вас конкретную проблему. Что вам нужно предоставить LLM, чтобы помочь вам сделать это? Но это легче сказать, чем сделать, потому что именно здесь мы входим в мир инженерии ИИ и контекстной инженерии. И именно над этим целые команды тратят недели и месяцы. Тем не менее, мы по-прежнему видим, как крупнейшие компании испытывают трудности с эффективным внедрением ИИ в свои продукты. Я привел пример Microsoft во вступлении к этому видео, но ранее в этом году у нас были Apple и Amazon с похожими неудачами, когда им буквально пришлось отозвать некоторые из своих продуктов ИИ. И теперь, хотя у меня, безусловно, нет всех ответов для вас, это по-прежнему очень сложная задача. В оставшейся части этого видео я дам вам несколько практических выводов, касающихся контекстной инженерии, основанных на том, что мы видели и что работает для продукта, над которым мы работали, а также на том, что рекомендуют некоторые ведущие компании, такие как Entropic, с точки зрения лучших практик. И теперь давайте начнем с советов и стратегий для системных промптов. И теперь вы знаете, что контекстная инженерия — это больше, чем просто промпты, но это, безусловно, важно. И то, что мы видим на практике, а также то, что подчеркивается entropic здесь, заключается в том, что существует тонкий баланс между тем, как вы получаете системный промпт именно таким, каким он должен быть, где обычно люди начинают со слишком общего, а затем со временем становятся слишком конкретными. Так что это наглядно проиллюстрировано на этом изображении с некоторыми примерами. И обычно, как это происходит в реальном мире, когда инженер или разработчик начинает проект, они начинают с некоторого базового промпта типа "вот что должна делать система". Затем они выпускают его. Затем пользователи начинают тестировать его и жаловаться. Таким образом, они собирают список отзывов, таких как "эй, это идет не так". Если ИИ, если я скажу это, ИИ должен сказать то, а не это. Тон должен быть более непринужденным. И вы получаете целый список всех этих типов проблем. Затем, что происходит? Обычно люди берут все эти проблемы и жестко кодируют их в системный промпт. Таким образом, вы переходите справа, где он слишком общий, вы переходите больше влево, где он слишком конкретный, и у вас буквально есть операторы if-else внутри системного промпта. Теперь это работает до определенной степени. Если это всего лишь несколько случаев, если это небольшое приложение, не такая уж большая проблема, это вполне работает, особенно если вы используете новейшие и лучшие модели, но это не масштабируемое решение. Таким образом, в какой-то момент вы действительно упретесь в стену, потому что вы раздуете контекстное окно. И как мы теперь знаем, когда оно становится слишком большим, например, у вас есть системный промпт, много сообщений пользователя, у вас есть данные там. Теперь все вдруг начинает пренебрегать или игнорировать некоторые из правил, которые вы там указали. Таким образом, калибровка системного промпта заключается в том, чтобы быть достаточно конкретным, но также позволять LLM быть творческой, а не давать ей построчные операторы if-else. Если вы продолжаете сталкиваться с проблемами, которые вы не можете решить, обычно гораздо лучше просто разделить промпт на две подзадачи и добавить перед ним маршрутизатор, где вы в основном позволяете ИИ-агенту решать, например, "должен ли я идти туда или туда?". И теперь вы уменьшаете размер проблемы и, следовательно, размер промпта. И это работает гораздо лучше, чем просто запихивать все в один большой промпт и позволять ему быть вашим единственным агентом, который решает все. Так что на самом деле речь идет о том, чтобы получить промпт именно таким, каким он должен быть. Так что убедитесь, что вы также следуете всем лучшим практикам промптинга, верно? Год назад мы все действительно пытались разобраться в этом. Но сейчас вы можете даже зайти на Entropic или OpenAI и буквально посмотреть их руководства, где они указывают структуру. Таким образом, обычно рекомендуется иметь четкие разделы либо в XML, либо в markdown, где вы говорите: "Вот ваша фоновая информация. Вот ваши инструкции. Вот ваше руководство по инструментам. Вот описания ваших выводов." И это должно быть кратко и сфокусировано. А затем, быстро, если вы разработчик с навыками ИИ и думали о фрилансе, выполнении побочных проектов или просто работе над более интересными задачами, но не совсем уверены, с чего начать, возможно, вам стоит ознакомиться с первой ссылкой в описании. Мы управляем сообществом из сотен фрилансеров-технологов, и мы все помогаем друг другу получать больше клиентов, создавать лучшие системы и работать над более значимыми проектами. Так что, если это звучит как вы, обязательно ознакомьтесь. Итак, вернемся к видео. И мы постоянно сталкиваемся с этими проблемами в консалтинговой работе, которую мы выполняем. Так, многие клиенты приходят к нам с уже существующим продуктом, над которым они работают, но они не удовлетворены результатами. В целом, это некоторые типы ассистентов, которые должны следовать некоторому пути, чтобы помочь пользователю достичь определенной цели, будь то прохождение оценки, прохождение некоторых видов терапевтических сеансов, коучинговых сеансов или просто помощь пользователю в решении проблемы, и тогда в начале они работают эффективно, но затем со временем производительность начинает снижаться, так что в какой-то момент это просто перестает иметь смысл. И тогда, когда мы погружаемся в кодовые базы, мы часто видим похожие шаблоны, где, во-первых, промпты слишком ограничительны с большим количеством негативных примеров, таких как "не делай этого, не делай того". Потому что это естественно происходит, когда пользователи начинают собирать отзывы, и пользователь говорит: "Смотрите, этого не должно быть", а затем разработчик берет эту информацию и вставляет ее в промпт. "Не делай этого. Не говори этого." Но вот что большинство людей не осознают. LLM не очень хорошо справляются с негативными примерами. Они действительно процветают, когда им дают положительные примеры. Это действительно концепция "картинка стоит тысячи слов". Положительный пример, означающий "вот как должен выглядеть ответ", намного лучше, чем негативный пример, говорящий "не делай этого". Просто скажите ему вместо этого, что делать. И мы также часто видим, что то, что изначально работало в решении для эффективного управления контекстом, не работает в масштабе или когда пользователи глубже погружаются во взаимодействия или глубже в разговоры. И именно здесь вам действительно нужно быть умным в отношении динамического внедрения системных промптов, например, суммирования или обрезки истории сообщений, чтобы снова освободить некоторые из этих токенов. Таким образом, в большинстве этих случаев эти ИИ-агенты терпят неудачу не потому, что они не могут рассуждать или потому, что модель недостаточно умна, а потому, что они рассуждают над плохим контекстом. Потому что инженеры, стоящие за этим, действительно настроили приложение так, чтобы оно либо давало слишком много информации, либо слишком мало противоречивой информации, либо устаревшей информации. И то, что мы наблюдали со многими клиентами, с которыми мы работали, многие инженеры, многие разработчики переходят в инженерию ИИ. Таким образом, они могут быть отличными инженерами и иметь многолетний опыт в разработке программного обеспечения, но иметь очень мало опыта работы над проектами ИИ, и, в частности, работы с недетерминированным программным обеспечением или моделями и языком. Поэтому часто я вижу, что многие разработчики не смотрят на данные и не воспринимают промпты достаточно серьезно, а затем, например, берут отзывы клиентов и просто буквально бросают их в ИИ, бросают их в cursor или cloud code и говорят: "Вот проблема, исправь промпт", но вместо этого вам следует анализировать, откуда возникают эти проблемы, а затем давать положительные примеры. И именно здесь вы можете позволить ИИ помочь вам оптимизировать эти промпты, но не наоборот. И помимо этого, я также уже упоминал, что инженеры обычно недостаточно смотрят на данные. Так что одна из хитрых вещей при создании продуктов LLM заключается в том, что когда вы находитесь в своей IDE, когда вы структурируете промпты, очень трудно получить представление о фактической истории сообщений, о том, как выглядит взаимодействие людей с вашим приложением. И именно поэтому так важно уже на раннем этапе интегрироваться с каким-либо инструментом трассировки, таким как Langfuse, например, который мы используем для всех наших проектов, где вы действительно можете видеть полное дерево разговора, полную историю сообщений, включая вызовы инструментов, потому что обычно, если система LLM ведет себя не так, как ожидалось, если вы посмотрите на полную трассировку, вы увидите системный промпт, первое сообщение пользователя, сообщения от пользователя и затем все это в совокупности, вы почти всегда можете немедленно обнаружить ошибку. Вы можете немедленно обнаружить, откуда исходит ошибка, потому что эти модели, особенно если вы используете лучшие модели, они уже настолько мощные. Дело не в том, что они достаточно умны. Дело не в том, что они не могут рассуждать, а просто в том, что вы спроектировали контекст таким образом, что он больше не имеет смысла для модели. Еще одна проблема, которую мы часто видим, заключается в том, что инженеры не знают, когда использовать простой рабочий процесс, где вы можете использовать LLM, против того, когда вы на самом деле будете использовать агента, потому что есть разница. И хотя термин "агент" применяется практически ко всем программным продуктам, использующим LLM, есть разница. И ранее в этом году я сделал целое видео об этом, которое набрало почти полмиллиона просмотров, что безумно. И там я также рассмотрел пост в блоге от Entropic, охватывающий некоторые шаблоны и действительно демонстрирующий, что работает в производстве прямо сейчас, где в большинстве случаев, когда вы пытаетесь автоматизировать бизнес-процессы, простые рабочие процессы, где вы используете маршрутизацию, цепочку промптов, вы все еще используете вызовы LLM, но это не совсем агентское. В большинстве случаев это вполне нормально и гораздо надежнее. То, что на самом деле считается агентом в настоящее время, — это LLM, которая автономно использует инструменты в цикле для решения конкретной проблемы. Так что это такие инструменты, как claw code или cursor. Они действительно агентские. Но для большинства инженеров, смотрящих это видео, вы, вероятно, не создаете следующую ChatGPT, Cursor или Clock Code. И если вы это делаете, вы, вероятно, уже знакомы с концепциями этого видео. Но большинство людей, включая меня, мы создаем автоматизации ИИ для решения общих бизнес-процессов. И знание того, когда простой рабочий процесс, который очень строгий, и вы пытаетесь сделать его максимально детерминированным, достаточно хорош, по сравнению с созданием агента с этим одним промптом, а затем множеством инструментов и субагентов, которые могут быстро стать беспорядочными. И теперь мы определенно видим тенденцию, поскольку модели становятся все более и более способными, они могут работать с большим контекстом. Они могут работать с большим количеством инструментов. Они определенно становятся мощнее. И я вижу будущее, где мы можем просто решать бизнес-задачи с помощью LLM, предоставляя им инструменты и просто позволяя им работать в среде. Но сейчас это все еще компромисс, который вы хотите сделать. Использование инструментов и позволение агентам работать в циклах очень хорошо работает в чат-ассистентах, приложениях в стиле ChatGPT, где пользователи находятся в цикле, где пользователи контролируют. Так что это то, что у вас есть в ChatGPT, Cursor, верно? Вы задаете ему вопрос, модель уходит, а затем возвращает вам результат, но он не всегда на 100% правильный. Так что, но поскольку вы находитесь в цикле, потому что у вас есть окно чата, вы можете корректировать курс, и вы все еще контролируете. Но для многих бизнес-сценариев это либо своего рода бэкенд-автоматизация, либо напрямую ориентированная на клиента, где, если клиент взаимодействует с вашей службой поддержки клиентов с помощью ИИ, вы, вероятно, не хотите, чтобы она говорила: "Вы действительно уверены, что это правильно? Я думаю, вам нужно использовать этот инструмент, чтобы получить правильную информацию." А затем LLM говорит: "О, да, вы правы. Это не так работает." Вы хотите, чтобы она, в основном, за один раз сделала это хорошо. И аналогичным образом, когда вы работаете над каким-то типом бэкенд-автоматизации, которая запускается веб-хуком, обрабатывает некоторую информацию и затем помещает ее в систему, это, как правило, там, где у вас нет человека в цикле, потому что это была первоначальная цель задачи — автоматизировать ее. Так что люди больше не нужны. Так что вам не нужен этот человеческий надзор. Поэтому в таких сценариях вы хотите гораздо большего контроля над тем, что делает ваше приложение. Таким образом, когда дело доходит до контекстной инженерии, также нет одного прямого способа сделать это. К сожалению, нет хака, который работает все время. Но именно поэтому это так сложно, особенно в масштабе. Существуют только лучшие практики и рекомендации для различных типов информации, которую вы можете предоставить вашей большой языковой модели. Итак, еще раз вернемся к изображению. Когда вы говорите о документах, если документ становится слишком большим, вы, вероятно, не хотите помещать весь документ в сам контекст. Вот где может пригодиться RAG. И тогда с RAG также поймите, сколько фрагментов вы извлекаете из базы данных фабрики? Возможно, вам придется сначала применить реранкер. Таким образом, вы сначала идете широко, получаете 50 фрагментов, используете реранкер, получаете топ-8 результатов. Это все стратегии, которые вы можете изучить, если вы с ними не знакомы, которые могут помочь вам управлять документами и контекстом из этих документов в масштабе. Далее у нас есть инструменты. Это обеспечение того, чтобы вы не раздували своего агента инструментами, а также инструментами с очень длинными описаниями. Таким образом, инструмент также вводится в контекстное окно. Поэтому инструменты должны быть краткими, описательными, сфокусированными. Они не должны быть запутанными или пересекающимися. Вы также всегда можете попытаться создать своего рода субагентов, где один агент может быть либо доступен системе как вызов инструмента, а затем иметь под ним инструменты, либо вы можете использовать подход рабочего процесса, где вы просто создаете маршрутизатор и передаете его другому вызову API LLM. Это все шаблоны, которые вы можете использовать, чтобы разделить его, но сделать его ясным и не делать проблему, а следовательно, контекст слишком большим. И тогда следующее — это память. Это весь разговор, история сообщений, идущая туда и обратно между пользователем и ассистентом. И теперь это сложный момент, потому что это часто область, где вы не увидите никаких проблем во время разработки, потому что вы запускаете эти короткие изолированные примеры с несколькими сообщениями туда и обратно. Но именно на это начнут жаловаться пользователи, когда они скажут: "Да, на 10-м шаге он полностью забыл, о чем мы говорили, и перестал следовать моим инструкциям". Поэтому в любое время вы хотите следить за историей сообщений и либо обрезать ее, просто удаляя более ранние экземпляры из истории сообщений, либо брать, скажем, первые 20, суммировать их, а затем помещать в разговор. Опять же, есть всевозможные трюки, которые вы можете сделать, и опять же, это станет очевидным, если вы просто посмотрите на полную трассировку от системного промпта до всего разговора пользователя. Если вы посмотрите на это и скажете: "Черт возьми, это слишком много информации", то это, вероятно, сигнал того, что LLM также испытывает с этим трудности. И тогда, когда дело доходит до промптов, у нас, конечно, есть исчерпывающие инструкции и знания предметной области. Это действительно то, где вам нужно найти баланс между тем, чтобы быть достаточно конкретным, не быть слишком расплывчатым, и не чрезмерно инженерить промпт с операторами if-else с большим количеством случаев. И особенно вы хотите избегать негативных случаев. Так что используйте примеры с несколькими выстрелами с положительными примерами того, что модель должна делать. И если промпт и случаи становятся слишком большими, слишком объемными, разбейте их на другую проблему. И что также очень эффективно для управления этим, это то, что вы используете какой-то тип конечного автомата, где вы отслеживаете состояние. И в зависимости от состояния, в котором находится пользователь, у вас есть другой системный промпт или, по крайней мере, другая часть системного промпта. Так что, скажем, вы проводите пользователя через поток, будь то оценка, онбординг или что-то еще, и в зависимости от того, где пользователь находится в этом путешествии, у вас могут быть разные инструкции, потому что если вы захватите всю оценку в один большой системный промпт, говоря: "Сначала нам нужно сделать это, а если это завершено, нам нужно перейти к этому этапу", то это, как правило, сигналы, что вы хотите разбить это и просто отслеживать это состояние в базе данных, а затем во время выполнения при каждом сообщении от пользователя вы просто извлекаете этот контекст из базы данных и помещаете его в память. Вот где вы проектируете историю сообщений. Таким образом, в этом смысле контекстная инженерия также не обязательно должна быть линейной, где вы просто смотрите на историю сообщений и просто обрезаете или суммируете ее, когда она становится слишком раздутой. Она также может означать, что вы отслеживаете определенное состояние и в зависимости от этого состояния извлекаете разные системные промпты. Возможно, полностью избавляетесь от истории сообщений или строите ее таким образом, где вы стратегически реализуете определенные сообщения в определенный момент истории разговора. И это может идти туда и обратно или даже в циклах снова, как это действительно зависит от проблемы, которую вы решаете, и приложения, которое вы строите. Вот что такое контекстная инженерия, и она очень креативна, и проблема в том, что она часто скрыта во время процесса разработки, потому что контекст накапливается по мере того, как вы начинаете взаимодействовать с системой. И это то, чего многие инженеры, работая над продуктом, на самом деле не делают и не привыкли делать, потому что они привыкли писать функции, писать модульные тесты, а затем видеть, что они проходят. Но ключ к созданию эффективных систем ИИ заключается в том, что им не нужно проходить один раз. Им не нужно проходить дважды, но им также нужно проходить на 10-м шаге и на 20-м шаге. И вот где возникают все сложности. Итак, это все для этого видео. Спасибо за просмотр. Надеюсь, вы нашли его полезным. И если это так, пожалуйста, поставьте лайк и подпишитесь. А теперь, если вы новичок в создании ИИ-агентов и хотите лучше понять шаблоны, которые вы можете использовать, я рекомендую посмотреть это видео. Если вы уже немного более технически подкованы и немного занимались созданием систем ИИ, то я рекомендую это видео, потому что там я рассказываю обо всех инструментах и библиотеках, которые я использую для создания производственных систем ИИ. Так что выберите любое из них, и тогда вы сможете продолжить обучение, и я увижу вас в следующем.