मेरे फाइन-ट्यूनिंग मॉडल ने OpenAI GPT-4 को पीछे छोड़ा

 (mlops.systems)
1 पॉइंट द्वारा GN⁺ 2024-07-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ISAF प्रेस रिलीज़ से structured data extraction करने वाले 724 टेस्ट में, कई fine-tuned मॉडल ने GPT-4 परिवार से अधिक accuracy दी
  • तुलना में GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo और TinyLlama, Mistral, Llama3, Solar, GPT-3.5 आधारित fine-tuned मॉडल शामिल थे
  • OpenAI मॉडल हमेशा valid JSON देते थे और Mistral·Llama3 fine-tuning भी स्थिर थे, लेकिन TinyLlama में template के आधार पर missing values और JSON quality में बड़ा अंतर था
  • अंतिम aggregation में OpenPipe से fine-tune किया गया Mistral-7B पहले स्थान पर रहा, और Solar LLM व Llama3-7B बहुत कम अंतर से पीछे रहे
  • Fine-tuning privacy, control और cost सुधार की संभावना देती है, लेकिन कई environments में फैले models की inference, evaluation और reproducibility मैनेज करने की MLOps complexity भी बढ़ाती है

प्रयोग का लक्ष्य और dataset

  • लक्ष्य ISAF प्रेस रिलीज़ से event जानकारी निकालने के काम में fine-tuned LLM की accuracy का मूल्यांकन करना था
  • डेटा Hugging Face Hub के public repository में है, और evaluation उस test split पर किया गया जिसे मॉडल ने नहीं देखा था
    • टेस्ट डेटा 724 rows से बना है
    • fields में name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured आदि शामिल हैं
  • validation और processing आसान बनाने के लिए हर row को Pydantic object में बदला गया
  • model output से निम्न JSON structure अपेक्षित था
    • name
    • start_date
    • event_type
    • province
    • target_group
    • min_killed
    • min_captured
    • killq
    • captureq
    • killcaptureraid
    • airstrike
    • noshotsfired
    • min_leaders_killed
    • min_leaders_captured

OpenAI baseline मॉडल की evaluation पद्धति

  • baseline comparison के लिए GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo का उपयोग किया गया
  • GPT मॉडल fine-tuned मॉडल जैसा prompt सीधे इस्तेमाल नहीं कर सकते थे, इसलिए लंबा prompt चाहिए था
    • निकालने वाले fields की सूची स्पष्ट की गई
    • event type, province, target group के allowed values दिए गए
    • number annotation rules शामिल किए गए
    • example प्रेस रिलीज़ और अपेक्षित JSON output साथ में डाला गया
  • number annotation rules ने ये criteria इस्तेमाल किए
    • a couple को 2 माना गया
    • several को न्यूनतम 3 माना गया
    • a few, some, a group, a small group, multiple को न्यूनतम 3 माना गया
    • numerous, a handful को न्यूनतम 4 माना गया
    • a large number को न्यूनतम 5 माना गया
    • facilitator leader नहीं है
  • bulk prediction asynchronous तरीके से चलाया गया, और GPT-3.5 Turbo के rate limit के कारण retry logic जोड़ा गया
  • prediction results हर event के predictions field में model name के हिसाब से store किए गए

Fine-tuning मॉडल configuration

  • OpenAI baseline मॉडल predictions के बाद, पहले से fine-tune किए गए local models और one-click fine-tuning service आधारित models की predictions उसी dataset में जोड़ी गईं
  • शामिल fine-tuned models ये हैं
    • tinyllama-templatefree
    • tinyllama-sharegpt
    • mistral-lora-templatefree
    • finetuned-openai-gpt-3.5-turbo-1106
    • finetuned-mistral-7b-optimised-openpipe
    • ft-solar-1-mini-chat-240612-predibase
    • finetuned-llama3-7b-32k-openpipe
  • Mistral local fine-tuned model को local run करना कठिन था, इसलिए Modal के A100 environment में inference किया गया
    • बाद की evaluation में यह लगभग सभी items पर fail हुआ
    • chart में इसे mistral-lora-templatefree के रूप में दिखाया गया
  • OpenAI की one-click fine-tuning service से gpt-3.5-turbo-1106 model को fine-tune किया गया
  • OpenPipe से Mistral 7B, Mistral 8x7B, Llama3 model predictions generate किए गए
  • Predibase में Upstage के Solar LLM आधारित model का evaluation किया गया
    • Solar LLM को ऐसा model बताया गया है जिसे structured data extraction जैसे fine-tuning अक्सर इस्तेमाल होने वाले tasks में मजबूत होने के लिए train किया गया है
    • base model Hugging Face Hub का upstage/SOLAR-10.7B-v1.0 माना जा रहा है
  • Qwen2 का Predibase inference काम नहीं कर पाया, इसलिए उसे इस evaluation से बाहर रखा गया
  • final prediction dataset Hugging Face Hub के public dataset पर publish किया गया

JSON validity और missing values

  • पहला evaluation यह check करने के तरीके से किया गया कि हर model output valid JSON है या नहीं
  • OpenAI models ने हर बार valid JSON generate किया
  • Fine-tuned Mistral और Llama3 models ने भी stable तरीके से valid JSON दिया
  • TinyLlama में template selection के आधार पर results काफी अलग रहे
    • tinyllama-sharegpt में 38 missing values थीं
    • माना गया कि missing values न होतीं तो इसमें 724 predictions और valid JSON सभी पूरे होते
  • missing values का aggregation इस प्रकार है
    • gpt-4o: 0
    • gpt-4-turbo: 0
    • gpt-3.5-turbo: 0
    • tinyllama-templatefree: 0
    • tinyllama-sharegpt: 38
    • finetuned-openai-gpt-3.5-turbo-1106: 0
    • finetuned-llama3-7b-32k-openpipe: 0
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 0
    • ft-solar-1-mini-chat-240612-predibase: 0

Field-wise accuracy

  • accuracy evaluation कुल 13 attributes के आधार पर किया गया
    • start_date
    • province
    • target_group
    • event_type
    • min_killed
    • min_captured
    • killq
    • captureq
    • killcaptureraid
    • airstrike
    • noshotsfired
    • min_leaders_killed
    • min_leaders_captured
  • सभी charts में कुल tasks की संख्या 724 है

  • start_date

    • start_date accuracy में Solar और fine-tuned GPT-3.5 model ने सबसे अच्छा प्रदर्शन किया
    • scores इस प्रकार हैं
      • gpt-4o: 527
      • gpt-4-turbo: 522
      • gpt-3.5-turbo: 492
      • tinyllama-templatefree: 231
      • tinyllama-sharegpt: 479
      • finetuned-openai-gpt-3.5-turbo-1106: 646
      • finetuned-llama3-7b-32k-openpipe: 585
      • mistral-lora-templatefree: 0
      • finetuned-mistral-7b-optimised-openpipe: 636
      • ft-solar-1-mini-chat-240612-predibase: 649
    • best model ने भी 75 dates गलत निकालीं, इसलिए date extraction में अभी भी सुधार की गुंजाइश है

  • province

    • province prediction में fine-tuned models OpenAI models से आगे रहे
    • scores इस प्रकार हैं
      • gpt-4o: 649
      • gpt-4-turbo: 645
      • gpt-3.5-turbo: 595
      • tinyllama-templatefree: 335
      • tinyllama-sharegpt: 660
      • finetuned-openai-gpt-3.5-turbo-1106: 704
      • finetuned-llama3-7b-32k-openpipe: 707
      • mistral-lora-templatefree: 0
      • finetuned-mistral-7b-optimised-openpipe: 711
      • ft-solar-1-mini-chat-240612-predibase: 704

  • target_group और event_type

    • target_group में कई groups हो सकते हैं, इसलिए score की गणना इस आधार पर की गई कि सही groups में से model ने कितना match किया
    • fine-tuned models ने target group identification में OpenAI models से काफी बेहतर प्रदर्शन दिखाया
    • हालांकि training data में न मौजूद नया group जुड़ने पर performance घट सकती है
    • event_type में semantically overlapping categories हैं, इसलिए इसे human annotators के लिए भी कठिन item माना जाता है
    • इस कठिन item में भी fine-tuned models ने अच्छा प्रदर्शन किया

  • Numbers और boolean fields

    • min_killed जैसे number estimation में fine-tuned models और OpenAI models के बीच gap कम हो गया
    • Mistral सबसे ऊपर रहा, लेकिन अंतर बड़ा नहीं था, और OpenAI models ने भी इस item में अच्छा प्रदर्शन किया
    • लंबे prompt में शामिल number annotation rules ने मदद की हो सकती है
    • killq जैसे boolean attributes में अधिकांश models ने high accuracy दर्ज की
    • fine-tuned Mistral ने इस item में भी GPT-4o के top score को पीछे छोड़ दिया
    • killcaptureraid OpenAI models के लिए disadvantage वाला item दिखा
      • kill-capture raid labeling में खास तरीके से इस्तेमाल हुआ technical term था
      • OpenAI models उस labeling judgment criteria को नहीं जानते थे
    • noshotsfired ऐसा field है जो एक खास अवधि की प्रेस रिलीज़ में “गोलीबारी नहीं हुई” बात पर जोर देने से निकला था
    • OpenAI models ने अपेक्षा के उलट order में performance दिखाया, और कारण समझने के लिए अतिरिक्त जांच की जरूरत है
    • min_leaders_killed और min_leaders_captured में overall high scores आए
    • LLMs numbers में कमजोर होते हैं, इस आम धारणा के उलट इस task में high performance दिखी, फिर भी fine-tuned models ने best results दिए

Final aggregated results

  • 13 individual accuracy scores को जोड़कर average निकाला गया और 0~100 scale की final aggregated accuracy calculate की गई
  • final results में fine-tuned models ने OpenAI GPT परिवार models को पीछे छोड़ दिया
  • TinyLlama ने भी GPT-3.5 Turbo से higher aggregated accuracy दिखाई
  • सबसे best-performing model OpenPipe पर fine-tune किया गया Mistral-7B था
  • Solar LLM और Llama3-7B, Mistral-7B से बेहद कम अंतर से पीछे रहे
  • structured data extraction fine-tuning में Mistral-7B, Solar 7B, Llama3-7B से शुरू करके कौन सा model best fit है, यह compare करने का approach उचित लगता है
  • केवल accuracy देखें तो ये तीनों models लगभग समान हो सकते हैं
  • model serving, efficiency और latency में अलग trade-offs हो सकते हैं

Fine-tuning के फायदे और लागत

  • OpenAI models में भी prompt में ज्यादा examples और rules डालकर performance बढ़ाई जा सकती है
  • लेकिन prompt लंबा होने पर प्रति request cost बढ़ती है
  • self fine-tuned model ये फायदे देते हैं
    • confidential information को OpenAI पर न भेजने की data privacy
    • छोटे model के कारण potential performance improvement
    • ज्यादा control
    • cost improvement की संभावना
  • cost comparison पर अभी साफ निष्कर्ष निकालना कठिन है
    • बड़े cloud providers economies of scale का फायदा उठा सकते हैं
    • लंबे समय तक repeated inference वाले real use cases में self model की cost logic ज्यादा convincing हो सकती है
    • OpenAI calls को improve करने के लिए बहुत सारे examples और explanations डालने पड़ सकते हैं, जिससे per-query cost बढ़ सकती है

Evaluation operations और MLOps complexity

  • Fine-tuning ने relatively कम tuning के साथ GPT-4 से बेहतर performance दी
    • इस्तेमाल किए गए models imported data से बने पहले fine-tuned models थे
    • ज्यादातर default values इस्तेमाल की गईं
  • आगे Solar, Llama3, Mistral 7B models पर focus करने की योजना है
  • Evaluation Jupyter notebook पर केंद्रित तरीके से implement किया गया, और operation process tedious था
    • कुछ models local पर चलते हैं
    • कुछ models अलग-अलग services और environments पर deploy हैं
    • 724 rows को loop करने वाला तरीका धीमा था
  • अगले iteration में evaluation को local पर run करने योग्य बनाना, data के कुछ slices का evaluation करके फिर full data तक expand करना जरूरी है
  • एक ही project में कई models handle करते समय standard inference interface जरूरी है
  • Models कई locations में फैले हों, fine-tuning और updates दोहराए जा रहे हों, और data लगातार बदल रहा हो, तो इन्हें manage करने के लिए system चाहिए
  • Fine-tuned LLMs का मुख्य trade-off यह है कि stable और repeatable operations के लिए बहुत सारे components manage करने पड़ते हैं

Evaluation से मिली value और next steps

  • Evaluation implementation tedious था, लेकिन इसने यह check करने का task-specific benchmark दिया कि training data या model improvement सच में progress ला रहे हैं या नहीं
  • Evaluation न हो तो improvement हुआ या नहीं, यह judge करना मुश्किल है
  • कई hyper-specialized models अलग-अलग बनाने का idea अभी का स्पष्ट next step नहीं है
    • जैसे: केवल captured personnel estimate करने में अच्छा separate model
    • current model performance देखें तो unclear है कि यह approach accuracy को बहुत बढ़ाएगा या नहीं
  • high-priority next step accuracy के अलावा evaluations चलाना है
    • पिछले article में mentioned out-of-domain data evaluation इसका example है
    • पूरी तरह अलग topic के fake data पर behavior check करना है
  • एक और next step top 3 models की LLM serving को गहराई से देखना है
    • LLM serving में non-LLM model serving से अलग tools, trade-offs और techniques होते हैं
  • अगर समस्या को और गहराई से देखा जाए, तो wrong cases को Lilac या Argilla जैसे web interface में डालकर failure patterns analyze करना उपयोगी होगा
  • failure scenarios को समझना fine-tuning parameters adjust करने की तुलना में accuracy improvement में ज्यादा मददगार हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-07-02
Hacker News की राय

  • OpenPipe के founder के तौर पर देखें तो data extraction ऐसा use case है जिसमें fine-tuned model खास तौर पर अच्छा करते हैं, इसलिए अच्छे नतीजे आना हैरानी की बात नहीं है
    अगर मजबूत training data बनाया जा सके, तो कई तरह के tasks में GPT-4 को हराना भी काफी आसान था, और एक हफ्ते पहले प्रकाशित हमारे research में भी creative summarization, Q&A, data extraction, classification जैसे 4 example tasks में से 3 में fine-tuned Llama 3 8B ने GPT-4 से बेहतर प्रदर्शन किया
    मुख्य बात high-quality training data को iterative तरीके से generate करने का तरीका बनाना था, और लेख में भी इसी हिस्से को कवर किया गया है: https://openpipe.ai/blog/mixture-of-agents

    • सोच रहा हूं कि क्या non-expert tech enthusiasts भी आसानी से fine-tune करके चला सकते हैं
      Use case यह है कि technical docs, खास news, 2 साल के blog posts, primary sources, Twitter explainer threads पर train करके पिछले 2 सालों में किसी topic की niche जानकारी इकट्ठा करने वाला topic expert LLM बनाया जाए
    • सोच रहा हूं कि अगर सवाल के आधार पर कई fine-tuned models में से एक चुनने वाला meta model LLM के रूप में बनाया जाए, तो क्या कुल मिलाकर GPT-4 से बेहतर नतीजे नहीं मिल सकते
    • सोच रहा हूं कि प्रमुख LLM providers (OpenAI, Anthropic आदि) के model responses से नए model को train करना terms of service का उल्लंघन है या नहीं

  • यह नतीजा बिल्कुल भी हैरान करने वाला नहीं है, और information extraction व text classification में छोटे specialized models भी बेहतर करते हैं—यह पहले के results से मेल खाता है
    PhD के दौरान मैंने fine-grained ACE-type event और emotion extraction किया था, और “छोटे” specialized fine-tuned transformers, BERT या Roberta-large जैसे LLM prompting से बेहतर थे
    Latest pipelines के साथ small model scores भी शामिल हों तो अच्छा होगा, और भले ही यह known result को reproduce करता हो, फिर भी काम अच्छा है

    • एक caveat है कि अगर अच्छे specialized models बनाना नहीं आता, तो सबका समय और पैसा ही बर्बाद होगा: https://www.threads.net/@ethan_mollick/post/C46AfItO8RS?hl=e...
    • Paper का topic दिलचस्प लग रहा है; क्या कोई link है?

  • असली काम में LLM का जो गंभीर use case उपयोगी लगा, वह सिर्फ data extraction/structuring था
    Experience sampling reports से, जिन्हें online share नहीं किया जा सकता था, events की शुरुआत, अंत और description निकालना था, और llama.cpp से model चलाकर उन्हें onset, offset, description, और किसी खास condition के पूरा होने/न होने—इन 4 columns वाले CSV में बदला
    Prompt में desired structure के कुछ examples डालने भर से कई models ने अच्छा काम किया, और laptop पर same quality range में सबसे तेज Mixtral 8x7b पसंद आया
    इस task के लिए fine-tuned छोटा model शायद बेहतर और तेज होगा, और जब OpenAI जैसी जगहों पर data नहीं भेज सकते तो offline processing जरूरी होती है; ऐसे में छोटे, locally runnable और fine-tunable models चमक सकते हैं

    • GPT-3 के साथ web data extraction experiment करते हुए यह बात जल्दी समझ आ गई थी, और Reddit व HN पर पहला prototype डालने के बाद rule-based web scraping stack को automate करने की काफी मांग दिखी
      Maintenance-heavy और scale करना मुश्किल इस “boring and hard” problem को automate करने वाले startup https://kadoa.com तक बात पहुंची
      AI सबसे ज्यादा value ऐसे relatively कम flashy use cases में जोड़ता है, और jobs खत्म करने के बजाय web scraping, form filling, data entry जैसे repetitive tasks को automate करेगा
    • Next step में deployment/inference पर काम करते हुए देखना चाहता हूं कि model को कितना छोटा बनाया जा सकता है
      Spacy लंबे समय से tens of MB वाले models के साथ इसी दिशा को आगे बढ़ाता रहा है, और अब इसमें ज्यादा interest दिखना अच्छा है
      Ideally, बहुत सारे tiny models हों जो हर एक बेहद specialized, size में छोटे और inference में तेज हों, लेकिन अगर उन्हें सही ढंग से organize न किया जाए तो सबको up to date रखना किसी point पर manage करना मुश्किल हो जाएगा

  • यही तो model fine-tuning का core है
    Hosting options और local options को मिलाकर fine-tuning process को follow करके दिखाना अच्छा लगा

    • क्या कोई अच्छी service है जहां “यह dataset है, इन 9 models को fine-tune करो और evaluation stats दो” जैसा काम हो सके?
    • असली point सिर्फ यह नहीं है कि model fine-tune करने से बेहतर हो गया, बल्कि यह है कि कहीं ज्यादा simple model को fine-tune करके काफी ज्यादा advanced model को हराया गया

  • लेख अच्छी तरह लिखा गया और informative है
    Example के GPT test में temperature=1 इस्तेमाल होता दिखा; सोच रहा हूं कि structured output की जरूरत वाले tasks में क्या यह best practice है
    मेरी हल्की-फुल्की समझ के हिसाब से ऐसे workloads के लिए temperature 0 सबसे अच्छा होता है, और higher temperature ज्यादा creative tasks के लिए होता है

    • Settings उस specific model की guide के हिसाब से रखीं
      कुछ LLM fine-tuning providers ने सच में temperature 0 specify किया था, और उसे वैसे ही follow किया; दूसरों ने 1 recommend किया
      हर model के लिए best value ढूंढने को iterative experiments किए जा सकते हैं, और बाद की iterations/fine-tuning में जिन models पर focus करना हो, उनके लिए ऐसा करना worth it है

  • ऐसा example देखना अच्छा होगा जहां GPT-4o गलत था लेकिन best-performing model सही था
    साथ ही structured data extraction काफी करने के अनुभव से, temperature 0 पर दोबारा try करना अच्छा होगा; मेरे experience में हमेशा 0 इस्तेमाल करना चाहिए और फर्क बहुत बड़ा हो सकता है
    Temperature 1 का मतलब व्यवहार में यह है कि वह ऐसे tokens भी चुनना शुरू कर देता है जिनके सही होने की probability कम है

    • Historical data के आधार पर जिस use case में साफ सही/गलत answers हैं, उसमें temperature 0 comparison दिलचस्प होगा
      AI SQL editor में temperature experiment करते समय 0.3 ideal था, क्योंकि 0 के करीब जाना accuracy के लिए optimize करता है, लेकिन गलती होने पर self-recovery मुश्किल हो जाती है

  • इसी तरह के topic पर paper लिखा था: https://www.nature.com/articles/s41467-024-45563-x

  • सोच रहा हूं कि target news article की potentially controversial content, ChatGPT की summarization ability को प्रभावित कर सकती है या नहीं

    • OpenAI Azure के साथ financial news articles पर LLM information extraction इस्तेमाल कर रहा हूं, और यह बड़ा problem है
      सिर्फ financial news text से ही 4% articles में 404 content moderation response आता है, और यही open models पर विचार करने की मुख्य वजह है
    • शायद ऐसा नहीं होगा
      आम तौर पर ऐसी error आने पर output बिल्कुल नहीं आता, लेकिन लेख दिखाता है कि सभी 724 test cases में queries के लिए normal JSON output मिला
      ऐसे topics training data में अच्छी तरह शामिल रहे होने की संभावना है, और open-source models ने भी similar data इस्तेमाल किया होगा, इसलिए proprietary models और open-source models के बीच gap भी बहुत बड़ा नहीं होगा

  • पुराने खयालों वाला लगने का risk लेकर कहूं तो top priority यह होनी चाहिए कि सभी models को जितना हो सके free/open-source के रूप में release किया जाए, ताकि हर कोई उन्हें fine-tune कर सके
    यह उस broader idea का sub-case है कि free/open-source आम तौर पर freedom और quality दोनों में बेहतर होता है

    • इसका मतलब ऐसा लगता है कि जो सबसे ज्यादा personal data जमा करके उस पर ownership claim करेगा, वही best product बनाएगा
      यह वैसा ही है जैसे targeted ads ज्यादा “relevant” होने के कारण अच्छे लगते थे, लेकिन अब बात ads से आगे useful products तक पहुंच गई है
      Apple या Microsoft जैसे platform owners apps और products से, यहां तक कि local तौर पर भी, data scrape कर सकते हैं, इसलिए model quality में 3–6 महीने आगे होने से कहीं बड़ा advantage बन जाता है
      इस tech की centralization मुझे पसंद नहीं है, लेकिन small fine-tuned models बेहतर हैं यह hopeful बात होने पर भी openness और privacy भर से जीतना मुश्किल या लगभग असंभव होगा
      Best case यह है कि SMB services के area में open models commoditized और effective हो जाएं, ताकि OpenAI token costs की जरूरत न रहे
      शायद यही Zuck का plan रहा होगा, और इरादा ऐसी technology में centralized gatekeeper को रोकना रहा होगा जिससे मुख्य तौर पर competitors को फायदा होता है
      फिर भी दुश्मन का दुश्मन दोस्त होता है, इसलिए उसके actions public good के लिए किए गए सबसे अच्छे कामों में से हो सकते हैं

  • Predibase ने हाल ही में 700 से ज्यादा fine-tuning experiments किए, popular open-source LLMs की 30 tasks पर performance benchmark की और GPT-4 से compare किया
    85% cases में GPT-4 को हराया, और results यहां देखे जा सकते हैं: https://predibase.com/fine-tuning-index
    Site पर interactive charts और Arxiv paper link है