Let's see the same example as we just
saw with searching using RAG, but in a
slightly different manner.
So let's just run it first, and then
we will talk about it.
So in this case, I'm going to say
hello to it.
It just comes back and says hello.
It doesn't do a search, and that's because
I put the search as a tool now,
so only when we search for something, it
will go and do the search on the
fly and give us the answer back.
So the way this is done is we
have exactly the same as we had before.
That has not changed, but we have defined
a search tool down here, and we have
moved all the search we put in here
before out into the search tool.
So now I have a search tool with
an input, and just making the most similarity
knowledge that we just return from the search
tool instead of giving it into the messages.
And then we have given this the tool
of being able to search the knowledge, and
we have instructed it to use that tool.
This has benefits and drawbacks.
So one of the benefits is if we
ask nothing about the knowledge base, we don't
spend tokens answering back.
So the pleasantries here for hello doesn't cost
us extra.
But if you have a very weak model,
or if you ask in a slightly awkward
way, like for example, what is the Wi
-Fi?
You can now see that it doesn't really
understand that it needs to call the tool.
So the risk you're doing here is that
you end up not calling the tool.
And we can begin to prompt our way
out of that, and we can say always
use the search tool.
But if we do that, what is the
Wi-Fi?
It now knows that it needs to do
that.
But if we say hello, it also searches
now because it's now been told that it
always needs to use the tool.
So the best way here is to begin
to go up in models in terms of
them being more intelligent to follow these rules.
So for example, a Chat GPT 4.1
is better at calling the tools and understanding
when to call them and when to not.
So is the Wi-Fi?
Where the other one just asked what is
Wi-Fi or just give an explanation of
what is Wi-Fi in general.
This one is intelligent enough to know, hey,
they're talking about what is the Wi-Fi
at the office or what is the Wi
-Fi in general I probably need to search.
So it's all a balancing.
If you put them up front like we
did in the previous one, you are ensured
that it will always search no matter what.
And in real life scenarios, I do that
at many cases where I know it's not
too expensive to do the search.
But if I know that it's expensive to
do the search, I tend to put it
out in the tool.
Again, also if the real life scenario is
that sometimes this chatbot can actually answer all
kinds of things with other questions like not
the internal knowledge base, but also some support
cases or customer information and so on, then
it's better to have as a tool and
let the AI choose, oh, this is an
internal question about knowledge.
Let me run it.
Oh, it's not about that, then let's not
do it as a tool.
But again, we need to go up in
models in order for it to be a
bit more reliant.
So that is actually everything there is about
making this into a tool.
So nothing special in terms of tool calling,
just like we saw in the section about
that.
The only difference is that now we're just
using RAC inside the tool to get the
data.
So that's everything.