- GPT-4o high-resolution मोड में इस्तेमाल होने वाले हर 512x512 tile को प्रोसेस करने के लिए 170 tokens चार्ज करता है। लगभग 0.75 token/word के अनुपात से देखें तो इसका मतलब है कि एक तस्वीर लगभग 227 शब्दों के बराबर है
- “एक तस्वीर हज़ार शब्दों के बराबर होती है” वाली कहावत से तुलना करें तो यह लगभग 4 गुना का अंतर है
- 170 एक अजीब तरह से बहुत विशिष्ट संख्या है। OpenAI pricing में “20 डॉलर” या “0.50 डॉलर” जैसी rounded संख्याएँ, या internal dimensions में 2 और 3 की powers इस्तेमाल करता है
- 170 जैसी संख्या चुनने की वजह क्या हो सकती है? Programming में ऐसे नंबर जिन्हें codebase में बिना किसी explanation के डाल दिया जाए, उन्हें “magic number” कहा जाता है, और 170 काफ़ी नज़र आने वाला magic number है
- image cost को token count में बदलने की ज़रूरत क्यों है? अगर मकसद सिर्फ billing है, तो tile per cost की सूची देना कम confusing होता
- क्या होगा अगर OpenAI ने 170 इसलिए चुना क्योंकि वह सचमुच literal रूप से सही है? क्या होगा अगर image tile वास्तव में 170 लगातार embedding vectors के रूप में represent होता हो?
Embedding
- transformer models के बारे में सबसे पहले याद रखने वाली बात यह है कि वे discrete tokens पर नहीं बल्कि vectors पर काम करते हैं
- input vectors होना चाहिए, नहीं तो transformer के core में मौजूद dot-product similarity का कोई मतलब नहीं रहेगा
- tokens की पूरी अवधारणा preprocessing step है: text को tokens में बदला जाता है, और tokens को transformer model की पहली layer तक पहुँचने से पहले embedding model द्वारा embedding vectors में बदला जाता है
- उदाहरण के लिए, Llama 3 internal रूप से 4,096 feature dimensions इस्तेमाल करता है
- “My very educated mother just served us nine pizzas.” वाक्य को देखें
- इसे BPE द्वारा 10 integer tokens (period सहित) में बदला जाता है, फिर हर token को embedding model द्वारा 4,096-dimensional vector में बदला जाता है, जिससे 10x4096 matrix बनती है
- यही transformer model के लिए “असल” input है
- लेकिन ऐसा कोई नियम नहीं है कि ये vectors ज़रूर text embedding model से ही आएँ
- text data के लिए यह एक अच्छी strategy है, लेकिन अगर transformer में किसी और format का data feed करना ho, तो बस कोई दूसरी embedding strategy इस्तेमाल की जा सकती है
- हमें पता है कि OpenAI इस दिशा में सोचता रहा है, क्योंकि उसने 2021 में CLIP embedding model जारी किया था
- CLIP text और image को एक ही semantic vector space में embed करता है, ताकि cosine similarity का इस्तेमाल करके किसी text string से जुड़े images या दूसरे semantically similar images खोजे जा सकें
- लेकिन CLIP पूरे image को एक single vector में embed करता है, 170 में नहीं। GPT-4o को image (और इसी तरह video, audio तथा दूसरे data types) को represent करने के लिए internal रूप से कोई अलग उन्नत strategy इस्तेमाल करनी होगी। यही वजह है कि वह “omnimodal” है
- खास तौर पर image data के लिए वह strategy क्या हो सकती है, इसका अनुमान लगाने की कोशिश की जाती है
Feature dimensions की संख्या
- अगर यह अनुमान लगाएँ कि GPT-4o embedding vectors को represent करने के लिए internal रूप से कितनी dimensions इस्तेमाल करता है, तो proprietary होने की वजह से सही संख्या पता नहीं चल सकती, लेकिन कुछ reasonable assumptions की जा सकती हैं
- OpenAI को 2 की powers पसंद लगती हैं, और कभी-कभी उसमें 3 का एक factor भी मिलाया जाता है
- उदाहरण के लिए, ada-002 embeddings में 1,536 और text-embedding-3-large में 3,072 इस्तेमाल होते हैं
- GPT-3 के बारे में जाना जाता है कि वह कुल 12,288 dimensions इस्तेमाल करता है
- संभव है कि GPT-4o ने इस parameter को बनाए रखा हो या बढ़ाया हो
- यह कम संभावना लगती है कि GPT-3 से GPT-4o तक embeddings की संख्या घटी हो, हालांकि ऐसा संभव है
- GPT-4 Turbo जैसे releases वास्तव में पिछली versions से तेज़ और सस्ते थे, और अगर developers के पास ऐसे benchmark results थे जो दिखाते हों कि छोटा size quality के लिहाज़ से उतना ही अच्छा है, तो embedding dimensions घटाना उसका हिस्सा हो सकता था
- GPT-4o के अंदर इस्तेमाल होने वाली feature dimensions की संख्या संभवतः इनमें से एक होगी: 1536, 2048, 3072, 4096, 12228, 16384, 24576
- मान लेते हैं कि GPT-4o embedding vectors की dimension के लिए 12,228 इस्तेमाल करता है। अगर यह 2 या 4 के factor से अलग भी हो, तो उससे बहुत फ़र्क नहीं पड़ता। वही तर्क लागू होगा
Image embedding
- image tiles square होते हैं, इसलिए संभव है कि वे square token grid के रूप में represent किए जाते हों
- 170, 13x13 के बहुत क़रीब है
- अतिरिक्त token, CLIP की तरह, पूरे image की gestalt impression को encode करने वाला single embedding vector हो सकता है
- तब 512x512x3 से 13x13x12228 तक कैसे पहुँचा जा सकता है?
Strategy 1: Raw pixels
- image को vector space में डालने का एक बहुत सीधा तरीका:
- 512x512 image को 8x8 “mini tile” grid में बाँट दिया जाए
- हर mini tile 64x64x3 होगा, और उसे 12,228-dimensional vector में flatten किया जाएगा
- हर mini tile एक single embedding vector होगा
- पूरा image tile 64 लगातार embedding vectors से represent होगा
- इस approach में दो समस्याएँ हैं:
- 64 ≠ 170
- यह बहुत बेवकूफ़ाना है (raw RGB values को embed करके यह उम्मीद करना कि transformer बाकी सब समझ लेगा, तर्कसंगत नहीं है)
Strategy 2: CNN
- अच्छी बात यह है कि ऐसे गुणों वाला model पहले से मौजूद है, और 10 साल से ज़्यादा समय से image data को सफलतापूर्वक प्रोसेस करता आया है: convolutional neural network (CNN)
- CNN में translation और scale invariance जैसी विशेषताएँ होती हैं
- AlexNet और YOLO, CNN architectures के प्रतिनिधि उदाहरण हैं
- CNN, raw pixels को semantic vectors में compress करने वाली funnel की तरह काम करता है
- YOLO image को एक single flat vector तक reduce नहीं करता, बल्कि 13x13 पर रुक जाता है
- YOLOv3 का output 13x13 grid पर रखे गए 169 अलग vectors का होता है, जिनमें से हर एक 1,024-dimensional होता है
- उम्मीद की जा सकती है कि GPT-4o का hypothetical image-embedding CNN, ऐसी ही CNN architectures के रूप से मिलता-जुलता होगा
- 512x512x3 से 13x13x12228 तक जाने के लिए standard CNN layers इस्तेमाल करने का एक तरीका प्रस्तुत किया गया है
- AlexNet जैसी design इसे सुंदर तरीके से हासिल कर सकती है (5 समान repeated blocks का उपयोग करके)
- YOLO से ज़्यादा मिलती-जुलती एक alternative भी है, लेकिन वह 12x12 तक पहुँचती है (13x13 की जगह)
- इसे साबित नहीं किया जा सकता, लेकिन यह speculative design दिखाता है कि ऐसी plausible CNN architecture हो सकती है जो images को kxk embedding-vector grid के रूप में represent करे
Experimental verification
- क्या GPT-4o सचमुच 13x13 grid के embedding vectors “देख” सकता है?
- इसे test करने के लिए Zener cards से प्रेरित एक task बनाया गया: image के grid में मौजूद सभी symbols का रंग और shape पहचानना
- एक simple program से test grid images generate की गईं, और GPT-4o को prompt दिया गया कि वह JSON array format में हर cell की shape और color बताए
- अगर 13x13 hypothesis सही है, तो उम्मीद होगी कि GPT-4o 13x13 size तक अच्छा perform करेगा और उसके बाद performance गिरने लगेगी
- लेकिन वास्तव में उसने 5x5 grid तक या उससे नीचे perfect performance दिखाई, और उसके बाद performance तेज़ी से गिर गई
- 7x7 grid पर उसने 76% accuracy दिखाई, और 13x13 grid पर उसकी performance chance level के बराबर रही
- इसका मतलब है कि 169 tokens, 13x13 grid को represent करते हैं — यह hypothesis ग़लत है
- हालांकि, 5x5 grid के नतीजे यह संकेत देते हैं कि GPT-4o image के भीतर 25 अलग-अलग objects और उनकी absolute positions को track कर सकता है
- हो सकता है कि मूल अवधारणा सही हो लेकिन dimensions का अनुमान ग़लत हो, और CNN में ज़्यादा layers जोड़कर 13x13 की जगह 5x5 तक reduce किया जा सकता हो
- अगर मान लिया जाए कि केवल 5x5 grid या उससे छोटे आकार का उपयोग होता है, तो फिर यह सोचना होगा कि output को 170 tokens तक पहुँचाने के लिए किस तरह संरचित किया जा सकता है
पिरामिड रणनीति
- 85 और 170 के करीब संख्या पाने का एक तरीका यह मानना है कि इमेज को क्रमशः अधिक सूक्ष्म स्तरों की एक श्रृंखला, यानी पिरामिड की तरह, encode किया जाता है
- पूरी इमेज की gestalt impression को capture करने के लिए एक embedding vector से शुरू किया जाए, फिर बाएँ/मध्य/दाएँ और ऊपर/मध्य/नीचे को capture करने के लिए
3x3 जोड़ा जाए, फिर 5x5, 7x7 आदि
- अगर यह रणनीति
7x7 पर रुकती है, तो यह 'master thumbnail' के लिए 85 tokens के बहुत करीब पहुँचती है
- अंतिम
9x9 grid जोड़ने पर यह 170 के बहुत करीब पहुँचती है
- 12+32+52+72+92=1+9+25+49+81=165
512x512 tile के लिए एक अस्थायी 2x2 grid का उपयोग करके, और हर एक के लिए एक विशेष <|image start|> token मानकर, इसे पूरी तरह match किया जा सकता है
- 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
- इस scheme में rows की शुरुआत और अंत के लिए कोई separator नहीं है, लेकिन इसे 2D positional encoding से संभाला जा सकता है, ठीक वैसे ही जैसे text tokens की positional information encode करने के लिए RoPE का उपयोग होता है
- ऊपर की बात केवल odd grid sizes लेती है और
5x5 को छोड़ देती है, इसलिए यह उस प्रमाण से पूरी तरह मेल नहीं खाती कि 5x5 के बाद Zener grid performance गिरने लगती है
- एक विकल्प यह हो सकता है कि
5x5 तक सभी grids, यानी even और odd दोनों, लिए जाएँ
- यह approach 55 tokens देती है: 12+22+32+42+52=55
- अगर हर mini tile पर 3 tokens और हर tile के बीच 1 separator token माना जाए, तो 170 तक पहुँचा जा सकता है
- संख्यात्मक आधार पर यह पूरी तरह संतोषजनक नहीं है, लेकिन empirical results से अच्छी तरह मेल खाती है
- पिरामिड रणनीति सहज रूप से बहुत आकर्षक है, और अलग-अलग zoom levels पर spatial information encode करने का लगभग "स्पष्ट" तरीका लगती है
- यह समझा सकता है कि
5x5 grid या उससे नीचे यह अच्छा perform क्यों करती है, और 6x6 या उससे ऊपर बहुत खराब क्यों हो जाती है
- यह परेशान करने वाली बात है कि हर hypothesis सब कुछ समझाने के बेहद करीब लगती है, लेकिन संख्याएँ कभी साफ-सुथरे तरीके से fit नहीं बैठतीं
- फिर भी, ऐसी पिरामिड रणनीतियों में से यह सबसे अच्छा तरीका है जो मैं सोच पाया हूँ
ऑप्टिकल कैरेक्टर रिकग्निशन (OCR)
- ऊपर की कोई भी hypothesis यह नहीं समझाती कि GPT-4o OCR कैसे करता है
- CLIP मूलतः OCR बहुत अच्छी तरह नहीं कर सकता, कम से कम बड़े text blocks के मामले में तो नहीं
- (फिर भी, GPT-4o OCR कर सकता है, यह अपने आप में काफी चौंकाने वाली बात है, और emergent capability का एक स्पष्ट उदाहरण है)
- GPT-4o स्पष्ट रूप से high-quality OCR कर सकता है
- यह लंबे text blocks को transcribe कर सकता है, और handwritten text या moved, rotated, projected, या आंशिक रूप से ढके हुए text को भी पढ़ सकता है
- आधुनिक OCR engines इमेज को साफ करने, characters के bounding boxes और strips खोजने, और फिर उन strips के along एक बार में एक character या word पर विशेष character recognition models चलाने के लिए बहुत काम करते हैं
- वे सिर्फ एक बड़े CNN का उपयोग नहीं करते
- सिद्धांत रूप से, हो सकता है OpenAI ने वाकई उतना ही शानदार model बनाया हो, लेकिन यह Zener grid task में उसके अपेक्षाकृत कमजोर performance से मेल नहीं खाता
- अगर वह इमेज में एक साफ
6x6 grid के 36 symbols नहीं पढ़ सकता, तो वह सैकड़ों text characters को पूरी तरह नहीं पढ़ सकता होगा
- इस असंगति को समझाने के लिए एक सरल theory:
- मेरा मानना है कि OpenAI Tesseract जैसे off-the-shelf OCR tool (या कोई proprietary, state-of-the-art tool) चलाता है और पहचाने गए text को image data के साथ transformer में feed करता है
- यह समझा सकता है कि शुरुआती versions इमेज में छिपे text से आसानी से confuse क्यों हो जाते थे (क्योंकि GPT-4o के नज़रिए से वह text prompt का हिस्सा था)
- अब इसे ठीक कर दिया गया है, और GPT-4o इमेज के भीतर छिपे malicious prompts को ignore करने में काफ़ी कुशल है
- हालांकि, यह यह नहीं समझाता कि इमेज में मिले text के लिए per-token charge क्यों नहीं लिया जाता
- दिलचस्प बात यह है कि text को इमेज के रूप में भेजना वास्तव में अधिक efficient है
- छोटे लेकिन पढ़ने योग्य font वाली
512x512 इमेज में आसानी से 400-500 text tokens आ सकते हैं, लेकिन 'master thumbnail' के 85 के अलावा सिर्फ 170 input tokens का शुल्क लिया जाता है, यानी कुल 255 tokens (जो इमेज के शब्दों की संख्या से काफी कम है)
- यह theory यह भी समझाती है कि image processing में अतिरिक्त latency क्यों आती है
- CNN मूलतः लगभग तुरंत काम करता है, लेकिन third-party OCR में अतिरिक्त समय लगेगा
- वैसे (यह कहने का मतलब नहीं कि इससे कुछ साबित होता है), OpenAI code interpreter में इस्तेमाल होने वाले Python environment में PyTesseract installed है
- आप uploaded image पर PyTesseract चलाकर second opinion लेने को कह सकते हैं
निष्कर्ष
- मूल रूप से, मैंने एक ठोस तथ्य — कि OpenAI ने जादुई संख्या 170 का उपयोग किया — से काफी अनुमान लगाए हैं
- लेकिन ऐसा लगता है कि एक पूरी तरह plausible approach मौजूद है, जो YOLO जैसी दूसरी CNN architectures से अच्छी तरह मेल खाती है: image tiles से embedding vectors तक mapping करने का तरीका
- इसलिए मुझे नहीं लगता कि 170 tokens सिर्फ image processing के लिए आवश्यक अनुमानित compute की billing के लिए इस्तेमाल किया गया कोई approximation है
- और मुझे यह भी नहीं लगता कि यह कुछ अन्य multimodal models की तरह image और text data को जोड़ने के लिए layers को stitch करता है
- मेरा मानना है कि GPT-4o, CLIP और YOLO के मिश्रण जैसी CNN architecture का उपयोग करके, images को सीधे transformer के semantic vector space में embed करता है, और
512x512 इमेज को शाब्दिक रूप से 170 embedding vectors के रूप में represent करता है
- जब मैंने यह लेख शुरू किया था, तब मुझे पूरा विश्वास था कि 170 tokens का मतलब
13x13 grid और एक अतिरिक्त "gestalt impression" token है
- लेकिन Zener task में performance
5x5 के बाद गिरने लगी, और यह धारणा टूट गई। अंदरूनी तौर पर जो भी हो रहा है, वह 13x13 से काफी छोटा लगता है
- इसके बावजूद, YOLO से की गई तुलना काफ़ी persuasive है, और
5x5 Zener task पर performance लगभग पक्का करती है कि यह किसी न किसी तरह की grid processing कर रहा है
- इस theory की दूसरे क्षेत्रों में भी काफ़ी predictive power है
- यह समझाती है कि GPT-4o कई images को process करके दो images की तुलना जैसे tasks कैसे कर सकता है
- यह समझाती है कि यह एक ही इमेज में कई objects देख सकता है, लेकिन जब किसी complex scene में objects बहुत ज़्यादा हों तो overwhelmed क्यों हो जाता है
- यह भी समझाती है कि GPT-4o किसी scene में individual objects की absolute और relative positions को लेकर इतना अस्पष्ट क्यों दिखता है, और इमेज में objects की सटीक गिनती क्यों नहीं कर पाता (जब कोई object दो adjacent grid cells में फैला होता है, तो दोनों में वही class activate हो जाती है, इसलिए यह तय नहीं कर पाता कि वह एक object है या दो)
- विडंबना यह है कि यह theory जिस एकमात्र चीज़ को साफ़ तौर पर नहीं समझा पाती, वही वह सवाल है जिसने मुझे शुरू में यह लेख लिखने के लिए प्रेरित किया था: आखिर 170 tokens ही क्यों?
- पिरामिड theory (
1x1 + 2x2 + 3x3 + 4x4 + 5x5) मेरे हिसाब से सबसे अच्छा अनुमान था, लेकिन यह विशेष रूप से साफ-सुथरा नहीं है
- अगर किसी के पास इससे बेहतर मेल खाने वाली theory हो — या वास्तविक जानकारी हो, बशर्ते वह NDA का उल्लंघन न करती हो — तो मैं उसकी राय सुनना चाहूँगा
बाद की टिप्पणी: alpha channel की चाल
- इस प्रोजेक्ट पर काम करते हुए पता चला कि GPT-4o alpha channel को ignore करता है, इसलिए उसका व्यवहार थोड़ा अप्रत्याशित लगता है
- "ignore करता है" का मतलब यह नहीं है कि कोई image editor PNG को JPG में बदलते समय डिफ़ॉल्ट बैकग्राउंड पर composite करके transparency हटा देता है
- GPT-4o सचमुच केवल RGB channels लेता है और alpha channel को नज़रअंदाज़ करता है
- इसे सावधानी से तैयार की गई 4 images से समझाया जा सकता है
- सुविधा के लिए HTML और CSS का इस्तेमाल करके images को checkered pattern के ऊपर दिखाया गया, जबकि images खुद सपाट और transparent background वाली हैं
- लेकिन आधी images में transparent black background है, और बाकी आधी में transparent white background है
- "transparent black" या "transparent white" क्या होता है?
- जब RGBA color को 4 bytes में दर्शाया जाता है, तब alpha 100% होने पर भी RGB bytes मौजूद रहते हैं
- इसलिए
(0, 0, 0, 255) और (255, 255, 255, 255) एक अर्थ में अलग colors हैं, लेकिन दोनों 100% transparent हैं, इसलिए कोई सही renderer इन्हें अलग तरह से नहीं दिखाएगा
- जब GPT-4o से पूछा जाए कि इन 4 images में वह क्या "देखता" है:
- transparent black background पर black text: GPT-4o इसे "" के रूप में पढ़ता है
- transparent white background पर black text: GPT-4o इसे "ENORMOUS" के रूप में पढ़ता है
- transparent black background पर white text: GPT-4o इसे "SCINTILLA" के रूप में पढ़ता है
- transparent white background पर white text: GPT-4o इसे "" के रूप में पढ़ता है
- यहाँ क्या हो रहा है?
- एक पैटर्न दिखता है कि GPT-4o text को तभी पढ़ पाता है जब text का color transparent background के "color" से अलग हो
- इससे पता चलता है कि GPT-4o alpha channel को ignore करता है और केवल RGB channels देखता है। GPT-4o के लिए transparent black, black है और transparent white, white है
- RGB के 3 channels को सुरक्षित रखते हुए alpha channel को 100% पर सेट करके image में बदलाव करें, तो यह और स्पष्ट दिखता है
- इसके लिए Pillow function का इस्तेमाल किया गया
- इसका उपयोग करके नीचे की दो images बनाई गईं, जिनमें RGB data समान है और केवल alpha channel अलग है
- alpha channel = 255: GPT-4o छिपे हुए platypus को आसानी से देख सकता है
- alpha channel = 0: GPT-4o को यह पूरी तरह transparent image की तरह दिखता है
- आप
hidden_platypus.png image डाउनलोड करके उसे सीधे ChatGPT में डालकर देख सकते हैं, और यह उसे सही-सही बताएगा
- आप देखेंगे कि image का आकार 39.3KB है, जो
platypus.png जितना ही है; अगर यह वास्तव में पूरी तरह खाली और transparent image होती, तो PNG compression की वजह से यह बहुत छोटी होनी चाहिए थी
- या ऊपर वाले function का इस्तेमाल करके alpha channel को फिर से 255 पर सेट करके original image को बहाल किया जा सकता है
- यह bug है या नहीं, यह तय नहीं है, लेकिन यह निश्चित रूप से चौंकाने वाला व्यवहार है, और ऐसा लगता है कि कोई malicious user इसका इस्तेमाल इंसानों को बायपास करके सीधे GPT-4o तक जानकारी smuggle करने में कर सकता है
- लेकिन GPT-4o, GPT-4v की तुलना में image में छिपे malicious prompts को detect और ignore करने में काफी बेहतर है
image_tagger utility से बनाई गई GPT-4o test image gallery में आप ऐसे और उदाहरण देख सकते हैं जहाँ GPT-4o image में छिपे malicious prompts को सफलतापूर्वक detect और ignore करता है
- इसलिए, भले ही यह bug हो, यह स्पष्ट नहीं है कि इसका दुरुपयोग वास्तव में किया जा सकता है या नहीं
- फिर भी, अगर GPT-4o browser में इंसान जो देखता है ठीक वही "देखता", तो यह कम चौंकाने वाला होता
2 टिप्पणियां
इसलिए (0, 0, 0, 255) और (255, 255, 255, 255) एक मायने में अलग रंग हैं, लेकिन दोनों ही 100% पारदर्शी हैं, इसलिए ऐसी कोई स्थिति नहीं है जहाँ कोई सही renderer उन्हें अलग तरह से दिखाए।
पारदर्शी होने के लिए alpha 0 होना चाहिए, यानी (0, 0, 0, 0) और (255, 255, 255, 0), तो लगता है कि मुख्य लेख में टाइपो है।
Hacker News की राय