Janani Sekar:
All right. Hello everyone, and welcome to the third module in this Agentic AI for Research series. This video is going to be all about giving you the essential technical concepts required to understand the inner workings of an AI agent. So we've been saying things like AI agents have access to APIs and external tools. We've been saying that AI agents are reasoning engines using language models with other things built on top of them, the ability to execute multi-step workflows. What exactly does all of that mean? Well, let's get started with the external tools bit. So we'll first talk about APIs or application programming interfaces, which are basically protocols that allow software applications to communicate with each other. And specifically by communicate, I mean sending and receiving data. So when you have an agent that is querying a database like the Federal Reserve for inflation, or you have an agent that is writing a PDF or searching the internet, that is going to require that agent to connect to some other software application or tool or website.

And that happens through an API. And so if it's helpful to see an analogy, IBM proposes thinking about this as a restaurant. This is not my analogy. This is written by computer scientists who understand this very well. If you want to see the original reference for this, that will also be linked at the end of the presentation. For me personally, more so than even this analogy, I think doing an example can be a really helpful way to put concreteness to this. And so imagine that we have an agent that we want to communicate with the Spotify API. And by that, I mean we want data about songs that Spotify has in its database. So the way that we would go about doing this is we would get ourselves what we call an API key or authentication token. This is basically proof that we have the authorization to access data from Spotify.

You just need to log into the website and you can get yourself one of these. The next thing that we'll do is we'll tell our agent to write a structured query to get data from Spotify. This would involve basically saying, "I want data on Song X and the fields or the parameters that I want include things like artist, album, release date." The request will be written in a specific format, typically a format called JSON. It'll get sent over the internet. The Spotify API is going to receive that request. It's going to pass it to Spotify, query a database, get the information that you're looking for, format that responds in a similar format and send it back to you, the user, along with a code that indicates whether that interaction was a success or not. And you've probably seen these codes before, even in your regular internet browsing, where a 200 is typically a success code, a 404 is a classic error, page not found, resource not found, data not found error.

And this is how we know whether or not that interaction was successful. So we've now talked about APIs, how agents can access external tools, which is what gives them this leg up over standard language models, but not to ignore the language models themselves. Like I said, these are really the backbone of the agent. These are the reasoning and the brain behind that agent and how it plans tasks and how it executes tasks. And we've all seen and worked with language models at this point. We know what Claude and GPT are. To peel back a little bit of the mystery since people have asked me about this, I thought I would quickly touch on how language models work from a technical sense, and then we can get into the discussion of what they can do for us as agents. When we build language models, they are just neural networks, but they are trained on massive amounts of data, typically the entire internet.

And the way that they're trained is they see millions and billions of documents. And as they see those documents and the words in those documents, they learn which words occur next to each other in the same context, which teaches them how words relate to each other, the meanings of words, the similarities of words, which then allows them to learn a probability distribution over this entire vocabulary, over this entire space of different words. And so what happens is as a user like you or me asks a language model a question, all the language model is doing when it's generating an answer is using its probability distribution to generate the most likely, the most probable sequence of text to respond to that question given the words or the text in that question. It just keeps generating an answer or response word by word until the next most probable action is to stop generating text because it's reached the end of a thought or the idea or it's answered your question.

So pretty complicated in code and in math, but not super complicated in logic. So what kinds of capabilities become exposed when you have a model that is designed to do such a thing? So we know that obviously language understanding is the main one. It's also the main goal behind why these models were developed, but alongside an understanding of language, we also get things like the ability to problem solve, the ability to generate code, the ability to translate, not just between languages, but between formats, between tones, between audiences, and really this is what allows agents to do a wide range of cognitive work. And so there are things that language models on their own don't do very well, and this is where having access to tools and agentic capabilities is going to take them to the next level. If you've ever used a language model to do coding, you know that it doesn't have access to your local data files, the files on your computer, it doesn't know what's in your downloads directory versus in your documents directory, doesn't have access to all of the columns in your table.

So if you tell it to run a regression, it might use the wrong file path, it might use the wrong column names. If you pasted that in directly to your R or your data or your Python interpreter, it probably wouldn't even work. You might have to go back and forth a little bit. The same thing is also true about more complicated tasks like making plots or figures. So how do we get language models to work more effectively for us even when we have agents? So there is an entire field, entire corner of this literature, I should say, that is dedicated to helping us use agents and language models effectively by giving them the right kinds of prompts by asking them the right kinds of questions. So you can think about prompt engineering as getting AI to work for you by asking it or communicating to it in the right way.

I'm going to go over the next few slides, some best principles for prompting and getting good quality outputs from language models. These are strategies that are assembled by two papers that I think are really good reads, Liu et al and Wei et all in 2023 and 2022 respectively. These will also be linked at the very end of this presentation. I'm not going to spend too much time on any one of these slides. If you'd like to read the prompts over or test them out, I will pause the video or feel free to pause the video and look closer, but I'm just going to go through each of these best practices as quickly as I can. So the number one thing is to be specific. We generally want to avoid saying things like analyze this data. We instead want to do more of saying things like, analyze this data set, which has this column, this column and this column.

By analysis, I mean I want you to do one, two, and three, providing context. So also pretty self-explanatory, similar to the last idea. Maybe tell the model a little bit more about the nature of your data and what types of columns it has, whether those are numerical or categorical or text data, how many rows do you have? What do those rows represent? And so on and so forth. This one I will spend a few minutes on. Specifying the output format can be a really good way to guarantee some degree of data quality. This can be something as simple as write me a 200 word paragraph or give me two sentences or give me an outline or use bullets, but it can also be a lot more detailed like you are asking a language model about employees in your organization and you want to make sure that when it responds, each response has an employee name, age, ID, department, and the like.

This would not be something that I think we would typically do as researchers, but let me give you an example where you might use a structured output when you're annotating data. You want the actual annotation or the response from the model. You want some level of magnitude, so how much does this label or annotation apply to this data? And then you might want some confidence. So how much, how sure are you in this label or annotation that you've given me? So you can do a three-way structured output that gives you both your data, but also some metadata about the model's response. And the way that we would typically do this is using a Python library called Pydantic. I will leave this slide up for a little bit so that you can pause the video and look at the documentation for Pydantic if you're interested in understanding this in a little bit more detail.

For some additional strategies, viewshot prompting, using examples is a really good way to get the model to answer in a format that is closer to what you're expecting. You should try to structure your examples from least complicated to most complicated in my experience. There's also some trial and error to be done here in terms of how many examples is sufficient and how many examples is too much such that your model gets confused. That definitely just is situational and comes from some trial and error. Chain of thought is explicitly telling your model to think. A very similar strategy involves what we call role prompting. So saying you are a teacher or you are a research assistant, or you are an econometrician, or you are a financial advisor. And what this does is somehow inside a model that already had this knowledge just unlocks that knowledge. And so telling a model to think like an econometrician somehow automatically makes it better at running a diff and diff.

We don't fully understand why, but we know that this is true in practice, so you should definitely try it. Specifying constraints is another one that I'll spend a little bit of time on. I find that it is helpful to tell a model what not to do, and giving it this laundry list of instructions on how not to behave actually makes sure that you constrain the space of response and volatility and response that you might get. So also worth flagging. Some common challenges that both I've experienced that a lot of my peers have experienced that people have documented in the literature are order effects. So this is what I said earlier when I said the order of examples when your few shot prompting can really make a difference. Framing effects, are you framing your question in a positive or negative way and how does that change your model's response?

How detailed or verbose is your prompting? Detail is generally good. There is also such a thing as too much. And keep in mind that things that might seem very clear to you can actually be interpreted ambiguously by your model. And so obviously we can't anticipate all of these ahead of time. The best way to see what prompting strategy really works is to try a bunch of things and then compare results. And especially if your analysis for whatever research task you're working on is not robust to different types of prompts, you want to make sure that you report all of those results and you see if there are any underlying patterns in prompting that cause the responses to be more similar or more different.