Transcription
Я занимаюсь AI и делюсь этим на канале AI ранец. Меня зовут Александр. Желаю вам приятного просмотра.
Сегодня поговорим на достаточно важную тему, а именно контекст engнириing. Это критически важная тема для всех, кто работает C. Вы общаетесь с GPT, с Clдом Gini в чате, либо вы занимаетесь AI-кодингом в том же cloudдкоде или создаёте AI агентов. По факту конкенериering - это основа, то, что реально помогает выжить из LLM максимум.
Но я сразу хочу сказать, что вокруг этого термина за последние месяцы развелось много хайпа. И многие думают, что контекст инжениринг - это нечто новое, то, что вообще всё меняет, весь подход и так далее. Я хочу вам сказать, что это не так. Контекст инжениринг - это не нечто новое. Это просто собирательный термин, хороший собирательный термин, который описывает работу с контекстом в AI моделях.
Сегодня мы разберёмся с тем, что такое контекст engниerриing, дадим определение, посмотрим, чем он отличается от проompt инженеринга. Почему-то, опять же, многие думают, что контекст engниerриing заменяет prompt engineering, но опять же это не так. К этому мы вернёмся немного попозже. Также рассмотрим, из каких компонентов в принципе состоит контекст, чтобы понимать, что вообще мы инженирим, когда мы говорим контекст инжениринг. Что это значит? Нам нужно разбираться, из чего состоит контекст, из каких компонентов. И в конце мы поговорим на интересную тему, почему больше контекста не значит лучше. Также затронем немного контекст road. В общем, будет очень интересно. Так что поехали.
Как всегда, давайте начнём с хорошего определения. КонExT engриering - это дизайн и построение систем, которые дают LLM иагентам правильную информацию в правильное время для выполнения какой-либо задачи. Ещё раз, то есть это продуманная сборка, подача информации, подача контекста для AI для того, чтобы она стабильно работала и делала, что вам нужно. Это не только как сформулировать вопрос, да, как дать user query в том же промжиниринге. Это, в принципе, нечто собирательно. То есть как положить инструкции, как написать промт, какие файлы загрузить и тому подобное.
Итак, как я уже говорил ранее, многие думают, что контекст engнириing заменяет проompirриing, но это не так. Почему? Потому что в самом контексте также есть промт, есть user query, то, что usер пишет в саму модель. Также есть системный промт. System промт. Его также называют инструкцией и тому подобное. То есть у нас уже как минимум, грубо говоря, два промта, две инструкции есть. И чтобы грамотно писать данные инструкции, от них очень много что зависит, если честно, нужно владеть промт инженерингом. Поэтому сразу мы видим, что контекст engниринг не заменяет промт engниринг ни в коем случае. Не путайте эти понятия.
Давайте теперь перейдём вообще к теме, из чего состоит в принципе контекст. Давайте напишем здесь контекст. И первый компонент контекста, я его, в принципе, совместил. Я сюда могу отнести memory и files и в принципе сказать, что это knowledge. Я считаю, что просто про первый контекст, в принципе, вот такая память, файлы, knowledge. Удобнее думать, что это вот одна и та же вещь. Что сюда входит? Сюда входит, допустим, история разговоров с ягентом. Сюда входят все возможные файлы. И, в принципе, вот это такая, знаете, просто, Knowledge base, грубо говоря. Конечно, здесь можно немного сделать разделение, что файлы - это больше такие статические данные. Меory там - это история диалогов, персональные предпочтения пользователей, но я решился вместить это всё в одну часть. Ещё раз, к файлам можно отнести документы, изображения, базы данных, тот же и тому подобное. Ещё, если мы говорим про AI codдинг, то к файлам можно отнести документацию. То есть, условно говоря, вы в cloudкоде создаёте сабагента и даёте ему документацию под какую-либо задачу.
Второй компонент - это tool calling. Здесь мы не предоставляем самого инструмента по факту, да, к тому же я агенту или сабагенту у вас в clудкоде том же, но мы даём описание данного инструмента. Мы говорим там модели, что вот есть такой инструмент, он делает это, это, и ты можешь им пользоваться и получать с помощью данного инструмента какой-либо контекст, например, из вне. То есть, условно говоря, в лколинг можно отнести там придумать, а, инструмент, который фейтчит информацию о том, какая сейчас погода в каком-либо городе. И Aагент с помощью данного инструмента может получить данный контекст, то есть дополнительный external контекст. контекст из вне.
Третья часть - это системный промт. Возвращаемся к системному промту. И здесь нужно вернуться опять же в prompt engриering. То есть системный проompт - это системная инструкция для агента. Например, мы пишем, допустим, a helpful assistant. Ты специализируешься на том, чтобы заказывать еду. Это есть системный промт. Но для того, чтобы составить хороший системный промт, поверьте, если вы хотите, чтобы ваша система, ваша AI система реально работала хорошо, система проompт - это одна из самых главных вещей. Здесь как бы и кроется весь промт инженеринг. Это правда важно.
Также четвёртый компонент - это user query. Это промт, который usеer пишет система. Тоже очень важно. Здесь, в принципе, тоже можно отнести это к проomнженирингу. То есть нужно составить грамотный пром, чтобы лмка тебя правильно поняла и сделать всё, как надо. В принципе, я могу выделить такие четыре основные части. Это memory, files, knowledge, это всё в одну часть идёт. Дальше calling, системный prompt и user query. Я могу вот выделить такие четыре главные части, которые и составляют контекст.
Возвращаясь к примеру про AI codдинг, когда мы создаём сабагента. Сабагенту что мы даём? Мы даём ему системный промт. Также мы даём ему tool calling. Там можно выбрать, какие инструменты он может использовать. Давайте напишем Tools. Соответственно, даём ему какую-либо документацию. Мы делаем под него специальную документацию. Можем подключить его к регу, чтобы он фейчил информацию. Даём какую-то ему мемоory прошлых, допустим, conversation. Да, это всё мы относим к мери, например. И четвёртый пункт, само собой, когда мы уже разрабатываем какой-либо проект, мы даём user query, то есть мы говорим сабагенту: "Сделай то-то, то-то, используй это, смотри документацию". Это есть user query. На примере сабагента снова можем выделить такие четыре главные части, из чего формируется контекст.
Идём далее. И сейчас вы можете сказать: "О'кей, мы поняли, что такое контекст, понимаем, что такое контекст". engриing. Но мы же можем положить, в принципе, кучу информации в контекст, и пусть лмка там сама разбирается. Можем напихать вообще всю документацию, например, все файлы, написать кучу всего в системном промте, дать миллион мпишек. Но я скажу вам, что так делать не надо. Почему? Потому что появляется такая вещь, как контекстро.
Контекстро - это ухудшение работоспособности LLM с увеличением заполнения контекстного окна. Простыми словами, чем больше информации в контекстном окне, чем больше токенов уже израсходовано, тем хуже мы будем получать ответы. Я думаю, вы сами это замечали неоднократно. Даже если взять тот же, а, чат GPT, то есть один чат, если вы его сильно нагрузили, то у вас уже такие ответы идут плохие, галлюцинация и тому подобное.
Есть отличный от Крома. Это такая векторная база данных. Они сделали его 14 июля. Context rot. How increasing input tokens impacts LLM performance. Как увеличение input токенов влияет на LM performance? У них отличный resarch. Вот мы видим, допустим, график на X оси. У нас input token length, то есть сколько токенов мы даём. И как мы можем видеть, с увеличением количества инпуттокенов перформанс реально падает и достаточно сильно. На самом деле они тут проводили очень много исследований, такие как, а, needд, то есть где-то в середине кроется needд, и модели нужно было его найти. В общем, очень интересный ресч. Я оставлю ссылочку на него в своём Telegram-канале, будет пост с этим видео, там будет ссылка. В общем, когда мы заполняем очень сильно контекстное окно, в принципе, появляется контекстрот. И это достаточно плохая вещь, и ваша, а, lm, то есть её перфомансы реально деградируют.
Поэтому главная задача в контекстнжениринге собрать все необходимые компоненты контекста, но сделать это так, чтобы не было никакой редансы. То есть собрать только самое необходимую, условно говоря, опять же, перейти в сапагента. системным пром должен быть сбалансирован. Там не должно быть куча всего, должно быть чётко и по делу Tools, если вы дадите, допустим, кучу MCP сабагенту, я не знаю, знаете ли вы или нет, нопишки они очень сильно едят токенов. То есть очень много едят токенов. Это тоже большая проблема. Поэтому, если вы дадите, допустим, 20 мпишек сабагенту, у вас контекст просто будет заполнен, потому что, опять же, каждая MCP - это расход токенов. Дальше, если вы в Memory дадите, допустим, там всю документацию по целому, я не знаю, там, Open Agency DK, условно говоря, она просто перезаполнит весь контекст. И user query тоже не нужно там писать много, много страниц. Как бы user query должен быть сбалансированный. В общем, задача контекст инжениринга взять все эти компоненты, но сделать так, чтобы всё было по делу, то есть не было никакой воды, всё чётко, ёмко, и тогда у вас всё будет нормально. работать.
В общем, я надеюсь, теперь вам понятно, что такое контекст engнириing. Вы поняли, что это не новая вещь. Мы рассмотрели, из чего он состоит, затронули Контекстро, тоже достаточно важную тему, и на примере сабагентов всё достаточно понятно, я думаю, объяснил. Если вам понравилось данное видео, обязательно ставьте лайк, пишите комментарии, что хотели бы ещё увидеть. Я благодарю вас за просмотр.