لقد تحققنا من هذا التمييز مباشرة في كود خدمة aura-ai، وليس في صفحة التسويق: ثلاث وحدات موفر (anthropic, gemini, openai) تشكل البوابة، لا أكثر. تؤكد بقية المشهد أن هذه فئة مطورين حقيقية، وليست حجة تسويقية معزولة. تنشر Neon صفحتين مخصصتين ("بوابة الذكاء الاصطناعي" و"الخلفية لوكلاء الذكاء الاصطناعي")، وقد أثبتت LiteLLM نفسها كمشروع مرجعي مفتوح المصدر، وخصصت Braintrust مقارناتها الخاصة بها.
الأساسيات
- تم التحقق من 3 موفري خدمات أصليين في كود: OpenAI، Anthropic (Claude)، Google Gemini (
aura-ai/src/llm/mod.rs). - تمر Mistral وScaleway AI وOllama عبر محول OpenAI العام (
OPENAI_BASE_URL)، وليس من خلال عميل مخصص. - يجلب المواطن الأصلي أكثر من مجرد الاتصال: قاطع الدائرة بواسطة (المشروع، المورد)، إعادة محاولة التراجع، سلسلة التراجع (الترتيب الافتراضي Anthropic → OpenAI → Google)، وتوحيد أسباب إيقاف التشغيل.
- يغطي Anthropic الدردشة فقط: لا توجد واجهة برمجة تطبيقات للتضمين، على عكس OpenAI وGemini اللذين يغطيان كليهما.
- تؤكد Neon وLiteLLM وBraintrust على نفس الفئة من جانب السوق، مع ثلاثة أساليب مختلفة: البوابة المُدارة، والوكيل مفتوح المصدر، والمحتوى المقارن.
ما هي بوابة الذكاء الاصطناعي على الواجهة الخلفية لـ Postgres؟
تعمل بوابة الذكاء الاصطناعي على مركزية المكالمات لمقدمي خدمات LLM الخارجيين خلف واجهة واحدة، بدلاً من ترميز كل تكامل SDK على جانب التطبيق. تظل مفاتيح واجهة برمجة التطبيقات (API) من جانب الخادم، ولا يتم كشفها للعميل أبدًا. تضيف البوابة طبقة مشتركة من إعادة المحاولة وتجاوز الفشل واحتساب التكاليف بالإضافة إلى الموفرين الذين لديهم تنسيقات استجابة مختلفة.
في واجهة Postgres الخلفية مثل Aurabase، هذا الاختيار له نتيجة مباشرة: نفس البوابة تعمل على تشغيل دردشة التطبيق، وNL2SQL (ترجمة اللغة الطبيعية إلى SQL) وRAG (بحث متجه pgvector). يؤدي المزود غير المتكامل إلى تدهور الميزات الثلاث في وقت واحد، وليس ميزة واحدة فقط. وهذا ما يجعل التمييز الأصلي/المتوافق أكثر من مجرد تفاصيل تنفيذ.
الموفر الأصلي أو نقطة النهاية المتوافقة: الفرق الملموس
يقوم العميل الأصلي بتشفير الشكل الحقيقي لواجهة برمجة التطبيقات الخاصة بالموفر: بنية الطلب، وتنسيق الاستجابة، وحقول الاستخدام الخاصة بهذا الموفر. هذه هي حالة Anthropic، التي لا تشبه واجهة برمجة التطبيقات "Messages" الخاصة بها واجهة OpenAI، أو Gemini، التي تتم إضافة عدد الرموز المميزة الخاصة بها (thoughtsTokenCount) إلى عداد الإخراج بدلاً من تضمينه هناك بالفعل.
تعيد نقطة النهاية المتوافقة مع OpenAI استخدام عميل OpenAI الحالي وتغير عنوان URL الأساسي فقط. ينجح هذا لأن مقدم الخدمة الخارجي (Mistral، وScaleway AI، وOllama) اختار تقليد عقد واجهة برمجة التطبيقات الخاص بـ OpenAI، وغالبًا ما يكون ذلك مع انحرافات: لا يوجد حقل منفصل لرمز الاستدلال، ولا يوجد ضمان على الشكل الدقيق للأخطاء. وينتهي التوافق حيث ينتهي التقليد.
3 عملاء أصليين من LLM في Aurabase، لا أكثر
الملف الذي ينظم الموفرين في aura-ai لا يترك مجالًا للغموض. ثلاث وحدات، واحدة لكل موفر أصلي، ولم يتم الإعلان عن أي شيء آخر.
تطبق كل وحدة سمة ChatProvider (الإكمال والبث واسم النموذج). اثنان منهم، OpenAI وGemini، ينفذان بالإضافة إلى ذلك EmbeddingProvider. Anthropic لا تحتاج إليها: لا يكشف Claude عن واجهة برمجة تطبيقات التضمين من جانب البائع، وهي حقيقة منتج لشركة Anthropic نفسها، وليس عيبًا في كود Aurabase.
| OpenAI | العميل الأصلي | الدردشة + حساب التضمينات المتجهة عالية الدقة |
|---|---|---|
| أنثروبي (كلود) | العميل الأصلي | استنتاج الدردشة وإكمال النموذج المنظم كلود |
| جوجل الجوزاء | العميل الأصلي | الدردشة + التضمينات، والعد الرمزي للاستدلال الإضافي |
| ميسترال | الموقع المتوافق | التوجيه عبر بروتوكول OpenAI القياسي المتوافق (عنوان URL المخصص) |
| سكاليواي الذكاء الاصطناعي | الموقع المتوافق | الطريق عبر عميل openai.rs، المتغير OPENAI_BASE_URL |
| أولاما (استضافة ذاتية) | الموقع المتوافق | الطريق عبر عميل openai.rs، المتغير OPENAI_BASE_URL |
قم بتوصيل Mistral أو Scaleway AI أو Ollama بمشروع Aurabase
لا يتطلب تكوين Mistral أو Scaleway AI أو Ollama وحدة نمطية جديدة: يقوم نفس المتغير OPENAI_BASE_URL بإعادة توجيه عميل openai.rs إلى نقطة نهاية أخرى متوافقة. هذا تبديل التكوين، وليس التطوير.
ويتغير السلوك تبعاً لذلك. تظل أخطاء HTTP مصنفة بنفس الآلية (429 ← حد المعدل، 5xx ← عابر وقابل لإعادة المحاولة، 404 ← نموذج غير معروف)، لأن التصنيف يعيش على مستوى نقل HTTP، وليس التحليل الخاص بالموفر. ما لا يلي: العد الدقيق لرموز الاستدلال، الخاصة بعميل Gemini المخصص.
لماذا يعد برنامج Native بمثابة تغيير في قواعد اللعبة: التبديل، والأخطاء، والفواتير
تضيف بوابة Aurabase ثلاث آليات مرونة بالإضافة إلى العملاء الأصليين الثلاثة. يقوم قاطع الدائرة لكل زوج (مشروع، موفر) بقطع المكالمات إلى موفر الخدمة الذي يفشل بشكل متكرر، مع وجود رمز مميز للتحقيق في حالة شبه مفتوحة قبل إعادة فتحه. تؤدي إعادة المحاولة التراجعية الأسية مع عدم الاستقرار إلى إعادة تشغيل الأخطاء العابرة (المهلة، 5xx، 429)، دون الاعتماد على مكتبة أرقام عشوائية خارجية.
عندما يتم تكوين العديد من مقدمي الخدمة في سلسلة، يتم إجراء محاولة واحدة فقط لكل مزود قبل التبديل إلى التالي، لتجنب التضخيم (إعادة المحاولة × التراجع) الذي قد يؤدي إلى مضاعفة مكالمات المنبع وزمن الوصول الإجمالي. الترتيب الافتراضي لهذه القناة هو Anthropic، ثم OpenAI، ثم Google Gemini.
يقوم كل مزود أيضًا بتسمية سبب إيقاف الاستجابة بشكل مختلف: length في OpenAI، MAX_TOKENS في Gemini، max_tokens في Anthropic، لنفس الواقع (الاقتطاع). يقوم الكود بتطبيع هذه المفردات الثلاثة نحو مجموعة مشتركة (stop, length, content_filter, tool_use, other). بدون هذا التوحيد القياسي، سيحتاج العميل متعدد البائعين إلى معرفة المفردات الثلاثة لاكتشاف الاستجابة المقتطعة.
الفواتير يوضح نفس المخاطر. في OpenAI وAnthropic، تم تضمين منطق النموذج بالفعل في عداد الرموز المميزة للمخرجات المشحونة. في Gemini، تتم إضافة thoughtsTokenCount بشكل منفصل إلى candidatesTokenCount: تجاهلها يقلل من التكلفة الحقيقية للاستعلام. ليس لدى المحول العام المتوافق مع OpenAI أي سبب لمعرفة هذه الخصوصية، الخاصة بتنسيق الاستجابة الأصلي لـ Gemini.
Neon، LiteLLM، Braintrust: أين توجد أفضل بوابات LLM في عام 2026؟
يؤكد السوق أن بوابة الذكاء الاصطناعي أصبحت لبنة متوقعة وليست حجة تسويقية معزولة. تنشر Neon صفحتين مخصصتين للمنتج، "AI Gateway" و"Backend for AI agent"، وكلاهما موجه لمطوري Postgres. لقد أثبتت LiteLLM نفسها كمشروع مرجعي مفتوح المصدر لتوحيد المكالمات لعدد كبير من مقدمي الخدمة خلف تنسيق قريب من OpenAI. من جانبها، تنشر شركة Braintrust مقارناتها الخاصة حول هذا الموضوع، وهي علامة على أن الفئة قوية بما يكفي لتبرير المحتوى التحريري المخصص.
يستجيب هؤلاء اللاعبون لحاجة حقيقية: تقليل الاقتران بين رمز التطبيق وموفر LLM معين. الفرق مع Aurabase هو التكامل. لا توجد البوابة بجوار الواجهة الخلفية: فهي تشترك في نفس الخدمة مثل NL2SQL وRAG، في نفس قاعدة بيانات Postgres. يوجد أيضًا حل وسط معاكس: يغطي الوكيل المخصص مثل LiteLLM بشكل عام موفري خدمات أكثر من البوابة المدمجة في الواجهة الخلفية للتطبيق.
| أوراباسي | متكامل مع الواجهة الخلفية لـ Postgres (خدمة aura-ai) | 3 مواطنين تم التحقق منهم + متوافق مع OpenAI للباقي |
|---|---|---|
| بوابة النيون للذكاء الاصطناعي | منتج مخصص، إلى جانب قاعدة بيانات Postgres المُدارة | موثق على صفحتين رسميتين منفصلتين |
| لايتLLM | وكيل مستقل مفتوح المصدر، أمام أي واجهة خلفية | مجموعة واسعة من مقدمي الخدمات عبر تنسيق قريب من OpenAI |
متى تختار البوابة الأصلية، ومتى تختار وكيلًا عامًا
تتمتع البوابة الأصلية مثل بوابة Aurabase بميزة حقيقية عندما يجب أن تظل الواجهة الخلفية والذكاء الاصطناعي في نفس النظام: ثم تتشارك NL2SQL وRAG والدردشة التطبيقية نفس سياسة المرونة ونفس الفواتير، دون تشغيل خدمات إضافية.
الحل الوسط المعاكس موجود. إذا كانت أولويتك هي تغطية عدد كبير جدًا من مقدمي الخدمة، أو إذا كان يجب على البوابة أن تخدم العديد من الواجهات الخلفية المستقلة وليس مجرد مشروع Postgres، فغالبًا ما يظل الوكيل العام مثل LiteLLM هو الخيار الصحيح. لا تسعى Aurabase إلى التنافس مع هذا النطاق الواسع من التغطية: فالرهان هو العمق عبر 3 مقدمي خدمات رئيسيين، ومتكاملين مع بقية الواجهة الخلفية.
لفهم كيف يغير هذا التكامل بشكل ملموس استخدام NL2SQL مقارنة بالطريقة التي تستخدم الموصلات الخارجية، النهج الذي اختاره Supabase، راجع يعتمد Supabase على الموصلات، وليس على NL2SQL.
البوابة الأصلية المتكاملة مقابل وكيل LLM العام
ملخص للمعايير التي تميز بين النهجين، دون الحكم على القيمة: كل منهما يستجيب لحاجة مختلفة.
| الموردين | التعمق في 3 موردين رئيسيين + توافق OpenAI مع الباقي | مجموعة واسعة من الموردين، والتكامل الموحد عموما |
|---|---|---|
| مفاتيح واجهة برمجة التطبيقات | مشفرة على الجانب الخلفي، نفس الخدمة مثل قاعدة البيانات | مشفرة على جانب الوكيل، الخدمة منفصلة عن الواجهة الخلفية للتطبيق |
| رابط NL2SQL/RAG | نفس الخدمة، نفس محلل الموفر | لا توجد روابط أصلية، قم ببناء التكامل الخاص بك |
| المرونة | قاطع الدائرة بواسطة (المشروع، المورد)، التراجع، إعادة محاولة التراجع | يعتمد على التكوين المختار للوكيل |
| النشر | خدمة واحدة أقل للتشغيل (بالفعل في الواجهة الخلفية) | قابلة للفصل وإعادة الاستخدام عبر مشاريع/واجهات خلفية متعددة |
لرؤية هذه البوابة وهي تعمل في حالة ملموسة، راجع البرنامج التعليمي NL2SQL على Postgres. للحصول على تفاصيل حول قدرات الذكاء الاصطناعي الأصلية لـ Aurabase، راجع صفحة الذكاء الاصطناعي الأصلي.