GPT-4o görüntüleri nasıl kodluyor olabilir?

xguru · 2024-06-10T09:39:37+09:00

GPT-4o, yüksek çözünürlük modunda kullanılan her 512x512 karo için 170 token ücretlendiriyor. Yaklaşık 0,75 token/kelime oranına bakıldığında bu, bir görselin yaklaşık 227 kelimeye eşit olduğu anlamına geliyor “Bir resim bin kelimeye bedeldir” sözüyle karşılaştırıldığında yaklaşık 4 kat fark var 170 sayısı tuhaf denecek kadar spesifik bir sayı. OpenAI fiyatlandırmada “20 dolar” veya “0,50 dolar” gibi yuvarlanmış sayılar ya da iç boyutlarda 2 ve 3’ün kuvvetlerini kullanıyor Neden 170 gibi bir sayı seçilmiş olabilir? Programlamada, kod tabanına açıklama olmadan bırakılan sayılara “magic number” denir; 170 oldukça dikkat çekici bir magic number Görsel maliyetini neden token sayısına dönüştürsünler? Amaç yalnızca faturalandırma olsaydı, karo başına maliyeti listelemek daha az kafa karıştırıcı olurdu Ya OpenAI’nin 170’i seçmesinin nedeni bunun kelimenin tam anlamıyla doğru olmasıysa? Ya bir görsel karo gerçekten 170 ardışık embedding vektörüyle temsil ediliyorsa? Embedding Transformer modelleri hakkında önce hatırlanması gereken şey, ayrık token’lar üzerinde değil vektörler üzerinde çalıştıklarıdır Girdi vektör olmak zorundadır; aksi halde transformer’ın temelindeki iç çarpım benzerliği anlamsız olurdu Token kavramının tamamı bir ön işleme aşamasıdır: metin token’lara dönüştürülür ve token’lar, transformer modelinin ilk katmanına ulaşmadan önce bir embedding modeli tarafından embedding vektörlerine çevrilir Örneğin Llama 3, dahili olarak 4.096 özellik boyutu kullanır “My very educated mother just served us nine pizzas.” cümlesine bakarsak Bu cümle BPE tarafından 10 tamsayı token’a (nokta dahil) dönüştürülür; ardından her biri embedding modeli tarafından 4.096 boyutlu vektöre çevrilir ve sonuç 10x4096’lık bir matris olur Transformer modeline verilen “gerçek” girdi budur Ancak bu vektörlerin mutlaka bir metin embedding modelinden gelmesi gerektiğine dair bir kural yoktur Bu, metin verisi için iyi çalışan bir stratejidir; fakat transformer’a beslemek istediğiniz başka veri türleri varsa, farklı bir embedding stratejisi kullanabilirsiniz OpenAI’nin 2021’de CLIP embedding modelini yayımlamış olması, bu yönde düşündüklerini gösteriyor CLIP, metni ve görselleri aynı anlamsal vektör uzayına gömer; böylece cosine similarity kullanarak bir metin dizisiyle ilişkili görselleri ya da başka görsellere anlamsal olarak benzeyen görselleri bulabilir Ancak CLIP tüm görseli tek bir vektör olarak gömer, 170 tane olarak değil. GPT-4o, görselleri (ve aynı şekilde video, ses ve diğer veri türlerini) temsil etmek için dahili olarak başka gelişmiş stratejiler kullanıyor olmalı. “Omnimodal” olmasının nedeni de bu Özellikle görsel verisi için bu stratejinin ne olabileceğini çıkarım yoluyla anlamaya çalışalım Özellik boyutu sayısı GPT-4o’nun embedding vektörlerini temsil etmek için dahili olarak kullandığı boyut sayısını tahmin etmeye çalışırsak, bu bilgi kapalı kaynak olduğu için gerçek sayıyı bilemeyiz; ancak makul varsayımlar yapabiliriz OpenAI’nin 2’nin kuvvetlerini sevdiği ve bazen buna tek bir 3 çarpanı eklediği görülüyor Örneğin ada-002 embedding için 1.536, text-embedding-3-large için ise 3.072 kullanıyor GPT-3’ün genel olarak 12.288 boyut kullandığı biliniyor GPT-4o bu parametreyi korumuş ya da artırmış olabilir Embedding sayısının GPT-3’ten GPT-4o’ya düşmüş olması olası görünmüyor, ama imkânsız da değil GPT-4 Turbo gibi sürümler önceki versiyonlara göre gerçekten daha hızlı ve daha ucuzdu; geliştiricilerin daha küçük boyutun kalite açısından eşdeğer derecede iyi olduğunu gösteren benchmark sonuçları varsa, embedding boyutunu küçültmek bunun bir parçası olmuş olabilir GPT-4o içinde kullanılan özellik boyutu sayısının şu değerlerden biri olması muhtemel: 1536, 2048, 3072, 4096, 12228, 16384, 24576 GPT-4o’nun embedding vektörü boyutu için 12.228 kullandığını varsayacağım. 2 ya da 4 katı kadar sapma olsa bile bu çok önemli değil. Aynı argüman geçerli olur Görsel embedding Görsel karo kare olduğu için, büyük olasılıkla kare bir token ızgarasıyla temsil ediliyordur 170, 13x13’e çok yakındır Fazladan token, CLIP’e benzer şekilde tüm görselin gestalt izlenimini kodlayan tek bir embedding vektörü olabilir Peki 512x512x3’ten 13x13x12228’e nasıl gidilebilir? Strateji 1: Ham piksel Görseli vektör uzayına koymanın çok basit bir yolu: 512x512 görseli 8x8’lik “mini karo” ızgarasına bölmek Her mini karo 64x64x3 olur ve 12.228 boyutlu bir vektöre açılır Her mini karo tek bir embedding vektörüdür Tüm görsel karo 64 ardışık embedding vektörüyle temsil edilir Bu yaklaşımın iki sorunu var: 64 ≠ 170 Çok saçma (ham RGB değerleriyle embedding yapıp gerisini transformer’ın çözmesini beklemek pek mantıklı değil) Strateji 2: CNN Neyse ki bu özelliklere sahip bir model zaten var ve 10 yılı aşkın süredir görsel veriyi başarıyla işliyor: convolutional neural network (CNN) CNN’ler translation ve scale invariance gibi özelliklere sahiptir AlexNet ve YOLO, tipik CNN mimarilerine örnek olarak verilebilir CNN, ham pikselleri anlamsal vektörlere sıkıştıran bir huni gibidir YOLO, görseli tek bir düzlemsel vektöre indirgemez; 13x13’te durur YOLOv3’ün çıktısı, her biri 1.024 boyutlu 169 farklı vektörden oluşan 13x13’lük bir ızgaradır GPT-4o’nun varsayımsal görsel embedding CNN’inin, bu CNN mimarilerinin formuna benzemesi beklenir 512x512x3’ten 13x13x12228’e gitmek için standart CNN katmanlarının nasıl kullanılabileceğine dair bir öneri sunuluyor AlexNet’e benzer bir tasarım bunu zarif biçimde başarabilir (aynı tekrar eden 5 blok kullanarak) YOLO’ya daha çok benzeyen bir alternatif de var, ancak 13x13 yerine 12x12’ye ulaşıyor Bunu kanıtlamak mümkün değil, fakat bu spekülatif tasarım, görselleri kxk embedding vektörü ızgarası olarak temsil edebilen makul bir CNN mimarisinin var olabileceğini gösteriyor Deneysel doğrulama GPT-4o gerçekten 13x13’lük bir embedding vektörü ızgarası görebiliyor olabilir mi? Bunu test etmek için, Zener kartlarından ilham alan bir görev tasarlanmış: bir görsel ızgarasındaki tüm sembollerin renk ve şekillerini tanımlamak Basit bir programla test amaçlı ızgara görselleri üretilmiş ve GPT-4o’dan her hücrenin şekil ve rengini JSON dizi formatında açıklaması istenmiş Eğer 13x13 hipotezi doğruysa, GPT-4o’nun 13x13 boyutuna kadar iyi performans gösterip sonrasında düşüş yaşaması beklenirdi Ancak gerçekte model, yalnızca 5x5 ve daha küçük ızgaralarda kusursuz performans gösteriyor; sonrasında performans keskin biçimde düşüyor 7x7 ızgarada %76 doğruluk gösterirken, 13x13 ızgarada şans seviyesinde performans sergiliyor Bu da 169 token’ın 13x13’lük bir ızgarayı temsil ettiği hipotezinin yanlış olduğu anlamına geliyor Ancak 5x5 ızgara sonucu, GPT-4o’nun bir görsel içindeki 25 farklı nesneyi ve bunların mutlak konumlarını takip edebildiğini düşündürüyor Temel fikir doğru olabilir ama boyut yanlış tahmin edilmiş olabilir; CNN’e daha fazla katman eklenerek 13x13 yerine 5x5’e düşürülebilir Yalnızca 5x5 ve altındaki ızgaraların kullanıldığını varsayarsak, 170 token’a ulaşmak için çıktının nasıl yapılandırılmış olabileceği üzerine düşünmek gerekir Piramit stratejisi 85 ve 170’e yakın sayılar elde etmenin bir yolu, görüntünün giderek daha ayrıntılı düzeylerde bir dizi piramit gibi kodlandığını varsaymaktır Tüm görüntünün gestalt izlenimini yakalamak için tek bir embedding vektörüyle başlayıp, sol/orta/sağ ve üst/orta/alt kısımları yakalamak için 3x3 eklenmesi, ardından 5x5, 7x7 vb. eklenmesi Bu strateji 7x7’de durulursa “master thumbnail” için 85 tokene çok yaklaşır 12+32+52+72=1+9+25+49=84 Son 9x9 gridin eklenmesi 170’e çok yaklaşır 12+32+52+72+92=1+9+25+49+81=165 512x512 tile için geçici bir 2x2 grid kullanıp her biri için özel bir token varsayılırsa tam olarak eşleşme sağlanabilir 1+12+32+52+72=1+1+9+25+49=85 1+12+22+32+52+72+92=1+1+4+9+25+49+81=170 Bu şemada satırların başlangıcı ve sonu için herhangi bir ayraç yok, ancak bu durum, metin token’larının konum bilgisinin RoPE ile kodlanmasına benzer şekilde 2D konumsal kodlama ile ele alınabilir Yukarıdakiler yalnızca tek sayılı grid boyutlarını aldığı ve 5x5’i atladığı için, Zener grid performansının 5x5 sonrasında düşmeye başladığına dair kanıtlarla tamamen örtüşmez Alternatif olarak 5x5’e kadar tüm gridler (çift ve tek) alınabilir Bu yaklaşım 55 token verir: 12+22+32+42+52=55 Her mini tile başına 3 token ve her tile arasında 1 ayraç token varsayılırsa 170’e ulaşılabilir 3×(12+22+32+42+52)+5=170 Sayısal gerekçelendirme açısından tamamen tatmin edici değil, ancak ampirik sonuçlarla iyi örtüşüyor Piramit stratejisi sezgisel olarak çok çekici ve farklı yakınlaştırma düzeylerinde uzamsal bilgiyi kodlamanın neredeyse “apaçık” bir yolu gibi hissettiriyor Bu, neden 5x5 grid ve altında iyi performans gösterip 6x6 ve üstünde çok kötüleştiğini açıklayabilir Tüm hipotezler her şeyi açıklamaya büyüleyici derecede yakın görünüyor, ancak rakamlar hiçbir zaman tam olarak temiz biçimde yerine oturmuyor gibi; bu da can sıkıcı Yine de bu tür bir piramit stratejisi, aklıma gelen en iyi yöntem Optik karakter tanıma (OCR) Yukarıdaki hipotezlerin hiçbiri GPT-4o’nun OCR’ı nasıl yaptığını açıklamıyor CLIP özünde OCR’ı, en azından büyük metin blokları söz konusu olduğunda, çok iyi yapamaz (Buna rağmen GPT-4o’nun OCR yapabiliyor olması başlı başına oldukça şaşırtıcı ve ortaya çıkan yeteneklerin açık bir örneği) GPT-4o açıkça yüksek kaliteli OCR yapabiliyor Uzun metin bloklarını yazıya dökebiliyor ve el yazısı metni ya da kaydırılmış, döndürülmüş, perspektifi değişmiş veya kısmen örtülü metni okuyabiliyor Modern OCR motorları görüntüyü temizlemek, karakterlerin sınır kutularını ve bantlarını bulmak, ardından bu bantlar boyunca özel karakter tanıma modellerini bir seferde bir karakter veya kelime çalıştırmak için çok iş yapar Yalnızca büyük bir CNN kullanmazlar Teorik olarak OpenAI gerçekten bu kadar iyi bir model inşa etmiş olabilir, ancak bu, Zener grid görevindeki görece zayıf performansla tutarlı değil Bir görüntüde temiz bir 6x6 grid içindeki 36 sembolü okuyamıyorsa, yüzlerce metin karakterini kusursuz şekilde okuyamamalı Bu tutarsızlığı açıklamak için basit bir teori: OpenAI’ın Tesseract gibi hazır bir OCR aracı (veya özel, son teknoloji bir araç) çalıştırıp tanımlanan metni görüntü verisiyle birlikte transformer’a verdiğini düşünüyorum Bu, ilk sürümlerin neden görüntü içine gizlenmiş metinlerle kolayca karıştığını açıklayabilir (çünkü GPT-4o açısından o metin prompt’un bir parçasıydı) Bu artık düzeltilmiş görünüyor ve GPT-4o, görüntü içine gizlenmiş kötü amaçlı prompt’ları görmezden gelmekte başarılı Ancak bu, görüntüde bulunan metin için neden token başına ücret alınmadığını açıklamıyor İlginç biçimde, metni görüntü olarak göndermek gerçekten daha verimli Küçük ama okunabilir yazı tipine sahip bir 512x512 görüntüye kolayca 400-500 metin token’ı sığabilir, ancak yalnızca “master thumbnail” için 85’e ek olarak 170 giriş token’ı ücretlendirilir; toplam 255 token eder (görüntüdeki kelime sayısından çok daha az) Bu teori, görüntü işlenirken neden ek gecikme oluştuğunu açıklıyor CNN’ler özünde anlıktır, ancak üçüncü taraf OCR ek zaman gerektirir Ayrıca (bunun bir şeyi kanıtladığını söylemiyorum ama) OpenAI code interpreter’da kullanılan Python ortamında PyTesseract kurulu Yüklediğiniz bir görüntü üzerinde PyTesseract çalıştırarak ikinci bir görüş almasını isteyebilirsiniz Sonuç Aslında tek bir sağlam olgudan, yani OpenAI’ın büyülü 170 sayısını kullanmış olmasından yola çıkarak epey tahminde bulundum Ancak YOLO gibi diğer CNN mimarileriyle oldukça uyumlu, tamamen makul bir yaklaşım var gibi görünüyor: görüntü tile’larını embedding vektörlerine eşlemek Bu yüzden 170 token’ın yalnızca görüntü işleme için gereken yaklaşık hesaplama miktarını faturalandırmak amacıyla kullanılan bir tahmin olduğunu düşünmüyorum Ayrıca bazı diğer multimodal modellerin yaptığı gibi görüntü ve metin verisini birleştirmek için katmanların zincirlendiğini de düşünmüyorum GPT-4o’nun, CLIP ile YOLO karışımı bir CNN mimarisi kullanarak görüntüleri doğrudan transformer’ın anlamsal vektör uzayına gömerek 512x512 görüntüyü kelimenin tam anlamıyla 170 embedding vektörü olarak temsil ettiğini düşünüyorum Bu makaleye başlarken, 170 token’ın 13x13 grid ve ek bir “gestalt izlenimi” token’ı için olduğunu tamamen çözdüğümden emindim Ancak Zener görevindeki performans 5x5 sonrasında bozulmaya başlayınca bu teori çöktü. İçeride ne yapıyorsa, 13x13’ten çok daha küçük görünüyor Yine de YOLO benzetmesi ikna edici ve 5x5 Zener görevindeki performans, bir tür grid kullandığını neredeyse doğruluyor Bu teorinin başka alanlarda da güçlü bir öngörü gücü var GPT-4o’nun birden fazla görüntüyü işleyip iki görüntüyü karşılaştırma gibi görevleri nasıl yapabildiğini açıklıyor Aynı görüntü içinde birden fazla nesneyi görebilmesine rağmen, sahne çok fazla nesne içerdiğinde neden bunaldığını açıklıyor GPT-4o’nun sahnedeki tek tek nesnelerin mutlak ve göreli konumları konusunda neden çok belirsiz göründüğünü ve neden görüntüdeki nesneleri doğru biçimde sayamadığını açıklıyor (bir nesne bitişik iki grid hücresine yayılmışsa aynı sınıf her ikisinde de etkinleşir; dolayısıyla bunun tek nesne mi yoksa iki nesne mi olduğundan emin olamaz) İronik biçimde, bu teorinin temiz biçimde açıklayamadığı tek şey, başta bu makaleyi yazmama neden olan soru: neden özellikle 170 token? Piramit teorisi (1x1 + 2x2 + 3x3 + 4x4 + 5x5) aklıma gelen en iyi açıklamaydı, ancak özellikle temiz bir açıklama değil Biraz daha iyi uyan bir teoriye sahip olan birinden (ya da NDA’yı ihlal etmiyorsa gerçek bilgiye sahip birinden) görüş duymak isterim Son not: alfa kanalı hilesi Bu proje üzerinde çalışırken GPT-4o'nun alfa kanalını yok saydığı ve bu yüzden bir miktar sezgilere aykırı davrandığı görüldü Buradaki "yok saymak", bir görsel düzenleyicinin PNG'yi JPG'ye dönüştürürken varsayılan bir arka planla birleştirip saydamlığı kaldırması anlamına gelmiyor GPT-4o kelimenin tam anlamıyla yalnızca RGB kanallarını alıyor ve alfa kanalını yok sayıyor Bu durum dikkatle hazırlanmış 4 görselle açıklanabiliyor Kolaylık için görüntüler HTML ve CSS kullanılarak dama deseninin üzerinde gösterildi ve görsellerin kendisi düz, saydam bir arka plana sahip Ancak yarısında saydam siyah arka plan, diğer yarısında ise saydam beyaz arka plan bulunuyor "Saydam siyah" veya "saydam beyaz" ne demek? RGBA renkleri 4 baytla ifade edildiğinde, alfa %100 olsa bile RGB baytları yine de mevcut olur Bu nedenle (0, 0, 0, 255) ile (255, 255, 255, 255) bir bakıma farklı renklerdir, ancak ikisi de %100 saydam olduğundan düzgün çalışan bir renderer'ın bunları farklı göstermesi gereken bir durum yoktur GPT-4o'ya bu 4 görselde ne "gördüğünü" sorarsanız: Saydam siyah arka plan üzerinde siyah metin: GPT-4o bunu "" olarak okuyor Saydam beyaz arka plan üzerinde siyah metin: GPT-4o bunu "ENORMOUS" olarak okuyor Saydam siyah arka plan üzerinde beyaz metin: GPT-4o bunu "SCINTILLA" olarak okuyor Saydam beyaz arka plan üzerinde beyaz metin: GPT-4o bunu "" olarak okuyor Burada neler oluyor? Ortaya çıkan desen, GPT-4o'nun yalnızca metin rengi saydam arka planın "renginden" farklı olduğunda metni okuyabildiğini gösteriyor Bu da GPT-4o'nun alfa kanalını yok sayıp yalnızca RGB kanallarına baktığını gösteriyor. GPT-4o için saydam siyah siyahtır, saydam beyaz da beyazdır Görüntüyü, 3 RGB kanalını koruyup alfa kanalını %100 yapacak şekilde değiştirirseniz bunu daha net görebilirsiniz Bunu yapmak için bir Pillow fonksiyonu kullanıldı Bununla aşağıdaki iki görsel oluşturuldu; RGB verileri aynı, yalnızca alfa kanalı farklı Alfa kanalı = 255: GPT-4o gizli ornitorenki kolayca görebiliyor Alfa kanalı = 0: GPT-4o bunu tamamen saydam bir görsel olarak görüyor hidden_platypus.png görselini indirip doğrudan ChatGPT'ye ekleyebilirsiniz; doğru şekilde açıklayacaktır Görsel boyutunun 39.3KB ile platypus.png ile aynı olduğu görülebilir; eğer gerçekten tamamen boş ve saydam bir görsel olsaydı PNG sıkıştırması nedeniyle çok daha küçük olması gerekirdi Ya da yukarıdaki fonksiyon kullanılarak alfa kanalı tekrar 255'e ayarlanıp orijinal görsel geri yüklenebilir Bunun bir bug olup olmadığı kesin değil, ancak kesinlikle şaşırtıcı bir davranış ve kötü niyetli bir kullanıcının bilgiyi insanı atlayıp doğrudan GPT-4o'ya kaçırmak için bunu kullanabileceği hissini veriyor Ancak GPT-4o, görsellere gizlenmiş kötü niyetli prompt'ları tespit edip yok sayma konusunda GPT-4v'den çok daha iyi image_tagger yardımcı aracıyla oluşturulan GPT-4o test görsel galerisinde, GPT-4o'nun görsele gizlenmiş kötü niyetli prompt'ları başarıyla tespit edip yok saydığı başka örnekler bulunabilir Bu yüzden bug olsa bile gerçekten kötüye kullanılıp kullanılamayacağı net değil Yine de GPT-4o, tarayıcıda insanın gördüğü şeyle aynı şeyi "görseydi" bu daha az şaşırtıcı olurdu

(oranlooney.com)

18 puan yazan xguru 2024-06-10 | 2 yorum | WhatsApp'ta paylaş

GPT-4o, yüksek çözünürlük modunda kullanılan her 512x512 karo için 170 token ücretlendiriyor. Yaklaşık 0,75 token/kelime oranına bakıldığında bu, bir görselin yaklaşık 227 kelimeye eşit olduğu anlamına geliyor
- “Bir resim bin kelimeye bedeldir” sözüyle karşılaştırıldığında yaklaşık 4 kat fark var
170 sayısı tuhaf denecek kadar spesifik bir sayı. OpenAI fiyatlandırmada “20 dolar” veya “0,50 dolar” gibi yuvarlanmış sayılar ya da iç boyutlarda 2 ve 3’ün kuvvetlerini kullanıyor
Neden 170 gibi bir sayı seçilmiş olabilir? Programlamada, kod tabanına açıklama olmadan bırakılan sayılara “magic number” denir; 170 oldukça dikkat çekici bir magic number
Görsel maliyetini neden token sayısına dönüştürsünler? Amaç yalnızca faturalandırma olsaydı, karo başına maliyeti listelemek daha az kafa karıştırıcı olurdu
Ya OpenAI’nin 170’i seçmesinin nedeni bunun kelimenin tam anlamıyla doğru olmasıysa? Ya bir görsel karo gerçekten 170 ardışık embedding vektörüyle temsil ediliyorsa?

Embedding

Transformer modelleri hakkında önce hatırlanması gereken şey, ayrık token’lar üzerinde değil vektörler üzerinde çalıştıklarıdır
- Girdi vektör olmak zorundadır; aksi halde transformer’ın temelindeki iç çarpım benzerliği anlamsız olurdu
- Token kavramının tamamı bir ön işleme aşamasıdır: metin token’lara dönüştürülür ve token’lar, transformer modelinin ilk katmanına ulaşmadan önce bir embedding modeli tarafından embedding vektörlerine çevrilir
Örneğin Llama 3, dahili olarak 4.096 özellik boyutu kullanır
- “My very educated mother just served us nine pizzas.” cümlesine bakarsak
- Bu cümle BPE tarafından 10 tamsayı token’a (nokta dahil) dönüştürülür; ardından her biri embedding modeli tarafından 4.096 boyutlu vektöre çevrilir ve sonuç 10x4096’lık bir matris olur
- Transformer modeline verilen “gerçek” girdi budur
Ancak bu vektörlerin mutlaka bir metin embedding modelinden gelmesi gerektiğine dair bir kural yoktur
- Bu, metin verisi için iyi çalışan bir stratejidir; fakat transformer’a beslemek istediğiniz başka veri türleri varsa, farklı bir embedding stratejisi kullanabilirsiniz
OpenAI’nin 2021’de CLIP embedding modelini yayımlamış olması, bu yönde düşündüklerini gösteriyor
- CLIP, metni ve görselleri aynı anlamsal vektör uzayına gömer; böylece cosine similarity kullanarak bir metin dizisiyle ilişkili görselleri ya da başka görsellere anlamsal olarak benzeyen görselleri bulabilir
- Ancak CLIP tüm görseli tek bir vektör olarak gömer, 170 tane olarak değil. GPT-4o, görselleri (ve aynı şekilde video, ses ve diğer veri türlerini) temsil etmek için dahili olarak başka gelişmiş stratejiler kullanıyor olmalı. “Omnimodal” olmasının nedeni de bu
Özellikle görsel verisi için bu stratejinin ne olabileceğini çıkarım yoluyla anlamaya çalışalım

Özellik boyutu sayısı

GPT-4o’nun embedding vektörlerini temsil etmek için dahili olarak kullandığı boyut sayısını tahmin etmeye çalışırsak, bu bilgi kapalı kaynak olduğu için gerçek sayıyı bilemeyiz; ancak makul varsayımlar yapabiliriz
OpenAI’nin 2’nin kuvvetlerini sevdiği ve bazen buna tek bir 3 çarpanı eklediği görülüyor
- Örneğin ada-002 embedding için 1.536, text-embedding-3-large için ise 3.072 kullanıyor
- GPT-3’ün genel olarak 12.288 boyut kullandığı biliniyor
- GPT-4o bu parametreyi korumuş ya da artırmış olabilir
Embedding sayısının GPT-3’ten GPT-4o’ya düşmüş olması olası görünmüyor, ama imkânsız da değil
GPT-4 Turbo gibi sürümler önceki versiyonlara göre gerçekten daha hızlı ve daha ucuzdu; geliştiricilerin daha küçük boyutun kalite açısından eşdeğer derecede iyi olduğunu gösteren benchmark sonuçları varsa, embedding boyutunu küçültmek bunun bir parçası olmuş olabilir
GPT-4o içinde kullanılan özellik boyutu sayısının şu değerlerden biri olması muhtemel: 1536, 2048, 3072, 4096, 12228, 16384, 24576
GPT-4o’nun embedding vektörü boyutu için 12.228 kullandığını varsayacağım. 2 ya da 4 katı kadar sapma olsa bile bu çok önemli değil. Aynı argüman geçerli olur

Görsel embedding

Görsel karo kare olduğu için, büyük olasılıkla kare bir token ızgarasıyla temsil ediliyordur
- 170, 13x13’e çok yakındır
- Fazladan token, CLIP’e benzer şekilde tüm görselin gestalt izlenimini kodlayan tek bir embedding vektörü olabilir
Peki 512x512x3’ten 13x13x12228’e nasıl gidilebilir?

Strateji 1: Ham piksel

Görseli vektör uzayına koymanın çok basit bir yolu:
- 512x512 görseli 8x8’lik “mini karo” ızgarasına bölmek
- Her mini karo 64x64x3 olur ve 12.228 boyutlu bir vektöre açılır
- Her mini karo tek bir embedding vektörüdür
- Tüm görsel karo 64 ardışık embedding vektörüyle temsil edilir
Bu yaklaşımın iki sorunu var:
1. 64 ≠ 170
2. Çok saçma (ham RGB değerleriyle embedding yapıp gerisini transformer’ın çözmesini beklemek pek mantıklı değil)

Strateji 2: CNN

Neyse ki bu özelliklere sahip bir model zaten var ve 10 yılı aşkın süredir görsel veriyi başarıyla işliyor: convolutional neural network (CNN)
CNN’ler translation ve scale invariance gibi özelliklere sahiptir
AlexNet ve YOLO, tipik CNN mimarilerine örnek olarak verilebilir
CNN, ham pikselleri anlamsal vektörlere sıkıştıran bir huni gibidir
YOLO, görseli tek bir düzlemsel vektöre indirgemez; 13x13’te durur
- YOLOv3’ün çıktısı, her biri 1.024 boyutlu 169 farklı vektörden oluşan 13x13’lük bir ızgaradır
GPT-4o’nun varsayımsal görsel embedding CNN’inin, bu CNN mimarilerinin formuna benzemesi beklenir
512x512x3’ten 13x13x12228’e gitmek için standart CNN katmanlarının nasıl kullanılabileceğine dair bir öneri sunuluyor
- AlexNet’e benzer bir tasarım bunu zarif biçimde başarabilir (aynı tekrar eden 5 blok kullanarak)
- YOLO’ya daha çok benzeyen bir alternatif de var, ancak 13x13 yerine 12x12’ye ulaşıyor
Bunu kanıtlamak mümkün değil, fakat bu spekülatif tasarım, görselleri kxk embedding vektörü ızgarası olarak temsil edebilen makul bir CNN mimarisinin var olabileceğini gösteriyor

Deneysel doğrulama

GPT-4o gerçekten 13x13’lük bir embedding vektörü ızgarası görebiliyor olabilir mi?
Bunu test etmek için, Zener kartlarından ilham alan bir görev tasarlanmış: bir görsel ızgarasındaki tüm sembollerin renk ve şekillerini tanımlamak
Basit bir programla test amaçlı ızgara görselleri üretilmiş ve GPT-4o’dan her hücrenin şekil ve rengini JSON dizi formatında açıklaması istenmiş
Eğer 13x13 hipotezi doğruysa, GPT-4o’nun 13x13 boyutuna kadar iyi performans gösterip sonrasında düşüş yaşaması beklenirdi
Ancak gerçekte model, yalnızca 5x5 ve daha küçük ızgaralarda kusursuz performans gösteriyor; sonrasında performans keskin biçimde düşüyor
- 7x7 ızgarada %76 doğruluk gösterirken, 13x13 ızgarada şans seviyesinde performans sergiliyor
Bu da 169 token’ın 13x13’lük bir ızgarayı temsil ettiği hipotezinin yanlış olduğu anlamına geliyor
- Ancak 5x5 ızgara sonucu, GPT-4o’nun bir görsel içindeki 25 farklı nesneyi ve bunların mutlak konumlarını takip edebildiğini düşündürüyor
Temel fikir doğru olabilir ama boyut yanlış tahmin edilmiş olabilir; CNN’e daha fazla katman eklenerek 13x13 yerine 5x5’e düşürülebilir
Yalnızca 5x5 ve altındaki ızgaraların kullanıldığını varsayarsak, 170 token’a ulaşmak için çıktının nasıl yapılandırılmış olabileceği üzerine düşünmek gerekir

Piramit stratejisi

85 ve 170’e yakın sayılar elde etmenin bir yolu, görüntünün giderek daha ayrıntılı düzeylerde bir dizi piramit gibi kodlandığını varsaymaktır
- Tüm görüntünün gestalt izlenimini yakalamak için tek bir embedding vektörüyle başlayıp, sol/orta/sağ ve üst/orta/alt kısımları yakalamak için 3x3 eklenmesi, ardından 5x5, 7x7 vb. eklenmesi
Bu strateji 7x7’de durulursa “master thumbnail” için 85 tokene çok yaklaşır
- 12+32+52+72=1+9+25+49=84
Son 9x9 gridin eklenmesi 170’e çok yaklaşır
- 12+32+52+72+92=1+9+25+49+81=165
512x512 tile için geçici bir 2x2 grid kullanıp her biri için özel bir <|image start|> token varsayılırsa tam olarak eşleşme sağlanabilir
- 1+12+32+52+72=1+1+9+25+49=85
- 1+12+22+32+52+72+92=1+1+4+9+25+49+81=170
Bu şemada satırların başlangıcı ve sonu için herhangi bir ayraç yok, ancak bu durum, metin token’larının konum bilgisinin RoPE ile kodlanmasına benzer şekilde 2D konumsal kodlama ile ele alınabilir
Yukarıdakiler yalnızca tek sayılı grid boyutlarını aldığı ve 5x5’i atladığı için, Zener grid performansının 5x5 sonrasında düşmeye başladığına dair kanıtlarla tamamen örtüşmez
Alternatif olarak 5x5’e kadar tüm gridler (çift ve tek) alınabilir
- Bu yaklaşım 55 token verir: 12+22+32+42+52=55
Her mini tile başına 3 token ve her tile arasında 1 ayraç token varsayılırsa 170’e ulaşılabilir
- 3×(12+22+32+42+52)+5=170
Sayısal gerekçelendirme açısından tamamen tatmin edici değil, ancak ampirik sonuçlarla iyi örtüşüyor
Piramit stratejisi sezgisel olarak çok çekici ve farklı yakınlaştırma düzeylerinde uzamsal bilgiyi kodlamanın neredeyse “apaçık” bir yolu gibi hissettiriyor
- Bu, neden 5x5 grid ve altında iyi performans gösterip 6x6 ve üstünde çok kötüleştiğini açıklayabilir
Tüm hipotezler her şeyi açıklamaya büyüleyici derecede yakın görünüyor, ancak rakamlar hiçbir zaman tam olarak temiz biçimde yerine oturmuyor gibi; bu da can sıkıcı
- Yine de bu tür bir piramit stratejisi, aklıma gelen en iyi yöntem

Optik karakter tanıma (OCR)

Yukarıdaki hipotezlerin hiçbiri GPT-4o’nun OCR’ı nasıl yaptığını açıklamıyor
- CLIP özünde OCR’ı, en azından büyük metin blokları söz konusu olduğunda, çok iyi yapamaz
- (Buna rağmen GPT-4o’nun OCR yapabiliyor olması başlı başına oldukça şaşırtıcı ve ortaya çıkan yeteneklerin açık bir örneği)
GPT-4o açıkça yüksek kaliteli OCR yapabiliyor
- Uzun metin bloklarını yazıya dökebiliyor ve el yazısı metni ya da kaydırılmış, döndürülmüş, perspektifi değişmiş veya kısmen örtülü metni okuyabiliyor
Modern OCR motorları görüntüyü temizlemek, karakterlerin sınır kutularını ve bantlarını bulmak, ardından bu bantlar boyunca özel karakter tanıma modellerini bir seferde bir karakter veya kelime çalıştırmak için çok iş yapar
- Yalnızca büyük bir CNN kullanmazlar
Teorik olarak OpenAI gerçekten bu kadar iyi bir model inşa etmiş olabilir, ancak bu, Zener grid görevindeki görece zayıf performansla tutarlı değil
- Bir görüntüde temiz bir 6x6 grid içindeki 36 sembolü okuyamıyorsa, yüzlerce metin karakterini kusursuz şekilde okuyamamalı
Bu tutarsızlığı açıklamak için basit bir teori:
- OpenAI’ın Tesseract gibi hazır bir OCR aracı (veya özel, son teknoloji bir araç) çalıştırıp tanımlanan metni görüntü verisiyle birlikte transformer’a verdiğini düşünüyorum
- Bu, ilk sürümlerin neden görüntü içine gizlenmiş metinlerle kolayca karıştığını açıklayabilir (çünkü GPT-4o açısından o metin prompt’un bir parçasıydı)
  - Bu artık düzeltilmiş görünüyor ve GPT-4o, görüntü içine gizlenmiş kötü amaçlı prompt’ları görmezden gelmekte başarılı
Ancak bu, görüntüde bulunan metin için neden token başına ücret alınmadığını açıklamıyor
İlginç biçimde, metni görüntü olarak göndermek gerçekten daha verimli
- Küçük ama okunabilir yazı tipine sahip bir 512x512 görüntüye kolayca 400-500 metin token’ı sığabilir, ancak yalnızca “master thumbnail” için 85’e ek olarak 170 giriş token’ı ücretlendirilir; toplam 255 token eder (görüntüdeki kelime sayısından çok daha az)
Bu teori, görüntü işlenirken neden ek gecikme oluştuğunu açıklıyor
- CNN’ler özünde anlıktır, ancak üçüncü taraf OCR ek zaman gerektirir
- Ayrıca (bunun bir şeyi kanıtladığını söylemiyorum ama) OpenAI code interpreter’da kullanılan Python ortamında PyTesseract kurulu
  - Yüklediğiniz bir görüntü üzerinde PyTesseract çalıştırarak ikinci bir görüş almasını isteyebilirsiniz

Sonuç

Aslında tek bir sağlam olgudan, yani OpenAI’ın büyülü 170 sayısını kullanmış olmasından yola çıkarak epey tahminde bulundum
Ancak YOLO gibi diğer CNN mimarileriyle oldukça uyumlu, tamamen makul bir yaklaşım var gibi görünüyor: görüntü tile’larını embedding vektörlerine eşlemek
Bu yüzden 170 token’ın yalnızca görüntü işleme için gereken yaklaşık hesaplama miktarını faturalandırmak amacıyla kullanılan bir tahmin olduğunu düşünmüyorum
Ayrıca bazı diğer multimodal modellerin yaptığı gibi görüntü ve metin verisini birleştirmek için katmanların zincirlendiğini de düşünmüyorum
GPT-4o’nun, CLIP ile YOLO karışımı bir CNN mimarisi kullanarak görüntüleri doğrudan transformer’ın anlamsal vektör uzayına gömerek 512x512 görüntüyü kelimenin tam anlamıyla 170 embedding vektörü olarak temsil ettiğini düşünüyorum
Bu makaleye başlarken, 170 token’ın 13x13 grid ve ek bir “gestalt izlenimi” token’ı için olduğunu tamamen çözdüğümden emindim
- Ancak Zener görevindeki performans 5x5 sonrasında bozulmaya başlayınca bu teori çöktü. İçeride ne yapıyorsa, 13x13’ten çok daha küçük görünüyor
Yine de YOLO benzetmesi ikna edici ve 5x5 Zener görevindeki performans, bir tür grid kullandığını neredeyse doğruluyor
Bu teorinin başka alanlarda da güçlü bir öngörü gücü var
- GPT-4o’nun birden fazla görüntüyü işleyip iki görüntüyü karşılaştırma gibi görevleri nasıl yapabildiğini açıklıyor
- Aynı görüntü içinde birden fazla nesneyi görebilmesine rağmen, sahne çok fazla nesne içerdiğinde neden bunaldığını açıklıyor
- GPT-4o’nun sahnedeki tek tek nesnelerin mutlak ve göreli konumları konusunda neden çok belirsiz göründüğünü ve neden görüntüdeki nesneleri doğru biçimde sayamadığını açıklıyor (bir nesne bitişik iki grid hücresine yayılmışsa aynı sınıf her ikisinde de etkinleşir; dolayısıyla bunun tek nesne mi yoksa iki nesne mi olduğundan emin olamaz)
İronik biçimde, bu teorinin temiz biçimde açıklayamadığı tek şey, başta bu makaleyi yazmama neden olan soru: neden özellikle 170 token?
- Piramit teorisi (1x1 + 2x2 + 3x3 + 4x4 + 5x5) aklıma gelen en iyi açıklamaydı, ancak özellikle temiz bir açıklama değil
Biraz daha iyi uyan bir teoriye sahip olan birinden (ya da NDA’yı ihlal etmiyorsa gerçek bilgiye sahip birinden) görüş duymak isterim

Son not: alfa kanalı hilesi

Bu proje üzerinde çalışırken GPT-4o'nun alfa kanalını yok saydığı ve bu yüzden bir miktar sezgilere aykırı davrandığı görüldü
Buradaki "yok saymak", bir görsel düzenleyicinin PNG'yi JPG'ye dönüştürürken varsayılan bir arka planla birleştirip saydamlığı kaldırması anlamına gelmiyor
- GPT-4o kelimenin tam anlamıyla yalnızca RGB kanallarını alıyor ve alfa kanalını yok sayıyor
Bu durum dikkatle hazırlanmış 4 görselle açıklanabiliyor
- Kolaylık için görüntüler HTML ve CSS kullanılarak dama deseninin üzerinde gösterildi ve görsellerin kendisi düz, saydam bir arka plana sahip
- Ancak yarısında saydam siyah arka plan, diğer yarısında ise saydam beyaz arka plan bulunuyor
"Saydam siyah" veya "saydam beyaz" ne demek?
- RGBA renkleri 4 baytla ifade edildiğinde, alfa %100 olsa bile RGB baytları yine de mevcut olur
- Bu nedenle (0, 0, 0, 255) ile (255, 255, 255, 255) bir bakıma farklı renklerdir, ancak ikisi de %100 saydam olduğundan düzgün çalışan bir renderer'ın bunları farklı göstermesi gereken bir durum yoktur
GPT-4o'ya bu 4 görselde ne "gördüğünü" sorarsanız:
- Saydam siyah arka plan üzerinde siyah metin: GPT-4o bunu "" olarak okuyor
- Saydam beyaz arka plan üzerinde siyah metin: GPT-4o bunu "ENORMOUS" olarak okuyor
- Saydam siyah arka plan üzerinde beyaz metin: GPT-4o bunu "SCINTILLA" olarak okuyor
- Saydam beyaz arka plan üzerinde beyaz metin: GPT-4o bunu "" olarak okuyor
Burada neler oluyor?
- Ortaya çıkan desen, GPT-4o'nun yalnızca metin rengi saydam arka planın "renginden" farklı olduğunda metni okuyabildiğini gösteriyor
- Bu da GPT-4o'nun alfa kanalını yok sayıp yalnızca RGB kanallarına baktığını gösteriyor. GPT-4o için saydam siyah siyahtır, saydam beyaz da beyazdır
Görüntüyü, 3 RGB kanalını koruyup alfa kanalını %100 yapacak şekilde değiştirirseniz bunu daha net görebilirsiniz
- Bunu yapmak için bir Pillow fonksiyonu kullanıldı
- Bununla aşağıdaki iki görsel oluşturuldu; RGB verileri aynı, yalnızca alfa kanalı farklı
  - Alfa kanalı = 255: GPT-4o gizli ornitorenki kolayca görebiliyor
  - Alfa kanalı = 0: GPT-4o bunu tamamen saydam bir görsel olarak görüyor
hidden_platypus.png görselini indirip doğrudan ChatGPT'ye ekleyebilirsiniz; doğru şekilde açıklayacaktır
- Görsel boyutunun 39.3KB ile platypus.png ile aynı olduğu görülebilir; eğer gerçekten tamamen boş ve saydam bir görsel olsaydı PNG sıkıştırması nedeniyle çok daha küçük olması gerekirdi
- Ya da yukarıdaki fonksiyon kullanılarak alfa kanalı tekrar 255'e ayarlanıp orijinal görsel geri yüklenebilir
Bunun bir bug olup olmadığı kesin değil, ancak kesinlikle şaşırtıcı bir davranış ve kötü niyetli bir kullanıcının bilgiyi insanı atlayıp doğrudan GPT-4o'ya kaçırmak için bunu kullanabileceği hissini veriyor
Ancak GPT-4o, görsellere gizlenmiş kötü niyetli prompt'ları tespit edip yok sayma konusunda GPT-4v'den çok daha iyi
- image_tagger yardımcı aracıyla oluşturulan GPT-4o test görsel galerisinde, GPT-4o'nun görsele gizlenmiş kötü niyetli prompt'ları başarıyla tespit edip yok saydığı başka örnekler bulunabilir
Bu yüzden bug olsa bile gerçekten kötüye kullanılıp kullanılamayacağı net değil
Yine de GPT-4o, tarayıcıda insanın gördüğü şeyle aynı şeyi "görseydi" bu daha az şaşırtıcı olurdu

2 yorum

hi098123 2024-06-10

Dolayısıyla (0, 0, 0, 255) ile (255, 255, 255, 255) bir anlamda farklı renkler olsa da, ikisi de %100 şeffaf olduğu için doğru çalışan bir render edicinin bunları farklı göstermesi gereken bir durum yok.

Şeffaf olmaları için alpha değerinin 0 olduğu (0, 0, 0, 0) ve (255, 255, 255, 0) olması gerekir; anlaşılan metinde bir yazım hatası var.

xguru 2024-06-10

Hacker News görüşleri

Modern bir açık kaynak alternatife ihtiyaç: En yeni makine öğrenimi tekniklerine dayanan, Tesseract için modern bir açık kaynak alternatife acilen ihtiyaç var. Şu anda kullanılan LLM'ler gereğinden fazla güçlü ve pahalı.
Llava1.6, IntenVL ve CogVLM2'nin OCR yetenekleri: Bu modeller, döşenmiş görüntü embedding'leri ve yalnızca LLM ile OCR yapabiliyor. Tesseract'ın OCR çıktısını girdi olarak vermek güvenilirliği artırıyor, ancak zorunlu değil.
CLIP embedding'lerinde metin tanıma: CLIP embedding'leri, metin yeterince büyükse metni "okuyabiliyor". Tiling, küçük metinlerin okunabilmesini sağlıyor.
Merak ve açık uçlu keşif: Bu teknolojinin nasıl çalıştığına dair merakı ve açık uçlu keşfi seviyorum. Makine öğrenimi modeli yorumlama açısından yeniden normalleştirme grubu teorisiyle bağlantısı da ilgi çekici.
Metni görüntü olarak iletmenin verimliliği: Metni görüntü olarak iletmek daha verimli olabilir. Küçük yazı tipleriyle 512x512 bir görüntüye 400-500 token kolayca sığdırılabilir.
OpenAI'ın yetersiz dokümantasyonu: OpenAI'ın neden açık ve kapsamlı dokümantasyon sunmadığını anlamıyorum. API kullananlar için bu dokümantasyon eksikliği büyük bir engel.
GPT-4'ün görüntü işlemede yaptığı hatalar: GPT-4 vision'ın, PDF'nin birden fazla sayfasını temsil eden tek bir görüntü üzerinde OCR yaparken içeriği bozduğu durumlar yaşadım. OpenAI'ın açık bir dokümantasyonu olsaydı, bu tür sorunlardan daha etkili biçimde kaçınılabilirdi.
Yazının kalitesi: Bu yazının çok iyi yazıldığını düşünüyorum. Konuyu kolay anlaşılır kılarken aynı zamanda derinliğini de koruyor. Bir konuyu basitçe anlatabilmek için onu gerçekten iyi anlamak gerekir.
VQVAE kullanma olasılığı: Token sözlüğü oluşturmak ve görüntüleri encoder ile dönüştürmek için VQVAE kullanma ihtimali var.
Görüntü-token eşlemesinin maliyeti: Görüntüleri token ID'leri yerine token embedding'lerine eşlemenin, yaklaşık 170 kat daha fazla hesaplama ve alan tüketmesi mümkün.
13x13 tiling olasılığı: Örtüşen alımlama alanları nedeniyle 13x13'lük bir nesne ızgarasının algılanamadığını dışlamak mümkün değil. Örtüşen tiling çözünürlüklerinden oluşan bir piramit de mümkün olabilir.
GPT-4 performansını test etme yöntemi: 7x7'lik bir ızgaradaki renkli şekilleri JSON olarak isteyerek GPT-4 performansını test etme yöntemi oldukça dahiyane.