कम ट्रेनिंग डेटा और छोटे मॉडल के साथ बड़े language models से बेहतर प्रदर्शन करने की तकनीक

 (blog.research.google)
3 पॉइंट द्वारा GN⁺ 2023-09-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े LLM few-shot के ज़रिए नए tasks हल कर सकते हैं, लेकिन serving cost बहुत अधिक होती है; इसलिए Google Cloud AI टीम ने छोटे task-specific models को natural language rationale के साथ train करने वाली distilling step-by-step विधि प्रस्तावित की
  • इस तरीके में few-shot Chain-of-Thought(CoT) से LLM की intermediate reasoning निकाली जाती है, और इसे multitask learning में बदला जाता है जहाँ T5 model label prediction और rationale generation दोनों साथ सीखता है
  • प्रयोगों में 540B PaLM को base LLM और T5 को downstream model के रूप में इस्तेमाल कर e-SNLI, ANLI, CQA, SVAMP पर natural language inference, commonsense QA और arithmetic word problems का मूल्यांकन किया गया
  • e-SNLI में कुल डेटा के सिर्फ 12.5% से standard fine-tuning से बेहतर प्रदर्शन मिला, और ANLI में 770M T5 ने 80% डेटा के साथ 540B PaLM few-shot प्रदर्शन को पार कर model size को 700 गुना से अधिक घटा दिया
  • यह छोटा model deploy करने और training data संग्रह लागत के बीच trade-off को कम करने वाला तरीका है, और Vertex AI में private preview के रूप में उपलब्ध है

LLM deployment cost और छोटे मॉडल training की सीमाएँ

  • LLM zero-shot और few-shot prompting के ज़रिए पहले न देखे गए नए tasks संभाल सकते हैं, लेकिन वास्तविक सेवाओं में model size एक बड़ी बाधा बन जाती है
    • 175B स्तर के एक LLM को serve करने के लिए विशेष infrastructure पर कम-से-कम 350GB GPU memory चाहिए
    • उस समय के नवीनतम LLM का आकार 500B parameters से भी अधिक था
  • व्यवहार में अक्सर छोटे task-specific models deploy किए जाते हैं, और आम तौर पर दो तरीके इस्तेमाल होते हैं
    • fine-tuning: BERT या T5 जैसे pre-trained छोटे models को human-labeled downstream data से update किया जाता है
    • distillation: बड़े LLM द्वारा generate किए गए labels से छोटे model को train किया जाता है
  • दोनों तरीकों में लागत का बोझ बना रहता है
    • fine-tuning में human-created labels चाहिए, इसलिए लागत और काम दोनों अधिक होते हैं
    • distillation में बड़ी मात्रा में unlabeled data चाहिए, और यह data इकट्ठा करना भी कठिन हो सकता है

Distilling step-by-step का मुख्य विचार

  • Distilling Step-by-Step! Outperforming Larger Language Models with Less Training Data and Smaller Model Sizes model size और training data collection cost के बीच trade-off को कम करने का एक तरीका है
  • distilling step-by-step में LLM से natural language rationale, यानी intermediate reasoning steps, निकाले जाते हैं और उन्हें छोटे model training के लिए अतिरिक्त supervision signal की तरह इस्तेमाल किया जाता है
  • natural language rationale input question और output answer के बीच संबंध को स्पष्ट करता है
    • उदाहरण के लिए, अगर कमरे की लंबाई और चौड़ाई तथा पहले से मौजूद carpet area दिया हो, तो LLM “Area = length * width” जैसी intermediate rationale generate कर सकता है
    • ऐसी rationale में task knowledge शामिल हो सकती है, जिसे छोटा model सामान्यतः बहुत अधिक data से सीखता
  • सिर्फ labels सीखने के बजाय label और rationale को साथ सिखाया जाता है ताकि छोटा model कम data में task सीख सके

दो-चरणीय training प्रक्रिया

  • पहला चरण few-shot CoT prompting के ज़रिए LLM से rationale निकालने की प्रक्रिया है
    • हर task के लिए input, rationale और output के तीन घटकों वाले examples LLM prompt में डाले जाते हैं
    • LLM इन्हीं examples का अनुसरण करते हुए नए input के लिए rationale generate करता है
  • commonsense QA उदाहरण में “Sammy wanted to go to where the people are” सवाल और options दिए जाते हैं
    • सही उत्तर “(a) populated areas” है
    • rationale यह संबंध देती है कि उसे ऐसी जगह जाना था जहाँ बहुत लोग हों, और options में populated areas ही ऐसी जगह है
  • दूसरे चरण में निकाली गई rationale को छोटे model training में शामिल किया जाता है
    • standard label prediction task के अलावा एक नया rationale generation task भी सिखाया जाता है
    • model input के आगे [label] या [rationale] जैसे task prefixes जोड़कर दोनों tasks अलग किए जाते हैं
    • rationale generation task model को intermediate reasoning steps बनाना सिखाता है, जिससे अंततः label prediction बेहतर होती है

प्रयोग सेटअप और तुलना के आधार

  • base LLM 540B PaLM है
  • task-specific downstream model के रूप में T5 models का उपयोग किया गया
  • CoT prompting में जहाँ संभव था वहाँ मौजूदा CoT prompts का उपयोग किया गया, और नए datasets के लिए examples सीधे बनाए गए
  • मूल्यांकन 3 NLP tasks के 4 benchmarks पर किया गया
    • e-SNLI, ANLI: natural language inference
    • CQA: commonsense QA
    • SVAMP: arithmetic word problems
  • तुलना के मानक दो दिशाओं में थे
    • few-shot prompted LLM से तुलना के लिए 540B PaLM की few-shot CoT prompting का उपयोग किया गया
    • standard fine-tuning और standard distillation भी तुलना में शामिल थे, लेकिन ब्लॉग मुख्य रूप से standard fine-tuning तुलना पर केंद्रित है

कम training data से standard fine-tuning को पार करना

  • distilling step-by-step standard fine-tuning की तुलना में बहुत कम training data पर बेहतर प्रदर्शन देती है
  • e-SNLI में पूरे dataset के सिर्फ 12.5% का उपयोग करके पूरे dataset पर train की गई standard fine-tuning से बेहतर प्रदर्शन हासिल किया गया
  • दूसरे datasets में भी आवश्यक data size कम हुआ
    • ANLI: dataset size में 75% की कमी
    • CQA: dataset size में 25% की कमी
    • SVAMP: dataset size में 20% की कमी
  • यह तुलना human-labeled datasets के विभिन्न sizes पर 220M T5 model के साथ की गई

छोटे deployment model से PaLM baseline को पार करना

  • distilling step-by-step few-shot CoT prompt वाले LLM की तुलना में बहुत छोटे model से बेहतर प्रदर्शन देती है
  • e-SNLI में 220M T5 model ने 540B PaLM से बेहतर प्रदर्शन किया
  • ANLI में 770M T5 model ने 540B PaLM से बेहतर प्रदर्शन किया
    • यह model PaLM से 700 गुना से अधिक छोटा है
    • यही 770M T5 model केवल standard fine-tuning से PaLM स्तर तक पहुँचने में कठिनाई दिखाता है
  • यह नतीजा छोटे model size और LLM baseline से अधिक प्रदर्शन, दोनों को एक साथ दिखाता है

डेटा और model size दोनों को साथ घटाने का परिणाम

  • ANLI में distilling step-by-step ने सिर्फ 770M T5 और पूरे data के 80% के साथ 540B PaLM के few-shot प्रदर्शन को पार किया
  • वहीँ standard fine-tuning समान परिस्थिति में पूरे 100% data के बाद भी PaLM प्रदर्शन तक नहीं पहुँच सकी
  • एक coarse search के ज़रिए यह जाँचा गया कि LLM की few-shot CoT performance को पार करने के लिए न्यूनतम T5 model size और न्यूनतम human-labeled examples कितने चाहिए
  • नतीजतन, यह तरीका LLM performance को पार करने के लिए आवश्यक deployment model size और training data amount दोनों को कम करता है

उपलब्धता

  • distilling step-by-step Vertex AI पर private preview के रूप में उपलब्ध है
  • उपयोग में रुचि होने पर Google Cloud Project number और use case summary के साथ vertex-llm-tuning-preview@google.com पर संपर्क करने के लिए कहा गया है

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

1 टिप्पणियां

 
GN⁺ 2023-09-24
Hacker News टिप्पणियाँ

  • लगता है छोटे expert models ज़्यादातर applications पर हावी होंगे। size और usability के बीच एक sweet spot और बारीक संतुलन होता है, और लेख में दिखाए गए जैसे कई mechanisms शायद उस sweet spot को खोजकर हासिल कर पाएँगे

    • बड़े general-purpose models को कई छोटे expert models और एक routing model से बनाया जा सकता है, जो तय करे कि किस domain-specific model से पूछा जाए

  • distillation model में T5 का इस्तेमाल दिलचस्प है। मुझे लगा था encoder-decoder architecture खत्म होने की दिशा में है, लेकिन लगता है यह अब भी relevant है
    यह भी दिलचस्प है कि यह idea कोई अकल्पनीय रूप से जीनियस या बहुत out-of-the-box चीज़ नहीं है। इससे दिखता है कि explore करने के लिए अभी भी बहुत सारे low-hanging fruit बचे हैं, और large language models का भविष्य भी तय नहीं है। असली समाधान शायद इस तरह trained experts का mixture हो सकता है। सही ideas का combination मिल जाए तो holy grail जैसे लक्ष्य हासिल किए जा सकते हैं—यह सोचकर excitement होती है

    • T5 family शानदार है। FastChat-T5 की text generation quality हैरान करने वाली है, उदाहरण के लिए retrieval-augmented generation chatbots के लिए भी अच्छी है, और CPU पर भी इतनी तेज़ चलाई जा सकती है कि real-time conversation हो सके
    • जिस paper का ज़िक्र है वह मई में submit हुआ था। encoder-decoder architecture multimodal models में अब भी काफी valid लगता है
      अभी भी बहुत सारे low-hanging fruit बचे हैं। मैंने chain of thought, tree of thought, graph of thought, self-ask, self-critique, self-plan, self-reflect जैसी दर्जनों variants देखी हैं
    • जानना चाहूँगा कि आपको क्यों लगा कि encoder-decoder architecture खत्म होने की दिशा में है

  • large language models/machine learning/artificial intelligence field में activity और progress सचमुच जबरदस्त है। खासकर जब Nvidia जैसा hardware बहुत महंगा है, तो ऐसी optimization खास तौर पर valuable है

  • यह तो https://arxiv.org/abs/2212.08410 जैसा ही है, बस 1 साल बाद आया है, है न

    • improvements impressive हैं, लेकिन GSM8K 22% final result के तौर पर बहुत ध्यान खींचने वाला नहीं है

  • मैं researcher नहीं हूँ, लेकिन हमेशा से मेरी intuition रही है कि सबसे effective model multimodal होगा और carefully designed core curriculum पर trained होगा
    मैं यह सुनिश्चित करना चाहूँगा कि system effective और accurate generalization के लिए ज़रूरी basic structures और skills सीखकर बनाए रखे। फिर उन चीज़ों को maintain रखते हुए इसे बहुत सारा diverse data खिलाया जाए ताकि यह exceptions और skills को combine करने के तरीके सीख सके। हालांकि core skills और knowledge को अंत तक guarantee करने का कोई तरीका चाहिए। paper में जैसे final answer के साथ-साथ उसकी understanding या manipulation process भी output करवाया जाए, तो शायद यह संभव हो
    उदाहरण के लिए code generation model में requested program की state machine simulation output करने की requirement रखी जा सकती है

    • मैं सहमत हूँ कि multimodal ही आगे का रास्ता है, लेकिन curriculum को ज़रूरी तौर पर carefully design करना होगा, ऐसा मानने की कोई सहज वजह नहीं दिखती। https://gwern.net/scaling-hypothesis से तुलना की जा सकती है
    • school curriculum के idea के बारे में सोचें तो, क्या training data का order फर्क डालता है, यह जानने लायक है। simple से complex खिलाने पर और उल्टा करने पर फर्क पड़ सकता है। gradient descent निश्चित रूप से बेहतर या बदतर अलग-अलग local minima तक पहुँच सकता है, नहीं क्या

  • पहले figure में large language model की training data quantity distillation model और task-specific model से कम क्यों है, यह समझ नहीं आ रहा
    या authors ने large language model के लिए जरूरी training data quantity को distillation/task-specific model के लिए जरूरी training data में शामिल करके count किया है?
    https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj...

    • सही। वे उस data quantity को count कर रहे हैं जो problem solve करने के लिए आपको खुद collect करनी होगी
      आप pre-trained large language model ला सकते हैं, और उस case में मुझे जो data collect करना है वह उस model को fine-tune करने के लिए जरूरी data है

  • क्या उन विशाल large language models में बहुत सारी unused capacity बची हुई है, या छोटा language model reasoning task की सिर्फ नकल कर रहा है? यानी imitation की imitation?

    • real और imitation के बीच कोई मूलभूत distinction नहीं है
      जिन datasets पर विशाल large language models train होते हैं, उनमें बहुत noise होता है जो progress रोकता है। उनमें बहुत सा irrelevant knowledge भी होता है, जिसे model को सीखना या memorize करना पड़ता है, इसलिए absurdly many parameters चाहिए होते हैं
      अगर आप language model को human knowledge का sum total सिखाने की कोशिश नहीं कर रहे हैं और high-quality curated dataset देते हैं, तो scale barrier बहुत कम हो जाता है
      https://arxiv.org/abs/2305.07759
    • वह सवाल लगभग “क्या आज के विशाल large language models near-optimal हैं” जैसा ही लगता है, और साफ लगता है कि नहीं हैं
      optimal size estimate करने के तरीके पर किस तरह के ideas हो सकते हैं, यह जानने की उत्सुकता है
    • बड़े models generalize बेहतर करते हैं। छोटे models को specific tasks के लिए train करना ज्यादा आसान है

  • दिलचस्प। छोटे model को latest large language models जैसी performance देने के लिए क्या RLHF अनिवार्य होगा? output structure, tone, domain understanding से जुड़े issues instruction tuning से solve हो सकते हैं, लेकिन यह छोटे model की reasoning ability improve करने के लिए भी काफी होगा या नहीं, पता नहीं

  • कहा जाता है कि 175 billion parameters वाले एक large language model को serve करने के लिए special infrastructure पर कम से कम 350GB GPU memory चाहिए
    Apple ऐसा Mac Studio बेचता है जो available GPU memory को 144GB तक support करता है
    अगर वह 300GB से ज्यादा memory वाला Mac Pro निकाले और large language model serving market पर कब्जा कर ले, तो काफी मजेदार होगा

    • क्या Metal पर large language models को batch process कर सकने वाला कोई framework है? GGML या MLC में अभी ऐसा नहीं लगता
      अगर नहीं, तो यह अभी large language model hosting के लिए unsuitable होने की एक और वजह भर है
      वैसे असली game changer Intel हो सकता है। theoretical तौर पर वह 2x48GB Arc cards के साथ आकर, AMD/Nvidia जिस market में professional card customers की वजह से नहीं उतरते, उसे lower price पर target कर सकता है
    • उम्मीद है Apple का hardware advantage M3 generation में सही तरह से खुलकर आएगा। A17 Pro में ray tracing support आने से उम्मीद बंधती है कि वे existing leaders को तेजी से catch up कर सकते हैं
      सच कहूँ तो यही latest Apple hardware से दूर रहने की मेरी एकमात्र वजह है। मैं ज्यादातर desk पर computer use करता हूँ, और PC hardware, खासकर GPU, Apple के top products जो कर सकते हैं उससे बहुत आगे है। Linux मेरे work के लिए बहुत अच्छी तरह fit बैठता है, और काम खत्म होने पर games भी खेल सकता हूँ—ऐसे में लगभग 4,000 dollars खर्च करना justify करना मुश्किल है
    • देखना है कि large language model users को पकड़ने के लिए hardware products की RAM capacity को dramatically बढ़ाने वाला पहला कौन होगा। यह market share हासिल करने का रास्ता लगता है
    • वह number quantization के बिना है। 175 billion parameters को 4-bit में quantize करें तो लगभग 120GB VRAM में आ जाएगा। 34 billion parameter model 4-bit quantization के साथ एक RTX3090 24GB VRAM में भी fit हो जाता है

  • सोचता हूँ क्या Facebook सभी users की पूरी chat history से large language model train कर पाएगा