PRODمنصة BaaS الأوروبية السياديةافتح لوحة المعلومات →

الذكاء الاصطناعي الأصلي · 10 دقيقة للقراءة

بوابة الذكاء الاصطناعي: موفري الخدمات الأصليون والمتوافقون مع OpenAI

Affane Daylami · Fondateur · 31 مارس 2026

العودة إلى بلوق

تقوم بوابة AI بتوجيه المكالمات إلى موفري LLM متعددين من نقطة دخول واحدة. في Aurabase، تعيش هذه الطبقة مباشرة في الواجهة الخلفية لـ Postgres. لدى كل من OpenAI وAnthropic (Claude) وGoogle Gemini عميل أصلي مشفر، مع معالجة الأخطاء الخاصة به، والفوترة الرمزية والبث. كل شيء آخر، Mistral، وScaleway AI، وOllama المستضاف ذاتيًا، يمر عبر محول عام متوافق مع OpenAI. التمييز ليس تجميليًا: فهو يحدد ما الذي ينجح حقًا (التبديل التلقائي، والعد الدقيق للرموز المميزة للاستدلال) وما الذي ينجح "طالما أن المزود يقلد واجهة برمجة تطبيقات OpenAI بأمانة".

تم إنشاء هذا النص الإنجليزي تلقائيًا من النص الأصلي الفرنسي ولم تتم مراجعته بعد.
تمت ترجمة هذه الصفحة تلقائيًا. النسخة الإنجليزية موثوقة.

لقد تحققنا من هذا التمييز مباشرة في كود خدمة 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 لا يترك مجالًا للغموض. ثلاث وحدات، واحدة لكل موفر أصلي، ولم يتم الإعلان عن أي شيء آخر.

llm/mod.rsrust
pub mod anthropic;
pub mod gemini;
pub mod openai;

تطبق كل وحدة سمة 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 إلى نقطة نهاية أخرى متوافقة. هذا تبديل التكوين، وليس التطوير.

.env هالة منظمة العفو الدوليةbash
# الموفر الافتراضي: OpenAI الأصلي
OPENAI_API_KEY=sk-...

# قم بالتبديل إلى مزود متوافق مع OpenAI (Mistral، وScaleway AI، وOllama...)
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، وليس التحليل الخاص بالموفر. ما لا يلي: العد الدقيق لرموز الاستدلال، الخاصة بعميل 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.

#
المناظر الطبيعية 2026

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، راجع صفحة الذكاء الاصطناعي الأصلي.

#
الأسئلة المتداولة

الأسئلة الشائعة

هل يمكن استخدام ميسترال مع Aurabase؟+
نعم، عبر نقطة النهاية المتوافقة مع OpenAI: قم بتكوين OPENAI_API_KEY باستخدام مفتاح Mistral وOPENAI_BASE_URL باستخدام عنوان URL الأساسي لواجهة برمجة تطبيقات Mistral. إنه ليس عميلًا أصليًا مخصصًا: تستخدم ميسترال نفس الكود الذي يستخدمه مزود OpenAI، مع نفس القيود، بما في ذلك عدم وجود حساب منفصل للرموز المميزة للاستدلال.
ماذا يحدث إذا تعطل مزود LLM الأساسي؟+
تكتشف دائرة قاطعة لكل زوج (مشروع، مورد) حالات الفشل المتكررة وتقطع المكالمات إلى هذا المورد. إذا تم تكوين سلسلة احتياطية (الترتيب الافتراضي: Anthropic، ثم OpenAI، ثم Google Gemini)، فسيتحول الاستعلام تلقائيًا إلى الموفر التالي، مع محاولة واحدة فقط لكل موفر لتجنب إعادة المحاولة × التضخيم الاحتياطي.
ما الفرق بين العميل الأصلي ونقطة النهاية المتوافقة مع OpenAI؟+
يقوم العميل الأصلي بتشفير الشكل الحقيقي لواجهة برمجة التطبيقات الخاصة بالموفر: بنية الطلب، وتنسيق الاستجابة، وحقول الاستخدام الخاصة بذلك الموفر، مثل العد الإضافي لرموز الاستدلال المميزة في Gemini. تعمل نقطة النهاية المتوافقة على إعادة استخدام عميل OpenAI الحالي عن طريق تغيير عنوان URL الأساسي فقط، والذي يعمل طالما أن موفر الطرف الثالث يحاكي عقد OpenAI API عن كثب.
هل تقدم Aurabase عمليات التضمين لجميع مقدمي الخدمة الأصليين؟+
لا. يقوم OpenAI وGoogle Gemini بتنفيذ واجهة التضمين، وليس واجهة الإنسان. لم يكشف كلود عن واجهة برمجة تطبيقات التضمين من جانب المزود: وهذا ليس عيبًا في كود Aurabase، ولكنه ميزة للمنتج الأنثروبي نفسه. يقدم الدليل الفني لـ AI Gateway تفاصيل التكوين حسب البائع، سواء كان أصليًا أو متوافقًا.

هل أنت جاهز للنشر؟

الواجهة الخلفية الخاصة بك في خمس دقائق.

لا حاجة لبطاقة ائتمان · 500 ميجابايت مجانًا · 50000 MAU