يعتمد معظم وكلاء الذكاء الاصطناعي على نموذج واحد للتعامل مع كل مرحلة من مراحل التنفيذ. حيث تمر خطوة التخطيط، واستدعاء الأدوات، واستخراج البيانات، والتلخيص، ومعالجة الأخطاء عبر نفس نموذج LLM. ورغم أن هذا النهج مباشر للنماذج الأولية، إلا أنه يؤدي إلى عدم كفاءة كبيرة في بيئات الإنتاج.
إن خطوة التخطيط التي تتطلب استنتاجاً عميقاً لا تحتاج إلى نفس النموذج المستخدم في خطوة أساسية لاستخراج بيانات JSON. فمهمة توليد الكود لها متطلبات تختلف عن مهمة التصنيف. إن استخدام نموذج استنتاج عالي المستوى مثل Claude Fable 5 أو Claude Opus 4.8 لتنسيق سلسلة نصية لتاريخ يعد هدراً مكلفاً للموارد.
يتيح لك بناء وكلاء الذكاء الاصطناعي باستخدام نماذج متعددة توجيه كل خطوة في سير العمل إلى النموذج الأنسب لتلك المهمة المحددة. يستكشف هذا الدليل كيفية تصميم وتنفيذ وإدارة هذه البنى متعددة النماذج.
إذا كنت تعمل على طبقة الـ API بدلاً من طبقة تنسيق الوكلاء، فارجع إلى تصميم الـ API الموجه للوكلاء (Agent-First API Design) ولماذا تنتقل الفرق من واجهات برمجة تطبيقات النماذج المباشرة إلى واجهة برمجة تطبيقات ذكاء اصطناعي موحدة جنباً إلى جنب مع هذا الدليل. تعمل الوكلاء متعددة النماذج بشكل أكثر موثوقية عندما تكون واجهة الـ API الأساسية مستقرة بما يكفي لتبديل النماذج دون إعادة كتابة كود التنسيق.
:::info
أهم النقاط
- مطابقة النموذج مع تعقيد المهمة: استخدم نماذج صغيرة وسريعة للتوجيه، والاستخراج، والتنسيق، واحتفظ بنماذج الاستنتاج الأكبر للتخطيط والتحليل المعقد.
- توحيد المخططات (Schemas): طبق التحقق الصارم من المخرجات (مثل Pydantic) عند كل عملية تسليم لمنع انحراف العقود عند التبديل بين مزودي النماذج المختلفين.
- التصميم من أجل الاحتياط (Fallbacks): ابنِ مسارات احتياطية آلية للتعامل مع حدود المعدل (rate limits)، أو انقطاع الخدمة لدى المزود، أو ارتفاع زمن الاستجابة دون تعطيل سير عمل الوكيل.
- مركزية القياسات (Telemetry): تتبع زمن الاستجابة، وعدد الـ tokens المدخلة/المخرجة، والتكلفة لكل خطوة لتحسين منطق التوجيه الخاص بك باستمرار. :::
معمارية الوكيل متعدد النماذج
توزع معمارية الوكيل متعدد النماذج المهام عبر نماذج متخصصة بناءً على متطلبات التعقيد والتكلفة وزمن الاستجابة.
طلب المستخدم
│
▼
┌─────────────┐
│ الموجه │ ← يصنف تعقيد المهمة
│ (نموذج سريع) │
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│نموذج │ │نموذج │
│بسيط │ │معقد │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ المجمع │ ← يدمج النتائج
│ (نموذج سريع) │
└─────────────┘
تتكون المعمارية الأساسية من خمسة مكونات رئيسية:
- الموجه (Router): نموذج سريع ومنخفض التكلفة يصنف المهام الواردة حسب التعقيد والقصد.
- مجمع النماذج (Model Pool): مجموعة من النماذج المتوافقة مع أنواع المهام المختلفة (مثل الاستنتاج، أو الاستخراج، أو توليد الكود).
- المجمع (Aggregator): نموذج سريع يدمج النتائج من الخطوات المتوازية في استجابة نهائية.
- سياسة الاحتياط (Fallback Policy): قواعد تحدد النموذج الذي يجب استخدامه إذا فشل الاختيار الأساسي، أو انتهت مهلته، أو واجه حدود المعدل.
- طبقة القياسات (Telemetry Layer): نظام تسجيل يسجل اختيارات النماذج، وزمن الاستجابة، وتكاليف الـ tokens الدقيقة لكل خطوة.
بدون سياسات الاحتياط والقياسات، قد يصبح الوكيل متعدد النماذج صعب التصحيح، مع ملفات تعريف غير متوقعة لزمن الاستجابة والتكلفة.
التنفيذ باستخدام OpenAI SDK
يسمح لك استخدام بوابة API موحدة بالوصول إلى نماذج من مزودين مختلفين باستخدام SDK ومفتاح API واحد. وهذا يبسط عملية تبديل النماذج والتوجيه.
يوضح المثال التالي تنفيذاً أساسياً للتوجيه. يجب التحقق من توفر النماذج وتسعيرها في دليل نماذج TokenLab.
from openai import OpenAI
client = OpenAI(
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
# مجمع النماذج مع مستويات التكلفة والقدرة
MODELS = {
"router": "deepseek-v4-flash", # تصنيف سريع
"simple": "deepseek-v4-flash", # استخراج، تنسيق
"reasoning": "claude-sonnet-5", # تخطيط، تحليل
"complex": "gpt-5.5", # توليد كود، منطق معقد
"budget": "deepseek-v4-flash", # معالجة كميات كبيرة
}
def route_task(task: str) -> str:
"""استخدم نموذجاً منخفض التكلفة لتصنيف تعقيد المهمة."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """صنف هذه المهمة إلى فئة واحدة فقط:
- simple: استخراج بيانات، تنسيق، ترجمة
- reasoning: تحليل، تخطيط، مقارنة
- complex: توليد كود، حل مشكلات متعدد الخطوات
- budget: معالجة كميات كبيرة، مهام غير حرجة
أجب باسم الفئة فقط بأحرف صغيرة."""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""وجه المهمة إلى النموذج المختار ونفذها."""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
وكيل واقعي: خط أنابيب مراجعة الكود
لرؤية التأثير العملي لبناء وكلاء الذكاء الاصطناعي باستخدام نماذج متعددة، ضع في اعتبارك خط أنابيب مصمماً لمراجعة طلبات السحب (pull requests). يقسم سير العمل هذا المراجعة إلى خطوات متخصصة بدلاً من إرسال فرق الكود بالكامل إلى نموذج واحد باهظ الثمن.
def review_pr(diff: str) -> dict:
"""خط أنابيب مراجعة PR متعدد النماذج."""
# الخطوة 1: تصنيف التغييرات باستخدام نموذج سريع ومنخفض التكلفة
classification = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{
"role": "user",
"content": f"صنف تغييرات الكود هذه: {diff[:2000]}\n"
"الفئات: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# الخطوة 2: إجراء فحص أمني باستخدام نموذج استنتاج قوي
security = client.chat.completions.create(
model="claude-sonnet-5",
messages=[{
"role": "system",
"content": "أنت مراجع أمني. تحقق من: "
"SQL injection, XSS, auth bypass, أسرار في الكود، "
"إلغاء تسلسل غير آمن. كن محدداً بشأن أرقام الأسطر."
}, {
"role": "user",
"content": f"راجع هذا الفرق بحثاً عن مشكلات أمنية:\n{diff}"
}]
).choices[0].message.content
# الخطوة 3: تحليل جودة الكود باستخدام نموذج للأغراض العامة
quality = client.chat.completions.create(
model="gpt-5.5",
messages=[{
"role": "user",
"content": f"راجع جودة الكود: التسمية، الهيكل، "
f"معالجة الأخطاء، تغطية الاختبارات.\n{diff}"
}]
).choices[0].message.content
# الخطوة 4: توليد ملخص باستخدام نموذج سريع ومنخفض التكلفة
summary = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{
"role": "user",
"content": f"لخص مراجعة الـ PR هذه في 3 نقاط:\n"
f"النوع: {classification}\n"
f"الأمن: {security[:500]}\n"
f"الجودة: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
تحسين التكلفة والكفاءة
يوضح الجدول أدناه توزيع النماذج لخط الأنابيب هذا. يختلف التسعير الدقيق حسب المزود والحجم؛ تحقق من الأسعار الحالية في دليل نماذج TokenLab.
| الخطوة | النموذج | الـ Tokens المدخلة | الدور / التخصص |
|---|---|---|---|
| 1. التصنيف | DeepSeek V4 Flash | ~2,100 | تصنيف سريع، توجيه منخفض التكلفة |
| 2. الأمن | Claude Sonnet 5 | ~2,500 | استنتاج عميق، تحليل أمني |
| 3. الجودة | GPT-5.5 | ~2,500 | جودة كود متقدمة ومراجعة هيكلية |
| 4. الملخص | DeepSeek V4 Flash | ~1,200 | تجميع نصوص سريع ومنخفض التكلفة |
إن تشغيل الخطوات الأربع عبر نموذج استنتاج رائد مثل Claude Sonnet 5 أو GPT-5.5 سيزيد التكاليف بشكل كبير. من خلال توجيه المهام الأبسط إلى نماذج أقل تكلفة مثل DeepSeek V4 Flash، يقلل خط الأنابيب متعدد النماذج من إنفاق الـ tokens الإجمالي مع الحفاظ على الاستنتاج العميق لخطوة التحليل الأمني الحرجة.
التوجيه حسب القدرة، وليس السعر فقط
بينما يعد خفض التكلفة هدفاً شائعاً، يجب أن تأخذ قرارات التوجيه في الاعتبار أيضاً قدرات النماذج المحددة. تقيم سياسة التوجيه القوية النماذج عبر أربعة أبعاد رئيسية:
- عمق الاستنتاج: المنطق المعقد، التخطيط، والاستنتاج متعدد الخطوات.
- نافذة السياق (Context Window): حجم المعلومات الخلفية أو الكود المطلوب للمهمة.
- موثوقية استخدام الأدوات: دقة استدعاء الوظائف وتوليد المخرجات المهيكلة.
- حساسية زمن الاستجابة: متطلبات السرعة للتطبيق الموجه للمستخدم.
تساعد هذه الأبعاد في وضع قواعد توجيه واضحة:
- مهام التفكيك والتخطيط توجه إلى نماذج الاستنتاج الثقيلة.
- مهام استخراج البيانات والتنسيق توجه إلى نماذج سريعة ومنخفضة التكلفة.
- مهام توليد الكود وتحليل البنية توجه إلى نماذج محسنة لمهام البرمجة.
- مهام تحليل المستودع بالكامل توجه إلى نماذج ذات نوافذ سياق كبيرة.
لمواءمة الموجه الخاص بك مع هذه المتطلبات، راجع مقارنة نماذج البرمجة ومقارنة الأسعار لمطابقة خطوات سير عملك مع معايير النماذج الحالية.
التكامل مع LangChain
يمكنك أيضاً تنفيذ التوجيه متعدد النماذج داخل أطر التنسيق مثل LangChain. يقوم المثال التالي بتهيئة نماذج مختلفة باستخدام رابط أساسي موحد للـ API:
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
# تهيئة النماذج بتكوينات متميزة
fast_model = ChatOpenAI(
model="deepseek-v4-flash",
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
reasoning_model = ChatOpenAI(
model="claude-sonnet-5",
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
# تحديد سلاسل متخصصة
classify_chain = ChatPromptTemplate.from_template(
"صنف قصد هذا الطلب: {input}"
) | fast_model
analyze_chain = ChatPromptTemplate.from_template(
"قم بإجراء تحليل مفصل لهذه المشكلة: {input}"
) | reasoning_model
متى تستخدم وكلاء متعدد النماذج
إدخال نماذج متعددة يضيف تعقيداً معمارياً. يكون هذا النهج مفيداً عادةً عندما:
- تنوع متطلبات المهام: يتعامل الوكيل مع مزيج من المهام البسيطة (مثل التصنيف أو التنسيق) والمهام المعقدة (مثل التخطيط الاستراتيجي أو توليد الكود).
- حجم وتكلفة مرتفعان: تكون نفقات الـ API الشهرية مرتفعة بما يكفي لجعل التحسين يحقق وفورات ذات مغزى.
- نقاط قوة النماذج المتخصصة: يستفيد سير العمل من نقاط قوة مزودين محددين، مثل نافذة سياق Gemini، أو قدرات البرمجة لدى Claude، أو سرعة استخدام الأدوات لدى GPT.
- احتياجات زمن استجابة غير متماثلة: يجب أن تعيد أجزاء معينة من سير العمل النتائج فوراً، بينما يمكن أن تستغرق خطوات الخلفية الأخرى وقتاً أطول.
بالنسبة للوكلاء ذوي الغرض الواحد أو واجهات الدردشة البسيطة، غالباً ما يكون النموذج الواحد أسهل في الصيانة. قد لا يكون العبء التشغيلي للتوجيه مبرراً إذا كان كل طلب يتطلب نفس المستوى من القدرة.
أنماط الفشل الشائعة
تقدم البنى متعددة النماذج أنماط فشل محددة تتطلب التخفيف:
1. الموجهات المفرطة في الهندسة
إذا أصبح موجه التصنيف معقداً للغاية، فقد تصبح خطوة التصنيف نفسها بطيئة ومكلفة. اجعل موجهات التوجيه موجزة وفئات التصنيف واسعة.
2. انحراف عقد المخرجات
قد تنسق النماذج المختلفة المخرجات بشكل مختلف، حتى عند توجيهها لإرجاع JSON. قد يرجع نموذج JSON خام، بينما يغلفه آخر في كتل markdown. لمنع فشل المحلل في المراحل اللاحقة، افرض مخططات صارمة باستخدام مكتبات التحقق مثل Pydantic عند كل تسليم للخطوات.
3. تدهور الجودة الصامت
إذا قامت سياسة احتياطية بتوجيه طلب إلى نموذج من مستوى أدنى أثناء انقطاع المزود الأساسي، فقد يرجع الوكيل إجابات ذات جودة أقل دون إثارة خطأ. يساعد تنفيذ استراتيجية واضحة لتحديد معدل الطلبات ونظام تنبيه في تتبع متى تكون المسارات الاحتياطية نشطة.
4. القياسات المجزأة
عندما يتم تقسيم استخدام النماذج عبر واجهات برمجة تطبيقات مباشرة متعددة للمزودين، يصبح تجميع مقاييس التكلفة والأداء أمراً صعباً. تبسط مركزية الطلبات عبر بوابة واحدة التسجيل وتتبع التكلفة.
حلقة تقييم بسيطة
للحفاظ على وكيل متعدد النماذج، أنشئ حلقة تقييم أساسية لتتبع الأداء. يمكنك تسجيل المقاييس التالية لكل تشغيل في جدول قاعدة بيانات:
- فئة المهمة: التصنيف المعين بواسطة الموجه.
- النموذج المختار: النموذج المختار لكل خطوة.
- زمن استجابة الخطوة: الوقت المستغرق لإكمال كل خطوة.
- استخدام الـ Tokens: أعداد الـ tokens المدخلة والمخرجة الدقيقة.
- حالة الاحتياط: ما إذا تم تشغيل نموذج احتياطي.
- تعليقات المستخدم: مؤشر ثنائي حول ما إذا كانت المخرجات النهائية ناجحة.
يساعد تحليل هذه البيانات في تحديد ما إذا كان الموجه يختار النماذج الصحيحة، وأي الخطوات هي التي تدفع غالبية تكاليفك، وما إذا كانت النماذج الاحتياطية تحافظ على جودة مقبولة.
الأسئلة الشائعة
كيف تتعامل مع تنسيقات الموجهات المختلفة عبر نماذج مختلفة؟
تستجيب النماذج المختلفة بشكل أفضل لهياكل موجهات مختلفة. على سبيل المثال، تعمل بعض النماذج بشكل أفضل مع موجهات النظام (system prompts)، بينما يفضل البعض الآخر التعليمات المضمنة في موجه المستخدم. للتعامل مع هذا، جرد موجهاتك في قوالب تتكيف بناءً على النموذج المستهدف، بدلاً من إرسال سلاسل نصية خام متطابقة إلى كل نموذج في مجمعك.
هل يضيف التوجيه الكثير من زمن الاستجابة للتطبيقات الموجهة للمستخدم؟
يضيف التوجيه قدراً صغيراً من زمن الاستجابة لخطوة التصنيف. يمكنك تقليل ذلك باستخدام نماذج محسنة للغاية ومنخفضة زمن الاستجابة للموجه، مع إبقاء حدود الـ tokens القصوى منخفضة (أقل من 10 tokens)، أو موازاة الخطوات عندما يمكن استنتاج التصنيف من حالة تطبيق المستخدم أو نقطة الدخول.
كيف تمنع أخطاء تحليل JSON عند التبديل بين النماذج؟
لمنع أخطاء التحليل، استخدم ميزات المخرجات المهيكلة (مثل وضع JSON أو استدعاء الأدوات) المدعومة من قبل مزودي النماذج. بالإضافة إلى ذلك، غلف جميع مخرجات النماذج في طبقة تحقق باستخدام Pydantic أو مكتبات مماثلة لتحليل، والتحقق من، وإصلاح الحمولة قبل تمريرها إلى الخطوة التالية في خط أنابيبك.
الوصول إلى كل نموذج عبر API واحد: ابدأ مع TokenLab للوصول إلى أكثر من 300 نموذج بمفتاح API واحد. ابنِ وكلاء متعددين النماذج دون إدارة حسابات مزودين متعددين أو إعادة كتابة منطق التوجيه لواجهات برمجة تطبيقات مختلفة.
المصادر
تم رصد السعر في 2026-07-07
- TokenLab model directoryتمت المراجعة في 2026-07-07
- Berkeley Function Calling Leaderboardتمت المراجعة في 2026-07-09
- SWE-benchتمت المراجعة في 2026-07-09
- RouteLLM paperتمت المراجعة في 2026-07-09
- Braintrust LLM router guideتمت المراجعة في 2026-07-09



