Tokenizer पर ध्यान देना चाहिए

 (cybernetist.com)
9 पॉइंट द्वारा GN⁺ 2024-10-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • e-commerce डेटा को संभालने वाले AI ऐप्स के विकास में मदद करते समय यह समस्या सामने आई कि Retrieval-augmented generation(RAG) कुछ queries पर अच्छी तरह काम कर रहा था, लेकिन कुछ अन्य queries पर नहीं
  • ऐसी समस्याओं को हल करते समय input data (indexed मूल text, retrieval में इस्तेमाल होने वाली user query) को देखना महत्वपूर्ण है
  • खास तौर पर chunking और tokenization के संदर्भ में optimization की ज़रूरत दिखी

[Tokenization]

  • tokenization वह प्रक्रिया है जिसमें text को tokenizer द्वारा छोटे हिस्सों, यानी tokens, में तोड़ा जाता है
  • इन tokens को token IDs से map किया जाता है, जो integer values होती हैं और tokenizer vocabulary के भीतर token की विशिष्ट पहचान करती हैं
  • tokenizer vocabulary उन सभी possible tokens का set है जिनका उपयोग tokenizer को train करने में किया जाता है
  • अगर text के tokens, LLM की tokenizer vocabulary में नहीं हैं, तो समस्या हो सकती है
  • अधिकांश LLMs के पास 30k~300k आकार की बड़ी vocabulary होती है
  • ज़्यादातर widely used LLMs subword tokenizers पर निर्भर करते हैं (BPE, Wordpiece आदि)
  • tokenizer के प्रकार
    • word: whitespace characters और punctuation आदि के आधार पर विभाजन
    • character: अलग-अलग characters (कभी-कभी punctuation सहित) में विभाजन
    • subword: tokens को ऐसे subwords में विभाजित करना जो अर्थहीन लग सकते हैं
    • अधिकांश LLMs subword tokenizers का उपयोग करते हैं
      • BPE(Byte-Pair Encoder): OpenAI की tiktoken library
      • Wordpiece: Cohere, MiniLM-L6-v2 आदि

MiniLM-L6-v2 और tiktoken की तुलना

  • MiniLM-L6-v2 model की tokenizer vocabulary size 30522 है, जो tiktoken(200019) से काफी छोटी है
  • "tokenizer tokenizes text into tokens" वाक्य को tokenize करने पर
    • MiniLM-L6-v2: [CLS] token ##izer token ##izes text into token ##s [SEP]
    • tiktoken: token, izer, token, izes, text, into, tokens
  • OpenAI की tiktoken library BPE tokenizer को implement करती है और ChatGPT LLM models में उपयोग होती है
  • MiniLM-L6-v2 vocabulary में German और Japanese characters भी शामिल हैं

Emoji, typos, और domain-specific शब्दों की tokenization

  • MiniLM-L6-v2 emoji को [UNK] token के रूप में tokenize करता है
  • tiktoken ने कुछ Unicode character tokens पर training ली है, लेकिन RAG में यह फिर भी समस्या बन सकता है
  • "Gucci Savoy Leathertrimmed Printed Coatedcanvas Suitcase" जैसे domain-specific product names भी ठीक से tokenize नहीं होते
  • typo वाले वाक्य ("I hve received wrong pckage") के मामले में
    • MiniLM-L6-v2: i, h, ##ve, received, wrong, pc, ##ka, ##ge
    • tiktoken: I, h, ve, received, wrong, p, ck, age

[Embeddings]

  • tokenizer अपने आप में बहुत उपयोगी नहीं होता. इसे मुख्य रूप से individual tokens की frequency के आधार पर जटिल numerical analysis करने के लिए विकसित किया गया था
  • text का contextual meaning बनाए रखने के लिए ऐसा तरीका चाहिए जो tokens के बीच संबंधों को capture कर सके
  • embeddings वे vectors हैं जो tokens का प्रतिनिधित्व करते हैं, और text के शब्दों के बीच अर्थ व संबंधों को अच्छी तरह पकड़ते हैं
  • embeddings transformer training का एक byproduct हैं, और tokenized text dump से वास्तव में सीखे जाते हैं
  • text generation का अनुरोध करते समय LLM को input के रूप में वास्तव में embeddings ही दिए जाते हैं
  • LLM दो मुख्य components से बना होता है: encoder और decoder
    • encoder और decoder दोनों embeddings को input के रूप में लेते हैं
    • encoder का output भी embeddings ही होता है, जो decoder के cross-attention head तक भेजा जाता है और decoder output के token generation (prediction) में महत्वपूर्ण भूमिका निभाता है
  • RAG pipeline में text को पहले tokenize किया जाता है, फिर embed किया जाता है, और उसके बाद transformer में input किया जाता है
    • token IDs tokenizer vocabulary में index की तरह काम करते हैं, और embedding matrix से embeddings लाने में भी इस्तेमाल होते हैं
    • लाए गए embeddings को tensor के रूप में assembled करके transformer input के रूप में दिया जाता है
  • encoder flow: text tokenization -> प्रत्येक token का embedding लाना -> embedding tensor assemble करना -> transformer input में डालना -> encoding -> encoder output को decoder cross-attention तक भेजना -> decoder output बनाना

Embedding उदाहरण

  • "You can break it 😞" और "You can not break it 😊" की भावनाएँ उलटी हैं, फिर भी MiniLM-L6-v2 में embedding distance बहुत करीब है
  • OpenAI बेहतर प्रदर्शन दिखाता है क्योंकि उसकी token vocabulary emoji को बेहतर संभालती है
  • typos के मामले में भी OpenAI बेहतर handle करता है
  • लेकिन OpenAI में भी अगर वाक्य के अंत में whitespace जोड़ दिया जाए, तो embeddings के बीच दूरी उम्मीद से ज़्यादा बढ़ जाती है
  • date formats को संभालते समय भी developers को कठिनाई होती है. relative time expressions ("कल ship किया गया") खास तौर पर बड़ी समस्या बन सकते हैं
  • currency notation (£40, $50, 40£, 50¢ आदि) के अंतर भी अजीब समस्याएँ पैदा कर सकते हैं
  • Gucci bag वाले case की तरह domain-specific data के लिए आम तौर पर fine-tuning से समाधान किया जाता है, लेकिन हमेशा data और evaluation metrics की जाँच ज़रूर करनी चाहिए

निष्कर्ष

  • यह लेख बेहतर ढंग से समझने में मदद करता है कि tokenizer, RAG ऐप्स को कैसे प्रभावित कर सकता है और tokenizer पर ध्यान देना क्यों ज़रूरी है
  • agent applications में garbage-in garbage-out हमेशा उम्मीद के मुताबिक परिणाम नहीं देगा
  • input text को थोड़ा-सा साफ़ करना भी बहुत मददगार हो सकता है
    • date formats को लगातार एक समान standardize करना
    • जहाँ तक संभव हो trailing whitespace हटाना (embedding पर इसके प्रभाव की पुष्टि हुई)
    • अलग-अलग currencies की prices जैसे अन्य numerical data पर भी यही लागू करना
  • उम्मीद है कि कभी ऐसा समय आए जब tokenizer के बारे में बिल्कुल सोचना न पड़े. और इसे पूरी तरह छोड़ा जा सके
  • तब typos, मनमाने whitespace characters, और word perplexity आधारित adversarial attacks जैसी चीज़ों से निपटने की ज़रूरत नहीं रहेगी. दुख की एक श्रेणी शायद रातोंरात गायब हो जाएगी
  • तब तक ज़िम्मेदारी से tokenization करें

GN⁺ की राय

  • यह लेख अच्छी तरह दिखाता है कि tokenizer और embeddings, RAG-आधारित AI ऐप्स के प्रदर्शन को कैसे प्रभावित कर सकते हैं. खासकर emoji, typos, और domain-specific terms को संभालते समय किन बातों पर ध्यान देना चाहिए, यह वास्तविक उदाहरणों के साथ समझाया गया है, इसलिए developers के लिए काफ़ी मददगार लगेगा
  • हालांकि, इस लेख में parichay kiye gaye MiniLM-L6-v2 और OpenAI के tiktoken दोनों ही English के लिए optimized models हैं, इसलिए Korean जैसी दूसरी भाषाओं को संभालते समय अतिरिक्त बातों पर विचार करना पड़ सकता है. Korean के मामले में morphological analyzer का उपयोग करके tokenization काफ़ी किया जाता है, इसलिए इसके फायदे, सीमाएँ और कमियों को भी देखना ज़रूरी लगता है
  • इसके अलावा यह लेख RAG pipeline में tokenizer और embeddings की भूमिका पर केंद्रित है, लेकिन वास्तविक production environments में data preprocessing, hyperparameter tuning, model compression जैसे विचार करने योग्य पहलू इससे कहीं अधिक होते हैं. इसलिए इस लेख की बातों को एक शुरुआती बिंदु की तरह लेना चाहिए, और वास्तविक development process में विभिन्न experiments और evaluations के जरिए सर्वोत्तम तरीका खोजना महत्वपूर्ण होगा
  • दूसरी ओर, GPT-4 जैसे large language models के आने से tokenizer के महत्व के कम होने की राय भी है. कारण यह है कि ये models token level के बजाय sentence या paragraph level पर काम करते हैं, इसलिए individual tokens की quality का performance पर प्रभाव तुलनात्मक रूप से कम हो सकता है. हालांकि इस पर अभी पर्याप्त research नहीं है, इसलिए पक्का निष्कर्ष निकालना कठिन है
  • अंत में, जैसा कि इस लेख में कहा गया है, केवल input data को पहले से साफ़ और standardize करने भर से भी model performance में बड़ा सुधार हो सकता है. वास्तविक services विकसित करते समय user input की विविधता और noise को ध्यान में रखते हुए मज़बूत data preprocessing pipeline बनाना बहुत महत्वपूर्ण होगा. साथ ही data labeling और annotation कार्यों में भी पर्याप्त resources लगाकर high-quality training data सुनिश्चित करना आवश्यक लगता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-24
Hacker News राय

  • tokenizer को LLM का "sexy" हिस्सा नहीं माना जाता, लेकिन कुछ लोग इसे एक अवसर के रूप में देखते हैं। xVal जैसे पेपर tokenization की specialization strategy पेश करते हैं। spelling और character-level काम एक और समस्या है जिसे tokenization innovation से फायदा मिल सकता है

    • LLM शब्दों में characters की संख्या गिनने या character omission करने में कमजोर हैं। उदाहरण के लिए, GPT-4o characters की instances गिनने के लिए एक छोटा Python प्रोग्राम लिखकर चलाता है। tokenization prompt के characters के बारे में ज्ञान को प्रभावी रूप से मिटा देता है और इस तरह के tasks के प्रदर्शन पर सीधा नकारात्मक असर डालता है

  • meaningful काम करने के लिए डेटा को समझना ज़रूरी है। बहुत से लोग automated data processing tools का इस्तेमाल मुख्य रूप से इसलिए करते हैं क्योंकि वे डेटा को सीधे देखना नहीं चाहते। वे चाहते हैं कि कंप्यूटर डेटा को देख सके और अतिरिक्त जानकारी इकट्ठा करने के अनुरोध कर सके

  • ब्लॉग पोस्ट में typos वाले हिस्से की खास तौर पर सराहना हुई। मैं एक प्रोजेक्ट में RAG-जैसी application में मदद कर रहा हूँ, और मुझे चिंता है कि user query में छोटे typos या formatting differences embedding distance calculation को कैसे प्रभावित करते हैं

    • मैं सोच रहा हूँ कि क्या training data में जानबूझकर typos/replacements/capitalization जोड़नी चाहिए ताकि यह सीखा जा सके कि "wrk" और "work" शायद synonyms हैं

  • Elasticsearch का उपयोग करके 1-2 वाक्य के input और paragraph-से-लंबे documents के बीच similarity को advanced text queries से संभालने वाले एक app पर काम करने का अनुभव रहा है। यह दिलचस्प था कि tokenization strategy कुछ queries को कितना प्रभावित कर सकती है

    • उदाहरण के लिए, "W-4" या "W4" जैसे मामलों में standard tokenization "-" या letter/number boundary पर split कर सकती है। इससे यह input index में पूरी तरह पहचान से बाहर हो सकता है

  • लगा कि लेख में हर समस्या के समाधान पर चर्चा कम थी। सुझाव है कि spelling check को tokenizing से पहले चलाया जाए, या misspelled words और संभावित corrected words को साथ-साथ tokenize किया जाए

    • brand name वाली समस्या का समाधान पता नहीं। यह समस्या कम प्रचलित भाषाओं या बहुत सारे compound words इस्तेमाल करने वाली भाषाओं में और गंभीर हो सकती है

  • कई developers पारंपरिक (deterministic) space में development करने के आदी हैं, लेकिन statistical space में समस्याओं के बारे में सोचने का तरीका नहीं बदल पाते। LLM apps आखिरकार statistical space ही हैं

    • एक developer के रूप में, मुझे यह समस्या users को समझाने में कठिनाई होती है

  • RAG लागू करने वाले ज़्यादातर लोग tokenization के बारे में नहीं, embedding के बारे में सोचते हैं

    • data corpus को chunks में बाँटा जाता है और हर chunk के लिए embedding निकाली जाती है। query बनाई जाती है और हर query के लिए embedding निकाली जाती है। query से distance के आधार पर corpus chunks की ranking की जाती है। return value तैयार की जाती है
    • यह लेख उन hidden, अपेक्षाकृत साधारण tasks के महत्व को रेखांकित करता है जो system performance पर बड़ा असर डाल सकते हैं

  • ब्लॉग पोस्ट के कुछ numbers को reproduce नहीं किया जा सका। उदाहरण के लिए, SentenceTransformer का उपयोग करने वाले code में दो sentences की cosine similarity की गणना का परिणाम उम्मीद से अलग है

  • कई RAG implementations में यह समस्या देखी गई कि target document को incoming query के लिए अच्छा search key मान लिया जाता है। हाल की एक project में search key को return value (chunked documents) से अलग करके और LM का उपयोग करके उपयुक्त key generate कर embedding करने से search relevance में काफी सुधार हुआ

  • कहा जाता है कि कई बड़े LLM vocabularies काफी बड़े हैं, लेकिन सिर्फ English में ही 10 लाख से अधिक शब्द हैं। 30k-300k tokens छोटे लगते हैं