> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
यह विनिर्देश ग्राफआरएजी और डॉक्यूमेंटआरएजी सेवाओं में स्ट्रीमिंग सपोर्ट जोड़ने का वर्णन करता है, जो नॉलेज ग्राफ और डॉक्यूमेंट रिट्रीवल क्वेरी के लिए वास्तविक समय में टोकन-दर-टोकन प्रतिक्रियाएं सक्षम करता है। यह एलएलएम टेक्स्ट-कंप्लीशन, प्रॉम्प्ट और एजेंट सेवाओं के लिए पहले से लागू किए गए मौजूदा स्ट्रीमिंग आर्किटेक्चर का विस्तार करता है।
## लक्ष्य
**संगत स्ट्रीमिंग यूएक्स**: सभी ट्रस्टग्राफ सेवाओं में समान स्ट्रीमिंग अनुभव प्रदान करें।
**न्यूनतम एपीआई परिवर्तन**: एक ही `streaming` फ़्लैग के साथ स्ट्रीमिंग सपोर्ट जोड़ें, स्थापित पैटर्न का पालन करें।
**पिछड़ा संगतता**: मौजूदा गैर-स्ट्रीमिंग व्यवहार को डिफ़ॉल्ट के रूप में बनाए रखें।
**मौजूदा बुनियादी ढांचे का पुन: उपयोग**: पहले से लागू प्रॉम्प्टक्लाइंट स्ट्रीमिंग का लाभ उठाएं।
**गेटवे सपोर्ट**: क्लाइंट एप्लिकेशन के लिए वेबसॉकेट गेटवे के माध्यम से स्ट्रीमिंग सक्षम करें।
## पृष्ठभूमि
वर्तमान में लागू की गई स्ट्रीमिंग सेवाएं:
**एलएलएम टेक्स्ट-कंप्लीशन सेवा**: चरण 1 - एलएलएम प्रदाताओं से स्ट्रीमिंग।
**प्रॉम्प्ट सेवा**: चरण 2 - प्रॉम्प्ट टेम्प्लेट के माध्यम से स्ट्रीमिंग।
**एजेंट सेवा**: चरण 3-4 - इंक्रीमेंटल थॉट/ऑब्जर्वेशन/एन्सर चंक्स के साथ रीएक्ट प्रतिक्रियाओं को स्ट्रीमिंग करना।
आरएजी सेवाओं के लिए वर्तमान सीमाएं:
ग्राफआरएजी और डॉक्यूमेंटआरएजी केवल ब्लॉकिंग प्रतिक्रियाओं का समर्थन करते हैं।
उपयोगकर्ताओं को किसी भी आउटपुट को देखने से पहले एलएलएम प्रतिक्रिया पूरी होने तक इंतजार करना होगा।
नॉलेज ग्राफ या डॉक्यूमेंट क्वेरी से लंबी प्रतिक्रियाओं के लिए खराब यूएक्स।
अन्य ट्रस्टग्राफ सेवाओं की तुलना में असंगत अनुभव।
यह विनिर्देश ग्राफआरएजी और डॉक्यूमेंटआरएजी में स्ट्रीमिंग सपोर्ट जोड़कर इन कमियों को दूर करता है। टोकन-दर-टोकन प्रतिक्रियाओं को सक्षम करके, ट्रस्टग्राफ:
सभी क्वेरी प्रकारों में संगत स्ट्रीमिंग यूएक्स प्रदान कर सकता है।
आरएजी क्वेरी के लिए कथित विलंबता को कम कर सकता है।
लंबी अवधि की क्वेरी के लिए बेहतर प्रगति प्रतिक्रिया प्रदान कर सकता है।
क्लाइंट एप्लिकेशन में वास्तविक समय प्रदर्शन का समर्थन कर सकता है।
## तकनीकी डिजाइन
### आर्किटेक्चर
आरएजी स्ट्रीमिंग कार्यान्वयन मौजूदा बुनियादी ढांचे का लाभ उठाता है:
1.**प्रॉम्प्टक्लाइंट स्ट्रीमिंग** (पहले से लागू)
`kg_prompt()` और `document_prompt()` पहले से ही `streaming` और `chunk_callback` पैरामीटर स्वीकार करते हैं।
ये आंतरिक रूप से स्ट्रीमिंग सपोर्ट के साथ `prompt()` को कॉल करते हैं।
1. स्कीमा फ़ील्ड जोड़ें (RAG सेवाओं दोनों के लिए अनुरोध + प्रतिक्रिया)
2. GraphRag.query() और DocumentRag.query() विधियों को अपडेट करें
3. प्रोसेसर को स्ट्रीमिंग को संभालने के लिए अपडेट करें
4. गेटवे डिस्पैच हैंडलर को अपडेट करें
5.`--no-streaming` ध्वज `tg-invoke-graph-rag` और `tg-invoke-document-rag` में जोड़ें (डिफ़ॉल्ट रूप से स्ट्रीमिंग सक्षम, एजेंट CLI पैटर्न का अनुसरण करते हुए)
**कॉलबैक पैटर्न**:
एजेंट स्ट्रीमिंग में स्थापित समान एसिंक्रोनस कॉल बैक पैटर्न का पालन करें:
प्रोसेसर `async def send_chunk(chunk)` कॉल बैक को परिभाषित करता है
कॉल बैक को RAG सेवा को पास करता है
RAG सेवा कॉल बैक को PromptClient को पास करती है
PromptClient प्रत्येक LLM टुकड़े के लिए कॉल बैक को लागू करता है
प्रोसेसर प्रत्येक टुकड़े के लिए स्ट्रीमिंग प्रतिक्रिया संदेश भेजता है
**त्रुटि प्रबंधन**:
स्ट्रीमिंग के दौरान होने वाली त्रुटियों को `end_of_stream=True` के साथ त्रुटि प्रतिक्रिया भेजनी चाहिए
एजेंट स्ट्रीमिंग से मौजूदा त्रुटि प्रसार पैटर्न का पालन करें
## सुरक्षा संबंधी विचार
मौजूदा RAG सेवाओं से परे कोई नया सुरक्षा संबंधी विचार नहीं:
स्ट्रीमिंग प्रतिक्रियाएं समान उपयोगकर्ता/संग्रह अलगाव का उपयोग करती हैं
प्रमाणीकरण या प्राधिकरण में कोई बदलाव नहीं
टुकड़े की सीमाएं संवेदनशील डेटा को उजागर नहीं करती हैं
## प्रदर्शन संबंधी विचार
**लाभ**:
कथित विलंबता में कमी (पहले टोकन तेजी से आते हैं)
लंबे उत्तरों के लिए बेहतर UX
कम मेमोरी उपयोग (पूरे उत्तर को बफर करने की आवश्यकता नहीं है)
**संभावित चिंताएं**:
स्ट्रीमिंग प्रतिक्रियाओं के लिए अधिक Pulsar संदेश
टुकड़ा करने/कॉल बैक ओवरहेड के लिए थोड़ा अधिक CPU
स्ट्रीमिंग वैकल्पिक है, डिफ़ॉल्ट गैर-स्ट्रीमिंग रहता है, जिससे इसे कम किया जा सकता है
**परीक्षण संबंधी विचार**:
बड़ी नॉलेज ग्राफ (कई त्रिगुण) के साथ परीक्षण करें
कई पुनर्प्राप्त दस्तावेज़ों के साथ परीक्षण करें
स्ट्रीमिंग बनाम गैर-स्ट्रीमिंग के ओवरहेड को मापें
## परीक्षण रणनीति
**इकाई परीक्षण**:
streaming=True/False के साथ GraphRag.query() का परीक्षण करें
streaming=True/False के साथ DocumentRag.query() का परीक्षण करें
कॉल बैक कार्यान्वयन को सत्यापित करने के लिए PromptClient को मॉक करें
**एकीकरण परीक्षण**:
पूर्ण GraphRAG स्ट्रीमिंग प्रवाह का परीक्षण करें (मौजूदा एजेंट स्ट्रीमिंग परीक्षणों के समान)
पूर्ण DocumentRAG स्ट्रीमिंग प्रवाह का परीक्षण करें
गेटवे स्ट्रीमिंग अग्रेषण का परीक्षण करें
CLI स्ट्रीमिंग आउटपुट का परीक्षण करें
**मैन्युअल परीक्षण**:
`tg-invoke-graph-rag -q "What is machine learning?"` (डिफ़ॉल्ट रूप से स्ट्रीमिंग)
`tg-invoke-document-rag -q "Summarize the documents about AI"` (डिफ़ॉल्ट रूप से स्ट्रीमिंग)
`tg-invoke-graph-rag --no-streaming -q "..."` (गैर-स्ट्रीमिंग मोड का परीक्षण करें)
सत्यापित करें कि स्ट्रीमिंग मोड में वृद्धिशील आउटपुट दिखाई दे रहा है
## माइग्रेशन योजना
माइग्रेशन की आवश्यकता नहीं:
`streaming` पैरामीटर (डिफ़ॉल्ट रूप से False) के माध्यम से स्ट्रीमिंग वैकल्पिक है
मौजूदा क्लाइंट अपरिवर्तित रहते हैं
नए क्लाइंट स्ट्रीमिंग को अपना सकते हैं
## समयरेखा
अनुमानित कार्यान्वयन: 4-6 घंटे
चरण 1 (2 घंटे): GraphRAG स्ट्रीमिंग समर्थन
चरण 2 (2 घंटे): DocumentRAG स्ट्रीमिंग समर्थन
चरण 3 (1-2 घंटे): गेटवे अपडेट और CLI ध्वज
परीक्षण: प्रत्येक चरण में शामिल
## खुले प्रश्न
क्या हमें NLP क्वेरी सेवा में भी स्ट्रीमिंग समर्थन जोड़ना चाहिए?
क्या हम केवल LLM आउटपुट या मध्यवर्ती चरणों (जैसे, "इकाइयों को पुनर्प्राप्त करना...", "ग्राफ को क्वेरी करना...") को स्ट्रीम करना चाहते हैं?
क्या GraphRAG/DocumentRAG प्रतिक्रियाओं में टुकड़े मेटाडेटा (जैसे, टुकड़े संख्या, कुल अपेक्षित) शामिल होना चाहिए?