Learn Machine Learning and Data Analytics with Python: post #187 — TG.ME

Traditional vs. Agentic RAG, clearly explained! The future is Agentic RAG, and it's because a traditional RAG setup has some major limitations...👇 1) Retrieve once and generate once. ↳ This means if the retrieved context isn't enough or correct, the LLM can not dynamically search for more information. 2) Inability to reason through complex queries. ↳ If a query requires multiple retrieval steps or CoT (chain of thought), traditional RAG falls short. 3) Limited adaptability ↳ The system can't modify its strategy based on the problem at hand. Eg. Whether to do vector search, web search or call an API. Agentic RAG addresses these issues. The core idea is to introduce agentic behaviors at each stage of RAG. Agents can actively think through tasks—planning, adapting, and iterating to find the best solution, rather than just following a set of instructions, and LLMs enable this. The image below illustrates the workflow of an agentic RAG. Refer to it as you continue reading... Steps 1-2) The user inputs a query, and an agent refines it (corrects spelling, simplifies for embedding, etc.) Step 3) Another agent decides if more details are needed. ↳ Step 4) If not, the refined query is sent to the LLM. ↳ Steps 5-8) If yes, the agent selects the relevant sources (vector database, tools/APIs, internet), retrieves context, and sends it to the LLM. Step 9) A response is generated. Step 10) A final agent checks if the answer is relevant. ↳ Step 11) If yes, return the response. ↳ Step 12) If no, restart from Step 1. This process repeats until the system provides an acceptable answer or concedes it cannot respond. This makes the RAG much more dynamic and robust. However, it's important to note that building RAG systems often comes down to design preferences and choices. The diagram below is just one of many blueprints an agentic RAG system may have. You can adapt it to suit your specific use case.