عندما تطول محادثة تطبيق يعتمد على OpenAI API، لا يكفي حذف الرسائل القديمة عشوائيًا لتقليل حجم الطلب. فقد تحمل تلك الرسائل قرارات أو نتائج أدوات يحتاجها الرد التالي. تتيح ميزة ضغط السياق، أو Compaction، تقليل حجم السياق مع الاحتفاظ بالحالة اللازمة لاستكمال التفاعل. وهذا دليل للتحضير لعام 2027 استنادًا إلى الإمكانات المتاحة، وليس إعلانًا عن تغيير مستقبلي أو ضمانًا لتكلفة ثابتة.
ما الذي ينتج عن ضغط السياق؟
ينقل الضغط حالة مهمة من التفاعل السابق في عنصر ضغط مشفر، يستخدم رموزًا أقل لنقلها إلى الطلبات التالية. هذا العنصر معتم، وليس نصًا معدًا للقراءة البشرية أو ملخصًا يمكنك تحرير فقراته. لذلك ينبغي التعامل معه بوصفه جزءًا من سياق المحادثة الذي يعاد تمريره، لا جوابًا نهائيًا يعرض للمستخدم.
وهناك فرق بين عنصر الضغط وبين النافذة المضغوطة كاملة. ففي المسار المستقل قد تتضمن النافذة عناصر محتفظًا بها من السياق السابق، إلى جانب عنصر الضغط. اختزالها في العنصر المشفر وحده لا يطابق طريقة الاستخدام المحددة لهذا المسار.
الضغط داخل طلب Responses
يمكن تفعيل الضغط من جهة الخادم داخل طلب إنشاء الرد إلى POST /responses، باستخدام context_management وتحديد compact_threshold. عندما يتجاوز عدد رموز السياق المحسوب العتبة، ينفذ الخادم الضغط ويصدر عنصر الضغط ضمن تدفق الرد، ثم يستكمل التوليد. لا يحتاج هذا الأسلوب إلى استدعاء منفصل لنقطة الضغط المستقلة.
إذا كنت تدير المحادثة بمصفوفة مدخلات ترسلها في كل مرة، فألحق عناصر المخرجات، بما فيها عنصر الضغط، بسياق الطلب التالي. وبعد إلحاق المخرجات يمكن إسقاط العناصر التي تسبق أحدث عنصر ضغط لتقليل حجم الطلب. هذه توصية لهذا النمط، وليست قاعدة تطبق على جميع طرق إدارة الحالة.
عند استخدام previous_response_id
في نمط ربط الردود باستخدام previous_response_id، مرر رسالة المستخدم الجديدة في الدور التالي مع معرف الرد السابق. لا تجمع ذلك مع تقليم يدوي للسياق وفق قاعدة المصفوفة السابقة؛ فإدارة السلسلة هنا تختلف عن إعادة إرسال نافذة المدخلات كاملة.
الضغط المستقل والتحكم في توقيته
إذا أردت اختيار لحظة الضغط صراحة، فاستخدم POST /responses/compact. ترسل نافذة السياق التي جمعتها، وتشمل الرسائل وتفاعلات الأدوات والعناصر الأخرى، ثم تحصل على نافذة مضغوطة للطلب التالي. ويجب أن تظل النافذة المرسلة إلى عملية الضغط ضمن نافذة السياق التي يدعمها النموذج؛ فالضغط ليس وسيلة لإرسال مدخل يتجاوز الحد أصلًا.
احتفظ بمخرجات عملية الضغط المستقلة كاملة، وأرسلها كما هي في طلب /responses التالي، مع رسالة المستخدم الجديدة. لا تحذف العناصر المحتفظ بها من هذه النتيجة بحجة أن عنصر الضغط المشفر موجود بالفعل.
الاحتفاظ بالبيانات والتحقق قبل الاعتماد
المسار المستقل عديم الحالة ومتوافق مع عدم الاحتفاظ بالبيانات، بينما يرتبط توافق الضغط من جهة الخادم بهذا الوضع بضبط store=false في طلبات إنشاء الرد. لا تخلط بين إعداد التخزين وبين اختيار عتبة الضغط؛ فكل منهما يؤدي غرضًا مختلفًا.
قبل تشغيل محادثات طويلة، حدد نمطًا واحدًا لإدارة الحالة، واختبر استمرار القرارات المهمة ونتائج الأدوات بعد الضغط. راقب حجم السياق وزمن الاستجابة بدل افتراض أن كل عملية ستنتج نسبة تقليل واحدة. ويمكن متابعة إعدادات ضغط السياق عند مراجعة تكامل التطبيق.
