Transcription
Привет всем и добро пожаловать на этот урок. Как вы можете видеть на экране, мы собираемся решить одну важную проблему, с которой вы столкнетесь, когда будете работать с агентами, ИИ-агентами, а также в рамках экзамена. Итак, у вашего ИИ-агента есть проблема с памятью, и как вы ее решаете? Вы, по сути, представьте себе это, верно? Вы потратили недели на создание агента поддержки клиентов, как мы делали в этой серии, верно? Он решает множество проблем, таких как споры по биллингу, обработка возвратов, вы знаете, он также обрабатывает крайние случаи. Тестирование также очень надежное. А затем вы выпускаете его в продакшн. Вот куда вы его выпускаете, верно? Вы не отправляете его куда-то еще, верно? Итак, через 3 недели, верно, поступает жалоба клиента. Агент дал ей неверную сумму возврата. Это сценарий. Я имею в виду, не потому, что он сделал ошибку в расчетах, верно? потому что вы сделали его безошибочным. Вы знаете, он обрабатывает каждый вид возврата. Он проверяет его дважды и все такое. Но все же он дал ей неверную сумму возврата. И очень важно понимать эти мелкие проблемы, когда мы приближаемся к собеседованию или готовимся к экзамену. Верно? Я имею в виду, он не сделал ошибку в расчетах, потому что он забыл, какой была сумма. Верно? Итак, через 20 сообщений в длинном разговоре детали из начала просто исчезли. Теперь это проблема памяти. Я имею в виду, это реально и очень распространено. Это одна из самых распространенных проблем, которую вы увидите, и она может тихо разрушить производственные системы, которые, казалось бы, идеальны. Так что это одна из вещей, которую мы будем решать в этом конкретном эпизоде. И следующая вещь, которую мы будем решать в этом эпизоде, — это шаблоны эскалации. Итак, у вас есть автоматизированный агент, верно? Когда агент должен эскалировать к человеку? Потому что в какой-то момент будет барьер, который агент не сможет преодолеть, и в это время необходимо вмешательство человека. И я также покажу вам в нашем проекте, который мы строим, нашего агента поддержки клиентов, и я построил здесь очень маленький шаблон эскалации, когда он должен эскалировать к человеку-агенту, и мы также подробно обсудим это, и это будет интересно. Так что просто оставайтесь с нами, и мы увидим много всего. Итак, как я уже говорил, в этом эпизоде мы решим две проблемы, верно? одна — это сохранение контекста или проблема памяти, которую мы только что обсудили, а вторая — шаблоны эскалации, потому что эти две части связаны, вы знаете, так что агент, который не может правильно хранить свою память, не может принимать хорошие решения об эскалации, верно? просто держите это в уме, сравните это со своим обычным сценарием использования, своим обычным повседневным сценарием использования, если вы что-то не помните, как бы вы ответили или как бы вы это эскалировали, верно? это простой вопрос, который вы можете задать себе. Хорошо, давайте двигаться дальше.
Теперь давайте поговорим о контекстном окне. Итак, контекстное окно — это рабочая память вашего агента, верно? Вам нужна надежная ментальная модель того, что такое контекстное окно. Очень важно, чтобы вы понимали, что это такое. Затем вы перейдете к решению проблемы. Так что думайте о контекстном окне как о своем рабочем столе, верно? Вы видите, это ваш стол, и вы идете и обустраиваете свой стол, что-то вроде вашего рабочего стола, верно? Все на столе сразу доступно, вы можете увидеть это, сослаться на это и использовать это немедленно. Вам нужна ручка, она здесь. Вам нужны какие-то документы, они здесь. Что-то вроде этого. Это все, что вы расставили на своем столе, но у стола есть предел размера, очевидно. У стола есть, он не растет бесконечно, верно? У вас есть своего рода маленький диск, вы нашли маленький диск, у вас есть маленький диск. Если у вас есть большой диск, каждый диск имеет свои ограничения по размеру, очевидно. Так что, когда вещи заполняются, вещи начинают выталкиваться за край, и как только что-то соскальзывает со стола, это может быть так, как будто его не существует. Я имею в виду, если что-то упало, у вас была синяя ручка на столе, и она упала, и вы этого не заметили, когда она упала. Теперь, когда вы ищете синюю ручку, ее нет. И через некоторое время вы даже забываете, что у вас вообще была синяя ручка. Вы идете и покупаете новую ручку. Верно? Точно так же работает контекстное окно. Оно удерживает все в разговоре одновременно. Верно? Итак, что оно удерживает? Системный запрос, который, по сути, является инструкцией Claude для выполнения задачи. Я имею в виду, какую личность Claude, по сути, имеет, вот что такое системный запрос. И после этого он также будет хранить каждое сообщение в разговоре, которое, по сути, от пользователя к Claude. Вы ходите туда и обратно в своем агентском цикле, верно? Все эти сообщения вы добавляете и отправляете. Так что это тоже в контекстном окне. Затем вы также совершаете некоторые вызовы инструментов, верно? Это также будет частью этого, а также результаты инструментов. Итак, все эти вещи: ваш системный запрос, ваши сообщения, ваши вызовы инструментов и ваши результаты инструментов. По сути, это все вещи, которые мы используем в конкретном агентском цикле, верно? Так оно и будет. Все это имеет значение, верно? И все это находится на одном столе, а размер этого стола измеряется в токенах, которые мы уже знаем. Так что, по сути, ваш сайт, вы знаете, ваш стол — это контекстное окно. Весь, вы знаете, размер стола — это, по сути, токены, верно? Так что разные подписки, которые предлагает Claude, например, давайте возьмем эту ментальную модель. Если вы возьмете подписку Pro, ваш стол будет маленьким, поэтому вы сможете держать на нем только определенные вещи. Если вы перейдете на подписку Max, то ваш стол будет очень большим, поэтому у вас будет очень большой контекст, который может вместить много токенов, по сути. Так что я надеюсь, что это имеет смысл.
Теперь одно замечание по экзамену, которое я хочу сделать, это то, что API Claude является без состояний. Так что это значит? Вы можете видеть, что это также на экране. Вы отправляете полный разговор с нуля при каждом вызове API. Это то, что я говорю в агентском цикле. Вы продолжаете добавлять эти сообщения, верно? Вы знаете, каждый раз, когда вы отправляете эти сообщения, вы знаете, какие бы результаты ни пришли, вы добавляете их, а затем отправляете обратно в Claude. Нет серверной памяти. Я имею в виду, нет постоянных сессий. Вы знаете, это похоже на то, что управление контекстом требуется архитектурно, иначе это сломает многие вещи, и те проблемы, те проблемы с возвратом, которые мы только что обсуждали в начале этой лекции, будут происходить чаще, потому что, вы знаете, вам нужно помнить, что Claude забудет, если вы не управляете этим контекстом должным образом. Хорошо.
Итак, когда возникают такие проблемы, верно? Я имею в виду, когда контекстное окно переполняется, что-то должно уступить или что-то должно быть сделано. Так что разработчики фреймворков, вы знаете, естественно, есть для суммирования, что в порядке. Я имею в виду, это отличный способ сохранения контекста. Кстати, есть также один инструмент, я имею в виду, команда, которая приходит, известная как, я имею в виду, вы знаете, это сжатие, обычно используется в сеансах Claude, но здесь это немного отличается, когда вы имеете дело с производственными системами ИИ-агентов, такими как агент поддержки клиентов, просто предоставление обычного, я имею в виду, своего рода резюме без большого количества фактов не сработает, верно? потому что резюме теряют точность. Теперь, когда вы работаете в сеансе кода Claude, например, вы получаете резюме, а затем повторно используете это резюме, это нормально, потому что это своего рода обобщенное резюме, которое вы даете Claude. Хорошо, это код, который я написал, и вот какие изменения вам нужно внести. Но когда дело доходит до приложений, где вы создали ИИ-агента, которому нужен точный клиент, который пострадал, какой возврат был обработан, и все эти проблемы, им нужны фактические данные вместо того, чтобы сказать, что какой-то возврат клиента произошел, но какой возврат клиента произошел, этого может не быть в резюме, которое вы генерируете, и это проблема. Так что резюме теряют точность. Важны конкретные идентификаторы. Какой был идентификатор клиента? Какова была сумма возврата? Числа, даты, все эти вещи нужны для производственной системы ИИ-агента. Он также может забыть пороговые значения политики. Вы не знаете, что он забудет. Так что это будет испарено этими ленивыми резюме, верно? Так что же такое ленивое резюме? Я только что привел вам пример. Например, ленивое резюме: клиент сообщил о проблемах с доставкой и продуктом, запрашивая возврат. Нет данных о том, какой клиент и какие проблемы с продуктом. Но что такое хорошее резюме? Заказ № 12345, скажем, верно? И название продукта? Беспроводные наушники, скажем. Какова была цена? 149 долларов. Какова была проблема? Доставлено с опозданием на 3 дня или что-то в этом роде, вы знаете. Так что, просто сравнив оба эти резюме, вы поймете, что было уничтожено. Вы знаете, номер заказа, необходимый для обработки возврата, точная сумма в долларах, все самое важное было потеряно, когда вы просто даете случайное, предварительное, неточное резюме, верно? И таким образом, даже если вы генерируете резюме, Claude не сможет понять, хорошо, для этого клиента мне пришлось обработать возврат или что-то в этом роде, верно? Так что я надеюсь, вы понимаете, почему резюме хороши и почему в этом конкретном сценарии критических систем резюме могут не работать.
Итак, одно замечание по экзамену, которое я хочу сделать, это то, что прогрессивное суммирование, которое теряет числовые значения, мы только что это обсуждали, верно? конкретные даты или критические пороговые значения политики — это режим отказа надежности, верно? это не проблема эффективности. Здесь вы отказываетесь от надежности только для экономии токенов, по сути. Здесь наша проблема — сэкономить токены, это стало второстепенным, но главная проблема в том, что ваша память выходит из-под контроля. Я имею в виду, ваш агент теряет память. Так что мы должны решить это в первую очередь, а затем мы должны беспокоиться о токенах. Очевидно, оба взаимосвязаны, но вы должны понимать, какова мотивация здесь, верно? Я надеюсь, что это имеет смысл. Хорошо.
Итак, давайте двигаться дальше. Потерянное в середине — слепое пятно внимания. Теперь здесь есть что-то, что звучит удивительно, но на самом деле является тем, чему люди не уделяют особого внимания. Именно это я и хотел сформулировать, поэтому я сделал долгую паузу. Так что большие языковые модели, LLM, уделяют очень мало внимания содержимому в середине. Так что же это значит? Итак, у вас есть запрос. У него есть разделы, верно? У него есть начальный раздел, средний раздел и затем последний раздел, верно? Даже если вы пишете это в одном абзаце, у него есть эти разделы. Так что LLM, и вообще как человек, я тоже скажу вам свое мнение. Так что всякий раз, когда я начинаю читать что-то, я уделяю больше внимания первым нескольким строкам, потому что они будут содержать большую часть фактов. Даже когда вы читаете газету, большая часть важного содержится на первой странице новостей, которая в целом даст вам представление о том, что важно. Затем средние разделы немного, вы знаете, вы теряете интерес по какой-то причине. И вы знаете, некоторые, если вы читаете газету, большая часть, вы знаете, рекламы и ненужных вещей, некоторые из ненужных вещей могут попасть в средние разделы газеты, а затем есть некоторые захватывающие разделы в последней части, по сути, которые обычно являются спортом, это шаблон, которому следуют газеты. Так что это кривая внимания. Так что модель LLM будет больше заинтересована в том, что вы даете в начале, которое является первым сообщением, а затем это становится слепым пятном. Она просто быстро пройдет, например, через средний раздел запроса, а затем то, чем заканчивается ваш запрос, например, этому тоже будет уделено больше внимания, верно? Так что суть, которую я хочу донести, заключается в том, что если вы поместите много важных фактов в среднюю часть, то эти факты могут быть похоронены. Так что, если вы поместите основные компоненты сюда, такие как идентификатор клиента или идентификатор заказа и сумму возврата, если вы поместите это в этот раздел вашего запроса, это может не быть обработано или, вы знаете, это займет больше времени, потому что, вы знаете, LLM приходится искать, где это находится. Но если вы поместите такую информацию в начальную часть, в первое сообщение, то на 100% времени, в основном, она сразу же получит факты. А затем важные резюме или важные факты, которые, вы знаете, LLM нужно обработать, например, вы можете оставить это в конце, например, последнее сообщение клиента или последний разговор, вы можете оставить это в конце, чтобы это стало одним целым кругом. LLM сможет связать точки, которые она получила, вы знаете, важные факты, которые ей нужны. Затем, очевидно, не так, чтобы вы должны оставить эту область пустой, верно? Вы можете поместить туда некоторые результаты инструментов или некоторые низкие, своего рода требования, которые не очень важны, вы можете поместить их сюда, а затем вы можете поместить, вы знаете, последнее сообщение или более важные вещи в конце. Так что вы не теряете данные здесь, но вы упорядочиваете данные, чтобы LLM работала более эффективно. И почему я уделяю больше внимания здесь, потому что очень важно понимать с точки зрения экзамена, а также как вы работаете в своей повседневной жизни, как вы упорядочиваете свои запросы в повседневной жизни, верно? Так что это критические детали: номера заказов, суммы возвратов, детали политики, вы знаете, вы помещаете их в начало, верно? Затем результаты инструментов, сообщения инструментов, все эти вещи, которые, своего рода, не так важны, поместите их в середину, верно? в середину, прямо в слепое пятно, а затем в конце вы должны поместить другие важные вещи, верно? Так что я надеюсь, что это имеет смысл, верно? Хорошо.
Итак, давайте поговорим о следующем, что является результатами инструментов, безмолвным пожирателем контекста. Каждый вызов инструмента, который делает ваш агент, возвращает данные. И всякий раз, когда вы добавляете каждый вызов инструмента и все, что есть в вызове инструмента, токены используются для обработки сообщений. Так что вы находитесь в агентском цикле. Вы, что вы делаете, это вы слепо вызываете, я имею в виду, очевидно, вызовы инструментов необходимы, но вы, по сути, слепо добавляете любое сообщение инструмента, которое вы получаете на каждом шаге, вы добавляете его напрямую, верно? как ненужные детали, которые вы, возможно, получили, вы также добавляете. В этом случае, очевидно, будет использоваться больше токенов, верно? Например, есть инструмент получения клиента в нашем агенте поддержки клиентов. Так что, если вы хотите полностью обработать каждое сообщение, вы бы использовали около, например, 400 токенов. Затем у нас есть поиск заказа, этот конкретный инструмент также есть. Он может занять 350 токенов. Проверка политики также есть. Он может занять 600 токенов. История доставки. Так что, если вы просто сложите все эти токены, используемые для обработки вызовов инструментов, вместе, вы получите около 2000-3000 токенов в каждой итерации вашего агентского цикла. Теперь вам не нужно фактически обрабатывать все, что выходит из каждого инструмента. Вы можете фильтровать это, верно? Просто представьте, если вы обрабатываете, это всего лишь один вызов инструмента, и есть пять инструментов в одном, простите, в одном агентском цикле, например, вы вызываете пять инструментов, и представьте себе в производственной системе, где каждый раз вызываются эти пять инструментов, и просто представьте, сколько токенов, даже если вы вызываете. Так, согласно расчету, каждый агентский цикл вы используете 2000-2500 токенов только для обработки этих сообщений инструментов. Просто представьте, даже если это происходит 20 раз, тогда вы используете 40000-50000 токенов всего за 10-20 раз. Верно? Теперь это очень большая нагрузка. Теперь, очевидно, в производственной системе это будет вызываться гораздо чаще, чем 20 раз. Агентский цикл будет происходить, вы знаете, гораздо чаще, чем 20-30 раз. Так что вы неоправданно используете токены для неоправданной обработки ненужных данных. Я надеюсь, что это имеет смысл и не сбивает вас с толку. Так что же мы делаем в этом сценарии? Вы скажете: "Хорошо, мы не можем просто игнорировать результаты инструментов". Это справедливый вопрос. Мы не должны игнорировать результаты инструментов. Так что же еще мы можем сделать? Так что, я имею в виду, чтобы сделать это эффективным, и я уже дал ответ в одной из предыдущих лекций. Это было давно. Так что вам придется запомнить это. Любая другая концепция, которую мы обсуждали, которая может помочь здесь. Я уже обсуждал эту концепцию, кстати. Я просто сделаю паузу, и вы тоже сделаете паузу в видео. Подумайте об этом, и вы сможете ответить здесь. Верно? Ответ — использование хуков до вызова инструмента. Или, простите, хуков после вызова инструмента. Вы можете использовать либо, вы знаете, данные, которые вы получаете от предыдущего инструмента, вы можете использовать хук после вызова инструмента для фильтрации данных, которые вам понадобятся в следующей итерации, или перед передачей данных в сам инструмент, вы можете использовать хук до вызова инструмента для извлечения, вы знаете, необходимых полей, которые нужны для этой конкретной вещи, верно? Я надеюсь, что это имеет смысл.
Итак, что мы знаем? Что мы делаем? Что мы делаем? Как мы структурируем это? Вы можете структурировать это, используя блок фактов дела, блокнот вашего агента. Так что же это значит? Я перейду к моему, и я создал эту маленькую вещь, очень маленькую, своего рода POJO или модель сущности здесь. Так что для обработки каждого дела, например, у вас есть агент поддержки клиентов, и для обработки каждого, своего рода, дела или проблемы или заявки, которую поднимает клиент, вам понадобятся данные из этих типов данных, верно? Например, какой идентификатор клиента, какой идентификатор заказа, какой товар, какая сумма возврата, какая дата заказа, сколько дней в рамках политики, все эти вещи вам понадобятся. Теперь, что произойдет, когда любой инструмент запустится, например, поиск заказа или обработка возврата, он вернет вам в обобщенном виде. Хорошо. Так это клиент, и это было сообщение, которое сказал клиент, и все эти вещи, и это была сумма возврата. Так что он вернет вам в обобщенном виде в виде строки. Теперь у вас может быть пост-хук, например, пост-хук после того, как инструмент был запущен, у вас может быть пост-хук там. В этом пост-хуке вы можете взять все сообщение. Вы можете использовать регулярные выражения или что-то в этом роде, вам даже не нужно использовать ИИ там, вы можете использовать регулярные выражения там, которые просто извлекут информацию, все эти факты дела, которые нужны, и поместят их в какой-то объект или что-то в этом роде, массив или объект, что угодно. Теперь, когда вы добавляете сообщение для следующего вызова инструмента или следующей части агентского цикла, вы фактически отправляете только необходимые вещи. Так что вы делаете половину и половину, как если вы помните, я уже говорил о хуках до и после вызова инструмента, что это обычное кодирование, которое вы делаете, это обычные функции, как мы также написали несколько функций, верно? если вы возьмете наши пост-хуки после вызова инструмента, и пост-хуки после вызова инструмента, я проверю некоторые другие места здесь. У нас есть, так что у нас есть некоторые, своего рода, вещи здесь. Хорошо. Так что здесь пост-хук после вызова инструмента нормализует это перед моделью, чтобы модель видела их, по сути. Так что, если вы хотите отфильтровать некоторые данные или если вы хотите нормализовать данные или удалить ненужные вещи, чтобы модель не страдала от исчерпания контекста из-за обработки ненужных данных, вы можете использовать пост-хук после вызова инструмента, который мы уже обсуждали, или вы также можете использовать хук до вызова инструмента, если вы хотите, своего рода, дважды проверить данные или очистить данные, прежде чем даже будет вызван инструмент. Верно? Все это мы уже обсуждали. Так что вот что я имел в виду в этом сценарии, например, вы занимаетесь поддержкой клиентов, вы извлекаете это в этом формате, а затем используете это, верно? Так что это блок фактов дела, и на экзамене вас будут тестировать на том, как вы обрабатываете такой сценарий, верно? Так что он будет содержать все необходимые данные и четыре правила доказательства: верхнее размещение всегда находится в зоне наивысшего внимания, которую мы только что обсуждали здесь. Все эти данные должны быть в этой части вашего запроса, потому что это критические факты, которые необходимы для обработки. Всегда свежие, динамически обновляемые по мере роста разговора, проверенные только подтвержденные данные инструмента. Это то, что я сказал, если вы хотите дважды проверить данные, даже прежде чем передать их инструменту, вы также можете использовать хук до вызова инструмента. Сжатые, дистиллированные примерно до 200 токенов вместо передачи всей строки, которую вы получили от вызова инструмента, вы просто сжимаете ее, и передаете необходимые данные. Так что экзамен критически важен. Одна вещь, которую я хочу отметить, это, по сути, извлечение транзакционных фактов в постоянный блок фактов дела является окончательным средством от потери суммирования и эффекта потери в середине. Верно? Так что это то, что я хотел вам сказать, что вам нужно сначала обрезать, а затем передать. И мы уже обсуждали это. У вас есть необработанный вывод инструмента, например, 400 токенов. Вы передаете его в пост-хук после вызова инструмента, как этот. Он выполнит фильтрацию. Он отбросит весь шум, который не нужен для обработки, и затем он сгенерирует этот блок фактов дела, а затем передаст его в контекст агента. Так что с точки зрения экзамена, обрезайте многословные выводы инструментов, прежде чем они накопятся на уровне хуков. Очистка контекста после того, как он уже раздут, — это провальная стратегия. Так что еще до передачи его в сам контекст агента, вам нужно обрезать и очистить данные. Верно? Я надеюсь, что это имеет смысл. Хорошо.
Итак, давайте двигаться дальше. Структура имеет значение, как мы обсуждали, начало и конец. Мы уже обсуждали кривую, верно? Кривую внимания, которую мы обсуждали. Так что, очевидно, в запросе, какие бы сообщения вы ни добавляли, убедитесь, что вы всегда держите блок фактов дела в первой части, которую мы обсуждали. Далее вы можете поместить некоторые обрезанные результаты инструментов, которые являются легкими, актуальными только для немедленного принятия решений, лишенными исторического раздувания, находятся в долине низкого внимания. Критический обзор плюс финальный вопрос, я имею в виду, это должно быть в конце. Потому что это также важно, что было сделано, например, критический обзор, например, очень важная сводная строка или любые детали политики, которые, вы знаете, возврат должен быть сделан в течение 30 дней, например, если у вас есть такая политика, вы можете иметь ее в конце, потому что первая часть и последняя часть — это то, где находится внимание для LLM, и мы подробно обсуждали это всего несколько слайдов назад. Так что запомните эти три части. Не запоминайте их, на мой взгляд. Просто запомните их. Это очень легко запомнить, и мы, люди, тоже делаем то же самое, верно? Так что это своего рода само собой разумеющееся. Я надеюсь, что это имеет смысл. Да.
Итак, теперь давайте перейдем к следующей части этого конкретного урока, которая, по сути, заключается в том, когда эскалировать. И, по сути, мы меняем направление. И мы теперь собираемся решить, когда ваш ИИ-агент перестанет пытаться решить все самостоятельно, а затем, по сути, эскалирует проблему к человеку. И, знаете, иногда люди не понимают, когда мне следует заставить агента эскалировать к, вы знаете, заставить агента эскалировать к человеку, потому что я заметил это так много раз. Я использовал так много служб поддержки в наши дни, каждая служба поддержки, с которой вы связываетесь как клиент, — это боты, и много раз, когда я использую ее, я разочаровываюсь, потому что даже когда я говорю, подключите меня к, явно говорю, подключите меня к агенту поддержки человека, они все равно этого не делают, все равно дают какой-то автоматический ответ или пытаются решить это самостоятельно. Да. Но это не тот путь, по которому следует идти. Вы знаете, вы должны сделать своего агента таким образом, чтобы агент знал, хорошо, это та черта, которую я не должен пересекать, и вот когда я должен полностью эскалировать дело человеку, и это три вещи, по сути, три момента, когда агент понимает, хорошо, если такой момент наступает или такой триггер возникает, то вот когда мне нужно эскалировать. Больше никаких вопросов.
Первый триггер — явный запрос человека. Так что клиент напрямую спрашивает вас, например, хорошо, я хочу агента-человека любой ценой, подключите меня к агенту, позвольте мне поговорить с кем-то реальным. Если все это, вы знаете, клиент говорит, тогда вы должны эскалировать это человеку. Вы должны сделать агента, я имею в виду, вы должны закодировать агента таким образом, чтобы он эскалировал к человеку. Без вопросов. Верно? И это очень важно с точки зрения экзамена, потому что вас будут тестировать в определенных сценариях.
Второй триггер — пробел в политике или исключение. Я имею в виду, например, есть ситуация, которая не охватывается четко доступной политикой, верно? Возможно, дело сочетает в себе условия, которые, вы знаете, каждая политика охватывает отдельно, возможно, это так, но ничто не рассматривает их вместе. Агент не может понять, какую политику мне следует проверить, или какую политику она охватывает. Так что, когда нет четкой политики, вы знаете, авторизации, человек должен принять решение. Я надеюсь, что это имеет смысл.
Третье — агент застрял или не может прогрессировать. Так что искренняя неспособность прогрессировать после разумных исчерпывающих попыток, как будто агент застрял в цикле, вы знаете, очевидно, в этом случае у вас может быть количество повторных попыток. Мы уже обсуждали это, что у вас может быть 20 или 30 повторных попыток, например, и все же, если агент не может завершить это за 20 или 30 повторных попыток, это просто означает, что агент застрял в агентском цикле, ничего из этого не выходит. Так что в этом случае, очевидно, агент должен эскалировать к человеку. Так что запомните три вещи: когда агент должен эскалировать к человеку, первое — явный запрос, пробел в политике, и если агент застрял, в это время агент также должен эскалировать к человеку.
Теперь следующее. Теперь мы обсудили, какими должны быть триггеры для эскалации к человеку. Второе — что не должно вызывать эскалацию, и это ловушки для экзаменов, и это антипаттерны. Так что вы должны избегать этого.
Первый антипаттерн — только негативные настроения. Это означает, что клиент расстроен, используя, вы знаете, он написал это с восклицательными знаками, все заглавные буквы, все такое, и явно расстроен, но этот сценарий не означает, что им нужна поддержка человека. Я имею в виду, они проецируют себя в гневной эмоции, но вещи, которые они просят, четко подпадают под политику и могут быть четко обработаны агентом. Например, нет двусмысленности, просто способ, которым они проецируют себя, немного более негативный. Так что это также очень важно понять, что в этом случае, если это может быть обработано агентом, пожалуйста, пусть агент обработает это, если только клиент явно не заявит: "Я не верю, что бот сможет мне помочь, мне нужна поддержка человека". В этом сценарии только вам нужно эскалировать это человеку. Это переходит ко второй части — сложности задачи. Так что, даже если задача, которую, вы знаете, клиент просит, немного сложна, но все же она не выходит из-под контроля бота. Все вызовы инструментов, которые ему нужно сделать, все условия четко совпадают, и в этом случае вам также не нужна помощь человека, даже если это немного сложно, но агент достаточно умен, чтобы справиться с этим. Теперь, например, при выполнении этого он застревает в цикле, это отдельный сценарий. В этом случае ему нужно эскалировать, но просто видя, что это как бы простая вещь, студент видит очень большой вопрос на экзамене и просто видя длину вопроса, они могут испугаться его и вообще отказаться от вопроса. Так что это не правильный путь. Им нужно прочитать вопрос, чтобы понять, что нужно сделать. Подобный случай здесь. Я надеюсь, что это имеет смысл.
Третье, очень важно понять, очень легко пренебречь — это оценки уверенности модели. Так что, я имею в виду, это просто собственный показатель уверенности модели. Например, я на 70% уверен, что это правильная сумма возврата. Не используйте это как ворота для эскалации, потому что самоотчетная уверенность Claude не откалибрована с фактической точностью надежным измеримым способом. Так что он может сказать 95% уверенности и ошибиться, верно? И он может быть на 60% уверен, он может быть прав. Так что оценки уверенности не являются суждением для эскалации к человеку. Вы не должны, своего рода, выносить суждение на основе оценки уверенности модели. Это должно исходить из этих трех вещей, этих трех триггеров, которые мы только что обсуждали, что это должно быть эскалировано к человеку. Я надеюсь, что это имеет смысл. Итак, давайте двигаться дальше.
Золотое правило: всякий раз, когда клиент просит, я хочу человека, тогда немедленно эскалируйте. В этом случае, если клиент сам просит, что, вы знаете, я хочу немедленно эскалировать, тогда не пытайтесь решить это. Не спрашивайте, почему они хотят человека. Все эти вопросы не должны задаваться. Это должно быть немедленно эскалировано. И, к сожалению, все боты, с которыми я взаимодействовал в реальных производственных ботах, не делают этого, и я действительно разочарован. На самом деле, они должны улучшаться на основе всех этих инструкций. Хорошо, все, что не имеет отношения к нашему экзамену, но если вы создаете производственный ИИ-чатбот, убедитесь, что все это включено. Я надеюсь, что это имеет смысл. Хорошо.
Итак, мы уже это обсуждали. Так что пробел в политике против покрытой политики. Принятие решений. Явный запрос на человека. Если клиент просит об этом, тогда немедленно эскалируйте. Если нет, тогда проверьте политику. Я имею в виду, очевидно, хуки также могут проверять политику, кстати. Так что вы выполняете проверку политики, по сути, в вашем агентском цикле. Четко ли политика это покрывает? Если нет, я имею в виду, разрешите автономно. Не эскалируйте на всякий случай. Верно? Если политика это не покрывает, я имею в виду, я имею в виду, простите, я только что сказал, я запутался здесь. Если политика это не покрывает, по сути, тогда есть пробел. Так что эскалируйте. Если запрос подпадает под политику, и агент может разрешить конкретную политику, хорошо, под этой политикой возврата, например, это подпадает под запрос, тогда вы можете легко его разрешить, верно? Теперь, даже если это подпадает под политику, как я сказал, это может застрять. Так что, если он застрянет, тогда, очевидно, нам придется эскалировать. Вы знаете, он исчерпал все, и вам придется продолжать попытки, количество повторных попыток, которые вам придется сохранить, и мы уже знаем, как это сделать, мы обсуждали это много лекций назад. Если он не застрял, тогда продолжайте работать. Так что эскалация — это не запасной вариант для сложных проблем. Если политика это покрывает, тогда решайте уверенно. Если есть пробел в политике, тогда эскалируйте. Только при этих сценариях вам придется эскалировать к человеку. Если ваш агент должен быть безошибочным, тогда убедитесь, что он следует всем этим рекомендациям. Это лучшие практики создания агента, иначе вы не поймете, что делает ваш агент. Хорошо.
Итак, прежде чем мы проверим этот вопрос, я просто хочу показать вам, как я сделал передачу. Так что, если вы видите, мы не в этом конкретном агенте, который мы сделали в этом агенте поддержки клиентов, я просто добавил обычную функцию передачи клиенту. Да, краткая причина передачи. Так что это, по сути, эскалация к человеку, и это описание инструмента. Передайте разговор агенту поддержки человека, верно? Вызовите это немедленно, когда клиент явно просит. Так что это, по сути, Claude поймет. Очевидно, это описание инструмента, верно? потому что вам нужно дать правильное описание инструмента. Вы, очевидно, потому что мы уже обсуждали, что описания инструментов действительно важны для Claude, чтобы не путаться между инструментами, и я уже подробно это обсуждал. Вызовите это немедленно, когда клиент явно просит поговорить с человеком, с менеджером или с реальным человеком. Проверьте личность или решите проблему самостоятельно сначала. Также вызовите это, когда запрос превышает ваши полномочия. Я имею в виду, когда вы, по сути, не находитесь в политике, политика это не покрывает, верно? и возвращает подтверждение того, что передача была создана. У нас нет реального человека здесь, это просто обычная ситуация. Так что, по сути, это будет выполнено, когда мы дадим некоторый ввод, например, такое сообщение. Обработайте это сообщение клиента и решите, следует ли решать, по сути, или эскалировать. Так что клиент говорит: "Я не хочу иметь дело с ботом, подключите меня к реальному агенту". Так что мы просто передаем это в этот под-агент. Это агентский цикл, верно? Мы делали это здесь. Так что это агент, и здесь у нас цикл, и у нас есть несколько коротких примеров, и мы обсуждали, как мы можем использовать короткие примеры в системном запросе, верно? Так что это, по сути, верно? И, да, я надеюсь, что это имеет смысл. Так что здесь группа агентов запускает весь этот код, который мы уже обсуждали, верно? как это работает. Так что на данный момент мы будем обсуждать только эту часть, эскалацию, и я уже запускал это раньше, и, по сути, это сообщение, и когда оно столкнется с таким сообщением, оно должно немедленно эскалировать. Так что я просто очищу это, и я снова запущу код. Верно? Так что, если вы видите, все проверки и все это произойдет, по сути. Так что координатор разлагает задачу, и для начала клиент будет проверен. Так что, очевидно, он не может просто передать человеку без проверки клиента. Так что это проверка клиента. Клиент существует. Так что он в хорошем состоянии, и заказ также проверен. И вот действие. Я не могу обработать этот возврат напрямую. Сумма заказа в 750 долларов превышает авторизацию в 500 долларов. Это один из сценариев, когда его следует передать человеку. Пожалуйста, свяжитесь с вашим руководителем по биллингу или старшей командой поддержки для рассмотрения. Это сценарий номер два. Так что здесь у нас сценарий номер один и сценарий номер два. Клиент явно просит человека. Так что начинаем задачу пользователя. Обработайте это сообщение клиента и решите, следует ли думать. Теперь здесь он был эскалирован к агенту-человеку. Билет — это эта вещь. Клиент, очевидно, был проверен. Клиент явно запросил агента-человека, и это результат. Результат инструмента, и он говорит: эскалировано истина, идентификатор билета — это, идентификатор клиента — это, и все эти вещи. Так что, если я отправлю этот код, вы сможете попробовать все эти сценарии. И если в сценарии номер два вместо того, чтобы сказать: "Эскалировать к агенту-человеку", вы зададите обычный вопрос, тогда агент попытается решить его сам. Но если вы явно скажете, что, хорошо, эскалируйте это человеку, тогда он эскалирует к агенту-человеку, как это сообщение вы получите. Так что я отправлю этот код, вы можете попробовать его сами, вы можете поиграть. И, да, я надеюсь, что это имеет смысл. Так что вот как вы бы спроектировали правильного агента, который может понять, когда эскалировать к человеку или что-то в этом роде.
Пример вопроса номер один. Сара, заказ 4 5 6 7 8, 12 месяцев, очень расстроена, повреждение подтверждено, поздняя доставка подтверждена. Она говорит: "Я достаточно долго с этим разбираюсь, я просто хочу поговорить с реальным человеком". Что должен сделать агент дальше? Перевести немедленно к человеку без дальнейших попыток решения. Так что он также может дать вам варианты: предпринять еще один шаг решения, спросить, почему она предпочитает человека, предложить портал самообслуживания и все такое. Нет, это не сработает. Это все ловушки. Вы должны немедленно увидеть вариант, который говорит: "Эскалировать к человеку". Я надеюсь, что это имеет смысл.
Итак, просто быстрая карточка или справочная карточка для этого конкретного урока. Так что контекст и эскалация. Мы делаем две вещи. Так что будьте осторожны, прогрессивное суммирование теряет конкретные числа и даты. Мы уже это обсуждали. Используйте блок фактов дела и обрезайте необходимые результаты, которые вам нужны для контекста. Обрезайте результаты инструментов с помощью пост-хуков. Сокращает 95% раздувания. Помните кривую U. Держите факты подальше от середины. Эскалация, действие два. Допустимые триггеры: явный запрос, пробел в политике. Агент застрял. Тогда вы эскалируете к человеку. Недопустимые ловушки: настроения, сложность, оценки уверенности. Пожалуйста, не эскалируйте к человеку на основе всех этих ловушек. Золотое правило: явный запрос человека означает, что человек сказал: "Я хочу эскалировать", тогда немедленно эскалируйте. Хорошо.
Итак, это все для этого урока. Увидимся на следующем уроке. До тех пор хорошего дня. Берегите себя. Пока-пока.