Benchmark-Driven Development: Beyond TDD for AI Systems
discoveryAIbenchmarkingsoftware architecturetestinginnovationTypeScriptdevelopment methodologyexperientialinsights
I discovered Benchmark-Driven Development in early 2025 while building a translation system I had been working on for two years and several document rendering engines. The translation system became the laboratory where this methodology crystallized. I'd been working with AI systems since around 2023, and as I made strides, I realized that AI models were evolving so fast that traditional approaches couldn't keep pace.
كان ذلك في الوقت الذي ظهر فيه استدعاء الدوال للتو كابتكار في السوق، قبل أن يصبح الوكلاء المستقلون شيئًا حقيقيًا. كنت أقيم أزواج لغوية مختلفة، وبنيت خطوط أنابيب معقدة، وأدركت أنني بحاجة إلى وسيلة للمشروع نفسه لقياس القدرات حتى الدرجة الدقيقة. لم تكن المشكلة مجرد اختبار ما إذا كان شيء ما يعمل — بل كانت اكتشاف ما كان يعمل أفضل عندما يتغير المشهد كل بضعة أسابيع.
## من الاختبارات إلى المحاكاة
لقد فهمت دائمًا قيمة الاختبار، خاصةً عند بناء أنظمة المؤسسات للحكومة حيث تتطلب المتطلبات الصارمة والعقود الممولة بالكامل إثباتًا. لكن عندما فرض TDD على المشاريع التي عملت عليها، شهدت شيئًا مهمًا: الأطر تعمل فقط عندما يعتنقها الفرق فعليًا. فرض التبني الكامل نادرًا ما يكون منطقيًا.
ما تعلمته هو أن أفضل نهج غالبًا ما يكون مختلطًا—يُعتمد فقط ما يلزم. جاذبتني اختبارات القدرات الأساسية أكثر من تغطية الوحدات الشاملة. لماذا تحتفظ بآلاف الاختبارات المبعثرة عندما يمكن لسكريبت محاكاة واحد تحت 1000 سطر أن يحقق صحة سير المستخدم الكامل?
لتطبيق تجنيد سياسي، بنيت محاكاة أنشأت فرقًا وهمية، ومحاكاة انضمام ومغادرة المتسائلين، وخلق أعباء عمل واقعية، وضغط النظام على نطاق واسع. كشفت هذه كل شيء: سلوك واجهة المستخدم، عرض المخططات، سلامة البيانات في الحدود القصوى. أعطاني برنامج واحد أكثر ثقة من أي اختبارات وحدات مبعثرة قد أبدت.
في 25 سنوات من الترميز، قضيت السنوات الأخيرة 10-12 مدركًا تمامًا مدى قيمة بطاقة الأداء الممتازة يمكن أن تكون. كنت أستخدم بطاقات الأداء قبل وجود GPT، وإعادة النظر فيها مع الذكاء الاصطناعي خلال السنوات الثلاث الماضية كانت مثيرة للإعجاب. أدت تلك التجارب المحاكاة إلى الأساس لما أصبح تطوير مستند إلى المعايير.
## اللحظة التي تغير فيها كل شيء
اكتشفت الحقيقة عندما أدركت شيئًا غيّر كل شيء: **يمكن للمعيار أن يصدر ببساطة تكوينًا يدخل مباشرةً إلى الإنتاج** لقد تم اختباره بالفعل، هناك، جاهز للاتصال مع المطالبات وكل شيء كانت تلك البصيرة الكبيرة
ظهر ذلك من مواجهة مشكلة أساسية في نظام الترجمة ادعى مزودو الذكاء الاصطناعي دعم العشرات من اللغات، لكن إلى أي مدى وجود الجودة لم تكن تلك المعلومات موثقة جيدًا، وتعلمت من خلال الخبرة أنني لا أستطيع الوثوق الكامل بمطالب الموردين—ولن أجب
لذلك أنشأت حلقة تقييم معيارية تعيش في المشروع يمكنني إعطاؤها خدمة ونموذج، وستقوم بتقييم اللغات التي تجيدها فعليًا—وليس ما ادعى المورد، بل ما أظهره الأدلة التجريبية
العملية ثابتة: نفس الدخل، نفس المخرج، مخزنة باستمرار للحصول على نتائج سريعة عند تغيير المطالبات، نقوم بالاختبار A/B لاكتشاف الأفضل الموديلات التي فشلت باستمرار تم حظرها أو خفض ترتيبها لزوجين لغويين محددين مما يجعل المعايير أكثر إنتاجية
أثبت أن استخدام الذكاء الاصطناعي لبناء تكاملات الذكاء الاصطناعي قوي بشكل لا يصدق مع استدعاء الدوال والأطر المبكرة التي ستتطور إلى عوامل، استطعت بناء معايير باستخدام الذكاء الاصطناعي، مع بطاقات تقييم وتقييمات ما اكتشفته حول النماذج وقدرات اللغة اختلف بشكل كبير عن مطالب المورد بحاجة إلى أن أكون أقرب إلى الجوهر، أقرب إلى الأدلة الفعلية
```mermaid
graph TB
Problem[ادعاءات البائع]
Loop[حلقة التقييم]
Cache[ذاكرة التخزين المؤقت الثابتة]
ABTest[موجهات اختبار A/B]
Demote[فشل القائمة السوداء]
Discovery[إصدار إلى الإنتاج]
Problem -->|إنشاء| Loop
Loop -->|تمكين| Cache
Cache -->|سريع| ABTest
Cache -->|تتبع| Demote
ABTest -->|اختراق| Discovery
Demote -->|تحسين| Discovery
style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5
style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2px
```
لم تكن نظريًا. ظهرت من الألم العملي لعدم القدرة على الوثوق بادعاءات البائع وتحديث أنظمة الإنتاج باستمرار مع ظهور نماذج جديدة. تطورت المقاييس من أدوات القياس إلى مولدات التكوين.
## ما هو التطوير القائم على المعيار فعلاً
التطوير القائم على المعيار يتجاوز التحقق ليصبح عملية توليدية. حيث تتحقق الاختبارات من الدقة، يقارن المعيار الأداء عبر أبعاد متعددة. الأهم من ذلك، في التطوير القائم على المعيار، يصدر المعيار الإعداد الذي يقود نظام الإنتاج.
ما أقوله حقاً هو هذا: بدلاً من التحقق فقط مما إذا كان الكود يعمل، يقيم النظام باستمرار أي نهج يعمل أفضل، ثم يضبط نفسه تلقائياً لاستخدام هذا النهج الأمثل. احصل على ما يعمل وابنِ شيئًا يخدم سياقك فعليًا.
**التطوير القائم على الاختبار:**
```mermaid
graph TB
Test[اكتب اختبار]
Code[اكتب رمزًا]
Pass[يتم الاختبار بنجاح]
Test --> Code
Code --> Pass
style Pass fill:transparent,stroke:#10B981,stroke-width:2px
```
**التطوير القائم على المعيار:**
```mermaid
graph TB
Bench[شغل المعيار]
Compare[قارن النتائج]
Config[أنشئ إعدادًا]
Deploy[الإنتاج]
Bench --> Compare
Compare --> Config
Config --> Deploy
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
style Config fill:transparent,stroke:#3B82F6,stroke-width:2px
```
## داخل نظام الترجمة
في نظام الترجمة، بدلاً من اختيار نموذج ذكاء اصطناعي واحد وتفاؤل أنه يعمل جيداً عبر جميع أزواج اللغات، أنشأت نظام تقييم شامل يقيم عدة نماذج عبر ثلاثة مؤشرات رئيسية:
1. **جودة** - دقة الترجمة والحفاظ على الفروق الثقافية
2. **سرعة** - وقت الاستجابة لمختلف طول النصوص
3. **تكلفة** - تسعيرة كل رمز أو كل طلب
التقييمات تحدثت عن نفسها وكشفت عن رؤى مفاجئة غيّرت جذرياً نظرتي لقدرات اللغات بالذكاء الاصطناعي.
حظي باللحظة الواضحة من مشروع ترجمة مخطوطة صينية لعميل. كانت زوجته قد ألفت مخطوطة صينية ذات 175+ صفحة، وكنت أساعد في رقمنتها وترجمتها. التقطت الصفحات باستخدام ميزة التراكب في Google Translate، ثم قسّم المحتوى إلى مجموعات من 10-15 صفحة للتقييم المنهجي.
باستخدام Claude Opus—أكثر نموذج متقدم متاح في ذلك الوقت—قمت بإجراء تقييمات شاملة على كل جزء. لم يترجم الذكاء الاصطناعي فقط؛ بل حلل جودة إخراج الترجمة الآلية في Google Translate. كانت النتائج مدهشة: فقدان 30% في الفروق الثقافية، مع أمثلة محددة تُظهر بالضبط أين انكسر المعنى.
سيشرح الذكاء الاصطناعي: “هذه العبارة تعني X بالإنجليزية وفقًا للترجمة الآلية، لكن الصينية تنقل فعليًا Y—السياق الثقافي هو Z، وهذه سوء الفهم يغيّر المعنى أساسيًا.” لم تكن هذه اختلافات دقيقة. كانت خسائر كبيرة في الرسالة المقصودة للكاتب.
ما جعل هذا الاكتشاف أكثر إزعاجًا هو اختبار النماذج التي تدَّعي دعمًا لـ 50-80+ لغات. بما أنني أعرف الإسبانية بعض الشيء، تمكنت من ملاحظة خسائر مماثلة في الفروق الثقافية قد تتخطىها المقاييس الأبسط تمامًا. أدى ذلك إلى التساؤل عما يعنيه حرفًا 'اللغة المدعومة' عندما يكون هناك فقدان 30% في الفروق الثقافية مقارنةً بالبدائل الأغلى تكلفة.
كان الزوجان متأثرين بشدة بالتقرير المفصل—لم يتوقعوا هذا الدقة في تحديد أين فشلت الترجمة ولماذا. بالنسبة لي، كانت اللحظة الحاسمة: احتجت إلى معايير تقيس ما يهم فعلاً، وليس ما يدعيه البائعون. أثرت هذه التجربة مباشرة في النهج المدفوع بالمعايير والذي أصبح مركزياً في طريقة بناءي للأنظمة.
```mermaid
graph TB
Input[مجموعة اختبار]
Models[نماذج الذكاء الاصطناعي]
Bench[مجموعة المعايير]
Metrics[النتيجة: Q/S/C]
Winner[أفضل تكوين]
ProdConfig[الإنتاج]
Input --> Bench
Models --> Bench
Bench -->|الجودة| Metrics
Bench -->|السرعة| Metrics
Bench -->|التكلفة| Metrics
Metrics --> Winner
Winner -->|التوليد التلقائي| ProdConfig
style Winner fill:transparent,stroke:#3B82F6,stroke-width:2px
style ProdConfig fill:transparent,stroke:#10B981,stroke-width:2px
```
## تقييم المُقَيِّم
أحد الابتكارات الحاسمة كان تنفيذ ما أسميه "تقييم المُقَيِّم أولاً." كونِي معتادًا بعض الشيء على الإسبانية، تمكنت بسهولة من تحديد خسائر في الفروق الثقافية التي فاتت مؤشرات التقييم البسيطة. الحل كان استخدام نماذج أكثر تكلفة وعالية الجودة خصيصًا لتقييم بطاقة الدرجات نفسها، مما يضمن أن المقاييس تقيس ما يهم حقًا.
أن يكون لدينا حلقات تقييم واستخدام نماذج أكثر ذكاءً لتقييم المُقَيِّمين أصبح تقنية قوية. الحصول على مُقَيِّم جيد لشيء ما هو خلق رائع في مشروع—إنجاز، تحدي، وتحقيق في آن واحد.
حسّن هذا الإجراء المتعقّم بطاقة الدرجات بشكل تدريجي، وتمكّنت من إنشاء إطار تقييم قوي يمكن الوثوق به فعليًا لاتخاذ قرارات تلقائية. من خبرتي، هذا هو المكان الذي يفشل فيه معظم الفرق: يثقون بمُقَيِّميهم دون تقييمهم أولًا.
```mermaid
graph TB
Basic[المقاييس الأساسية]
Human[مراجعة بشرية]
Premium[نموذج مميز]
Refined[بطاقة الدرجات المحسّنة]
Trust[مُقَيِّم موثوق]
Basic -->|الفجوات المكتشفة| Human
Human -->|أفكار| Premium
Premium -->|تقييم| Basic
Premium --> Refined
Refined -->|تكرار| Trust
style Human fill:transparent,stroke:#333333,stroke-width:2px
style Premium fill:transparent,stroke:#3B82F6,stroke-width:2px
style Trust fill:transparent,stroke:#10B981,stroke-width:2px
```
## عندما تتحول المقاييس إلى تكوين
بمجرد أن أدركت أن المقاييس يمكن أن تولد تكوينات للإنتاج، فكل شيء توحد. يعيشه معيار الأداء جنبًا إلى جنب مع الكود ويمكن أن يركّز على أي طبقة في خط الأنابيب أو مكوّن في المحرك. يمكنه إنشاء مكوّنات وهمية، واختبار التباينات، وعندما تتحسن النقاط، يطلق تكوينًا مباشرة في شفرة المصدر.
أصبح ذلك الاتصال أساسيًا. يتطور الذكاء الاصطناعي بسرعة هائلة بحيث يكمن فائدة وجود تقييم الأداء متمازجًا في المشروع. عندما يُصدر نموذج جديد مع اقتصاديات أو سرعات أفضل، تبقى بطاقات النقاط كما هي ويستمر تقييم الأداء. التحسينات في الجودة لا تُصدق.
التوليفات الفائزة—اختيار النموذج، هندسة المطالب، ضبط المعاملات—مُختبرة مسبقًا مع مسارات تدقيق كاملة، تُطلق في التكوين وتذهب مباشرة إلى الإنتاج. مع نظام الترجمة، منحني هذا وعيًا لا يُصدق بقدرات النماذج على ترجمة اللغات. أصبح الفائزون تلقائيًا التكوين الإنتاجي، مستخدمين دائمًا أفضل توازن بين الجودة والسعر والحفاظ على الدقة الثقافية.
أوجد هذا مسار تدقيق يُظهر بالضبط سبب اتخاذ كل قرار تقني، مدعومًا بالبيانات التجريبية. عندما يسأل أحدهم "لماذا النموذج X للترجمة الإسبانية-إلى الفرنسية ولكن النموذج Y للترجمة الصينية-إلى الإنجليزية؟" الإجابة موجودة في نتائج المعيار.
## هندسة المطالب عبر البيانات
تطور النظام لتقييم ليس فقط اختيار النماذج بل هندسة المطالب نفسها. كنت قادرًا على إنشاء المقاييس ثم جعل أجزاء مختلفة تعمل حتى على مطالب الذكاء الاصطناعي، اختبار A/B لمطالب مختلفة بشكل منهجي . ظهر فائزون واضحون استنادًا إلى المقاييس المعتمدة. أزال هذا التخمين من هندسة المطالب، مع استبدال الحدس بقرارات مبنية على البيانات.
## اقتصاديات الاكتشاف المستمر
هناك جانب كبير لتوفير التكاليف في هذا النهج. تم تصميم بطاقة الأداء لتعزيز أفضل جودة وتنوع ثقافي مع سرعة جيدة، وأيضًا بأفضل تكلفة. أبعد ذلك، هناك التكلفة التي أتوفر عليها من خلال عدم الحاجة إلى تقييم أي شيء يدويًا—فقط أترك كل شيء يتكشف عند إصدار نموذج جديد أو نسخة من النموذج.
عندما يدعي النموذج أنه جيد حقًا في أزواج لغوية معينة، فمن السهل جدًا إضافته إلى التكوين ومراقبة تشغيل المعايير. أعلم أن أي فائز سيُطبّق في الإنتاج، مدعومًا بأدلة صلبة.
بالنسبة لي، التطوير المدفوع بالمعايير يشبه وجود فريق صغير من الوكلاء يعمل في المشروع، في قسم خاص، يبحث ويكتشف ويقيّم. إنه ممتع جدًا للمشاهدة. يشبه وجود ورشة بحث وتطوير صغيرة في المشروع تقوم بالعمل. كانت نظام الترجمة واحدة من أنظمتى المفضلة — قضيت أكثر من سنتين في بنائه متقطعًا، وأخيرًا وصل إلى مرحلة يمكنني فيها إنشاء خدمة به، رغم أنني أستخدمه حاليًا خصوصيًا.
## الدورة الفاضلة
التطوير القائم على المقاييس يُخلق دورة فاضلة:
1. **الوضوح عبر القياس**: تصبح الجودة التجريدية مقاييس ملموسة
2. **التعلم عبر المقارنة**: كل معيار يعلّم شيئًا جديدًا عن فضاء المشكلة
3. **الثقة عبر البيانات**: القرارات مدعومة بأدلة محلية وقابلة للتحقق
4. **التطور عبر الأتمتة**: يحسّن النظام نفسه باستمرار
لقد ثبت أن هذه الطريقة فعّالة للغاية في بناء نحو الابتكار. أصبح هذا منهجي المفضل لبناء الأنظمة، خاصة في مجال الذكاء الاصطناعي حيث تتحرك القاعدة باستمرار تحت أقدامنا. أنا لست متشددًا حول هذا أيضًا. يكشف سياق كل مشروع ما النهج الذي يعمل بأفضل شكل.
```mermaid
graph TB
Define[تحديد المقاييس]
Implement[بناء المقاييس]
Cache[تخزين النتائج مؤقتًا]
Evaluate[إجراء اختبارات A/B]
Select[اختيار الفائز]
Generate[إصدار التكوين]
Deploy[نشر إلى الإنتاج]
Monitor[مراقبة الأداء]
Define --> Implement
Implement --> Cache
Cache --> Evaluate
Evaluate --> Select
Select --> Generate
Generate --> Deploy
Deploy --> Monitor
Monitor -.->|مستمر| Evaluate
style Cache fill:transparent,stroke:#333333,stroke-width:2px
style Select fill:transparent,stroke:#3B82F6,stroke-width:2px
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
```
## ما ظهر من الممارسة
من خلال تطبيق التطوير المدفوع بالمعايير، ظهرت هذه الأنماط كأهمية:
- **الأرقام الواضحة ثبتت أهميتها**: أصبح النجاح قابلًا للقياس عبر أبعاد متعددة عندما تم تتبع الأداء والتكلفة والجودة بجانب الدقة.
- **الاختبارات الشاملة كشفت عن مشاكل خفية**: اختباره عبر كامل نطاق المدخلات المتوقعة والحالات الحادة كشف عن مشكلات تفوت الاختبار الجزئي.
- **التخزين المؤقت سمح بالتكرار السريع**: التكرارية والتخزين المؤقت الحازم جعلت آلاف التغييرات في المعايير ممكنة دون حساب مكرر.
- **الإعداد الآلي خفض الأخطاء**: عندما تولد نتائج المعايير إعدادات الإنتاج مباشرة، اختفت أخطاء النسخ اليدوي.
- **سجلات التدقيق أمنت الوضوح**: تتبع كل قرار تكوين إلى بيانات المعايير، ما يجعل تصحيح الأخطاء والمساءلة مباشرة.
## أين يزدهر هذا النهج
فلسفتي عندما يتعلق الأمر بتطوير البرمجيات هي أن النهج يجب أن يتطور دائمًا وفقًا للسياق والحاجة. التطوير القائم على المقاييس لن يكون منطقيًا للعديد من المشاريع، خاصة تلك التي لا تتمتع بطبيعة تجريبية أو ليست مدمجة مباشرة مع أنظمة الذكاء الاصطناعي التي تواجه تطورًا سريعًا.
بالنسبة لي، توتّر معدل التطور في المجال مع نطاق قدرات الذكاء الاصطناعي—من المخرجات الحتمية بالكامل عند درجة حرارة صفر إلى المخرجات الإبداعية عند درجات حرارة أعلى— خلق الحاجة. مع نظام الترجمة، أصبح النهج القائم على المقاييس منطقيًا لأنني كنت أستطيع قياس الجودة، السرعة، والتكلفة بأدلة صلبة ومسار ورقي.
لقد أثبت أن BDD أكثر فاعلية في السيناريوهات التي تتضمن:
- خيارات تنفيذ متعددة صحيحة (نماذج ذكاء اصطناعي مختلفة، خوارزميات، أو مناهج)
- مشاهدات تقنية تتطور بسرعة
- متطلبات تحسين متعددة الأبعاد (الجودة، السرعة، التكلفة)
- الحاجة إلى قرارات تقنية قابلة للشرح
- مساحات تكوين معقدة
- الأنظمة التي تتطلب التكيف المستمر مع القدرات الجديدة
إنه قوي بشكل خاص للأنظمة الذكية، محركات العرض، مسائل التحسين، وأي مجال حيث يعتمد "الأفضل" على السياق وتوازنات التبادل. يكشف سياق كل مشروع النهج الذي يعمل أفضل.
## الطريق إلى الأمام
مع دمج الذكاء الاصطناعي بشكل متزايد في أنظمتنا، تصبح الاختبارات الثابتة غير كافية. تشير الأدلة إلى أن المنهجيات التي تتكيف بسرعة مع تطور التكنولوجيا الأساسية تُنتج نتائج أفضل. يقدم التطوير القائم على المقاييس مسارًا إلى الأمام حيث تقوم أنظمتنا بتحسين نفسها باستمرار استنادًا إلى الأدلة التجريبية.
كان الانتقال من TDD إلى BDD تطورًا نحو شيء أكثر قوة، مع الاحتفاظ بالاختبارات مع التمديد إليها. في عالم تتغير فيه أفضل الحلول يوميًا، يجب أن تكون منهجياتنا التطويرية ديناميكية على قدم المساواة.
## الخلاصة
يُعَدّ تطوير القائم على المؤشرات تطوراً في الطريقة التي نبني بها ونُحسِّن بها الأنظمة. من خلال جعل المؤشرات توليدية بدلاً من مجرد تقييمية، نخلق أنظمة ذات تحسين ذاتي مع مسارات تدقيق مدمجة.
التحليل الأساسي: بدلاً من اختبار ما إذا كان شيء ما يعمل فقط، قم بقياس ما يعمل بأفضل حال باستمرار، ثم اضبط النظام تلقائياً لاستخدام ذلك الحل الأمثل. في عصر التغيير التكنولوجي المتسارع، تصبح هذه القابلية للتكيف والشفافية ضرورية لبناء أنظمة مبتكرة.
إنه مجزٍ للغاية لأنني أتعلم منه بنفسي. لدي وضوح أكبر، وتُدعَم عملية اتخاذ القرار بالبيانات المحلية الفعلية. مراقبة تشغيل المؤشرات ممتعة للغاية—مثل امتلاك ورشة أبحاث وتطوير صغيرة داخل المشروع تكشف ما يعمل بينما أركز على البناء.
لأي شخص يبني أنظمة في مجالات تتطور بسرعة، يقدم هذا نهجًا عمليًا لتحقيق التميز من خلال التحسين التجريبي. اعتمد فقط ما يخدم الأهداف الفعلية. اسأل كل شيء لكشف ما يهم فعليًا. عندما يفهم الفرق *لماذا* يفعلون ما يفعلونه، تتحدث النتائج عن نفسها.
لتحليل منهجي للإطار وأنماط التنفيذ، لقد وثقت المكوّنات الأساسية في [Benchmark-Driven Development: A Framework](/articles/benchmark-driven-development-framework).
هذا هو المقال الأول الذي أشاركه على موقعي، وآمل أن تجد قيمة في رحلة اكتشاف هذه المنهجية. اعتنِ بنفسك وتمنياتي لك بالتوفيق.