ClawAI कैसे बना है
अठारह स्वतंत्र रूप से परिनियोजित होने वाली सेवाएँ, हर एक का अपना डेटाबेस, एक इवेंट-संचालित रीढ़ के माध्यम से समन्वित। उत्तर बनते ही स्ट्रीम होते हैं, और हर परत स्वतंत्र रूप से सुरक्षित है।
अंतिम बार समीक्षित 2026-07-25
ClawAI कैसे बना है
ClawAI एक ही रिवर्स प्रॉक्सी के पीछे अठारह स्वतंत्र रूप से परिनियोजित होने वाली सेवाएँ हैं। ऑथेंटिकेशन, चैट, राउटिंग, कनेक्टर, मेमोरी, फ़ाइलें, रिसर्च, वर्कस्पेस, इमेज जनरेशन, दस्तावेज़ निर्यात, बिलिंग, ऑडिट और लॉगिंग — हर एक अपनी खुद की प्रक्रिया के रूप में अपने खुद के डेटाबेस के साथ चलती है। वेब ऐप इन सबतक एक ही एपीआई सतह से पहुँचता है।
इसकी वजह है समावेशन। एक धीमा प्रोवाइडर, एक अटकी हुई फ़ाइल कन्वर्ज़न या एक विफल निर्यात चैट को अपने साथ नीचे नहीं गिरा सकता, क्योंकि वे कोई प्रक्रिया, कोई कनेक्शन पूल और कोई डेटाबेस साझा नहीं करते। हर सेवा अपने आप परिनियोजित, स्केल और रोलबैक होती है।
- 18
- स्वतंत्र रूप से परिनियोजित होने वाली सेवाएँ
- प्रति सेवा एक
- कभी कोई साझा डेटाबेस नहीं
- HTTP + इवेंट
- सिंक्रोनस कॉल के साथ एक असिंक्रोनस इवेंट बस
- एक ही प्रवेश बिंदु
- सब कुछ के आगे एक ही रिवर्स प्रॉक्सी
सेवाएँ
हर सेवा बाहर से दिलचस्प नहीं होती। ये वे सेवाएँ हैं जिन्हें एक सामान्य अनुरोध छूता है, लगभग उसी क्रम में जिसमें वह उन्हें छूता है।
- ऑथेंटिकेशनPostgreSQL
- खाते, सत्र, टोकन जारी करना और रीफ़्रेश रोटेशन, भूमिकाएँ और अनुमतियों के सेट।
- चैटPostgreSQL
- बातचीत और संदेश, कॉन्टेक्स्ट असेंबली, स्ट्रीमिंग एक्ज़ीक्यूशन और मल्टी-मॉडल ऑर्केस्ट्रेशन।
- राउटिंगPostgreSQL
- हर संदेश को वर्गीकृत करती है, सक्रिय मोड और किसी भी नीति को लागू करती है, और अपने फ़ॉलबैक चेन के साथ निर्णय दर्ज करती है।
- कनेक्टरPostgreSQL
- प्रोवाइडर क्रेडेंशियल, मॉडल कैटलॉग, क्षमता फ़्लैग और निरंतर हेल्थ जाँच।
- मेमोरी और कॉन्टेक्स्टPostgreSQL + pgvector
- मेमोरी रिकॉर्ड, सुझाव कतार, कॉन्टेक्स्ट पैक और उनके वर्ज़न, और सिमेंटिक रिट्रीवल।
- फ़ाइलेंPostgreSQL
- अपलोड, सुरक्षा स्कैनिंग, टेक्स्ट एक्सट्रैक्शन, OCR, चंकिंग और रिटेंशन।
- रिसर्चPostgreSQL
- स्रोतों वाले उत्तरों के लिए वेब खोज, पेज लाना और साक्ष्य असेंबली।
- वर्कस्पेसPostgreSQL
- बारह तीसरे-पक्ष टूल्स से OAuth कनेक्शन, वेबहुक, शेड्यूल्ड सिंक और क्रॉस-टूल खोज।
- इमेज जनरेशनPostgreSQL
- इमेज अनुरोध, प्रोवाइडर एडाप्टर और इमेज रेंडर होते समय प्रति-चरण प्रगति।
- दस्तावेज़ जनरेशनPostgreSQL
- उत्तरों को PDF, DOCX, CSV, HTML, Markdown, TXT और JSON में रेंडर करना।
- बिलिंगPostgreSQL
- प्लान, सब्सक्रिप्शन, वर्ज़न वाली कीमतें, इनवॉइस और टोकन सीमा प्रवर्तन।
- ऑडिटMongoDB
- किसने क्या किया इसका अपरिवर्तनीय रिकॉर्ड, साथ ही वह उपयोग लेजर जिससे हर टोकन सीमा का आँकड़ा निकाला जाता है।
- लॉगिंगMongoDB
- हर सेवा और ब्राउज़र से संरचित लॉग, एक रोलिंग विंडो पर सुरक्षित।
हर सेवा उसी डेटाबेस का नाम रखती है जिसकी वह मालिक है। और कुछ भी उससे नहीं जुड़ता — जिस सेवा को किसी और का डेटा चाहिए वह उसे HTTP पर माँगती है या किसी इवेंट पर प्रतिक्रिया करती है।
प्रति सेवा एक डेटाबेस
हर सेवा ठीक एक डेटाबेस की मालिक है और वही एकमात्र चीज़ है जो उससे जुड़ती है। कोई साझा स्कीमा नहीं, कोई क्रॉस-सर्विस जॉइन नहीं, और कोई रिपोर्टिंग डेटाबेस चुपचाप सबकी टेबल नहीं पढ़ता।
कीमत यह है कि कुछ सवालों के लिए एक जॉइन की बजाय दो कॉल लगते हैं। फ़ायदा यह है कि बिलिंग में एक स्कीमा बदलाव चैट को नहीं तोड़ सकता, और लॉगिंग में एक बेक़ाबू क्वेरी आपकी बातचीत जिस कनेक्शन पूल पर निर्भर है उसे खत्म नहीं कर सकती।
- कोई क्रॉस-डेटाबेस क्वेरी नहीं
- एक सेवा अपनी टेबल पढ़ती है और किसी और की नहीं। कहीं और का डेटा एक एपीआई कॉल या एक इवेंट के ज़रिए आता है।
- स्कीमा निजी हैं
- एक सेवा किसी से समन्वय किए बिना अपनी टेबल बदल सकती है, क्योंकि कोई बाहरी उपभोक्ता उनके आकार पर निर्भर नहीं है।
- माइग्रेशन प्रति सेवा चलते हैं
- हर सेवा स्टार्ट-अप पर अपना खुद का डेटाबेस माइग्रेट करती है। कोई वैश्विक माइग्रेशन नहीं है जिसका सबको इंतज़ार करना पड़े।
- विफलताएँ स्थानीय रहती हैं
- जो डेटाबेस धीमा है या अनुपलब्ध है वह पूरे उत्पाद की बजाय एक क्षमता को घटाता है।
एक अनुरोध का जीवन
भेजें दबाने और उत्तर पढ़ने के बीच क्या होता है।
अनुरोध प्रमाणित होता है
रिवर्स प्रॉक्सी इसे चैट को सौंपती है, जो आपके एक्सेस टोकन और आपकी भूमिका से जुड़ी अनुमतियों को सत्यापित करती है।
टोकन सीमा जाँची जाती है
बिलिंग पुष्टि करती है कि आपका प्लान आपके माँगे मॉडल की अनुमति देता है और आपकी दैनिक व मासिक टोकन सीमा में अभी जगह है।
संदेश सहेजा और घोषित किया जाता है
चैट संदेश को अपने डेटाबेस में लिखती है और एक इवेंट प्रकाशित करती है। राउटिंग इसे सुन रही होती है।
राउटिंग एक मॉडल चुनती है
संदेश वर्गीकृत होता है, सक्रिय मोड और नीतियाँ लागू होती हैं, कनेक्टर की सेहत जाँची जाती है, और एक फ़ॉलबैक चेन के साथ निर्णय दर्ज होता है।
कॉन्टेक्स्ट इकट्ठा किया जाता है
चैट मेमोरी से प्रासंगिक रिकॉर्ड और पैक आइटम माँगती है, और फ़ाइलों से प्रासंगिक टुकड़े, फिर इन्हें एक टोकन बजट के भीतर प्रॉम्प्ट में मिला देती है।
मॉडल को कॉल किया और स्ट्रीम किया जाता है
चैट प्रोवाइडर को कॉल करती है और चरण, टेक्स्ट, तर्क प्रक्रिया व मेट्रिक्स को Server-Sent Events के ज़रिए आपके ब्राउज़र तक भेजती है जैसे-जैसे वे आते हैं।
परिणाम सहेजा जाता है
उत्तर, इसका राउटिंग निर्णय, इसकी टोकन गिनती और इसकी कॉन्टेक्स्ट रसीद — सब एक साथ दर्ज किए जाते हैं।
उपयोग और ऑडिट दर्ज होते हैं
बिलिंग आपकी टोकन सीमा में से लागत मापती है और ऑडिट इवेंट दर्ज करता है। मेमोरी एक्सट्रैक्शन भी यहीं चलता है।
चरण 1 से 7 सिंक्रोनस हैं — आप इनका इंतज़ार करते हैं। चरण 8 और मेमोरी एक्सट्रैक्शन उत्तर आपकी स्क्रीन पर आने के बाद होते हैं, इसलिए वे आपके अनुभव में कोई विलंबता नहीं जोड़ते।
इवेंट बस
वह काम जिसे आपके उत्तर देखने से पहले खत्म होने की ज़रूरत नहीं, एक RabbitMQ टॉपिक एक्सचेंज पर एक इवेंट के रूप में प्रकाशित होता है और जो भी सेवाएँ इसकी परवाह करती हैं वे इसे संभालती हैं। उपयोग मीटरिंग, ऑडिट रिकॉर्ड और मेमोरी एक्सट्रैक्शन — सब इसी तरह चलते हैं।
इवेंट ही वजह हैं कि चैट को यह जानने की ज़रूरत नहीं कि ऑडिट मौजूद है। चैट बताती है कि क्या हुआ; जिसे भी प्रतिक्रिया देनी है वह सब्सक्राइब करता है। एक उपभोक्ता जोड़ने के लिए पब्लिशर में कोई बदलाव नहीं करना पड़ता।
- टॉपिक एक्सचेंज
- पब्लिशर बताते हैं कि क्या हुआ, यह नहीं कि किसे सुनना चाहिए। उपभोक्ता उन पैटर्न से जुड़ते हैं जिनकी उन्हें परवाह है।
- बैकऑफ़ के साथ रीट्राई
- एक विफल हैंडलर को बढ़ती देरी के साथ तीन बार दोबारा आज़माया जाता है, जो ज़्यादातर क्षणिक विफलताओं को सोख लेता है।
- डेड-लेटर कतार
- जो संदेश अपने रीट्राई के बाद भी विफल रहता है वह गिराए जाने या उसके पीछे सब कुछ रोकने की बजाय एक डेड-लेटर कतार में जाता है।
- इडेम्पोटेंट हैंडलर
- हैंडलर एक ही इवेंट के दो बार आने को सहन करते हैं, क्योंकि एट-लीस्ट-वन्स डिलीवरी गारंटी देती है कि आखिरकार एक तो आएगा।
- सब कुछ ऑडिट करने योग्य है
- ऑडिट हर डोमेन इवेंट को सब्सक्राइब करता है, इसलिए क्या हुआ इसका रिकॉर्ड इस पर निर्भर नहीं करता कि हर सेवा को एक लिखना याद रहे।
स्ट्रीमिंग
उत्तर पोलिंग से नहीं, Server-Sent Events के ज़रिए आते हैं। कनेक्शन आपके संदेश भेजते ही खुलता है और उत्तर पूरा होने या रद्द होने तक सब कुछ ले जाता है।
बफ़रिंग एंड-टू-एंड बंद है — प्रॉक्सी पर और रास्ते की हर सेवा में — क्योंकि जो स्ट्रीम बफ़र्ड है वह बस अतिरिक्त चरणों वाली एक धीमी प्रतिक्रिया है।
वही चैनल टेक्स्ट जनरेशन, इमेज जनरेशन प्रगति और लंबे समय तक चलने वाली रिसर्च को ले जाता है, इसलिए इंटरफ़ेस के पास चल रहे काम को दिखाने का तीन की बजाय एक तरीका है।
- चरण परिवर्तन
- कतार में, राउटिंग, कॉन्टेक्स्ट इकट्ठा करना, मॉडल को कॉल करना, समापन — ताकि किसी रुकावट का हमेशा एक दृश्यमान कारण हो।
- कॉन्टेंट डेल्टा
- उत्तर का टेक्स्ट जैसे-जैसे मॉडल इसे बनाता है, टोकन दर टोकन।
- रीज़निंग डेल्टा
- जो मॉडल अपनी सोच दिखाते हैं, उनके लिए तर्क प्रक्रिया की स्ट्रीम उत्तर से अलग पहुँचाई जाती है और अलग से ही रेंडर भी होती है।
- मेट्रिक्स टिक
- अब तक के टोकन, प्रति सेकंड टोकन, पहले टोकन तक का समय, और समय असल में कहाँ गया — मॉडल लोड, प्रॉम्प्ट मूल्यांकन या जनरेशन।
- टर्मिनल इवेंट
- एक अंतिम उपयोग सारांश, या एक स्पष्ट त्रुटि या रद्दीकरण। स्ट्रीम कभी बस रुकती नहीं।
क्या कहाँ सहेजा जाता है
चार तरह के स्टोर, हर एक वहीं इस्तेमाल होता है जहाँ वह बेहतर है।
- PostgreSQL
- खातों, बातचीत, राउटिंग निर्णयों, मेमोरी, फ़ाइलों, कनेक्शन और बिलिंग के लिए रिकॉर्ड की व्यवस्था — प्रति सेवा एक डेटाबेस।
- pgvector
- PostgreSQL के भीतर वेक्टर समानता खोज, जो एक अलग वेक्टर डेटाबेस चलाए बिना प्रासंगिक मेमोरी और कॉन्टेक्स्ट पैक आइटम पुनर्प्राप्त करने के लिए इस्तेमाल होती है।
- MongoDB
- ऑडिट इवेंट, उपयोग लेजर और संरचित लॉग: एक रोलिंग रिटेंशन विंडो के साथ उच्च-मात्रा का केवल-जोड़ने वाला डेटा।
- Redis
- कैशिंग, रेट-लिमिट काउंटर और अल्पकालिक समन्वय स्थिति। जो कुछ भी मायने रखता है वह सिर्फ़ यहीं संग्रहीत नहीं है।
सुरक्षा तंत्र
उत्पाद में मौजूद ठोस नियंत्रण। कोई प्रमाणन दावा नहीं — अंत में दिया नोट देखें।
- एक्सेस और रीफ़्रेश टोकन
- रीफ़्रेश रोटेशन के साथ कम अवधि वाले एक्सेस टोकन। घुमाए गए टोकन का दोबारा इस्तेमाल सत्र को अमान्य कर देता है।
- पासवर्ड हैशिंग
- प्रति-उपयोगकर्ता सॉल्ट के साथ Argon2। पासवर्ड कभी किसी भी पुनर्प्राप्त करने योग्य रूप में सहेजे या लॉग नहीं किए जाते।
- भूमिका-आधारित एक्सेस नियंत्रण
- भूमिकाओं के साथ स्पष्ट अनुमतियों के सेट जुड़े होते हैं, जो हर सेवा के हर एंडपॉइंट पर गार्ड्स द्वारा लागू होते हैं — सिर्फ़ इंटरफ़ेस में नहीं।
- एन्क्रिप्टेड क्रेडेंशियल
- प्रोवाइडर और कनेक्टर सीक्रेट AES-256-GCM से एन्क्रिप्ट होकर सहेजे जाते हैं और कभी किसी एपीआई द्वारा वापस नहीं दिए जाते।
- स्कीमा सत्यापन
- किसी भी लॉजिक तक पहुँचने से पहले हर अनुरोध बॉडी को स्पष्ट लंबाई और आकार सीमाओं के साथ एक Zod स्कीमा के विरुद्ध सत्यापित किया जाता है।
- रेट लिमिटिंग
- हर सेवा पर प्रति-खाता थ्रॉटलिंग, ताकि एक क्लाइंट बाकी सबके लिए क्षमता खत्म न कर सके।
- सुरक्षा हेडर
- प्रति-अनुरोध नॉन्स के साथ एक सख़्त कंटेंट सिक्योरिटी पॉलिसी, HSTS, और हर प्रतिक्रिया पर मानक हार्डनिंग हेडर।
- हर जगह TLS
- ब्राउज़र से एज तक TLS और फिर हर आंतरिक हॉप पर फिर से, सेवाओं के बीच प्रमाणपत्र सत्यापन के साथ।
- लॉग रिडैक्शन
- टोकन, पासवर्ड, एपीआई कीज़ और ऑथराइज़ेशन हेडर को किसी भी लॉग में लिखे जाने से पहले हटा दिया जाता है।
ClawAI के पास आज कोई तीसरे-पक्ष का सुरक्षा प्रमाणन नहीं है — न SOC 2, न ISO 27001, न HIPAA। हम ऐसे आश्वासन जताने के बजाय जो हमने हासिल नहीं किए, ऊपर दिए तंत्रों का वर्णन करते हैं। औपचारिक आवश्यकताओं वाले संगठनों को हमसे इन्हें उठाना चाहिए ताकि इन्हें एक एंगेजमेंट के हिस्से के रूप में तय किया जा सके।
ऑब्ज़र्वेबिलिटी
हर सेवा एक ही रूप में वही संकेत भेजती है, और वे सब कहीं न कहीं क्वेरी करने योग्य जगह पहुँचते हैं। "इस अनुरोध को क्या हुआ" का जवाब देने वाले किसी ऑपरेटर को अठारह लॉग फ़ाइलें खोलने की ज़रूरत नहीं होनी चाहिए।
- संरचित लॉग
- हर सेवा और ब्राउज़र से JSON लॉग, इवेंट बस के ज़रिए भेजे और एक रोलिंग विंडो पर सुरक्षित।
- अनुरोध सहसंबंध
- एक अनुरोध ID ब्राउज़र में जनरेट होता है और हर सेवा हॉप में साथ ले जाया जाता है, ताकि एक पहचानकर्ता पूरा रास्ता फिर से बना सके।
- ऑडिट इवेंट
- सुरक्षा और व्यवसाय से जुड़ी कार्रवाइयों का एक अलग, अपरिवर्तनीय रिकॉर्ड, जो परिचालन लॉग से अलग रखा जाता है।
- उपयोग लेजर
- हर मापी गई कॉल एक लेजर एंट्री के रूप में लिखी जाती है। टोकन सीमा के आँकड़े लेजर से निकाले जाते हैं, न कि किसी ऐसे काउंटर से जो भटक सकता है।
- हेल्थ एग्रीगेशन
- एक समर्पित सेवा बाकी हर सेवा को पोल करती है और यह एक इकट्ठी की गई व्यू में रिपोर्ट करती है कि क्या चालू है।
जब कुछ विफल होता है
मॉडल प्रोवाइडरों में आउटेज, रेट लिमिट और सुस्त दिन आते हैं। प्लेटफ़ॉर्म इन्हें सोखने के लिए बना है, न कि इन्हें आपको ऐसे स्पिनर के रूप में सौंपने के लिए जो कभी हल नहीं होता।
- फ़ॉलबैक चेन
- हर राउटिंग निर्णय के साथ विकल्पों की एक क्रमबद्ध सूची होती है। अगर चुना गया मॉडल विफल होता है, तो अगले को स्वतः आज़माया जाता है और प्रतिस्थापन दर्ज होता है।
- सेहत-आधारित परहेज़
- कनेक्टरों की सेहत लगातार जाँची जाती है, और विफल हो रहे प्रोवाइडर को राउटर द्वारा तब तक छोड़ दिया जाता है जब तक वह ठीक न हो जाए।
- सुरक्षित रीट्राई
- इवेंट हैंडलर डुप्लिकेट डिलीवरी को सहन करते हैं, ताकि एक रीट्राई विफलता को ठीक करे, आपकी टोकन सीमा से दो बार न घटाए।
- त्रुटियाँ दृश्यमान हैं
- जब हर विकल्प विफल होता है, तो बातचीत में एक स्पष्ट त्रुटि लिखी जाती है और स्ट्रीम में नीचे भेजी जाती है। ऐसी कोई चुप्पी वाली विफलता नहीं जो इंटरफ़ेस को इंतज़ार में छोड़ दे।
- प्रभाव का दायरा
- अलग-अलग प्रक्रियाएँ और अलग-अलग डेटाबेस का मतलब है कि एक विफलता एक ही क्षमता घटाती है। इमेज जनरेशन बंद होने से आपकी चैट नहीं रुकती।
वही आर्किटेक्चर, आपके नेटवर्क के भीतर
इस पेज पर सब कुछ होस्टेड सेवा का वर्णन करता है, लेकिन आर्किटेक्चर इससे बँधा नहीं है। वही अठारह सेवाएँ, वही इवेंट बस और वही डेटा मॉडल किसी संगठन के अपने ही नेटवर्क के भीतर परिनियोजित किया जा सकता है।
उस कॉन्फ़िगरेशन में बाहरी मॉडल प्रोवाइडरों की जगह आपके अपने GPU पर सर्व किए गए ओपन-वेट मॉडल ले लेते हैं, ताकि कोई प्रॉम्प्ट, दस्तावेज़ या बातचीत आपके इन्फ़्रास्ट्रक्चर से बाहर न जाए। यह ऐसा प्लान नहीं है जिसे आप खरीद सकें बल्कि एक सीमित-दायरे वाला एंगेजमेंट है — हम इसे आपकी टीम के साथ मिलकर तय करते हैं।
इसे चलते हुए देखें
किसी आर्किटेक्चर को परखने का सबसे तेज़ तरीका है वह इस्तेमाल करना जो यह बनाता है। निःशुल्क प्लान सेट करने में एक मिनट लगता है।