MTS: القرارات المعمارية الأولى في الذكاء الاصطناعي اليوم تضع قيودًا تمتد لعقود

يقترح نص MTS على Habr AI النظر إلى تطور الذكاء الاصطناعي لا بوصفه سباقًا بين النماذج، بل بوصفه تراكمًا لقرارات معمارية تعيش بعد ذلك عقودًا. والفكرة الرئيسية بسيطة: فالطبقات الأولى من الكود والبيانات والعمليات اليوم قد تصبح أساسًا يتعذر تفكيكه لأنظمة الذكاء الاصطناعي المستقبلية، تمامًا كما أصبح «المركز التقني» (Techno-Core) في رواية «هايبيريون».

استعارة من «هايبيريون»

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

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

كيف يتزايد التعقيد

لا تكمن المشكلة في النماذج وحدها. فأي منتج ذكاء اصطناعي يُبنى على طبقات: خطوط معالجة البيانات، والمرشحات، وقواعد البيانات المتجهية، وأدوات التنسيق (orchestrators)، وsystem prompts، وقواعد الأمان، وواجهات المستخدمين، والتكامل مع الخدمات الخارجية. وعادةً ما تظهر كل طبقة استجابةً لمهمة عاجلة لدى الأعمال: تسريع الإصدار، أو خفض كلفة الطلبات، أو رفع جودة الإجابات، أو تغطية أحد المخاطر. وكل قرار من هذه القرارات يبدو معقولًا بمفرده، لكن بعد بضع سنوات يتشكل منها بناء يصعب شرحه واختباره وتغييره بأمان.

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

ماذا ينبغي على الفرق أن تفعل

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

• الفصل بوضوح بين ما يفعله النموذج وما تفعله منطقيات الأعمال (business logic) في المنتج
• توثيق أسباب القرارات المعمارية الرئيسية، لا الكود النهائي وحده
• الحد من عدد الاعتماديات الخفية بين البيانات والـ prompts وأداة الاسترجاع (retriever) والواجهة
• تضمين قابلية المراقبة (observability): السجلات، والتتبع (tracing)، وإصدارات الـ prompts، ومراقبة الجودة
• إزالة الحلول المؤقتة بانتظام قبل أن تتحول إلى بنية تحتية دائمة

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

ماذا يعني ذلك

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