एआई गेटवे: देशी बनाम ओपनएआई-संगत प्रदाता

एआई गेटवे एप्लिकेशन पक्ष पर प्रत्येक एसडीके एकीकरण को कोड करने के बजाय, एक इंटरफ़ेस के पीछे बाहरी एलएलएम प्रदाताओं को कॉल को केंद्रीकृत करता है। एपीआई कुंजियाँ सर्वर-साइड रहती हैं, क्लाइंट के सामने कभी नहीं आतीं। गेटवे विभिन्न प्रतिक्रिया प्रारूपों के साथ प्रदाताओं के शीर्ष पर पुनः प्रयास, विफलता और लागत गणना की एक सामान्य परत जोड़ता है।

Aurabaseजैसे पोस्टग्रेज बैकएंड पर, इस विकल्प का सीधा परिणाम होता है: वही गेटवे एप्लिकेशन चैट, NL2SQL (SQL में प्राकृतिक भाषा अनुवाद) और RAG (pgvector वेक्टर खोज) को शक्ति प्रदान करता है। एक खराब एकीकृत प्रदाता केवल एक ही नहीं, बल्कि सभी तीन सुविधाओं को एक साथ ख़राब कर देता है। यही वह चीज़ है जो कार्यान्वयन विवरण से अधिक मूल/संगत भेद बनाती है।

एक मूल ग्राहक प्रदाता के एपीआई के वास्तविक रूप को एन्कोड करता है: अनुरोध संरचना, प्रतिक्रिया प्रारूप, इस प्रदाता के लिए विशिष्ट उपयोग फ़ील्ड। यह एंथ्रोपिक का मामला है, जिसका "संदेश" एपीआई ओपनएआई या जेमिनी से मिलता-जुलता नहीं है, जिसके तर्क टोकन (thoughtsTokenCount) की गिनती पहले से ही वहां शामिल होने के बजाय आउटपुट काउंटर में जोड़ दी जाती है।

एक OpenAI संगत समापन बिंदु मौजूदा OpenAI क्लाइंट का पुन: उपयोग करता है और केवल आधार URL को बदलता है। यह काम करता है क्योंकि तीसरे पक्ष प्रदाता (मिस्ट्रल, स्केलवे एआई, ओलामा) ने ओपनएआई के एपीआई अनुबंध की नकल करना चुना, अक्सर विचलन के साथ: कोई अलग तर्क टोकन फ़ील्ड नहीं, त्रुटियों के सटीक रूप पर कोई गारंटी नहीं। अनुकूलता वहीं समाप्त हो जाती है जहां नकल समाप्त होती है।

वह फ़ाइल जो प्रदाताओं को aura-ai में व्यवस्थित करती है, अस्पष्टता के लिए कोई जगह नहीं छोड़ती है। तीन मॉड्यूल, प्रति मूल प्रदाता एक, और कुछ घोषित नहीं।

pub mod anthropic;
pub mod gemini;
pub mod openai;

प्रत्येक मॉड्यूल ChatProvider विशेषता (पूर्णता, स्ट्रीमिंग, मॉडल नाम) लागू करता है। उनमें से दो, ओपनएआई और जेमिनी, अतिरिक्त रूप से EmbeddingProviderलागू करते हैं। एंथ्रोपिक को इसकी आवश्यकता नहीं है: क्लाउड विक्रेता-पक्ष एम्बेडिंग एपीआई को उजागर नहीं करता है, एंथ्रोपिक का ही एक उत्पाद तथ्य है, ऑराबेस कोड की कमी नहीं है।

मिस्ट्रल, स्केलवे एआई या ओलामा को कॉन्फ़िगर करने के लिए नए मॉड्यूल की आवश्यकता नहीं होती है: वही OPENAI_BASE_URL वेरिएबल openai.rs क्लाइंट को किसी अन्य संगत एंडपॉइंट पर रीडायरेक्ट करता है। यह एक कॉन्फ़िगरेशन टॉगल है, विकास नहीं।

# डिफ़ॉल्ट प्रदाता: मूल OpenAI
OPENAI_API_KEY=sk-...

# ओपनएआई संगत प्रदाता पर स्विच करें (मिस्ट्रल, स्केलवे एआई, ओलामा...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# जैसे मिस्ट्रल: https://api.mistral.ai/v1

व्यवहार तदनुसार बदलता रहता है। HTTP त्रुटियाँ उसी तंत्र द्वारा वर्गीकृत रहती हैं (429 → दर सीमा, 5xx → क्षणिक और पुनः प्रयास योग्य, 404 → अज्ञात मॉडल), क्योंकि वर्गीकरण HTTP परिवहन स्तर पर रहता है, न कि प्रदाता-विशिष्ट पार्सिंग पर। क्या अनुसरण नहीं करता है: समर्पित जेमिनी क्लाइंट के लिए विशिष्ट तर्क टोकन की सटीक गिनती।

ऑराबेस गेटवे तीन मूल ग्राहकों के शीर्ष पर तीन लचीलापन तंत्र जोड़ता है। प्रति जोड़ी (प्रोजेक्ट, प्रदाता) एक सर्किट ब्रेकर बार-बार विफल प्रदाता को कॉल काटता है, इसे फिर से खोलने से पहले अर्ध-खुली स्थिति में एक जांच टोकन के साथ। बाहरी यादृच्छिक संख्या लाइब्रेरी पर निर्भरता के बिना, घबराहट के साथ एक घातीय बैकऑफ पुनः प्रयास क्षणिक त्रुटियों (टाइमआउट, 5xx, 429) को पुनरारंभ करता है।

प्रत्येक प्रदाता प्रतिक्रिया को रोकने का कारण भी अलग-अलग बताता है: OpenAI में length, जेमिनी में MAX_TOKENS, एंथ्रोपिक में max_tokens, एक ही वास्तविकता (छंटनी) के लिए। कोड इन तीन शब्दावलियों को एक सामान्य सेट (stop, length, content_filter, tool_use, other) की ओर सामान्यीकृत करता है। इस मानकीकरण के बिना, एक बहु-विक्रेता ग्राहक को एक संक्षिप्त प्रतिक्रिया का पता लगाने के लिए सभी तीन शब्दावलियों को जानने की आवश्यकता होगी।

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

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

ये खिलाड़ी एक वास्तविक आवश्यकता पर प्रतिक्रिया देते हैं: एप्लिकेशन कोड और किसी दिए गए एलएलएम प्रदाता के बीच युग्मन को कम करना। ऑराबेस के साथ अंतर एकीकरण का है। गेटवे बैकएंड के बगल में नहीं रहता है: यह समान पोस्टग्रेज डेटाबेस पर NL2SQL और RAG जैसी समान सेवा साझा करता है। विपरीत समझौता भी मौजूद है: लाइटएलएलएम जैसी एक समर्पित प्रॉक्सी आमतौर पर एप्लिकेशन बैकएंड में एकीकृत गेटवे की तुलना में अधिक प्रदाताओं को कवर करती है।

ऑराबेस जैसे देशी गेटवे का वास्तविक लाभ तब होता है जब बैकएंड और एआई को एक ही सिस्टम में रहना चाहिए: एनएल2एसक्यूएल, आरएजी और एप्लिकेशन चैट तब समान लचीलापन नीति और समान बिलिंग साझा करते हैं, बिना अतिरिक्त सेवाओं के संचालन के।

विपरीत समझौता मौजूद है. यदि आपकी प्राथमिकता बहुत बड़ी संख्या में प्रदाताओं को कवर करना है, या यदि गेटवे को केवल पोस्टग्रेज प्रोजेक्ट ही नहीं बल्कि कई स्वतंत्र बैकएंड की सेवा देनी है, तो लाइटएलएलएम जैसी सामान्य प्रॉक्सी अक्सर सही विकल्प बनी रहती है। ऑराबेस कवरेज की इस व्यापकता के साथ प्रतिस्पर्धा करने की कोशिश नहीं करता है: दांव 3 प्रमुख प्रदाताओं की गहराई है, जो बाकी बैकएंड के साथ एकीकृत है।

यह समझने के लिए कि यह एकीकरण बाहरी कनेक्टर्स का उपयोग करने वाले दृष्टिकोण की तुलना में NL2SQL के उपयोग को कैसे ठोस रूप से बदल देता है, सुपाबेस द्वारा चुना गया दृष्टिकोण, देखें सुपाबेस कनेक्टर्स पर निर्भर करता है, न कि मूल NL2SQLपर।

उन मानदंडों का सारांश जो वास्तव में मूल्य निर्णय के बिना, दो दृष्टिकोणों को अलग करते हैं: प्रत्येक एक अलग आवश्यकता पर प्रतिक्रिया करता है।

To see this gateway at work in a concrete case, see the NL2SQL tutorial on Postgres. For details of Aurabase's native AI capabilities, see the Native AIpage.