الشهر الماضي قمت بتدريب زميل انتقل حديثاً إلى وظيفة جديدة لبناء نموذج أولي لخدمة العملاء الذكية، والمتطلبات بسيطة: المستخدم يسأل، النموذج يجيب، مع القليل من الذاكرة السياقية، وقدرة على الكتابة التدريجية. يبدو أنه يمكن إنجازه في يومين، لكنه وقع في مطبات كتابة مفتاح API بشكل ثابت، ومنطق إعادة المحاولة، ودمج البث المباشر. قمت بتنظيم العملية كاملة في هذا المقال، ليُقرأ كملاحظات عند تدريب المبتدئين.
الخطوة الأولى: فكك المتطلبات أولاً، ثم اختر النموذج
لا تبدأ بكتابة الكود مباشرة. متطلبات قدرات خدمة العملاء الذكية تنقسم تقريباً إلى ثلاثة أجزاء: التعرف على النية، والإجابة على الأسئلة المعرفية، والدردشة متعددة الجولات. التعرف على النية يحتاج السرعة والرخص، ويكفي استخدام DeepSeek-V3 أو واجهة Qwen API؛ الإجابة على الأسئلة المعرفية تتضمن مستنداتك الخاصة، ويجب المرور عبر RAG، والنموذج يحتاج فهم السياق الطويل؛ الدردشة متعددة الجولات تتطلب أسلوباً عالياً، وClaude 4 Sonnet أو GPT-4o أكثر استقراراً.
أسلوبي هو تشغيل السلسلة بنموذج عام أولاً، ثم استبداله بنداً بنداً. توجيه النماذج المتعددة من SiCore TokenWorks يوفر العناء في هذه المرحلة، نفس الكود مع تغيير اسم النموذج يمكنك مقارنة النتائج، دون تغيير المصادقة. اختيار واجهة API للنماذج الكبيرة ليس اختيار الأقوى، بل اختيار الأنسب للمهمة.
الخطوة الثانية: إدارة المفاتيح، لا تكتبها في الكود
كتابة المفتاح مباشرة في الكود المصدري هي الخطأ الأكثر شيوعاً لدى المبتدئين. بمجرد رفعه إلى git، يصبح معلناً. الطريقة الصحيحة هي متغيرات البيئة مع تصنيف ملفات الإعداد: محلياً استخدم .env، وفي الاختبار والإنتاج استخدم مركز الإعداد أو خدمة إدارة المفاتيح.
عزل البيئات المتعددة يتطلب تذكر ثلاث نقاط: التطوير والاختبار والإنتاج تستخدم مفاتيح مختلفة؛ كل مفتاح له حد حصة مستقل؛ مفتاح الإنتاج يُعطى للخادم فقط، والواجهة الأمامية لا تحصل عليه أبداً. في مشروعنا نستخدم SiCore TokenWorks، مفتاح واحد يمكنه استدعاء GPT-4o وClaude وDeepSeek وQwen وERNIE وDoubao وغيرها من النماذج الرئيسية، مما يوفر عناء صيانة عدة أنظمة مصادقة، وتبديل المفاتيح بين البيئات هو مجرد تغيير متغير.
الخطوة الثالثة: تغليف الاستدعاء وإعادة المحاولة عند الأخطاء
الكود الذي يستدعي SDK مباشرة غير قابل للصيانة. غلّف طبقة، وتعامل بشكل موحد مع المهلة وتحديد المعدل وإعادة المحاولة. الفكرة كالتالي: غلّف استدعاء النموذج كدالة، معاملاتها messages واسم النموذج، وتلتقط داخلياً ثلاثة أنواع من الأخطاء — مهلة الشبكة، و429 تحديد المعدل، وأخطاء الخادم 5xx.
استراتيجية إعادة المحاولة تستخدم التراجع الأسي، المرة الأولى انتظر ثانية، الثانية ثانيتين، الثالثة أربع ثوانٍ، بحد أقصى ثلاث مرات. يجب التعامل مع 429 بشكل خاص، بالنظر إلى ترويسة retry-after المُرجعة. لا تعد المحاولة لجميع الأخطاء، فإعادة المحاولة لمئة مرة على خطأ في المعاملات لا فائدة منها. قيمة بوابة النماذج تكمن في هذه الطبقة، حيث يتم تجميع إعادة المحاولة والتخفيض والسجلات في مكان واحد، وكود الأعمال يهتم فقط بالحصول على النتيجة.
تنبيه من المطبات: إعادة المحاولة يجب أن تكون متساوية الأثر. إذا كان الاستدعاء له آثار جانبية (مثل الكتابة في قاعدة البيانات)، تأكد قبل إعادة المحاولة أن المرة السابقة فشلت فعلاً.
الخطوة الرابعة: الإخراج المتدفق والربط مع الواجهة الأمامية
جوهر تجربة خدمة العملاء هو "تأثير الآلة الكاتبة". الخادم يستخدم SSE لدفع الـ token قطعة قطعة إلى الواجهة الأمامية، والواجهة الأمامية تستقبل عبر EventSource أو ReadableStream من fetch.
النقاط الرئيسية في الخادم: اضبط stream=True، وحلل الـ delta المُرجعة قطعة قطعة، وعند الوصول إلى [DONE] تنتهي. النقاط الرئيسية في الواجهة الأمامية: لا تستدعِ setState مع كل حرف تستقبله، اجمع لمدة 20 إلى 50 مللي ثانية ثم اعرض دفعة واحدة، وإلا ستتوقف الصفحة كعرض شرائح.
هناك مطب آخر، أثناء البث قد يغلق المستخدم الصفحة. يجب على الخادم الاستماع لحدث قطع الاتصال، وإلغاء الطلب upstream في الوقت المناسب، وإلا ستحرق الـ token هدراً. في ظل الفاتورة حسب الاستخدام، هذا الهدر يتراكم.
الخطوة الخامسة: مراقبة التكلفة والتنبيهات
قبل الإطلاق يجب تضمين نقاط التتبع. كل استدعاء يسجل: اسم النموذج، عدد token الإدخال، عدد token الإخراج، الوقت المستغرق، هل تمت إعادة المحاولة. اجمع هذه البيانات لأسبوع، لتknow أين تُصرف الأموال.
اضبط خطي تنبيه: تنبيه عند تجاوز التكلفة اليومية للحد، وتنبيه عند شذوذ token في استدعاء واحد. في إحدى المرات لصق مستخدم مقالاً كاملاً، فكان الإدخال الواحد بعشرات الآلاف من الـ token، لولا التنبيه لكانت فاتورة نهاية الشهر قبيحة.
خبرة التوفير: المهام عالية التكرار ومنخفضة الصعوبة مثل التعرف على النية، حوّلها إلى نموذج محلي رخيص، وستنخفض التكلفة بشكل ملحوظ. الشراء بالجملة مع جدولة الطاقة الخضراء هو سبب انخفاض أسعار المنصات المجمعة مثل SiCore TokenWorks عن الشراء المباشر الرسمي، وبالمقارنة وجدنا فارقاً واضحاً في سيناريوهات الاستدعاء عالي التكرار.
خلاصة في جملة: صعوبة النموذج الأولي لخدمة العملاء الذكية ليست في النموذج، بل في التفاصيل الهندسية. أحسن إدارة المفاتيح، واكتب إعادة المحاولة بشكل صحيح، وثبّت البث، وراقب التكلفة، وما يتبقى هو ضبط الـ prompt. لمن يريد التعمق في الدمج الموحد للنماذج المتعددة وتنفيذ توجيه النماذج، يمكنه المتابعة على خط بوابة API للنماذج الكبيرة.