طبقة السياق: RAG، الرسم البياني المعرفي، وذاكرة المؤسسة

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

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

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

ما المقصود بطبقة السياق

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

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

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

لماذا أصبحت طبقة السياق مجالًا معماريًا مستقلاً

في المساعدات البسيطة (copilots)، غالبًا ما يُعتبر السياق كافيًا إذا كان النموذج قادرًا على البحث في المستندات. في بيئة الوكيل المؤسسي (agentic enterprise)، هذا غير كافٍ. يجب على الوكيل فهم الوضع التشغيلي الحالي، وتفسير القواعد السارية، وتذكر الخطوات التي تمت، والتصرف ضمن حدود الصلاحيات.

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

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

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

RAG للاسترجاع المعرفي المُتحكم فيه

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

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

لكن بناء RAG جيد أصعب بكثير من مجرد إدراج المستندات في قاعدة بيانات متجهات (vector database). جودته تحددها التصميمات الأولية، وليس فقط نموذج البحث.

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

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

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

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

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

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

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

الرسم البياني المعرفي للعلاقات التجارية غير الملتقطة في المستندات

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

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

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

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

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

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

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

ذاكرة المؤسسة: التذكر دون تخزين الأخطاء كحقائق

المكون الثالث لطبقة السياق هو الذاكرة. تتيح الذاكرة للوكيل تذكر السياق الذي لا يتوفر دائمًا في prompt واحد أو استعلام واحد. هذا مهم لأن العديد من الأعمال المؤسسية تتم عبر خطوات متعددة، عبر أيام، وحتى عبر فرق.

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

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

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

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

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

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

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

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

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

دمج RAG والرسم البياني والذاكرة في طبقة سياق واحدة

هذه المكونات الثلاثة لا تحل محل بعضها البعض. إنها تكمل بعضها البعض. يساعد RAG الوكيل في استرجاع المعرفة ذات الصلة من المستندات والمجموعات المؤسسية. يساعد الرسم البياني المعرفي الوكيل في فهم العلاقات بين الكيانات التجارية. تساعد الذاكرة الوكيل في الحفاظ على استمرارية السياق عبر الجلسات وسير العمل والتعلم التشغيلي.

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

هنا تصبح طبقة السياق حقًا طبقة تنفيذ، وليست مجرد طبقة بحث.

الآثار العملية

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

بالنسبة لمدير تكنولوجيا المعلومات (CIO)، السؤال هو: هل تمتلك المؤسسة بالفعل طبقة سياق يمكن إدارتها، أم أنها لا تزال تعتمد على هندسة prompts والاسترجاع المؤقت؟ بالنسبة لمدير العمليات (COO)، في سير العمل ذي الأولوية، ما السياق الذي يحتاجه الوكيل حقًا لاتخاذ قرارات ملائمة وآمنة؟ بالنسبة لمدير الموارد البشرية (CHRO)، إذا بدأ الوكيل في تخزين ذاكرة المستخدم أو الذاكرة المؤسسية، فهل سياسات الخصوصية والعدالة والتصحيح جاهزة؟ بالنسبة لقائد التحول، هل حالات استخدام الوكيل مبنية على سياق مؤسسي موثوق، أم فقط على عرض توضيحي للاسترجاع يبدو مقنعًا؟

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