ما هي هندسة سياق الذكاء الاصطناعي؟ ولماذا قد تشتريها بدلاً من بنائها؟

تتمثل هندسة سياق الذكاء الاصطناعي في تصميم كل ما يحيط بالوكيل من معلومات وحدود وتعليمات، بحيث يعرف ما الذي يمكنه رؤيته، وما الذي ينبغي أن يفعله، وكيف يتصرف عندما يواجه حالة جديدة أو بيانات ناقصة. ووفقاً لشرح Doug Whitley، مدير الهندسة في Stack Overflow، وAsh Zade، مدير المنتجات، فإن الهدف ليس إغراق الوكيل بكل البيانات المتاحة، بل تزويده بالسياق المحدد الذي يحتاج إليه لإنجاز مهمة يمكن التنبؤ بنتيجتها.

جاء ذلك في حوار نشره Stack Overflow Blog ضمن سلسلة “No Dumb Questions”، وناقش الفروق بين هندسة السياق والبنية التحتية للسياق وهندسة السياق، إضافة إلى علاقة هذه المفاهيم بتقنيتي RAG وMCP، وأسباب لجوء الشركات إلى شراء حلول جاهزة بدلاً من بناء كل شيء داخلياً.

من البنية التحتية إلى الهندسة

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

ويضع RAG في منطقة تجمع المستويات الثلاثة. فالفهارس ومخازن السياق وطرق البحث تمثل جانب البنية التحتية، بينما تمثل عملية بناء النظام بلغة مثل .NET أو Python أو Rust جانب الهندسة. وفي المقابل، تحدد المعمارية الشكل العام للنظام والقواعد التي تحكم طريقة عمله. أما MCP، فيراه Whitley بروتوكولاً مع متطلبات محددة، لكن قرار دمجه في النظام، واللغات المستخدمة، والميزات التي سيدعمها، كلها قرارات تصميمية.

تقليل مساحة القرارات التي يتخذها الوكيل

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

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

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

الثقة والصلاحيات والتدخل البشري

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

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

• صلاحيات المصدر: يرث الوكيل صلاحيات المستخدم في الأنظمة التي يبحث فيها، مثل Slack أو MS Teams أو Google Drive أو SharePoint.
• النطاقات: يستطيع المستخدم تضييق نطاق البيانات المتاحة للوكيل حتى لو كان يملك صلاحية الوصول إلى مجموعة أوسع منها.
• البيانات الجديدة: يمكن تقييد ما ينشئه الوكيل أو يعيده إلى النظام، بحيث يرسله إلى المستخدم أولاً ولا يضيفه تلقائياً إلى قاعدة المعرفة العامة أو يشاركه مع الفريق.

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

لماذا قد تشتري الشركة الحل بدلاً من بنائه؟

يقول Whitley إن بناء هندسة السياق ممكن، لكن التحدي لا يقتصر على كتابة الكود. فعندما تجمع الشركة بيانات من Slack وMS Teams وGoogle Drive وSharePoint وConfluence وGitHub وJira، يتعين عليها تحديد كيفية الفهرسة والفرز وإعادة الترتيب، وكيفية التعامل مع المعلومات المتعارضة أو الناقصة أو غير الصحيحة.

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

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

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