منذ فترة كتبت عن نمذجة اللغة دون شبكات عصبية، حيث ولّدت شكسبير باستخدام نموذج n-gram غير محدود: لا أوزان، لا تدريب، فقط العد. لحسن الحظ، صادفت الورقة 'Language Modeling is Compression'، التي ذكرت التكافؤ بين الضغط والتوقع: كل نموذج توقع هو جوهريًا ضاغط، وكل خوارزمية ضغط هي نموذج توقع. هذا أدى إلى السؤال الطبيعي: هل يمكن لـ gzip إجراء نمذجة لغة؟ بدون شبكة عصبية، بدون معلمات متعلمة، لا شيء. فقط الضاغط الذي يأتي مع نظام التشغيل الخاص بك. تُعدّه بمجموعة نصوص (corpus)، وتعطيه مPrompt نص عادي، ويستمر في ذلك المPrompt بالبحث عن تسلسلات البايت التي تضغط بشكل أفضل. إليك بعض المخرجات الحقيقية وغير المعدلة بعد إعداده على tiny Shakespeare:

gzipt --corpus data/tinyshakespeare.txt --prompt $'MENENIUS:\n' --length 200

MENENIUS:'Though all at once canq MARCIUS: Pray now, nocamest thou to a morsel .LARTIUS: Hence, and I' the end admire, where Gagain; and after it ag .النتيجة؟ إنه ليس نصًا متماسكًا تمامًا، لكنه claramente يعرف شيئًا عن النص. أكثر بكثير مما توقعته أن يعرفه gzip.

فكيف يمكن لضاغط أن يولد هذا؟ الضغط هو التوقع. فكّر في ما يفعله الضاغط. ينفق بضع بايتات على البيانات التي 'يتوقعها' والعديد من البايتات على البيانات التي لا يتوقعها. إذا أعطيتك ملفًا يحتوي على الحرف A مكررًا مليون مرة، يمكنك وصفه بجملة واحدة. مليون بايت عشوائي، من ناحية أخرى، لا يحتوي على بنية يمكن استغلالها ولا يضغط تقريبًا. هذا ليس مصادفة؛ بل هو جوهر نظرية المعلومات. عدد البتات اللازمة لترميز رمز هو $-\log_2 p$، حيث $p$ هو الاحتمال الذي يعينه النموذج له. الاحتمال العالي يعني عدد قليل من البتات. لذا فإن أي ضاغط يحتوي بشكل طبيعي على نموذج احتمال مخفي داخله، سواء كتبه أحد أم لا. يستخدم gzip DEFLATE، والذي يضغط البايتات التالية من خلال البحث عن مطابقات مقابل النص الحديث في نافذة منزلقة بحجم 32 KiB. إذا كانت الاستمرارية تعكس شيئًا موجودًا بالفعل في النافذة، فإن DEFLATE ترمّزها كإشارة خلفية رخيصة بدلاً من بايتات حرفية. وبالتالي: الاستمرارية التي يتوقعها gzip، لأنها تعكس نصًا موجودًا بالفعل في نافذته، تُضغط إلى تقريبًا لا شيء. هذا يعطينا درجة. إذا كان لدي بعض السياق وأريد معرفة مدى جودة استمرار مرشح، فأنا فقط أقيس: score(المرشح) = len(gzip(السياق + المرشح)). كلما كان الطول المضغوط أقل، كان المرشح أكثر 'توقعًا'. لتهيئة النموذج، أضمّن مجموعة نصوص في نافذة gzip. أي استمرار يشبه المجموعة يضغط صغيرًا، وأي استمرار لا يشبه المجموعة يضغط كبيرًا. التوليد عبر البحث بالحزمة. التقييم شيء؛ التوليد شيء آخر. النهج الساذج لاختيار البايت التالي الفردي الذي يضغط أفضل يفشل بشكل سيء، ولسبب دقيق: gzip يعطي فقط طول بايت صحيح (بدون كسور). إضافة بايت غالبًا لا يغير الطول المضغوط على الإطلاق، لذا فإن العديد من المرشحين يتعادلون والإشارة تُدفَن في ضوضاء الكمية. الحل هو النظر إلى الأمام بطول كامل قبل الالتزام. gzipt يجري بحثًا بالحزمة على تسلسلات البايت. في كل خطوة، السياق الحالي هو: نافذة المجموعة + ذيل حديث من (المPrompt + البايتات المولدة). ثم يحاول gzipt بايتات محتملة التالية. كل استمرار مرشح يُقيّم بضغط السياق + المرشح والتحقق من عدد البايتات التي يأخذها النتيجة المضغوطة. الحلقة هي:

المPrompt. ابدأ بمPrompt المستخدم كنص أولي للاستمرار. لا يوجد رمز بداية؛ بايتات المPrompt هي مجرد جزء من السياق الذي يراه gzip.

السياق. أظهر لـ gzip نافذة المجموعة بالإضافة إلى ذيل حديث من المPrompt/النص المولّد.

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

كرر لبايتات horizon.

الالتزام. خذ الاستمرارية الكاملة الأكثر قابلية للضغط (أو عيّن بين المتأهلين إذا كانت الحرارة إيجابية)، أضفها، واستمر.

...

الأسئلة الشائعة س: هل يمكن استخدام gzip كنموذج لغة؟

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