AWS ने Bedrock में एकल-चरणीय RAG और केवल-पुनर्प्राप्ति मोड जोड़ा

Amazon Web Services ने घोषणा की कि 9 नवंबर, 2026 से Amazon Bedrock Managed Knowledge Base एकल-चरणीय पुनर्प्राप्ति-संवर्धित जनरेशन (RAG) और केवल अंशों वाले अनुरोधों का समर्थन करता है AgenticRetrieveStreamके लिए 0–5 की विस्तारित सीमा maxAgentIteration ऐप्लिकेशन को स्रोतों की पुनर्प्राप्ति, एक खोज के बाद उत्तर या सेवा की मौजूदा बहु-चरणीय एजेंट-आधारित पुनर्प्राप्ति चुनने की सुविधा देती है।

इस अपडेट के साथ, जटिल खोजों के लिए इस्तेमाल होने वाले उसी स्ट्रीमिंग API में बुनियादी RAG पैटर्न भी उपलब्ध है—पहले एक बार पुनर्प्राप्ति और फिर तैयार किया गया उत्तर। एकल-चरणीय RAG में उत्तर तैयार करने के लिए फ़ाउंडेशन मॉडल को एक बार कॉल किया जाता है, जबकि केवल-पुनर्प्राप्ति अनुरोधों में मॉडल को कोई कॉल नहीं किया जाता। AWS का कहना है कि एजेंट-आधारित पुनर्प्राप्ति की तुलना में एकल-चरणीय संचालन से विलंबता और मॉडल का इस्तेमाल घट सकता है, लेकिन घोषणा में विलंबता या लागत की कोई मापी गई तुलना नहीं दी गई है।

एक पैरामीटर से पुनर्प्राप्ति मोड चुनें

0 का मान उत्तर तैयार किए बिना मेल खाने वाले अंश लौटाता है; 1 एक बार पुनर्प्राप्ति करता है और इसके साथ उत्तर तैयार करता है generateResponse=true; और 2 से 5 तक के मान मौजूदा एजेंट-आधारित व्यवहार को बनाए रखते हैं। हर मोड कई नॉलेज बेस का समर्थन करता है। इसलिए, एकल-चरणीय का अर्थ है एक बार पुनर्प्राप्ति—यह केवल एक नॉलेज बेस तक सीमित होने का संकेत नहीं है।

एक इटरेशन का अर्थ है फ़ाउंडेशन मॉडल को एक बार कॉल करना। उत्तर तैयार करने की सुविधा चालू होने पर, की सीमा n अंतिम कॉल उत्तर तैयार करने के लिए रखती है और अधिकतम n से 1 कम योजना-चक्रों की अनुमति देती है। हर योजना-चक्र में क्वेरी को नए सिरे से लिखना और पुनर्प्राप्ति करना शामिल होता है। शुरुआती अनुमान-आधारित पुनर्प्राप्ति योजना बनाने से पहले होती है और इसकी गिनती सीमा में कभी नहीं होती।

मान 0 होने पर उत्तर तैयार करने की सुविधा बंद होनी चाहिए। इसे चालू करने पर 4xx त्रुटि आती है, क्योंकि उत्तर के लिए मॉडल को कॉल करना आवश्यक है। मान 1 होने पर स्ट्रीम में पुनर्प्राप्ति और स्रोतों पर आधारित एक उत्तर शामिल होता है, लेकिन योजना-चरण के ट्रेस इवेंट नहीं होते। 2 से 5 तक के मान इस्तेमाल करने वाले मौजूदा अनुरोधों में कोई बदलाव नहीं होता।

स्ट्रीमिंग का व्यवहार और संचालन संबंधी सीमाएँ

AgenticRetrieveStream API का संदर्भ बताता है कि messages, retrievers, और agenticRetrieveConfiguration अनुरोध में देना अनिवार्य है, जबकि generateResponse वैकल्पिक है। उत्तर तैयार करने की सुविधा चालू होने पर ही तैयार उत्तर के अंश भेजे जाते हैं। अंतिम परिणाम में पुनर्प्राप्त सामग्री, संश्लेषित उत्तर और ऐसे उद्धरण हो सकते हैं जो उत्तर के अंशों को सहायक नतीजों से जोड़ते हैं।

केवल-पुनर्प्राप्ति संचालन सीधे कॉल करने के बराबर है Retrieve लेकिन इसका जवाबी प्रारूप अलग होता है: अंश स्ट्रीम के result इवेंट में दिखाई देते हैं, लेकिन इसमें score या location फ़ील्ड शामिल नहीं होते। पहले से इस्तेमाल करने वाले ऐप्लिकेशन AgenticRetrieveStream इसलिए पा सकते हैं Retrieveजैसा व्यवहार—इसके लिए अलग API को जोड़ने के बजाय केवल एक पैरामीटर बदलना होता है।

जटिल सवालों के लिए, Amazon Bedrock उपयोगकर्ता मार्गदर्शिका ऐसी कार्यप्रणाली बताती है जिसमें क्वेरी को उप-क्वेरी में बाँटा जाता है, यह जाँचा जाता है कि पुनर्प्राप्त साक्ष्य पर्याप्त हैं या नहीं, अतिरिक्त खोजें की जाती हैं और ज़रूरत पड़ने पर पूरा दस्तावेज़ शामिल किया जा सकता है। एजेंट-आधारित पुनर्प्राप्ति केवल पूरी तरह प्रबंधित Bedrock नॉलेज बेस का समर्थन करती है और हर अनुरोध में अधिकतम पाँच रिट्रीवर की अनुमति देती है। इटरेशन की अधिकतम सीमा घटाने से एजेंट पहले रुक सकता है और जटिल सवालों पर सटीकता संभावित रूप से कम हो सकती है।

ऐप्लिकेशन टीमें मोड चुनकर उसकी जाँच करती हैं

AWS इन सेटिंगों को एक काल्पनिक बैंक के आंतरिक नीति सहायक के उदाहरण से समझाता है; यह किसी ग्राहक के तैनात सिस्टम का उदाहरण नहीं है। एकल स्वामित्व वाले व्यवसाय के दस्तावेज़ों से जुड़ा सवाल इस्तेमाल करता है maxAgentIteration=1, जबकि एकल स्वामित्व वाले व्यवसाय और LLC की आवश्यकताओं की तुलना करने वाला सवाल, जिसमें अनिवासी मालिकों पर लागू नियमों की जाँच भी शामिल है, 4 का इस्तेमाल करता है और अधिकतम तीन योजना-चक्रों की अनुमति देता है। नीति की भाषा देखने का अनुरोध 0 का इस्तेमाल करता है और बिना सारांश के स्रोत-अंश लौटाता है।

मोड का चयन ऐप्लिकेशन को करना होता है; maxAgentIteration अनुरोधों को अपने-आप अलग-अलग मार्गों पर नहीं भेजता। उदाहरण वाला सहायक नीतियों की जानकारी खोजने और उनकी तुलना करने में मदद करता है, लेकिन न तो खातों को मंज़ूरी देता है और न ही बैंक की समीक्षा और प्राधिकरण प्रक्रिया की जगह लेता है।

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

इस बदलाव से पुनर्प्राप्ति की गहराई हर अनुरोध के लिए तय किया जाने वाला एक स्पष्ट इन्फ्रास्ट्रक्चर विकल्प बन जाती है। सीधे जानकारी खोजने वाले अनुरोधों में योजना बनाने के लिए मॉडल को कॉल करने से बचा जा सकता है, जबकि जटिल क्वेरी में साक्ष्य जुटाने की पुनरावृत्त प्रक्रिया जारी रहती है। उद्यमों के लिए मुख्य सवाल यह है कि क्या मॉडल का कम इस्तेमाल करने पर भी उनके अपने दस्तावेज़ों के आधार पर पूरे और समर्थित उत्तर मिलते हैं—इसके बजाय यह मान लेने के कि इटरेशन की अधिक सीमा हमेशा बेहतर होती है।