Evaluations | The .NET Blog

تقييمات موجه النماذج هي الخطوة التي تتجاوزها فرق كثيرة

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

تُرجِمت هذه المقالة تلقائيًا. للاطلاع على النسخة الأصلية بالإنجليزية، انقر هنا.

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

ولهذا السبب فإن مستودع تقييم موجه النماذج الجديد مفيد.

فهو يمنح الفرق طريقة أكثر واقعية للإجابة عن الأسئلة التي تهم فعلًا:

هل يحافظ التوجيه على الجودة؟
هل يحسن التكلفة؟
ماذا يفعل بزمن الاستجابة؟
ماذا يتغير إذا قيدت مجموعة النماذج؟

المقال الأصلي يطرح الأسئلة الصحيحة

من الأشياء التي أعجبتني في المقال الأصلي أنه لا يتعامل مع موجه النماذج على أنه جيد بديهياً.

بدلاً من ذلك، يطرح الأسئلة غير المريحة ولكن الصحيحة:

“على مطالبي، هل يطابق النموذج الذي اختاره موجه النماذج تلقائيًا أو يتفوق على النموذج الفردي الذي كنت سأختاره؟”
“هل أنا أوفر المال فعلاً من البداية إلى النهاية، أم أنني فقط أنقل الإنفاق من مكان إلى آخر؟”

هذا هو الموقف الصحيح تمامًا.

لأن التوجيه التلقائي مغرٍ، لكنه لا يزال قرارًا على مستوى النظام. وقرارات الأنظمة يجب أن تُقاس، لا أن يُعجب بها فقط.

لماذا هذا المستودع أهم مما يبدو في البداية

على مستوى واحد، هذا مجرد مستودع تقييم.

وعلى مستوى آخر، هو علامة على النضج.

إنه يقول: إذا أردت تبنّي التوجيه التلقائي، فإليك طريقة أكثر انضباطًا للاختبار:

الجودة
التكلفة
زمن الاستجابة
مقايضات المجموعة الفرعية
سلوك توزيع النماذج

هذا أفضل بكثير من التعامل مع التوجيه كصندوق أسود بعلامة تجارية جيدة.

رأيي

هذا مثال جيد على نوع الأدوات التي تحتاجها منصات الذكاء الاصطناعي أكثر: ليس مزيدًا من السحر، بل مزيدًا من الطرق للتحقق من هذا السحر قبل أن تثق به.

هذه هي الطريقة التي تتجنب بها الفرق بناء ثقة مكلفة فوق افتراضات غير مختبرة.

المقال الأصلي: How to run evals for the model router

التحدي الأصعب في تطوير الذكاء الاصطناعي لم يعد الوصول إلى النموذج. بل تشغيل النموذج المناسب بإتقان

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

تمت ترجمة هذه المقالة تلقائيًا. للنسخة الأصلية، انقر هنا.

نحن تجاوزنا مرحلة أن مجرد امتلاك الوصول إلى نموذج قوي كان كافيًا.

هذا ما تفهمه جيدًا إرشادات Foundry الجديدة لإدارة النماذج والتكلفة والجودة.

التحدي الحقيقي الآن تشغيلي:

اختيار النموذج المناسب لكل عبء عمل
التحقق منه مقابل بياناتك الخاصة
إدارة الكمون والإنفاق
حوكمة الترقيات ومخاطر الانحدار

هذا ما تحتاج الفرق الجادة إلى التميز فيه.

المقال الأصلي يعرّف المشكلة بالشكل الصحيح

جملة واحدة من المقال الأصلي تلتقط هذا التحول جيدًا جدًا:

“أصعب جزء في بناء أنظمة الذكاء الاصطناعي اليوم لم يعد الوصول إلى نموذج قادر. بل معرفة كيفية اختيار النموذج المناسب والتحقق منه وتحسينه وتشغيله عبر دورة الحياة الكاملة لتطبيق حقيقي.”

هذا هو التشخيص الصحيح تمامًا.

كثير من الفرق لا تزال تعتقد أن اختيار النموذج هو القرار الأساسي.

ليس كذلك.

تشغيل النموذج هو المشكلة الأكبر:

أي عبء عمل يحصل على أي نموذج؟
كيف تُثبت الجودة؟
ما شكل التكلفة المقبول؟
ماذا يحدث عندما يظهر نموذج جديد أو يتراجع نموذج قديم؟
كيف تختبر تغييرًا من دون كسر سير العمل الحقيقي؟

هذا هو العمل الهندسي الحقيقي الآن.

لماذا هذا المقال من Foundry مفيد

أحب هذا المقال لأنه يتحدث عن أنظمة الذكاء الاصطناعي بالطريقة التي يفكر بها مهندسو المنصات ذوو الخبرة فعلًا.

ليس كأنه “اختر أذكى نموذج وامضِ”.

بل كنظم تعيش تحت مفاضلات:

القدرة
الكمون
التكلفة
الأمان
الحوكمة
ضغط الترقيات

هذا أكثر فائدة بكثير من التفاؤل القائم على المقارنات المعيارية.

التحول الأهم هو التفكير الذي يبدأ بالمعايير

يقترح المقال الأصلي تحديد معايير النجاح قبل فتح كتالوج النماذج.

أعتقد أن هذه من أهم العادات التي يمكن للفرق تبنيها.

إذا فتحت الكتالوج أولًا، فأنت ترتكز على السمعة.

إذا حددت المعايير أولًا، فأنت ترتكز على واقع عبء العمل.

هذا مسار أكثر صحة.

لأن النموذج الذي يفوز في اختبار معياري ليس بالضرورة هو النموذج الذي يفوز في:

مطالباتك
ميزانية الكمون لديك
حدود التكلفة الخاصة بك
متطلبات الحوكمة لديك

هذا الفرق هو حيث يبدأ نضج هندسة الذكاء الاصطناعي.

قصة تعدد النماذج تتحول إلى ميزة حقيقية

شيء آخر يعجبني هو الطرح الصريح بأنه لا يرتبط بنموذج واحد.

المقال يعرض Foundry ليس كوجهة لنموذج واحد، بل كسطح تشغيلي عبر:

نماذج Microsoft
نماذج الشركاء
النماذج مفتوحة المصدر
النماذج المعاد تدريبها
استراتيجيات التوجيه والتحسين

هذا مهم لأن مرونة النماذج لم تعد ترفًا. إنها جزء من إدارة المخاطر.

إذا تغيرت الجودة، أو تحركت الأسعار، أو أصبحت الحصص محدودة، فستحتاج الفرق إلى بدائل.

التحكم في التكلفة ليس موضوعًا ثانويًا

المقال أيضًا محق عندما يصوغ التكلفة كاعتبار معماري.

هذا ليس مشكلة “سنحسنها لاحقًا”.

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

لهذا أعتقد أن الأقسام المتعلقة بـ:

التوجيه
التجميع
التخزين المؤقت
القدرة المخصصة
إدارة الحصص

أهم مما قد يظنه كثير من الناس.

الفرق التي تعامل انضباط التكلفة كجزء من تصميم النظام ستصمد زمنًا أفضل بكثير من الفرق التي تتعامل معه كعمل تنظيف لاحق.

وجهة نظري

هذا مقال مفيد من Foundry لأنه يتحدث عن أنظمة الذكاء الاصطناعي كما يجب على المهندسين المتمرسين تشغيلها فعلًا.

ليس كعروض. ليس كنماذج أولية لمرة واحدة. وليس كسياحة على القوائم المعيارية.

بل كنُظم تشغيل لأعباء العمل والقيود والمفاضلات والتغير المستمر.

هذا هو مستوى النقاش الذي يجب أن يواصل التقدم إليه.

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

المقال الأصلي: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

قصة Foundry من المراقبة إلى العائد على الاستثمار هي ما تحتاجه منصات الوكلاء الجادة

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

تمت ترجمة هذه المقالة تلقائيًا. للنسخة الأصلية، انقر هنا.

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

لهذا تبدو قصة Foundry الجديدة من المراقبة إلى ROI مهمة.

الرسالة الحقيقية ليست “أضفنا المزيد من لوحات المعلومات”.

الرسالة الحقيقية هي أن منصات الوكلاء الجادة تحتاج إلى حلقة تشغيل مستمرة:

تتبع ما حدث
تقييم ما إذا كان جيدًا
تحسين ما يحتاج إلى عمل
ربط النتيجة بالقيمة التجارية

هذه قصة أقوى بكثير من الكلام الإنشائي المعتاد حول المنصات.

الجملة الأساسية في المقال الأصلي تقول كل شيء

يفتتح المنشور الأصلي بجملة أرى أن على كل فريق يبني وكلاء أن ينتبه إليها:

“إطلاق وكيل ذكاء اصطناعي هو الجزء السهل. أما الحفاظ عليه دقيقًا وآمنًا وخاضعًا للمساءلة في الإنتاج فهو حيث تتعثر الفرق.”

هذا صحيح تمامًا.

لقد تجاوزنا بالفعل المرحلة التي كان فيها السؤال الرئيسي هو: “هل أستطيع أن أجعل الوكيل يفعل شيئًا رائعًا؟”

السؤال الأصعب والأكثر قيمة هو:

هل أستطيع تشغيل هذا الشيء بعد أن يبدأ في التفاعل مع مستخدمين حقيقيين وأدوات حقيقية وتكاليف حقيقية؟

هذا هو الاتجاه الذي تحاول Foundry دفع النقاش نحوه.

لماذا هذا أهم من مجرد عرض توضيحي آخر لوكيل

العديد من إعلانات وكلاء الذكاء الاصطناعي لا تزال تركز على الإنشاء: ابنِ الوكيل، وصّل الأدوات، وجّه المهام، وأطلق الواجهة.

كل ذلك جيد.

لكن الأسئلة التشغيلية هي ما يجعل معظم الأنظمة الجادة إما مستدامة أو تجارب مكلفة:

ماذا يفعل الوكيل فعليًا في الإنتاج؟
هل فعل الشيء الصحيح؟
هل يزداد سوءًا بمرور الوقت؟
هل هو مكلف أكثر من القيمة التي يخلقها؟
ما تغييرات الإعدادات التي حسّنت الجودة فعلًا؟

لهذا أعتقد أن إعلان Foundry أهم من ملخص الميزات المعتاد. إنه يحاول تعريف حلقة Agent DevOps، لا مجرد قصة إنشاء وكيل.

الحلقة ذات الأجزاء الأربعة هي المنتج الحقيقي هنا

ينظم المقال المنصة عمليًا حول أربع قدرات:

Trace
Evaluate
Monitor
Optimize

هذا هو الشكل الصحيح.

وأنا أزعم أن أي منصة تريد أن تؤخذ بجدية في أحمال عمل إنتاج الوكلاء ستحتاج في النهاية إلى هذه العناصر الأربعة كلها.

التتبع وحده لا يكفي.

التقييم وحده لا يكفي.

التحسين من دون أدلة ليس سوى تخمين.

والحديث عن ROI من دون telemetry غالبًا مجرد مسرحية.

زاوية التشغيل البيني ذكية بشكل خاص

أحد أقوى قرارات الإعلان هو أن Foundry لا تتظاهر بأن كل وكيل سيُبنى في إطار عمل واحد.

المنشور الأصلي يتحدث صراحة عن امتداد التتبع والتقييم عبر:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
الأطر المخصصة عبر OpenTelemetry

هذا مهم.

لأن الارتباط بمنصة واحدة هو من أسرع الطرق لجعل قصة تشغيل كانت مفيدة في الأصل أقل جاذبية.

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

قد يصبح التقييم بمعايير محددة أهم مما يتوقعه الناس

جزء التقييم بالمعايير يستحق الإشارة إليه أيضًا.

أعتقد أن هذا أحد أكثر الإضافات عملية في المنشور كله.

لماذا؟ لأن “الجيد” يعتمد على السياق.

يقول المقال إن التقييم بالمعايير يولد “معايير تقييم تراعي السياق انطلاقًا من السلوك المقصود للوكيل”. وهذا هو الاتجاه الذي تحتاجه هذه الأنظمة بالضبط.

تقييم الجودة العام مفيد.

لكن في النهاية تحتاج الفرق إلى تقييم الوكلاء وفق معاييرها الخاصة:

النبرة
إنجاز المهمة
الالتزام بالسياسات
توقعات الكمون
حدود التكلفة
القواعد التجارية الخاصة بالمجال

هنا يبدأ التقييم في أن يصبح ذا معنى تشغيليًا بدل أن يكون مثيرًا للاهتمام أكاديميًا.

ROI هو الجزء الأكثر إزعاجًا، ولهذا هو مهم

وأعتقد أيضًا أن جزء ROI في الإعلان مهم لأنه مزعج تحديدًا.

يسأل المنشور السؤال مباشرة:

“هل هذا الوكيل يستحق ما يكلفه؟”

هذا السؤال يتم تجاهله كثيرًا في أحاديث الذكاء الاصطناعي.

لكنه السؤال الصحيح.

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

وبصراحة، هذه اللغة المشتركة مطلوبة بشدة.

رأيي

هذا من أفضل الإعلانات على مستوى المنصة في هذه المجموعة لأنه يركز على تشغيل الوكلاء، لا مجرد بنائهم.

وهنا يبدأ العمل الصعب فعلاً.

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

قصة Foundry هذه تحاول التحرك في هذا الاتجاه بالضبط.

ولهذا تستحق أن تؤخذ بجدية.

المنشور الأصلي: Build 2026: From observability to ROI for AI agents on any framework