توجيه تذاكر الدعم مع OpenAI Decisions API: دليل عملي

ابدأ بالقرار الذي يحتاجه الكود

يمكن النظر إلى Decisions بوصفها موزّعًا يعمل ضمن قائمة محددة من الوجهات. أنت تقدّم المعطيات والسؤال، ثم يحدد تطبيقك ما يحدث بعد وصول الإجابة.

حتى 11 أكتوبر 2026، كانت الواجهة في مرحلة البيتا العامة، مع توقّع إتاحتها للجميع «خلال الأسابيع المقبلة». هذا توقّع من OpenAI، وليس موعد إطلاق محددًا. النموذج الوحيد المدعوم هو gpt-6-luna، ونقطة النهاية هي POST /v1/decisions. وتصفها OpenAI بأنها «أسرع بنحو 10 أضعاف من Responses API». تعامل مع ذلك بوصفه ادعاءً من OpenAI، لا نتيجة قياس لأداء تطبيقك. دليل Decisions من OpenAI

حدّد شكل الإجابة قبل كتابة التعليمات:

في التقييم العددي، يبدأ ترقيم المستويات من المؤشر 0. وقد تقع النتيجة بين مستويين، لأنها تلخّص عدم اليقين عبر المستويات. استخدم الاختيار عندما يحتاج الكود إلى فئة واحدة. أنواع الأسئلة

جرّب أنواع الطلبات الثلاثة

هذه أمثلة طلبات cURL الثلاثة الواردة في الدليل، نُقلت مع توحيد التنسيق وإضافة تعليقات للفصل بينها. اضبط OPENAI_API_KEY في بيئة الصدفة؛ ويحتاج مثال التحقق من الشرط أيضًا إلى ملف محلي باسم product.png. ينفّذ كل أمر طلبًا مستقلًا. راجعنا هذه الأمثلة بالرجوع إلى الدليل العام، ولم نشغّلها من حساب مسجّل الدخول. أمثلة الطلبات الأصلية

العنصران المشتركان هما input للمعطيات، وquestions للقرارات المطلوب اتخاذها بشأنها. ويحدد حقل name الخاص بالسؤال إجابته داخل مصفوفة answers التي تعيدها الواجهة. مرجع الطلبات والاستجابات

# Predicate: inspect product.png for visible damage
IMAGE_BASE64="$(base64 < product.png | tr -d '\r\n')"

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "model": "gpt-6-luna",
  "input": [{
    "role": "user",
    "content": [
      {"type": "input_text", "text": "Inspect the product in this photo."},
      {"type": "input_image", "image_url": "data:image/png;base64,$IMAGE_BASE64"}
    ]
  }],
  "questions": [{
    "type": "predicate",
    "name": "visible_damage",
    "instructions": "Does the product have visible damage, such as a crack, tear, or dent? Ignore shadows and damage to the packaging."
  }]
}
JSON

# Choice: route a customer complaint
curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "I was charged twice for my order.",
    "questions": [{
      "type": "choice",
      "name": "department",
      "instructions": "Which department should handle this complaint?",
      "choices": [
        {"value": "billing", "description": "Payments, invoices, and refunds."},
        {"value": "technical", "description": "Problems using the product."},
        {"value": "shipping", "description": "Delivery and tracking."},
        {"value": "other", "description": "Requests outside these categories."}
      ]
    }]
  }'

# Score: assess issue severity
curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "Export fails in Safari but works in Chrome.",
    "questions": [{
      "type": "score",
      "name": "severity",
      "instructions": "How severe is this issue?",
      "levels": [
        {"label": "Cosmetic", "description": "Appearance only; no lost functionality."},
        {"label": "Workaround available", "description": "A task fails, but another way works."},
        {"label": "Fully blocked", "description": "A task fails with no workaround."}
      ]
    }]
  }'

يوفّر مثال الاختيار نقطة انطلاق عملية: شكوى خصم قيمة الطلب مرتين يجب أن تُوجّه إلى إحدى قوائم العمل المحددة. أما مثال التقييم فيطرح سؤالًا مختلفًا: ما حجم التعطّل إذا أخفقت المهمة في متصفح، لكنها ما زالت تعمل في متصفح آخر؟ افصل بين الجهة المسؤولة عن التذكرة ودرجة خطورتها، حتى يمكن أن تكون مشكلة الفوترة عاجلة من دون أن تتحوّل إلى تذكرة دعم تقني.

تحقّق من الرفض قبل قراءة القيمة. تفحص أمثلة SDK في الدليل الشرط answer.type == "refusal" قبل الوصول إلى probability أو choice أو score. الرفض نتيجة مستقلة؛ فلا يُعامل كإجابة ضعيفة الثقة، ولا يُدرج ضمن فئة other. كيفية التعامل مع الرفض

توجيه تذاكر الدعم بناءً على الاختيار

اجعل إسناد التذاكر إلى قوائم العمل محور النسخة الأولى. يمكن لفريق الدعم إرسال عنوان التذكرة ورسالة العميل ذات الصلة، والحصول على القسم المختار، ثم ترك كود التطبيق المعتاد يطبّق سياسة التوجيه.

ابدأ بتعريفات قوائم العمل الواردة في الدليل، ثم استبدلها بما يطابق مسؤوليات فرقك الفعلية. احتفظ بخيار other للطلبات التي لا تندرج ضمن اختصاص الأقسام المحددة. طلب استرداد المبلغ يخص قسم الفوترة، لكن هذا التصنيف لا يمنح إذنًا بردّ المبلغ.

يوضّح هذا المقتطف الصغير كيف يطبّق التطبيق السياسة بعد تحليل استجابة JSON ناجحة واختيار إجابة department. يجب أن تتضمن thresholds حدود القبول التي حددتها باستخدام تذاكر مصنّفة مسبقًا؛ وإذا غاب حد القبول، تبقى التذكرة للمراجعة.

QUEUES = {
    "billing": "billing",
    "technical": "technical",
    "shipping": "shipping",
}

def queue_for(answer, thresholds):
    if answer.get("type") == "refusal":
        return "manual_review"
    if answer.get("type") != "choice":
        return "manual_review"
    department = answer.get("choice")
    if department not in QUEUES:  # Includes the guide's "other" choice.
        return "manual_review"
    cutoff = thresholds.get(department)
    confidence = answer.get("confidence")
    if cutoff is None or confidence is None or confidence < cutoff:
        return "manual_review"
    return QUEUES[department]

في سير العمل المقترح هنا، تبقى التذاكر أيضًا قيد المراجعة اليدوية عند حدوث أخطاء في الواجهة، أو انتهاء مهلة الانتظار، أو غياب الإجابات. سجّل إصدار السؤال، وقائمة العمل المقترحة، ومستوى الثقة، والقائمة النهائية، وأي تصحيح يجريه الموظفون. واجعل تحديث قائمة العمل آمنًا عند إعادة المحاولة، حتى لا تؤدي إعادة الطلب إلى تكرار الإسناد.

يمكن جمع أسئلة مستقلة عن التذكرة نفسها في طلب واحد. أما السؤال اللاحق الذي يتوقف معناه على إجابة سابقة، فمكانه طلب لاحق. إرشادات طرح أسئلة متعددة

اضبط حدود القبول باستخدام بيانات مصنّفة

اختر حدود القبول بناءً على قياس الأخطاء التي يستطيع نشاطك تحمّلها. لا تنشر OpenAI أرقامًا لمعايرة الثقة في الدليل، بل توجّه المطوّرين إلى استخدام بيانات مصنّفة من تطبيقاتهم. فقيمة الثقة لا تضمن أن الإجابة ستكون صحيحة بالنسبة نفسها على تذاكرك. تفسير الإجابات

ابدأ بتذاكر سابقة راجع مسؤول الدعم وجهتها الصحيحة. ضمّن طلبات قصيرة، ومشكلات متداخلة، وحالات ينقصها السياق، وشكاوى تحتوي على تعليمات موجّهة إلى النموذج. وافصل الأمثلة التي تستخدمها لضبط الأسئلة وحدود القبول عن مجموعة مستقلة تحتفظ بها للمقارنة النهائية.

قِس عدد التذاكر المسندة إلى قائمة خاطئة، ونسبة ما يُحال إلى المراجعة، والوقت الذي يقضيه الموظفون في تصحيح الإسناد. افحص كل قائمة على حدة. فقد تختلف الكلفة التشغيلية لتوجيه تذكرة شحن إلى الفوترة عن كلفة تفويت بلاغ عن اختراق حساب.

شغّل الحل المرشّح بالتوازي مع المصنّف الحالي أولًا، من دون تغيير الإسنادات الفعلية. ولا تعتمده إلا عندما تستوفي النتائج معيار قبول مكتوبًا. احتفظ بمسار التوجيه القديم للرجوع إليه عند الحاجة. هذه خطوات نشر مقترحة، وليست نتائج اختبار لهذه الواجهة.

ستة استخدامات تستحق التجربة، حسب الأولوية

أفضل الاستخدامات للبدء هي التي تكون فئاتها ثابتة، وأخطاؤها قابلة للرصد، ولديها شخص مسؤول أصلًا عن الاستثناءات. هذا الترتيب تقدير لجدوى التنفيذ، وليس ترتيبًا لنتائج الدقة.

عند تصنيف البيانات، حدّد ما إذا كان السجل قد ينتمي إلى موضوعات متعددة. فالاختيار المفرد يحدد فئة واحدة، بينما قد تلائم الأسئلة المنفصلة التصنيفات المتداخلة. ولتقييم خطورة الحوادث، عرّف الأثر بمفاهيم تشغيلية، مثل فقدان وظيفة وتوافر حلول بديلة. كلمات مثل «خطير» تترك للنموذج مساحة واسعة للتأويل.

ما الأثر الفعلي للتسعير؟

السعر الوارد في الدليل هو $0.10 لكل 1M رمز إدخال على gpt-6-luna، من دون رسوم على المخرجات أو القراءة من الذاكرة المؤقتة أو الكتابة إليها. وقد تُطبّق رسوم إضافية للمعالجة الإقليمية ومعاملات مضاعفة لسعر الإدخال عند استخدام سياق طويل. هذه أسعار Decisions؛ فلا تطبّق قاعدة الفوترة هذه على الاستدعاءات المعتادة للنموذج نفسه. تسعير Decisions

المثال التالي حساب افتراضي لدفعة طلبات، وليس قياسًا للاستخدام أو سعرًا ثابتًا لكل قرار. نفترض 100,000 استدعاء للتصنيف، يحتوي كل منها على 1,000 رمز إدخال غير مخزّن مؤقتًا، بما يشمل التعليمات والخيارات. وللاستدعاء الحالي عبر Responses، نفترض أيضًا إجمالي 50 رمز مخرجات خاضعًا للفوترة لكل استدعاء. نستخدم الأسعار الأساسية المعتادة للسياق القصير، من دون كتابة إلى الذاكرة المؤقتة أو رسوم إقليمية إضافية أو إعادة محاولات أو أي رسوم أخرى.

أسعار النموذج المعتادة مأخوذة من جدول الأسعار القياسي لدى OpenAI. في هذا المثال، يوفّر إلغاء فوترة المخرجات $2.50 على الدفعة بأكملها. وهذا وحده سبب ضعيف لإعادة كتابة تكامل يعمل بالفعل.

المبرر الأقوى تشغيلي: تقليل الانتظار في سير عمل متتابع، أو تقليل الكود اللازم لمعالجة الاستجابات، أو خفض الفرز اليدوي مع الحفاظ على معدل الخطأ نفسه. قارن بفواتيرك الفعلية وعبء المراجعة لديك. استخدام نموذج حالي أغلى، أو إجابات مولّدة أطول، يغيّر الحساب، وكذلك خصومات الذاكرة المؤقتة القائمة. ويجب أن تشمل ميزانية الانتقال وقت التطوير وكلفة التذاكر الموجّهة خطأً.

فكرتان تستحقان البناء

الخيار الأول: موجّه لتذاكر الدعم مع المراجعة وسجل التعديلات اليدوية

قد يدفع مسؤول عمليات الدعم مقابل أداة ربط تقترح قوائم عمل محددة، وتعلّق الحالات غير المؤكدة للمراجعة، وتحول تصحيحات الموظفين إلى بيانات للتقييم. المنتج المفيد هنا هو سير عمل التوجيه كاملًا، بما في ذلك صيانته.

تقدّر DataForSEO حجم البحث عن «ticket triage» بنحو 170 عملية بحث شهريًا على Google في الولايات المتحدة، وفق التحقق بتاريخ 11 أكتوبر 2026. هذا مؤشر محدود على طلب معلومات، وليس عددًا للمشترين. كما تعالج منتجات مكاتب الدعم الحالية هذه الحاجة: توفر Zendesk تصنيفات للفرز الذكي، وتشترط إضافة Copilot لاستخدامها في سير العمل. دليل الفرز من Zendesk

يمكن أن تدعم أصغر نسخة مفيدة نظام مكتب دعم واحدًا، وتستورد التذاكر السابقة، وتعرض معاينة لإسنادها إلى القوائم، وتوفّر صندوق مراجعة يسمح بتعديل القرارات يدويًا. وأقوى دليل لبيعها هو انخفاض الإحالات غير الضرورية لدى العميل. التحدي أن المنتج القائم قد يغطي هذه الحاجة بالفعل؛ فإذا كان مكتب الدعم يدير القوائم جيدًا، فإن موجّهًا إضافيًا يزيد عبء الصيانة. ركّز على مشكلة محددة في توزيع المسؤوليات أو في إحالة التذاكر بين الأنظمة.

الخيار الثاني: منصة مراجعة لتصنيفات محددة

قد يدفع فريق بحث أو بيانات مقابل منصة تقترح تصنيفات، وتجمع التصحيحات، وتبيّن الفئات التي يتكرر الخلاف حولها. تقدّر DataForSEO حجم البحث عن «automated data labeling» بنحو 90 عملية بحث شهريًا على Google في الولايات المتحدة، وفق التحقق نفسه. هذا يدل على اهتمام بالمهمة، ولا يثبت استعدادًا للدفع مقابل هذا التنفيذ بعينه.

يمكن أن تستقبل النسخة الأولى ملف CSV، وتطبّق مجموعة تصنيفات ذات إصدار محدد، وتعرض الصفوف غير المؤكدة للمراجعة، ثم تصدّر النتائج المصحّحة. احتفظ بمجموعة تقييم مستقلة حتى تتمكن من مقارنة تغييرات التصنيفات بإنصاف. المشكلة أن النموذج يستطيع إعادة إنتاج تصنيف غير واضح بكلفة زهيدة. لذلك يحتاج المنتج إلى أدوات جيدة للمراجعة وإدارة الفئات؛ فبناء واجهة حول استدعاء API يسهل تقليده.

موجّه تذاكر الدعم هو الخيار الأقوى للبدء. فوضوح المسؤولية عن قوائم العمل يوفّر خطأً يمكن رصده، وموظفًا يستطيع تصحيحه، وسير عمل متكررًا يمكن إثبات القيمة من خلاله. تحدّث إلى هذا الموظف قبل بناء منصة عامة لاتخاذ القرارات.

متى يكون الإبقاء على الحل الحالي أفضل؟

احتفظ بواجهة Responses API عندما تحتاج إلى استخراج حقول وفق مخطط JSON تحدده أنت، أو إلى تفسير مكتوب، أو إلى استدعاء أداة يطلبه النموذج مع وسيطاته. تخدم Decisions أنواع الإجابات الأضيق نطاقًا المذكورة أعلاه. إرشادات OpenAI لاختيار الواجهة

واحتفظ بالقواعد الحتمية عندما تكون الإجابة موجودة أصلًا في حقل بالحساب أو في سياسة صريحة. لا يضيف النموذج الكثير إلى قاعدة مثل «وجّه عملاء هذه المنطقة إلى هذا الفريق». وأبقِ الموافقة البشرية وفحوص صلاحيات التطبيق للإجراءات ذات العواقب المهمة. يمكن لقرار التوجيه أن يساعد في سير عمل ردّ المبالغ، لكنه لا يثبت استحقاق العميل أو صلاحية الموظف.

راجع قيود التكامل التالية قبل تحديد موعد الانتقال:

• الصور: يسمح الدليل فقط بروابط بيانات base64 المضمّنة، أي إن بايتات الصورة تُرمّز داخل الطلب نفسه. ولا تدعم تعليمات الدليل روابط صور مستضافة عبر HTTP أو HTTPS، ولا file_id، وهو معرّف يشير إلى ملف رُفع سابقًا. متطلبات إدخال الصور
• ضوابط البيانات: ينص الدليل على دعم عدم الاحتفاظ بالبيانات، Zero Data Retention أو ZDR، والاستخدام وفق HIPAA للعملاء المؤهلين. ويُدعم توطين البيانات والمعالجة الإقليمية في الولايات المتحدة وأوروبا، وتحديدًا المنطقة الاقتصادية الأوروبية EEA + سويسرا. وتسري متطلبات الأهلية والاتفاقيات والإعداد والقيود؛ فهذه ليست إعدادات افتراضية تلقائية للحساب. توافر Decisions، ضوابط البيانات لدى OpenAI
• نضج الإصدار: مرحلة البيتا العامة سبب للاحتفاظ بمسار يتيح الرجوع إلى الحل السابق. إذا كان المصنّف الحالي يحقق أهدافه، ولا يقدّم تغييره فائدة قابلة للقياس، فأبقِه كما هو.

البدائل: Jev وClef وMicrosoft-Decision-1

قارن الحلول المرشّحة باستخدام عبء العمل المصنّف نفسه قبل تغيير المزوّد. يقبل Jev من TypeSafe الحالة والأسئلة ذات الأنواع المحددة عبر واجهة System One API. ويوفّر Cloudflare Clef قرارات ذات أنواع محددة ضمن Workers AI. أما Microsoft-Decision-1، فهو متاح في Microsoft Foundry لمهام تشمل التصنيف والتوجيه وتحديد الأولويات. دليل البدء السريع من TypeSafe، وثائق Cloudflare Clef، إعلان Microsoft

اجعل التكاملات القائمة، ومتطلبات الاستضافة، ونتائج التقييم، وآلية معالجة الاستثناءات أساس اختيار قائمتك النهائية. يشرح دليلنا لتوجيه تذاكر الدعم باستخدام Jev نمط التوجيه، ويوضّح مقال هل Jev Router مجاني؟ الفرق بين برمجيات التوجيه والاستدلال المستضاف. تعامل مع صيغة طلبات كل مزوّد وطريقة تعبيره عن الثقة على حدة.

خطوتك العملية مع بداية الأسبوع

اختر استدعاء التصنيف الذي يوجّه التذاكر إلى مجموعة قائمة من قوائم العمل. اطلب من المسؤول عنه مراجعة عينة مصنّفة وممثّلة، وتوثيق معدلات الخطأ والمراجعة المقبولة، ثم مقارنة Decisions بالاستدعاء الحالي بالتوازي من دون تغيير الإسنادات. ولا تنتقل إليها إلا بعد أن تثبت جدارتها بهذا الدور في سير العمل.

إذا كنت تريد بناء سير عمل لتوجيه التذاكر حول أدواتك الحالية، فنحن نبني أنظمة ذكاء اصطناعي للإنتاج الفعلي.