𝗜𝗻 𝗮 𝗹𝗼𝗻𝗴-𝗿𝘂𝗻𝗻𝗶𝗻𝗴 𝗥𝗔𝗚 𝘀𝘆𝘀𝘁𝗲𝗺, 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗱𝗮𝗻𝗴𝗲𝗿𝗼𝘂𝘀 𝗯𝘂𝗴 ...

In a long-running RAG system, the most dangerous bug isn't a single wrong answer. It's the one that snowballs: retrieved again and again, reinforced each time, until the system treats it as fact. It's easy to miss: the model generates from a bad retrieval → no one corrects it, so the system assumes it's right → it gets written back to memory → the next query pulls it up again and reinforces the error. CRAG (Corrective RAG) breaks this loop. It adds one step between retrieval and generation: evaluation. A lightweight evaluator judges whether each retrieved document actually answers the question and tags it with a confidence score, stored alongside the memory. The evaluator sorts results into three tiers:

• 0.9 → correct: refine and use
• 0.5–0.9 → ambiguous: add a web search
• <0.5 → wrong: discard and search instead

On the next retrieval, the system pre-filters first, keeping only entries above 0.7. Weak content gets screened out before it's reused, so it never re-enters the store → retrieve → reinforce loop. CRAG needs a vector database that can store confidence scores dynamically, run hybrid retrieval, and isolate tenants. Milvus supports JSON metadata filtering, hybrid retrieval, and Partition Key out of the box, which is exactly what CRAG needs. Learn how to set up CRAG: milvus.io/blog/fix-rag-r#RAG#VectorDatabase#Milvus#LLM#AIEngineering