Codex olmayan modeller için açık kaynaklı Codex CLI, bağlamı yerel olarak sıkıştırır: bir LLM, bir sıkıştırma istemi kullanarak konuşmayı özetler. Sıkıştırılmış bağlam daha sonra kullanıldığında, responses.create() onu, özeti çerçeveleyen bir devir teslim istemi ile alır. Her iki istem de kaynak kodda görülebilir.
Codex modelleri için CLI bunun yerine compact() API'sini çağırır ve bu da şifrelenmiş bir blob döndürür. Dahili olarak bir LLM kullanıp kullanmadığını, hangi istemleri kullandığını veya herhangi bir devir teslim istemi olup olmadığını bilmiyoruz.
Aşağıda, basit bir istem enjeksiyonunun (2 API çağrısı, 35 satır Python) API sıkıştırma yolunun, bağlamı özetlemek için kendi sıkıştırma istemi ve özete eklenmiş bir devir teslim istemi ile bir LLM kullandığını nasıl ortaya çıkardığını gösteriyorum. İstemler, açık kaynaklı sürümlerle neredeyse aynıdır.
Adım 1 — compact()
Hazırlanmış bir kullanıcı mesajıyla compact()'ı çağırıyorum. Sunucu tarafında, bir sıkıştırıcı LLM, kendi gizli sistem istemini kullanarak girdimizi işler (daha önce hiç görmediğim ve bulmak istediğim).
Sunucu, sıkıştırıcının bağlamını şu şekilde birleştiriyor gibi görünüyor:
Sıkıştırıcı LLM, sistem istemini + girdimizi birlikte okur. Girdimiz bir enjeksiyon yükü (yukarıdaki kırmızı metin) içerdiğinden, sıkıştırıcı, kendi sistem istemini çıktısına dahil etmesi için kandırılır. Bu düz metin özeti yalnızca OpenAI'in sunucusunda bulunur. Biz yalnızca şifrelenmiş blob'u görürüz:
Bu noktada blob'un içinde ne olduğunu okumamızın hiçbir yolu yoktur. AES ile şifrelenmiştir ve anahtar OpenAI'in sunucularında bulunur. Sadece sıkıştırıcının enjeksiyona uyduğunu ve istemini özete yazdığını umarız. Bunu öğrenmenin tek yolu Adım 2'dir.
Adım 2 — create()
Şifrelenmiş blob'u + ikinci bir kullanıcı mesajını responses.create()'a iletiyorum. Sunucu blob'un şifresini çözer ve modelin bağlamını birleştirir.
Gönderiyorum:
Model şöyle bir şey görüyor gibi görünüyor:
Adım 1 işe yaradıysa, şifresi çözülmüş blob, sıkıştırma istemini (enjeksiyonumuzla sızdırılan) içermelidir. Sunucu ayrıca blob'a bir devir teslim istemi ekler. Dolayısıyla, probumuz modelin gördüklerini tekrarlamasını başarıyla sağlarsa, çıktı her üçünü de ortaya çıkarmalıdır: sistem istemi, devir teslim istemi ve sıkıştırma istemi.
Çıktı
Aşağıda, extract_prompts.py'nin bir çalıştırmasından alınan eksiksiz, düzenlenmemiş çıktı bulunmaktadır. Sarı = sistem istemi, yeşil = devir teslim istemi, pembe = sıkıştırma istemi.
Bunların gerçek istemler olduğunu ve sadece halüsinasyon görülen metinler olmadığını nasıl bilebiliriz? Çıkarılan sıkıştırma istemi ve devir teslim istemi, açık kaynaklı Codex CLI'deki (prompt.md, summary_prefix.md) codex olmayan modeller için kullanılan bilinen istemlerle yakından eşleşir; bu da modelin bunları sıfırdan icat etmesini olası kılmaz. Sonuçlar çalıştırmalar arasında farklılık gösterir.
Tahmini İşlem Hattı
Hepsini bir araya getirdiğimizde, çıkarma işleminin ortaya çıkardıklarına dayanarak compact()'ın sunucu tarafında ne yaptığına dair en iyi tahminimiz aşağıdadır.
Komut Dosyası
Açık Soru
Altta yatan istemler neredeyse aynıyken, Codex CLI neden iki tamamen farklı sıkıştırma yolu (codex olmayan modeller için yerel LLM, codex modelleri için şifrelenmiş API) kullanıyor? Peki özeti neden şifreleyelim ki?
Söylemesi zor. Belki de şifrelenmiş blob, bu basit deneyin ortaya çıkarabileceğinden daha fazlasını taşıyordur, örn. araç sonuçlarının nasıl sıkıştırılıp geri yüklendiğine dair belirli bir şey. Ama daha fazla test etmeye zahmet etmedim.
