Transcription
[музыка] Всем привет. Спасибо всем, кто смог подключиться сейчас к нам на прямую трансляцию.
А сегодня лекцию прочитает Владимир Владимирович Крылов, доктор технических наук и научный консультант по применению технологии искусственного интеллекта в разработке ПО. А сегодня Владимир Владимирович нам расскажет о том, как промцинг эволюционировал и развился в контекст инжениринг. И, конечно же, пожалуйста, задавайте все свои вопросы в комментариях на Ютубе или же в комментариях к анонсу этой лекции в нашем Telegram-канале. Ссылочка на него есть в описании под этим видео. А сейчас Владимир Владимирович, спасибо, вам слово.
>> Спасибо, Настя. Добрый день, уважаемые слушатели. Спасибо всем, кто подключился к нашему каналу. Мы сегодня говорим с вами об эволюции промтинга. Куда это идёт? И мы теперь видим, что это идёт контекст инженерингу. Вообще реакция, так сказать, сообщества на столь бурно происходящее в области промптинга, она ошаломила. Вот такие так сказать сюжеты стали повседневными на очень-очень многих каналах. Очень многие специалисты буквально сказали, что всё, и рег умирает, и промпнжениринг, и всё конец. Конец всему этому. Нужно учиться чему-то совсем другому. С чем это связано? В чём основная вообще проблема ЛМ? Почему вот направление развития применения этих моделей оказалось вот именно таким, где промптинг оказался проблематичной частью всего так сказать процесса использования языковых моделей.
Основная проблема здесь состоит в том, что всё чаще стало звучать, что основное, почему я не могу применить ЛМ, потому что у неё существуют галлюцинации. И галлюцинации появляются по неизвестным мне причинам, которыми я практически не могу управлять. Но практически не могу управлять, как правило, сводится к тому, что говорят: "Вы пишете плохой промт, попробуйте его изменить". И начались достаточно глубокие исследования, ведь с самого начала первые ЛМ давали очень высокий уровень галлюцинации. Ей совершенно было ни по чём сослаться на несуществующую статью, дать несуществующий л и обсудить эту статью в своём тексте. И вот поэтому исследования, направленные на галлюцинации, позволили построить к настоящему времени достаточно подробную таксономию. Какие же бывают эти самые галлюцинации? Вот я здесь вам табличку показываю. Вы видите, что тут 14 различных направлений, которые могут быть объединены ошибок, так сказать, возникающих при работе, которые могут быть объединены под общим названием галлюцинации. А в общем-то такие четыре основных направления - это просто фактические ошибки, то есть те утверждения, которые противоречат проверяемым фактам или консенсусу авторитетных источников. Ну, не всё можно проверить. Там какая-нибудь, допустим, существует утверждение, просто авторитетные источники с ним соглашаются, а другие, ну, может быть, какая-то доля существует, которые против этого. Спекулятивные ответы - это такие заявления, такие утверждения, которые вообще не подтверждены доказательствами и никакой фактической базы не имеют. Логические ошибки. Это просто ошибочные рассуждения, нелогичные выводы. И, наконец, есть такие галлюцинации, которые относятся к невероятным сценариям, нереалистичные, маловероятные ситуации, которые описывает как ну, имеющие значение.
Вообще говоря, обсуждался некоторое время вопрос: "А может быть, галлюцинация - это вообще не ошибка? Может быть, это некие полезные свойства? Может быть, ЛМ предсказывает что-то такое, чего мы ещё не знаем, пройдёт несколько лет и окажется, что она права. Но можно говорить о том, что можно в разных ситуациях галлюцинацию воспринимать плохой или нежелательной, но существуют и такие, когда галлюцинация является частью творческого процесса. Например, если вы создаёте сюжет фильма, просите ЛМ создать такой сюжет, то галлюцинации там могут сыграть жизненно важную роль в создании интересной истории. То есть никакими фактами это подтвердить невозможно, а вот сценарий фильма будет очень живой и интересный. Если в автопилоте это абсолютно ясно, что галлюцинация - это баг, который подлежит так или иначе устранению и борьбе с ним, то в других случаях, как, например, вот написании сценариев и другого какого-то контента, это просто фича, то есть это хорошее свойство. И вот температуру, с помощью которой мы можем при запросе устанавливать в ЛМ, обычно это учитывают, то есть устанавливают более, так сказать, фантастический уровень температуры, более высокий, чтобы возникало более свободное изложение.
Ну вот мы с вами можем говорить о галлюцинациях, но оказывается, вот я долго, так сказать, пытался тоже построить некоторые аспекты развить в том, почему появляются галлюцинации в ЛМ. И мне очень помогла книга, которая посвящена в общении ЛМ. Это книга, посвящённая галлюцинациям у людей. Оливер Сакс написал очень серьёзную, 17 глав книгу про галлюцинации, которые возникают у людей. И, знаете, из неё абсолютно, так сказать, прозрачно видно, что галлюцинация, во-первых, это не психическое расстройство, то есть это не болезнь психики, а это неврология чаще всего и связана с изменениями активности нейронов в коре головного мозга необычный в необычных условиях. А необычные условия. Вот, как правило, есть такой самый типичный случай галлюцинаций. Это синдром Шарля Бане, когда эти галлюцинации возникают, когда нарушаются какие-то источники внешние поступления информации, скажем, от глаз. Вот Шарль Банне, как правило, при расстройствах зрения возникают галлюцинаторные картины. Человек что-то видит, ему даже приятно то, что он это видит, потому что его настоящее зрение утрачивается. Слепые очень часто все обладают галлюцинациями. А вот другие варианты тоже существуют. Но вот я рассмотрел, внимательно прочитав все эти главы, там описании болезней ээ ээ людей, их рассказы, о наблюдении врачей и вот ээ нехватка внешней информации. Вот в основном, что вызывает и у людей вот эти нереальные галлюцинации. И поэтому вообще автор приходит к выводу, что галлюцинация - это часть эволюционной необходимости мозга. То есть они все возникли, потому что вот так эволюционировал мозг. Он добавлял всевозможные новые функции по мере эволюции, строил иерархические связи. И вот когда у этих иерархических связей не хватает каких-то возбуждений, которые необходимы для нормального функционирования, то есть шаг назад как бы эволюционный совершается, то начинают генерироваться явления, не связанные с внешним миром. Вот в ЛМ - это, конечно, скорее инженерная проблема, которую стараются минимизировать, но и там, и там, и у людей, и в ЛМ мы видим, как стремление к порядку и смыслу легко превращает реальность в мираж. То есть, по сути, она хочет функционировать система так, чтобы эту реальность заполнить всю, а не хватает. И вопрос, вообще-то, не в том, как остановить галлюцинации, а в том, как научиться их распознавать в себе, в других и вот в ЛМ распознавать их в алгоритмах. Вот Оливер Сакс пишет, что в большинстве случаев человек не попадает в ловушку психического заболевания, если он правильно понимает, где граница галлюцинаций, а где граница реального восприятия. И это вполне достаточно для того, чтобы водить машину, работать, заниматься тем творческим процессом, которые ему свойственны или не творческим, может быть, с какой-то точки зрения, но нахождение само по себе, наличие вот этих галлюцинаций не будет не особо влиять на его жизнь.
Ну вот в борьбе с этими галлюцинациями выработались некие, так сказать, шаблоны. Например, было придумана такая ролевая игра. И промпты, которые мы создаём, они должны начинаться с того, что мы задаём роль. Задаём роль, например, думай как миллиардер, укради мышление гения, увеличь свой доход в 10 раз за 6 месяцев дальше. И поэтому сам промпт он содержит в себе, видите, в первую очередь, действуй как основатель, а дальше, скажем, миллиардер. Если бы у тебя были мои навыки ноль долларов и ты хотел построить бизнес стоимостью 10 млн, какой был бы план? Ну и вот начинает вырабатывать этот самый план на основании такого промпта. Но если вы уберёте, действуй как основатель миллиардер, то получаемый план станет совершенно бессмысленным. И вот были построены достаточно много различных систем разработки, которые относятся непосредственно к промпт-инженирингу. Вот промттеус такой ID, который был построен, является весьма популярным инструментом для того, чтобы строить хорошие промты. Те, кто занимается этим серьёзно, несколько раз там итерирует промты, точные находит формулировки, определяет, когда какие ошибки. Вот в в промпрометеусе, в промметеусе есть как раз возможность делать это очень быстро и эффективно, пробовать на разных ЛМ, как это звучит, подгонять под некую робастность, которая позволит будущей разработке вашей существовать и на других ЛМ. И вот для того, чтобы всё это работало, при разработке ID учитывалась достаточно точная таксономия промптинга. Antropic давно уже предложил interactive tutorial. То есть вы можете запускать некие Jпиitр блокноты для того, чтобы пробовать, как будут выглядеть результаты, возвращать, как будут различные LLM вам на различные промпты. Вот этот интерактивный тюториал позволяет изучить типичные правила, которые будут, ну, если не гарантировать, то, по крайней мере, во много раз повышать эффективность ваших промптов. И вот самое последнее, что было опубликовано - это guide GPT5. Вот этот промтинг гайд оказался таким революционным, что многих погубил. Мною они делали там чуть ли в течение не 6-ти там семи месяцев. Вот, допустим, человек, который не был знаком с направлением развития вот эти reasoning models, которые рассуждающие модели, писал по одной из технологий, из техник, так сказать, промптинга. Скажем, вот эту цепочку рассуждений COT, да, Chain of Thought, вот его промпт оказался совершенно бессмысленным, бесполезным и даже вредным. Другие варианты, которые были построены по хорошо, так сказать, опубликованным, известным шаблонам промптов, стали отказывать. Под GPT5 промгай нанёс, так сказать, очередной удар, который показывает, что вот учились, учились мы Промптингу, и вдруг оказывается новые ЛМ, их целая волна. Вот те, которые занимаются ризнингом, которые занимаются рассуждением, ведь не один GPT5. И таких моделей сегодня много, и каждый из них нужно находить свой ключик по-разному формулировать задание.
Ну и вот смотрите, сейчас совершенно бешеные деньги вкладываются в то, чтобы построить дата-центры. Это уже не сотни тысяч GPU, это уже миллионы GPU начинают участвовать в разработке. Это многие сотни миллиардов долларов. И появилось такое высказывание: "Хватит промптить, начинайте в конце концов инженерить". Где же этот инжеринг, когда вот так всё зыбко и сегодня работает промпт, завтра нет? Сегодня он хорошо работает, а на другой задаче он даёт, на других данных он даёт плохие очень уровни ошибок галлюцинации или просто не удовлетворяет по какой-то там по какому-то из критериев вашей задачи. Ну вот контекст инженеринг, он теперь превращает и решение из некого общения с экстрасенсом в систему более надёжную. Процесс там основной разбор задачи, проектирование некоторой схемы, динамический поиск и замкнутый цикл инструментов. Вот это такие направления, которые позволяют говорить, что от инженеринга промптов, а инженеринг промптов тоже пошёл в направлении большей формализации. Смотрите, что получилось. Мы стали использовать некоторые действительно инженерные подходы к тому, как должен быть составлен промпт. Появились методы, например, automatic prompt engра. Это APE, когда вы используете саму LM для того, чтобы предложить там даже 50-100 вариантов инструкций тестов, небольших валидационных, так сказать, задач, на которых ваш промпт будет опробоваться. Это уже очень серьёзная работа. И здесь появился так называемый сперпромт. Этот сперпромт позволяет вот эти 50 различных вариантов построить и испытать. Появился текстград. Это вообще автоматическое дифференцирование текстов. Он работает как градиентный поиск. На множестве всевозможных промптов, которые будут порождаться, он будет вести в точку минимума, который позволит минимуму потерь, который позволит получить вам наилучший промт. Появилось APO, automatic prompt optimization, появился метапромптинг, появилась DSPY. DSPY - это удивительное, так сказать, самоулучшающееся обучение система машинного обучения. Вот смотрите, DSPY относится к тоже не градиент based continuous optimization, а есть ещё промтюнинг. Промптюнинг в различном виде, который позволяет нам генерировать так называемые софтпромпты. И появились у моделей прямо в вид запроса generate soft prompt. Сколько токенов ты на это допускаешь. И вот этот софтпромпт будет к ваш к твоему запросу конкатенирован и будет далее использоваться для того, чтобы улучшить работу, найти хороший результат, уменьшить уровень галлюцинации, уменьшить тот уровень ошибок, который у вас сегодня есть. То есть он несколько вариантов запроса порождает вот этот софтпромпт, и сразу происходит как бы файн-тюнинг нашей языковой модели. Microsoft пошёл ещё дальше. Он вообще пошёл по пути создания программированного программирования промптинга. Помол - это инструмент, это язык. Вот на языке пол записывается формально на формальном языке ваша собственно задача. Вы формулируете, что вы хотите. Ээ вот видите роль, источник приложенный изображения и приложенной задача сама describe how rocket launching space. Да. Вот, ээ, помл вдруг сделал шаг, ну, фактически назад. Мы говорили, мы откажемся от языка программирования и перейдём к программированию на естественном языке. Это и есть промптинг. И вдруг из-под Microsoft выходит язык, на котором надо сначала записать формальный язык. Язык разметки. Он напоминает чем-то нам HTML. А нужно записать вашу задачу. Самое странное потом, что LLM должна получить снова откомпилированный в виде естественного текста на естественном языке вариант вашей задачи. Помол компилируется, а потом, превратившись в текст на естественном языке, поступает в окно, в контекстное окно LLM.
Ну вот, видите, тут такое наступает очень жестокое, так сказать, состязание. Что же, может быть, вообще надо у ЛМ как-то построить вход на основе формальных языков. И вот Андрей Карпатый, который, так сказать, ведущую роль играет сегодня в области применения ЛМ, он говорит о том, что, в общем-то, дело не в том. Главное успех заключается не просто в том, как насколько изощрённо вы построите промкты. Он заключается в том, что вы правильно подберёте набор данных, с которыми должна работать ЛМ и промпт должен содержать в себе по существу вот эти данные, на основе которых будет получать вам выдавать вам качественный результат. Вот так переход к контекст инженерингу осуществляется в настоящее время.
Ну так что же такое контекст инженеринг? Вот в отличие от промтинга, в котором вы просите модель что-нибудь сделать, в контекст-инжениринге вы подготавливаете всё для того, чтобы модель могла ответить, выполнить ваше задание прежде чем вы его сформулируете. То есть, видите, в общем-то, вы получаете новую для себя проблему, но она выглядит достаточно привычно. Не только надо изощрённо как-то спросить, нет, попробуйте это сделать по-другому. Вы просите обычно, как обычно, как в простом промкте, но вам нужно подготовить всё для того, чтобы этого было информацией достаточно для того, чтобы получить качественный ответ. Как старый, как таковой промт-инжиниринг сегодня уже действительно мёртв. Это многие специалисты утверждают. То есть изощрённое конструирование промптов на основе каких-то собственных ваших мозговых движений практически больше не требуется. Но в действительности-то это не прямое утверждение, что забудьте всё, чему вас там учили. В действительности промпт инженеринг становится ещё важнее, но он претерпевает ребрендинг. И этот ребрендинг не пустой. Опять же, Андрей Карпатый говорит, что если вот вначале было софтвер и мы писали компьютерный код, потом появились ML программы машинного обучения, где главное было нахождение весов, и веса позволяли выдать правильный результат. И мы перешли после этого к софтверно. И там промпт заменил нам те необходимые представления, для которых которые необходимы для решения задачи. Так вот, сейчас мы этот промпт переводим в некоторое другое состояние, состояние понимания. Контекст инженеринг - это и искусство, и наука. Наука и искусство заполнение контекстного окна ровно той информацией, которая нужна для следующего шага. У Серёжи Булаева я взял, так сказать вот эту формулировку. Она мне очень понравилась. Ээ она хорошо продумана. И он объясняет наука, почему это и почему это искусство. Наука потому что это система описания задач, примеры. Использование баз знаний РЕК, мультимодальные данные, инструменты истории состояний, сжатие, суморизация информации. Это некоторая система технического подхода, это инженерный подход. Э, но здесь и искусство, потому что нужна интуиция, понимание психологии, модели. И вот когда у вас достаточно много контекста, то получается, что расходы растут, падает качество и результат. И вы говорите: "Такое количество токенов истратить". Экономически это становится совершенно невыгодным. Но если вы делаете слишком мало контекста, то есть как привычно стало долго и вот до сравнительно время при работе с ЛМ формулировки достаточно короткие наших промптов, то не справится модель просто с вашей задачей. Вот термин контекст инженеринг таким образом - это некая полезная абстракция. Она хороша, когда вы рассуждаете, обсуждаете насущные проблемы, которые возникают при создании внутри в составе некоторого агента искусственного интеллекта. То есть есть это некоторое расширение, в общем-то, смотрите, это retrieval augmented generation. Вот и контекстный инженеринг позволяет строить вот этот агмен, то есть тот, который расширенный расширенную генерацию реализовать, но не на основе ретривола. Поэтому первая буква фактически потеряла здесь смысл, а на основе всех источников, которые у вас есть.
Смотрите, если мы будем говорить о контексте, то его понятие, вообще говоря, надо расширить. Это не просто какая-то одна подсказка, убирающаяся там внутрь контекстного окна. Вообще вы должны при проектировании сегодня вот обращение к LЛLM продумать всё, что видит модель, прежде чем сгенерировать ответ. И вы в этот контекст включаете не только системный пром инструкции, которые есть у каждой, не только не только юзеровский промпт, который вы допишите и зададите соответствующую задачу для создадите тем задачу для LН. Сюда входит, конечно, если у вас используется и вы туда направляете файлы, картинки, там ещё что-то для того, чтобы они могли быть использованы. Теперь появляются доступные инструменты. То есть вы можете теперь указать, что вы можете пользоваться такими-то инструментами, например, срчем, там, скажем, браузером, который будет посещать интернет и искать нужную информацию. Вы можете использовать history short-term memory. И эта short-term memory позволяет вам запоминать, что перед этим было сделано для того, чтобы поддерживать историю. Ну и, естественно, есть Long-term memory. Это когда записанная память всего там, допустим, что совершала вся ваша организация, весь ваш entтерпрайз, и вы можете информацию коллаборативную записывать туда. Ну вот видите, контекст тем самым включает в себя инструкции, системный пром state history, longterm memory, retriever information, rec available tools каком виде хотите, чтобы был представлен результат. То есть, вообще говоря, видите, расширение контекста, расширение этого понятия и расширение того действительно набора токенов, которые будут направлены в в окно входное контекстное окном, оно происходит на основе некой виртуальной базы знаний и выбора инструмента. Поэтому теперь вы можете А что такое инструмент? Я думаю, вы представляете, то есть вы можете использовать, вообще говоря, там любое приложение, которое есть в вашем компьютере. Или вы можете использовать там какую-нибудь, ээ, там double систему для того, чтобы быстро находить маршруты, куда нужно пройти проехать для того, чтобы достичь нужного места. Вы можете использовать там всевозможные инструменты, допустим, заказа бронирования гостиниц, бронирование просто там помещений для развития бизнеса, ещё что-нибудь такое. Вот тул становится очень важным, и он помещает, к нему будет происходить обращение со стороны ЛЛМ. И этот тул вернёт дополнительную информацию, который расширит тот содержание контекстного окна теми токенами, которые будут возвращены от этого инструмента. Структура темплейта, она примерно вот такая вот, скажем, для клода.
>> Владимир Владимирович,
>> Да,
>> Владимир Владимирович, я очень прошу прощения. У нас, а, к сожалению, немножечко подвисла ваша камера. Может быть, у вас есть возможность это исправить, не выходя из эфира?
>> Опять подвисла камера,
>> Да?
>> Аэ, к сожалению, не отвисает. Я прошу прощения у наших зрителей. А мы сейчас быстро решим этот момент и, а, непосредственно вернёмся. Владимир Владимирович вернётся в эфир буквально через одну минутку. А пока я напоминаю нашим зрителям, что у вас есть возможность задавать вопросы в чатике, в чатике на Ютубе. У вас есть возможность задавать, а, вопросы Владимиру Владимировичу в комментариях под анонсом этой лекции в нашем Telegram-канале. Ссылочка Telegram-канал, а, есть в описании под видео на YouTube, собственно говоря. Ну или же, например, вы можете по этому QR-коду подключиться, который присоединиться, который вы сейчас видите на экране. С нами снова Владимир Владимирович. Владимир Владимирович, подгрузите, пожалуйста, презентацию заново.
>> Угу.
>> И вернёмся к тому же месту, на котором остановились. Так, а пока я напоминаю нашим зрителям, что также наши, а, лекции выложены на, а, ВКонтакте, в нашей группе ВКонтакте, и также мы их выкладываем в Яндекс-музыку, если вам удобнее слушать, а не смотреть. А наш подкаст можно найти также по нашему названию Аипдеф. Владимир Владимирович, вижу презентацию вывожу. Спасибо большое.
>> Да, а я приношу извинения, но интернет работает прекрасно. Теперь вот контекст инженеринг может быть представлен сегодня как некий инженерный способ постоянно предоставлять ровно нужную информацию, инструменты в ограниченном окне контекста. И тогда будет надёжно решать любые сложные задачи. Ключевые составляющие контекста могут быть объединены в таблицу из семи составляющих. Значит, в контексте должен содержаться роль и цель, то есть понимание моделью, кто я и какую задачу решаю. Там могут содержаться также динамические знания. Это актуальные фрагменты, которые извлекаются извне, например, изкре из SQL баз, а там могут находиться также составляющие контекста из краткосрочного памяти, то есть текущие последние эн ходов, которые были совершены ЛМ. Там может быть долгосрочная память, межсеансовый профиль пользователя, корпоративная база знаний, ограничение формата, то есть в по какой схеме, в каком стиле и какая должна быть длина вывода, и оценка и логи, количественные измерения и влияние контекста. Вот эти семь компонентов сегодня являются важными. Из них вы должны исходить, если собираетесь неким регулярным способом использовать инжениринг контекста.
Ну и вот шаги основные такие рабочего процесса, контекст инженеринга. Первый - это разбор задачи. То есть вы берёте, какую проблему у вас должна решить модель. Под задача проверить всю логистику, подобрать необходимый инструмент и использовать его. Вот доска из четырёх колонок метод называется задача подзадача и инструмент данные. То есть мы вот таким вот образом будем решать проблему на первом шаге. На втором шаге мы проектируем схему контекста. Это так называемый шаблон трёхуровневого контекста. То есть вы можете записать этот шаблон в форме Джейсона файла. И как вы видите, здесь будет сначала системный промпт, юзеровский профайл. Дальше идут инструменты и источники. На третьем шаге реализация динамического поиска. Это может быть векторная база данных. Это могут быть эмбедеры всевозможные, которые позволяют превратить, скажем, SQL-базу в векторную по существу. Вы указываете, какая стратегия поиска будет указываться, будет использоваться. Сжатие. Если фрагмент слишком сильный, то следует сжать и использовать только самери по почанкам. Дальше шаг четвёртый. Регистрация и вызов инструмента и шаг пятый управление памятью. И вот, ээ, вообще, ээ, если взять вот, это такой инструмент, ээ, его он часто его называют NHN, вот этот no dimension позволяет строить эффективные диаграммы и не просто в виде графического изображения, а автоматически оркестрировать вот все эти проблемы. Вот вы видите здесь, например, мы можем строить, ээ, какие мы будем подключать модели здесь, какие мы можем подключать сюда всевозможные источники данных, другие инструменты. Вот поэтому фреймворк, который сегодня предлагает, скажем, вот context engineering framework, он выглядит в соответствии с тем, что я рассказал перед этим. Но я специально привёл вам вот эти картинки для того, чтобы вы вспомнили, если придётся этим, так сказать, вдруг заниматься, это вызовет у вас интерес, а уж результат, я вас уверяю, не заставит себя ждать. То есть контекст инженеринг заставляет, во-первых, привлечь гораздо большее внимание со стороны людей, занимающихся сегодня разработкой программных средств, потому что теперь вы начинаете думать снова в тех терминах, которых более вам было привычно, чем лингвистического конструирования промптов. Вот одна из наиболее значимых, один из наиболее значимых результатов, это было построение двенадцати факторных агентов на основе контекст engниринга. Идея здесь в том, что если раньше программы представлялись в виде, вот, скажем, 60 лет назад, в виде такого направленного графа, который был блок-схемой по существу, и мы привыкли формулировать задачу, говорить, что я, кажется, нашёл решение, когда появлялся у нас вот этот самый появлялась блок-схема и софтвер по существу работал, реализуя каждый из блоков и связи между ними как некий направленный граф. 20 лет назад стали строить асинхронные графы, вот те, которые называются DAG. И эти стали лежать в основе построения оркестраций, микросервисов, модулей, функций и так далее. И вот сегодня, значит, мы перешли к следующему шагу. Больше не нужно строить самому эти А вы можете просто строить многоагентную систему, указывать для каждого агента его поведение, и они автоматически будут оркестроваться для того, чтобы получить правильное решение задачи, откатываться при ошибках, запрашивать дополнительную информацию и так далее. Вот факторы. Я все 12 не буду демонстрировать здесь просто из экономии времени, но посмотрите, что первое, что вы должны, скажем, видеть у каждого агента, что он использует такую его задачей является преобразование текста на естественном языке в API Tool. Сегодня это выполняет, скажем, агент выполняет протокол ещё, который называется model context Protocol. Вот этот модул MSP - это как раз задача, выполняющая подключение тула через API по существу. Другой фактор, это вы должны и никуда от этого не деться, всё равно написать свой собственный промт какой-то. Третий фактор, вы должны построить контекст, построение контекста, то есть всё, что будет входить, откуда будет брать модель, необходимые данные, как она будет формировать собственное окно с привлечением вот этих всевозможных инструментов. Четвёртый фактор - это инструменты, сами выбор инструментов. И как структурировать выход? Это может быть либо там Джейсон схема, либо может быть текстовый выход, но он всё равно структурируется, скажем, по параграфам, по главам, по каким-то разделам. Пятый фактор - это мы должны, ээ, упростить после того, как всё это вы получили, упростить, значит, все состояния в контекстном окне. То есть, если там что-то повторяющееся, нужно повторяющееся или способная быть переобразовано из одного содержания в другое, то это необходимо сделать такое упрощение. Наконец, необходимо предусмотреть, в общем-то, контакт человека с любым из инструментов. Зачем это требуется, понятно. Во-первых, часть инструментов требует либо персональных
данных, либо согласие человека на то, чтобы, значит, совершить транзакцию там по его банковской карте либо ещё что-то. То есть с инструментами должен быть обеспечен обязательно контакт с человеком. Он может запрашиваться, может игнорироваться при определённых условиях, но тогда не исполняться.
Ну вот агенты должны быть небольшие, сфокусированные на отдельные подзадачи. И начало процесса может быть запущено от различных внешних приложений, от имейла, от слэка, от веб-апликейшна, от телеграмма там что угодно. И триггером должно быть предусмотрено что-нибудь из этих, ну, самых разнообразных приложений. Тогда вы получите возможность использования ваших агентов для гораздо более широкого числа задач.
Ну и вот самый последний фактор сделать, так сказать, вот так, чтобы он, ну, сокращал по возможности такое вот statтлес положение. То есть управление следующим шагом порождало новый контекст. Контекст обогащался, и агенты после того, как что-то выполнено, могли использовать уже этот новый контекст для выполнения.
Ну вот и завершения нашей сегодняшней лекции я хочу сказать, что вообще понятие расширения контекста, а оно уже перешагивает контекст как текстовое некое содержание. Вот есть такой interhuman interhuman resource. Он показывает нам, как можно сегодня использовать не только текст, а ещё и, скажем, вот изображение человека, который разговаривает с ЛМ. Смотрите, за пределами текстового контекста мы можем декодировать, расшифровывать поведение человека. И когда перед вами камера, вы туда что-то говорите, будет поступать для обработки расширенный контекст тем, что удаётся прочитать программе, что продаёт удаётся прочитать Visual LM, скажем, самые распространённые с этой картинки с аудио и видеоизображения. То есть, допустим, неуверенно эта часть была промпта произнесена задачей, будет больше уделено дальше в этом контексте тогда обработки именно этой части. Если, значит, оказалось, что тут какой-то сарказм прозвучал, будет использоваться вот по существу транскрипция того, что вы произнесли, но с учётом того, что это было произнесено саркастически, и изображение человека позволило дать возможность ЛЛМ разобраться и расставить соответствующие веса.
Ведь, вообще говоря, вся эта лм основана на tion механизме. И любые промпты, любой контекст, который мы ей задаём, он дальше подвергается сразу обработке механизмам антен. Это и self attнtion, всякие кроссотеншены и прочее всё, что там реализуется. И вот она развешивает веса на отдельные фрагменты токенов в вашем контекстном окне. И, вообще говоря, контекст инженеринг состоит в том, чтобы правильно приспособиться к тому, как работают механизмы attention в LM. Если вы это почувствуете и научитесь правильно расставлять вот все необходимые акценты внутри контекстного окна, то ЛМ уменьшает уровень своих галлюцинаций до столь же незначительных величин, какие они сегодня встречаются у людей. Когда вы встречаете незнакомого человека, вы же тоже не знаете, галлюцинирует он или нет, как он что у него там в мозгу происходит. Вот так и здесь. Но до уровня вот такой статистической значимости примерно как человека, достигнуть уровень галлюцинации с помощью контекстного инженеринга на сегодня стало совершенно естественным и достижимым.
Видите, ээ мы добрались до конца сегодняшней лекции. Спасибо вам большое за внимание. Я готов ответить на любые ваши вопросы. Спасибо, >> Владимир Владимирович. Спасибо за такую интересную лекцию. Сейчас у нас действительно блог вопрос-ответ. И я напоминаю нашим зрителям, что вы до сих пор можете продолжать задавать, а, ваши вопросы в Телеграме или на Ютубе, а, или даже ВКонтакте, может быть. Так что, а, пожалуйста, а сейчас начнём с первых комментариев. А вот замечают, ну, чтобы писать такие запросы, нужно уже быть экспертом в той области, для которой используется АИ. Аа такие запросы, судья по времени комментарии, а говорим именно о запросах в стиле контекстно инжениром, давайте скажем так. И действительно, здесь возникает вопрос, вот сейчас складывается ощущение, что искусство писать промты или, может быть, наука писать промты всё больше усложняется. Теперь нужно думать как модель, чтобы правильно объяснить ей контекст. Но не проще ли думать как человек и просто делать свои задачи самому? Не меняем ли мы шило на мыло и где-то грань разумного применения ЛМ?
Вот в контексте последних разработок >> для каждого человека грань разная. То есть некоторым вообще этот искусственный интеллект он и не нужен. И ээ он привык так жить, и ему всегда будет проще. Сегодня мы говорим о контекстном инжениринге. Почему? Потому что мы вышли за уровень чат GPT. Мы вышли за тот уровень, когда можно обойтись такой просто формулировкой. Вы знаете, почти 70% запросов, скажем, Опi оценивает к чату GPT как тестовые. 70% запросов. Люди, зная ответ, какой должен быть, спрашивают и пытаются сравнить. А вот что он выдал-то? И если плохо, удовлетворены одни, если хорошо, удовлетворены другие. Но следующего запроса, того реального, который для чего всё это делается, не делают. И это 70%. И это чат GPT, который используют там десятки, сотни миллионов уже человек. Поэтому я что хочу сказать, что да, то, что вот я сегодня рассказывал, это несколько более профессиональная сторона. Это, наверное, больше сторона разработки агентов самих. Но ведь вот смысл-то сводится к тому, что мы сами говорили: "А куда деваться будут все эти программисты, если достаточно будет просто написать на естественном языке, что я хочу сделать?" А программист-то мне тогда вообще и не нужен? Вот, понимаете? Тот круг задач, которые решаются вот таким вот способом, он будет определённый, и кого-то он удовлетворит. А кого-то он не удовлетворяет уже сегодня. Вот мы сегодня работаем над направлением, когда люди пытаются упростить себе работу, скажем, развёртывая какого-то агента у себя в десктопе, скажем, мы этого агента развёртываем и хотим, чтобы он решал достаточно сложные и комплексные такие задачи. И вот если он просто попытается в качестве этого агента использовать обычную LLM, он, как правило, упирается в тупик. Фронтирные различные модели, вот как чат GPT5, например, да, GPT5 она в себе уже не просто LLM, там целая куча уже приделана вот тех самых инструментов, э, памяти всякой и прочей. для того, чтобы это был уже полноценный агент. Но теперь вот появляется такой вопрос. Вокруг вот этого окна месседжа у вас куча там плюсик, там какой-то, тулы, там ещё чего-то. А здесь-то вам надо разобраться или нет? И поэтому отчасти я, когда готовил эту лекцию, я рассчитывал не только на тех, кто проектирует агентов искусственного интеллекта, а ещё и на тех, кто пользуется готовыми вот такими вот агентами по существу. То, что вы сейчас видите на Open, это уже не просто тот плейграунд, который был 2 года назад. Сейчас это уже агент, и уже вам надо подумать, а что за тулзы там подключить? Может, вам надо подключить интерпретатор на Python, допустим, для того, чтобы, когда она будет создавать вам ответ, могла попробовать и запрограммировать какую-то часть, и тогда исключится, например, все галлюцинации, связанные, что там больше 9.11 или 9.09, 09. Да, вот, понимаете, получается несколько такая вторая задача, контекст инженеринга - это умение работать с современными агентами. Они называются вроде также Open Chat GPT, но посмотрите вокруг, сколько всяких появилось вот этих кнопочек. Надо уметь ими пользоваться. И цель моя была сегодня ещё и такая, чтобы пытливые умытелись, а что же это такое? Так вот, оно опять появилось для того, если вы этим будете пользоваться, то галлюцинации будет гораздо меньше. На порядок.
>> Спасибо. А, Владимир Владимирович, а вас наши зрители благодарят за лекцию. преподаю в университете их в проектировании и этим летом адаптируя учебный план под текущей реалии пришёл в контекст инженирингу. А тут ваша такая удачная лекция как раз попалась. Спасибо. Спасибо и вам, что смотрите наши лекции. Благодарим. Надеюсь, вы все ещё с нами. А, Владимир Владимирович, следующий вопрос. А вы приводили в качестве примера, а скрин с инструмента N. А в последнее время не первый раз уже о нём слышу. Аа, и у нас, кстати, недавно тоже на канале демонстрировали работу с ним. Он вам нравится и, в принципе, готовы этот инструмент рекомендовать? Почему вы его в принципе выделили, если не секрет?
Вы знаете, вот такие инструменты для оркестрации, для построения интеграции всевозможных программных модулей, да, они их много, вообще говорят, но вот вот принято это так читать. NHN >> А что >> появилась в компании в 2019 году, прошло 6 лет, и она всё время развивается. Вот сегодня они решили эти проблемы с нахождением MCP-серверов, например. Вы просто указываете, к какому тулу вам надо подключиться, а NATN отыскивает теc сервера model протокол, какие сегодня есть готовые. если они к этому инструменту есть, она их сама подключит. Вот мне понравилось именно то, что она, так сказать, живая эта система. Она постоянно поддерживается в духе всего развития вот этого агентного ИИ. И мне поэтому и в то же время она оставила за собой ту автоматизацию программных процессов, которые были старые. И вот когда делаешь агента, иногда хочется что-то доброго, старого там использовать это. Почему бы это не использовать? Если вы посмотрите какой-нибудь там Gн, да, вы увидите, что вы никуда не выйдете за пределы их песочницы. А manion позволяет именно строить вот такие развитые и исторически наследующие всевозможные возможности возможности, да, слово на слово. А так вот и удобно, но она, конечно, опять же, эта диаграмма, эта система, она не совсем чайниковая. То есть у вас должен быть не лингвистической, так сказать, дух образования и мышления, а у вас должен быть инженерный. Но опять же, это ответ на тот запрос, куда денутся программисты. Угу. Поняла. Спасибо. А есть сейчас уже сейчас есть какие-то исследования, позволяющие понять, насколько лучший результат мы получаем, используя именно контекст инженеринг, а не промг промжиниринг. А может быть кто-нибудь уже сказал что-то типа мы получаем на n% лучше или что-то вроде этого?
>> Да, конечно, полно таких сообщений, очень много результатов. И, собственно, вы видите, насколько быстро происходит вот у всех практически поставщиков сервисов LLM подключение вот этих вот всевозможныхз всевозможных возможностей. Там уже появляются тулы. Вот недавно появилась память об этом. Тут же сделан был анонс, что вот в Open появилась память, потому что действительно вот вы работаете, сегодня что-то делали, завтра начинаете, хотите это продолжить, а начали новый сеанс и всё уже забыто. Такая память, которую вы могли использовать, вот этот longterm, которая она позволит вам поддерживать этот процесс. Угу. А сейчас по Промнигу уже есть куча обучающих материалов, лекций, курсов и так далее. Теперь это всё получается либо выбрасывать, либо сильно дорабатывать. Или есть какие-то области, где именно промтинг остаётся актуальным и в принципе в в контекст инженеринг можно не лезть?
Вы знаете, то, что написано в этих многочисленных гайдах илах, оно всё в принципе работает. Но когда вы, например, теперь возьмёте модель, которая предназначена для рининга, и ей распишитесь: "Делай по шагам то-то и то-то", вы получите уровень галлюцинации, уровень ошибок гораздо выше, чем если бы всё это вы не писали. То есть вы там какую-то изощрённую технику составления промпта применили, а это только погубит результат. Здесь надо просто мыслить совершенно логично. Может быть, следует начать с самого простого промпта и отдать его современные модели. Тогда вы в лучшем случае, так сказать, получите улучшение, а в худшем случае не будет ухудшения. Но, вообще говоря, промтинг для новых моделей, он начал отличаться. Вот контекст инжениринг, даже если вы не используете никаких инструментов, он уже позволяет для новых моделей получить результаты лучше. Галлюцинации уровень. Вот метрики есть различные для оценки галлюцинации. Эти показывают, что например на 30% уменьшить, это просто постоянно. Как только вы структурировали, скажем, ваш промт, так на 30% уменьшается эта вероятность. Угу. >> Очень большая цифра. А как вы относитесь к идее, что LLM пишут промты лучше нас? Иногда она звучит. Может быть, всегда стоит отдавать свои промты на редактирование моделим не мучиться?
>> Ну да, это неплохой подход. Просто здесь обычно экономика вызывает, так сказать, сомнения. Когда вы у вас вы работаете вот с этим с Юрпромптом, вы израсходуете токенов там в 10 раз больше, чем нужен вам для конкрет получения конкретного результата. И дальше вопрос, насколько часто потом вам понадобится результат? То есть одно дело, когда вы вмонтируете этот промпт в агента, понимаете, да, и дальше это будет юзаться постоянно. А другое дело, если вам нужен однократный результат, а вы вот весь этот кошмар по ромптингу 50 там 100 раз все токены повторяете и заплатите, в общем-то, бешеные деньги. Ну, наверное, для тех там, кто сидит там на 200 долларовых этих самых тарифах в Open Ну ничего, там всё равно деньги хорошие. А вот люди, которые лимитированы, это дело очень будет существенно сказываться. Угу. >> А вы сказали, что контекст инженеринг - это искусство и наука, заполнение контекстного окна. Ну и, собственно говоря, дальше определение по тексту. Искусство и наука. А как этому лучше учиться, этому искусству и науке?
>> Вообще ведь вся инженерия - это искусство и наука. Удачные проекты инженерные, они возникают тогда, когда творческий человек, привыкший мыслить достаточно широко, как это необходимо в искусстве, да, а который имеет полёт, обладает полётом фантазий, применяет регулярные, обоснованные научные знания к тому, чтобы сгенерировать то или иное техническое решение. Поэтому это всё вообще характерно для любой, мне кажется, инженерии. А здесь мы находимся на переднем гра краю этой инженерии, и здесь это наиболее становится важным.
>> Угу. А может быть, а, да, а я полностью с вами согласна. Такая а немножко мысль постругацким, как мы обсуждали это немножко до эфира. А скажите, пожалуйста, может быть, есть какие-то конкретные гайды, книжки и так далее по контекст-инженирингу, которые можно прочитать уже сейчас? Вот что бы вы посоветовали сходить почитать, посмотреть?
>> Да, конечно, уже есть. У меня есть вот даже в этой лекции я сослался на гайд, который был сделан антропиком. Ну, если нужно более детально, то я давайте я напишу прямо конкретно ссылки.
>> Угу. >> Хорошо. Спасибо большое. Кро. >> Ну, книг больших ещё, Насть, нет. То есть таких вот, так сказать, внушительных, как по промнгу. По промтингу уже понаписали очень много книг. И вот теперь их можно, как говорится, отправлять под делитег. Очень многие.
>> Понятно. Хорошо. А вот такой момент, мысль о том, что моделям нужен контекст для эффективной работы, впрочем, как и людям. Да, если взять любого человека, непогружённого в контекст, начать пытаться от него что-то требовать, навряд ли мы что-то хорошее получим. Вот эта мысль кажется довольно простой. А как вы думаете, почему к эта идея, идеи важности контекста, а, так глобально и основательно пришли только сейчас?
Но я думаю, что это просто технические возможности. Мы рано, как говорится, запустили модель как чисто языковую. Ведь всех интересовала, сможет ли она вообще формулировать результаты на нормальном естественном языке, когда к ней обращаются на естественном языке. Ведь вот на что был всегда фокус. Но обнаружилось, что даже изучив всё, что было опубликовано человечеством на этих самых в интернете, в библиотеках, в книгах, чудовищные там эти пебайты информации поглотив, всё равно она даёт нам ответы, которыми мы часто не удовлетворены. Вот эти самые галлюцинации, которые нас не устраивают, и устранить их постоянным каким-то внутренним дообучением даже теоретически невозможно, потому что вы находитесь в одном, так сказать, контекстном окне сами, как человек. У вас есть какая-то корпоративная база, есть какие-то в руках Google Search, там ещё что-то. Э невозможно их научить. Вы также, как вас, который располагает вот всей этой информацией. Вот отсюда и возникло первое ведь, что стали делать - это рег. Рек - это как раз попытка была дать возможность дополнить контекстное окном информацией, данными, которые вы только знаете. Она не могла её получить во время предварительного обучения. Это либо внутренние документы, либо содержимое вашей электронной почты там, ну и так далее.
>> Какая-то какой-то там прайс-лист вашей компании, ещё что-нибудь, понимаете? И вот появился рек, и тогда вдруг сразу оказалось возможным с помощью ЛМ решать ещё массу всевозможных задач. То есть настолько резко расширился круг, настолько резко упали галлюцинации при задании ей вопросов, чтобы было понятно, что а вот, например, с арифметикой, вы помните, может быть, первые даже мои лекции, когда мы разбирали, почему 2 + 7 она там не может найти правильный ответ. Так вот, достаточно, ведь нам понятно, калькулятор добавь, да, и всё. И вот когда подумали: "Ну давай добавим этот калькулятор". Это был первый инструмент, который добавили к ЛМ. И когда она встречала 2 + 7, она обращалась к этому калькулятору, и получался правильный ответ. И это опять расширило резко возможности. Ну и вот следующий шаг, он был по существу количественный. Давай предоставим возможность через любой апи подключаться. Если есть от инструменты какой-то апи, пусть она сама подключится и спросит.
>> Память тот самый. Да. Вот так.
>> А, хорошо, спасибо. А вот ещё одно небольшое, как казалось бы, противоречие. С одной стороны, все говорят о безопасности данных, что нельзя сообщать облачным всё подряд, ну, условно, облачным, да. Э, с другой стороны, говорят о необходимости контекста для полезных ответов качественных. Вам не кажется, что здесь есть определённое противоречие? И что вообще с этим совсем будет дальше? Все будут обзаводиться локальными моделями или как это разрешить?
Ну, понимаете, вообще говоря, когда подписывается у любого энтерпрайза какое-то соглашение об обработки данных, то сегодня существует масса форм, которые гарантируют, что не будет того-то, не будет того-то и не будет того-то. При любом, так сказать, параноидальном характере заказчика у него естественный выход. Это сделать всё у себя. Ну и пускай, как говорится, делает. Но он от этого не избавится, от контекстного инжеринга. Просто ему это будет, вот мы сейчас говорим, где-то в среднем сейчас считается где-то 10.000 долларов стоит использование Open фронтирного с собственными данными энтерпрайзовыми. Но сколько нужно будет затратить этому энтерпрайзу для того, чтобы развернуть подобную модель на своей инфраструктуре? Сколько лет она будет отбиваться? Как посчитать рои? Это тоже все считают и убеждаются в том, что если твоя задача достаточно сложная и требуются вот такие изощрённые модели, как GPT5, скажем, да, или Клод, то, в общем-то, развёртывание тебе встанет в очень серьёзную копеечку, и ты её не отобьёшь, потому что через пару лет эта задача уже будет никому не нужна, она будет решаться там за копейки. А ты вложился в эти самые в GPU, настроил там электростанцию вокруг, построил, ещё что-нибудь. Ведь это очень дорогое удовольствие. И ограничиваются тогда примерно 90 что ли процентов, я прочитал сегодня, попыток собственных собственный строить вот локальный он премиis, вот эти самые lм, серьёзные задачи, решающие. а заканчиваются ничем. И говорят, даже был опубликован такой отчёт и говорят: "Неудач, всё неудачно". Неудачно - это 90% в этих неудачах - это собственные попытки развернуть всю инфраструктуру и написать собственный софт. Понимаете? Вот здесь какая штука. Сегодня мы примерно как в семидесятые годы находимся на уровне, когда появились мейнфреймы. То есть появились вот эти гигантские компьютеры, на которые можно было отдавать задачу, решать. И к ним появились удалённые терминалы. Я сам помню, появились такие дисплейные классы, когда можно было прийти в этот дисплейный класс и работать с этим мейнфреймом в режиме разделения времени в общем-то самому. Вот мы примерно в этом сейчас находимся на этом этапе. А вот маленькие компьютеры, это были калькуляторы, в это время уже популярны были, но они, конечно, этих задач решать не могли. Даже какие-нибудь там вот у нас это в в России, в Советском Союзе были компьютеры БК0010, там это такие маленькие настольные первые такие персональные компьютеры. На них тоже уже здорово. Там можно было на бейсике программировать серьёзные, сравнительные вещи, казалось бы, делать, но всё равно это, ну, не то. Не они, они решили проблему для людей в это втянуться, но они не решали те проблемы, которые были важны в это время в инженерном, научном плане. И вот только когда произошёл следующий шаг и мейнфреймы с их мощностью удалось спрятать в одну PC в один персональный компьютер. Вот тогда это был шаг. И вот мне кажется, что на сегодня пока вот этот уровень ээ моделей, которые сегодня существуют, не будет спрятан в достаточно экономически эффективное железное решение, мы тоже не можем отказаться от этих фронтирных моделей.
>> Угу. То есть получается, нам нужно ждать каких-то карманных ЛМ, как в своё время у нас появились личные телефоны, да, но с возможностями не тех, которые есть сегодня.
Сегодня уже есть карманный. Сегодня уже на Маке вы можете запустить довольно серьёзный там deпсик или ещё что-нибудь такое. А есть Apple Silicon там, который позволяет это запускать, но они всё равно будут решать весьма ограниченный круг задач. То есть, если вы той же Сирий, там, которая сейчас будет работать вот с Apple Silicon, сM, будете задавать какой-нибудь вопрос о творчестве там Пушкина или ещё что-нибудь, она ничего вам не ответит, если это американская система. Она просто этого не знает. С языками очень резко ограничено, когда вы пытаетесь построить, да, мультилинг, практически там ничего нет. на маленьких таких моделях побольше уже там, да, начинают появляться, но опять очень ограничено. Хорошо, спасибо большое, Владимир Владимирович. Очень, а, интересная лекция, очень интересные ответы на вопросы. А, пожалуйста, обращаясь к нашим зрителям, пожалуйста, задавайте все свои вопросы, если они ещё у вас остались в комментариях в Телеграме. э там, возможно, на Ютубе, в ВК, где угодно. А мы постараемся на них ответить, передать их Владимиру, Владимиру Владимировичу. И также, пожалуйста, а, ставьте реакции, подписывайтесь на наши каналы, а на наш Telegram-канал можете перейти по QR-коду, например, который вы сейчас видите на экране или по ссылочке в описании. А это всё нам помогает делать больше качественного контента, а, и читать больше таких же интересных лекций. Владимир Владимирович у нас на канале. Так что большое спасибо и до новых встреч. Хорошего дня.
>> Спасибо всем слушателям. До свидания. Удачи всем.