顧哥知識系統

吳恩達 Agentic AI 第八講 Agentic design patterns

閱讀時間約 8 分鐘

吳恩達 Agentic AI 第八講 Agentic design patterns

Transcript

[00:01] We build agent-ed workflows by taking
[00:03] building blocks and putting them
[00:04] together to sequence out these complex
[00:07] workflows.
[00:08] In this video, I’d like to share with
[00:10] you a few of the key design patterns,
[00:12] which are patterns for how you can think
[00:14] about combining these building blocks
[00:16] into more complex workflows. Let’s take
[00:19] a look. I think four key design patterns
[00:21] for building agent-ed workflows are
[00:23] reflection, tool use, planning, and
[00:26] multi-agent collaboration. Let me
[00:27] briefly go over what they mean, and then
[00:30] we’ll actually go through most of these
[00:32] in depth later in this course as well.
[00:34] The first of the major design patterns
[00:36] is reflection. So, I might go to an LLM
[00:40] agent and ask it to write code, and it
[00:42] turns out that an LLM might then
[00:44] generate code like this. You know, it
[00:46] defines here a Python function to do a
[00:48] certain task. I could then construct a
[00:50] prompt that looks like this. I can say,
[00:52] “Here’s code intended for a certain
[00:53] task.” And then copy-paste whatever the
[00:55] LLM had just output back into this
[00:57] prompt. And then I’ll ask it check the
[00:59] code carefully for correctness, style,
[01:00] and efficiency, and give it a critique
[01:02] of the code. And turns out that the same
[01:03] LLM model, prompted this way, may be
[01:06] able to point out some problems with the
[01:08] code. And if I then take this critique
[01:11] and feed it back to the model to say,
[01:14] “Look, this is a bug. Could you change
[01:16] the code to fix it?” Then it may
[01:18] actually come up with a better version
[01:20] of the code. To give a preview of tool
[01:23] use, if you’re able to run the code and
[01:25] see where the code fails, then feeding
[01:29] that back to the LLM can also cause it
[01:32] to be able to iterate and generate a
[01:34] much better, say, V3 version three of
[01:36] the code. So, reflection is a common
[01:38] design pattern where you can ask the LLM
[01:41] to examine its own output, or maybe
[01:43] bring in some external sources of
[01:45] information, such as run the code and
[01:47] see if it generates any error messages,
[01:49] and use that as feedback to iterate
[01:51] again and come up with a better version
[01:54] of its output. And this design pattern
[01:56] isn’t magic. It does not result in
[01:59] everything working 100% of the time. But
[02:00] sometimes it can be a nice bump in the
[02:03] performance of your system. Now, I’ve
[02:05] drawn this as if it was a single LLM
[02:07] that I’m prompting, but to foreshadow
[02:09] multi-agent workflows, you can also
[02:12] imagine, instead of having the same
[02:14] model critique itself, you can imagine
[02:16] having a critic agent, and all that is
[02:18] is an LLM that’s been prompted with
[02:21] instructions like, “Your role is to
[02:22] critique code. Here’s code intended for
[02:25] task. Check the code carefully.” and so
[02:26] on. And the second critic agent may be
[02:28] to point out errors or run unit tests.
[02:31] And by having two simulated agents,
[02:34] where each agent is just an LLM prompted
[02:36] to take on a certain persona, you can
[02:38] have them go back and forth to iterate
[02:40] to get a better output. In addition to
[02:43] reflection pattern, the second important
[02:45] design pattern is tool use, where today
[02:48] LLMs can be given tools, meaning
[02:50] functions that they can call in order to
[02:52] get work done. For example, if you ask
[02:55] an LLM, “What’s the best coffee maker
[02:56] according to reviews?” and you give it a
[02:58] web search tool, then it can actually
[03:00] search the internet to find much better
[03:02] answers. Or a code execution tool. If
[03:05] you ask a math question like, “If I
[03:07] invest $100 at compound interest, what
[03:09] do I have at the end?” it can then write
[03:10] code and execute code to compute an
[03:12] answer. Today, different developers have
[03:15] given LLMs many different tools for
[03:17] everything from math or data analysis to
[03:19] gather information by fetching things
[03:21] from the web or from various databases,
[03:23] to interface with productivity apps like
[03:25] email, calendar, and so on, as well as
[03:28] to process images and much more. And the
[03:30] ability of an LLM to decide what tools
[03:33] to use, meaning what functions to call,
[03:36] that lets the model get a lot more done.
[03:39] The third of the four design patterns is
[03:41] planning. This is an example from a
[03:44] paper called Hugging GPT, in which if
[03:47] you ask a system to “Please generate an
[03:51] image where a girl is reading a book on
[03:52] a is the same as blind image, then
[03:54] please subscribe to new emission voice,
[03:56] then a model can automatically decide
[03:58] that to carry the task, it first needs
[04:01] to find a post determination model to
[04:04] figure out the post of the boy, then to
[04:06] post the image, to generate a picture of
[04:07] a girl, and the image to text, and then
[04:09] finally text to speech. And so, in
[04:12] planning, an LLM decides what is the
[04:14] sequence of actions it needs to take. In
[04:17] this case, it is a sequence of API
[04:20] calls, so that it can then carry out the
[04:22] right sequence of steps in the right
[04:24] order in order to carry out the task.
[04:27] So, rather than to developer hard coding
[04:29] the sequence of steps in advance, this
[04:31] actually lets the LLM decide what are
[04:33] the steps to take. Agents that plan
[04:36] today are harder to control and somewhat
[04:38] more experimental, but sometimes they
[04:40] can give really delightful results. And
[04:42] then finally, multi-agent workflows.
[04:45] Just as a human manager might hire a
[04:47] number of others to work together on a
[04:49] complex project, in some cases, it might
[04:52] make sense for you to hire a set of
[04:54] multiple agents, maybe each of which
[04:56] specializes in a different role, and
[04:58] have them work together to accomplish a
[05:01] complex task. The picture you see here
[05:03] on the left is taken from a project
[05:05] called Chat Dev, which is a software
[05:07] framework created by Chen Chen and
[05:09] collaborators. In Chat Dev, multiple
[05:12] agents with different roles, like chief
[05:14] executive officer, programmer, tester,
[05:16] designer, and so on, collaborate
[05:18] together as if they were a virtual
[05:20] software company, and can
[05:23] collaboratively complete a range of
[05:25] software development tasks. Let’s
[05:27] consider another example. If you want to
[05:30] write a marketing brochure, maybe you’d
[05:32] think of hiring a team of three people,
[05:34] such as a researcher to do online
[05:37] research, a marketer to write the
[05:38] marketing text, and then finally an
[05:40] editor to edit and polish the text. And
[05:43] so, in a similar the you might consider
[05:46] building a multi-agent workflow in which
[05:49] you have a simulated research agent, a
[05:51] simulated market agent, and a simulated
[05:54] editor agent that then come together to
[05:57] carry out this task for you. Multi-agent
[06:00] workflows are more difficult to control
[06:03] since you don’t always know ahead of
[06:04] time what the agents will do, but
[06:06] research has shown that they can result
[06:08] in better outcomes for many complex
[06:11] tasks, including things like writing
[06:13] biographies or deciding on chess moves
[06:15] to make in a game. You learn more about
[06:17] multi-agentic workflows later in this
[06:19] course as well. And so with that, I hope
[06:21] you have a sense of what agentic
[06:23] workflows can do, as well as of what are
[06:26] the key challenges of finding building
[06:28] blocks and putting them together, maybe
[06:30] by these design patterns, in order to
[06:32] implement an agentic workflow, and of
[06:35] course also developing eval so you can
[06:37] see how well your system is doing and
[06:39] keep on improving on it.
[06:41] In the next module, I’d like to share
[06:44] with you a deep dive into the first of
[06:47] these design patterns, that is
[06:49] reflection, and you’ll find that is a
[06:52] maybe surprisingly simple to implement
[06:54] technique that can give the performance
[06:56] of your system sometimes a very nice
[06:58] bump.
[06:59] So, let’s go on to the next module to
[07:02] learn about the reflection design
[07:04] pattern.

關係圖譜