هل نحتاج نموذج يعرف كل شي؟

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

وهذي بالضبط النقلة اللي تمر فيها نماذج الذكاء الاصطناعي الحين.

المعرفة المخزّنة لها سقف

النموذج التقليدي كل معرفته مخزّنة داخل أوزانه (weights). كل شي شافه في التدريب صار محفوظ بشكل إحصائي غير مباشر، وأي شي خارج هالنطاق إما يعتذر عنه أو يخترع جواب بثقة كاملة.

المشكلة في هذا الأسلوب ليست في السعة فقط،لكن فيها كم نقطة أعمق:

المعرفة تتجمد عند تاريخ معيّن. تحديثها يعني إعادة تدريب أو اعادة ضبط Fine-tuning، وهذي عملية مكلفة وبطيئة وليست عملية لبيانات تتغير كل ساعة.

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

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

كيف يشتغل استدعاء الأدوات فعليًا

استدعاء الأدوات (tool calling) الناس تتخيله أعقد من الواقع. الآلية بسيطة، وفهمها يوضح كثير من السلوك اللي تشوفه. أول شي، أنت تعرّف الأدوات المتاحة للنموذج على شكل وصف منظم، عادةً JSON Schema فيه اسم الأداة، ووش تسوي، ووش المدخلات اللي تحتاجها وأنواعها. هذا الوصف يدخل ضمن السياق (context) اللي يشوفه النموذج.

لما توصله رسالتك، النموذج يقرر: هل أقدر أجاوب من معرفتي، ولا هذا السؤال يحتاج معلومة خارجية؟ إذا قرر الخيار الثاني، مخرجاته ما تكون نص للمستخدم، تكون طلب استدعاء منظّم فيه اسم الأداة والمعاملات.

وبعدها وهذي النقطة اللي كثير يغفل عنها: النموذج ما ينفّذ ولا شي بنفسه. هو بس يقترح. اللي ينفّذ فعليًا هو التطبيق أو الـ runtime اللي حولك. يستقبل الطلب، يتحقق منه، ينفذه، ويرجع الناتج.

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

هذي الحلقة هي أساس كل شي بعدها.

وعشان تتضح الصورة أكثر، هذا شكل تعريف الأداة اللي يشوفه النموذج:

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

الفرق بين RAG والأدوات

كثير يخلط بين الاثنين، مع إن الفرق جوهري.

في RAG التقليدي، أنت تجيب المستندات ذات الصلة وتحقنها في السياق قبل لا يشوف النموذج السؤال. يعني القرار قرارك أنت، والنموذج يستلم النص جاهز. الاسترجاع هنا سلبي وثابت.

في الأدوات، النموذج هو اللي يقرر: هل أحتاج بحث؟ وش الكلمات اللي أبحث فيها؟ النتيجة ما كفت، هل أعيد الصياغة وأبحث مرة ثانية؟

الفرق إن الأول استرجاع، والثاني تصرّف.

وهذا الفرق هو نفسه الفرق بيني وبين المهندس اللي شغلت معه. أنا كنت أفتح التوثيق وأقرأ من فوق لتحت (استرجاع)، وهو يعرف وش يسأل بالضبط ويقيّم الجواب ويعيد السؤال إذا ما ضبط (تصرّف).

بروتوكول MCP وحل مشكلة الربط

الأدوات وحدها ما كانت كافية، والسبب مشكلة معروفة اسمها M×N.

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

بروتوكول MCP يحوّل المسألة إلى M+N. كل خدمة تبني خادم (server) واحد يتبع البروتوكول، وكل تطبيق يبني عميل (client) واحد يتكلم بنفس البروتوكول، والاثنين يشتغلون مع بعض بدون ربط مخصص.

والخادم ما يقدّم أدوات فقط، يقدّم ثلاثة أنواع:

• الأدوات (Tools) وهي عمليات ينفذها النموذج.
• والموارد (Resources) وهي بيانات يقدر يقرأها.
• والقوالب (Prompts) وهي صيغ جاهزة لمهام متكررة.

والنقل يصير إما محليًا عبر stdio، أو عن بعد عبر HTTP، حسب طبيعة الخدمة.

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

الـ Agent هو الحلقة نفسها

لما تجمع نموذج قادر على التخطيط، مع أدوات موصولة، مع حلقة تسمح له بخطوات متتابعة، يطلع لك اللي نسميه Agent.

الفرق بينه وبين النموذج العادي إن العادي يستقبل سؤال ويرجع جواب واحد. الـ Agent يستقبل هدف، ويفكك المهمة، وينفذ خطوة، ويقرأ النتيجة، ويقرر الخطوة الجاية بناءً عليها، ويعدّل خطته إذا طلعت النتيجة غير متوقعة.

يعني القيمة مو في النموذج لحاله، القيمة في الحلقة وفي جودة القرارات داخلها.

معايير التقييم تغيّرت أشوف إن أهم أثر لهالتحول إنه غيّر السؤال اللي نقيس فيه النماذج. ما صارت “كم يعرف”. صار أقرب لهذي الأسئلة:

هل يميّز متى يحتاج أداة ومتى يجاوب مباشرة؟ استدعاء أداة لسؤال بسيط إهدار، وتجاهل الأداة في سؤال يحتاجها خطأ أكبر.

هل يعبّي المعاملات صح من أول مرة؟ نسبة كبيرة من فشل الـ agents سببها معاملات ناقصة أو بصيغة غلط، مو ضعف في الفهم.

وش يسوي لما ترجع له الأداة بخطأ أو ببيانات فاضية؟ يعيد المحاولة بشكل مختلف، ولا يدخل في حلقة مكررة، ولا يخترع نتيجة من راسه ويكمل عليها؟

هل يعرف متى يوقف؟

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

الجانب الثاني من الصورة

مع إني ما أشوفها قصة وردية بالكامل، وفيها كم مشكلة حقيقية. التكلفة والزمن. كل استدعاء أداة يعني رحلة كاملة: النموذج يقرر، والأداة تنفذ، والناتج يدخل السياق، والنموذج يقرأ من جديد. عشر خطوات يعني عشر دورات، وكل دورة تكلفة tokens وزمن انتظار. تراكم الخطأ. إذا كانت دقة الخطوة الواحدة 95%، فالمهمة اللي فيها عشر خطوات دقتها تقارب 60%. وهذا يفسر ليه الـ agents تعمل بشكل ممتاز في العروض القصيرة، وتتعثر في المهام الطويلة.

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

المعرفة ما اختفت، تغيّر دورها

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

وش أتوقع

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

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

وسلامتكم

Originally published on X.