كيفية استخراج آثار التفكير في الذكاء الاصطناعي: دراسة حالة حول التقطير على مرحلتين وعزل واجهة برمجة التطبيقات
يعد تقطير نماذج الذكاء الاصطناعي أحد أكثر الموضوعات حساسية في صناعة نماذج اللغات الكبيرة. عندما يصبح نموذج جديد أقوى بشكل ملحوظ فجأة، أو تبدأ إجاباته في التشابه مع سلوك معين،
كيف يتم استخراج مسارات الاستدلال في الذكاء الاصطناعي: دراسة حالة حول التقطير على مرحلتين وأمن واجهات البرمجة
مقدمة
كان تقطير نماذج الذكاء الاصطناعي دائمًا أحد أكثر المواضيع حساسية في صناعة نماذج اللغة الكبيرة. عندما يصبح نموذج جديد أقوى فجأة بشكل ملحوظ، أو تبدأ إجاباته في إظهار خصائص سلوكية لنماذج رائدة، يتساءل الباحثون بطبيعة الحال عما إذا كان هناك شكل من أشكال نقل المعرفة أو الاستدلال.
ورقة بحثية حديثة من 116 صفحة أضافت نوعًا مختلفًا من الأدلة إلى هذا النقاش. أفاد الباحثون أن حالات الاستدلال المخفية المكشوفة في سير عمل واجهات برمجة تطبيقات محددة، في ظل الظروف التي درسوها، يمكن استعادتها بمساعدة نموذج آخر. كما طرحت الدراسة نفسها مخاوف أمنية أوسع: إذا لم تكن مسارات الاستدلال ومسارات سلوك الوكلاء معزولة بصرامة كافية عند تخزينها أو مشاركتها أو إعادة تشغيلها، فقد تحتوي على معلومات حساسة.
ينبغي اعتبار هذه النتائج نتاجًا بحثيًا، وليس حكمًا نهائيًا على مسألة تقطير الذكاء الاصطناعي. لم يدّعِ المؤلفون أن كل تشابه بين النماذج يثبت وجود تقطير. بدلاً من ذلك، تقدم تجاربهم أدلة جديدة حول كيفية نقل مسارات الاستدلال وإعادة إنتاجها وكشفها.
كشف عملية استدلال Opus من خلال استدعاءين لواجهة برمجة التطبيقات
حقق باحثون من معهد MATS Research وELLIS Institute Tübingen ومؤسسات أخرى فيما إذا كان يمكن استعادة الاستدلال المخفي عادةً خلف واجهات برمجة التطبيقات.
يستخدم الإعداد التجريبي المُبلغ عنه نموذجًا أقوى لتوليد حالات الاستدلال، ونموذجًا أصغر من نفس عائلة النماذج لتفسير حالات الاستدلال هذه. في المثال الموصوف في المقالة المصدر، يولّد Opus 4.8 الاستدلال بينما يُستخدم Haiku 4.5 لكشف عملية الاستدلال المخفية.
أُبلغ أيضًا أن نفس الفكرة العامة طُبقت على أنظمة نماذج أخرى، بما في ذلك نماذج OpenAI وGoogle. النقطة الأساسية ليست في أن النماذج الأصغر يمكنها بطبيعتها قراءة الحالات الداخلية لجميع النماذج الأقوى، بل في أن البنية التحتية المشتركة لواجهات برمجة التطبيقات وتنسيقات حالات الاستدلال المتوافقة قد تخلق واجهات تفاعل غير متوقعة.
العملية الموصوفة في المقالة المصدر بسيطة بشكل مدهش.
الخطوة الأولى: جعل النموذج الأقوى يحل المشكلة
الطلب الأول يجعل Opus 4.8 يحل مشكلة، مثل إيجاد أكبر عامل أولي للرقم 8،139،881.
وفقًا للمقالة المصدر، يحتوي استجابة واجهة برمجة التطبيقات على معلومتين مرتبطتين: ملخص استدلال مُعالج وسلسلة طويلة تبدو غير قابلة للقراءة. تحدد المقالة الأخيرة كتمثيل مشفر لسلسلة التفكير الكاملة للنموذج.
الخطوة الثانية: إعادة تشغيل كتلة الاستدلال على نموذج آخر
يضع الهجوم المُبلغ عنه بعد ذلك الكتلة المشفرة في طلب جديد، ويبدّل النموذج إلى Claude Haiku 4.5.
يطلب الموجه من النموذج الأصغر المتابعة وإعادة إنتاج الاستدلال المرتبط بالحالة المقدمة داخل وسم <thinking-copy>.
وفقًا للتجارب المُبلغ عنها، تمكن Haiku من إعادة إنتاج عملية الاستدلال المخفية. تشمل المسارات المستعادة المزعومة عمليات القسمة التجريبية والاستبعاد والتحليل إلى عوامل والتحقق.
كما أن عدد الرموز المُبلغ عنه مذهل. تقول المقالة المصدر إن الكمية المستخرجة
من رموز الاستدلال تقترب من عدد رموز التفكير التي تمت فوترتها فعليًا في واجهة برمجة التطبيقات، مما يشير إلى أن المواد المستعادة ليست مجرد ملخص قصير.
لماذا يمكن للنماذج الأصغر قراءة الحالات المخفية للنماذج الأقوى؟
هذا هو السؤال التقني الجوهري.
عادةً ما تحتاج نماذج الاستدلال إلى تنفيذ عمل متعدد الخطوات. في المهام الوكيلة، قد يبحث النموذج في الويب، وينفّذ كودًا، ويستدعي أدوات، ويفحص النتائج، ثم يواصل الاستدلال من الحالة الناتجة.
يجب الحفاظ على هذه الحالة بين استدعاءات واجهة برمجة التطبيقات.
أحد البنى الممكنة هو حفظ الحالة على جانب العميل، بدلاً من تخزين كل شيء على خوادم المزود. يمكن تعبئة حالة الاستدلال للنموذج في كتلة مشفرة، وإعادتها إلى العميل، ثم تقديمها مرة أخرى في الطلبات اللاحقة. يمكن للخادم فك تشفير الكتلة، مما يسمح للنموذج بالمتابعة من حيث توقف.
هذا التصميم يمكن أن يقلل من متطلبات التخزين على جانب الخادم ويدعم سير العمل الذي يركز على الخصوصية. لكنه أيضًا ينشئ حدًا أمنيًا يجب تنفيذه بحذر.
المشكلة المُبلغ عنها هي أن كتل الاستدلال المشفرة لا ترتبط دائمًا بشكل كافٍ بسياقها الأصلي. في الظروف التي درسها الباحثون، أنتج هذا ثلاثة أشكال من قابلية التشغيل البيني:
- عبر الجلسات: يمكن إعادة استخدام كتل استدلال من جلسات سابقة في جلسات جديدة.
- عبر المستخدمين: يمكن تقديم كتل استدلال مكشوفة علنًا من قبل مستخدم آخر.
- عبر النماذج: يمكن معالجة كتل استدلال مولدة بواسطة نماذج أقوى بواسطة نماذج أخرى من نفس المزود.
قد تكون لهذه السلوكيات دوافع هندسية معقولة. تبديل النماذج، وأنظمة التراجع، وضغط السياق، وسير عمل الوكلاء طويلة الأمد تستفيد جميعها من الحالة القابلة لإعادة الاستخدام.
المشكلة تكمن في أنه إذا لم تكن الحالة مقيدة بدقة بالمستخدم الأصلي والجلسة والنموذج وسياق التفويض، فإن قابلية التشغيل البيني نفسها قد تصبح سطح هجوم.
وحدة فك ترميز منخفضة التكلفة يمكن أن تغير الاقتصاديات
اكتشاف مهم آخر يتعلق بالتكلفة.
قدّرت المقالة المصدر أنه بناءً على افتراضات تسعير واجهة برمجة التطبيقات الخاصة بـ Haiku 4.5 المُشار إليها، عندما يحتوي كل مسار على حوالي 12,000 رمز إدخال وإخراج، تبلغ التكلفة الاسمية لفك تشفير 10,000 مسار استدلال حوالي 720 دولارًا أمريكيًا.
هذا يغير اقتصاديات استخراج مسارات الاستدلال. إذا كان النموذج المكلف يُستخدم فقط لتوليد الحالات الأصلية بينما يقوم نموذج أرخص بفك التشفير، فإن الهجمات التي تتطلب وصولًا مكلفًا إلى نماذج متطورة قد تصبح أكثر عملية.
هذا مهم بشكل خاص لمزودي النماذج، لأن مسارات الاستدلال يمكن أن تمثل جزءًا مهمًا من القيمة المبدعة أثناء عملية الاستدلال. إذا أمكن استعادة هذه المسارات وإعادة استخدامها خارج حدودها المقصودة، فقد تصبح شكلًا جديدًا من تسريب الملكية الفكرية للنماذج.
لغز التقطير يحصل على أول أدلة
بمجرد حصول الباحثين على مسارات استدلال أكثر اكتمالاً، استخدموها للتحقيق في سؤال أوسع: هل يمكن أن تكشف أنماط الاستدلال الخاصة بنموذج معين عن دليل على التقطير؟
أجرى الباحثون تجربتين.
التجربة 1: إعادة إنتاج رموز استدلال متتالية
في التجربة الأولى، اختار الباحثون
16 رمزًا متتاليًا من مسار استدلال Opus، وجعلوا عدة نماذج تواصل حل نفس المشكلة.
الفكرة بسيطة: إذا كان بإمكان نموذج إعادة إنتاج نفس الاستمرار بسهولة أكبر من نموذج آخر، فقد يشير ذلك إلى أنه تعلم شيئًا قريبًا بشكل غير طبيعي من نمط استدلال النموذج المصدر.
كانت الفروق المُبلغ عنها كبيرة.
أحد النماذج يحتاج نظريًا إلى حوالي 10 مليارات محاولة لإعادة إنتاج عبارة Opus المختارة عن طريق الصدفة. نموذجان آخران قُدر أنهما يحتاجان إلى حوالي 100 تريليون و1000 تريليون محاولة على التوالي.
بمعنى آخر، في المقارنة المُبلغ عنها، كان أحد النماذج أسهل في إعادة إنتاج نفس نمط استدلال Opus بحوالي مليون مرة مقارنة بالنماذج البديلة.
التجربة 2: حقن بداية الاستدلال فقط
التجربة الثانية زودت نموذجًا آخر فقط ببداية مسار استدلال Opus، ثم لاحظت كيف تطورت استجابته.
في أحد الأمثلة، تم توفير خمسة رموز فقط.
وفقًا للتقارير، حتى هذه الكمية الصغيرة من المعلومات جعلت صياغة النموذج الهدف وإجابته وإيقاع حل المشكلات تنزاح نحو مسار Opus. ارتفعت درجة التشابه المُبلغ عنها من 0.17 إلى 0.33.
ثم وسّع الباحثون الاختبار ليشمل 30 سؤالًا. وفقًا للمقالة المصدر، أظهرت 29 من هذه الأسئلة نفس التأثير العام: إعطاء النموذج نقطة بداية بأسلوب Opus جعل الاستجابات اللاحقة أكثر شبهاً بـ Opus مقارنة باستخدام نقطة بداية من نموذج آخر.
هل يثبت هذا التقطير؟
هذا وحده ليس كافيًا.
تؤكد المقالة المصدر أن الباحثين لم يعلنوا حل مسألة التقطير. تشابه المخرجات أو أنماط الاستدلال هو دليل يستحق التحقيق، لكنه لا يثبت تلقائيًا أن نموذجًا تم تدريبه مباشرة على بيانات استدلال خاصة لنموذج آخر.
ما تقدمه هذه التجارب هو طريقة أكثر تحديدًا لدراسة خصائص الاستدلال الخاصة بنموذج معين، لأنه الآن يمكن تحليل مسارات استدلال أطول.
GitHub ومسارات الوكلاء العامة تخلق مشكلة أمنية أخرى
هذه المشكلة لا تقتصر على شركات النماذج.
وفقًا للتقارير، جمع الباحثون 6,708 مسارًا وكيلًا متاحًا للعموم من GitHub وHugging Face، وأعادوا بناء 315,320 كتلة استدلال.
من بين هذه المسارات، احتوى 328 مسارًا على عنصر حساس واحد على الأقل، أي حوالي 4.9% من المسارات المجمعة.
ذكرت المقالة المصدر أن الباحثين وجدوا:
- 62 مفتاح واجهة برمجة تطبيقات
- 33 كلمة مرور
- 24 رمز وصول
- 7 مفاتيح خاصة
- 30 عنوان بريد إلكتروني شخصي
- 130 اسمًا شخصيًا
- 36 عنوانًا بريديًا
هذا تحذير عملي حقيقي للمطورين الذين يبنون أنظمة وكلاء.
قد يبدو المسار وكأنه مخرجات تصحيح أخطاء عادية، لكنه قد يحتوي على معاملات أدوات، ومتغيرات بيئة، وبيانات اعتماد، ومعلومات شخصية، وعناوين URL داخلية، أو بيانات أخرى لا ينبغي أبدًا أن تكون جزءًا من مجموعات تدريب عامة أو مستودعات.
إذا كان سيتم تسجيل مسارات الوكلاء أو مشاركتها أو نشرها، يجب على المطورين التعامل معها كبيانات حساسة محتملة، وليس كسجلات تطبيقات عادية.
أسئلة شائعة
ما هو مسار الاستدلال في الذكاء الاصطناعي؟
مسار الاستدلال في الذكاء الاصطناعي هو الحالات الوسيطة أو المخرجات المتعلقة بالاستدلال التي يولدها النموذج أثناء عمله على مهمة. اعتمادًا على تصميم واجهة برمجة التطبيقات، قد يتلقى المستخدم ملخصًا أو حالات استدلال منظمة أو تمثيلات مشفرة بدلاً من الحسابات الداخلية الأصلية للنموذج.
ما هو تقطير نماذج الذكاء الاصطناعي؟
تقطير النماذج هو تقنية تسمح لنموذج أصغر أو مختلف بالتعلم من سلوك نموذج أكبر أو أقوى. تُستخدم على نطاق واسع لنقل القدرات المفيدة إلى نماذج أقل تكلفة في التشغيل أو أسرع.
هل يمكن لاستعادة مسارات الاستدلال إثبات أن نموذجًا تم تقطيره؟
لا.
استعادة مسار الاستدلال يمكن أن تقدم دليلاً على تشابه النماذج، لكنها في حد ذاتها لا تحدد كيفية تدريب النموذج. لإجراء إسناد أكثر قوة، يلزم الحصول على مصادر بيانات التدريب والتجارب المضبوطة والأدلة الأخرى.
لماذا تشكل حالات الاستدلال المشفرة خطرًا أمنيًا؟
التشفير يحمي محتوى كتلة الحالة، لكنه لا يضمن تلقائيًا أن كتلة الحالة مرتبطة بالمستخدم أو الجلسة أو النموذج أو سياق التفويض الصحيح. إذا كانت هذه الحدود ضعيفة، فقد يتم إعادة استخدام حالة مشفرة صالحة في سياقات غير مقصودة.
لماذا تعتبر مسارات الوكلاء حساسة؟
قد تحتوي مسارات الوكلاء على استدعاءات أدوات، وموجهات، ومتغيرات بيئة، وبيانات اعتماد API، وبيانات شخصية، ومسارات ملفات داخلية، ومعلومات أخرى يتم جمعها أثناء التنفيذ. لذلك، إذا تم نشرها دون تنظيف مناسب، حتى لو كان التطبيق الأصلي يبدو غير ضار، فقد تؤدي إلى كشف معلومات سرية.
هل يجب على المطورين نشر مسارات الوكلاء الخام على GitHub؟
يجب تجنب نشر المسارات الخام ما لم تتم مراجعتها وتنظيفها بعناية. قبل مشاركة المسارات، يجب إزالة المعلومات السرية والرموز وبيانات الاعتماد والمعلومات الشخصية وعناوين URL الخاصة والبيانات الملكية.
هل تستطيع النماذج الأصغر دائمًا فك تشفير استدلال النماذج الأكبر؟
لا. النتائج المبلغ عنها تعتمد على سلوك API المحدد، وسلسلة النماذج، وتنسيق حالة الاستدلال، والظروف التجريبية. لا ينبغي تفسير ذلك على أنه قاعدة عامة بأن النماذج الأصغر يمكنها دائمًا استعادة استدلال النماذج الأكبر.
الأدوات ذات الصلة
- توثيق Anthropic API: الوثائق الرسمية لتطوير Claude API والنماذج.
- توثيق منصة OpenAI: الوثائق الرسمية لتكامل OpenAI API والنماذج.
- توثيق Google Gemini API: الوثائق الرسمية للبناء باستخدام نماذج Gemini.
- GitHub: منصة شائعة لعرض ومشاركة الكود المصدري ومسارات الوكلاء.
- Hugging Face: المنصة الرئيسية للنماذج ومجموعات البيانات وموارد أبحاث التعلم الآلي.
الروابط ذات الصلة
- توثيق Anthropic: وثائق Claude API الرسمية للمطورين.
- توثيق OpenAI: الوثائق الرسمية لـ OpenAI API.
- مطورو Google AI: الموارد الرسمية لمطوري Gemini وGoogle AI.
- GitHub: منصة استضافة الكود المصدري والتعاون المتعلقة بمسارات الوكلاء العامة.
- [Hugging
Face](https://huggingface.co/): مركز النماذج ومجموعات البيانات المشار إليه في المقالة المصدر.
- المرجع المصدر على منصة X: المنشور المرجعي المشار إليه في المقالة الأصلية.
الملخص
تسلط الأبحاث المبلغ عنها الضوء على حدود أمنية دقيقة ولكنها مهمة حول حالات الاستدلال في الذكاء الاصطناعي. إذا كان من الممكن إعادة استخدام كتل الاستدلال عبر الجلسات أو المستخدمين أو النماذج دون ارتباطات تفويض صارمة، فقد تتحول ميزة مصممة لدعم إدارة الحالة بكفاءة إلى قناة استخراج غير متوقعة.
يوفر هذا البحث أيضًا طريقة جديدة للتحقيق في تشابه النماذج وربما التقطير (distillation) من خلال فحص مسارات استدلال أطول بدلاً من الاعتماد على الإجابات النهائية فقط. في الوقت نفسه، هذه النتائج ليست حكمًا نهائيًا على ما إذا كان أي نموذج محدد قد تم تدريبه من خلال تقطير غير مصرح به.
بالنسبة للمطورين، الدرس الأكثر مباشرة عملي: تعامل مع حالات الاستدلال ومسارات الوكلاء كبيانات حساسة، وفرض ربط الهوية والجلسة والنموذج وحدود الوصول بدقة قبل التخزين أو المشاركة.