ما هو تخزين الأوامر؟ أفضل الممارسات مشروحة

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

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

يوفر هذا الدليل نظرة شاملة حول تخزين الطلبات، وكيف يعمل، وفوائده، وتفاصيل تنفيذها (مركزًا على واجهة برمجة التطبيقات الخاصة بشركة Anthropic، والتي تتعلق أيضًا بنماذج Claude على AWS Bedrock)، واعتبارات التسعير، والقيود، وأفضل الممارسات.

كيفية عمل تخزين الطلبات: الآلية

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

1. فشل التخزين (الطلب الأول / تغيير البادئة): عندما يصل طلب مع بادئة لم يتم رؤيتها مؤخرًا أو لا تتطابق مع أي إدخال مخزّن، يقوم LLM بمعالجة كامل الطلب كما هو معتاد. ومع ذلك، إذا كان التخزين ممكّنًا لحدود بادئة معينة، تقوم النظام بتخزين الحالة الداخلية للنموذج المرتبطة بتلك البادئة بعد معالجتها. غالبًا ما يشار إلى ذلك باسم كتابة التخزين المؤقت. يتم ربط معرف فريد، عادةً ما يكون تجزئة تشفيرية لمحتوى البادئة (بما في ذلك طلبات النظام وتعريفات الأدوات والرسائل حتى النقطة المخزنة)، بهذه الحالة المخزنة، مما يجعلها مفتاح التخزين المؤقت.
2. نجاح التخزين (طلبات لاحقة): إذا وصل طلب لاحق ضمن فترة حياة التخزين (TTL) ومطابقة بادئته بالضبط للمحتوى المرتبط بمفتاح التخزين المخزن، يسترجع النظام الحالة الداخلية المحفوظة. يتقدم LLM فعليًا إلى نهاية البادئة دون إعادة معالجتها. ثم يحتاج فقط إلى معالجة الجزء الجديد من الطلب (اللاحقة). يعرف ذلك بأنه قراءة التخزين أو نجاح التخزين.

البادئة المخزنة:

ما يشكل بالضبط "البادئة" يعتمد على واجهة برمجة التطبيقات وكيف تقوم بترتيب طلبك. عمومًا، تشمل الأجزاء الثابتة لطلبك التي تعتزم إعادة استخدامها عبر الاستدعاءات. على سبيل المثال، باستخدام هيكل واجهة برمجة التطبيقات لشركة Anthropic كمرجع:

• الأدوات: تعريفات الأدوات/الوظائف المتاحة.
• طلب النظام: تعليمات أو سياق على مستوى عالٍ للنموذج.
• الرسائل: رسائل المستخدم/المساعد الأولية، مثل أمثلة قليلة أو تاريخ المحادثة.

عادةً ما يكون الترتيب مهمًا (مثلًا، تعالج Anthropic tools، ثم system، ثم messages). تحدد المكان الذي تنتهي فيه البادئة القابلة للتخزين باستخدام معلمات واجهة برمجة التطبيقات المحددة.

خصائص التخزين:

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

لماذا تستخدم تخزين الطلبات؟

تطبيق تخزين الطلبات يقدم فوائد كبيرة، تركز بشكل أساسي على الأداء وكفاءة التكلفة.

1. تقليل زمن الاستجابة: غالبًا ما تكون هذه هي الفائدة الأكثر مباشرة. من خلال تخطي إعادة معالجة آلاف الرموز الخاصة بالبادئة، يمكن لـ LLM البدء في معالجة المعلومات الجديدة ذات الصلة (اللاحقة الطلب) بشكل أسرع بكثير. يتترجم ذلك مباشرة إلى أوقات استجابة أسرع للمستخدم النهائي. بالنسبة للتطبيقات التي تتطلب تفاعلًا في الوقت الحقيقي، مثل روبوتات المحادثة أو مساعدي البرمجة، فإن هذه السرعة هي أمر حيوي. تشير تقارير AWS Bedrock إلى تقليل محتمل في زمن الاستجابة يصل إلى 85% للنماذج المدعومة.
2. تقليل التكلفة: عادةً ما تتقاضى واجهات برمجة التطبيقات LLM بناءً على عدد الرموز المدخلة والمخرجة المعالجة. عندما يحدث نجاح التخزين، يتم عادةً فرض رسوم بمعدل أقل بكثير للرموز التي تم قراءتها من التخزين مقارنة بمعدل الرموز المدخلة القياسي. تدفع فقط المعدل القياسي للمدخلات للرموز الجديدة في اللاحقة (ويمكن أن يكون معدل أعلى قليلاً لكتابة التخزين الأولية). على مدى العديد من الاستدعاءات مع بادئات ثابتة وكبيرة، يمكن أن يؤدي ذلك إلى وفورات كبيرة في التكلفة. تقترح AWS Bedrock أن التخفيضات في التكلفة تصل إلى 90% ممكنة.
3. أداء مُحسَّن للحالات الشائعة: يكون التخزين مؤثرًا بشكل خاص للتطبيقات التي تنطوي بطبيعتها على تكرار الطلبات:

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

1. تكامل سلس: تم تصميم تخزين الطلبات للعمل جنبًا إلى جنب مع ميزات LLM الأخرى. على سبيل المثال، يندمج مع ميزات AWS Bedrock مثل الوكلاء وGuardrails، مما يسمح لك باستغلال الإعدادات المعقدة دون تحمل العقوبة الكاملة لزمن الاستجابة جراء المكونات المتكررة.

كيفية تمكين تخزين الطلبات

تختلف الطريقة المحددة لتمكين تخزين الطلبات قليلاً بين مزودي LLM وواجهات برمجة التطبيقات الخاصة بهم. هنا، سنركز على التنفيذ باستخدام واجهة برمجة التطبيقات Messages الخاصة بشركة Anthropic، والتي تنطبق مباشرة على نماذج Claude عبر Anthropic أو من خلال منصات مثل AWS Bedrock.

المبدأ العام: ترتيب الطلب الخاص بك

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

+-------------------------+--------------------------+
|      البادئة الثابتة      |     اللاحقة الديناميكية       |
| (طلب النظام، الأدوات،    | (استفسار المستخدم الجديد،  |
|  الأمثلة القليلة،         |  آخر دور محادثة، إلخ)|
|  السياق الأولي)           |                          |
+-------------------------+--------------------------+
          ^
          |
   نقطة اهتمام التخزين هنا

تنفيذ واجهة برمجة التطبيقات Anthropic (cache_control)

تستخدم شركة Anthropic المعلمات cache_control ضمن جسم طلب واجهة برمجة التطبيقات Messages لتمكين وإدارة التخزين المؤقت.

• التمكين: تضمين كائن cache_control داخل واحد من الكتل التي تريد تضمينها على أنها نهاية بادئتك القابلة للتخزين. حاليًا، النوع المعتمد الوحيد هو "ephemeral".
• المكان: يمكنك وضع كتلة cache_control في:
• رسالة طلب system.
• كائن message معين (دور المستخدم أو المساعد).
• كتلة تعريف tool (أقل شيوعًا، ولكن ممكن).
• ترتيب إنشاء التخزين: يتم بناء بادئة التخزين استنادًا إلى المحتوى حتى وتضمين الكتلة المميزة بـ cache_control، وفقًا للترتيب القياسي: tools -> system -> messages.
• نقاط اهتمام متعددة: يمكنك تحديد ما يصل إلى 4 نقاط اهتمام للتخزين ضمن طلب واحد عن طريق إضافة cache_control إلى كتلة متعددة. سيقوم النظام بمحاولة العثور على أطول بادئة مخزنة مطابقة استنادًا إلى هذه النقاط المحتملة.

مثال (SDK بايثون الخاص بشركة Anthropic): تخزين طلب النظام

import anthropic

client = anthropic.Anthropic(api_key="YOUR_API_KEY")

# الطلب الأول (كتابة التخزين)
response1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # هذا الطلب النظام هو المحتوى الذي نريد تخزينه
            "text": "أنت مساعد مفيد متخصص في الفلك. قاعدة معرفتك تشمل تفاصيل موسعة حول تطور النجوم وعلم الكونيات وعلوم الكواكب. رد بدقة وبإيجاز.",
            "cache_control": {"type": "ephemeral"} # علامة على التخزين
        }
    ],
    messages=[
        {
            "role": "user",
            # هذا هو الجزء الديناميكي، غير مخزن في البادئة
            "content": "ما هو حد شاندراسيخار؟"
        }
    ]
)
print("الرد الأول:", response1.content)
print("الاستخدام (الكتابة):", response1.usage)
# قد يبدو مخرجات الاستخدام كمثال:
# الاستخدام (الكتابة): الاستخدام (input_tokens=60، output_tokens=50، cache_creation_input_tokens=60، cache_read_input_tokens=0)

# الطلب اللاحق (نجاح التخزين - ضمن TTL، مثل < 5 دقائق لاحقًا)
response2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # بالضبط نفس الطلب النظام السابق
            "text": "أنت مساعد مفيد متخصص في الفلك. قاعدة معرفتك تشمل تفاصيل موسعة حول تطور النجوم وعلم الكونيات وعلوم الكواكب. رد بدقة وبإيجاز.",
            "cache_control": {"type": "ephemeral"} # علامة مرة أخرى
        }
    ],
    messages=[
        {
            "role": "user",
            # استفسار ديناميكي جديد
            "content": "اشرح مفهوم الطاقة المظلمة."
        }
    ]
)
print("\\\\nالرد الثاني:", response2.content)
print("الاستخدام (نجاح):", response2.usage)
# قد يبدو مخرجات الاستخدام كمثال:
# الاستخدام (نجاح): الاستخدام (input_tokens=8، output_tokens=75، cache_creation_input_tokens=0، cache_read_input_tokens=60)

في هذا المثال:

1. الطلب الأول يعالج 60 رمزًا من طلب النظام و8 رموز من رسالة المستخدم. يتم تخزين طلب النظام (cache_creation_input_tokens: 60).
2. الطلب الثاني يجد نجاح التخزين للطلب النظام المتطابق (cache_read_input_tokens: 60). تحتاج فقط إلى معالجة 8 رموز جديدة من رسالة المستخدم كمدخلات قياسية (input_tokens: 8).

مثال (التخزين التدريجي في المحادثة):

لتخزين تاريخ المحادثة، يمكنك وضع cache_control على آخر رسالة تريد تضمينها في التخزين للدور التالي.

# الدور 1 (المستخدم يسأل، المساعد يرد - نظام التخزين + الدور 1)
response_turn1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "حافظ على شخصية ودية."}], # خزّن هذا أيضًا
    messages=[
        {"role": "user", "content": "مرحبًا Claude!"},
        {"role": "assistant", "content": "مرحبًا هناك! كيف يمكنني مساعدتك اليوم؟", "cache_control": {"type": "ephemeral"}} # خزّن حتى هنا
    ]
)
# دعنا نتظاهر بأن المستخدم يضيف رسالة أخرى للدور 2
# الدور 2 (نجاح التخزين للنظام + الدور 1، كتابة التخزين للدور 2)
response_turn2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "حافظ على شخصية ودية."}], # نفس طلب النظام
    messages=[
        {"role": "user", "content": "مرحبًا Claude!"}, # جزء من البادئة القابلة للتخزين الآن
        {"role": "assistant", "content": "مرحبًا هناك! كيف يمكنني مساعدتك اليوم؟"}, # جزء من البادئة القابلة للتخزين الآن
        {"role": "user", "content": "أخبرني بحقيقة ممتعة."}, # محتوى ديناميكي جديد
        {"role": "assistant", "content": "هل كنت تعلم أن العسل لا يفسد؟", "cache_control": {"type": "ephemeral"}} # خزّن حتى نهاية الدور 2
    ]
)
# الاستخدام لدور 2 سيظهر cache_read_input_tokens للنظام + الدور 1
# وcache_creation_input_tokens لرسائل المستخدم / المساعد الجديدة لدور 2

متابعة أداء التخزين:

تتضمن استجابة واجهة برمجة التطبيقات مقاييس الاستخدام التي تكشف كيفية استغلال التخزين:

• input_tokens: عدد الرموز المدخلة غير المخزنة المعالجة (اللاحقة الديناميكية).
• output_tokens: عدد الرموز المتولدة في الاستجابة.
• cache_creation_input_tokens: عدد الرموز المدخلة التي تم معالجتها وتخزينها في التخزين في هذا الطلب (يحدث عند فشل التخزين).
• cache_read_input_tokens: عدد الرموز المدخلة التي تم تحميلها من التخزين في هذا الطلب (يحدث عند نجاح التخزين).

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

AWS Bedrock:

بالنسبة للنماذج مثل Anthropic Claude التي يتم الوصول إليها عبر AWS Bedrock، يتم عادةً تمكين آلية التخزين باستخدام نفس معلمة cache_control ضمن جسم طلب استدعاء النموذج (application/json المرسلة إلى InvokeModel أو InvokeModelWithResponseStream). ينبغي عليك بناء جسم JSON وفقًا لمتطلبات النموذج المحدد (مثل تنسيق واجهة برمجة التطبيقات Messages الخاصة بشركة Anthropic) وتضمين حقل cache_control كما هو موضح أعلاه. تحقق من الوثائق الخاصة بنموذج المورد الذي تستخدمه.

ما هي أسعار تخزين الطلبات؟

يقدم تخزين الطلبات هيكل تسعير أكثر تعقيدًا مقارنة بتكاليف الرموز القياسية. بينما يعتبر مفيدًا بشكل عام، من المهم فهم أنواع الرموز المختلفة المعنية:

1. رموز الإدخال الأساسية: هذه هي الرموز المدخلة القياسية التي ليست جزءًا من بادئة مخزنة (أي اللاحقة الديناميكية في سيناريو نجاح التخزين، أو الطلب بالكامل إذا لم يتم استخدام التخزين أو فشل). يتم فرض رسوم عليها بمعدل رموز الإدخال القياسي للنموذج.
2. رموز كتابة التخزين (cache_creation_input_tokens): عندما يتم معالجة بادئة لأول مرة (أو بعد فشل التخزين) وكتابتها في التخزين، يتم فرض رسوم على الرموز المرتبطة بتلك البادئة عادةً بمعدل متميز. على سبيل المثال، تفرض شركة Anthropic 25% أكثر من معدل الرموز المدخلة الأساسية لتسجيل التخزين. هذا يعكس تكلفة كل من المعالجة وتخزين إدخال التخزين.
3. رموز قراءة التخزين / رموز نجاح التخزين (cache_read_input_tokens): عندما يحدث نجاح التخزين، يتم فرض رسوم على الرموز المرتبطة بالبادئة المحملة من التخزين بمعدل مخفض بشكل كبير. على سبيل المثال، تفرض شركة Anthropic 10% فقط من معدل الرموز المدخلة الأساسية (خصم قدره 90%) من أجل قراءة التخزين. هذا يعكس المدخرات الحوسبية.
4. رموز المخرجات: يتم فرض رسوم على الرموز التي تم توليدها بواسطة LLM استجابةً بمعدل الرموز المخرجة القياسي للنموذج، بغض النظر عما إذا تم استخدام التخزين للمدخلات.

جدول الأسعار (نماذج Anthropic Claude - معدلات توضيحية):

(ملاحظة: يُرجى دائمًا مراجعة الصفحات الرسمية للتسعير الخاصة بشركة Anthropic وAWS Bedrock للحصول على أحدث المعدلات.)

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

قيود تخزين الطلبات

بينما يعد تخزين الطلبات قويًا، إلا أن له قيودًا وعوامل يجب مراعاتها:

الحد الأدنى لطول التخزين: غالبًا ما يكون لدى النماذج متطلبات حد أدنى من الرموز لـ البادئة لتكون مؤهلة للتخزين. لا يمكن تخزين الطلبات التي تقل عن هذا الحد، حتى لو كانت مُعلمة بـ cache_control.

• نماذج Anthropic Claude 3.7/3.5 Sonnet & Opus: حد أدنى 1024 رمز.
• نماذج Anthropic Claude 3.5/3 Haiku: حد أدنى 2048 رمز.

إبطال التخزين (كسر التخزين): التخزين حساس للغاية للتغيرات في البادئة. أي تغيير سيكسر التخزين ويجبر على كتابة جديدة:

• تغيير أي نص محتوى داخل كتل system أو tools أو messages المعينة كجزء من البادئة.
• تغيير ترتيب أو عدد تعريفات tool.
• تغيير معلمات tool_choice (مثل الانتقال من auto إلى أداة معينة).
• إضافة، إزالة، أو تغيير الصور داخل الطلب (بالنسبة للنماذج المتعددة الوسائط).
• قد يؤدي تغيير معلمات أخرى للنموذج تؤثر على المعالجة الأولية إلى كسر التخزين أيضًا (مثل إعدادات التفكير الممتد لشركة Anthropic يمكن أن تلغي تخزين الرسائل).

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

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

النماذج المدعومة: تخزين الطلبات غير متاح عالميًا عبر جميع النماذج أو الموردين. تحقق دائمًا من الوثائق الخاصة بالنموذج المحدد الذي تنوي استخدامه. (تم تأكيد حاليًا لمجموعة متنوعة من نماذج Claude 3 و3.5).

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

أفضل الممارسات للتخزين الفعال

لزيادة فوائد تخزين الطلب:

1. تنظيم الطلبات بذكاء: ضع المعلومات الأكثر استقرارًا وقابلية لإعادة الاستخدام (طلبات النظام، التعليمات، تعريفات الأدوات، وثائق السياق، أمثلة قليلة) في بداية تسلسل طلبك. ضع المعلومات الديناميكية والمتغيرة باستمرار (استفسارات المستخدم، آخر أدوار المحادثة) بعد نقطة اهتمام التخزين.
2. تحديد نقاط اهتمام مثالية: استخدم cache_control (أو آلية مكافئة) بشكل مدروس. ضع علامة على نهاية أكبر كتلة ممكنة من المحتوى الثابت حقًا. إذا كنت تستخدم نقاط اهتمام متعددة (كما يسمح بذلك Anthropic)، اعتبر مستويات مختلفة من الاستقرار في هيكل الطلب الخاص بك.
3. مراقبة استخدام التخزين: تحقق بانتظام من cache_creation_input_tokens وcache_read_input_tokens في استجابات واجهة برمجة التطبيقات الخاصة بك. استهدف نسبة عالية من القراءات إلى الكتابات على مر الزمن. إذا رأيت الغالبية العظمى هي كتابات، فقد تتغير بادئاتك في كثير من الأحيان، أو قد تكون أدناه الحد الأدنى لطول التخزين.
4. تجنب التغييرات غير الضرورية: كن واعيًا لـ أن أي تغييرات صغيرة، تبدو غير مهمة على ما يبدو، في محتوى البادئة (مثل إضافة مسافة أو تغيير علامات الترقيم) ستكسر التخزين. تأكد من التناسق في كيفية توليد البادئات.
5. النظر في مفاضلات التكلفة: يكون التخزين أكثر فعالية لـ البادئات الطويلة والمستخدمة بشكل متكرر. لا تقم بتخزين بادئات قصيرة جدًا، حيث أن المدخرات المحتملة ضئيلة وقد لا تفوق التعقيد. تجنب تخزين مدخلات المستخدم عالية التغير.
6. اختبر وكرر: جرب هياكل الطلب المختلفة ونقاط اهتمام التخزين للعثور على الاستراتيجية المثلى لحمل العمل ونمط الاستخدام لتطبيقك المحدد.

الخاتمة

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