Hello hello hello good afternoon everyone I hope you all had a wonderful lunch there's
So many of you as well, I'm actually kind of surprised by this.
Happy to see that there's that much interest in talking about evals.
I personally am a big fan of anything evals related, but I know that's not everyone's cup of tea, right?
So very happy to see this many people of you.
So today's session is really going to be about evals.
And I guess my goal for this session is for you all to be
afterwards, to be inspired, to build evils, to be like,
okay, evils are actually really useful
and how you can act on them, right?
Like, we're gonna be building evils.
I want you to get a better sense of like,
okay, how should I be thinking about building evils?
What are useful type of evils?
And then also, how can we use and take these evils
to then make better agents, right?
So that's the main goal of this session.
And the way we're going to do this is by building a slide generation agent and then finding
out like, okay, what are some good evals?
What do we want to measure?
And then how can we build now better agents based on feedback that we're getting from
our evals?
And the first thing that we all need to set the stage on is what are evals, right?
So evals are systematic tests that measure how well an AI system performs on a specific
domain or use case.
So they give you information about what's the quality of the results, what did it do
well, what was it not good at, how can we improve.
And evals are made up of tests that define certain scenarios that then encode certain
expectations through degrading logic.
So one way that we're thinking about evals is if you, for example, are building an AI
system, an AI agent, and you want to make sure that the output adheres to a certain
type of quality, or you need to make sure this must always be present, evals are a way
to kind of encode this behavior in a way where then afterwards, if your evals fail, you know,
like, okay, my agent is not doing all of the behaving the way it is intended.
So that's the way how we can use these evals.
And then evals is also the bridge between things like it seems to work or like we know
it works or maybe it's all like, ah, it kind of feels a little bit worse today for some
reason.
It's always very hard to act on these types of vibes, right?
Like I think vibes definitely have their own place.
I think they're useful just to get like a general sense check of like how people are
feeling.
But they're not very actionable, right?
And that's kind of what we want to get out of evals.
We want to have something that's actionable.
So then we always ship evals.
Once we release a model, we always
have this accompanying benchmark card.
And we always list, oh, these are a bunch of evals.
This is what we achieve, what our models achieve.
We compare them to other models.
We compare them to competitor models.
And there's always a few usual suspects.
For example, SweeBench is a very famous one which measures agent decoding abilities.
Terminal Bench is one that's also quite popular, but we also have other types of evils, right?
We have tool use and agents, like for example, like TauBench, BrowseGum, OS World, which
are some other evils that measure different things.
And then we also have reasoning and knowledge, like ArcAGI too.
Now this is all fine and dandy, right?
And then you look at these evils and we always, every time a new model is like, oh, it's
top of the benchmark for these and these evals, right?
And they give us a general sense of how well is the model
and how much did we improve upon previous versions, right?
But for you guys, if you're building something,
if you're building an agentic system,
this doesn't really say much usually, right?
Because we don't measure, for example,
a very specific use case that you guys are building on, right?
We measure these generic, general benchmark
that measure a lot of capabilities,
but they might not be applicable to your specific use case.
So that's why we always say, build your own evals,
benchmark the different models, benchmark your AI agent,
and make sure that you get the most out of the models,
and make sure that you're also using the right model
for the job.
All right?
And so why are these evals specifically important?
So this is my pitch to you of start using evals.
So without evils, suppose you don't have evils,
I think we've all been into the scenario
where you have this agent and it's working fine
and then you get this feedback of a customer
who is saying it's not really up to par
of this new model switch, something is off.
It's very hard to do anything with that information.
It's just like, okay, do you have some logs
maybe that we can take a look at some specific instances?
and then you try to debug it manually.
But in a way, you're still flying blind.
You're always in a reactive loop,
so you wait for the feedback, and then you're like,
okay, let's see what we can do about this.
So you basically only catch issues in production.
You can fix, for example, one issue,
which then might, for example,
create multiple more down the line
by making, I don't know, a prompt change tweak
that suddenly degrades the capabilities
on other tasks that you haven't even considered.
It's also quite annoying to distinguish genuine feedback from noise, which is always, you
don't want to act on every single thing that you see because people have also some biases
in their way they perceive these things.
And then finally, I think which is the most important one, is there's no way to verify
improvements or regressions on anything that you're building or that you've done.
So you need a way to make sure that the changes that you are making to your agent are actually
impacting the quality and making sure that you improve upon the previous versions.
And so this is basically what evils do give you. If you add evils, you have clarity. You need to
define what does success look like. Because let's say you don't have evils and you're not even able
to articulate this is how the agents should behave, this is what a successful end product would look
like for my agent, then how can you make sure that your agent is actually behaving properly
because you can't even vocalize it to yourself.
Like, this is what it should be.
So building this evals forces you
to define, formalize, in a way, what
you expect your agent to do.
It also allows you, as I said, to iterate on Optible Agent
configs.
You can also adopt new models faster, right?
Instead of saying, like, oh, we might test out this new model
and then see if it's like, OK.
You now have some clarity.
You say, OK, this is better on this,
and this is not better on this, and this
is why we should or should not migrate to a new model.
Which especially, I think, is quite relevant
with the pace of new models coming out.
I think it's also like just taking this load of your back
of always constantly having to find like,
okay, what is the new frontier, right?
And then finally making problems visible before launch, right?
So you know, like, oh, if there's like a few cases
that you have that we always do well,
but that you trust to provide a lot of insight,
That's where you get the most value out of evals.
And so how do evals really fit in?
So originally, when we were thinking about prompt
engineering, we had basically this flow of how you should
optimize your prompts.
So first you develop your test cases, which are the evals
in the end.
Then you write a prompt.
You test out the prompt against the tasks.
You refine the prompt a little bit.
And then it goes back.
You run the prompt again.
you refine it until you've like, okay,
I'm doing great on my evals,
I'm confident that my system is working properly.
And then finally you can like ship the polish prompt, right?
Over time systems have gotten a little,
oh, can I go back?
Can we go back one slide please?
Thank you.
So over time it has gotten a little bit more complex
with now agents coming in to loop with like tool calls,
skills, all the different ways to optimize your contacts
and all that stuff.
So over time, these systems get more and more complex.
So it's also way more leverage that you can pull
to make changes to your agents,
which makes it once again, then more important
to have evals that forces you to have concrete way
of identifying these are the things that we can change
and these are the things that impact the system
in a positive way.
So once again, like with agents, it's the same flow, right?
except now we test way more and way more complex things.
evals, when you create them, there's basically a few
graders, a grader is what we consider basically a way
how we can judge the outputs, right?
And like one of those ways is for example,
a code-based grader, which is pretty similar to,
for example, a unit test, as you might know,
in like software engineering, right?
It can be like a string match, redjacks,
maybe a fuzzy match, but it's like a strict analysis, right?
It finds static and tool call checks,
and the advantages of this one is it's fast,
cheap, deterministic, but it has a big drawback,
which is that it's brittle, and it also lacks nuance, right?
And with this we mean, especially brittle
is quite an interesting one, in my opinion,
because the deterministic checks,
they force a certain deterministic behavior, right?
But sometimes this is absolutely the way we want an agent
to behave, right?
Like for example, let's say you have an agent
that creates a slide deck, for example,
you want to make sure that in the end,
there is a slide deck present, the terministic check.
But then if you want to have like a check
on what's the quality of this slide deck,
this is way more nuanced, right?
Like you cannot easily encode this
in like some of the terministic checks, right?
And that's why we also have this second type of graders,
which is the model based graders, right?
And this is like rubric based reasoning.
So if for example say like,
is this slide high quality?
Very generic, but that might be for example rubric,
or like for example, is this text coherent?
Also a way to get some intel
on how well your agent's performing.
You can do some interesting things with this as well.
Paralyzed comparison is in my opinion, quite underrated.
let's say you have two examples, two outputs,
and then you're basically asked model,
which one of the two do you prefer and why?
That's also quite interesting to get some information out of,
especially for these scenarios where you don't really
have a clear way of defining what makes a better one, right?
And then another one is the multi-judge consensus,
which is just, for example, you take like best of three
and you say like three judges score independently
and say like majority wins, for example.
Once again, that this multi-judge consensus
is interesting because it allows you to introduce
some more determinism in a way,
where if you have like, we know that an LLM
is undeterministic, right?
And the same would be happening
for these model based graders, right?
If you run them like 100 times, a few times it might say,
oh, this is great, and a few other times it might say,
ah, it's not that great.
If you have like this multi-judge consensus,
you basically are assuming, let's put more compute
into this and let's see what the majority of our graders
consensus is.
And this unlocks a lot of things.
Like this is flexible, this is scalable, this is nuanced.
But as I said, it's non-deterministic.
It costs more money and also it requires some calibration,
which we will see is not easy at all.
And then finally, the most expensive one
are the human graders.
And these are probably the graders
that when you're building these agentic systems,
you will be using the least, right?
Because they're like incredibly expensive.
You have like a whole subject matter expert
that will do like a whole review of the system.
It's expensive, it's slow as well,
but it's the highest quality, it is very nuanced.
And yeah, it's like really good for like some AB testing
and some spot checking, right?
So I'm not sure like how many of you were able
to clone the wrapper beforehand and have this all set up.
I actually wanted to do this session a little bit differently
but given the amount of people, I will probably do a little bit more myself instead of letting
you think about all of the things. But I'll quickly give you an overview of what's in
the wrapper. Let me make this a little bit bigger. I have made some pre-made slides that
I will show you in a bit. The resources is the main thing where you guys would be working
in. So you have the, let me close this session for now. I'm safe like the agent.yaml. And
And this is basically where you would define your agent.
I think before we did a session.
So this is basically what we're going to use,
like the managed agent.
So for the people who attended that session before lunch,
it's basically the same thing.
We define here an agent in this case.
And we have given this the system prompt.
So this is a system prompt that we're giving.
So basically, you are a slide generation agent.
And when the user gives you a topic,
create a PowerPoint file at this location.
And then also, we tell it, you have a shell
with Biden PPTX pre-installed.
So that's all we give it for now.
And then we also have an environment,
which we've defined with a few packages,
and what it needs to complete this session.
And then basically, that's it.
We also have some other things defined,
but I will get to that.
I think maybe the first question that I have for the audience
today is, we want to make a slight generation agent.
What do you guys think is a good evil?
What are you trying to measure?
What would be some good information that you want to get out of evils?
Sorry?
Number four, it's on slide.
This is an easy, useful thing to track.
And anyone else with some ideas?
Sorry?
Yeah, absolutely valid.
Absolutely valid.
Yeah, yeah, yeah.
And this is actually, I like these two examples,
because they immediately give you a different sense
of how you can use a type of grader.
Like for example, the number of words on a slide
is quantifiable, right?
It's like easy to say you can count the number of words
with a deterministic grader, with a code grader.
The one if it's overlapping or if it's overspilling,
that one is harder to encode in code, right?
So for this one, you might, for example, use a model grader.
And that's exactly what we did, right?
So we have actually defined for you guys
already a few graders beforehand.
do a specific, directories, we have the code,
and we have judge.
So the code one is, as I said, it's like this.
This code creators are quite deterministic,
like for example, if we take a look at emoji count,
for example, is one that we have defined,
where we basically just count the number of emojis
present in the slide deck.
Because we just noticed that it's quite prevalent.
Like for example, if I open the slide deck,
let me go with environment one in this case.
So these are the slides that are basically the agents running.
It's done beforehand just because it can take quite a while to get the agents running.
But this is, for example, the results of our initial agents.
So this is slide number one, slide number two, slide number three, with some weird things
on the bottom left, slide four and slide five.
Now, I think we can all agree this is not the best slide deck
you guys have ever seen.
But it's a good start.
At least there's a slide deck.
There's five slides.
I think that's exactly the prompt that we send it.
So we have a few slides.
There's a few content on it.
There's a few boxes.
It's a slide deck.
Given these slides, is there anything else
that you guys are seeing that this is something
that we would never want in our slide deck?
What was that?
No teal.
If you absolutely want to avoid teal, that's absolutely right.
I think in this case, it doesn't do that for every single slide.
Let me see for the career one.
Let me see what this...
Oh, okay, maybe it does always use teal, actually.
But for example, in this one, we see this overlap of words and this horizontal.
What else do we have? Some weird coloring?
Yeah, there's a few weird things happening generally, right?
So yeah, based on this, you take a look at what it is, what it was also, and you're like,
what type of graders do I want to define for this specifically?
Right? And so we did that and we noticed, for example, emoji counts is one that's quite prevalent.
We want to check how many times do we see an emoji popping up.
Another one is, for example, cluttered slides,
like how many shapes do we see on these slides?
Like if that's just too many things, it becomes cluttered.
Counting the number of slides,
for example, we always ask for five slides,
making sure that you have five slides.
Do we have slides with image, small fonts,
text heavy slides?
Now, in this case, it's quite arbitrarily chosen, right?
These were just things that we thought were,
this is quite representative of what a slide deck might be.
have for graders, right? It really depends, like I really want to stress this, like it
really depends from use case to use case what makes a good grader, right? I think
generally the way I think about this thing is if you have a grader that you
get no useful out of information out of then you should not have that part of
your e-mail, right? Like each thing you should be able to tell, like for each
single scenario that you're testing, you should be able to say like this is the
the information that I want to get out of this.
This is the type of, this is the part of the system
that I'm testing, and this is how I can act on
if it's being degrading, right?
So those were just like a few codes once,
and then we also have a few judge ones.
For example, the color judge,
which basically judged what's the color contrast,
and then it gives a score from like zero to five.
Same with image, the layout, text,
and this is the prompt that we give.
Let me close this one real quick.
Oh, actually let me keep it like this.
So this is basically the system prompt that we give it.
So it's saying, please evaluate the slide
based on each of the following criteria, text.
The title should be simple and clear
to indicate the main points.
For main content, avoid too many text and keep
force concise.
Use a consistent and readable font size, style, and color.
And I mean, it goes on and on.
So we give for each of the different things
that we want to measure, we give the little information
of like, this is what you should be focusing on
when you want to measure this, right?
Okay, cool.
So we have these evals.
Let's say you have now created a slide deck
and you now wanna see like, okay, what are the results?
And how can we act on these results?
So in this wrapper, we also have created
this nice little script that will automatically
score your slide deck for you.
And so at the top here, we basically have it all listed out.
So we have like the slide count,
which is being counted the number of slides,
which image, text-heavy slides, cluttered slides,
small font slides, and so on.
We also have our judges over here,
which are saying they give a score from zero to five,
based on how good is the text,
how good is image at the layout and the color.
Honestly, this course, you can immediately note
that these scores are quite high.
So as we said, we calibrated between zero and five.
And as we see the scores you've been giving here
between 2.8 and 4, which honestly, I think, are quite high,
given the slide deck that we have seen.
So that's like the part of the calibration
that needs to happen as well.
I think there's also one thing that I maybe want to stress.
It's not because you have set up your evils once,
that they are now like the ground truth.
Evils, over time, they can evolve.
They need to be a living artifact.
It's not like something you make once and then forget
and then use this to make all of your future decisions on.
Because we will see over time,
as I go through all of the different examples
that we have, we will see like there needs to be a way also
how we can see, how we can make sure that the evals
that we create are actually still measuring
something useful for us, right?
If you ever hear people talk about saturation of evals,
that's basically what they mean in a way that like
the eval is not giving any more relevant information
that we can act on due to several reasons.
Cool, so we see this and I guess maybe the first thing
that we wanna do in this case is we wanna make an agent
that is a little bit more polished.
And so for this, we actually just update our system problems.
So instead of just having like, oh, you are a slide generation
agent, make a slide deck, we now give it a little bit more
information of what are the expectations that we have of you
in terms of typography.
Because as we know this, we said, oh, the font is too small,
there's too many words on there, it's not readable,
or it's too big.
So we give it a little bit more information.
So we say slide title should be this size, section header
should be this size, body this size, caption this size.
And we also gave it some information on the layout
and density, like the things that we expect
from the layout and density point of view.
For example, we say keep the body text on size,
leave braiding room, and left aligned paragraphs.
And then also, I think everyone kind of,
I mean, I am at least getting ticked off.
Like if I read something that's clearly AI written,
I'm always a little bit skeptical of
if I can completely trust the content,
even if the person sending me these texts has Reddit himself or themselves and is standing
behind that content. We also say avoid these AI generated tells as well. Never use the
DIN accent lines and titles and don't pepper slide with emojis as decorative icons. This
is based on the things that we have seen in our e-mail. We have looked at the slide deck
we're like, oh, this is not properly done.
These fonts are a little bit off.
There's some emoji use in here.
It's like a little bit all over the place.
And then based on the score, we were like, OK,
these are the things that were clearly failing it.
So we have emoji count four in this case, small font slides
also for as well, cluttered slides too,
and text heavy slides.
So based on the information that we have gotten from the Eval
that we have run, we have made these changes
to our new agents.
Let me now pull up the result of the new agent
that we have created in this case, right?
So this is slide one, which I think is immediately
way more enjoyable to look at,
like there's no overlapping stuff,
there's no dollar sign, that's just generally it's cleaner.
This once again, I think this one still has
like quite small text, but at least once again,
we're like getting a little bit more consistent
with the coloring as well.
Once again, like the whole slide deck is more consistent.
the third slide, the fourth slide, and the fifth slide.
And this is just by basically identifying,
here's a few failure modes of our original one.
Here's how we now make changes based
on these things that we found in the system prompt,
and now we run it back.
And now once again, we can do the same thing.
So we're now basically in this loop
of finding what's wrong, iterating, finding what's wrong,
running it again, and making improvements over time.
So now we can take a look back at what we find over here.
Oh, and this is actually way worse,
suddenly we see like emoji count 20.
I'm wondering where they are.
I haven't seen them actually.
I'm wondering where that is at.
I wonder if it's like a mistake in this case.
But generally we see like, okay, small font slides,
we've seen that, but we've improved upon the cluttering.
And let's see, text heavy, is that still the case?
I think that's fine.
I mean, those are a little bit text heavy,
but I think it's acceptable, right?
So now we're like, so this once again shows the value
of like human review as well, right?
Because now we see, oh, these things that we have defined
in our evals are maybe not as well defined
as we hoped them to be, right?
Because now I'm here arguing like,
oh, this is not as text heavy as I expected it to be, right?
So that means that something is actually wrong
with the way we're grading.
So now we go back then, we would go back,
go to our creator, change the creator,
updated and make sure they did better reflects the actual thing that we want to measure.
And this is also not something to be underestimated.
Like this calibration of how your agent should behave and how your judges should judge the
specific output is really something very fickle.
You should spend proper time trying to find the ways on how you should make this happen.
Let's say now that we want to have an agent.
I think with this one, I mean, it's fun.
I think it's nice.
but it's still quite text heavy and it's only text, right?
Let's say now that we want to have an agent.
Let's say that's one of our requirements, right?
That we have an agent that we always want to have
include diagrams.
Once again, we go back to our system prompt,
we update it, and we now say every slide must include
at least one generated diagram or charts
inserted as an actual image, right?
So once again, we update the system prompt
or any part of the agent that you can tune,
And then we go again and we check what do we get.
Okay, so this one is quite interesting.
I guess personally I'm not a fan of having
an image on the opening slide,
but once again it is what we define that it should do.
So I'm gonna let the slide.
But it's a nice graph, what it's saying,
it's like no negotiation and active negotiation.
So it's arguing that if you do active negotiation
for your salary, you can see over time
the gap widens between no negotiation
and yes, no negotiation.
some extra benchmarks.
I think this looks immediately way better
just in the way it is,
kind of grounded into some actual facts right now
instead of just waffling its way through the slide deck.
Yeah, this one, I'm not a big fan of it.
I feel like it's a little bit stretched,
but that might also just be the screenshot.
Yeah, and this one also not the best one either, right?
Let me see what the score to Jason now says, okay?
No emojis, great, no cluttered slides.
Still quite text heavy slides, surprisingly.
Still small font slides, I think that's fine.
I think we just say like with images, I think.
Yeah, I think we accept like these types of things are fine.
So once again, shows you some questions
regarding the greater that we've said.
But now we can also take a look at like the judges, right?
Like for example, because now we have images
that we have created, so now we can also consider
how does the image judge think this is.
And it says it's 3.8 out of 5.
Doesn't give us a lot to go of, right?
It just gives us a random number.
What does this mean?
How can we improve upon this?
But that's fine for now.
Now, one thing that we always see that works just generally
quite well, and that's like it's transversal over every single
use case is adding a QA loop, right?
For coding, this is quite intuitive.
That's basically saying you create an agent that actually
is writing the code, right?
And then you add a second agent that is then looking
at the code that has been written and just criticizes it.
So it's basically saying, this is bad, this is bad,
this is bad, this introduced a bug, this introduced a bug,
this is not according to standards, whatever, right?
So it basically is criticizing the thing
that has been created.
And then that part of the feedback you give back
to your original agent, the creation agent.
The creation agent goes off again.
Does the creation, does the fine tuning,
makes the changes that were informed by the criticizing,
And then, once again, after that is done,
it goes back to the criticizing agent.
And that loop basically goes on and on and on
until both sides are like, okay, this is fine.
We can ship this.
And that's basically what we now do in this next step.
So we basically say like, okay, required QA loop.
Assume there are no problems.
Assume there are problems.
And then your job is to find them.
Approach QA as a bug hunt, not a confirmation step.
And this is quite interesting because we're like
actively instructing the agent to behave in a way adversely,
like we're saying there are issues, you need to find them.
It's not like, oh, there might be something,
you might be interested in finding something,
no, it's actively saying there are issues, go find them.
And then we say we instruct off writing the deck,
okay, convert it to images, inspect every slide,
image yourself, fix issues, re-render, re-inspect,
and then do not stop until you've completed
at least one fixed and verified cycle.
Cool. Now, as I said, I think for coding,
this is quite intuitive.
But I think it's also quite intuitive
if you take a look at the slides that we have created,
because that's basically what we did.
We have looked at the slides and we're like,
ah, this is not good.
This is not good.
Let's take that feedback, update our creators,
update our system prompt, and let's run it back again.
So let's now see if this is actually
showing some improvements.
I think this is immediately a lot better.
Also the image is way bigger now, I think it's way more readable even from a further
distance away.
Still the slides are small, but for example it's source now, there's a source over here
as well which is quite good.
I think this is also way better, it is more clean structured, I think the image is also
a little bit better as well.
A quite interesting graph in this case, your value profile versus team average.
This one is still a little off in my opinion.
So we now have like little introduction of like these
sweet ticks.
And this one is also a little bit better, I would say,
but I think like just the image taking is kind of
messing with the slide here.
And so then we kind of know the drill by now.
We take a look at the score.
We see like, has it improved?
Why do we see still gaps?
And now we see like for all of the judges that we have created
it is higher than the ones before, right?
We are now all good in the 4.2 to 4.4 now.
So we're on a good track, right?
And you can keep on doing this, you can keep on doing this.
And you will always make like these little changes,
but sometimes, and this is I guess
where it gets quite interesting and more like nuanced,
is you can also just go to a smarter model, right?
Because like now you're like defining,
oh, this is what a good slide should look like,
this is what it should do, this is what it should not do.
But with these models getting smarter and better over time,
you kind of expect them to be able to figure that out
on their own, right?
I mean, that would at least be nice.
So that's why we tried it out as well.
So now in the last one, we basically just
changed our model to Opus 47 instead of Sonnet 47,
which we have used up to these points, if you can.
46.
So now we have switched to Opus 47.
And we have basically just given it a simple prompt again.
Like you are a slide generation agent.
And then when the user gives you a topic,
create a PowerPoint file at whatever,
and then you have a shell.
So it's basically just the initial prompt
that we gave to our sonnet model in the beginning, right?
And then once again, let's now consider taking a look
at the results of those.
And this is just a base prompt, right?
Like you can immediately see like it's
significantly better than the sonnet one, right?
I think there's still clear issues that we can iron out,
but generally, it's way more structured.
And then we can take a look at the score as well.
And I think this is quite interesting and quite telling.
For example, Opus just does not use any emojis.
Like it kind of knows, if you wanna make a slide deck
about salary increase, emojis are probably not
the right place to put them.
It also has few small font slides
because it has this innate knowledge of,
okay, it should be readable.
This is how a slide deck should function.
This is what people expect out of a slide deck.
And then we get to these judge graders.
We see a 5 for the image judge.
Do we even have an image in this one?
I don't think we do, actually.
No, we don't.
OK, but once again, we got a 5 in this one.
Layout judge 4.2, and then a color judge 4.8,
entitled body coherence 4.4.
So this is immediately giving extremely high scores as well,
which I think is quite interesting, because this is,
once again showing that we might not be measuring the right thing.
And this is not too unexpected for these types of creators,
or for these judge creators.
I think one of these things would like,
OK, let's go to the code creators.
I think those are quite straightforward.
I think most people in the room would have understood by now
like how they work and what we can do with them.
Like for example, emoji count, it's quite simple.
Just count the number of emojis, and that's it.
But with this judging, what we have done here
is actually quite problematic.
We basically say like give a score from zero to five.
And for text, the title should be simple and clear
to indicate the main point for make on
that avoid too many text and keep words.
But it has nothing to anchor on, right?
Like it doesn't really know what good looks like in this case.
It doesn't know what bad looks like.
So there's still like this trade off
between like what does a model actually know
And what do we need to give more information
on to the model to make sure that it can give
like a proper judging of what we actually have produced.
Right?
So for example, in this case, I would for example,
say what could help is say like,
oh, this is a bad example.
Like let's say you have a zero,
like everything is just awful.
These are some telltale signs that you're dealing
with an extremely badly pre-formatted slide deck.
And then over time, the different ranges
you can express.
And then once over time, once again,
that doesn't mean it will still be able to give a good answer.
Because we now have these results.
We have this number that our LLM decided
to output for some reason.
Like, for example, in this case, image just put out 5.
OK, what do we do with that number now?
OK, it's a 5.
We just said there was not a single image in the slide deck.
So how can we interpret this five?
One way of doing this is just basically always
asking your judge graders to give reasons why
it came to that conclusion.
And one thing that should be very cautious about
is the ordering.
I've had it happen where I was setting this up,
and I did this exact thing.
So I had the number, and then I said, OK, give me all the reasons
why you did that.
And so then it said, oh, it's a four.
And the reasons for this are this, this, and this.
But we know that in LLM, it works auto-regressively.
So if it is anchored on this four,
it will do anything it can to argue why it should be a four,
anything.
And even if it's extremely bad, if it should be a one,
it will still say, oh, it is good for these and these reasons.
Because it needs to justify the four that it put out.
So once how you do it is you actually turn it around.
So first you say, give me a bunch of reasons, give me pros,
give me cons, give me reasons why it should be high,
give me reasons why it should be bad.
And then based on all of those reasons together,
then you need to make a final decision on the output.
And that goes also back to this QA loop as well,
because then once again, you can get a little bit tricky here
where you have multiple agents also doing the verification
part, where you have one agent that is finding all of the issues.
And then the other one is refuting those, for example.
One example that I can give, which I think is quite interesting,
let's say you want to make a document for,
where you need to like some analysis,
you first need to get a lot of context
from the internet, for example,
like on the legal document, for example, right?
And you ask the, you ask a model to like make a summary of
a certain case, what was decided,
what does this have for legal implications
for all the cases, right?
You need to be very careful with like all of these things
that like legal cases are generally like quite tricky.
And an agent would love to create like, oh, this and this
and jump to complete like, this is reason and that's it.
And then the grader might be like, oh, this is unclear.
This is maybe not as, this is maybe untrue.
This is maybe like glossing over the actual facts,
all of those type of things.
But then once again, you can apply these multiple techniques.
You can have multiple graders, for example,
seeing like evaluating those and seeing like,
what are the main ones popping up?
Because once again, a grader might still hallucinate things as well,
especially in these very nuanced scenarios.
So there's different ways of how you then
can work with these judges to make sure that you actually
get good consistent output that is actionable.
And what I've shown you here today
is basically just a small introduction to how evils can help you.
But it's definitely not the end.
I think 45 minutes for a session on evils
is, in my opinion, quite short.
because it can get really deep, right?
Because I started this session with talking about benchmarks,
which are, in the end, just evals.
And every single time, why would every single model provider
cast so much about benchmarks, so much about evals
if it wasn't one of the main important things
when we are building new models, right?
Exactly. We need to find the things that we are failing at.
Exactly. We need to find things, what are we good at?
What are we bad at?
How can we make the model better in future generations?
And that's the same thing when building applications
that are consisting, that's using AI agents, right?
It's the same thing.
It's just finding what works, finding what doesn't,
iterating, and making sure that the changes that you're making,
that you're informed on the decisions that you are making,
and making sure that the changes you make
have actually positive influence on your final output.
OK.
Thank you guys so much.
This is all the time that I have.
Thank you guys.
You