الاتجاهات المستقبلية: ما بعد الـ LLMs، وكيف تبقى مطلوباً في سوق العمل كمهندس AI؟

لماذا لم يعد إتقان LLMs وحده كافياً؟

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

إذا كنت قد فهمت سابقاً كيف تعمل النماذج لغوياً عبر مقال مدخل إلى هندسة الذكاء الاصطناعي التوليدي: كيف تعمل نماذج اللغة الكبيرة (LLMs) برمجياً؟، فالخطوة التالية هي الانتقال من التفكير في model-centric إلى system-centric. هذا التحول هو ما يحدد من سيبقى مطلوباً فعلاً في سوق العمل.

الاتجاه الأول: الانتقال من تطبيقات السؤال والجواب إلى أنظمة تنفيذ الأعمال

الموجة القادمة ليست مجرد روبوت دردشة، بل أنظمة قادرة على اتخاذ خطوة ثم خطوة، مع استدعاء أدوات خارجية وتنفيذ مهام فعلية. هنا يظهر دور العملاء الأذكياء (AI Agents)، وخصوصاً حين يُدمجون مع أدوات مخصصة، أو مع منهجية ReAct، أو داخل بنى Multi-Agent Systems.

كيف تتدفق البيانات في هذا النوع من الأنظمة؟

• يُرسل المستخدم هدفاً عالي المستوى بدلاً من سؤال بسيط.
• يحلل النظام النية ويحوّلها إلى خطة فرعية.
• يختار Agent الأداة المناسبة: بحث، قاعدة بيانات، API، أو مفسر Python.
• تعود النتائج الخام إلى طبقة تنظيم السياق، ثم يُعاد تمريرها للنموذج لصياغة القرار التالي.
• قبل الإخراج النهائي، تُطبق سياسات تحقق، فلترة، وتسجيل logging.

المهندس المطلوب مستقبلاً ليس من “يشغّل النموذج”، بل من يفهم كيف يبني طبقة orchestration تمنع الانهيار عند فشل أداة أو تغيّر مخرجات خدمة خارجية.

الاتجاه الثاني: صعود البنية الهجينة بين RAG و Fine-Tuning

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

المعمارية الأذكى في السنوات القادمة

• طبقة ingest تستخرج البيانات من PDF وCSV وواجهات الأعمال.
• طبقة تحويل عبر Embeddings وتخزين داخل Vector DBs.
• طبقة استرجاع ذكي تعتمد hybrid search أو MMR.
• طبقة نموذج مضبوطة سلوكياً عبر LoRA أو QLoRA عند الحاجة.
• طبقة تقييم تمنع هلوسة الإجابات وتقيس الدقة والزمن والتكلفة.

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

الاتجاه الثالث: الذكاء متعدد الوسائط سيصبح مهارة أساسية

المستقبل ليس نصاً فقط. تطبيقات الأعمال تتعامل مع صور فواتير، صوت مكالمات، مستندات ممسوحة، جداول، ورسوم بيانية. لذلك من يفهم Vision Models، وWhisper و TTS، واستخراج البيانات من الصور إلى JSON سيملك أفضلية أوضح من مهندس يحصر نفسه في النصوص.

المسألة هنا هندسية: كل وسيط له pipeline مختلف، لكن الفكرة واحدة؛ تحويل الإشارة الخام إلى تمثيل منظم، ثم تمريره إلى طبقة reasoning أو retrieval، ثم إرجاع نتيجة قابلة للاستخدام داخل تطبيق حقيقي.

الاتجاه الرابع: الطلب سيرتفع على مهندسي التقييم والأمان أكثر من “كتّاب البرومبتات”

مرحلة الانبهار بـ prompt engineering وحدها تتراجع. نعم، ما زالت مهمة، ويمكنك مراجعة هندسة الأوامر داخل الكود، لكن السوق الآن يدفع أكثر لمن يضمن أن المخرجات موثوقة وآمنة. هذا يشمل مقاومة Prompt Injection، وبناء مقاييس تلقائية عبر Evaluation، ومراقبة الأداء والتكلفة بواسطة LangSmith.

لماذا هذا مهم وظيفياً؟

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

كيف تبقى مطلوباً في سوق العمل كمهندس AI؟

1) ابنِ مهارة البنية الكاملة لا مهارة الجزء الواحد

تعلم كيف تربط بين LangChain، وقواعد الاسترجاع، والذاكرة، والواجهات، والنشر. المهندس المطلوب هو من يمكنه الانتقال من السكربت إلى الخدمة ثم إلى المنتج.

2) طوّر مشاريع تثبت تدفق البيانات end-to-end

بدلاً من مشروع “اسأل ملفاً” فقط، ابنِ نظاماً يقرأ البيانات، يخزنها، يسترجعها، يقيّمها، ثم ينشرها عبر FastAPI أو واجهة Streamlit. هذا النوع من المشاريع أقرب لاحتياجات الشركات.

3) تعلم التفكير بالتكلفة والزمن لا بالدقة فقط

المهندس الناضج يفهم إدارة الرموز والتكلفة، ويعرف متى يستخدم نموذجاً كبيراً، ومتى يعتمد على نموذج أصغر، أو caching، أو routing بين النماذج.

4) كن جيداً في تحويل المخرجات إلى بيانات منظمة

في الأنظمة الحقيقية، القيمة ليست في نص جميل فقط، بل في إخراج منضبط يمكن استهلاكه برمجياً. لهذا يصبح فهم Output Parsers أساسياً في أي وظيفة قوية.

مثال هندسي مختصر على خط إنتاج حديث لتطبيق توليدي

فيما يلي مثال مصغّر يعبّر عن طريقة التفكير التي يطلبها السوق: استرجاع سياق، بناء رسالة نظام، ثم طلب مخرجات منظمة قابلة للاختبار لاحقاً.

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import JsonOutputParser

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
parser = JsonOutputParser()

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are an AI engineer assistant. Answer only from provided context."),
    ("human", "Context: {context}\nQuestion: {question}\nReturn JSON only.")
])

chain = prompt | llm | parser

result = chain.invoke({
    "context": "Retrieved chunks from vector database...",
    "question": "What architecture should we use for an enterprise AI assistant?"
})

print(result)

ما الذي يبيّنه هذا المثال؟

• الفصل بين طبقة السياق وطبقة التوليد.
• الاعتماد على إخراج منظم يسهل اختباره.
• تقليل الهلوسة عبر ربط الإجابة بسياق مسترجع.
• تجهيز النظام لاحقاً للإدماج مع التقييم والمراقبة.

البرومبتات المستقبلية ستكون أقرب إلى مواصفات تشغيل

في الأنظمة المتقدمة، لم يعد البرومبت مجرد “اكتب لي جواباً جيداً”، بل صار وثيقة تشغيل تحدد الحدود، تنسيق الإخراج، وسياسة التصرف عند نقص المعلومات.

أنت نظام مساعد مؤسسي. استخدم السياق المسترجع فقط. إذا لم تكن المعلومة موجودة، أعد الحقل “answer_status”: “insufficient_context”. لا تخمّن. أخرج النتيجة بصيغة JSON تحتوي على summary وcitations وrisk_level.

هذا النوع من الصياغة يعكس نضجاً هندسياً، لأنه يبني سلوكاً قابلاً للمراقبة لا مجرد نص جميل.

خارطة مهارات عملية للسنوات القادمة

• إتقان الأساسيات: Python، هياكل البيانات، وتصميم APIs.
• بناء أنظمة RAG كاملة، لا تجريبية فقط.
• فهم النماذج المفتوحة عبر Hugging Face وتشغيلها محلياً مع Ollama.
• تعلم تخصيص النماذج عملياً عبر LoRA و QLoRA.
• إتقان النشر، العزل، والتشغيل عبر Docker وDeployment.

الخلاصة: الوظائف لن تختفي، لكنها ستصبح أكثر هندسية

ما بعد LLMs لا يعني نهاية النماذج، بل يعني أن قيمتها ستُقاس بقدرتك على وضعها داخل نظام موثوق، اقتصادي، وآمن. إذا أردت أن تبقى مطلوباً، فلا تتمسك بدور “مستخدم النموذج”، بل انتقل إلى دور مهندس البنية: من ingestion إلى retrieval، ومن orchestration إلى evaluation، ومن prototyping إلى production. هذا هو الفرق بين شخص يتابع الموجة، وشخص يبني فوقها شركة أو مساراً مهنياً طويل الأمد.