I Read Claude 4's Leaked Prompt - 7 Lessons for Better AI

D-Squared www.youtube.com

Краткое содержание

В этом видео рассматриваются семь ключевых приемов из системных подсказок Cloud Force, которые помогут сделать ИИ-агентов более быстрыми, надежными и устойчивыми к сбоям. Обсуждаются такие темы, как адаптация к типам разговоров, использование инструментов в зависимости от контекста, проверка ответов ИИ, масштабирование усилий, применение хороших и плохих примеров, умеренное использование жестких правил и приоритет внутренних инструментов.

  • Адаптация ИИ к различным типам разговоров для улучшения взаимодействия с пользователем.
  • Использование инструментов и поиска в зависимости от контекста и сложности вопроса.
  • Проверка ответов ИИ и предоставление логического обоснования для повышения точности и надежности.

Сопоставление типов разговоров

Для создания более подходящего контексту ИИ важно адаптировать стиль разговора в зависимости от темы и тона. В системных подсказках Cloud Force подчеркивается, что для непринужденных, эмоциональных или сочувственных бесед ИИ должен отвечать в соответствующем тоне, сохраняя естественность и теплоту. В технических ответах допустимо использование маркированных списков, более формального стиля и подробных пояснений. Классификатор типов разговоров может помочь определить подходящий стиль ответа на основе входящего вопроса, делая ИИ более адаптивным и полезным.

Когда ИИ "может быть" прав

Определите, когда ИИ должен немедленно отвечать, выполнять поиск или предлагать поиск в зависимости от типа вопроса. Если ИИ уже знает ответ (например, на основе фактов из обучающего корпуса), он должен ответить немедленно. Если ИИ не уверен в ответе или вопрос требует актуальной информации, он должен сначала ответить, а затем предложить выполнить поиск. Для актуальных данных (например, погода, новости) поиск должен выполняться автоматически. Такой подход позволяет ИИ адаптироваться к вопросу, эффективно использовать ресурсы и обеспечивать лучший пользовательский опыт.

Доверяй, но проверяй

Если пользователь исправляет ИИ или сообщает об ошибке, ИИ должен тщательно обдумать проблему, прежде чем признать ошибку пользователя, поскольку пользователи иногда сами ошибаются. Важно избегать чрезмерной покладистости ИИ и стремиться к правильности, а не к угодливости. В случае несогласия пользователя с ответом ИИ, следует добавить промежуточный шаг, чтобы ИИ повторно задал вопрос, проверил себя и пользователя, и вернулся с выводом, подкрепленным логическим обоснованием.

Масштабирование усилий

Определите, когда и сколько инструментов использовать в зависимости от сложности задачи. Если вопрос включает веб-поиск и внутренний поиск, установите минимум в три вызова инструментов. Приоритет следует отдавать внутренним инструментам, затем внешнему поиску в Интернете и, наконец, комбинации этих двух вариантов. Количество вызовов инструментов должно масштабироваться в зависимости от сложности вопроса: от двух до четырех для простых вопросов, от пяти до девяти для анализа нескольких источников и 10+ для подробных отчетов. Важно рассчитывать бюджет для этих усилий на основе задаваемого вопроса, чтобы обеспечить эффективное использование ресурсов и отличный пользовательский опыт.

Хорошие и плохие примеры

При обучении ИИ важно предоставлять как хорошие, так и плохие примеры. Это помогает модели быстрее учиться и понимать, что следует делать, а чего следует избегать. Например, при вызове инструментов следует всегда использовать правильный формат вызова функции с XML-тегами и правильными терминами, а не использовать нефункциональные форматы заполнителей. Важно поддерживать примерно равное соотношение хороших и плохих примеров.

Жесткие правила никогда не действуют

Используйте жесткие правила ("никогда") экономно и только для очень важных задач, которые модель не должна решать по политическим, юридическим или каким-либо другим причинам. Сосредоточьтесь на том, что нужно делать, а не на том, чего не нужно делать. Если модель не соблюдает инструкции, несмотря на попытки, только тогда следует использовать отрицательные термины или писать все заглавными буквами.

Приоритет внутренних инструментов

При создании агентов для предприятий важно настроить как можно больше внутренних инструментов, чтобы предоставить пользователю максимальную денежную ценность. Сосредоточьтесь на внутренних инструментах, а затем переходите к внешним только тогда, когда внутренние не работают. Если внутренние инструменты недоступны, предложите включить их в меню. Использование внутренних инструментов позволяет ИИ выполнять глубокие исследования наборов данных компании и автоматизировать различные задачи, экономя время, деньги и получая доход.

Summarize any YouTube video in seconds

Get summaries like this one for any video, in your language, with the free Summ app.

Download on the Apple Store
Get it on Google Play

Расшифровка

YouTube Transcript Generator

0:00 Эй, что происходит, Интернет? Итак, всего несколько дней назад произошла утечка подсказок системы Cloud Force , все 10 000 слов, и я прочитал каждую строчку, так что вам не придется этого делать . Если вы создаете агентов ИИ или внедряете модели рассуждений в производство для своих приложений, эта утечка станет для вас мастер-классом и расскажет, как заставить эти модели работать на производстве. Итак, я выделил семь приемов, которые сделают ваш ИИ более быстрым, надежным и менее склонным к сбоям в работе. И это не просто теоретические советы. Это реальные подсказки, которые Anthropic использует для управления одной из самых передовых систем искусственного интеллекта в мире. Итак, если вам это интересно, давайте начнем. Итак, как всегда, OpenAI подарил нам прекрасную картинку. А это очень похоже на мультяшный субботний утренний эпизод, когда у нас есть системное приглашение Cloud 4, полученное от

0:46 этого антропного ученого по данным. Поэтому, когда я говорю «утечка», я заключаю это в кавычки. И причина, по которой я заключаю слово «утечка» в кавычки, заключается в том, что системное приглашение для облака 4 (по крайней мере, базовое приглашение) всегда предоставляется облаком. Они всегда дают подсказки, чтобы люди могли у них поучиться. Итак, у вас есть облако опуса, облако для опуса и облако для сонета. Оба они практически идентичны, за исключением названий. Поэтому они, очевидно, изменили названия сонета и опуса в системной подсказке. И, как ни странно, после свидания наступила менструация. Итак, это базовая подсказка. Но эта подсказка здесь совершенно минимальна. Поэтому они показывают только начальную часть. Но если вы зайдете на несколько GitHub, где была показана полная утечка, то увидите, что она содержит около 10 000 слов. И эти 10 000 слов включают не только базовую подсказку, но и все вызовы инструментов, связанные с ней примеры и

1:33 уроки для Fshot по всей системной подсказке. И это то, через что нам предстоит пройти. Это более подробная информация, которой я хочу с вами поделиться. Итак, вернемся сюда и, как я уже сказал, у нас семь уроков. И вы видите, что у нас здесь выстроены семь уроков . Начнем с одного и постепенно перейдем к следующему. И первым делом мы займемся сопоставлением типов разговоров. Таким образом, каждый из этих уроков, вероятно, будет состоять из двух-трех сегментов. Итак, два, которые останутся неизменными, будут приглашением. Вот это и будет темой, которую мы обсудим. И это не просто подсказка. Существует множество подсказок, которые обсуждаются в самой подсказке системы . Я просто выделю несколько из них, которые, как мне кажется, отражают эту идею, которую вы затем сможете применить к своим собственным агентам и своим собственным моделям в своих производственных приложениях. Итак, мы дадим подсказку с примером, а затем приведем основной вывод . Итак, вот наш первый пример подсказки.

2:19 И здесь есть две части, которые подстраиваются под определенный тип разговора. Поэтому, если мы прочитаем его, чтобы услышать более непринужденные, эмоциональные, сочувственные и основанные на советах беседы, Клод сохранит тон естественным, теплым и сочувственным. А затем повторяю тот же самый момент прямо под этим, и это, вероятно, через несколько предложений после этого момента, потому что я как бы вытащил эти фрагменты из системного приглашения. В нем говорится: «В неформальных беседах вполне нормально, если ответы Клода будут короткими, длиной всего в несколько предложений». Итак, это еще раз подчеркивает важность того, чтобы в этом типе разговора вы соответствовали тону говорящего человека, и в этом случае, если он сопереживающий, эмоциональный или непринужденный, вы отвечаете соответствующим образом, а затем, как правило, это было, наверное, пятью или шестью абзацами позже, он повторяет этот момент как напоминание о том, что Клод адаптирует формат своих ответов к

3:05 теме разговора. И в системном подсказке есть множество примеров, где говорится о технических ответах. Таким образом, в технических ответах вы можете использовать маркеры, вы можете быть более формальными, вы можете дать больше пояснений в ответе, и он может быть немного длиннее. Итак, самое интересное здесь то, что они просят Клода адаптировать и подгонять свой разговор на основе контекста того, что от него требуется, и тона, в котором это обсуждается. И это своего рода основной вывод для нас, которые работают с этими агентами ИИ, как в производстве, так и в основном в моделях рассуждений. И вы можете маршрутизировать эти сообщения на основе классификаторов. Допустим, у нас есть разговор, у нас есть определенный тип агента, которого мы создаем, и у него есть определенный вариант использования, который он решает, и определенный тип персоны, с которой он работает . В таких случаях, вероятно, существует от трех до пяти сценариев, в которых этот ИИ должен реагировать определенным тоном или определенной длиной и т. д.

3:52 И мы можем включить это в подсказки нашей системы . Поэтому, возможно, мы сможем добавить классификатор. Итак, классификатор типов разговоров . Таким образом, основываясь на типе поступающего вопроса, мы можем проверить или инициировать ИИ таким образом, чтобы он был более разговорным, более пояснительным, более лаконичным и т. д. А имея эти правила стиля в подсказках нашей системы, ИИ кажется более подходящим для определенного контекста, основываясь на вопросе пользователя. Таким образом, ваш ИИ становится более адаптивным на основе разговора. Итак, это наш первый урок. Наш следующий урок будет интересным. Так что это действительно относится к вызову инструмента. Поэтому я думаю, что мы, скорее всего, увидим больше подобных тем и многих других уроков, которые я расскажу о том, как эти агенты, вызываемые системой, будут в значительной степени склонны к вызову инструментов,

4:38 а также к особенностям и граничным случаям вокруг инструментов в целом, когда мы вступим в мир агентов. Итак, этот урок номер два — теперь уже не «может быть». Что я имею в виду? Ну, это действительно зависит от типа задаваемого вопроса. Итак, если ИИ уже знает ответ, то есть если это вопрос, основанный на фактах, который уже заложен в его обучающий корпус, Клод должен немедленно ответить, то есть в том случае, если он уже знает ответ. Если Клод не уверен в том, каким может быть ответ, потому что это может быть вопрос, который может включать информацию, выходящую за рамки его обучающего прогона, то есть что-то, что прошло этап обучения после проверки, Клод сначала отвечает на него тем, что, по его мнению, является ответом, а затем предлагает выполнить поиск. И, наконец, если это что-то актуальное, например, фактические данные о вчерашнем дне, новости, цены на фондовом рынке и т. д., то

5:24 поиск будет выполнен автоматически. Он не будет угадывать ответ на основе своего тренировочного прогона. Ниже я приведу примеры того, как это выглядит . Итак, это наша подсказка, а внутри системной подсказки есть множество подсказок . Поэтому я, вероятно, не знаю, скорее всего, четыре-пять абзацев, посвященных только этой теме, а именно знанию того, когда использовать определенные инструменты, исходя из вопроса, который задан вне сферы применения. Так это что-то актуальное сегодня или что-то историческое или сложное? Так ли сложен вопрос, что мне нужно использовать множество инструментов, чтобы получить действительно хорошее представление о наборе данных и затем ответить? Так что здесь речь идет о масштабе, а не о сложности. Итак, область применения здесь первая — использование инструмента веб-поиска. По сути, это означает, что нужно использовать поисковик в Интернете, когда вам задают вопрос о чем-то актуальном, если он вам нужен. И сначала он говорит, что Клод отвечает на стабильные вопросы, исходя из своих собственных обширных знаний

6:09 . Поэтому он обозначил этот вопрос как стабильный . Вот эти вопросы и есть в корпусе знаний. Так что подумайте, эм, вы знаете, сколько миль находится от Солнца до Земли, или вы знаете, что такое, какова идея, можете ли вы объяснить изменение климата или какова столица Парижа и т. д. Это стабильные факты, которые довольно постоянны во времени, а затем после этого следующий пункт, который он утверждает, касается тем, чувствительных ко времени, или когда пользователям явно нужна актуальная информация для немедленного поиска. Итак, это возвращает нас к вопросу о том, какая была погода вчера, что было в новостях вчера, какова была вчера цена акций Nvidia на фондовом рынке и т. д. Это вещи, которые очень своевременны. И последнее — может быть. Так вот этот сверху — нет. Вот этот сейчас. А вот этот вот внизу —

6:57 возможно. А может быть, это означает, что если есть сомнения относительно необходимости поиска, ответьте прямо, но предложите выполнить поиск позже. То есть сначала предлагается ответить, а затем предложить выполнить поиск. И самое классное в этом то, что ИИ адаптируется в зависимости от вопроса. Таким образом, в зависимости от заданного вопроса, объема используемых слов и т. д., ИИ выберет либо немедленный ответ, либо поиск или предложение выполнить поиск. Итак, это подсказка, и есть множество других, о которых я упоминал, но эта содержит все, что вам нужно знать. А теперь примеры. Поэтому я хотел бы привести вам несколько конкретных примеров того, как это выглядит . Итак, я задал Клоду три разных вопроса, которые вписываются в каждую из этих категорий. Итак, мы никогда не искали, иногда искали, всегда искали. Так вот, этот пункт никогда не является поиском. Итак, я спросил: «Какая столица Японии?» Он возвращается и

7:43 говорит: «Токио». Хорошо, справедливо. Так что это тот случай, когда никогда не нужно искать. Это может быть поиск. Итак, я спрашиваю: «Какие страны требуют визы для граждан США?» Что ж, это в некоторой степени постоянство, но также и изменения. Итак, изначально он выдает мне ответ: «Хорошо, вот страны, которые принимают визы, и связанные с этим требования». А в самом конце вы видите : «Хотите ли вы, чтобы я поискал самые последние требования к визам для конкретных стран, которые вы планируете посетить?» То есть, он говорит: «Мне нужно получить обновленные требования ко всему, что вас интересует». Итак, он дает мне ответ, а затем предлагает выполнить поиск. Итак, это поиск «возможно». А это всегда поиск. Итак, каков текущий обменный курс между Японией и долларом США? а затем прямо здесь сразу переходит к поиску и затем дает мне ответ. Так что ответа нет . Он просто сразу перешел в

8:28 поиск. Итак, вот четыре или три примера, которые вписываются во все три категории, о которых мы только что говорили. Итак, какой вывод мы можем из этого сделать? Что ж, если вы создаете агента и запускаете в производство модели, основанные на рассуждениях, то с этим связаны определенные затраты и задержка. Таким образом, количество вызовов инструментов, которые вы вызываете, будет определять количество токенов, которые вам необходимо использовать, и количество времени, которое вам придется ждать, пока эти токены рассуждений завершат работу, чтобы ответить пользователю. Поэтому, если они задают вопрос, который не обязательно требует поиска, вам следует немедленно перейти к ответу. Таким образом, это просто обеспечивает надежное дерево решений внутри создаваемого вами агента для использования инструментов и поиска по мере необходимости на основе задаваемых вопросов. Так что это просто хороший способ использовать ресурсы

9:15 наиболее эффективно. но и обеспечить наилучший пользовательский опыт . И это действительно очень важный момент, который нам всем следует принять во внимание. Все в порядке. Итак, наш следующий пункт — доверяй, но проверяй. Итак, у нас есть ИИ, который думает, потому что наш пользователь не согласен с ним, и он говорит: «Хорошо, я хочу быть добрым к пользователю, но мне нужно убедиться, что его несогласие на самом деле справедливо». И это один из моментов, которые они здесь привели. И мы спустимся сюда и увидим, что, э-э, заявление, которое они здесь разместили, заключается в том, что если пользователь исправляет Клода или сообщает Клоду, что он совершил ошибку, то Клод сначала тщательно обдумывает проблему, прежде чем признать ошибку пользователя, поскольку пользователи иногда сами совершают ошибки. Итак, это на самом деле, э-э,

10:02 своего рода шутка, но на самом деле это серьезно. У OpenAI несколько недель назад была эта больная, причудливая проблема с GPT40, когда она, по сути, была доброй и всегда говорила, что ты прав. Даже если вы просите его сделать что-то экстремальное или заявляете что-то экстремальное, он всегда очень любезен, даже чрезмерно любезен. А это бесполезно для ИИ. И это не то, что мы хотим привить нашим агентам, особенно по мере того, как они становятся все более умными. Поэтому они встроили это в свою системную подсказку, чтобы гарантировать, что их ИИ не всегда будет согласным. и иногда даже не соглашается с пользователем, если он действительно совершает ошибку, и он ее обосновал и признал тот факт, что пользователь неправ. И какой вывод мы можем сделать из этого? Прежде всего, в зависимости от типа ИИ и агента, которых вы создаете, а также от варианта использования, я предполагаю, что в большинстве случаев вы бы предпочли, чтобы все было правильно, а не приемлемо. Если это правда, то вам следует избегать покладистости. Вставьте

10:49 что-то подобное в системное приглашение, если необходимо, а затем всегда добавляйте промежуточные шаги, когда пользователь отклоняет то, что изначально предоставил ИИ, особенно если это логический вопрос или что-то в этом роде, то есть цель, которая может быть, эм, либо вы знаете, истина или ложь, да, да или нет и т. д. В этом случае, если это произойдет, и они отклонят, то вы должны прийти сюда, добавить этот промежуточный шаг, чтобы ИИ повторно задал вопрос, какой бы он ни был, проверил себя и пользователя и вернулся с выводом, который либо согласен, либо не согласен с ними на основе того, что он обнаружил, а затем также дал свое логическое обоснование, чтобы пользователь понял, почему. Вот и весь наш третий урок. Четвертый урок, который нам предстоит здесь, — это масштабирование усилий. Итак,

11:34 этот бот, очевидно, масштабирует лестницу усилий, и это интересно, потому что возвращает нас к вызову инструмента. Итак, это то, что мы снова увидим во многих системных подсказках в будущем для многих моделей рассуждений, и это будет выяснение того, когда использовать, сколько инструментов и в зависимости от сложности. Итак, это возвращает нас к тому, о чем я говорил ранее: ИИ использует инструменты на основе масштаба и сложности. Итак, областью поиска был тот поиск, о котором я упоминал ранее. Так следует ли искать и находить то, что актуально? Следующее, что здесь есть — это сложность. Так насколько же сложна поставленная перед ним задача? сколько вызовов инструментов необходимо вызвать и какие инструменты следует вызвать, исходя из внутренних и внешних типов вопросов. Итак, первое, о чем я хочу здесь сказать, это то, что мы устанавливаем минимум. Мы заявляем, что если заданный вопрос включает

12:21 как веб-поиск, так и внутренний поиск, мы должны установить по крайней мере три вызова инструментов для достижения этой задачи. И способ, которым мы можем указать, что их минимум три, основан на терминах, используемых в вопросе. Поэтому, если они говорят «наш, мой» или что-то, связанное с их личным пониманием, компанией и т. д., нам нужно использовать оба варианта, а их должно быть не менее трех. После этого у нас есть приоритет инструмента. Итак, какой приоритет следует отдать этим инструментам? И мы поговорим об этом подробнее на следующем уроке. Но сначала у нас внутренний звонок. Поэтому приоритетом номер один является использование внутренних инструментов для внутренних наборов данных вашей компании. Далее следует внешний поиск в Интернете, а затем — комбинация этих двух вариантов. Вот это и есть приоритет. А теперь следующее — это масштаб. Итак, сколько вызовов инструментов мне следует использовать? Не только какие, но и сколько. И здесь мы начинаем

13:07 с двух. Итак, если это простой вопрос, то мы могли бы перейти от двух к четырем. Простое сравнение вещей. Если это анализ нескольких источников, то есть если я задаю ряд вопросов, которые мне нужно сложить, а затем провести своего рода анализ этих нескольких источников данных, то это будет от 5 до 9. А затем, после этого, мы можем перейти на 10+ для более подробных отчетов. Итак, это задача глубокого исследовательского типа. И вы можете понять, является ли это глубокой исследовательской задачей, основываясь на используемых терминах. Итак, здесь они заявляют, что если они говорят «глубокое погружение», « комплексный», «анализ», «оценка» и т. д., то большинство этих терминов будут иметь по крайней мере пять инструментов, поэтому они будут соответствовать нашему среднему уровню. Но в зависимости от того, что обсуждается и запрашивается, а также от включенных наборов данных, их может быть 10 или даже 20. Так что если вы посмотрите на подсказки внутри системной подсказки, вы увидите, что 20 — это максимум, который они могут ввести. Их число не превысит 20. Кроме того, в системном

13:54 приглашении приводится ряд примеров того, что можно спросить в каждой из этих категорий. И я приведу вам краткий пример того, как это выглядит. Итак, если мы перейдем сюда, то это будет... гм, вся системная подсказка, просто скопированная и вставленная в документ Google. И если мы посмотрим на это, то увидим в самом верху этой страницы, что там говорится о примерах исследований. Итак, это примеры от простого к сложному. Итак, если мы пройдемся по этому списку с самого верха, то все просто. Здесь, внизу, все сложно. Итак, если мы посмотрим на это, то увидим, что первым пунктом является обзор нашего последнего продукта. Так что это очень простой звонок, может быть, один или два звонка. А затем, если мы спустимся вниз, может быть, к средней части. Итак, как наши показатели эффективности соотносятся с отраслевыми эталонами? Итак, это гораздо сложнее, потому что вы говорите: сначала возьмите наши данные, найдите наши данные, затем найдите внешние наборы данных, а затем проведите их комплексный анализ.

14:40 Вероятно, это будет похоже на ситуацию вызова инструмента с 5 до 9. И вот этот последний будет чем-то экстремальным. Так вот, это довольно напряжённый вопрос. В нем говорится: «Э-э, получите средний годовой доход компаний из индекса NASDAQ 100». Какой процент компаний и какое количество компаний из индекса NASDAQ имеют доход ниже двух миллиардов? К какому процентилю это помещает нашу компанию ? Действенные способы увеличения наших доходов. Итак, это очень сложная задача, и они заявляют, что, скорее всего, потребуется от 15 до 20 вызовов инструментов, поскольку вы получаете различные наборы данных. Вы проводите не просто один тип анализа, а затем ранжируете и размещаете различные элементы в разных местах. Итак, это просто показывает, как возрастает сложность и количество инструментов, связанных с каждым из этих типов запросов. Теперь вопрос: что мы от этого получаем? Какой вывод? Для меня это очень ясно, просто и очень

15:26 похоже на предыдущее, где нам нужно было понять распределение ресурсов, верно? Потому что каждый из этих вызовов инструментов стоит денег и требует времени. И если мы хотим обеспечить отличный пользовательский опыт и эффективное использование ресурсов, нам нужно знать, сколько вызовов инструментов следует использовать в зависимости от задаваемого вопроса. Итак, нам необходимо рассчитать бюджет для этих усилий на основе заданного вопроса. Поэтому, если это простая просьба, мы должны обратиться к одному ресурсу. Если это большой запрос, например, отчет на 10 страниц , возможно, количество звонков, которые вы хотите назначить своему агенту, может быть увеличено до 20 или 30. И затем у нас должно быть, возможно, какое-то числовое значение усилия, которое мы сопоставляем с вызовами инструментов, как мы сделали выше. Итак, если они делают от пяти до девяти для многоисточников, 10 для отчетов, возможно, вы сделаете что-то подобное для своего агента, основываясь на сценарии и варианте использования, который у вас есть для вашей персоны. Итак, это наш

16:14 четвертый вывод. Пятым выводом станут хорошие и плохие примеры. Это довольно распространенная ситуация, и она существует уже некоторое время, но я хотел бы подчеркнуть это здесь на всякий случай, если люди не знают: когда у вас появляется системное сообщение, вы часто не уделяете ему достаточно времени, чтобы его изучить. Поэтому обучение в основном сводится к предоставлению разнообразных примеров, чтобы убедиться, что он знает, что делать. В большинстве случаев исторически люди просто приводили хорошие примеры. Вот как выглядит добро. Со временем все больше и больше моделей рассуждений ИИ стали включать в себя как хорошие, так и плохие стороны. И это как бы микроверсия неподкрепленного обучения, потому что подкрепленное обучение — это то, к чему вы приходите на данном этапе, как бы обучая эти модели, но это как бы извращенная версия того, когда вы даете им хорошие и плохие примеры, говоря, что следует делать, а что нет. И вы можете увидеть наглядный пример

16:59 этого здесь, в этом запросе от облака, где говорится, что никогда не используйте нефункциональные форматы заполнителей для вызовов таких инструментов, как веб-поиск. Всегда используйте правильный формат вызова функции с uh со всеми правильными параметрами. любой другой формат вызова инструмента не будет работать. Таким образом, они по сути говорят о том, что никогда не используйте скобки при вызове инструмента. Всегда используйте XML-теги и правильные термины для этих инструментов. Так что никогда не использовать — это провал. Вот в чем заключается провал: если вы это сделаете, то потерпите неудачу, и они даже ясно дали это понять в самом конце. И вот тут-то и кроется что-то хорошее, это позитив. То есть это означает: всегда используйте это и никогда не используйте то. Итак, это наш хороший и плохой пример. И вывод здесь прост. Итак, как вы можете видеть из утверждения, модель обучается быстрее, если вы даете ей как хорошие, так и плохие

17:44 примеры и пропорции. Очевидно, вы не хотите, чтобы было слишком много плохого и слишком много хорошего. Вам нужно иметь примерно равное соотношение. Поэтому, если вы добавляете новый инструмент в свой агент и вам необходимо иметь несколько примеров того, как использовать эти инструменты, рассмотрите возможность добавления нескольких различных примеров того, как выглядят хорошие и плохие способы вызова этих инструментов и эффективного получения ответов. И вот еще один простой пример. Итак, в этом примере у вас есть поисковый веб- инструмент. И, например, в этом случае при поиске в Интернете вы хотите, чтобы он искал не только запрос, но и местоположение. В этом примере выполняется только запрос, а не местоположение. Так что это неудачный пример. Так что это плохой пример. Этого не хватает. И тогда хорошим примером будет случай, когда он включает в себя как запрос, так и местоположение. Итак, это наш пятый урок. Наш шестой урок здесь — жесткие

18:31 правила никогда не действуют. Это интересно, поскольку несколько противоречит тому, что Quad заявил в своем руководстве. Итак, Клод, где-то неделю назад, опубликовал руководство о том, как эффективно использовать подсказки в Claude 4 . И на самом деле, несколько дней назад я снял видео на эту тему, если вам интересно его посмотреть. И в этом они заявляют, что основное внимание следует уделять тому, что нужно делать, а не тому, чего делать не нужно. Но они противоречат сами себе, потому что используют этот метод внутри своей собственной системной подсказки для своей модели, основанной на рассуждениях. У меня смешанные чувства по этому поводу. Но я могу сказать, что они используют его экономно. Таким образом, они используют его только для очень важных задач, которые они никогда не хотят, чтобы их модель решала по политическим , юридическим или каким-либо другим причинам. Так что если вы собираетесь использовать баллы «никогда», делайте это экономно. Я расскажу об этом подробнее через секунду, но я просто хочу сказать об этом сразу. Вот

19:16 пример, два примера, взятые из подсказки помощника. Итак, здесь вверху, он говорит: «Клод никогда не начинает свой ответ с вопроса или идеи или наблюдения, которые были хорошими, замечательными, увлекательными, глубокими, превосходными или любыми другими положительными прилагательными. Он пропускает лесть и отвечает напрямую. Так что это снова возвращается к тошнотворной причуде из открытого ИИ, где вещь была слишком приятной и слишком доброй. Поэтому мы не хотим, чтобы наш ИИ был слишком приятным и добрым. Мы хотим, чтобы он был правильным и также соответствовал контексту того, что обсуждается. И здесь они дают действительно сильное никогда. Поэтому они говорят никогда здесь. Еще один здесь для авторских прав. Так что это интересно, потому что они заявили критически в самом начале этого высказывания критически. Всегда уважайте авторские права, никогда не воспроизводя большие 20- словные фрагменты контента из результатов поиска и обеспечивайте соблюдение правовых норм и избегайте причинения вреда владельцам авторских прав. Так что здесь

20:03 они пишут никогда заглавными буквами, что является еще одной вещью, которую они сказали не делать в своем руководстве неделю назад. Они сказали нет, нет необходимости кричать на свой ИИ, потому что он будет слушать. В этом случае они кричат ​​на свой ИИ и говорят, чего не делать, вместо того, что делать. Так что интересно, как, гм, они делают это для этих действительно специфических случаев использования, когда он должен избегать этого любой ценой. И вы можете видеть, что они действительно опираются на это для жестких правил никогда. Так что урок, который мы можем извлечь из этого, я уже изложил, но я переформулирую его, потому что я думаю, что очень важно, чтобы мы использовали это экономно. И причина, по которой я говорю экономно, заключается в том, что по мере того, как эти модели становятся более продвинутыми, они становятся очень хорошими в следовании инструкциям. Так что он будет делать то, что вы говорите, если вы просто скажете, что делать, вместо того, чего не делать. Так что если вы сосредоточитесь на том, что делать, а не на том, чего избегать, вы будете добиваться успеха почти всегда, большую часть времени. И в случаях,

20:49 когда это не работает, и если вы пытаетесь это сделать, но не выполняете, это несоблюдение инструкций, только тогда вы должны подумайте о том, чтобы сказать никогда или написать все заглавными буквами или сделать какой-то отрицательный термин. И, эм, это действительно единственный раз. Так что вы знаете, это, я думаю, это ...

21:52 и гм, это интересно, потому что я теоретизирую и предсказываю, что в будущем в течение следующего года или двух большая часть ценности, полученной от этих агентов, будет, когда я говорю ценность, экономическая ценность, денежная ценность будет получена от использования агентов внутри предприятий, поэтому, имея глубокое исследование наборов данных вашей компании или какой-то гм агент, который выполняет кучу задач внутри ваших наборов данных, а не просто выполняет поиск в Интернете, и вы можете видеть, как антропологи удваивают это с помощью только этих двух подсказок и множества других внутри их системной подсказки. И в самом конце они говорят, что при необходимости внутренние инструменты недоступны. Так что, если они недоступны, я даже хочу, чтобы вы отметили, какие из них отсутствуют, и предложили включить эти инструменты в меню. Так что, если чего-то нет, если оно есть, я хочу, чтобы вы затем предложили включить это, чтобы они могли использовать его позже. Так что урок здесь в том, что если вы создаете

22:39 агентов и если у вас есть возможность сделать это, я настоятельно рекомендую попытаться настроить как можно больше внутренних инструментов для вашего инструмента, вызывая вашего агента, чтобы предоставить как можно больше денежной ценности вашему пользователю для этого конкретного Вариант использования. И большинство вариантов использования агента будут иметь некое внутреннее колебание. Поэтому я рекомендую сначала сосредоточиться на внутренних инструментах, а затем переходить к внешним только тогда, когда внутренние не работают. И это, мои друзья, наш последний урок. Надеюсь, вы нашли это видео полезным, развлекательным, познавательным. Если так, поделитесь им со своими друзьями. Если вы хотите работать со мной, у меня есть компания Gradient Labs, которая помогает другим компаниям внедрять ИИ внутри компании для автоматизации различных процессов, экономя время, деньги и получая доход. Так что, если это вам интересно, ниже приведена ссылка, по которой вы можете записаться на бесплатный ознакомительный звонок на 30 минут, чтобы узнать, подходим ли мы вам

23:24 . С учетом сказанного, интернет, увидимся в следующий раз

Share

Краткое содержание видео YouTube