It is terrific that you're hanging on in there and making such great progress with this course.
As we enter the final few days of building really important expertise on the topic for today, for week
eight.
Day three is about continuing to strengthen, to upskill, building one more skill, but also resummarize
revise some of the stuff that we've done in the past.
So today we're going to look at something new.
Structured outputs, which is something actually that is quite a recent innovation, a way that you
can tell frontier models that you want them to respond according to a particular specification.
So we'll be doing that today.
And we're also just going to be doing more work experience with frontier models, carrying out something
which is going to be a throwback, a callback to the first week, because we're going to be doing some
internet scrappage, as we had done in the past, and using frontier models to help synthesize data.
You remember we wrote a summarizer A way back.
The Reader's Digest of the internet was our week.
One day, one instant gratification.
Well, we're taking that a couple of notches further.
Um, so that's the plan for today.
And a lot of this, again, is going to be about revising and building and experimenting.
So let me just say a few words about structured outputs.
So structured outputs.
You remember in the past we've used JSON generation.
We've we've said that we want the model to respond with an output format in JSON.
And then in the prompt we describe exactly what that JSON should look like.
And it's not 100% reliable.
It's actually very good.
It's it's uh, frequently, uh, if not almost all the time will respond with JSON.
But where it starts to, to go wonky is if you've got really complicated objects that you need it to
respond in, um, it will after a while, potentially hallucinate in some parts or give back wrong formats.
So the idea of structured outputs was to be more directive about specifying exactly how the model should
respond.
And the way you do that is you define the response with a class, with a Python class, and it's actually
going to be a class which is going to be a subclass of something called base model from Pydantic, which
you may have already had experience with if you're from an engineering background, but don't worry.
If not, I will show you.
Uh, you make a subclass of base model, and you use that to describe exactly what you're looking for.
Um, and then you specify that class when you call OpenAI, and it will create an instance of that class
in what it sends back to you.
Um, and so that's the, the idea, it's useful, as I say, for generating data in precisely a structure
that you need.
It needs to be compared with an alternative approach, which is use of tools function calling that we
looked at again some time ago.
Um, and they, they, they both they're quite similar techniques for ensuring that a particular, um,
uh, type of, of structure comes back in the response from the model.
And there's pros and cons of both of them.
Generally speaking, the recommendation is that if you are going to be hooking up your model directly
to application code so that it's going to be making calls to functions which need to have a particular
method signature, then it's better to use function calling and tools.
That is the the better model, because then it will absolutely respond according to that JSON structure
that you've defined with the right parameters for calling your function.
If what you're looking at is to try and generate data in a particular format for downstream consumption
or something, uh, then structured outputs is the way.
Uh, so those are some of the pros and cons, and it's something that you get a feel for after you've
tried it for a while and get to appreciate when one performs better than the other.
But with that introduction, let's head over to JupyterLab.
We're going to try it out for ourselves.