Magika: AI संचालित तेज़ और कुशल फ़ाइल प्रकार पहचान
Google का Magika प्रोजेक्ट सामग्री से फ़ाइल प्रकारों की पहचान करने के लिए एक compact neural network का उपयोग करता है, जिसका लक्ष्य `file`/libmagic जैसे पारंपरिक signature-based tools से बेहतर प्रदर्शन करना है, खासकर अस्पष्ट या semi-structured text formats में। टिप्पणीकार messy real-world uploads और बड़े file corpora को संभालने के लिए नए विकल्पों का स्वागत करते हैं, लेकिन ध्यान दिलाते हैं कि Magika फिलहाल बहुत कम formats का समर्थन करता है, अक्सर दर्जनों गुना धीमा है, और कभी-कभी “unknown” कहने के बजाय unknown या adversarial binaries को आत्मविश्वास से गलत लेबल कर देता है। कई लोग इसे मौजूदा deterministic methods के drop-in replacement के बजाय एक आशाजनक research और niche tool या second-pass classifier मानते हैं, और सवाल उठाते हैं कि open training data या polyglot files जैसे edge cases की मज़बूत handling के बिना यह कितना उपयोगी हो सकता है।
दायरा और समर्थित प्रकार
- मॉडल वर्तमान में लगभग 116 सामग्री प्रकारों को पहचानता है, जिसका ध्यान “मुख्य” और सामान्य प्रारूपों पर है।
- कई टिप्पणीकार उन सामान्य लेकिन अनुपस्थित श्रेणियों की ओर इशारा करते हैं: रॉ कैमरा इमेज, CAD फ़ाइलें, MIDI/संगीत फ़ॉर्मेट, ट्रैकर (.mod), कई विरासत भाषाएँ (Pascal, COBOL, assembly, APL), DXF, आदि।
- इसे विशेष रूप से समान दिखने वाले टेक्स्ट-आधारित प्रारूपों (जैसे CSV बनाम सामान्य टेक्स्ट, markdown, भाषा-विशिष्ट कोड) में अंतर करने के लिए आशाजनक माना जा रहा है।
सटीकता, विफलता के तरीके, और प्रतिकूल चिंताएँ
- ब्लॉग अपने डेटासेट पर >99% सटीकता का दावा करता है, लेकिन कई टिप्पणीकार गलत वर्गीकरण की रिपोर्ट करते हैं: DXF को PowerShell/plain text, HTML को VBA/ASP/generic text, fonts को FLAC/ISO, ROMs को SWF, Gradle Kotlin को Scala, अज्ञात binaries को ZIP, आदि।
- मुख्य आलोचना: अज्ञात या असमर्थित प्रारूपों को अक्सर “unknown”/“data” कहने के बजाय आत्मविश्वास से किसी ज्ञात प्रकार में मैप कर दिया जाता है।
- यह व्यवहार प्रतिकूल या सुरक्षा-संवेदनशील संदर्भों (malware detection, AV, upload validation) में खतरनाक माना जाता है।
- कुछ छोटे पैमाने के परीक्षणों में कुल मिलाकर सटीकता
fileके समान या थोड़ी बेहतर दिखती है, लेकिन विफलता के तरीके बहुत अलग और कम अनुमानित हैं।
प्रदर्शन और संसाधन उपयोग
- लेखकों का कहना है कि एकल फ़ाइलों के लिए Magika,
fileकी तुलना में लगभग 10× धीमा है; बैच में लगभग 2× धीमा। - वास्तविक प्रणालियों पर स्वतंत्र बेंचमार्क 30–50× धीमे रनटाइम और बहुत अधिक CPU उपयोग देखते हैं, खासकर CLI और Node/WASM के माध्यम से, जहाँ मॉडल लोडिंग प्रमुख लागत बनती है।
- इस बात पर बहस है कि अतिरिक्त ऊर्जा और विलंब मायने रखते हैं या नहीं: कुछ इसे सर्वर वर्कफ़्लो में नगण्य मानते हैं; अन्य बैटरी और इंटरैक्टिव UX की चिंताओं को रेखांकित करते हैं।
मौजूदा टूल्स से तुलना
file/libmagic लगभग 1600 प्रकारों का समर्थन करता है, बहुत तेज़ है, और संदेह होने पर अक्सर “data” लौटाता है।- कुछ लोगों का तर्क है कि libmagic “अधिक सक्षम, अनुमानित, और ऊर्जा-कुशल” है, विशेषकर binaries और fonts पर।
- अन्य लोग semi-structured text, zip-आधारित Office formats, और बड़े पैमाने के, गंदे डेटासेट्स पर libmagic की सीमाएँ बताते हैं, जहाँ यह गलत वर्गीकरण करता है या बहुत सामान्य परिणाम देता है।
- Apache Tika, TrID, ExifTool, और GitHub’s Linguist को मौजूदा विकल्पों के रूप में उल्लेख किया गया है।
उपयोग के मामले और एकीकरण रणनीतियाँ
- Google के भीतर उपयोग: Gmail/Drive फ़ाइलों को antivirus scanning और policy enforcement के लिए रूट करना।
- बाहरी विचार: upload validation (जब उपयोगकर्ता extensions से झूठ बोलते हैं), code editors की language detection, file managers और thumbnails, data recovery (Photorec outputs), secret scanners, web crawls।
- कई लोग एक hybrid दृष्टिकोण सुझाते हैं: पहले
file/libmagic का उपयोग करें, फिर जब परिणाम “data” हों या confidence कम हो तो Magika पर fall back करें।
ओपननेस, विस्तारयोग्यता, और AI के प्रति संदेह
- कोड और ONNX मॉडल Apache के तहत जारी किए गए हैं, लेकिन training code और dataset नहीं; कुछ लोग इसे केवल आंशिक रूप से “open” मानते हैं।
- training pipeline और data के बिना, नए formats के लिए community extension स्पष्ट नहीं है।
- headers और specs के माध्यम से अक्सर deterministic तरीके से होने वाले कार्य में ML के उपयोग पर व्यापक संदेह है, और यह चिंता भी कि “AI” branding, धीमे और कम पारदर्शी classifier की तुलना में, क्षमता को ज़्यादा बढ़ा-चढ़ाकर पेश करती है।