#

النقاط الرئيسية

• تشرح AWS أنماط التخزين المؤقت للمطالبات للوكلاء الذين يستدعون نماذج OpenAI عبر Amazon Bedrock.

• يمكن أن يؤدي إرسال البادئة نفسها بشكل متكرر إلى زيادة تكلفة الإدخال والوقت.

• يعيد التخزين المؤقت للمطالبات استخدام الحالة المعالجة لرموز الإدخال المطابقة.

• تصف AWS كلاً من التخزين المؤقت الضمني والصريح.

• الشرط الرئيسي هو تسلسل رموز ابتدائي مطابق.

ما الذي توضحه AWS

تشرح تدوينة في مدونة AWS Machine Learning بتاريخ 26 أكتوبر كيف يعمل التخزين المؤقت للمطالبات للوكلاء الذين يستدعون نماذج OpenAI عبر Amazon Bedrock. تركز التدوينة على استدعاءات الوكلاء المتكررة، حيث يرسل النظام التعليمات وتعريفات الأدوات والتبادلات السابقة والرسالة الأخيرة في كل مرة. ومع نمو المحادثة، يمكن معالجة البادئة غير المتغيرة مراراً وتكراراً. وتقول AWS إن هذه المعالجة المتكررة تضيف تكلفة إدخال ووقتاً قبل أن يجيب النموذج.

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

كيف يختلف نمطا التخزين المؤقت

تُميز AWS بين التخزين المؤقت الضمني والتخزين المؤقت الصريح. في التخزين المؤقت الضمني، يختار Bedrock بادئة قابلة لإعادة الاستخدام من تلقاء نفسه. أما في التخزين المؤقت الصريح، فيحدد المطور حدوداً باستخدام `promptcachebreakpoint`. وتذكر التدوينة أن هذين النهجين يمكن دمجهما في التصميم نفسه.

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

ما الذي تستعرضه المقالة

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

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

اعتبارات تشغيلية

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

كما أن التدوينة لا تعلن عن نموذج OpenAI جديد أو منطقة Bedrock جديدة. وتكمن قيمتها في تفاصيل التنفيذ. فهي تشرح كيف يمكن أن يندمج التخزين المؤقت للمطالبات في أنظمة الوكلاء التي ترسل تعليمات وسياقاً متشابهين بشكل متكرر.

الصلة بالمغرب

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

الخلاصة

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