Stanford CS230 | Autumn 2025 | Lecture 8: Agents, Prompts, and RAG

Всем привет, добро пожаловать на очередную лекцию по глубокому обучению CS230. Сегодня мы поговорим об улучшении приложений больших языковых моделей, и я называю эту лекцию "За пределами LLM". В ней много нового материала, и идея этой лекции заключается в том, что мы начали изучать нейроны, затем изучили слои, затем изучили глубокие нейронные сети, а затем немного узнали о том, как структурировать проекты в C3, и теперь мы переходим на один уровень выше, к тому, как это будет выглядеть, если бы вы строили агентные системы искусственного интеллекта на работе в стартапе, в компании. Вероятно, это одна из самых практических лекций. Опять же, цель не в том, чтобы создать продукт от начала до конца в течение следующего часа или около того, а скорее в том, чтобы рассказать вам обо всех методах, которые инженеры по искусственному интеллекту освоили, разобрались, исследуют, чтобы после занятия у вас было представление о различных методах промптинга, различных агентных рабочих процессах, многоагентных системах, оценке, когда вы захотите углубиться, у вас будет багаж для более глубокого погружения и более быстрого обучения. Хорошо, давайте постараемся сделать это максимально интерактивным, как обычно. Когда мы посмотрим на повестку дня, она начнется с основной идеи проблем и возможностей для расширения LLM. Итак, мы начинаем с базовой модели. Как мы можем максимизировать производительность этой базовой модели? Затем мы глубоко погрузимся в первую линию оптимизации, которая является методами промптинга, и мы увидим множество из них. Затем мы пойдем немного глубже. Если бы мы могли заглянуть под капот и немного доработать, как бы это выглядело? Я не поклонник доработки, и я много об этом говорю, но я объясню почему. Я стараюсь избегать доработки как можно больше. Затем мы сделаем раздел четыре по генерации с дополнением извлечения или RAG, о котором вы, вероятно, слышали в новостях. Возможно, некоторые из вас играли с RAG. Мы разберем, что такое RAG и как он работает, а затем различные методы в рамках RAG, а затем мы поговорим об агентных рабочих процессах ИИ. Я дам определение. Эндрю Ын — один из первых, кто назвал эту тенденцию "агентными рабочими процессами ИИ", и поэтому мы посмотрим на определение, которое Эндрю дает агентным рабочим процессам, а затем начнем видеть примеры. Раздел шесть очень практичен. Это тематическое исследование, где мы подумаем об агентном рабочем процессе, и я попрошу вас измерить, работает ли агент на самом деле, и мы мозговым штурмом придумаем, как мы можем измерить, работает ли агентный рабочий процесс так, как вы хотите. Есть множество методов, называемых eval, которые решают эту проблему. Затем мы кратко рассмотрим многоагентный рабочий процесс, а затем у нас может быть открытая дискуссия, где я поделюсь некоторыми мыслями о том, что дальше в области ИИ. И я с нетерпением жду ваших мыслей по этому поводу. Итак, давайте начнем с проблемы расширения LLM. Открытый вопрос для вас. Вы все знакомы с предварительно обученными моделями, такими как GPT3.5 Turbo или GPT40. В чем ограничение использования только базовой модели? С какими типичными проблемами вы можете столкнуться при использовании обычной предварительно обученной модели?

Да.

Не хватает некоторых знаний в предметной области. Вы совершенно правы. Знаете, несколько лет назад у нас была группа студентов, не связанная с LLM, но они строили автономное сельскохозяйственное устройство или транспортное средство, которое имело камеру внизу, делающую снимки посевов, чтобы определить, больно ли растение или нет, следует ли его выбросить, использовать ли его или нет. И этот набор данных не является набором данных, который вы найдете. И базовая модель или предварительно обученная модель компьютерного зрения, конечно, не обладала бы этими знаниями. Что еще?

Да.

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

Текущие.

Не хватает чего.

Не хватает актуальной информации. LLM не обновлена. И на самом деле, вы правы. Представьте, что вам придется переобучать свою LLM с нуля каждые пару месяцев. Одна история, которая мне показалась забавной, — это, вероятно, три года назад или, может быть, больше, пять лет назад, когда во время своего первого президентства президент Трамп однажды написал в Твиттере "Kov Fe". Вы помните этот твит или нет, просто "Kov". И это, вероятно, была опечатка, или это было у него в кармане, я не знаю. Но этого слова не существовало. LLM, которые работали в то время в Twitter, не могли распознать это слово. И поэтому рекомендательная система как бы сошла с ума, потому что внезапно все высмеивали этот твит, используя слово "kov", и LLM была так запутана, что означает это, кому следует это показывать, и это пример того, что в наши дни, особенно в социальных сетях, так много новых тенденций, и очень трудно заставить LLM соответствовать новой тенденции и понимать новые слова. Я имею в виду, вы часто слышите слова поколения Z, такие как "re" или "mid" или что-то еще. Я не знаю всех из них, но вы, вероятно, хотите найти способ, который позволит LLM понимать эти тенденции, не переобучая LLM с нуля. Да. Что еще?

Она обучена иметь широкий спектр знаний, и если вы хотите сделать что-то специализированное, что может.

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

Это делает модель намного тяжелее, намного медленнее.

Так, возможно, у нее есть много широких знаний в предметной области, которые могут не понадобиться для вашего приложения, и поэтому вы используете массивную тяжелую модель, когда на самом деле вы используете только 2% возможностей модели. Вы совершенно правы. Вам может не понадобиться все это. Поэтому вы можете найти способы обрезать, квантовать модель, модифицировать ее. Все это хорошие моменты. Я добавлю еще несколько. LLM очень трудно контролировать. Ваш последний пункт на самом деле является примером этого. Вы хотите контролировать LLM, чтобы использовать часть ее знаний, но это не так. На самом деле она путается. Мы видели это в истории. В 2016 году Microsoft создала печально известный твиттер-бот, который учился у пользователей, и он быстро стал расистским подонком. Microsoft в итоге удалила бота через 16 часов после запуска. Сообщество очень быстро определило, что это расистский бот. И вы можете сочувствовать Microsoft в том смысле, что на самом деле трудно контролировать LLM. Возможно, они могли бы лучше квалифицировать перед запуском, но действительно трудно контролировать. Еще более недавно это твит от Сэма Альтмана в ноябре прошлого года, где шла дискуссия между Илоном Маском и Сэмом Альтманом о том, чья LLM является машиной пропаганды левых или правых, и они ненавидели LLM друг друга, но в конце концов это говорит о том, что даже эти две команды, Grok и OpenAI, которые, вероятно, имеют самое большое финансирование и много талантов, не справляются с контролем своих LLM. Вы знаете. И время от времени, если вы проводите время на X, вы можете увидеть скриншоты пользователей, взаимодействующих с LLM, и LLM говорит что-то действительно спорное или расистское, или, знаете ли, что-то, что не будет считаться великим по социальным стандартам, я полагаю. И это говорит о том, что модель действительно трудно контролировать. Второй аспект — это то, что вы упоминали ранее. LLM могут показывать низкую производительность в вашей задаче. И это может включать конкретные пробелы в знаниях, такие как медицинская диагностика. Если вы занимаетесь медицинской диагностикой, вы бы предпочли LLM, которая специализируется на этом и отлично справляется. И на самом деле, что мы не упоминали как группа, это источники. Так что ответ имеет конкретные источники. Вам трудно поверить чему-либо, если у вас нет фактического источника исследования, которое это подтверждает. Несоответствия в стиле и формате. Итак, представьте, что вы строите юридический агентный рабочий процесс ИИ. Юриспруденция имеет очень специфический способ письма и чтения, где каждое слово имеет значение. Знаете, если вы ведете переговоры по крупному контракту, каждое слово в этом контракте может означать что-то другое, когда дело доходит до суда. И поэтому очень важно, чтобы вы использовали LLM, которая очень хороша в этом. Точность имеет значение. А затем, знаете ли, понимание специфических задач, таких как классификация в нишевой области. Здесь я привел пример, где, скажем, биотехнологическая компания пытается использовать LLM для категоризации отзывов пользователей как положительных, отрицательных или нейтральных. Знаете, возможно, для этой компании то, что обычно считается отрицательным отзывом, на самом деле считается нейтральным отзывом, потому что NPS этой отрасли обычно намного ниже, чем в других отраслях. Это понимание специфических задач, и LLM должна быть согласована с тем, что компания считает категоризацией, которую она хочет. Мы скоро увидим пример того, как решить эту проблему, а затем ограниченная обработка контекста. Многие приложения ИИ, особенно в корпоративной сфере, требуют данных с большим количеством контекста. Просто чтобы привести простой пример, управление знаниями — важная область, в которую предприятия вкладывают много средств в инструменты управления знаниями. Когда вы заходите на свой диск и у вас есть все ваши документы, в идеале вы могли бы иметь LLM, работающую поверх этого диска. Вы можете задать любой вопрос, и она мгновенно прочитает тысячи документов и ответит: "Каковы были наши результаты по продажам в четвертом квартале?". Это было X долларов. Она находит это очень быстро. На практике, поскольку LLM не имеют достаточно большого контекста, вы не можете использовать автономную обычную предварительно обученную LLM для решения этой проблемы. Вам придется ее расширить. Это имеет смысл?

[смех]

Другой аспект, связанный с контекстными окнами, заключается в том, что они на самом деле ограничены. Если вы посмотрите на контекстные окна моделей за последние 5 лет, даже лучшие модели сегодня будут иметь контекстное окно или количество токенов, которое они могут принимать в качестве входных данных, где-то в сотнях тысяч токенов максимум. Чтобы дать вам представление, 200 000 токенов — это примерно две книги. Да. Так много вы можете загрузить, и это может читать практически все, и вы можете представить, что когда вы имеете дело с пониманием видео или более тяжелыми файлами данных, это, конечно, проблема. Так что [фыркает] вам, возможно, придется разбивать это, вам, возможно, придется встраивать это, вам, возможно, придется искать другие способы, чтобы LLM обрабатывала большие контексты. Механизм внимания также мощный, но проблематичный, потому что он не очень хорошо справляется с вниманием в очень больших контекстах. На самом деле существует интересная проблема, называемая "иголка в стоге сена". Это проблема ИИ или, скажем так, бенчмарк, где, чтобы проверить, хорошо ли LLM уделяет внимание конкретному факту в большом корпусе, исследователи могут случайно вставить в книгу одно предложение, которое описывает определенный факт, такой как Арун и Макс пьют кофе в Blue Bottle посреди Библии, скажем, или какой-то очень длинный текст. А затем вы спрашиваете LLM: "Что пили Арун и Макс в Blue Bottle?", и вы смотрите, помнит ли она, что это был кофе. На самом деле это сложная проблема не потому, что вопрос сложный, а потому, что вы просите модель найти факт в очень большом корпусе, и это сложно. Так что опять же, это ограничивающий фактор для LLM. Мы поговорим о RAG через секунду, но я хочу предварительно представить, знаете ли, есть споры о том, является ли RAG правильным долгосрочным подходом для систем ИИ. Так, на высоком уровне, RAG — это механизм, если хотите, который встраивает документы, которые LLM может извлекать, а затем добавлять в качестве контекста к своему первоначальному запросу и отвечать на вопрос. Он имеет множество применений, управление знаниями — это пример. Итак, представьте, что у вас снова есть ваш диск, но каждый документ как бы сжат в представлении, и LLM имеет доступ к этому низкоразмерному представлению. Споры, которые этот твит от Ю описывает, заключаются в том, что теоретически, если у нас есть бесконечные вычисления, то RAG бесполезен, потому что вы можете просто мгновенно прочитать огромный корпус и ответить на свой вопрос. Но даже в этом случае задержка может быть проблемой. Представьте себе время, которое требуется ИИ, чтобы прочитать весь ваш диск каждый раз, когда вы задаете вопрос. Это не имеет смысла. Таким образом, RAG имеет другие преимущества, помимо даже точности. Кроме того, важны и источники. Так что RAG позволяет вам указывать источники. Мы поговорим обо всем этом позже. Но всегда есть споры в сообществе о том, является ли определенный метод действительно перспективным, потому что на практике, поскольку вычислительная мощность удваивается каждый год, скажем, некоторые методы, которые мы изучаем сейчас, могут быть неактуальны через 3 года, мы не знаем, по сути [фыркает]. Знаете, и аналогия, которую он проводит с контекстными окнами и почему подходы RAG могут быть актуальны даже в долгосрочной перспективе, — это поиск. Знаете, когда вы ищете в поисковой системе, вы все еще находите источники информации, и на самом деле в фоновом режиме есть очень подробные алгоритмы обхода, которые ранжируют и находят конкретные ссылки, которые могут быть лучшими для представления вам. По сравнению с тем, если бы вам пришлось читать, представьте, что вам пришлось бы читать всю сеть каждый раз, когда вы делаете поисковый запрос, без возможности сузить область поиска, это снова может быть неразумно.

Хорошо, когда мы думаем об улучшении LLM, самый простой способ, которым мы думаем об этом, — это два измерения. Одно измерение — мы улучшаем саму базовую модель. Например, мы переходим от GPT 3.5 Turbo к GPT4, к GPT40, к GPT5. Каждый из них должен улучшить базовую модель. GPT5 — это другой спор, потому что он как бы упаковывает другие модели внутри себя. Но, знаете ли, если вы думаете о 3.5, 4 и 4, это действительно то, что это. Предварительно обученная модель улучшается, и поэтому вы должны видеть улучшение производительности в своих задачах. Но другое измерение — мы можем фактически использовать LLM таким образом, чтобы сделать ее лучше. Так что вы можете просто промптировать GPT40. Вы можете связывать некоторые запросы и улучшать запрос, и это улучшит производительность. Это показано. Вы можете даже поместить вокруг нее RAG. Вы можете поместить вокруг нее агентный рабочий процесс. Вы можете даже поместить вокруг нее многоагентную систему. И это еще одно измерение для улучшения производительности. Так что вот как я хочу, чтобы вы об этом думали. Какую LLM я использую, а затем как я могу максимизировать производительность этой LLM. Эта лекция посвящена вертикальной оси. Это методы, которые мы увидим вместе. Звучит хорошо для введения. Итак, давайте перейдем к промпт-инжинирингу. Я начну с интересного исследования, чтобы мотивировать, почему промпт-инжиниринг важен. Есть исследование от HPS, UPEN, а также Гарвардской школы бизнеса и других, включая Уортон, которые взяли подгруппу консультантов BCG, индивидуальных исполнителей, разделили их на три группы. Одна группа не имела доступа к ИИ. Одна группа имела доступ, я думаю, это был GPT 4. А затем одна группа имела доступ к LLM, а также обучение тому, как лучше промптировать. А затем они наблюдали за производительностью этих консультантов в широком спектре задач. Есть несколько вещей, которые они заметили, которые, как мне показалось, были интересными. Одна из них — то, что они называют "границей JAG". Это означает, что некоторые задачи, которые выполняют консультанты, выходят за пределы границы JAG. То есть ИИ недостаточно хорош. Он не улучшает производительность человека. На самом деле, он делает ее хуже. А некоторые задачи находятся в пределах границы, то есть ИИ на самом деле значительно улучшает производительность, скорость, качество консультанта. Многие задачи терпят неудачу внутри и многие задачи терпят неудачу снаружи, и они поделились своими выводами, но TL;DR заключается в том, что есть граница, в пределах которой ИИ абсолютно помогает, и одна, где они называют это поведение "засыпанием за рулем", когда люди полагались на ИИ в задаче, которая выходила за пределы границы, и на самом деле это привело к худшим результатам, потому что человек недостаточно внимательно проверял выходные данные. Они отметили, что группа, которая была обучена, была лучше, чем группа, которая не была обучена промпт-инжинирингу, что также мотивирует, почему эта лекция важна. Так что вы будете в этой группе после. Еще один вывод — это кентавры и киборги. Они заметили, что консультанты имели тенденцию работать с ИИ одним из двух способов, и вы сами можете оказаться частью одной из этих групп. Кентавры — мифические существа, которые наполовину люди, наполовину, я думаю, наполовину лошади. Да, лошади. Наполовину лошади, наполовину что-то еще. И это были люди, которые делили и делегировали. Они могли бы дать ИИ довольно большую задачу. Итак, представьте, что вы работаете над PowerPoint, что, как известно, делают консультанты. Вы можете написать очень длинный запрос о том, как вы хотели бы, чтобы он сделал ваш PowerPoint, а затем дать ему поработать некоторое время, а затем вернуться, и он будет готов, в то время как другие действовали бы как киборги. Киборги — это полностью слитые бионические человеко-роботы, человек-робот и робот, дополненный роботизированными частями. И эти люди не делегировали бы задачу полностью. Они бы работали очень быстро с моделью, как бы туда-сюда. Я считаю, что многие студенты на самом деле больше работают как киборги, чем кентавры. Но, возможно, в корпоративной среде, когда вы пытаетесь автоматизировать рабочий процесс, вы думаете больше как кентавр. Да, это просто что-то, что стоит иметь в виду. Кроме того, многие компании скажут вам: "О, мы нанимаем промпт-инженеров и т. д.". Это карьера. Я не верю в это. Я думаю, что это просто навык, которым должен обладать каждый. Вы не сможете построить карьеру на промпт-инжиниринге, но, вероятно, будете использовать его как очень мощный навык в своей карьере. Итак, давайте поговорим об основных принципах проектирования запросов. Я даю вам очень простой запрос: "Суммируй этот документ", а затем документ загружается вместе с ним. И у модели нет особого контекста относительно того, каким должно быть резюме, насколько длинным оно должно быть, о чем оно должно быть и т. д. Вы можете улучшить эти запросы, сделав что-то вроде: "Суммируй эту 10-страничную научную статью о возобновляемой энергетике в пять пунктов, сосредоточившись на ключевых выводах и последствиях для политиков". Это уже лучше, верно? Вы указываете аудиторию, и она будет адаптирована к аудитории. Вы говорите, что хотите пять пунктов, и вы хотите сосредоточиться только на ключевых выводах. Это лучший запрос, вы бы возразили. Как можно еще улучшить этот запрос? Какие еще методы вы слышали или пробовали сами, которые могли бы улучшить этот одноразовый запрос?

Да.

Хорошо. Правильно. Пример. Так, скажем, вы имеете в виду, вот пример отличного резюме. Да, вы правы. Это хорошая идея. Быть как кто-то, действовать как.

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

Звучит так, будто ты очень хорош в этом, как.

Ты лучший в мире в этом, объясни [смех]. Да, на самом деле, я имею в виду, что эти вещи работают, это смешно, но это действительно работает, сказать "действуй как XYZ". Это очень популярный шаблон запроса. Но мы увидим несколько примеров. Что еще можно сделать?

Да.

Лично мне нравится говорить: "Критикуй свой собственный проект".

Хорошо.

Критикуй свой собственный проект. Так что вы используете рефлексию. Так что вы можете фактически сделать один вывод, а затем попросить его раскритиковать и затем вернуть. Да, мы увидим это. Это отличный вариант. Это тот, который, вероятно, работает лучше всего среди них, но мы увидим некоторые примеры. Что еще? Да.

Перерывы.

Хорошо. Разбейте задачу на шаги. Вы знаете, как это называется?

Нет.

Хорошо. Цепочка рассуждений. Итак, это на самом деле популярный метод, который, как показали исследования, улучшает. Вы можете дать четкую инструкцию и также побудить модель думать шаг за шагом. Подходите к задаче шаг за шагом и не пропускайте ни одного шага. А затем вы даете ей некоторые шаги, такие как: шаг первый — определите три наиболее важных вывода. Шаг второй — объясните, как каждый вывод влияет на политику в области возобновляемой энергетики. Шаг третий — напишите пятипунктное резюме, где каждый пункт касается вывода и т. д. Итак, цепочка рассуждений, я привел ссылку на статью 2023 года, которая популяризировала цепочку рассуждений. Цепочка рассуждений очень, очень популярна прямо сейчас, особенно в стартапах ИИ, которые пытаются контролировать свои элементы.

Хорошо. [фыркает] Возвращаясь к вашим примерам о "действуй как XYZ", я люблю смотреть на запросы других людей, и Эндрю тоже об этом говорит. И на самом деле онлайн есть много бесплатных репозиториев запросов на GitHub. На самом деле, я привел ссылку на репозиторий шаблонов запросов "awesome prompt template" на GitHub, где есть так много примеров отличных запросов, которые создали инженеры. Они говорят, что это отлично работает для нас, и они опубликовали это онлайн. И многие из них начинаются с "действуй как", знаете ли, "действуй как терминал Linux", "действуй [смех] как переводчик с английского", "действуй как интервьюер на позицию", и так далее. Преимущество шаблона запроса заключается в том, что вы можете фактически вставить его в свой код и масштабировать для множества пользовательских запросов. Позвольте мне привести пример из Worker. Знаете, где Worker оценивает навыки, некоторые из вас уже прошли тесты и пытается персонализировать его для пользователя. И на самом деле, если вы прочитаете в HR-системе в корпорации, в HR-системе может быть: Джейн — менеджер по продукту уровня три, она в США, и ее предпочтительный язык — английский, и на самом деле эти метаданные могут быть вставлены в шаблон запроса, который мы персонализируем для Джейн, и аналогично для Джо, чей предпочтительный язык — испанский. Он будет адаптирован для Джо, и это называется шаблоном запроса.

Да.

Базовые модели не используют что-то, что вам нужно.

Итак, вопрос в том, используют ли базовые модели шаблоны запросов, или вам нужно интегрировать их самостоятельно? Так что базовые модели, вероятно, используют системный запрос, который вы не видите, как когда вы на самом деле печатаете на ChatGPT, это возможно, это не публично, что OpenAI за кулисами имеет что-то вроде "действуй как очень полезный помощник для этого пользователя", и, кстати, вот твои воспоминания о пользователе, которые мы сохранили в базе данных, ты можешь на самом деле проверить свои воспоминания, а затем идет твой запрос, а затем начинается генерация. Так что, вероятно, они используют что-то подобное, но это не значит, что вы не можете добавить свой собственный. Так что на самом деле, если вы думаете о шаблоне запроса для примера Worker, который я показывал, возможно, он начинается, когда вы вызываете OpenAI, с "действуй как главный помощник", а затем под ним — "действуй как отличный наставник ИИ, который помогает людям в их карьере", и шаблон запроса OpenAI также имеет "следуй инструкциям создателя" или что-то в этом роде, знаете, это возможно. Да. Вопросы о шаблонах запросов. Опять же, я бы посоветовал вам пойти и прочитать примеры запросов. Некоторые из них довольно продуманные. Давайте поговорим о нулевом выстреле против нескольких выстрелов. Это уже упоминалось. Вот пример. Снова, возвращаясь к категоризации отзывов о продуктах. Скажем, мы работаем над задачей, где запрос: "Классифицируй тон этого предложения как положительный, отрицательный или нейтральный". И затем вы вставляете отзыв, который звучит так: "Продукт в порядке, но я ожидал большего". Если бы я провел опрос в комнате, я бы поставил на то, что некоторые из вас скажут, что это отрицательно, некоторые из вас скажут, что это нейтрально, потому что у вас на самом деле есть первая часть, которая относительно положительна. "В порядке", а затем вторая часть: "Я ожидал большего", которая относительно отрицательна. Так где же вы остановитесь? Это может быть субъективный вопрос, и, возможно, в одной отрасли это будет считаться удивительным, а в другой — действительно плохим, потому что люди привыкли к очень восторженным отзывам. И поэтому способ, которым вы можете фактически согласовать модель с вашей задачей, — это преобразовать этот нулевой запрос. Нулевой выстрел относится к тому факту, что ему не дается ни одного примера, в несколько выстрелов, где модели дается набор примеров в запросе, чтобы согласовать ее с тем, что вы хотите, чтобы она сделала. Итак, пример здесь: вы снова вставляете тот же запрос, что и раньше, с отзывом пользователя, а затем добавляете: "Вот примеры классификации тона". "Это полностью превзошло мои ожидания". Положительный. "Это нормально, но я хотел бы, чтобы в нем было больше функций". Отрицательный. "Обслуживание было адекватным. Ни хорошо, ни плохо". Нейтральный. Теперь классифицируй тон этого предложения. Вы знаете, после того, как вы услышали об этих вещах. И модель затем говорит: "Отрицательный". И причина, по которой она говорит "отрицательный", конечно, вероятно, из-за второго примера, который гласил: "Это нормально, но я хотел бы, чтобы в нем было больше функций", что мы сказали модели, что это отрицательно, потому что модель увидела, что она теперь соответствует вашим ожиданиям. Запросы с несколькими выстрелами очень популярны. И на самом деле, для стартапов ИИ, которые немного более продвинуты, вы можете увидеть, как они поддерживают запрос в актуальном состоянии, когда пользователь что-то говорит, и они могут иметь человека, который его маркирует, а затем добавляет его как несколько выстрелов в соответствующий запрос в их кодовой базе. Вы можете думать об этом почти как о создании набора данных, но вместо того, чтобы на самом деле создавать отдельный набор данных, как мы видели с контролируемой доработкой, а затем обучать модель на нем, вы просто помещаете его непосредственно в запрос. И оказывается, что, вероятно, быстрее сделать это, если вы хотите быстро экспериментировать, потому что вы не трогаете параметры модели. Вы просто обновляете свои запросы. И знаете ли, если это текстовые примеры, вы можете фактически объединить так много примеров в один запрос. В какой-то момент он станет слишком длинным, и у вас не будет необходимого контекстного окна. Но это довольно сильный подход, который быстро согласовывает LLM.

Хорошо. Да.

Исследования о том, как долго может быть, пока он не начнет с.

Итак, вопрос был: есть ли какие-либо исследования о том, насколько длинным может быть запрос, прежде чем модель фактически потеряет себя или перестанет следовать инструкциям? Есть, проблема в том, что исследования устаревают каждые несколько месяцев, потому что модели становятся лучше. И поэтому я не знаю, где находится передовой край. Вы, вероятно, можете найти это онлайн на бенчмарках, как мы видим, я привожу пример, в продукте Worker у вас есть голосовой разговор, некоторые из вас, кто пробовал его, где вы просите объяснить, что такое запрос, а затем вы объясняете, а затем есть алгоритм оценки, в фоновом режиме мы знаем, что после восьми поворотов модель теряет себя после восьми поворотов, потому что вы всегда вставляете предыдущий ответ пользователя, он просто начинает сходить с ума, и поэтому методы, которые мы используем в фоновом режиме, это мы фактически создаем главы разговора. Возможно, одна глава — это первый запрос, а затем вы фактически начинаете заново с другого запроса. Вы можете суммировать первую часть разговора, вставить резюме и затем продолжать. Знаете, это хаки для инженеров, которые инженеры могли бы придумать в фоновом режиме. Да. Потому что да, восемь поворотов делают запрос довольно длинным на самом деле. [фыркает] Давайте перейдем к цепочке. Цепочка — это самый популярный метод из всего, что мы видели до сих пор в промпт-инжиниринге. Это не цепочка рассуждений. Итак, цепочка рассуждений, которую мы видели, — это "думай шаг за шагом, шаг первый, шаг второй, шаг третий, не пропускай ни одного шага". Это отличается. Это связывание сложных запросов для улучшения производительности. И вот как это выглядит. Вы берете одношаговый запрос, такой как "Прочитай этот отзыв клиента и напиши профессиональный ответ, который признает его обеспокоенность, объясняет проблему, предлагает решение", а затем вы вставляете отзыв клиента, который гласит: "Я заказал ноутбук, он прибыл на 3 дня позже, упаковка была повреждена, очень разочарован. Мне это срочно нужно для работы". А затем вывод — это электронное письмо, которое немедленно предоставляется вам LLM после того, как она прочитает запрос. Итак, это может сработать, но это может быть трудно контролировать, знаете ли, потому что подумайте об этом. Есть несколько шагов, которые вы перечислили, и все это встроено в один и тот же запрос. И если бы вы хотели отлаживать шаг за шагом и знать, какой шаг слабее, вы бы не смогли. У вас все было бы смешано вместе. Поэтому одно из преимуществ цепочки — вы можете разделить запросы, чтобы отлаживать их отдельно, и это также приведет к более простому способу улучшения вашего рабочего процесса. Давайте скажем, первый запрос — "Извлеки ключевые проблемы". Определите ключевые проблемы, упомянутые в этом отзыве клиента. Вставьте отзыв клиента. Второй запрос, используя эти проблемы. Итак, вы вставляете обратно проблемы. "Составьте план профессионального ответа, который признает обеспокоенность, объясняет возможные причины и предлагает решение". Итак, это не, знаете ли, запрос номер три, "Напиши полный ответ". Итак, используя план, "Напиши профессиональный ответ", и затем вы получаете свой окончательный вывод. Итак, теоретически, вы не можете сказать мне: "О, второй подход лучше первого". Но что вы можете заметить, это то, что мы можем фактически протестировать эти три запроса отдельно друг от друга и определить, получим ли мы наибольшую выгоду от инжиниринга первого запроса, его оптимизации, или второго, или третьего. Теперь у нас есть три независимых запроса. И знаете ли, возможно, если бы план был лучше, производительность, скажем, электронного письма, как часто его будут открывать или удовлетворенность пользователей ответом, на самом деле возрастет. И поэтому цепочка улучшает производительность, но, что более важно, помогает вам более плавно контролировать свой рабочий процесс и отлаживать его.

Да.

Так что, если мы знаем, что три запроса независимо работают очень хорошо, если мы объединим их в один запрос и подчеркнем этот процесс поэтапного мышления, получим ли мы в среднем тот же результат или нам все равно придется делать этот разбивку?

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

Да, вместо процесса.

Я понимаю. Смотрите, зачем нам нужны три шага?

Да.

Да. Я имею в виду, подумайте об этом. Промежуточный вывод — это то, что вы хотите видеть. Например, если я отлаживаю первый подход, способ, которым я бы это сделал, это я бы захватил пользовательские инсайты. Например, вот электронное письмо, насколько хорош был ответ. Палец вверх, палец вниз. Была ли решена ваша проблема? Палец вверх, палец вниз. Это сообщит мне, насколько хорош мой запрос. И я могу инжинирить этот запрос, оптимизировать его, и я, вероятно, получу некоторую выгоду. Но мне не будет легко отследить, в чем была проблема. В то время как во втором подходе, не только я могу использовать сквозные метрики для улучшения моего процесса, я также могу использовать промежуточные шаги. Например, если я посмотрю на запрос два и посмотрю на план, и увижу, что план на самом деле так себе, он не очень хорош, тогда я думаю, что я могу получить много выгоды от плана. Или план на самом деле очень хорош, но последний запрос не очень хорошо переводит его в электронное письмо. Итак, план — это именно то, что я хочу, чтобы LLM делала, но перевод в электронное письмо, ориентированное на клиента, не очень хорош. На самом деле, он не соответствует нашему словарю внутри компании. Тогда я знаю, что в третьем запросе я получу наибольшую выгоду. Так что это то, что он позволяет мне делать. Иметь промежуточные шаги для обзора.

Да.

Есть ли какие-либо задержки?

Мы поговорим об этом. Есть ли какие-либо проблемы с задержкой? Да. В определенных приложениях вы не хотите использовать цепочку или вы не хотите использовать длинную цепочку, потому что это добавляет задержку. Мы поговорим об этом позже. Хороший момент. Так что практически это то, как выглядит связывание сложных запросов. У вас есть первый запрос с вашей первой задачей. Он выдает вывод, который вставляется во второй запрос с определенной второй задачей. Вывод затем вставляется в третий запрос с определенной третьей задачей и так далее. Вот как это выглядит на практике. Отлично. Мы поговорим больше позже о тестировании ваших запросов, но сейчас есть методы для этого, и мы увидим позже на этой лекции с нашим тематическим исследованием, как мы можем тестировать наши запросы. Но вот пример того, как вы можете это сделать. У вас может быть рабочий процесс суммаризации, знаете ли, запрос, который является базовым. Это один запрос. У вас может быть улучшенная суммаризация, которая является измененным запросом этого или рабочим процессом с цепочкой, знаете ли. А затем у вас есть тестовый случай, который является входными данными, которые вы хотите суммировать, скажем, и затем у вас есть сгенерированный вывод, и вы можете попросить людей оценить эти выводы. И вы заметите, что базовый вариант лучше или хуже, чем улучшенный запрос. Конечно, этот ручной подход занимает время. Но это хороший способ начать, и обычно совет — начать работать руками в начале, потому что вы быстро заметите некоторые проблемы, и это даст вам лучшее интуитивное понимание того, какие настройки могут привести к лучшей производительности. Однако, если вы хотите масштабировать эту систему на множество продуктов, множество частей вашей кодовой базы, вы можете захотеть найти способ сделать это автоматически, не прося людей проверять и оценивать резюме, верно? Один из подходов — использовать, знаете ли, платформы, такие как At Portera, наша команда использует платформу под названием Prompt Fu, которая позволяет вам фактически автоматизировать часть этого тестирования. В двух словах, что она делает, так это позволяет вам немедленно запускать один и тот же запрос с пятью различными LLM, помещать все в таблицу, что делает ее очень простой для оценки человеком, скажем. Или, альтернативно, она может позволить вам определить LLM-судей. LLM-судьи могут быть разных типов. Например, у меня может быть LLM-судья, который делает парное сравнение. Итак, то, что просят сделать LLM, это: вот два резюме. Просто скажите мне, какое из них лучше другого. Вот что делает LLM. И это может быть использовано как прокси для того, насколько хорош базовый вариант суммаризации по сравнению с улучшенным. Другой способ использовать LLM-судью — это если вы делаете это для оценки одного ответа. Итак, вот резюме, оцените его от одного до пяти, знаете ли, а затем вы можете пойти еще глубже и сделать парное сравнение с учетом эталона, или вы также добавляете рубрику. Вы говорите, что пять — это когда резюме ниже 100 символов. Я просто выдумываю, ниже 100 символов, упоминает по крайней мере три ключевых момента, которые различны, и начинается с первого предложения, которое отображает обзор, а затем переходит к деталям. Это отличное резюме, пять из пяти. Ноль — это когда LLM не смогла суммировать и на самом деле была очень многословной, скажем так, и поэтому вы помещаете за ней рубрику, и у вас есть LLM, просто находящая рубрику. Конечно, вы можете теперь комбинировать различные методы. Вы можете использовать несколько выстрелов для рубрики. Вы можете фактически дать примеры пяти из пяти, четырех из четырех, трех из трех, потому что теперь вы знаете несколько методов. Хорошо. [очищает горло] Это имеет смысл? Да. Хорошо. Итак, это был второй раздел по промпт-инжинирингу или первая линия оптимизации. Теперь, скажем, вы исчерпали все свои возможности для промпт-инжиниринга и думаете о том, чтобы фактически прикоснуться к модели, модифицировать ее веса или доработать ее. Другими словами, я говорил вам, что я не поклонник доработки. Есть несколько причин, почему. Во-первых, для доработки обычно требуются существенные размеченные данные, хотя сейчас есть подходы, которые становятся лучше в доработке, которые больше похожи на промптинг с несколькими выстрелами, чем на доработку. Это как бы сливается, хотя один модифицирует веса, другой — нет. Доработанные модели также могут переобучиться на конкретных данных. Мы увидим забавный пример. Теряя свою общую полезность. Так что вы можете доработать модель, и на самом деле, когда кто-то задает довольно общий вопрос, она работает не очень хорошо. Вы знаете, она может работать хорошо на вашей задаче. Так что это может быть актуально или нет. А затем это требует времени и затрат. Это моя главная проблема. И знаете ли, в Workera мы избегаем доработки как можно больше. Потому что к тому времени, когда вы закончите доработку своей модели, выйдет следующая модель, и она фактически превзойдет вашу доработанную версию предыдущей модели. Поэтому я бы избегал доработки, насколько это возможно. Преимущество методов промпт-инжиниринга, которые мы видели, заключается в том, что вы можете поместить следующую лучшую предварительно обученную модель непосредственно в свой код. Она обновится немедленно. Доработка так не работает. [смех] Однако есть преимущества, когда это все еще имеет смысл. Если задача требует повторяющегося вывода с высокой точностью, такого как юридическое научное объяснение, и если общая LLM испытывает трудности с предметно-специфическим языком. Итак, давайте быстро посмотрим на пример вместе, который является примером от Росса Лазеровица, я думаю, это было пару лет назад, 23 сентября, когда Росс пытался сделать доработку Slack. Он посмотрел на множество сообщений в Slack внутри своей компании и сказал: "Я доработаю модель, которая говорит как мы или работает как мы, потому что именно так мы работаем, верно? Это данные, которые представляют, как люди работают в компании". И поэтому он фактически доработал модель. Дал ей запрос вроде: "Привет, напиши, знаешь ли ты, он делегировал модели: "Напиши пост в блоге на 500 слов о промпт-инжиниринге", и модель ответила: "Я займусь этим утром". А затем он попытался надавить на модель немного дальше и сказал: "Сейчас утро". И модель сказала: "Я пишу прямо сейчас. Сейчас 6:30 утра. Напиши это сейчас". Хорошо, пожалуйста. [смех] Хорошо, я напишу это сейчас. Я на самом деле не знаю, что вы хотите, чтобы я сказал о промпт-инжиниринге. Я могу только описать процесс. Единственное, что приходит на ум для заголовка, это "Как мы строим запросы?". Это своего рода забавный пример доработки, потому что правда в том, что это пошло не так. Он хотел, чтобы модель говорила как мы на работе, а в итоге она вела себя как люди и на самом деле не следовала инструкциям. Так что один пример, почему я бы избегал доработки. Отлично, давайте поговорим о RAG. RAG важен. Важно знать о нем и, по крайней мере, иметь основы. Это очень распространенный вопрос на собеседовании, кстати. Если вы идете на собеседование, вас могут попросить объяснить в двух словах пятилетнему ребенку, что такое RAG, и, надеюсь, после этого вы сможете это сделать. Итак, мы видели некоторые проблемы с автономными LLM. Эти проблемы включают маленькое контекстное окно, тот факт, что трудно запоминать детали в большом контекстном окне, пробелы в знаниях, знаете ли, даты окончания, которые вы упоминали ранее. Модель может быть обучена до определенной даты, а затем она не может следовать тенденциям или быть в курсе. Галлюцинации, есть некоторые области, подумайте о медицинской диагностике, где галлюцинации очень дорогостоящи. Вы не можете позволить себе галлюцинацию. Знаете, даже в образовании представьте себе развертывание модели для образования молодежи США, и она галлюцинирует и учит миллионы людей чему-то совершенно неправильному. Это проблема. А затем отсутствие источников. Многим областям нравятся источники. Исследовательским областям нравятся источники. Образованию нравятся источники. Юриспруденции тоже нравятся источники. И поэтому предварительно обученная LLM не очень хорошо справляется с указанием источников. И на самом деле, если вы пытались найти источники в обычной LLM, она на самом деле много галлюцинирует. Она выдумывает научные статьи. Она просто перечисляет совершенно фальшивые вещи. Итак, как мы это решаем? С помощью RAG. RAG интегрируется с внешними источниками знаний, базами данных, документами, API. Он гарантирует, что ответы более точны, актуальны и обоснованы, потому что вы можете фактически обновлять свой документ. Ваш диск всегда обновлен. Я имею в виду, в идеале вы всегда добавляете новые документы. И когда вы запрашиваете "Каковы были наши результаты по продажам в четвертом квартале?", надеюсь, там будет последняя презентация совета директоров на диске, и она сможет прочитать последнюю презентацию совета директоров. Да. [фыркает] А также больший контроль разработчика. Мы увидим, почему RAG позволяет осуществлять целенаправленную настройку без необходимости переобучения модели. На самом деле, вы не трогаете модель с RAG. Это действительно техника, которая накладывается на модель. Итак, чтобы увидеть пример RAG, это приложение для ответов на вопросы, где мы находимся в медицинской области, и пользователь задает запрос. "Каковы побочные эффекты препарата X?". Это важный вопрос. Вы не можете галлюцинировать. Вам нужны источники. Вам нужно быть в курсе. Возможно, есть новое обновление этого препарата, которое теперь есть в базе данных, и вам нужно его прочитать. Так что вам нужно, RAG — отличный пример того, что вы хотели бы использовать здесь. То, как это работает, у вас есть база знаний из множества документов. Что вы делаете, так это используете встраивание для встраивания этих документов в низкоразмерные представления. Например, если документ — это PDF, длинный PDF, вы можете, знаете ли, прочитать PDF, понять его, а затем встроить. Мы видели множество подходов к встраиванию вместе. Тройная потеря и т. д., вы помните. Итак, представьте, что один из них здесь для LLM — это встраивание этих документов в низкое представление. Если представление слишком маленькое, вы потеряете информацию. Если оно слишком большое, вы добавите задержку, верно? Это компромисс. Вы будете хранить обычно эти представления в базе данных, называемой векторной базой данных. Есть много поставщиков векторных баз данных. Знаете, я думаю, я перечислил пару, которые очень распространены. Нет, я не перечислил, но я могу поделиться позже. Векторная база данных фактически хранит эти векторы в очень эффективной форме, позволяя быстро извлекать их с определенной метрикой расстояния. Итак, что вы делаете, так это вы также встраиваете обычно с тем же алгоритмом пользовательские запросы и запускаете процесс извлечения, который фактически означает, что на основе встраивания из пользовательского запроса и векторной базы данных найдите релевантные документы на основе расстояния между этими встраиваниями. Как только вы нашли релевантные документы, вы извлекаете их, а затем добавляете их к пользовательскому запросу с системным запросом или шаблоном запроса сверху. Так что шаблон запроса может быть: "Ответь на запрос пользователя на основе списка документов. Если ответа нет в документе, скажи: "Я не знаю"". Это ваш шаблон запроса, куда вставляется запрос пользователя, вставляются документы, а затем ваш вывод должен быть тем, что вы хотите, потому что он теперь основан на документе. Вы также можете добавить к этому шаблону запроса: "Сообщи мне точную страницу, главу, строку документа, которая была релевантна, и фактически свяжи ее также, чтобы быть более точным". Есть ли вопросы по RAG? Есть простой обычный RAG. Да. Да.

Встраивания документов по-прежнему сохраняют информацию о том, что находится на какой странице и в каком абзаце?

Вопрос.

Является ли, сохраняют ли векторные представления документов информацию о местоположении информации в этом документе, особенно в больших документах? Мм, отличный вопрос. Мы вернемся к нему через секунду, потому что вы правы, что обычный RAG может не справиться с очень большими документами. Итак, скажем так, вы знаете, когда вы открываете коробку с лекарством, и у вас есть эта гигантская белая бумага со всей информацией, и она очень длинная, мм, возможно, обычный RAG не справится. Поэтому люди придумали ряд методов для улучшения RAG, и, на самом деле, разбиение на части — это отличный метод, который очень популярен. Таким образом, вы можете фактически хранить в векторной базе данных векторное представление всего документа, а поверх этого вы также будете хранить вектор уровня главы, вы знаете, и когда вы извлекаете, вы извлекаете документ, вы извлекаете главу, и это позволяет вам быть более точным с источниками. Это один пример. Мм, другой популярный метод — это HIDE, мм, гипотетические векторные представления документов, где группа исследователей опубликовала статью, показывающую, что когда вы получаете запрос пользователя, одна из основных проблем заключается в том, что запрос пользователя на самом деле не похож на ваши документы. Например, запрос пользователя может быть таким: «Каковы побочные эффекты препарата X», тогда как на самом деле в документе в векторной базе данных векторы представляют очень длинные документы. Так как же гарантировать, что векторное представление будет близко к векторному представлению документа? Они используют запрос пользователя для создания поддельного, галлюцинаторного документа. Они встраивают этот документ, а затем сравнивают его с вектором в векторной базе данных. Это имеет смысл? Например, пользователь говорит: «Каковы побочные эффекты препарата X?» Есть подсказка, которая дается другой подсказке, которая гласит: «На основе этого запроса пользователя создайте пятистраничный отчет, отвечающий на запрос пользователя». Он генерирует, возможно, совершенно поддельный ответ. Вы встраиваете это, и это, вероятно, будет ближе к документу, который вы ищете. Да, это один пример подхода RAG. Опять же, цель этой лекции — не пройти через все эти три и объяснить вам каждый метод, который был открыт для RAG, но я просто хотел показать вам, сколько исследований было проведено между 2020 и 2025 годами в области RAG и сколько направлений исследований у вас теперь есть, из которых вы можете учиться. Обзорная статья связана в слайдах, кстати, и я поделюсь ими после лекции. >> [смех] >> Отлично. Итак, мм, мы добились некоторого прогресса. Надеюсь, теперь вы чувствуете, что если бы вы начали приложение LLM, вы знаете, как лучше составлять подсказки, вы знаете, как создавать цепочки, вы знаете, как выполнять дообучение, мм, вы также знаете, как выполнять извлечение, и у вас есть багаж методов, которые вы можете прочитать и найти кодовую базу, вытащить код, просмотреть код, но у вас есть широта. Теперь, мм, следующий набор тем, которые мы рассмотрим, связан с вопросом о том, как мы можем расширить возможности LLM от выполнения одиночных задач и использования внешних знаний до обработки многошаговых автономных рабочих процессов. Да. И вот здесь мы переходим к настоящему агентскому ИИ. Итак, давайте поговорим о рабочих процессах агентского ИИ, направленных на автономные и специализированные системы. Затем мы поговорим об оценках. Затем мы рассмотрим многоагентные системы. И мы закончим небольшими размышлениями о том, что дальше в ИИ. Итак, мм, Эндрю Ванг фактически ввел термин «агентные рабочие процессы ИИ». Мм, и его причина заключалась в том, что многие компании используют, скажем так, агентов, агентов, агентов повсюду. Агенты повсюду. Если вы пойдете работать в эти компании, вы заметите, что под агентом они подразумевают очень разные вещи. Некоторые люди на самом деле имеют подсказку и называют ее агентом. Вы знаете, другие люди имеют очень сложную многоагентную систему. Они называют ее агентом. И поэтому называть все агентом — это несправедливо. Поэтому Эндрю говорит: «Давайте называть это агентными рабочими процессами, потому что на практике это набор подсказок с инструментами с дополнительными ресурсами, вызовами API, которые в конечном итоге помещаются в рабочий процесс, и вы можете назвать этот рабочий процесс агентным». Так что все дело в многошаговом процессе для завершения задачи. Также называние его агентным рабочим процессом позволяет нам не путать его с тем, что я называл агентом на прошлой лекции с обучением с подкреплением, потому что в RL агент имеет очень специфическое определение: взаимодействует со средой, переходит из одного состояния в другое, имеет вознаграждение и наблюдение. Вы помните эту диаграмму, верно? Итак, вот пример того, как мы переходим от одношаговой подсказки к многошаговому агентному рабочему процессу. Давайте скажем, пользователь запрашивает продукт: «Какова ваша политика возврата в чат-боте?» И ответ с использованием RAG гласит: «Возврат возможен в течение 30 дней с момента покупки». И, возможно, RAG может даже ссылаться на документ о политике. Это то, что мы узнали до сих пор. Вместо этого агентный рабочий процесс может работать следующим образом. Пользователь говорит: «Могу ли я получить возврат за свой заказ?» И ответ через агентный рабочий процесс: агент извлекает политику возврата, используя RAG. Затем агент связывается с пользователем и говорит: «Можете ли вы предоставить номер вашего заказа?» Затем агент запрашивает API для проверки деталей заказа и, наконец, возвращается к пользователю и подтверждает: «Ваш заказ подлежит возврату». Сумма будет обработана в течение 3-5 рабочих дней. Это гораздо более продуманно, чем первая версия, которая, так сказать, обычная, верно? Итак, именно об этом мы будем говорить на следующих нескольких слайдах: как перейти от первого ко второму. Мм, существует множество специализированных агентных рабочих процессов онлайн. Вы знаете, вы слышали, и если вы бываете в Сан-Франциско, вы, вероятно, видите множество рекламных щитов: «Инженер-программист ИИ», «Ментор по навыкам ИИ», с которым вы взаимодействовали на уроке, «Рабочий ИИ», «Юрист ИИ», «Специализированный облачный инженер ИИ». Вы знаете, было бы преувеличением сказать, что все работает, но ведется работа в этом направлении. Да, я лично не поклонник того, чтобы ставить лицо за этими вещами. Я думаю, это трюк, и я думаю, что через несколько лет очень немногие продукты будут иметь человеческое лицо за собой. Мм, но это может быть маркетинговый ход некоторых стартапов. Это скорее пугает, чем увлекает, честно говоря. Мм, я хочу поговорить о пиратском сдвиге. Мм, это особенно полезно. Допустим, вы инженер-программист или планируете им стать, потому что инженерия программного обеспечения как дисциплина как бы меняется, или, по крайней мере, лучшие инженеры, с которыми я работал, способны перейти от детерминированного мышления к нечеткому мышлению и балансировать между ними, когда им нужно что-то сделать. Итак, вот пиратский сдвиг между традиционным программным обеспечением и агентным программным обеспечением ИИ. Первое — это способ обработки данных. Традиционное программное обеспечение работает со структурированными данными. У вас есть JSON, у вас есть базы данных. Они размещены в очень структурированном виде в конвейере обработки данных, а затем используются для отображения на определенном интерфейсе. Пользователь может заполнить форму, которая затем извлекается и вставляется в базу данных. Все это исторически были структурированные данные. Теперь все больше и больше компаний работают с неструктурированным текстом, изображениями, мм, и всем этим требуется динамическая интерпретация, мм, для преобразования входных данных в выходные. Само программное обеспечение было детерминированным. Теперь у вас есть много программного обеспечения, которое является нечетким, а нечеткое программное обеспечение создает так много проблем. Я имею в виду, представьте, что вы позволяете пользователю спрашивать что угодно на вашем веб-сайте. Шансы, что он сломается, огромны. Шансы, что вы подвергнетесь атаке, огромны. Шансы, это действительно, действительно сложно. Это сложнее, чем люди представляют это в Твиттере. [фыркает] Мм, нечеткая инженерия действительно сложна. Да, вы можете получить ненависть как компания, потому что один пользователь сделал что-то, что вы ему разрешили, что в итоге сломало базу данных, и в итоге, вы знаете, мы видели это со многими компаниями за последние пару лет. Так что требуется очень специализированное инженерное мышление для нечеткой инженерии, но также и знание, когда нужно быть детерминированным. Другое, что я называю, это с агентным программным обеспечением ИИ, мм, вы, вы, вы как бы хотите думать о своем программном обеспечении как о своем менеджере. Итак, вы знакомы с монолитным или, вы знаете, подходами к микросервисам в программном обеспечении, вы знаете, где вы структурируете свое программное обеспечение в разных, вы знаете, блоках, которые могут общаться друг с другом, и это позволяет командам отлаживать по одному разделу за раз, вы знаете, теперь эквивалентом в агентном ИИ является то, что вы думаете как менеджер. Итак, вы думаете: «Хорошо, если бы мне пришлось делегировать выполнение моего продукта группе людей, какие бы это были роли?» Был бы у меня графический дизайнер, который затем, вы знаете, собирает диаграмму и отправляет ее менеджеру по маркетингу, который превращает ее в хороший пост в блоге, который затем передает эксперту по маркетингу, который затем публикует пост в блоге, а затем оптимизирует и проводит A/B-тестирование, затем к специалисту по данным, который анализирует данные и затем выдвигает гипотезы и проверяет их или опровергает их. Так вы бы обычно думали, если бы строили агентное программное обеспечение ИИ, тогда как эквивалент этого в традиционном программном обеспечении может быть совершенно другим. Это может быть, у нас есть блок обработки данных прямо здесь, который занимается всей нашей обработкой данных. А затем здесь у нас есть UI/UX. Все, что связано с UI/UX, идет сюда. И вы знаете, компании могут структурировать это по-разному. И вот бизнес-логика, о которой мы хотим позаботиться. И над бизнес-логикой работают пять инженеров. Скажем так, хорошо [фыркает и смеется] тестирование и отладка также очень разные, и мы поговорим об этом в следующем разделе. Мм, другое, что, как мне кажется, имеет значение, это то, что с ИИ в инженерии стоимость экспериментов резко снижается, и поэтому люди, как мне кажется, должны быть более комфортными, выбрасывая код, вы знаете, это как в традиционной инженерии программного обеспечения, вы, вероятно, не выбрасываете код тоннами, вы строите код, и он надежен и пуленепробиваем, а затем вы обновляете его со временем, когда мы видели, что ИИ-компании более комфортно выбрасывают код. Да. Что имеет преимущества с точки зрения скорости, с которой вы двигаетесь, но также и недостатки с точки зрения качества вашего программного обеспечения, которое может чаще ломаться. Нет. Хорошо. Итак, в любом случае, я просто хотел сделать отступление о пиратском сдвиге от детерминированной к нечеткой инженерии. Мм, о, и на самом деле я могу привести пример из worker, который мы узнали, вероятно, за последние 12 месяцев: если вы использовали worker, вы, возможно, видели, что интерфейс иногда задает вам вопросы с множественным выбором, а иногда — с множественным выбором, а иногда — перетаскиванием, упорядочиванием, сопоставлением и т. д. Это примеры детерминированных типов элементов, то есть вы отвечаете на вопрос с множественным выбором, есть один правильный ответ, он полностью детерминирован. С другой стороны, у вас иногда бывают голосовые вопросы, где вы проходите ролевую игру, или у вас есть голосовые вопросы с кодированием, где ваш код считывается интерфейсом или чем-то еще. Это нечеткие вопросы, означающие, что алгоритм оценки может допускать ошибки, и эти ошибки могут быть дорогостоящими. И поэтому компаниям приходится придумывать систему «человек в контуре», которую вы, возможно, видели с функцией апелляции в конце. Итак, в конце оценки есть функция апелляции, которая позволяет вам сказать: «Я хочу подать апелляцию на агента, потому что я хочу оспорить то, что сказал агент о моем ответе, потому что я думал, что я лучше, чем думал агент». И тогда вы привлекаете человека в контур, который затем может исправить агента, может сказать агенту: «На самом деле, вы были слишком строги к ответу этого человека». Мм, и, знаете, это пример нечетко спроектированной системы, которая затем добавляет человека в контур, чтобы сделать ее более согласованной. И поэтому, если вы строите компанию, я бы посоветовал вам подумать: «Что я могу сделать с помощью детерминизма, и давайте сделаем это». А затем нечеткие вещи, я хочу сделать нечеткие вещи, потому что это позволяет больше взаимодействовать. Это позволяет больше общаться взад и вперед, но мне нужно установить для этого защитные ограждения. И как я собираюсь спроектировать эти защитные ограждения, в основном. Хорошо, вот еще один пример из корпоративных рабочих процессов, которые, вероятно, изменятся из-за агентного ИИ. Мм, это статья от McKinsey, я полагаю, из прошлого года, где они изучали финансовое учреждение и сказали, что, вы знаете, мы наблюдаем, что они часто тратят от одной до четырех недель на создание меморандума о кредитном риске, и вот процесс. Менеджер по работе с клиентами собирает данные из 15 и более чем 15 источников о заемщике, типе кредита и других факторах. Затем менеджер по работе с клиентами и кредитный аналитик совместно анализируют эти данные из этих источников. Затем кредитный аналитик обычно тратит 20 часов или более на написание меморандума, а затем возвращается к менеджеру по работе с клиентами. Они дают обратную связь, а затем проходят через этот цикл снова и снова, и это занимает много времени, чтобы получить кредитный меморандум, а затем провести исследование, где они изменили процесс. Они сказали, что агенты GenAI могут сократить время на 20-60% для меморандумов о кредитном риске, и процесс изменился: менеджер по работе с клиентами напрямую работает с системой агентов GenAI, предоставляет соответствующие материалы, необходимые для создания меморандума. Агент разбивает проект на задачи, которые назначаются специализированным агентам, собирает и анализирует данные из нескольких источников. Составляет меморандум. Затем менеджер по работе с клиентами и кредитный аналитик садятся вместе, просматривают меморандум, дают обратную связь агенту, и в течение, вы знаете, на 20-60% меньше времени все готово. И это пример того, где вы на самом деле не меняете человеческих заинтересованных сторон, вы просто меняете процесс и добавляете GenAI, чтобы сократить время, необходимое для получения кредитного меморандума. Оказывается, что, представьте, вы — корпорация, и у вас есть, вы знаете, 100 000 сотрудников, и есть много корпораций со 100 000 сотрудников. Вы сейчас в кризисе с точки зрения перепроектирования ваших рабочих процессов. Вы, вы знаете, оказывается, что если вы фактически извлечете описания вакансий из системы HR и интерпретируете их, вы также извлечете рабочие процессы бизнес-процессов, которые у вас закодированы на вашем диске. Вы фактически можете найти выгоды в нескольких местах, и в ближайшие несколько лет вы, вероятно, увидите, как рабочие процессы будут более оптимизированы для добавления GenAI. Даже если это произойдет, самое сложное — изменить людей. Мы знаем, что это здорово в теории, но теперь давайте попробуем применить этот второй рабочий процесс для 10 000 аналитиков кредитных рисков и менеджеров по работе с клиентами. По моим прогнозам, это займет годы. Потребуется 10-20 лет, чтобы это действительно было реализовано в масштабе организации, потому что изменения так трудны, вы знаете, так трудно перестроить бизнес-процессы, описания вакансий, стимулировать людей быть другими и вести себя по-другому, и обучать их, и так далее, и так далее, вы знаете, вот к чему движется мир, но это займет много времени, я думаю. Мм, затем я хочу поговорить о том, как на самом деле работает агент и каковы основные компоненты агента. Мм, представьте себе, мм, агент ИИ для бронирования путешествий. Это простой пример, о котором вы все думали. Мне до сих пор не удалось заставить агента забронировать мне поездку или или я боялся, потому что он забронирует очень дорогую или долгую поездку. Но теоретически, мм, вы можете иметь агент для бронирования путешествий, у которого есть подсказки. Итак, подсказки, которые мы видели, мы знаем методы оптимизации этих подсказок. У этого агента путешествий также есть система управления контентом и контекстом, которая, по сути, является памятью о том, что он знает о пользователе. Эта система управления контекстом может включать основную память или рабочую память и архивную память. Хорошо. Разница в том, что мм, внутри памяти, не вся память должна быть быстрой для доступа. Например, подумайте об этом: вы родились в продукте, и первый вопрос: «Привет, как вас зовут?» и я говорю: «Меня зовут Кион», это, вероятно, останется в рабочей памяти, потому что агент каждый раз, когда будет говорить со мной, захочет использовать мое имя, верно? Но затем, возможно, второй вопрос: «Кион, какой у вас день рождения?» и я даю ему свой день рождения. Нужно ли ему мой день рождения каждый день? Вероятно, нет. Поэтому он, вероятно, поместит его в долговременную память или архивную память, и эти воспоминания медленнее доступны, они дальше вниз по стеку, и вы знаете, что эта структура позволяет агенту определять, что является рабочей памятью, а что — долговременной памятью, вы знаете, и это облегчает агенту супербыстрое извлечение, потому что подумайте об этом: когда вы взаимодействуете с GPT, вы чувствуете, что он иногда очень личный, верно? Вы чувствуете, что он вас понимает. Представьте, что каждый раз, когда вы его вызываете, ему приходится читать воспоминания, и это может быть дорого. Это очень обременительные расходы, потому что это происходит каждый раз, когда вы с ним разговариваете. Поэтому вы хотите быть очень оптимизированными с рабочей памятью. Вы знаете, если поиск в памяти занимает 3 секунды, каждый раз, когда вы будете разговаривать со своим LLM, это займет 3 секунды, чего вы не хотите. Итак, в любом случае, а затем у вас есть инструменты. Инструменты могут включать API, такие как API поиска авиабилетов, API бронирования отелей, API аренды автомобилей, API погоды, а затем API обработки платежей. И обычно вы хотите сообщить своему агенту, как работает этот API. Оказывается, агенты или LLM, я должен сказать, очень хорошо читают документацию API. Итак, вы даете ему документацию API, и он читает JSON и читает, как выглядит GET-запрос, и это формат, который мне нужно отправить, а затем он отправляет его в этом формате, скажем так, а затем извлекает что-то. Это имеет смысл? Эти различные компоненты, вы знаете, Entropic также говорит о ресурсах. Ресурсы — это данные, которые где-то находятся, которые вы можете позволить своему агенту читать. Например, если вы создаете свои стартапы, у вас есть CRM. В CRM есть данные, и вы хотите использовать поиск по этим данным. Вы, вероятно, предоставите инструмент поиска и дадите доступ к ресурсу, и он будет выполнять поиск, когда вы захотите. Супер быстро. Этот тип архитектуры может быть построен с разной степенью автономии, от наименее автономной до наиболее автономной, и я приведу вам несколько примеров. Наименее автономная — это то, что вы жестко закодировали шаги. Например, я говорю агенту путешествий: сначала определите намерение, затем, мм, найдите в базе данных историю этого клиента с нами и его предпочтения, затем перейдите к правильному API, бла-бла-бла, затем перейдите к Я бы жестко закодировал шаги. Хорошо, это наименее автономный. Полуавтономный — я могу жестко закодировать инструменты, но я не собираюсь жестко кодировать шаги. Итак, я скажу агенту: «Вы ведете себя как агент путешествий, и ваша задача — помочь человеку забронировать поездку, и вот инструменты, к которым у вас есть доступ». И поэтому я не жестко кодирую шаги. Я просто жестко кодирую инструменты, к которым у вас есть доступ. Более автономный — агент решает шаги и может создавать инструменты. Итак, здесь вы можете фактически предоставить агенту доступ к редактору кода, и агент фактически сможет обращаться к любому API в Интернете, выполнять поиск в Интернете. Он может даже создавать код для отображения данных пользователю. Он может даже выполнять некоторые расчеты, например: «О, я рассчитаю самый быстрый маршрут из Сан-Франциско в Нью-Йорк». И какой из них может быть наиболее подходящим для того, что ищет пользователь. И затем я рассчитаю расстояние между аэропортом и этим отелем по сравнению с тем отелем. И я напишу код для этого. Так что это фактически полностью автономно с этой точки зрения. Хорошо. Итак, да, запомните эти ключевые слова: память, подсказки, инструменты и т. д. Теперь я представил API полетов, но это не обязательно должен быть API. Вы, вероятно, слышали термин MCP или протокол контекста модели, который был введен Anthropic. Я вставил основополагающую статью по MCP внизу этого слайда. Но позвольте мне объяснить в двух словах, почему эти вещи будут отличаться. В случае API, вы фактически научите свой LLM обращаться к API. Итак, вы скажете: «Вот как обращаться к этому API, и вот какие данные он вам отправит обратно», и вам придется делать это разово. Итак, вам придется создать или, так сказать, предоставить документацию API вашего API полетов, вашего API бронирования отелей, вашего API аренды автомобилей, а затем вы предоставите инструменты для вашей модели для связи с этими API. Это не очень хорошо масштабируется, вы знаете, по сравнению с MCP. MCP, на самом деле, заключается в том, чтобы поместить систему посередине, так сказать, которая упростит вашему LLM взаимодействие с этим конечным узлом. Например, вы можете, вы знаете, иметь сервер MCP и клиент MCP, когда вы пытаетесь взаимодействовать с этой базой данных путешествий или API полетов или MCP, и ваш агент фактически может просто взаимодействовать с ним и сказать: «Эй, что вам нужно, чтобы предоставить мне больше информации о рейсах?» и этот агент ответит: «Мне нужно, чтобы вы сказали мне, откуда вылет, куда прибытие, и что вы ищете на высоком уровне. Это мои требования». Хорошо, я вернусь к вам с моими требованиями. О, вы забыли сообщить мне свой бюджет, что угодно. О, позвольте мне дать вам свой бюджет и так далее. Мм, и это, это общение между агентами, которое обеспечивает большую масштабируемость. Вам не нужно жестко кодировать все. Компании выложили свои MCP, и ваш агент может взаимодействовать с ними и выяснять, как получить нужные данные. Это имеет смысл? >> Да. >> О, извините. Например, переписывание чего-либо, например, это страдание только из-за изменений в API, а не в агенте, вы можете переписать это. >> Да, разве это не просто смена? >> Мм, я думаю, в конечном итоге это вопрос, разве это не проблема смены, потому что в любом случае, если API должен быть обновлен, MCP также должен быть обновлен, так что вы скажете, верно? Да, это правильно, но, по крайней мере, это позволяет агенту как бы вернуться, усилить и выяснить, каковы требования. Но в конечном итоге, в идеале, если вы стартап, у вас есть некоторая документация, и автоматически у вас есть агент или рабочий процесс LLM, который читает эту документацию и соответствующим образом обновляет код, вы знаете, но я согласен, это не то, что полностью автономно. Да. Да. >> Почему это? >> Какая безопасность, в частности? >> Да. Так есть ли проблемы с безопасностью у MCP? Подумайте об этом так. MCP, в зависимости от данных, к которым вы получаете доступ, могут иметь разные требования, низкие или высокие ставки. Я не эксперт по всему спектру. Но меня не удивит, что, вы знаете, когда вы, когда вы, когда вы предоставляете MCP, я думаю, вы, многие MCP имеют аутентификацию. Итак, вы, возможно, действительно нуждаетесь в коде, чтобы фактически обращаться к нему, как и к API или ключу. Мм, да, но это хороший вопрос. Я, вы знаете, я не эксперт по безопасности этих систем, но, вы знаете, мы можем изучить это. Есть ли другие вопросы о том, что мы видели с агентными рабочими процессами, API, инструментами, MCP, памятью? Все это находится в стадии разработки. Так что даже память — это далеко не решенная проблема. Это довольно сложно на самом деле получить. Да, >> вам не нужно подтверждать доступ к API, но технически вы можете добиться чего-то от API, вы можете сделать то же самое. >> Точно. Точно. Да. Является ли MCP об эффективности или доступе к большему количеству данных? Это об эффективности. Это как, вы знаете, скажем, у вас есть агент кодирования, и вы знаете, у него есть клиент MCP, и есть несколько серверов MCP, которые выставлены там. Этот агент может очень эффективно взаимодействовать с ними и находить то, что ему нужно. Мм, и это более эффективный процесс, чем фактически отображать API и API на той стороне и как к ним обращаться и каков протокол, вы знаете, но вы знаете, это не о данных, которые раскрываются, потому что в конечном итоге вы контролируете данные, которые раскрываются, вы, вероятно, вы знаете, в зависимости от того, как построен MCP, я полагаю, вы, вероятно, подвергаете себя другим рискам, потому что ваш сервер MCP может видеть любой ввод практически от другого LLM, и поэтому он должен быть надежным. Но да, отлично. Итак, давайте посмотрим на пример пошагового рабочего процесса для агента путешествий. Итак, скажем, пользователь говорит: «Я хочу спланировать поездку в Париж с 15 по 20 декабря с перелетами, отелями рядом с Эйфелевой башней, а затем маршрутом обязательных для посещения мест». Это задача для агента путешествий. Шаг второй: агент планирует шаги. Итак, он говорит: «Я найду рейсы». Используйте API поиска рейсов, чтобы получить варианты на 15 декабря. Поиск отелей, генерация рекомендаций по местам для посещения, проверка предпочтений, бюджета и т. д. Бронирование поездки с помощью API обработки платежей. Шаг третий: это просто планирование, между прочим. Шаг третий: выполнение плана. Используйте свои инструменты, объедините результаты, а затем проактивное взаимодействие с пользователем и бронирование. Он может сделать первое предложение пользователю и попросить пользователя подтвердить или отклонить, а затем может повторить этот процесс планирования и выполнения. И, наконец, он может фактически обновить память. Он может сказать: «О, я только что узнал из этого взаимодействия, что пользователю нравятся только прямые рейсы. В следующий раз я буду предлагать только прямые рейсы». Или я заметил, что пользователи в порядке с трехзвездочными или четырехзвездочными отелями, и на самом деле они не хотят превышать бюджет или что-то в этом роде. Итак, надеюсь, теперь вам понятно, как вы можете это сделать. Мой вопрос к вам: как вы узнаете, работает ли это, и если бы у вас была такая система в эксплуатации, как бы вы [очищает горло] ее улучшили? Да, >> это пример. Итак, пусть пользователи оценивают свой опыт в конце. Это был бы сквозной тест, верно? Вы смотрите на пользовательский опыт на этапах и говорите, насколько он был хорош от одного до пяти, скажем так. Да, это хороший способ. А затем, если вы узнаете, что пользователь ставит один, как вы улучшаете рабочий процесс? >> Хорошо, вы спуститесь по дереву и скажете: «Хорошо, вы поставили один, какая у вас была проблема?» И тогда пользователь говорит: «Цены были слишком высокими», скажем так, и тогда вы вернетесь и исправите этот конкретный, мм, инструмент или подсказку или Да. Хорошо. Есть ли другие идеи? Да, хорошо. Так что это хорошее понимание. Отделите то, что связано с LLM, от того, что не связано с LLM. Детерминированные вещи. Детерминированные вещи вы, возможно, сможете исправить, более объективно, по сути. Да, там было что-то еще? Итак, приведите мне пример объективной проблемы, которую вы можете заметить, и как вы бы ее исправили, в отличие от субъективной проблемы. >> Да. Рейс, который дешевле, прямой. >> Хорошо, давайте скажем, вы говорите, что есть тот же рейс, но один дешевле другого, скажем так, он объективно хуже, и вы можете это почти автоматически зафиксировать. >> Так что вы могли бы фактически создать оценки, которые являются объективными, которые отслеживаются у ваших пользователей, и вы могли бы фактически провести анализ после и увидеть, что для объективных вещей мы заметили, что наш агентский ИИ-рабочий процесс LLM плох в ценообразовании. Он просто не так хорошо читает цены, потому что он всегда предлагает более дорогой вариант. Да, вы совершенно правы. А как насчет субъективных вещей? >> Да. >> Например, вы выбираете прямой или непрямой рейс, если непрямой немного дешевле? >> Да, хорошая мысль. Вы выбираете прямой или непрямой рейс, если непрямой дешевле, но прямой удобнее? Мм, да, это действительно хорошая мысль. Мм, как бы вы это зафиксировали? Скажем, этим пользуются тысячи пользователей. >> Мм, можно ли что-нибудь ввести о нас? >> Мм, можно ли что-нибудь ввести? Да, я имею в виду, вы могли бы, вы могли бы ввести что-нибудь о предпочтениях пользователя? Ну, вы могли бы построить набор данных, который содержит некоторую информацию. Итак, вы создаете 10 подсказок, где пользователь специально просит прямые рейсы, говорит, что я предпочитаю прямые рейсы, потому что я забочусь о своем времени, скажем так. А затем вы смотрите на вывод, и вы фактически даете хороший пример хорошего вывода, и вы, вероятно, сможете зафиксировать производительность вашего агентного рабочего процесса на этом конкретном тесте, понимает ли он приоритеты, учитывает ли он цены, учитывает ли он комфорт. Что насчет тона? Скажем, скажем, LLM сейчас не очень дружелюбен. Как бы вы это заметили и как бы вы это исправили? >> Да. >> Тестировать пользователя и запускать подсказки и смотреть, есть ли что-то не так. >> Хорошо, пусть тестовый пользователь запустит подсказку и посмотрит, есть ли что-то не так. Скажите мне о последнем шаге. Как бы вы заметили, что что-то не так? Итак, пусть несколько оценщиков ответят и посмотрят, удовлетворен ли он. >> Да, я согласен с вашим подходом. Пусть судьи LLM оценивают ответ по определенной рубрике того, как выглядит вежливость. Итак, в данном случае вы могли бы начать с анализа ошибок. Итак, вы начинаете, у вас есть тысяча пользователей, и вы знаете, вы можете просмотреть 20 взаимодействий пользователей и прочитать их, и вы можете заметить на первый взгляд, что LLM кажется очень грубым. Вы знаете, он просто очень, очень краток в своих ответах и не очень полезен. Вы замечаете это при анализе ошибок вручную. Затем вы переходите к следующему этапу. Вы фактически помещаете оценку за ним, вы говорите: «Я собираюсь создать набор судей LLM, которые будут смотреть на взаимодействие пользователя и оценивать, насколько оно вежливо, и я дам ему рубрику». Затем я сделаю следующее: я переключу свой LLM. Вместо использования GPT4 я буду использовать Grok. И вместо использования Gro, я буду использовать Lama. А затем я запущу эти три LLM бок о бок, передам их нашим судьям LLM, а затем получу свой субъективный балл в конце, чтобы сказать: «О, модель X была более вежливой в среднем». Да, совершенно верно. Это пример оценки, которая очень специфична и позволяет вам выбирать между LLM. Вы могли бы фактически провести ту же оценку между LLM, но исправить LLM, изменить подсказку. Вы фактически вместо того, чтобы говорить: «Действуй как агент путешествий», вы говорите: «Действуй как полезный агент путешествий», а затем вы видите влияние этого слова на вашу оценку с LLM в качестве судей. Это имеет смысл? Хорошо. Мм, отлично. Итак, давайте перейдем к следующему и проведем тематическое исследование с оценкой, и тогда мы почти закончим на сегодня. Скажем, ваш менеджер по продуктам просит вас создать агент ИИ для поддержки клиентов. Хорошо, с чего вы начнете? И вот пример пользовательской подсказки: «Мне нужно изменить адрес доставки для заказа бла-бла-бла. Я переезжаю по новому адресу». Итак, с чего вы начнете, если я дам вам этот проект? Вы знаете. >> Да. >> Итак, проведите исследование, посмотрите на бенчмарки и то, как разные модели работают в службе поддержки клиентов, а затем выберите модель. Это вы имеете в виду. Да. Это правда. Вы могли бы сделать это. Что еще вы могли бы сделать? Да. >> Хорошо. Да, мне нравится. Попробуйте разложить различные задачи, которые ему понадобятся, и попробуйте угадать, какие из них будут более сложными, какие должны быть нечеткими, какие должны быть детерминированными. Да, вы правы. Посидеть день-два с клиентом и посмотреть, как задача, вероятно, задача. >> Да, похоже на то, что вы сказали. Это то, что я бы рекомендовал. Вы говорите, что я бы посидел с агентом службы поддержки клиентов день или два, и я бы разложил задачу, которую они выполняют. Я бы спросил их, где они испытывают трудности, сколько времени это занимает. Да, обычно именно с этого вы начинаете с декомпозиции задач. Итак, скажем, мы проделали эту работу, и у нас есть этот список, я упрощаю, но агент службы поддержки клиентов обычно извлекает информацию, затем ищет в базе данных, чтобы получить запись клиента, затем проверяет политику, вы знаете, разрешено ли нам обновлять адрес или это фиксированная точка данных, затем составляет черновик ответного письма и отправляет письмо. Хорошо, мы разложили эту задачу. После того, как вы разложили эту задачу, спросите, как вы проектируете свой агентный рабочий процесс? >> Да. Каждый шаг, какой из них, какой метод мы будем использовать или что-то еще в каждой задаче, что вы собираетесь использовать для ресурсов? >> Именно. Итак, чтобы повторить, вы посмотрите на декомпозицию задач, получите инстинкт того, что является нечетким, что детерминированным, а затем определите, какая строка будет одноразовой LLM, какая потребует, возможно, RAG, какая потребует инструмент, какая потребует память, какая. Итак, вы начнете полностью проектировать эту карту, верно? Это также то, что я бы рекомендовал вам. Вы можете фактически составить черновик и сказать: «Хорошо, я беру пользовательскую подсказку, и первый шаг моей декомпозиции задач — извлечь информацию». Это кажется обычным LLM. Вы, вы, вы можете предположить, что обычный LLM, вероятно, будет достаточно хорош в извлечении того, что пользователь хочет изменить адрес, и это номер заказа, и это новый адрес. Вам, вероятно, не понадобится слишком много технологий, кроме LLM. Следующий шаг кажется, что вам нужен инструмент, потому что вам на самом деле придется искать в базе данных, а также обновлять адрес. Так что это может быть инструмент, и вам, возможно, придется создать пользовательский инструмент для LLM, чтобы сказать: «Позвольте мне подключить вас к этой базе данных» или «Позвольте мне дать вам доступ к этому ресурсу с помощью MCP». Да. После этого вам, вероятно, снова понадобится LLM, чтобы составить электронное письмо, но вы, вероятно, вставите подтверждение. Вы вставляете подтверждение того, что ваш адрес был изменен с X на Y. И тогда LLM составит ответ. И, конечно, чтобы не забыть, вам может понадобиться инструмент для отправки электронного письма. Вы знаете, вам, возможно, придется, вы знаете, отправить что-то, чтобы электронное письмо ушло, а затем вы получите вывод. Это имеет смысл? Итак, именно то, что вы описали. [вздыхает] Хорошо, переходя к следующему шагу. После того, как мы разложили наши задачи, затем мы спроектировали вокруг них агентный рабочий процесс. Это заняло у нас пять минут. На практике это займет у вас больше времени, если вы строите свой стартап на этом. Вы хотите убедиться, что ваша декомпозиция задач точна, ваша вещь здесь точна. И тогда вы можете проделать много работы над каждым инструментом и оптимизировать его, а также задержку и стоимость. Но давайте скажем, и теперь мы хотим знать, как, мм, если это работает, вы знаете, и я предполагаю, что у вас есть трассировки LLM. Трассировки LLM очень важны. На самом деле, если вы проходите собеседование в стартапе ИИ, я бы рекомендовал вам в процессе собеседования спросить их: «Есть ли у вас трассировки LLM?» потому что, если у них нет трассировок LLM, очень трудно отлаживать систему LLM, вы знаете, потому что у вас нет видимости цепочки сложных подсказок, которые были вызваны, и где ошибка, и вы знаете, так что это базовый, так сказать, часть стека стартапа ИИ — иметь трассировки LLM. [смех] Итак, давайте предположим, что у вас есть трассировки. Как вы узнаете, что ваша система работает? Вы знаете, мы, я, вы знаете, я обобщу некоторые вещи, которые я слышал ранее. Вы дали нам пример сквозной метрики. Вы смотрите на удовлетворенность пользователей в конце. Вы также можете использовать компонентный подход, где вы фактически смотрите на инструмент, обновления базы данных и вы вручную проводите анализ ошибок и смотрите: «О, инструмент на самом деле всегда забывает обновлять электронную почту». Он просто терпит неудачу при написании, вы знаете, и я это исправлю. Это, по сути, детерминировано. Или, вы знаете, когда он пытается отправить электронное письмо и обратиться к системе, которая должна отправить электронное письмо, он не отправляет его в правильном формате, и поэтому он терпит неудачу в этот момент. Опять же, вы могли бы это исправить. Черновик электронного письма, LLM не справляется отлично. Он не очень вежлив при составлении электронного письма, вы знаете. Итак, вы можете смотреть компонент за компонентом, и на самом деле легче отлаживать, чем смотреть на это сквозным образом. Вы, вероятно, будете использовать смесь обоих. Другой способ посмотреть на это — это что объективно, а что субъективно. Например, объективный пример — LLM извлек неправильный идентификатор заказа. Вы знаете, пользователь сказал: «Мой идентификатор заказа X», а LLM, когда он фактически вставил, искал в базе данных, использовал неправильный идентификатор заказа. Это объективно неправильно. Вы можете фактически написать код Python, который проверяет, проверяет просто соответствие между тем, что упомянул пользователь, и тем, что фактически было вставлено в базу данных или для поиска. У вас также есть субъективные вещи, о которых мы говорили, где вы, вероятно, захотите использовать либо человеческое рейтингование, либо LLM в качестве судей. Это очень актуально для субъективных оценок. [фыркает] И, наконец, вы обнаружите, что у вас есть количественные оценки и более качественные оценки. Итак, количественные — это процент успешных обновлений адреса. Задержка, вы можете фактически отслеживать компонентную задержку и видеть, какой из них самый медленный. Скажем, отправка электронного письма занимает 5 секунд, вы знаете, это слишком долго, скажем так, вы заметите компонентную или полную рабочую нагрузку. И тогда вы решите, где я оптимизирую свою задержку и как я это сделаю. И затем, наконец, качественные, вы можете фактически провести анализ ошибок и посмотреть, вы знаете, где галлюцинации, где несоответствия тона, вы знаете, сбиты ли пользователи с толку и чем они сбиты с толку, вы знаете, это было бы более качественно, и обычно это потребовало бы больше, вы знаете, подходов «белые перчатки» для этого. Хорошо, вот как это могло бы выглядеть. Я дал вам несколько примеров, но вы бы создали оценки, чтобы объективно, субъективно, компонентно, сквозным образом, а затем количественно и качественно определить, где ваш LLM терпит неудачу, а где он работает хорошо. Это дает вам представление о типах вещей, которые вы могли бы сделать, чтобы исправить и улучшить этот агентный рабочий процесс? Отлично. Ну, это было наше тематическое исследование по оценкам. Мы не будем углубляться в него, но, надеюсь, оно дало вам представление о типах вещей, которые вы можете делать с судьями LLM, с, вы знаете, объективными, субъективными, компонентными, сквозными и так далее. Мм, последний раздел о многоагентных рабочих процессах. Итак, вы можете спросить: «Эй, зачем нам нужен многоагентный рабочий процесс, когда рабочий процесс уже имеет несколько шагов, уже вызывает LLM несколько раз, уже дает им инструменты, зачем нам нужны несколько агентов?» И так много людей говорят о многоагентных системах онлайн, это даже не новая вещь, честно говоря. Я имею в виду, многоагентные системы существуют уже давно. Основное преимущество многоагентной системы будет параллелизм. Это как, есть ли что-то, что я хотел бы запустить параллельно, так сказать, независимо, но, возможно, есть некоторые синхронизации посередине, но именно там вы хотите поместить многоагентную систему. Это когда она параллельна. Другое преимущество, которое есть у некоторых компаний с многоагентными системами, заключается в том, что агент может быть повторно использован. Итак, скажем, в компании у вас есть агент, созданный для дизайна. Этот агент может использоваться в маркетинговой команде, и он может использоваться в команде продукта, вы знаете, и теперь вы оптимизируете агента, который имеет несколько заинтересованных сторон, которые могут с ним общаться и получать выгоду от его производительности. Мм, на самом деле я задам вам вопрос и дам вам минуту подумать. Скажем, вы создавали автоматизацию умного дома для своей квартиры или дома. Каких агентов вы бы хотели создать? Да, запишите это, а затем я попрошу вас через минуту поделиться некоторыми агентами, которых вы бы создали. Также подумайте, как бы вы установили иерархию между этими агентами или как бы вы их организовали, или кто с кем должен общаться. Хорошо. Хорошо. Уделите минуту этому. Будьте креативны, потому что я попрошу всех ваших агентов, и, возможно, у вас есть агент, о котором никто не думал. Хорошо, давайте начнем. Кто хочет дать мне набор агентов, которых вы бы хотели для своего умного дома? Да. Итак, первый — это набор агентов, которые отслеживают мои движения по дому и записывают информацию о моем доме. Другой агент получает эту информацию и регулирует температуру в комнате, а другой использует >> Хорошо, позвольте мне повторить. У вас есть четыре агента, я думаю, примерно. Один, который отслеживает биометрические данные, например, где вы находитесь в доме, как вы двигаетесь, такие вещи. Тот, который знает ваше местоположение. Второй определяет температуру в комнатах и имеет возможность ее изменять. Третий отслеживает энергоэффективность и может давать обратную связь по энергии и энергопотреблению, и, возможно, я не знаю, возможно, он также контролирует температуру, я не знаю, на самом деле, или газ или воду, возможно, он отключит вашу воду в какой-то момент, и затем у вас есть агент-оркестратор. Что именно делает оркестратор? >> Инструкции. >> Хорошо. Передает инструкции. Так это агент, который в основном общается с пользователем? >> Да. >> Хорошо. Так что, если я возвращаюсь домой и говорю: «Я хочу, чтобы духовка была предварительно разогрета», я общаюсь с оркестратором, а затем он передает это другому агенту. Хорошо, звучит хорошо. Да, это пример, я хочу сказать, иерархической, мм, многоагентной системы. Мм, что еще? Есть ли другие идеи? Что бы вы добавили к этому? Да. >> Минимальное действие, которое вы можете сделать. Представьте, что вы входите в комнату или просто входите в компьютер или просто открываете минимальное действие. У вас есть много агентов на [очищает горло], и затем в зависимости от того, кто это, и всего контекста, который у вас есть >> О, мне это нравится, это действительно хорошая мысль. Итак, позвольте мне обобщить: у вас есть агент безопасности, который определяет, можете ли вы войти или нет, и когда вы входите, он понимает, кто вы, а затем предоставляет вам определенные разрешения, которые могут отличаться в зависимости от того, являетесь ли вы родителем или, вы знаете, у вас может быть доступ к определенным автомобилям, а к другим нет, или ребенок не может открыть холодильник, или я не знаю, что-то вроде этого. Да. Или хорошо. Мне это нравится. Это хорошая мысль. Да. И это кажется достаточно сложным рабочим процессом, где вам нужен конкретный рабочий процесс, связанный с этим. Я согласен. [фыркает] >> Что еще? >> Да. Продолжая тему окружающей среды, вы можете усложнить. Итак, экономия энергии с помощью открытых дверей также из продуктового магазина, чтобы понять, что у вас в холодильнике или нет. Кто вышел. >> Ну, это действительно хорошо. Итак, вы упомянули два из них. Одно — это, возможно, агент, который имеет доступ к внешним API, которые могут понимать погоду снаружи, ветер, солнце, а затем контролирует определенные устройства дома, температуру, жалюзи и тому подобное, а также понимает ваши предпочтения для этого. Это действительно кажется хорошим вариантом использования, потому что вы могли бы передать это оркестратору, но он мог бы потеряться, потому что он делает слишком много. Так что, вероятно, и эти проблемы связаны друг с другом, такие как температура снаружи с API погоды может влиять на температуру внутри, как вы хотите, и так далее. А затем второе, которое мне также нравится, это то, что у вас может быть агент, который смотрит на ваш холодильник и на то, что внутри, и он может фактически иметь доступ к камере в холодильнике, например. И знать ваши предпочтения, а также иметь доступ к API электронной коммерции, чтобы заранее заказывать продукты на Amazon. Мм, я согласен, и, возможно, оркестратор будет линией связи с пользователем, но он может общаться с этим агентом, чтобы добиться этого. Да, мне это нравится. Итак, это все, мм.

Действительно хорошие примеры здесь. Вот список, который у меня был, э-э, там. Итак, климат-контроль, освещение, безопасность, управление энергией, развлечения, агент уведомлений, оповещения об обновлениях системы, энергосбережение и оркестратор. Так что все, что вы упомянули, на самом деле. Э-э, и тогда мы не говорили о различных моделях взаимодействия, но у вас есть разные способы организации многоагентной системы. Плоская, иерархическая. Похоже, это будет иерархическая. Я согласен. И причина в UIUX: я бы предпочел говорить только с оркестратором, а не обращаться к специализированному приложению, чтобы сделать что-то вроде этого, мне кажется, оркестратор мог бы за это отвечать. И поэтому я согласен, я, вероятно, выбрал бы иерархическую настройку здесь. Но, возможно, вы также добавите некоторые связи между другими агентами, как в плоской системе, где все со всем, например, э-э, с климат-контролем и энергией, если вы хотите связать эти два. Вы можете фактически позволить им общаться друг с другом. Когда вы позволяете агентам общаться друг с другом, это, кстати, по сути протокол MCB. Так что вы относитесь к агенту как к инструменту, точно так же, как к инструменту. Вот как вы взаимодействуете с этим агентом. Вот что он может вам сказать. Вот что ему нужно от вас, по сути. Хорошо, отлично. И тогда, не вдаваясь в подробности, существуют преимущества многоагентных рабочих процессов по сравнению, знаете ли, с одиночными агентами, такими как отладка. Легче отлаживать специализированного агента и отлаживать всю систему. Параллелизация тоже. Легче запускать вещи параллельно. Э-э, и вы можете сэкономить время. Э-э, знаете, есть некоторые преимущества в этом. И я оставляю вам этот слайд, если вы хотите углубиться. Отлично. Итак, мы узнали так много методов оптимизации LLM: от промптов до цепочек, до тонкой настройки, поиска, э-э, и до многоагентных систем. И тогда, чтобы закончить на э-э паре тенденций, за которыми я хочу, чтобы вы следили. Э-э, я думаю, на следующей неделе День благодарения. Это так? Это перерыв на День благодарения? Нет, через неделю. Хорошо. Ну, до перерыва на День благодарения. Так что, если вы путешествуете, вы можете подумать об этих вещах. Э-э, что дальше в области ИИ, я хотел бы выделить пару тенденций. Э-э, так что Элас Дискавер, один из OG э-э, знаете, LLM, э-э, и, знаете, соучредитель OpenAI, э-э, поднял вопрос о том, не достигаем ли мы плато или нет? Вы знаете, вопрос о том, увидим ли мы в ближайшие годы, что LLM не будут улучшаться так быстро, как мы видели в прошлом. Вероятно, в сообществе сложилось такое мнение, что, знаете ли, последняя версия GPT э-э не принесла того уровня производительности, которого ожидали люди, хотя она сделала ее намного проще в использовании для потребителей, потому что вам не нужно взаимодействовать с разными моделями, все под одной крышей, так что кажется, что прогресс есть, э-э, но плато неясно. Э-э, то, как я бы об этом думал, э-э, законы масштабирования LLM говорят нам, что если мы продолжим улучшать вычисления и энергию, то LLM должны продолжать улучшаться, но в какой-то момент они достигнут плато. Так что же выведет нас на следующий этап? И это, вероятно, поиск архитектуры. Все еще много LLM, даже если мы не понимаем, что под капотом, вероятно, основаны на трансформерах сегодня, но мы знаем, что человеческий мозг работает не так. Есть просто определенные вещи, которые мы делаем, которые намного эффективнее, намного быстрее, нам не нужно столько данных. Так что теоретически нам есть чему поучиться в плане поиска архитектуры, чего мы еще не выяснили. Неудивительно, что вы видите, как эти лаборатории нанимают так много инженеров, потому что вполне возможно, что в ближайшие несколько лет тысячи инженеров будут пытаться выяснить различные инженерные хитрости и тактики, а также поиск архитектур, которые приведут к лучшим моделям, и один из них внезапно найдет следующий трансформер, и это сократит в 10 раз потребность в вычислениях и потребность в энергии. Э-э, знаете, это как если бы вы читали серию книг Айзека Азимова "Основание", э-э, отдельные люди могут оказать огромное влияние на будущее благодаря своим решениям. Вы знаете, кто бы ни открыл трансформеры, оказал огромное влияние на направление развития ИИ. Я думаю, мы увидим больше этого в ближайшие годы, когда какая-то группа исследователей, которая быстро итерирует, может открыть определенные вещи, которые внезапно преодолеют это плато и выведут нас на следующий этап, и это будет продолжать улучшаться таким образом. И поэтому меня не удивляет, что так много компаний нанимают инженеров прямо сейчас, чтобы выяснить эти хитрости и эти, эти методы. Э-э, другой набор достижений, которые мы можем увидеть, — это мультимодальность. Так что, чтобы понять это, мы, мы, мы имели LLM, сначала текстовые, а затем мы добавили изображения, и сегодня, знаете ли, модели очень хороши в изображениях. Они очень хороши в тексте. Оказывается, что быть хорошим в изображениях и быть хорошим в тексте делает всю модель лучше. Так что тот факт, что вы хорошо понимаете изображение кошки, делает вас лучше и в тексте о кошке. Теперь добавьте еще одну модальность, такую как аудио или видео, вся система становится лучше. Так что вы лучше пишете о кошке, если знаете, как звучит кошка, если вы можете посмотреть на кошку на изображении. Это имеет смысл? Так что мы видим достижения, которые переводятся из одной модальности в другую. И это может привести к вершине робототехники, где все эти модальности объединяются, и внезапно робот лучше убегает от кошки, потому что он понимает, что такое кошка, как она звучит, как она выглядит и так далее. Это имеет смысл? Э-э, другое — это гармоничная работа нескольких методов. На лекциях во вторник мы видели обучение с учителем, обучение без учителя, самообучение, обучение с подкреплением, контроль качества, RAG и так далее. Если вы посмотрите на э-э, как учатся младенцы, э-э, это, вероятно, смесь этих различных подходов, как младенец э-э может иметь некоторое метаобучение, означающее, знаете ли, у него есть некоторый инстинкт выживания, который закодирован в ДНК, скорее всего, э-э, и это как предварительное обучение младенца, если хотите. Наряду с этим э-э мама или папа э-э указывают на вещи и говорят: плохо, хорошо, плохо, хорошо, хорошо, обучение с учителем. Наряду с этим младенец падает на землю и получает травму, и это сигнал вознаграждения для обучения с подкреплением. Наряду с этим младенец наблюдает за другими людьми, делающими что-то, или другими младенцами, знаете ли, делающими что-то, обучение без учителя. Вы понимаете, что я имею в виду? Это, мы, вероятно, смесь всех этих методов, и э-э, и я думаю, что именно туда движется тенденция: где эти методы, которые вы видели в CS230, объединяются, чтобы построить систему ИИ, которая учится быстро, имеет низкую задержку, дешева, энергоэффективна и максимально использует все эти методы. Э-э, наконец, и это особенно верно в Стэнфорде, э-э, вы проводите исследования, которые вы бы назвали человекоцентричными, и некоторые исследования, которые не являются человекоцентричными. Под человекоцентричными я должен сказать, что это подходы, основанные на мозге, и подходы, которые не основаны на людях, потому что оказывается, что человеческое тело очень ограничено. И поэтому, если вы на самом деле проводите исследования только о том, как выглядит человеческий мозг, вы, вероятно, упускаете вычисления, энергию и тому подобное, что вы можете оптимизировать даже за пределами нейронных связей в мозге. Но вы все еще можете многому научиться у человеческого мозга. И именно поэтому есть профессора, которые сейчас руководят лабораториями, которые пытаются понять, как работает обратное распространение для людей. И на самом деле, вероятно, мы не используем обратное распространение. Мы не используем обратное распространение. Мы только делаем прямое распространение, скажем так. Так что этот тип вещей — интересное исследование, которое я бы рекомендовал вам прочитать, если вы интересуетесь направлением развития ИИ. Э-э, и тогда, наконец, э-э, одна вещь, которая будет довольно ясна, я всегда говорю об этом, но это скорость, с которой все движется. Вы замечаете, что часть причины, по которой мы даем вам передышку в CS230, заключается в том, что эти методы так быстро меняются. Так что я не хочу утруждаться, обучая вас 17 методам RAG, которые оптимизируют RAG, потому что через два года вам это не понадобится, знаете ли. Так что я бы предпочел, чтобы вы думали о широте вещей, которые вы хотите понять, и когда вам это нужно, вы спринтуете и изучаете именно то, что вам нужно, быстрее, потому что полураспад знаний так низок, знаете ли, вы хотите выйти из класса с хорошей широтой и затем иметь возможность углубиться, когда вам это нужно после класса, и именно так разработан этот класс. Э-э, да, это все на сегодня. Так что спасибо, э-э, спасибо за участие.