لماذا توقفت عن الاعتماد على مزود ذكاء اصطناعي واحد

قمت ببناء روبوت دردشة (chatbot) يعمل في الوقت الفعلي لمنتدى مجتمعي. اعتقدت أن استخدام واجهة برمجة تطبيقات (API) واحدة سيكون كافيًا. لكنني كنت مخطئًا.

بعد ثلاثة أسابيع، واجهت خطأ 5xx خلال ساعات الذروة. توقف روبوت الدردشة الخاص بي عن العمل تمامًا. شعر المستخدمون بالإحباط. أدركت حينها أنه لا يمكنني الوثوق بمزود واحد للتطبيقات الموجهة للإنتاج (production apps).

استخدمت GPT-4. كان يعمل بشكل جيد حتى توقف فجأة. واجهت قيودًا على معدل الاستخدام (rate limits)، وانقطاعات في الاتصال (timeouts)، وتوقفًا تامًا للخدمة. شعرت أن الدفع مقابل فئات أعلى يشبه علاج العرض بدلاً من حل المشكلة الأساسية.

جربت مزودين آخرين، لكن جميعهم كان لديهم تنسيقات وطرق مصادقة (auth methods) مختلفة. أصبح الكود الخاص بي عبارة عن فوضى من جمل switch-case. كنت بحاجة إلى نظام من أجل:

تجنبت استخدام المكتبات الخارجية (third-party libraries) لأنها كانت معقدة للغاية وتتعطل بسهولة. بدلاً من ذلك، قمت ببناء موجه (router) بسيط.

أولاً، قمت بتعريف واجهة مشتركة (common interface) لجميع المزودين. يقوم كل مزود بتنفيذ دالة generate وفحص حالة الخدمة (health check).

بعد ذلك، قمت ببناء فئة موجه (router class). تحاول هذه الفئة الاتصال بالمزودين بترتيب محدد، وتستخدم تقنية التراجع الأسي (exponential backoff) وتخزينًا مؤقتًا بسيطًا. إذا فشل المزود الأول، ينتظر النظام ثم يحاول مع المزود التالي.

أنقذ هذا النظام عطلات نهاية الأسبوع الخاصة بي خلال ثلاثة انقطاعات مختلفة للخدمة. فهو يحافظ على استمرارية عمل تطبيقي حتى عندما يتوقف أحد المزودين الرئيسيين عن العمل.

إذا كنت ستبني هذا النظام، ضع هذه النقاط في اعتبارك:

إذا كان مشروعك صغيرًا، فلا تبالغ في هندسته (over-engineer). وإذا كنت بحاجة إلى البث (streaming)، فإن هذا النمط قد يزيد من زمن الاستجابة (latency). اختر الأداة المناسبة لحجم مشروعك.

كيف تتعامل مع موثوقية المزود؟ هل تلتزم بمزود واحد أم تبني طبقة احتياطية (fallback layer)؟

المصدر: https://dev.to/__c1b9e06dc90a7e0a676b/why-i-stopped-relying-on-a-single-ai-provider-and-built-a-fallback-system-1pc0

مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi