ما الذي يغطيه هذا الدليل؟

غالباً ما يرتبط LlamaIndex بـ retrieval-augmented generation، لكن السياق الموثق يصف توجهاً أوسع هو Agent Document Workflows، أو ADW. ووفقاً للوصف الوارد، يمكن لسير العمل التعامل مع المستند باعتباره جزءاً من عملية أعمال أكبر، والحفاظ على الحالة عبر المراحل، وتطبيق قواعد الأعمال، وتنسيق المكونات، واتخاذ إجراءات استناداً إلى محتوى المستند. وتُعد مراجعة العقود أحد الأمثلة؛ إذ قد تستخرج العملية المعلومات، وتقارنها بالمتطلبات التنظيمية، وتحدد المخاطر المحتملة، وتُعد التوصيات.

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

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

الخطوة الأولى: صمّم العمل كعملية تتمحور حول المستند

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

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

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

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

الخطوة الثانية: افصل بين سياق سير العمل وسجلات الأعمال الدائمة

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

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

تقارن دراسة الاستمرارية المقدمة عدة أطر للـ agents وآليات الاستمرارية الخاصة بها. ويذكر ملخصها أن LlamaIndex استخدم serialized Context في التقييم، وأن هذا الإعداد المختبر لم يستأنف التنفيذ في عملية جديدة. وتُعد هذه النتيجة سبباً لاختبار سلوك التعافي الدقيق الذي تحتاج إليه، لا أساساً للقول إن كل سير عمل في LlamaIndex عاجز عن التعافي. وبالمثل، فهي لا تثبت أن تخزين بيانات التطبيق في SQLite يتيح تلقائياً استعادة بيئة التشغيل.

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

الخطوة الثالثة: اجعل الموافقة قراراً من قرارات الأعمال

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

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

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

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

الخطوة الرابعة: صمّم التعافي واختبره بصدق

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

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

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

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

الخطوة الخامسة: تعامل مع معالجة المستندات كسلسلة من المراحل الخاضعة للمساءلة

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

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

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

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

الخطوة السادسة: قيّم النظام قبل وصفه بالموثوقية

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

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

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

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

أخطاء شائعة يجب تجنبها

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

أهم النقاط

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

أبقِ حالة الأعمال على مستوى التطبيق منفصلة عن استعادة سير العمل على مستوى الإطار. يذكر تقييم الاستمرارية أن LlamaIndex serialized Context لم يستأنف التنفيذ في عملية جديدة ضمن الإعداد المختبر، ولذلك تحتاج ادعاءات التعافي إلى نطاق محدد واختبار مباشر. صمّم المراجعة البشرية حول قرارات أعمال واضحة، واصفاً التوصيات والموافقات والعمل المكتمل بدقة.

هذا المقال دليل معماري، وليس درساً عملياً للنسخ والتشغيل مباشرة. وقبل نشر أي تنفيذ، تحقّق من واجهاته البرمجية واعتمادياته وسلوك التعافي واختباراته بالاستناد إلى الوثائق الرسمية للإصدارات المحددة التي جرى نشرها. الإسناد التحريري: فرق التحرير والهندسة في Gate of AI، شركة GateOfAI, LLC، وهي شركة مسجلة في ولاية ديلاوير بالولايات المتحدة الأمريكية.

المصادر والنطاق

• VentureBeat: يتجاوز LlamaIndex تقنية RAG لتمكين الـ agents من اتخاذ قرارات معقدة — تغطية Agent Document Workflows ومثال مراجعة العقود.
• The Hidden Footprint: Making Storage a First-Class Metric for LLM Agent Evaluation — ملخص تقييم الاستمرارية، بما في ذلك نتيجة التشغيل في عملية جديدة لاستخدام LlamaIndex serialized Context ضمن الإعداد المختبر.