تستخدم معظم وكلاء الذكاء الاصطناعي نموذجاً واحداً لكل شيء. خطوة التخطيط، استدعاءات الأدوات، التلخيص، واستعادة الأخطاء. هذا يعمل في العروض التجريبية، لكنه في بيئة الإنتاج يعتبر هدراً.
خطوة التخطيط التي تتطلب تفكيراً عميقاً (deep reasoning) لا تحتاج إلى نفس النموذج الذي تحتاجه خطوة استخراج JSON. مهمة توليد الكود لها متطلبات تختلف عن مهمة التصنيف. استخدام Claude Opus 4.6 (25 دولاراً لكل 1M output tokens) لتنسيق سلسلة تاريخ يشبه توظيف مهندس معماري خبير لطلاء جدار.
إليك كيفية بناء وكلاء يقومون بتوجيه كل خطوة إلى النموذج الأمثل.
إذا كنت تعمل على طبقة API بدلاً من طبقة الوكيل، فاقرأ Agent-First API Design و Why Teams Switch from Direct Model APIs to a Unified AI API جنباً إلى جنب مع هذه الصفحة. يعمل الوكلاء متعددو النماذج بشكل أفضل عندما يكون سطح API الأساسي مستقراً بما يكفي لتبديل النماذج دون إعادة كتابة كود التنسيق (orchestration).
هيكلية الوكيل متعدد النماذج
User Request
│
▼
┌─────────────┐
│ Router │ ← Classifies task complexity
│ (fast model)│
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│Simple│ │Complex│
│Model │ │Model │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ Aggregator │ ← Combines results
│ (fast model)│
└─────────────┘
ثلاثة مكونات:
- موجه (Router) يصنف المهام الواردة حسب تعقيدها
- مجموعة من النماذج (Pool of models) متوافقة مع أنواع المهام المختلفة
- مجمع (Aggregator) يجمع النتائج عند الحاجة
في الممارسة العملية، يحتاج وكلاء الإنتاج عادةً إلى قطعتين إضافيتين:
- سياسة تراجع (Fallback policy) عند فشل النموذج المفضل أو تباطؤه
- طبقة قياس عن بعد (Telemetry layer) تسجل اختيار النموذج، الـ latency، والتكلفة لكل خطوة
بدون هذين المكونين، يتحول الوكيل متعدد النماذج بسرعة إلى "صندوق أسود" بسلوك غير متوقع.
التنفيذ باستخدام OpenAI SDK
باستخدام مفتاح API واحد من خلال مجمع، يمكنك الوصول إلى جميع النماذج دون إدارة عدة SDKs:
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Model pool with cost/capability tiers
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - fast classification
"simple": "gpt-4.1-mini", # $0.40/1M in - extraction, formatting
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - planning, analysis
"complex": "gpt-4.1", # $2.00/1M in - code gen, multi-step
"budget": "deepseek-chat", # $0.28/1M in - bulk processing
}
def route_task(task: str) -> str:
"""Use a cheap model to classify task complexity."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """Classify this task into one category:
- simple: data extraction, formatting, translation
- reasoning: analysis, planning, comparison
- complex: code generation, multi-step problem solving
- budget: bulk processing, non-critical tasks
Reply with just the category name."""},
{"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:
"""Route task to appropriate model and execute."""
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:
"""Multi-model PR review pipeline."""
# Step 1: Classify changes (cheap model)
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Classify these code changes: {diff[:2000]}\n"
"Categories: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# Step 2: Security scan (reasoning model)
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "You are a security reviewer. Check for: "
"SQL injection, XSS, auth bypass, secrets in code, "
"unsafe deserialization. Be specific about line numbers."
}, {
"role": "user",
"content": f"Review this diff for security issues:\n{diff}"
}]
).choices[0].message.content
# Step 3: Code quality (general model)
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"Review code quality: naming, structure, "
f"error handling, test coverage.\n{diff}"
}]
).choices[0].message.content
# Step 4: Summary (cheap model)
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Summarize this PR review in 3 bullet points:\n"
f"Type: {classification}\n"
f"Security: {security[:500]}\n"
f"Quality: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
تحليل التكلفة لمراجعة PR نموذجية (diff بحجم 2K token):
| الخطوة | النموذج | Input Tokens | التكلفة |
|---|---|---|---|
| Classify | GPT-4.1-mini | ~2,100 | $0.0008 |
| Security | Claude Sonnet 4.6 | ~2,500 | $0.0075 |
| Quality | GPT-4.1 | ~2,500 | $0.0050 |
| Summary | GPT-4.1-mini | ~1,200 | $0.0005 |
| الإجمالي | ~$0.014 |
استخدام Claude Sonnet 4.6 لجميع الخطوات الأربع سيكلف حوالي 0.028 دولار. النهج متعدد النماذج يخفض التكاليف بنسبة 50% مع استخدام أقوى نموذج في الخطوة الأكثر أهمية (المراجعة الأمنية).
التوجيه حسب القدرة، وليس السعر فقط
تبدأ العديد من الفرق التوجيه متعدد النماذج بقاعدة بسيطة: المهام المكلفة تذهب للنماذج المكلفة، والمهام الرخيصة تذهب للنماذج الرخيصة.
هذه خطوة أولى جيدة، لكنها ليست كافية.
تعتمد سياسة التوجيه الأقوى على أربعة أبعاد:
- عمق التفكير (reasoning depth)
- طول السياق (context length)
- موثوقية استخدام الأدوات (tool-use reliability)
- الحساسية للتأخير (latency sensitivity)
يؤدي ذلك إلى قواعد أفضل:
- التخطيط والتفكيك يذهبان إلى نموذج قوي في التفكير (reasoning-heavy)
- الاستخراج والتنسيق يذهبان إلى نموذج رخيص وسريع
- مراجعة الكود تذهب إلى النموذج الذي يتمتع بأفضل سلوك في اكتشاف الأخطاء (bug-finding)
- التحليل على مستوى المستودع (repo-wide) يذهب إلى النموذج الذي يحتوي على أكبر نافذة سياق (context window)
هذا هو نفس السبب الذي يجعل coding model comparison و pricing comparison مصادر يجب أن تغذي الموجه الخاص بك بدلاً من بقائها في ملف أبحاث منفصل.
التكامل مع LangChain
from langchain_openai import ChatOpenAI
# Create model instances with different configs
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Use in LangChain chains
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
متى تستخدم الوكلاء متعددي النماذج
يضيف التوجيه متعدد النماذج تعقيداً. وهو يستحق العناء عندما:
- يتعامل وكيلك مع أنواع مهام متنوعة (وليس مجرد دردشة)
- تتجاوز تكاليف API الشهرية 100 دولار (تصبح الوفورات ذات مغزى)
- تحتاج إلى نقاط قوة محددة في النماذج (Claude للكود، Gemini للسياق الطويل، GPT للسرعة)
- يهمك التأخير (latency) في بعض الخطوات دون غيرها
بالنسبة لروبوتات الدردشة البسيطة أو الوكلاء أحاديي الغرض، فإن النموذج الواحد يكفي. لا مبرر لتعقيد التوجيه عندما تحتاج كل طلباتك إلى نفس القدرة.
نقطة التحول عادة ما تكون واحدة من هذه الحالات:
- أنت تدفع مقابل تفكير عالي المستوى (high-end reasoning) لمهام منخفضة القيمة
- أصبح انقطاع خدمة أحد المزودين يمثل مخاطرة حقيقية على العمل
- تختلف احتياجات السياق (context) بشكل كبير عبر سير العمل
- تحتاج إلى مراحل مراجعة / استخراج / تلخيص أرخص حول مرحلة أساسية واحدة مكلفة
إذا لم يكن أي من ذلك صحيحاً، فإن النموذج الواحد لا يزال هو الإجابة الصحيحة.
أنماط الفشل الشائعة
تفشل الأنظمة متعددة النماذج بطرق يمكن التنبؤ بها:
1. الموجه ذكي أكثر من اللازم
إذا أصبح prompt الموجه عبارة عن تمرين تصنيف ضخم، فستنفق الكثير لمجرد اتخاذ قرار بشأن ما يجب فعله. اجعل الموجه رخيصاً وبسيطاً.
2. انحراف عقود المخرجات (Output contracts drift)
يعيد أحد النماذج JSON نظيفاً، بينما يعيد نموذج آخر نصاً يتضمن كتلة JSON، مما يؤدي إلى تعطل المحلل (parser) في الخطوات التالية. استخدم schemas واضحة وتحققاً من الصحة (validation) عند كل عملية تسليم.
3. التراجع (Fallback) يغير الجودة بصمت
توجيه الطلب إلى نموذج أرخص أثناء ضغط المزود قد يجعل الوكيل يبدو غير مستقر إذا رأى المستخدم جودة مختلفة تماماً. لهذا السبب تنتمي rate limiting strategy إلى صلب التصميم، وليس كفكرة لاحقة.
4. غياب تقارير التكلفة
إذا لم تقم بتسجيل اختيار النموذج، التكلفة، والـ latency لكل خطوة، فلن تتمكن من معرفة ما إذا كان التصميم متعدد النماذج يوفر المال حقاً.
حلقة تقييم بسيطة
لا تحتاج إلى منصة تقييم ضخمة لتشغيل وكيل متعدد النماذج بمسؤولية.
ابدأ بجدول واحد أو جدول قاعدة بيانات واحد لكل تشغيل:
- فئة مهمة المستخدم
- قرار الموجه
- النموذج النهائي المستخدم في كل خطوة
- الـ latency في كل خطوة
- إجمالي تكلفة الـ tokens
- ما إذا كان قد تم تفعيل التراجع (fallback)
- ما إذا كان المستخدم قد قبل الإجابة
يمنحك ذلك إشارات كافية للإجابة على الأسئلة المهمة:
- هل يختار الموجه النموذج المكلف الصحيح بشكل متكرر بما يكفي؟
- أي خطوة تستهلك معظم الميزانية؟
- هل تنقذ عمليات التراجع (fallbacks) عمليات التشغيل أم أنها تخفي عدم الاستقرار فقط؟
- هل المسار الرخيص جيد بما يكفي للمهام المتكررة؟
هذا هو السبب أيضاً في أن البوابة الموحدة (unified gateway) تساعد. عندما يتوزع استخدام النماذج عبر العديد من المزودين، يصعب تجميع سجل تشغيل واحد قابل للمقارنة. عندما يمر كل شيء عبر طبقة API واحدة، ينخفض عبء المراقبة.
اجعل الهيكلية "مملة"
أفضل الوكلاء متعددي النماذج لا يبدون غريبين، بل يبدون "مملين" من الناحية التشغيلية (أي مستقرين ويمكن التنبؤ بسلوكهم).
وهذا يعني:
- شكل طلب واحد مستقر في طبقة التنسيق الخاصة بك
- مكان واحد لتعريف قواعد التوجيه
- مكان واحد لفحص التكلفة والـ latency
- سياسة تراجع واحدة لكل عائلة من المهام
- مصدر واحد للحقيقة لقوائم النماذج المسموح بها (allowlists)
إذا كان مخطط الوكيل الخاص بك يبدو ذكياً ولكن المشغلين لا يستطيعون شرح سبب ذهاب الطلب إلى نموذج دون آخر، فإن التصميم لم يكتمل بعد.
متى لا تستخدم وكيلاً متعدد النماذج
هناك أيضاً حالات واضحة يفوز فيها التصميم الأبسط.
لا تضف التوجيه لمجرد أن كتالوج النماذج كبير.
التزم بنموذج واحد عندما:
- يقوم المنتج بمهمة واحدة ضيقة بشكل متكرر
- تكون فروق الجودة بين النماذج غير ذات صلة بالمستخدم
- تكون حركة المرور (traffic) منخفضة جداً بحيث لا تهم تحسينات التكلفة
- تكون أدوات المراقبة والتشغيل لديك غير كافية بالفعل
- لا تملك بعد تقييمات (evals) قوية بما يكفي لمعرفة ما إذا كان التوجيه قد ساعد أم أضر
غالباً ما يتفوق نموذج واحد تم اختياره جيداً مع محاولات إعادة (retries) جيدة، ونظافة في الـ prompts، وقابلية للملاحظة (observability)، على مخطط فلاشي متعدد النماذج لا يثق به أحد.
السؤال الصحيح ليس "هل يمكننا التوجيه؟" بل "هل ينتج عن التوجيه جودة أفضل، تكلفة أقل، أو سلوك فشل أكثر أماناً لسير العمل هذا؟"
إذا كانت الإجابة غامضة، فحافظ على بساطة الهيكلية حتى يصبح سير العمل نفسه أكثر تنوعاً.
أهم النقاط المستفادة
- استخدم أرخص نموذج يتعامل مع كل خطوة بشكل جيد
- احجز النماذج المكلفة للمهام التي تحتاجها حقاً
- يجب أن تستخدم خطوات التصنيف/التوجيه دائماً أرخص نموذج متاح
- قس التكلفة الفعلية لكل تشغيل للوكيل، وليس فقط سعر الـ token الواحد
- مجمع API بمفتاح واحد يسهل الوصول متعدد النماذج بشكل كبير
الوكلاء متعددو النماذج ليسوا أفضل بطبيعتهم. إنهم أفضل عندما يحتوي سير العمل فعلياً على أنواع مختلفة من العمل.
الوصول إلى كل نموذج عبر API واحد: يوفر LemonData أكثر من 300 نموذج بمفتاح API واحد. ابنِ وكلاء متعددي النماذج دون إدارة حسابات مزودين متعددة أو إعادة اختراع التوجيه لكل زوج من المزودين.