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 в то время, не могли распознать это слово. И поэтому рекомендательная система как бы вышла из-под контроля, потому что внезапно все высмеивали этот твит, используя слово "kof", и LLM была так запутана, что означало это, куда ее следует показывать, кому ее следует показывать, и это пример того, что в наши дни, особенно в социальных сетях, так много новых тенденций, и очень трудно ограничить LLM, чтобы она соответствовала новой тенденции и понимала новые слова. Я имею в виду, вы часто слышите слова поколения Z, такие как "re" или "mid" или что-то еще. Я не знаю всех из них, но, вероятно, вы хотите найти способ, который позволит LLM понимать эти тенденции без переобучения LLM с нуля. Да. Что еще?

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

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

>> Так это делает модель намного тяжелее, намного медленнее.

>> Так, возможно, у нее есть много широких знаний предметной области, которые могут не понадобиться для вашего приложения, и поэтому вы используете массивную тяжелую модель, когда на самом деле используете только 2% возможностей модели. Вы совершенно правы. Вам может не понадобиться все это. Поэтому вы можете найти способы обрезать, квантовать модель, модифицировать ее. Все это хорошие моменты. Я добавлю еще несколько. LLM очень трудно контролировать. Ваш последний пункт на самом деле является примером этого. Вы хотите контролировать LLM, чтобы использовать часть ее знаний, но это не так. На самом деле она запутывается. Мы видели это в истории. В 2016 году Microsoft создала печально известный твиттер-бот, который учился у пользователей, и он быстро стал расистским ублюдком. Microsoft в итоге удалила бота через 16 часов после запуска. Сообщество очень быстро определило, что это расистский бот. И вы можете сочувствовать Microsoft в том смысле, что на самом деле трудно контролировать 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. Знаете, где Cara оценивает навыки, некоторые из вас уже прошли тесты и пытается персонализировать его для пользователя. И на самом деле, если вы прочитаете в HR-системе в корпорации, в HR-системе может быть: "Джейн — менеджер по продукту уровня три, она находится в США, и ее предпочтительный язык — английский", и на самом деле эти метаданные могут быть вставлены в шаблон промпта, который мы персонализируем для Джейн, и аналогично для Джо, чей предпочтительный язык — испанский. Он будет адаптирован для Джо, и это называется шаблон промпта.

>> Да.

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

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

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

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

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

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

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

>> Да.

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

>> Да.

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

>> Мы поговорим об этом. Есть ли какие-либо проблемы с задержкой? Да. В некоторых приложениях вы не хотите использовать цепочку или не хотите использовать длинную цепочку, потому что это добавляет задержку. Мы поговорим об этом позже. Хороший момент. Так что практически так выглядит связывание сложных промптов. У вас есть ваш первый промпт с вашей первой задачей. Он выводит результат, который вставляется во второй промпт с определенной второй задачей. Результат затем вставляется в третий промпт с определенной третьей задачей и так далее. Вот как это выглядит на практике. Отлично. Мы поговорим больше позже о тестировании ваших промптов, но сейчас есть методы для этого, и мы увидим позже на этой лекции с нашим тематическим исследованием, как мы можем тестировать наши промпты. Но вот пример того, как вы можете это сделать. У вас может быть рабочий процесс суммаризации, знаете ли, промпт, который является базовым. Это один промпт. У вас может быть улучшенная суммаризация, которая является модифицированным промптом этого или рабочим процессом с цепочкой, знаете ли. А затем у вас есть тестовый случай, который является входными данными, которые вы хотите суммировать, скажем, а затем у вас есть сгенерированный вывод, и вы можете попросить людей оценить эти выводы. И вы заметите, что базовый вариант лучше или хуже, чем улучшенный промпт. Конечно, этот ручной подход занимает время. Но это хороший способ начать, и обычно совет — это практиковаться в начале, потому что вы быстро заметите некоторые проблемы, и это даст вам лучшее интуитивное понимание того, какие настройки могут привести к лучшей производительности. Однако, если вы хотите масштабировать эту систему для многих продуктов, многих частей вашей кодовой базы, вы, возможно, захотите найти способ сделать это автоматически, не прося людей проверять и оценивать резюме, верно? Один из подходов — использовать, знаете ли, платформы, такие как At Portera, наша команда использует платформу под названием Prompt Fu, которая позволяет вам фактически автоматизировать часть этого тестирования. В двух словах, она позволяет вам запускать один и тот же промпт с пятью различными LLM немедленно, помещать все в таблицу, что очень легко для человека оценить, скажем. Или, альтернативно, она может позволить вам определить LLM-судей. LLM-судьи могут быть разных типов. Например, у меня может быть LLM-судья, который делает парное сравнение. Итак, LLM просят: "Вот два резюме. Просто скажите мне, какое из них лучше другого". Вот что делает LLM. И это может быть использовано как прокси для того, насколько хорош базовый вариант суммаризации по сравнению с улучшенным. Другой способ использовать LLM-судью — это если вы делаете это для оценки одного ответа. Итак, вот резюме, оцените его от одного до пяти, знаете ли, а затем вы можете углубиться и сделать парное сравнение с учетом эталона или добавить также рубрику. Вы говорите, что пять — это когда резюме ниже 100 символов. Я просто выдумываю, ниже 100 символов, упоминает по крайней мере три ключевых момента, которые отличаются, и начинается с первого предложения, которое отображает обзор, а затем переходит к деталям. Это отличное резюме, пять из пяти. Ноль — это когда LLM не смогла суммировать и на самом деле была очень многословной, скажем так, и поэтому вы ставите за ней рубрику, и у вас есть LLM, просто находящая рубрику. Конечно, вы можете теперь сочетать различные методы. Вы можете использовать few-shot для рубрики. Вы можете фактически дать примеры пяти из пяти, четырех из четырех, трех из трех, потому что теперь вы знаете несколько методов. Хорошо, [кашляет] это имеет смысл? Да. Хорошо. Итак, это был второй раздел по инженерии промптов или первой линии оптимизации. Теперь, скажем, вы исчерпали все свои возможности для инженерии промптов и думаете о том, чтобы фактически прикоснуться к модели, модифицировать ее веса или донастроить ее. Другими словами, я говорил вам, что я не поклонник донастройки. Есть несколько причин, почему. Во-первых, для донастройки обычно требуются существенные размеченные данные, хотя сейчас есть подходы, которые становятся лучше в донастройке, которые больше похожи на few-shot промптинг, чем на донастройку. Это как бы сливается, хотя один модифицирует веса, другой не модифицирует веса. Донастроенные модели также могут переобучиться на конкретных данных. Мы увидим забавный пример на самом деле. Потеря общего назначения. Так что вы можете донастроить модель, и на самом деле, когда кто-то задает довольно общий вопрос, она работает не очень хорошо. Знаете, она может хорошо работать на вашей задаче. Так что это может быть актуально или нет. А затем это затратно по времени и деньгам. Это моя главная проблема. И знаете, в worker мы стараемся избегать донастройки как можно больше. Потому что к тому времени, когда вы закончите донастройку своей модели, выйдет следующая модель, и она фактически превзойдет вашу донастроенную версию предыдущей модели. Поэтому я бы избегал донастройки как можно больше. Преимущество методов инженерии промптов, которые мы видели, заключается в том, что вы можете напрямую вставить следующую лучшую предварительно обученную модель в свой код. Она немедленно обновит все. Донастройка так не работает. [смех] Хотя есть и преимущества, когда это все еще имеет смысл. Если задача требует повторяющегося высокоточного вывода, такого как юридическое научное объяснение, и если общая LLM испытывает трудности с предметно-специфическим языком. Итак, давайте вместе посмотрим на быстрый пример, который является примером от Росса Лазеровица, я думаю, это было пару лет назад, 23 сентября, когда Росс пытался сделать донастройку Slack. Итак, он посмотрел на множество сообщений Slack в своей компании и сказал: "Я собираюсь донастроить модель, которая говорит как мы или работает как мы, потому что именно так мы работаем, верно? Это данные, которые представляют, как люди работают в компании". И поэтому он фактически приступил к донастройке модели. Дал ей промпт вроде "Привет, напиши, знаете ли, он делегировал модели: "Напиши пост в блоге на 500 слов о инженерии промптов", и модель ответила: "Я займусь этим утром". А затем он попытался надавить на модель дальше и сказал: "Сейчас утро". И модель сказала: "Я пишу прямо сейчас. Здесь 6:30 утра. Напиши это сейчас. Хорошо, пожалуйста. [смех] Хорошо, я напишу это сейчас. На самом деле я не знаю, что вы хотите, чтобы я сказал о инженерии промптов. Я могу только описать процесс. Единственное, что приходит на ум для заголовка, это "Как мы строим промпт?". Это своего рода забавный пример донастройки, потому что это правда, что это пошло не так, как он хотел. Он хотел, чтобы модель говорила как мы на работе, а в итоге она вела себя как люди и на самом деле не следовала инструкциям. Так что это один из примеров, почему я бы избегал донастройки. Отлично, давайте поговорим о RAG. RAG важен. Важно знать о нем и хотя бы иметь основы. Это очень распространенный вопрос на собеседовании, кстати. Если вы пойдете на собеседование, вас могут попросить объяснить в двух словах пятилетнему ребенку, что такое RAG, и, надеюсь, после этого вы сможете это сделать. Итак, мы видели некоторые проблемы с автономными LLM. Эти проблемы включают в себя маленькое контекстное окно, тот факт, что трудно запоминать детали в большом контекстном окне, пробелы в знаниях, знаете ли, даты окончания, вы упоминали ранее. Модель может быть обучена до определенной даты, а затем она не может следовать тенденциям или быть в курсе. Галлюцинации, есть некоторые области, подумайте о медицинской диагностике, где галлюцинации очень дорогостоящи. Вы не можете позволить себе галлюцинацию. Знаете, даже в образовании представьте себе развертывание модели для образования молодежи США, и она галлюцинирует и учит миллионы людей чему-то совершенно неправильному. Это проблема. А затем отсутствие источников. Многим областям нравятся источники. Научные области любят источники. Образование любит источники. Юриспруденция тоже любит источники. И поэтому предварительно обученная LLM не очень хорошо справляется с указанием источников. И на самом деле, если вы пытались найти источники в обычной LLM, она на самом деле много галлюцинирует. Она выдумывает исследовательские работы. Она просто перечисляет совершенно фальшивые вещи. Итак, как мы это решаем? С помощью RAG. RAG интегрируется с внешними источниками знаний, базами данных, документами, API. Он гарантирует, что ответы более точны, актуальны и обоснованы, потому что вы можете фактически обновлять свой документ. Ваш диск всегда обновлен. Я имею в виду, в идеале вы всегда загружаете в него новые документы. И когда вы спрашиваете "Каковы наши результаты продаж в четвертом квартале?", надеюсь, на диске есть последняя презентация для совета директоров, и она может прочитать последнюю презентацию для совета директоров. Да. [фыркает] И больше контроля для разработчиков. Мы увидим, почему RAG позволяет осуществлять целенаправленную настройку без необходимости переобучения модели. На самом деле, вы не трогаете модель с RAG. Это действительно техника, которая накладывается на модель. Итак, чтобы увидеть пример RAG, это приложение для ответов на вопросы, где мы находимся в медицинской области, и пользователь задает запрос. "Каковы побочные эффекты препарата X?". Это важный вопрос. Вы не можете галлюцинировать. Вам нужны источники. Вам нужно быть в курсе. Возможно, есть новое обновление для этого препарата, которое теперь есть в базе данных, и вам нужно его прочитать. Так что вам нужно, RAG — отличный пример того, что вы хотели бы использовать здесь. Работает это так: у вас есть база знаний из множества документов. Что вы делаете, это используете встраивание для встраивания этих документов в низкоразмерные представления. Например, если документ — это PDF, длинный PDF, вы можете, знаете ли, прочитать PDF, понять его, а затем встроить его. Мы видели много подходов к встраиванию вместе. Triplet loss и т. д., вы помните. Так что представьте, что один из них здесь для 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 рабочих дней. Это гораздо более продуманно, чем первая версия, которая является своего рода обычной, верно? Так что именно об этом мы будем говорить на следующих нескольких слайдах: как перейти от первого ко второму. В Интернете есть множество специализированных агентских рабочих процессов. Вы слышали, и если вы проводите время в Сан-Франциско, вы, вероятно, видите множество рекламных щитов: «AI Software Engineer», «AI Skills Mentor», вы взаимодействовали в классе с «AI to worker», «AISDR», «AI Lawyers», «AI», вы знаете, специализированный облачный инженер. Было бы преувеличением сказать, что все работает, но ведется работа в этом направлении. Да, я лично не поклонник того, чтобы ставить лицо за этими вещами. Я думаю, это трюк, и я думаю, что через несколько лет очень немногие продукты будут иметь человеческое лицо за собой. Но это может быть маркетинговая тактика некоторых стартапов. Это скорее пугает, чем увлекает, честно говоря. Хорошо, я хочу поговорить о пиратском сдвиге. Это особенно полезно. Допустим, вы программист или планируете им стать, потому что инженерия программного обеспечения как дисциплина как бы меняется, или, по крайней мере, лучшие инженеры, с которыми я работал, способны перейти от детерминированного мышления к нечеткому мышлению и балансировать между ними, когда им нужно что-то сделать. Итак, вот пиратский сдвиг между традиционным программным обеспечением и агентским ИИ-программным обеспечением. Первое — это то, как вы обрабатываете данные. Традиционное программное обеспечение работает со структурированными данными. У вас есть JSON, у вас есть базы данных. Они размещены в очень структурированном виде в конвейере обработки данных, а затем используются для отображения на определенном интерфейсе. Пользователь может заполнить форму, которая затем извлекается и вставляется в базу данных. Все это исторически были структурированные данные. Теперь все больше и больше компаний работают с неструктурированным текстом, изображениями и всем этим требуется динамическая интерпретация для преобразования входных данных в выходные. Само программное обеспечение раньше было детерминированным. Теперь у вас есть много программного обеспечения, которое является нечетким, а нечеткое программное обеспечение создает так много проблем. Я имею в виду, представьте, что вы позволяете пользователю спрашивать что угодно на вашем веб-сайте. Шансы, что он сломается, огромны. Шансы, что вы будете атакованы, огромны. Шансы, это действительно, действительно сложно. Это сложнее, чем люди делают вид в Твиттере. [фыркает] Нечеткая инженерия действительно сложна. Да, вы можете получить ненависть как компания, потому что один пользователь сделал что-то, что вы разрешили ему сделать, что в итоге сломало базу данных, и в итоге, вы знаете, мы видели это со многими компаниями за последние пару лет. Так что требуется очень специализированный инженерный склад ума для нечеткой инженерии, но также и знание, когда нужно быть детерминированным. Другое, что я называю, это с агентским ИИ-программным обеспечением, вы как бы хотите думать о своем программном обеспечении как о своем менеджере. Так что вы знакомы с монолитными или, знаете ли, подходами к микросервисам в программном обеспечении, где вы структурируете свое программное обеспечение в разные, знаете ли, блоки, которые могут общаться друг с другом, и это позволяет командам отлаживать одну секцию за раз, знаете ли. Теперь эквивалент с агентским ИИ — это то, что вы думаете как менеджер. Так что вы думаете: «Хорошо, если бы мне пришлось делегировать свою работу группе людей, какие бы это были роли?» Был бы у меня графический дизайнер, который затем, знаете ли, собирает диаграмму и отправляет ее менеджеру по маркетингу, который превращает ее в хороший пост в блоге, который затем передает эксперту по маркетингу, который затем публикует пост в блоге, а затем оптимизирует и проводит A/B-тестирование, а затем передает ученому по данным, который анализирует данные и затем выдвигает гипотезы и подтверждает или опровергает их. Так вы бы обычно думали, если бы строили агентское ИИ-программное обеспечение, тогда как эквивалент этого в традиционном программном обеспечении может быть совершенно другим. Это может быть: у нас есть блок обработки данных здесь, который обрабатывает всю нашу обработку данных. А затем здесь у нас есть UIUX. Все, что связано с UIUIX, идет сюда. И знаете, компании могут структурировать это по-разному. И вот бизнес-логика, о которой мы хотим позаботиться. И над бизнес-логикой работают пять инженеров. Скажем так, хорошо, [фыркает и смеется] тестирование и отладка также очень разные, и мы поговорим об этом в следующем разделе. Другое, что, как мне кажется, имеет значение, это то, что с ИИ в инженерии стоимость экспериментов резко снижается, и поэтому, как мне кажется, люди должны быть более комфортными, выбрасывая код. Знаете, это как в традиционной инженерии программного обеспечения, вы, вероятно, не выбрасываете код тоннами, вы пишете код, и он надежен и пуленепробиваем, а затем вы обновляете его со временем. Мы видели, что ИИ-компании более комфортно выбрасывают код. Да. Что имеет преимущества с точки зрения скорости, с которой вы движетесь, но также и недостатки с точки зрения качества вашего программного обеспечения, которое может чаще ломаться. Нет. Хорошо. Итак, в любом случае, я просто хотел сделать отступление о пиратском сдвиге от детерминированной к нечеткой инженерии. О, и на самом деле я могу привести пример из 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 или Model Context Protocol, который был введен 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 AI агентский рабочий процесс плох с ценами. Он просто не так хорошо читает цены, потому что он всегда предлагает более дорогой вариант. Да, вы совершенно правы. А как насчет субъективных вещей? >> Да. >> Например, выбираете ли вы прямой или непрямой рейс, если непрямой немного дешевле? >> Да, хорошо. Вы выбираете прямой рейс или непрямой рейс, если непрямой дешевле, но прямой более удобен? Да, это действительно хороший вопрос. >> Итак, как вы будете собирать эту информацию? Скажем, этим пользуются тысячи пользователей. >> Могли бы вы что-нибудь сообщить о нас? >> Могли бы вы что-нибудь сообщить? Да, я имею в виду, вы могли бы построить набор данных, который содержит некоторую информацию. Так что вы создаете 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, потому что через два года вам это не понадобится, понимаете? Так что я бы предпочел, чтобы вы подумали о том, какой широкий спектр вещей вы хотите понять, и когда вам это понадобится, вы будете спринтовать и учиться именно тому, что вам нужно, быстрее, потому что полураспад знаний так низок, понимаете, вы хотите выйти из класса с хорошим пониманием и затем иметь возможность углубиться, когда вам это понадобится после класса, и именно так разработан этот класс. Э-э, да, это все на сегодня. Так что спасибо, э-э, спасибо за участие.