نقد نظرية عدم جدوى هندسة التحكم لدى شركات التقنية الكبرى، ونظرية اللوبات العشوائية كقيمة افتراضية للجيل التالي

بعد نشر مقال ذات صلة من قبل AI Times يتناول "نظرية عدم جدوى هندسة التحكم لدى شركات التقنية الكبرى"، تبادل عدة قادة تقنيين آراءهم حول هذا الموضوع. وكان التقرير يشير إلى أن شركة OpenAI، تماماً كشركة Google، أدلت بتصريحات تفيد بأن نماذجها الجيلية الجديدة قد تكون قادرة على استيعاب جزء كبير من وظائف آليات التحكم الحالية.

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

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

أولاً، يجب أن ننظر إلى الطريقة التي يتم بها تداول المصطلحات الرئيسية

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

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

ما يجب الحذر منه هذه المرة أيضاً هو أن حكاية "harness is dead" أو "harness is useless" لا تبدو مستخدمة على نطاق واسع في العالم الناطق بالإنجليزية. المناقشة أقرب إلى أن قدرة النموذج على استخدام الأدوات تتحسن وأن بعض السقالات يتم امتصاصها في النموذج أو المنصة، وأن العمر الافتراضي للطبقات المعقدة من التنسيق المبني يدوياً قد يصبح أقصر. لم أتحقق شخصياً من التصريح الأصلي للنائب نوام براون، بل تعرفت عليه من خلال التقارير المحلية والعالمية. لذا دعني أفحص إطار "نظرية عدم جدوى هندسة التحكم" نفسه الذي تم تثبيته بسرعة في السياق المحلي.

آليات التحكم التي ستختفي وتلك التي يجب أن تبقى مختلفة

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

لكن، مثلما لخص المهندس Dong-Soo Lee من A2Sys، أعتقد أنه من الخطير تعميم هذا على كل هندسة التحكم. باختصار، الحالة كما يلي:

• آليات التحكم بالطلبات والتدفقات قد تتم امتصاصها بواسطة النموذج. أنا موافق.
• آليات التحكم بتنفيذ الأدوات تتعامل مع الأذونات والموافقة والتعافي من الفشل. هل هذه حقاً آليات سيتم التخلص منها؟
• آليات التحكم بوقت التشغيل والذاكرة والبنية الأساسية تتناول السياق والذاكرة المؤقتة وتوجيه النموذج والتكلفة والكمون وسجلات التدقيق. أعتقد أنه من الصعب اعتبار هذا أيضاً أنه سيختفي.

جوهر هندسة التحكم الذي تحدثت عنه من الفصل 7 إلى الفصل 11 في كتاب 『هندسة التحكم: Re:بدء من الصفر — هندسة البرمجيات بالذكاء الاصطناعي』 يكمن هنا. العقود تحدد نطاقات السماح، والهياكل والعزل تضيق نطاق التغيير، والتتبع والتحقق تربط الأهداف الأصلية والنتائج الفعلية. القياس والتشغيل يديران التكاليف والأذونات والعطل والاسترجاع. هندسة التحكم في هذا النطاق ليست شيئاً يتم حله بمجرد تحسن النموذج.

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

كتبت رأيي في التعليق على منشور الأستاذ Han Sang-Ki بهذه الطريقة:

يبدو أن الأمر يعتمد على مدى سعة نطاق هندسة التحكم. طالما أن للمنظمة والمطورين نية، أعتقد أنه من الصعب الاستغناء عنها.

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

في الممارسة الفعلية، الحدود المسؤولة أولاً قبل قدرات النموذج

تعمل Nextain مع شركات تطلب التطوير عبر Discord. واليوم أدرجت وكيل Claude Code الذي كان يعمل على حل مشكلة معينة هنا. يقرأ وكيل Nextain (في الواقع Claude Code مشغل على خادم) قناة Discord ويقدم الإجابات.

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

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

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

المشكلة الحالية هي الانجراف والتكلفة

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

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

في التعليق على الأستاذ Han Sang-Ki الذي ذكرته أعلاه، أشار السيد Ha Jung-Woo كبير مستشاري التخطيط المستقبلي للذكاء الاصطناعي السابق إلى "كفاءة التكلفة الإجمالية للرموز". هذا هو المقياس بالضبط. آلية التحكم ليست جهازاً لرفض النموذج الرائد. إنها وسيلة للتحكم في التكاليف لاستخدام النموذج المكلف فقط للقرارات التي تحتاج حقاً إليه، وتقسيم العمل المتكرر إلى نماذج صغيرة وأدوات محلية وبرامج نصية وأجهزة تحقق حتمية.

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

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

آليات التحكم هي خطوط الدفاع عن التكاليف والبيانات

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

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

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

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

OpenAI و Anthropic في طليعة منافسة آليات التحكم من خلال Codex و Claude Code. من ناحية أخرى، Google هي شركة نموذج وفي نفس الوقت مزود خدمات سحابية. لا يمكن القول أن كل شركة لها نفس المصالح بالضبط، لكن السبب في صعوبة الاستماع إلى هذا الجدل كمجرد تنبؤ تقني نقي واضح. آلية التحكم الجيدة تقلل "رغبة شركات التقنية الكبرى في نقل مساحة العمل إلى النموذج وجمع البيانات" و "الاعتماد على الاستخدام الرائد".

الحلقات ليست القيمة الافتراضية للجيل التالي

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

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

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

Naia تريد الاحتفاظ بمساحة العمل من جانب المستخدم

Naia لا ترفض النموذج الرائد. نحن ننوي استخدام النموذج الرائد السحابي تماماً في التطوير. يجب استخدام نموذج جيد.

لكننا لا ننوي تسليم كل مساحة عمل وبيانات إلى منصة شركات التقنية الكبرى. ما تسعى إليه Naia هو هيكل يستخدم معاً: محلي، P2P، open-weight، نماذج صغيرة، أجهزة تحقق حتمية، وآليات تحكم أذونات صريحة. استخدم النموذج الرائد المكلف للقرارات المهمة، لكن احتفظ بمساحة العمل الأساسية في يد المستخدم.

من هذه الناحية، تطور النماذج مفتوحة الوزن مثل DeepSeek و Qwen و Kimi و GLM مهم. يصبح من الممكن الجمع بين النماذج حسب الهدف، حماية البيانات محلياً، واستدعاء النموذج الرائد المغلق فقط عند الحاجة. في كوريا، استراتيجيات النماذج المستقلة من Upstage و Naver لها أيضاً معنى في هذا التدفق. قد تكون الطريقة الأكثر واقعية هي الجمع الجيد بين open-weight والنماذج المستقلة والآليات تحكم خاصة والسياق الصناعي المحلي، بدلاً من مجرد متابعة النماذج الرائدة من عمالقة التقنية العالمية.

يمكنك استئجار نموذج. لكن لا حاجة لاستئجار مساحة العمل والبيانات أيضاً.

الخلاصة: ما هو مطلوب أكثر من نظرية عدم الجدوى هو نقاش مستوى التقنية

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

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

الملاحظات والمصادر

كتاباتي والكتاب

• 『هندسة التحكم: Re:بدء من الصفر — هندسة البرمجيات بالذكاء الاصطناعي』
• 「شرح شامل لهندسة التحكم — النشأة والمفاهيم والفجوات والمستقبل في آن واحد」
• 「خبر إطلاق هندسة التحكم」

المحفز المباشر للمناقشة

• AI Times، "في أعقاب Google، OpenAI أيضاً 'نظرية عدم جدوى هندسة التحكم'... نماذج الجيل التالي ستمتص الوظائف"
• AI Times، "[25 يونيو] 'النموذج سيأكل آليات التحكم'..."
• منشور Facebook من الأستاذ Han Sang-Ki ومناقشة التعليقات
• Dong-Soo Lee من A2Sys، "نظرية عدم الجدوى؟ نصفها صحيح ونصفها خاطئ"

النصوص الأصلية والمواد التقنية

• OpenAI، "Learning to Reason with LLMs"
• OpenAI، "An OpenAI model has disproved a central conjecture in discrete geometry"
• OpenAI، "Introducing Codex"
• OpenAI، "Introducing OpenAI o3 and o4-mini"
• Google، "Gemini 2.0: our new AI model for the agentic era"
• "The Interplay of Harness Design and Post-Training in LLM Agents"
• "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
• "AutoHarness"