Transcription
Если вы разработчик, то прямо сейчас кажется почти невозможным угнаться за всем, что происходит в сфере ИИ. Все говорят об ИИ-агентах. Ваши ленты LinkedIn и X полны этого. Все делают вид, что это суперлегко. Тем не менее, вы все еще пытаетесь понять, стоит ли использовать LangChain или LlamaIndex, и пытаетесь отладить и разобраться во всех этих системах ИИ-агентов, которые вы создаете и с которыми экспериментируете. Все найденные вами учебные пособия либо беспорядочны, либо противоречивы. И каждую неделю выходит новое видео от FireShip, где они выпускают что-то новое, и вы думаете: «О, неужели нам теперь нужно знать и это?» Так что, в общем, это полный беспорядок. И моя цель в этом видео — помочь успокоить вашу тревогу по поводу ИИ и дать вам ясность относительно того, что на самом деле происходит в сфере ИИ прямо сейчас, и почему вы можете практически игнорировать 99% всего, что видите онлайн, и просто сосредоточиться на основных фундаментальных строительных блоках, которые вы можете использовать для создания надежных и эффективных агентов. Итак, в этом видео я проведу вас через семь фундаментальных строительных блоков, которые вам нужно понять, когда вы хотите создавать ИИ-агентов, независимо от того, какой инструмент вы используете. Теперь я приведу примеры кода на языке программирования Python, но, честно говоря, не имеет значения, какой инструмент вы используете, будь то N8, TypeScript, Java или любой другой язык программирования. Если свести все к этим семи фундаментальным строительным блокам, вы сможете реализовать это в чем угодно, потому что они настолько просты. Итак, я выполню эти простые блоки кода и покажу вам вывод, а также шаг за шагом пройдусь по всему с помощью диаграмм. Так что, даже если вы никогда не писали ни строчки кода на Python, вы все равно сможете следить за этим видео, и я могу гарантировать вам, что после просмотра этого видео у вас будет совершенно другое представление о том, что нужно для создания эффективных ИИ-агентов, и вы сможете смотреть практически на любую проблему, разбивать ее и знать шаблоны и строительные блоки, которые вам нужны, чтобы решить ее и автоматизировать. И тогда вы можете подумать: «Хорошо, Дейв, но почему я должен тебя слушать? Разве ты не часть тех 99% шума, о которых ты только что упомянул?» Ну, я оставлю это на ваше усмотрение. Но у меня есть несколько уникальная перспектива на рынок ИИ прямо сейчас. И это потому, что у меня более 10 лет опыта в области ИИ. Итак, у меня есть опыт в области машинного обучения, и я управляю собственной компанией по разработке ИИ, где за последние годы мы выполнили более 20 полных развертываний систем. Кроме того, у меня есть множество сообществ с тысячами участников в совокупности. Так что это дает мне хорошее представление обо всем, что происходит, что работает, а что нет. И, кроме того, я также регулярно беру интервью у лидеров отрасли, таких как Джейсон Лью или Дэн Мартелл, например. Так что я кратко хотел упомянуть это, чтобы вы знали, что я не просто какой-то случайный парень, создающий рабочие процессы N8 из своей спальни. И в этом нет ничего плохого. Это просто другая категория. Клиенты работают с нами и нанимают нас для создания готовых к производству систем, на которые они могут полагаться. И именно эти знания я хочу донести до вас в этом видео. И большая, большая проблема, которую я вижу прямо сейчас в сфере ИИ и почему вы чувствуете себя таким растерянным как разработчик, исходит из этого простого изображения здесь. На рынок просто поступает много денег. И каждый раз на протяжении всей истории, когда возникает такая возможность, что происходит? Люди набрасываются на нее, потому что люди хотят попытаться извлечь из нее выгоду. Так что, даже если вы хоть немного интересуетесь ИИ, вот как будет выглядеть большинство ваших лент в социальных сетях. И все они делают вид, что это суперлегко. Существуют все эти инструменты, которые вы можете использовать для создания целых армий агентов. Тем не менее, вы все еще задаетесь вопросом, с чего начать и как заставить все это работать в действительно готовой к производству среде. И вдобавок к этому, конечно, есть все фреймворки и библиотеки, которые следуют аналогичной тенденции, верно? Так что инструменты для разработчиков, репозитории GitHub, всевозможные инструменты, которые делают создание этих ИИ-агентов суперлегким. И, конечно же, у нас есть новости, все, что происходит, и множество других инструментов, построенных поверх этого, которые вы также можете использовать. И все это приводит к тому, что вы чувствуете себя действительно перегруженным и не имеете понятия, что происходит и на чем сосредоточиться. И теперь есть четкое различие между ведущими разработчиками и командами, которые фактически выпускают ИИ-системы, которые доходят до производства, по сравнению с разработчиками, которые все еще пытаются отладить последние фреймворки агентов. И заключается в том, что большинство разработчиков следуют всему хайпу, который вы видите в социальных сетях, фреймворкам, вниманию СМИ и множеству доступных ИИ-инструментов, в то время как умные разработчики понимают, что все, что вы видите здесь, — это просто абстракция над текущими лидерами отрасли — поставщиками моделей LLM, и как только вы это поймете как разработчик, создающий ИИ-системы, и начнете работать напрямую с API этих поставщиков моделей, вы поймете, что можете фактически игнорировать 99% всего, что вы видите онлайн, а также поймете, что фундаментально ничего не изменилось с момента появления функции вызова. Да, модели становятся лучше, но способ, которым мы работаем с этими LLM, остается прежним. И каждый раз, когда я поднимаю этот вопрос, люди говорят: «Что? Как это возможно?» Но наши кодовые базы двухлетней давности все еще работают. Они все еще работают. Нам нужно только менять конечные точки моделей через API, потому что мы спроектировали их таким образом, чтобы они не зависели от фреймворков, которые по сути построены на зыбучих песках. Так что весь этот контекст, который я сейчас предоставляю, очень важен, как и с LLM, потому что иначе остальная часть этого видео и семь основных строительных блоков не будут иметь большого смысла. Итак, первое и самое важное, что нужно понять, это то, что если вы посмотрите на ведущие команды, создающие ИИ-системы, они используют пользовательские строительные блоки, а не фреймворки. И это потому, что самые эффективные ИИ-агенты на самом деле не такие уж и агентские. Это в основном детерминированное программное обеспечение с стратегическими вызовами LLM, размещенными точно там, где они приносят пользу. Итак, проблема с большинством фреймворков агентов и учебных пособий заключается в том, что большинство из них настаивают на предоставлении вашей LLM просто набора инструментов, и пусть она сама выясняет, как решить проблему. Но на самом деле вы не хотите, чтобы ваша LLM принимала каждое решение. Вы хотите, чтобы она выполняла то, в чем она действительно хороша — рассуждение с контекстом, в то время как ваш код или приложение обрабатывает все остальное. И решение на самом деле довольно простое. Это просто программная инженерия. Так что вместо того, чтобы делать вызов API LLM с 15 инструментами, вы хотите тактично разбить то, что вы на самом деле строите, на фундаментальные компоненты, решить каждую проблему с помощью надлежащих лучших практик программной инженерии и включать шаг LLM только тогда, когда невозможно решить ее с помощью детерминированного кода. Вызов API LLM прямо сейчас является самой дорогой и опасной операцией в программной инженерии, и он очень мощный, но вы хотите избегать его любой ценой и использовать его только тогда, когда это абсолютно необходимо, и это особенно верно для систем фоновой автоматизации. Это очень важная концепция для понимания. Существует огромная разница между созданием персональных помощников, таких как ChatGPT или Cursor, где пользователи находятся в цикле, и созданием полностью автоматизированных систем, которые обрабатывают информацию или выполняют рабочие процессы без человеческого вмешательства. И давайте признаем, большинство из вас не создает следующий ChatGPT или Cursor. Вы создаете фоновые автоматизации, чтобы сделать вашу работу или вашу компанию более эффективной. Так что, когда вы создаете приложения, похожие на персональных помощников, использование инструментов и нескольких вызовов LLM может быть более эффективным. Но когда вы создаете систему фоновой автоматизации, вы действительно хотите их сократить. И, например, для наших производственных сред для наших клиентов мы почти никогда не полагаемся на вызовы инструментов. Так что вы хотите создавать свои приложения таким образом, чтобы вам требовалось как можно меньше вызовов API LLM. Только когда вы больше не можете решить проблему с помощью детерминированного кода, тогда вы делаете вызов. И когда вы дойдете до этой точки, все дело в инженерии контекста. Потому что, чтобы получить хороший ответ от LLM, вам нужен правильный контекст в нужное время, отправленный в нужную модель. Так что вам нужно предварительно обработать всю доступную информацию, подсказки и ввод пользователя, чтобы LLM могла легко и надежно решить проблему. Это самый фундаментальный навык при работе с LLM. И, наконец, последнее, что вам нужно понять, это то, что большинство ИИ-агентов — это просто рабочие процессы или DAG, если быть точным, или просто графы, если включать циклы. И большинство шагов в этих рабочих процессах должны быть обычным кодом, а не вызовами LLM. Так что я пытаюсь сделать в этом видео — это действительно помочь вам понять ИИ-агентов на фундаментальном уровне, с первых принципов. И теперь, когда мы подготовили почву, перейдем к фундаментальным строительным блокам, которые вам нужны. И их действительно всего семь или около того, которые вы используете для решения проблемы, разбивая ее на более мелкие проблемы, а затем пытаясь решить каждую из этих подпроблем с помощью этих строительных блоков, которые я представлю вам прямо сейчас. И строительный блок номер один — это то, что я называю уровнем интеллекта. Так что очень очевидно, верно? Это единственный по-настоящему ИИ-компонент в нем. И именно здесь происходит волшебство. Так что именно здесь вы делаете фактический вызов API к большой языковой модели. Без этого у вас просто обычное программное обеспечение. Сложность заключается не в самом вызове LLM. Это очень просто. Это все остальное, что вам нужно сделать вокруг него. Так что шаблон здесь таков: у вас есть ввод пользователя, вы отправляете его в LLM, и LLM отправляет его обратно вам. Теперь мы можем очень легко сделать это на языке программирования Python, используя, например, Python SDK OpenAI, где мы подключаемся с помощью клиента. Мы практически выбираем, какую модель хотим использовать. Мы вставляем подсказку, а затем ждем ответа. Так что простое выполнение этого может быть сделано на любом языке программирования. Это может быть сделано напрямую с помощью API. Это может быть сделано с помощью N8. Но это первый фундаментальный строительный блок. вам нужен способ общаться с этими моделями и получать от них информацию. Затем строительный блок номер два — это строительный блок памяти, и он обеспечивает постоянство контекста на протяжении ваших взаимодействий с этими моделями, потому что LLM ничего не помнят из предыдущих сообщений. Они без состояния, и без памяти каждое взаимодействие начинается с нуля. Так что вам нужно вручную передавать историю разговора каждый раз. Это просто хранение и передача состояния разговора, что мы делаем в веб-приложениях вечно. Так что, чтобы построить поверх уровня интеллекта, который мы только что видели, теперь, помимо просто предоставления подсказки ввода пользователя, мы также получаем предыдущий контекст и структурируем его в последовательность, похожую на разговор, где у нас есть последовательность сообщений. Затем мы можем получить ответ, и в рамках этого процесса мы также должны обрабатывать обновление нашей истории разговора. И во втором файле здесь, называемом memory.py, мы видим пример, где мы просим ИИ рассказать нам шутку. Затем мы задаем последующий вопрос, чтобы спросить, каким был мой предыдущий вопрос, но мы неправильно обрабатываем историю разговора. И поскольку LLM без состояния, если мы запустим это, оно просто не будет знать. И затем здесь, в этой функции, у нас есть правильный пример того, как обрабатывать память, где мы передаем историю разговора, и у нас есть чередующаяся последовательность между пользователем и ассистентом. Мы теперь динамически программируем это в нашем коде. В более реалистичном примере вы будете хранить и извлекать это из базы данных. И чтобы продемонстрировать это, мы можем просто запустить первую шутку. Итак, почему программисты предпочитают темный режим? Потому что свет привлекает ошибки. Затем мы задаем последующий вопрос, чтобы спросить, каким был мой предыдущий вопрос. И он говорит: «Я не могу вспомнить предыдущие взаимодействия». И, наконец, мы делаем это правильно, передавая предыдущий ответ. И тогда ваш предыдущий вопрос заключался в просьбе рассказать шутку о программировании. Так что теперь он понимает контекст истории разговора. Затем строительный блок номер три — это то, что мы называем инструментами для интеграции с внешними системами. Потому что в большинстве случаев вам нужно, чтобы ваш LLM действительно что-то делал, а не просто болтал, потому что чистая генерация текста ограничена. Вы хотите вызывать API, обновлять базы данных или читать файлы. Инструменты позволяют вашей LLM сказать: «Мне нужно вызвать эту функцию с этими параметрами», а ваш код обрабатывает фактическое выполнение этого. Так что, если мы посмотрим на диаграмму здесь, мы расширяем уровень интеллекта, вызов API LLM, потенциально также с памятью, и теперь мы также предоставляем LLM инструменты. И для каждого вызова API с инструментами LLM решает: следует ли мне использовать один или несколько доступных мне инструментов? Да или нет? Если нет, я дам прямой ответ, текстовый ответ. Если да, то выберите инструмент. Затем ваш фактический код отвечает за перехват этого и выполнение инструмента. затем снова передайте результат в LLM, чтобы она снова отформатировала окончательный ответ в виде текстового ответа для вас. И вызов инструментов также напрямую доступен у всех основных поставщиков моделей. Так что нет необходимости в каких-либо внешних фреймворках или библиотеках. Мы просто указываем функцию, которую хотим вызвать. Мы преобразуем это в схему инструмента, которую затем делаем доступной для LLM. Наш код выполнит простую проверку, чтобы увидеть, действительно ли LLM решила вызвать инструмент. затем передаст параметры в фактическую функцию и запустит ее, а затем снова передаст ее в LLM. И если мы запустим все это, мы теперь можем увидеть, что у нас есть LLM, которая, используя функцию get_weather, может получить информацию о погоде для любого города или места, о котором вы можете подумать. Так что мы расширяем LLM за пределы возможностей генерации текста на основе того, на чем была обучена модель. Так что через инструменты мы даем модели способ интегрироваться и подключаться к внешним системам. И теперь, если вы совершенно новичок в вызове инструментов, никогда этого не делали, это может быть немного сложно понять. Вам нужно увидеть несколько примеров. Для этого я настоятельно рекомендую ознакомиться с официальной документацией OpenAI по вызову функций. Или, если вы хотите углубиться в это, у меня есть полный курс для начинающих здесь, на YouTube, по созданию ИИ-агентов на чистом Python, который на самом деле является очень хорошим продолжением этого видео, ссылку на которое я также оставлю в описании. Хорошо. Итак, теперь, когда мы понимаем основные операции, которые вы можете выполнять с большой языковой моделью, мы переходим к строительному блоку номер четыре, который, возможно, является самым важным, и это валидация. Это может помочь нам с контролем качества и обеспечением структурированных данных. Так что, если вы хотите создавать эффективные приложения на основе больших языковых моделей, вам нужен способ убедиться, что LLM возвращает JSON, соответствующий вашей ожидаемой схеме, потому что LLM вероятностны и могут давать непоследовательные результаты. Если вы зададите один вопрос, а затем другой пользователь задаст вопрос немного по-другому, они могут получить совершенно другой ответ. Один может быть правильным, другой — неправильным. Так что вы валидируете вывод JSON по отношению к предопределенной структуре. Если валидация не удалась, вы можете отправить его обратно в LLM и исправить. И эта концепция известна как структурированный вывод. И нам нужен этот структурированный вывод, который очень важен, чтобы мы могли строить системы вокруг него. Так что вместо того, чтобы просто задавать вопрос большой языковой модели и получать текст в ответ, мы хотим предопределенную схему JSON, в которой мы на 100% уверены, что то, что мы получаем, содержит фактические поля, которые мы можем использовать позже в нашем приложении. Так что диаграмма выглядит так. Мы просим LLM предоставить нам структурированный вывод, который, по сути, является просто JSON. Мы валидируем его по схеме, используя библиотеку, такую как Pydantic или dataclasses Python. Мы проверяем, действителен ли он. Если он действителен, у нас есть структурированные данные. Если он недействителен, мы берем ответ об ошибке и отправляем его обратно в LLM, чтобы исправить. Итак, скажем, вы хотите создать какой-нибудь агентский инструмент управления задачами, который может преобразовывать естественный язык и превращать его в задачи с датами выполнения и приоритетами. Вместо того, чтобы просто создавать агента и позволять ему взаимодействовать с пользователем, а затем просто выдавать текстовый вывод того, что, по его мнению, является целью пользователя, мы можем определить конкретную структуру данных. В этом примере я делаю это с помощью библиотеки Pydantic в Python. И получение структурированного вывода от больших языковых моделей снова поддерживается всеми основными поставщиками моделей. Так что здесь вы можете видеть, что при вызове API LLM к OpenAI у нас есть параметр text_format, который мы можем сюда поместить, и мы устанавливаем его равным определенному объекту task_result, который мы хотим получить от LLM. Так что теперь с нашей системной подсказкой и инструкцией нашей модели извлечь информацию о задаче из ввода пользователя, и наша подсказка «Мне нужно завершить презентацию проекта к пятнице, это высокий приоритет», мы можем запустить это и получить фактический валидированный структурированный объект данных в ответ, где мы можем четко видеть, что у нас есть поле task и priority, которое мы теперь можем также программно вызывать. Так что мы теперь можем фактически получить доступ к нашему объекту результата. Мы можем вызвать задачу на нем, и мы фактически получаем информацию, которая там находится. И с помощью таких методов мы можем валидировать как входящие данные, то, что мы отправляем в LLM, так и исходящие данные, то, что LLM отправляет нам обратно. И вы уже понимаете, что инженерия контекста — один из самых важных навыков при создании надежных приложений LLM. Так что использование таких библиотек, как Pydantic, действительно находится в основе этого. И затем, очень быстро, если вы разработчик и когда-либо думали о том, чтобы начать работать фрилансером, чтобы, возможно, заработать немного больше денег на стороне, работать над интересными проектами или просто учиться, но вы не знаете, с чего начать или как найти первого клиента, возможно, вам стоит ознакомиться с первой ссылкой в описании. Это видео, где я рассказываю, как моя компания может помочь вам с этим. Мы проводим эту программу уже более 3 лет. У нас есть сотни примеров разработчиков, которые уже успешно сделали этот шаг и теперь работают над интересными проектами либо параллельно со своей основной работой, либо даже полностью. И теперь, если вы чувствуете, что вы еще не готовы технически к фрилансу или не чувствуете себя уверенно, есть вторая ссылка, которая научит вас всему, что вам нужно знать о том, как подготовиться к фрилансу в качестве ИИ-инженера. И это подводит нас к строительному блоку номер пять, и это контроль для детерминированных решений, принятия решений и потока процессов. Так что вы не хотите, чтобы ваша LLM принимала каждое решение. Некоторые вещи должны обрабатываться обычным кодом. Вы можете использовать операторы if-else, switch-case и логику маршрутизации для управления потоком на основе условий. Это просто обычная бизнес-логика и маршрутизация, которую вы бы написали в любом приложении. Так что, если мы посмотрим на диаграмму здесь, у нас есть входящие данные. Мы можем, например, использовать LLM для классификации намерения с использованием структурированного вывода, где мы говорим LLM: «Вот входящее сообщение. Это может быть вопрос, запрос, жалоба или категория «другое». Мы можем теперь запрограммировать наше приложение, используя простые операторы if, где мы делаем быструю проверку. Если категория равна «вопрос», мы вызываем эту конкретную функцию, которая обрабатывает только эту часть приложения. Если это запрос, мы делаем что-то другое. Если это жалоба, у нас есть другой способ ее обработки. Мы теперь делаем наш рабочий процесс в нашем процессе модульным. Мы берем большую проблему и разбиваем ее на более мелкие подпроблемы и категории, которые мы можем лучше решать индивидуально. И вот как это выглядит в простом примере кода. Так что мы снова используем Pydantic здесь, чтобы определить модель данных, где мы теперь можем указать намерение и установить его равным литералу, который по сути является категорией. Это может быть вопрос, запрос или жалоба. Если установлено что-то другое, это вызовет ошибку. У нас также есть оценка уверенности и обоснование. Затем у нас есть простая функция, которую мы можем использовать для фильтрации по типу намерения, которое у нас есть. И затем, на основе этого, мы можем вызвать конкретную функцию в нашем приложении. Это не более чем использование простых операторов if-else для создания маршрутизатора, который мы видим здесь на этой диаграмме. Так что, если я сейчас запущу это, я пройду через эти три примера. Так что три вопроса. Что такое машинное обучение? Пожалуйста, запланируйте встречу на завтра. И я недоволен качеством моей поверхности. Так что вы обнаружите, что LLM теперь проходит через это, и она определит намерение. Так что для первого вопроса, э, она определила, что это вопрос. Теперь это запрос во втором, а в третьем — жалоба. И на основе этого она обрабатывала это по-разному, основываясь на функциях, которые мы ей предоставили. И теперь вы можете видеть, что вы также можете начать объединять несколько вызовов LLM вместе, где, если это вопрос, у нас есть другая функция, которая делает еще один вызов OpenAI для его обработки. Для запроса мы можем сделать что-то другое. Здесь мы просто делаем простое оператор печати, но это может быть что угодно. Вот как вы создаете модульные рабочие процессы, где вы реализуете логику на основе определенных условий. И теперь помните, что все это возможно, потому что мы, прежде всего, используем структурированный вывод. Так что мы знаем, что получаем эту модель данных обратно. Затем в нашем коде мы смотрим на ответ от LLM и можем сказать: возьми намерение, а затем мы можем создать простой оператор if-else для простой проверки. Если намерение равно «вопрос», мы делаем это. Если намерение равно «запрос», мы делаем это, и так далее. И теперь в этот момент я также могу вернуться к тому, что я упоминал ранее в этом видео, и это было быть очень осторожным с вызовами инструментов, и что для наших производственных сред мы редко используем вызовы инструментов вообще. Так что мы делаем? Ну, мы почти всегда предпочитаем использовать структурированный вывод и позволять LLM определять конкретный тип категории, а затем на основе этой категории создавать простые маршрутизаторы в нашем коде, которые вы только что видели, используя операторы if-else, чтобы решить, какую функцию или инструмент, если хотите, использовать. Теперь, в простых случаях, результат будет точно таким же, независимо от того, используете ли вы вызов инструмента или подход, который я только что упомянул. Но когда ваши системы становятся более сложными, и вам нужно отлаживать вещи, может быть очень сложно выяснить, почему LLM не решила использовать вызов инструмента. В то время как, если вы используете шаг классификации с категориями и обоснованием того, почему она решила использовать эту категорию, у вас есть полный журнал для выяснения, хорошо, смотрите, у нас есть ошибка в этом шаге нашего рабочего процесса для этого конкретного набора данных, где LLM фактически считала, что это такая категория, и она дала обоснование того, почему она считала, что это такая категория. И это именно то, что мы делали здесь. Так что, помимо простого вывода ответа и классификации, мы также перечисляем обоснование. Так что вы можете увидеть это здесь, если я сделаю это немного больше. Так что ввод, что такое машинное обучение, обоснование: ввод запрашивает информацию или объяснение концепции и т. д. Так что это дает вам полный журнал процесса принятия решений LLM, который очень полезен для отладки. Хорошо. И это подводит нас к строительному блоку номер шесть, и это восстановление. Так что в продакшене что-то пойдет не так. И API будут недоступны. LLM будут возвращать чушь. Вы столкнетесь с ограничениями скорости. И вам нужны блоки try-catch, логика повторных попыток с отсрочкой и запасные ответы, когда что-то ломается. Это основа создания надежных приложений. Это просто стандартная обработка ошибок, которую вы бы реализовали в любой производственной системе. Так что это может выглядеть примерно так. У вас есть входящий запрос. Вы проверяете, является ли он успешным, да или нет, на основе либо ошибки, которая происходит, либо какого-то типа данных, который присутствует или отсутствует. Если это успех, вы можете просто вернуть результат. Все хорошо. Но если это не успех, есть ошибка, вы можете, например, повторить попытку, во-первых, проверить, возможно ли это вообще. Так что вы можете повторить попытку с отсрочкой. Или, если это вообще невозможно, у вас есть какой-то сценарий отката, где вы, например, сообщаете пользователю: «Извините, я не могу помочь с этим вопросом, потому что не смог найти нужную информацию в базе знаний», например. И здесь быстро простой пример на языке программирования Python: вы можете использовать блоки try-except, где, если что-то пойдет не так в этой первой части кода, это вызовет какой-то тип ошибки, он перейдет к исключению. Теперь вы можете расширить это с помощью блока finally, где вы можете попробовать что-то в другом случае, сделать это, а затем, если это не сработает, вы можете наконец сделать что-то еще. Здесь вы можете создать какой-то механизм восстановления, где мы можем, например, проверить, доступен ли определенный ключ. Так что мы пытаемся получить доступ к полю в словаре, которого нет в данном случае. Так что он недоступен. Мы используем информацию отката, и это приводит к общему выводу или стандартному ответу в данном случае. Это очень простая иллюстрация. Это бесконечно сложно, когда дело доходит до правильной реализации этого в ваших собственных приложениях, потому что каждый блок try-except будет совершенно уникален для проблемы, которую вы пытаетесь решить, и ошибок, которые могут или не могут возникнуть. И затем последний строительный блок — это то, что мы называем обратной связью. Так что человеческий надзор и одобрение рабочих процессов, потому что некоторые процессы сейчас слишком сложны, чтобы их полностью обрабатывали ваши ИИ-агенты. Иногда вам просто нужен человек в цикле, чтобы проверить работу LLM, прежде чем она будет запущена или отправлена кому-либо. Так что, когда задача или решение слишком важны или сложны для полной автоматизации, например, отправка очень конфиденциальных электронных писем клиентам или совершение покупок, добавление этапов одобрения, где люди могут просмотреть и одобрить или отклонить перед выполнением, имеет решающее значение. Это базовый рабочий процесс одобрения, как вы бы создали для любого приложения, но затем действительно имеете человека в цикле, где он делает полную остановку и ждет этого момента. Так что, скажем, LLM сгенерировала ответ или создала какой-то контент, и прежде чем отправить его в мир, вам нужен человеческий обзор. Так что человек, например, получает всплывающее окно в Slack с кнопкой «да» или «нет», чтобы просмотреть его, одобрить, и тогда, если все хорошо, отлично. Мы отправим его, мы выполним его. Если это «нет», мы можем потенциально предоставить обратную связь о том, что нам нужно скорректировать. И тогда мы отправляем это обратно в LLM, и мы повторяем процесс еще раз. И вот где мы возвращаемся к тому, что я упоминал о важности людей в цикле и разнице между созданием того, что я называю ИИ-помощниками, которые напрямую работают с людьми в цикле, такими как ChatGPT или Cursor. пользователь что-то спрашивает, LLM что-то делает, и пользователь немедленно видит обратную связь и может корректировать, и они могут работать в этом танце, идя вперед и назад, по сравнению с полностью автономными системами, которые работают в фоновом режиме. Скажем, система поддержки клиентов полностью автономна. Она поступает, ИИ должен решить эту заявку, сгенерировать ответ и затем отправить его обратно. Существует большое различие между ними. И почти все очень эффективные и отличные ИИ-продукты, если они доходят до точки, когда это становится слишком сложно, вместо того, чтобы просто оптимизировать ваш промпт все дальше и дальше, вам может понадобиться человек в цикле, чтобы быть на безопасной стороне, прежде чем выпускать что-то в продакшн, где оно работает в 80% случаев, но в 20% случаев это полный бардак. И как вы можете фактически реализовать это в вашем приложении или кодовой базе здесь, в seven_feedback.py, вы можете интегрировать или создать стратегический момент, где у вас есть полная остановка и не позволяете агенту продолжать, пока он не получит одобрение. Теперь есть различные способы сделать это. Это очень простой пример. Вы можете интегрировать какой-то фронтенд-приложение. Вы можете интегрировать что-то вроде Slack. Вам, вероятно, потребуется настроить некоторые вебхуки для пинга туда и обратно. Это очень технично и выходит за рамки этого видео, но принцип тот же. Вы хотите создать полную остановку, где, например, если вы запустите это, и я запускаю это в терминале здесь, чтобы продемонстрировать это. Скажем, мы генерируем контент. Итак, вот сгенерированный контент прямо сейчас. Агент, прежде чем продолжить, ждет одобрения. Так что я здесь прямо сейчас делаю это в терминале, но опять же, в реальном приложении вы захотите иметь системы, с которыми пользователи могут легко взаимодействовать и получать уведомления. Так что, скажем, я нажимаю «да», тогда окончательный ответ одобрен. Когда я запущу это еще раз, я позволю ему сгенерировать еще один кусок контента. Я могу теперь проигнорировать это или, по сути, сказать «нет» и просто не одобрить этот рабочий процесс. Теперь, в идеале, у вас также будет какая-то обратная связь по этому поводу. Но опять же, принцип тот же, полная остановка перед отправкой. Хорошо? Итак, это ваши семь строительных блоков, которые вам нужно понять, чтобы создавать надежных ИИ-агентов. И теперь вы берете большую проблему. Вы разбиваете ее на более мелкие проблемы. И для каждой более мелкой проблемы вы пытаетесь решить ее, используя доступные строительные блоки, используя вызов API LLM — уровень интеллекта — только тогда, когда вы абсолютно не можете обойтись. И теперь, если вы хотите узнать, как оркестрировать целые рабочие процессы, используя эти строительные блоки, то есть как фактически объединить их и собрать вместе, вам стоит ознакомиться с оркестровкой рабочих процессов, которую я привожу здесь. Так что это репозиторий GitHub для курса, который я уже упоминал, который у меня есть на YouTube. Так что это тот же самый ресурс, то же самое видео. Я оставлю ссылку ниже. Это очень хорошее продолжение этого видео, где мы объединим все. Так что, пожалуйста, поставьте лайк этому видео, подпишитесь на канал, а затем перейдите и посмотрите это видео.