Zubnet AIसीखेंWiki › RAG
टूल्स

RAG

इसे भी कहा जाता है: रिट्रीवल-ऑगमेंटेड जनरेशन
एक तकनीक जो एआई मॉडल को प्रतिक्रिया उत्पन्न करने से पहले संबंधित दस्तावेज बरामद करके बाहरी ज्ञान के अक्सेस देती है। एक बार में केवल ट्रेनिंग के दौरान मॉडल द्वारा सीखे गए चीजों पर निर्भर नहीं करते हुए, RAG एक ज्ञान डेटाबेस की खोज करता है, संबंधित चूने को खोजता है, और उन्हें प्रॉम्प्ट में संदर्भ के रूप में शामिल करता है।

यह क्यों मायने रखता है

RAG दो प्रमुख समस्याओं को हल करता है: हैल्यूसिनेशन (मॉडल के पास संदर्भ के लिए वास्तविक स्रोत होते हैं) और ज्ञान कट-अॉफ (ज्ञान डेटाबेस को पुनः प्रशिक्षण के बिना अपडेट किया जा सकता है)। यह वास्तव में अधिकांश उद्यम एआई के काम करने के तरीका है।

गहन अध्ययन

एक RAG pipeline के तीन चरण हैं: indexing, retrieval, और generation। indexing के दौरान, आप अपने दस्तावेज़ — PDFs, web pages, डेटाबेस records, जो भी हो — लेते हैं, उन्हें chunks में विभाजित करते हैं, हर chunk को एक embedding मॉडल के माध्यम से चलाते हैं ताकि एक vector मिले, और उन vectors को Qdrant, Pinecone, या Weaviate जैसे एक vector डेटाबेस में संग्रहीत करते हैं। retrieval के दौरान, उपयोगकर्ता की query को उसी मॉडल के साथ embed किया जाता है, और vector डेटाबेस top-k सबसे समान chunks (आम तौर पर 3–10) लौटाता है। generation के दौरान, उन chunks को context के रूप में मॉडल के prompt में ठूँसा जाता है, और मॉडल उस सामग्री में grounded एक प्रतिक्रिया उत्पन्न करता है। पूरा round trip — query को embed करें, search करें, prompt को इकट्ठा करें, generate करें — आम तौर पर 1–3 सेकंड लेता है।

Chunking समस्या

Chunking वह जगह है जहाँ अधिकांश RAG सिस्टम सफल या विफल होते हैं, और यह जितना दिखता है उससे अधिक सूक्ष्म है। chunks को बहुत छोटा split करें और आप context खो देते हैं; बहुत बड़ा और आप अप्रासंगिक टेक्स्ट पर क़ीमती context window space बर्बाद करते हैं। एक सामान्य शुरुआती बिंदु प्रति chunk 500–1000 tokens है जिसमें adjacent chunks के बीच 10–20% overlap है (ताकि आप उस जानकारी को न खोएँ जो एक सीमा को पार करती है)। लेकिन naive fixed-size chunking अक्सर वाक्यों को आधा काट देता है या एक heading को इसकी सामग्री से अलग कर देता है। अधिक परिष्कृत दृष्टिकोण self-contained और सार्थक chunks बनाने के लिए दस्तावेज़ संरचना का उपयोग करते हैं — headings, paragraph breaks, या semantic shifts पर splitting। LangChain का RecursiveCharacterTextSplitter और LlamaIndex का SentenceSplitter दोनों इसे संभालने का प्रयास करते हैं, लेकिन सबसे अच्छे परिणाम आम तौर पर अपने विशिष्ट दस्तावेज़ों को समझने और custom splitting logic लिखने से आते हैं।

Vector search से परे

Retrieval step में लोगों के एहसास से अधिक विकल्प हैं। शुद्ध vector similarity search (embedding space में nearest-neighbor lookup) default है, लेकिन यह सटीक keyword matches, proper nouns, और कोड identifiers के साथ संघर्ष करता है। यही कारण है कि hybrid search production सिस्टमों में मानक बन गया है: आप एक vector search और एक पारंपरिक keyword search (BM25) दोनों चलाते हैं, फिर reciprocal rank fusion या एक सीखे गए re-ranker का उपयोग करके परिणामों को संयोजित करते हैं। Qdrant, Weaviate, और Elasticsearch सभी natively hybrid search का समर्थन करते हैं। Re-ranking — retrieval से top 20–50 परिणाम लेना और उन्हें cross-encoder मॉडल के साथ score करना — latency जोड़ता है लेकिन प्रासंगिकता को नाटकीय रूप से बेहतर करता है। Cohere Rerank और Hugging Face से cross-encoder मॉडल यहाँ आम विकल्प हैं।

यह hallucination को नहीं मारेगा

एक आम भ्रम यह है कि RAG hallucination को समाप्त करता है। यह इसे महत्वपूर्ण रूप से कम करता है, लेकिन एक मॉडल अभी भी ऐसे विवरणों को hallucinate कर सकता है जो retrieved chunks में नहीं हैं, विशेष रूप से यदि chunks query का सीधे उत्तर देने के बजाय tangentially संबंधित हैं। अच्छे RAG सिस्टम इसे prompt निर्देशों में source citations शामिल करके ("केवल प्रदान किए गए context के आधार पर उत्तर दें, अपने sources cite करें"), low-relevance chunks को filter करके (हमेशा top-k लौटाने के बजाय एक न्यूनतम similarity threshold सेट करना), और मॉडल को "मेरे पास पर्याप्त जानकारी नहीं है" कहने देकर कम करते हैं जब retrieved context वास्तव में प्रश्न का उत्तर नहीं देता। कुछ टीमें एक सत्यापन step जोड़ती हैं जहाँ एक दूसरा मॉडल call जाँच करता है कि क्या प्रतिक्रिया वास्तव में sources द्वारा समर्थित है।

आगे का रास्ता

RAG को 2020 में Facebook AI Research (अब Meta AI) के एक paper में पेश किया गया था, लेकिन यह 2023 तक एक mainstream production pattern नहीं बना जब vector databases और embedding APIs इसे व्यावहारिक बनाने के लिए पर्याप्त रूप से परिपक्व हुए। तब से pattern कई दिशाओं में विकसित हुआ है: GraphRAG relational प्रश्नों के बेहतर handling के लिए vector search के बजाय (या साथ में) knowledge graphs का उपयोग करता है। Agentic RAG मॉडल को queries को reformulate करने, कई sources search करने, और एक एकल search करने के बजाय retrieval पर iterate करने की क्षमता देता है। और context-window विस्तार — मॉडल अब 100k+ tokens संभालते हैं — ने कुछ टीमों को छोटे ज्ञान आधारों के लिए RAG को पूरी तरह से छोड़ने का नेतृत्व किया है, बस सब कुछ prompt में ठूँसते हुए। वह दृष्टिकोण कुछ सौ पृष्ठों के docs के लिए काम करता है लेकिन scale पर टूट जाता है, जहाँ RAG आवश्यक बना रहता है।

संबंधित अवधारणाएँ

← सभी शब्द
← क्वांटाइज़ेशन RLHF →
ESC