الدرس 21 من 23

دراسات حالة المقابلات

دراسة حالة: دعم العملاء بالذكاء الاصطناعي

3 دقيقة للقراءة

لنستعرض مقابلة تصميم نظام كاملة لوكيل دعم عملاء بالذكاء الاصطناعي. هذا يوضح كيفية تطبيق إطار RADIO على مشكلة حقيقية.

سؤال المقابلة

"صمم نظام دعم عملاء يعمل بالذكاء الاصطناعي لشركة تجارة إلكترونية تتعامل مع 100,000 تذكرة دعم يومياً. يجب أن يحل النظام المشاكل البسيطة تلقائياً مع تصعيد المعقدة للوكلاء البشريين."

الخطوة 1: المتطلبات (R)

أسئلة توضيحية للسؤال:

  • ما أنواع التذاكر؟ (الطلبات، الإرجاع، مشاكل الحساب، أسئلة المنتجات)
  • ما هو معدل الأتمتة المستهدف؟ (افترض 70%)
  • ما اللغات؟ (الإنجليزية + الإسبانية مبدئياً)
  • متطلبات SLA؟ (الاستجابة الأولى < 30 ثانية)
  • قيود الميزانية؟ (افترض 50 ألف دولار/شهر للذكاء الاصطناعي)

المتطلبات الوظيفية:

  • تصنيف التذاكر الواردة حسب النوع والإلحاح
  • الحل التلقائي للمشاكل الشائعة (حالة الطلب، سياسة الإرجاع)
  • تصعيد المشاكل المعقدة مع ملخص السياق
  • دعم المحادثات متعددة الجولات
  • التعلم من حلول الوكلاء البشريين

المتطلبات غير الوظيفية:

  • 99.9% وقت التشغيل
  • < 2 ثانية وقت الاستجابة
  • معالجة 100 ألف تذكرة/يوم (~1.2 تذكرة/ثانية متوسط، 5x ذروة)
  • التكلفة أقل من 0.50 دولار لكل تذكرة محلولة

الخطوة 2: الهندسة (A)

┌─────────────────────────────────────────────────────────────────────┐
│                        قنوات العملاء                                 │
│              (ودجت الدردشة، البريد الإلكتروني، تطبيق الجوال)          │
└─────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│                   بوابة API + تحديد المعدل                           │
└─────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│                      خدمة توجيه التذاكر                              │
│  - تصنيف النية (مصنف مضبوط)                                          │
│  - تعيين الأولوية                                                    │
│  - كشف اللغة                                                         │
└─────────────────────────────────────────────────────────────────────┘
                    │                              │
           (تلقائي)│                      (معقد)│
                    ▼                              ▼
┌─────────────────────────┐       ┌────────────────────────────────────┐
│       وكيل الحل        │       │         التصعيد البشري             │
│       التلقائي         │       │                                    │
│                         │       │  - مولد ملخص السياق               │
│  - RAG للسياسات        │       │  - الاستجابات المقترحة             │
│  - أداة البحث عن الطلب  │       │  - قائمة انتظار الوكيل البشري      │
│  - بدء الإرجاع         │       │                                    │
└─────────────────────────┘       └────────────────────────────────────┘
                    │                              │
                    └──────────────┬───────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│                        تسليم الاستجابة                               │
│                      + جمع الملاحظات                                 │
└─────────────────────────────────────────────────────────────────────┘

الخطوة 3: البيانات (D)

قاعدة المعرفة (RAG):

knowledge_sources = {
    "policies": {
        "source": "internal_docs",
        "update_frequency": "daily",
        "chunks": 5000,
        "examples": ["سياسة الإرجاع", "أوقات الشحن", "الضمان"]
    },
    "product_catalog": {
        "source": "product_db",
        "update_frequency": "real-time",
        "chunks": 50000,
        "examples": ["مواصفات المنتج", "التوافق", "التوفر"]
    },
    "past_resolutions": {
        "source": "ticket_history",
        "update_frequency": "weekly",
        "chunks": 100000,
        "examples": ["حلول تذاكر مشابهة", "استجابات الوكلاء"]
    }
}

أدوات الوكيل:

tools = [
    {
        "name": "lookup_order",
        "description": "الحصول على حالة الطلب، التتبع، العناصر",
        "requires": ["رقم_الطلب أو البريد_الإلكتروني"]
    },
    {
        "name": "initiate_return",
        "description": "بدء عملية الإرجاع للعناصر المؤهلة",
        "requires": ["رقم_الطلب", "رقم_العنصر", "السبب"],
        "side_effects": True
    },
    {
        "name": "search_knowledge_base",
        "description": "البحث في السياسات ومعلومات المنتجات",
        "requires": ["الاستعلام"]
    },
    {
        "name": "escalate_to_human",
        "description": "النقل للبشري مع السياق",
        "requires": ["السبب", "الإلحاح"]
    }
]

الخطوة 4: البنية التحتية (I)

استراتيجية التوسع:

scaling_config = {
    "ticket_router": {
        "type": "kubernetes_deployment",
        "min_replicas": 3,
        "max_replicas": 20,
        "scale_metric": "requests_per_second",
        "target": 100  # طلبات لكل pod
    },
    "auto_resolution_agent": {
        "type": "kubernetes_deployment",
        "min_replicas": 5,
        "max_replicas": 50,
        "scale_metric": "queue_depth",
        "target": 10  # تذاكر لكل pod
    },
    "vector_database": {
        "type": "managed_pinecone",
        "pods": 3,
        "replicas": 2
    },
    "llm_api": {
        "primary": "gpt-4",
        "fallback": "gpt-3.5-turbo",
        "rate_limit": 10000  # طلبات في الدقيقة
    }
}

تقدير التكلفة:

cost_breakdown = {
    "llm_costs": {
        "auto_resolve": "70 ألف تذكرة × 0.10$ = 7,000$/يوم",
        "summarization": "30 ألف تذكرة × 0.05$ = 1,500$/يوم",
        "daily_total": "8,500$",
        "monthly_total": "255,000$"  # تجاوز الميزانية!
    },
    "optimization_needed": {
        "caching": "تخزين الاستجابات الشائعة → تخفيض 30%",
        "smaller_model": "استخدام GPT-3.5 للتصنيف → تخفيض 50%",
        "optimized_budget": "45,000$/شهر"
    }
}

الخطوة 5: العمليات (O)

المقاييس الرئيسية:

metrics_to_track = {
    "automation_rate": {
        "target": 0.70,
        "alert_threshold": 0.60
    },
    "customer_satisfaction": {
        "target": 4.5,  # من 5
        "alert_threshold": 4.0
    },
    "resolution_time": {
        "automated_target": "30 ثانية",
        "escalated_target": "4 ساعات"
    },
    "escalation_accuracy": {
        "target": 0.95,  # % من التصعيدات التي احتاجت بشري
        "false_escalation_cost": "5$ لكل تذكرة"
    }
}

حواجز الأمان:

guardrails = {
    "prohibited_actions": [
        "استرداد أكثر من 500$ بدون موافقة",
        "الوصول لمعلومات الدفع",
        "تقديم وعود عن تواريخ التسليم"
    ],
    "required_escalation": [
        "العميل يذكر إجراء قانوني",
        "المشاعر سلبية جداً (درجة < 0.2)",
        "المشكلة تتضمن مخاوف السلامة"
    ],
    "human_review_queue": [
        "أول حل لأنواع مشاكل جديدة",
        "عينة عشوائية 5% للجودة"
    ]
}

المقايضات المناقشة

القرار الخيار أ الخيار ب الاختيار السبب
النموذج GPT-4 GPT-3.5 هجين GPT-3.5 للتوجيه، GPT-4 للحل
RAG مقابل الضبط RAG الضبط الدقيق RAG السياسات تتغير بشكل متكرر
متزامن مقابل غير متزامن متزامن قائمة انتظار متزامن المستخدم يتوقع استجابة فورية

نصيحة للمقابلة

دراسة الحالة هذه توضح:

  1. النهج المنظم - إطار RADIO يبقيك منظماً
  2. تحليل المقايضات - أظهر أنك تفهم القيود
  3. الوعي بالتكلفة - التقدير الأولي تجاوز الميزانية، حسّنا
  4. الأمان أولاً - حواجز للإجراءات التلقائية

بعد ذلك، لنستكشف دراسة حالة وكيل مراجعة الكود. :::

اختبار

الوحدة 6: دراسات حالة المقابلات

خذ الاختبار