-: Hey there, Eden here.
And up until now, we saw two ways to do RAG in the course.
The first one was two-step RAG,
and this was done with the LangChain Expression Language.
And here, the retrieval
always happens before the generation,
simple and predictable.
So here we have a lot of control
of when the retrieval is going to happen.
It's not that flexible because it's always going to happen.
We're always going to retrieve the documents.
And it's really, really fast
because we don't have an LLM deciding
whether if we need to do retrieval or not.
And the second thing we saw,
queue LangChain call it agentic RAG,
but I call it a RAG agent.
So here we took our React agent
and we simply gave it a retrieval tool.
And here the LLM decided
when and how to retrieve during the reasoning process.
And here we have much less control
because we don't really control
when the retrieval is going to happen.
So it's really flexible
because the LLM decides what to do,
and the latency here in the RAG agent
is slower than the two-step RAG,
because here we have another LLM call
before we even do the retrieval.
And if we have a bunch of LLM calls and then the retrieval,
so this thing can vary here.
And there is also a hybrid architecture,
so it's going to combine elements from the agentic RAG
and the two-step RAG.
And this is actually something
I'm going to show you in the LangGraph section,
because we're going to be implementing
this kind of approach with LangGraph.
Now, the question that comes up is which approach is better?
And the answer for this question
is it depends on your use case.
However, hybrid RAG is something
which is going to combine the both of both worlds.
And from my experience working with production systems
and with customers in enterprises,
these kinds of architecture usually wins,
and it is most commonly used, at least today.
So in this hybrid RAG approach,
it's going to introduce intermediate steps
as query pre-processing,
retrieval, validation, and post-generation checks.
And these systems offer more flexibility
than the fixed pipeline
while maintaining some control over execution.
And in this approach, the benefits that we get for it
is that it has query enhancement.
So it's going to take the original query,
it's going to make it better,
so it would be better for the retrieval process.
Then after we retrieve the documents,
we are going to review them
and we're going to be validating those documents
to see that they actually mean a lot
and that they actually can answer the question
that was asked.
And thirdly, there is this answer validation
to see that there are no hallucinations
and that the answer actually answer the questions.
And you can see the architecture right over here.
And I don't want to cover it now
because we go very, very deep into this later in this course
and we see how to implement everything here
from the grounds up,
and we're going to have a very deep understanding on it.
So the short answer is that this hybrid approach,
this is actually what's currently used
in production systems for enterprises.
And this kinds of architecture is what I recommend
because it captures the both of both worlds.
The RAG agent, we saw from before, is way, way too flexible.
This here, it's way, way too flexible
because we give the LLM the entire freedom what to do.
For a lot of production application, this is not the case.
And let's talk about the use cases of RAG,
because usually we want to use it
for question-answer over documents,
over documentation, over some internal documents
or some knowledge base that we want to ground our answering.
And an agent is going to be an overkill for that.
So to summarize, this RAG agent
that we saw here and we implemented,
I don't really think it's the best solution,
and I would definitely not use it in production.