फाइन-ट्यूनिंग की वापसी

• फाइन-ट्यूनिंग फिर से AI डेवलपमेंट मेथडोलॉजी के केंद्र में उभर रही है, और यह Thinking Machines Labs के Tinker ऐलान तथा self-managed open source LLM deployment की ओर paradigm shift से प्रेरित है
• एक समय AI inference workload के 10% से भी कम तक सिमट चुकी फाइन-ट्यूनिंग अब GPU-as-a-service platforms, स्थिर हो चुके model ecosystem, और open-weight models के प्रसार के कारण फिर चर्चा में है
• LoRA(Low-Rank Adaptation) तकनीक अरबों parameters को दोबारा train करने के बजाय केवल छोटे low-rank matrices जोड़ती है, जिससे लागत बहुत घटती है और performance बनी रहती है या बेहतर होती है
• Tinker online reinforcement learning के ज़रिए continuous learning architecture देता है, जो पहले से लिखे गए जवाबों की नकल कराने के बजाय मॉडल के अपने जवाबों का मूल्यांकन और सुधार करके फाइन-ट्यूनिंग का भविष्य दिखाता है
• फाइन-ट्यूनिंग अब केवल एक तकनीकी चरण नहीं रही, बल्कि ownership, alignment, और continuous improvement के लिए एक strategic layer में विकसित हो रही है, और personal AI computers तथा specialized agents चलाने की प्रमुख शक्ति बन सकती है

---

फाइन-ट्यूनिंग की ऐतिहासिक पृष्ठभूमि

• Thinking Machines Labs ने Tinker की घोषणा की, जिससे fine-tuning-as-a-platform पर चर्चा फिर तेज़ हुई
  • OpenAI की पूर्व CTO Mira Murati द्वारा स्थापित इस startup को स्थापना के 6 महीने के भीतर 12 अरब डॉलर का valuation मिला
  • इसने विश्वविद्यालयों के साथ research collaboration के आधार के रूप में अपने fine-tuning platform को स्थापित किया
• Hugging Face के Clément Delangue ने self-managed, open source, specialized LLM deployment की ओर paradigm shift महसूस किया
  • NVIDIA का DGX Spark जैसे dedicated hardware इसे समर्थन दे रहे हैं
  • a16z का Personal AI Workstation इस trend का marketing उदाहरण है
• बड़े language models की पहली लहर के बाद फाइन-ट्यूनिंग पर थोड़े समय के लिए ध्यान गया था, लेकिन अब यह घटकर AI inference workloads के 10% से भी कम रह गई थी

Transformer से पहले का दौर

• Transformer क्रांति से पहले NLP specialized models पर निर्भर था
  • RNN और LSTM जैसी recurrent architectures ने शुरुआती प्रगति दिलाई
  • पहली बार hand-crafted linguistic features के बजाय word sequences से सीधे learning हुई
  • हर application को task-specific data के साथ शुरुआत से बनाना पड़ता था

Transformer का आगमन और फाइन-ट्यूनिंग मेथडोलॉजी की स्थापना

• 2017 में Google के Attention Is All You Need पेपर ने Transformer architecture पेश की
  • इसने recurrence और convolution को केवल self-attention से बदल दिया
• 7 महीने बाद ULMFiT ने साबित किया कि pre-trained language models, जो उस समय अभी भी LSTM आधारित थे, को अलग-अलग tasks के लिए fine-tune किया जा सकता है
  • इसने Transformer को व्यावहारिक बनाने के लिए methodological foundation स्थापित किया
• एक साल बाद BERT और GPT-1 ने इस डिज़ाइन को वास्तविक रूप में लागू किया
  • BERT ने understanding के लिए bidirectional attention वाले encoder पक्ष का उपयोग किया
  • GPT ने generation के लिए unidirectional attention वाले decoder पक्ष का उपयोग किया
• BERT ने खास तौर पर NLP की संस्कृति को बदल दिया
  • हर मॉडल को शुरुआत से बनाने के बजाय, researchers ने pre-trained Transformer को fine-tune करके वे परिणाम हासिल किए जिनके लिए पहले महीनों की manual feature engineering लगती थी

Full Fine-Tuning की सीमाएँ और LoRA का आगमन

• जब parameters लाखों से बढ़कर सैकड़ों अरब तक पहुँच गए, तब फाइन-ट्यूनिंग अब समझदारी भरा विकल्प नहीं रही
  • Full Fine-Tuning(FFT) का मतलब सभी layers और weights को दोबारा train करना है
  • इससे precision तो मिलती थी, लेकिन लागत बहुत अधिक थी
  • जो कभी कुछ घंटों का GPU काम था, वह बड़े औद्योगिक ऑपरेशन में बदल गया
• 2021 में Microsoft Research ने LoRA(Low-Rank Adaptation of Large Language Models) पेश किया
  • अरबों parameters को फिर से train करने के बजाय, LoRA मूल weights को freeze करती है और चुनी हुई layers में छोटे low-rank matrices जोड़ती है
  • केवल इन्हीं को train किया जाता है, जिससे लागत एक अंकीय गुणक तक घटती है और FFT की performance बनी रहती है या बेहतर होती है
  • LoRA default तरीका बन गया
  • 2024 तक Hugging Face की PEFT library की वजह से इसे एक line command से लागू करना संभव हो गया

Hyperparameter tuning की जटिलता

• फाइन-ट्यूनिंग केवल deploy और maintain करने वाला package भर नहीं है
  • असली जादू tuning में होता है, और ऐसी कोई एक configuration नहीं जो हर चीज़ पर फिट बैठे
• Hyperparameter tuning ही मॉडल की सफलता या विफलता तय करती है
  • rank, learning rate, और alpha ratio के बीच संतुलन बनाना विज्ञान से ज़्यादा कीमियागरी जैसा है
  • adapter overfitting या मॉडल द्वारा पहले से ज्ञात चीज़ें भूल जाने की समस्या(catastrophic forgetting) से बचना पड़ता है
• जब कुछ काम करने लगता है, तो evaluation validation से अधिक भविष्यवाणी-जैसा महसूस हो सकता है
• इस बीच LLM लगभग हर task में बेहतर होते गए और लगभग सर्वशक्तिमान लगने लगे
  • 2023 तक अधिकतर teams ने समझ लिया कि बड़े context windows की मदद से वे prompt engineering के माध्यम से fine-tuning performance का लगभग 90% हासिल कर सकते हैं
  • RAG(Retrieval-Augmented Generation) भी मॉडल को बाहरी knowledge base तक पहुँच देता है
  • इन दोनों approaches में retraining की ज़रूरत नहीं होती और बहुत कम operational burden के साथ ठीक-ठाक परिणाम मिल जाते हैं

फाइन-ट्यूनिंग फिर से ध्यान में क्यों है

• जो कारण पहले फाइन-ट्यूनिंग को अप्रासंगिक या अक्षम बनाते थे, वे अब एक-एक करके हल हो रहे हैं
  • Together.ai जैसे GPU-as-a-service platforms बहुत कम friction के साथ LoRA fine-tuning pipeline शुरू करने देते हैं
  • नए models अब भी तेज़ी से आ रहे हैं, लेकिन बदलाव अब क्रांतिकारी से अधिक evolutionary हैं
  • Mistral, Llama, Falcon, Yi, Gemma जैसे open-weight ecosystem संगठनों को vendor lock-in के बिना fine-tuned variants को own, inspect, और maintain करने के कई विकल्प देते हैं
  • कंपनियाँ शायद केवल prompting से हासिल होने वाली चीज़ों की सीमा तक पहुँच चुकी हैं
• फाइन-ट्यूनिंग को अब trendy feature नहीं, बल्कि control, differentiation, और embedded intelligence के लिए strategic lever के रूप में धीरे-धीरे फिर महत्व मिल रहा है

Thinking Machines Lab का Tinker और LoRA में सुधार

• Thinking Machines Lab का Tinker theorem proving, chemical reasoning, multi-agent reinforcement learning, और AI safety पर केंद्रित है
• उनकी blog post LoRA Without Regret में उन्होंने अधिक प्रभावी fine-tuning के तरीके साझा किए
  • मूल पेपर की तरह केवल attention layers नहीं, बल्कि सभी linear modules पर LoRA लागू करने की सिफारिश की
  • अक्सर नज़रअंदाज़ किए जाने वाले hyperparameter LoRA rank के महत्व पर ज़ोर दिया
  • उच्च learning rate(कम से कम 10 गुना), और छोटे batch size(सामान्य प्रथा के उलट) की सलाह दी
  • गणितीय या तार्किक verification के साथ reward function को स्पष्ट रूप से परिभाषित करने की सलाह दी
  • सभी सिफारिशें Hugging Face के TRL में स्पष्ट रूप से समझाई गई हैं और reproducible हैं

आधुनिक फाइन-ट्यूनिंग pipelines की modularity

• आधुनिक fine-tuning pipelines 5 साल पहले की तुलना में पूरी तरह अलग हैं
  • वे modular, serverless, और orchestrated हैं
• एक single deployment, base model के साथ दर्जनों LoRA adapters चला सकता है
  • हर adapter किसी खास tone, function, या domain का प्रतिनिधित्व करता है
• inference के दौरान system, static model file पर निर्भर रहने के बजाय सही adapter combination की ओर queries route करता है
• यह modularity अपनी चुनौतियाँ भी लाती है
  • Together.ai जैसे all-in-one platforms ज़्यादातर भारी काम संभाल लेते हैं, लेकिन उनमें अक्सर वह granular configuration और observability की कमी होती है जिसकी कई teams को ज़रूरत होती है
  • बड़े पैमाने पर लागत तेज़ी से बढ़ सकती है

Tinker का विशिष्ट दृष्टिकोण

• Tinker दोनों दुनिया के फायदे देने वाला लगता है
  • यह modern, fully managed fine-tuning stack की सुविधा को researchers के लिए granular control के साथ जोड़ता है
  • यह users को learning workflow और custom algorithms को सबसे गहरे स्तर पर orchestrate करने के लिए low-level learning primitives तक direct API access देता है
  • साथ ही यह कठिन काम भी संभालता है
• अभी Tinker केवल research उद्देश्यों के लिए reserved है, लेकिन उम्मीद है कि यह दूसरे platforms को प्रेरित करेगा
• infrastructure समस्याएँ धीरे-धीरे अतीत की बात बन रही हैं, लेकिन evaluation की बड़ी चुनौती अब भी बनी हुई है

मॉडल evaluation की कठिनाई और online reinforcement learning

• models का मूल्यांकन करना बहुत कठिन है
  • human evaluation असंगत, धीमा, और सबसे बढ़कर महँगा है
  • benchmarks जल्दी पुराने हो जाते हैं और data contamination के कारण प्रासंगिकता खो देते हैं
  • G-Eval या Chatbot Arena जैसे automated approaches भी अपनी समस्याएँ पैदा करते हैं और अक्सर bias को बढ़ाते हैं तथा अस्थिर scores बनाते हैं
• Benjamin Anderson का सुझाव है कि Tinker के पास समाधान का एक हिस्सा हो सकता है
  • Tinker users को online reinforcement learning करने की क्षमता देता है
  • यह वर्तमान model weights से completions लेता है, उन completions को score करता है, और completion अच्छा था या बुरा उसके आधार पर मॉडल को update करता है
  • supervised fine-tuning मॉडल को पहले से लिखे जवाबों की नकल करना सिखाती है, जबकि online RL उसके अपने जवाबों को score करके उसे बेहतर बनाती है
• इस architecture के साथ फाइन-ट्यूनिंग का भविष्य शायद फाइन-ट्यूनिंग जैसा दिखे ही नहीं
  • यह continuous learning जैसा लगने लगता है

फाइन-ट्यूनिंग का रणनीतिक विकास

• Moyai.ai के Robert Hommes ने कहा
  • "सैद्धांतिक रूप से फाइन-ट्यूनिंग हमेशा उचित थी। लेकिन closed-source labs जिस गति से model intelligence बढ़ा रहे थे, उसने इसे व्यावहारिक रूप से खराब विकल्प बना दिया"
  • "अब computing, data, और बेहतर frameworks के कारण रुझान फिर specialization की ओर झुक रहा है"
• self-hosting की ओर बदलाव उम्मीद से ज़्यादा नज़दीक हो सकता है
  • Exxa के Constant Razel ने कहा, "personal AI computers अब कोई दूर की कल्पना नहीं हैं"
  • तकनीक बेहतर हो रही है और अधिक सुलभ बन रही है
  • security और cost शुरुआती adoption को आगे बढ़ा सकते हैं
  • फाइन-ट्यूनिंग specialized high-performance agents को इसके ऊपर चलने योग्य बनाएगी
• फाइन-ट्यूनिंग अब सीमांत accuracy के लिए brute-force खोज से बदलकर proximity और control पर आधारित ownership, alignment, और continuous improvement के framework में बदल रही है
• यह अब केवल एक तकनीकी चरण नहीं, बल्कि intelligence के निर्माण और ownership के तरीके की strategic layer हो सकती है

[m00nlygreat]

लगता है इंसान ही उल्टा AI की प्रगति में रुकावट बन रहे हैं। यह काफ़ी दिलचस्प दुविधा है। हाहा

[GN⁺]

Hacker News राय

• सिर्फ 1 साल पहले तक मैं आशावादी था। RL-आधारित fine-tuning का एक वाकई मायने रखने वाला उदाहरण भी था। लेकिन जब इसे असली प्रोडक्शन काम में लागू करने की कोशिश होती है, तो मौजूदा इंडस्ट्री प्रैक्टिस से बहुत टकराव आता है। अपने आसपास के ML इंजीनियरों को देखकर लगता है कि खासकर LLM के बाद भर्ती हुए लोगों में असली ML ज्ञान की कमी अक्सर होती है। वे मूलतः AI डेवलपर या AI DevOps रोल में हैं। ML खुद भी data engineering और analytics की तरह धीरे-धीरे platform tools चलाने वाली नौकरी में बदलता जा रहा है। सच तो यह है कि कुछ cloud platform AI products में तो evaluation metrics तक नहीं मिलते, जिससे ढंग का ML solution बनाना मुश्किल हो जाता है। और हैरानी की बात यह है कि इसे बहुत बड़ा मुद्दा मानने वाले लोग भी कम हैं। RL fine-tuning के लिए अनगिनत बारीकियां, monitoring points और data refinement चाहिए। अब तो लोग साधारण ML models भी ठीक से कम सीखते हैं, और RL fine-tuning की learning gap उससे कहीं बड़ी है। अच्छे वास्तविक उदाहरण कम हैं, इसलिए काम के दौरान किसी सीनियर से सीखने का मौका भी नहीं मिलता। expert assignment और data labeling की लागत बचाने का भी चलन है। मुझे संदेह है कि कंपनी ऐसी तकनीकी मदद कितने समय तक देगी, और मेरे जाने के बाद इसे बारी-बारी से कौन संभालेगा। AutoML भी जनसामान्य तक नहीं पहुंच पाया, और मुझे लगता है RL को भी platform बनाना आसान नहीं होगा। हकीकत यह है कि ज्यादातर कंपनियां बड़े पैमाने पर स्केल होने वाले लेकिन घटिया products पर ज्यादा पैसा खर्च करने में भी हिचकिचाती नहीं हैं। इंडस्ट्री का ‘अनुभव’ आखिरकार proprietary platforms का अनुभव बनकर रह जाता है। tech stack में कभी-कभी “pytorch” मांगते हैं, लेकिन उसे सच में इस्तेमाल करना जानने वाले कर्मचारी लगभग नहीं होते। और अगर हों भी, तो operational burden की वजह से उसका उपयोग नहीं हो पाता

  • Labeling, चाहे आप model को train करें या न करें, system को तेज़ी और निष्पक्ष तरीके से validate करने के लिए वाकई ज़रूरी है। लेकिन labels हासिल करना हमेशा मुश्किलों से भरा रहता है। कभी-कभी SME resources मिल भी जाएं, तब भी उनसे सख्ती से एक समान मानदंड लागू करवाने वाली communication कठिन होती है, और आखिरी labels अक्सर इस्तेमाल लायक नहीं निकलते। नतीजतन मैं कई बार खुद ही स्वेच्छा से labeling करता था। domain understanding मेरी सीमित थी, लेकिन “neural network को क्या पसंद आता है” इसका मोटा अंदाज़ा था, इसलिए waiting time काफ़ी घट जाती थी। बड़े models को tune करना आज भी justify करना आसान नहीं है। अक्सर 6 महीने इंतज़ार करें तो उससे बेहतर base model आ जाता है। लेकिन अगर बड़े model इतने महंगे हों कि efficiency गिर रही हो, तो छोटे model को उद्देश्य के हिसाब से fine-tune करना निश्चित रूप से मूल्यवान है

  • मुझे लगता है कि असली engineering — यानी जटिल theory को सच में काम करने वाले systems में बदलने की क्षमता — व्यापक अर्थ में काफी कमजोर हुई है। अब लोग engineering skill को निखारने में बहुत समय लगाने के बजाय पहले से बने engineering services पर सवार होना ज़्यादा पसंद करते हैं। hacker mindset से देखें तो किसी धुंधले-से GPU पर खुद model train करने से ROI मांगने की बात नहीं होती। व्यक्तिगत इंजीनियर ज्ञान अर्जित करने की भूख से ऐसा करते हैं

  • आख़िरकार कोई न कोई वास्तविक performance measurement के ज़रिए सही नतीजे देगा, और फिर Michael Lewis इस पर किताब लिखेगा, तो एक नया cycle फिर शुरू हो जाएगा

  • मैंने भी कई ऐसी teams देखी हैं जिन्होंने fine-tuning से बड़ा प्रभाव अपेक्षित किया, लेकिन वास्तव में उन्हें सिर्फ incremental या मामूली सुधार ही मिला। आखिर में productization तक ले गए, फिर नए SOTA updates के साथ कदम न मिला पाने का अफसोस हुआ। मैं जानबूझकर fine-tuning से बच रहा हूं। क्योंकि models खुद इतनी तेजी से बेहतर हो रहे हैं कि बड़ी कंपनियों की product development speed उनका पीछा नहीं कर पा रही

• हाल ही में मैंने Twitter पर LLM fine-tuning से आर्थिक value बनाने वाले examples पर survey किया। मैं यह सवाल लगभग हर 6 महीने में पूछता हूं, और ज़्यादातर नतीजे हमेशा निराशाजनक रहे हैं। इस बार पहले की तुलना में थोड़े ज़्यादा भरोसेमंद जवाब मिले। मुख्य examples मैंने अपने Twitter thread में संकलित किए हैं, और जो Twitter पर नहीं हैं उनके लिए thread viewer लिंक भी साझा किया है। एक प्रभावशाली case Datadog का है, जिसने natural language search query feature में 500ms से कम latency हासिल की हैसंबंधित ट्वीट, official docs देखें। Vercel, Next.js auto-generation के लिए custom fine-tuned model चला रहा हैblog भी है। Shopify product photo analysis के लिए fine-tuned Vision LLM का उपयोग कर रहा हैलेख देखें

  • Regression tasks में fine-tuning लगभग अनिवार्य है। Classification में भी yes/no threshold tuning के लिए probability values सीधे इस्तेमाल की जा सकती हैं, इसलिए यह उपयोगी है

  • ज्यादातर कंपनियों के लिए fine-tuning का risk-reward अपेक्षा से खराब होगा। अगर prompt में और data ठूंसकर काम हो सकता है, तो अक्सर वही आसान पड़ता है

  • अगर आपके पास ऐसे use cases के ideas हैं जहां fine-tuning बड़ा बदलाव ला सकती है, लेकिन खुद experiment करने का समय या resources नहीं हैं, तो ऐसे ideas साझा करना स्वागतयोग्य है। मैं अभी ऐसे cases इकट्ठा कर रहा हूं, और फिलहाल मेरे पास सिर्फ 3 वास्तविक/verified examples हैं

  • बहुत से लोग जो LLM में domain knowledge fine-tune करना चाहते हैं, वे अक्सर गलती से, मान लीजिए psychology की किताबों को काटकर सिर्फ text भर देते हैं। उस तरीके से आप ‘psychology लागू करने का व्यवहार’ नहीं सिखाते, बल्कि केवल उसके बारे में ‘परिचयात्मक लेख लिखना’ सिखाते हैं। dataset design की गलतियां fine-tuning की कई असफलताओं का कारण हैं। उल्टा, अगर dataset structure सही हो, तो 7B model भी 180B model से बेहतर efficiency दे सकता है

• हाल में देखे कुछ examples के आधार पर मैं OP की राय से सहमत हूं। PaddleOCR, 0.9B parameters के साथ text, tables, formulas, charts और handwriting तक में SOTA accuracy के करीब पहुंचता हैpaper। और 3B/8B models HTML को JSON में निकालने वाले task में GPT-5 स्तर की accuracy, 40~80x सस्ती लागत और तेज़ inference speed हासिल कर रहे हैंReddit। अगर आप किसी खास task की efficiency बढ़ाना चाहते हैं, तो fine-tuning मायने रखती है

  • क्या किसी ने PaddleOCR को खुद इस्तेमाल किया है? Amazon Textract या Azure Document Intelligence (LayoutLM v3 आधारित) से तुलना किए बिना SOTA कहना थोड़ा अजीब लगता है। मैंने document recognition पर experiments किए थे, तब ये दोनों सबसे मजबूत लगे थे

  • यह चर्चा फिर SLM बनाम LLM, यानी model size के सवाल पर लौटती है। SLM को खास workflows के लिए optimize किया जा सकता है, और उस task में वह LLM को हरा भी सकता है। लेकिन अगर 1. precision बहुत महत्वपूर्ण न हो, या 2. traffic बहुत ज़्यादा न हो, तो समय/मेहनत के हिसाब से इसका मूल्य कम हो जाता है

• Lamini नाम का LLM fine-tuning startup शुरू करने वाले व्यक्ति के तौर पर मैं OP से सहमत नहीं हूं। हमारी hypothesis यह थी कि fine-tuning, deep learning को शुरू से सीखने की तुलना में बहुत आसान तरीके से इस्तेमाल होगी। हम पहले से बहुत शक्तिशाली LLM से शुरू कर रहे थे, इसलिए यह और आसान लगेगी — ऐसा सोचा था। लेकिन लगभग 20 वास्तविक projects करने के बाद पता चला कि fine-tuning, deep learning जितनी ही कठिन है और उसका entry barrier भी ऊंचा है। मौजूदा market structure में यदि कोई ML engineer deep learning आधारित fine-tuning में सक्षम है, तो वह startup शुरू कर सकता है या आसानी से Anthropic, OpenAI वगैरह में शामिल हो सकता है। विडंबना यह है कि LLM solutions बनाने वाली teams में सबसे अच्छे engineers की वैसी कद्र नहीं होती। नतीजतन Claude, GPT, Qwen जैसी चीजें बनाने वाली विशेषज्ञ teams, व्यक्तिगत users की fine-tuning कोशिशों से ज़्यादा प्रतिस्पर्धी हैं। अभी RAG, prompt engineering, reasoning, AI agents, memory, SLM वगैरह कहीं ज़्यादा आसान और शक्तिशाली solutions हैं

  • क्या Anthropic या OpenAI सच में किसी भी ऐसे व्यक्ति को रख लेते हैं जो LLM fine-tuning करना जानता हो?

  • उस समय जिन models की fine-tuning की गई थी, वे किस तरह के थे? क्या वे इतने mature थे कि उन्हें अच्छी तरह tune किया जा सके? क्या catastrophic forgetting जैसी समस्या थी? अब तो कहीं बेहतर open source models भी उपलब्ध हैं। अगर architecture को शुरू से fine-tuning को ध्यान में रखकर डिज़ाइन किया जाए, तो पिछली पीढ़ी की कमियों को भी दूर किया जा सकता है। कंपनियां किसी और का model किराये पर लेने के बजाय अपना model खुद own करना चाहती हैं

• Fine-tuning toolbox में ज़रूर होना चाहिए ऐसी अच्छी technique है। लेकिन व्यवहार में इसके लागू होने वाले use cases अपेक्षा से कहीं संकरे हैं। एक तरफ कई NLP tasks में LLM का base performance ही इतना अच्छा है कि fine-tuning की ज़रूरत नहीं पड़ती। दूसरी तरफ, सचमुच जटिल tasks में fine-tuning बहुत मुश्किल है और data collection बहुत महंगी है। अंततः fine-tuning उन tasks के लिए उपयोगी solution है जो कठिनाई में बीच के स्तर पर हों और जिनके लिए data collection व्यावहारिक हो

  • मुझे लगता है ऐसे उपयुक्त use cases लाखों में हो सकते हैं

  • ऐसे “बीच वाले” tasks के कुछ उदाहरण कौन से हो सकते हैं?

• यह website यूरोप से एक्सेस करने पर भी बहुत तेज़ load होती है। scroll के साथ content dynamically load होता है, और images भी ज़्यादा compression के बावजूद अच्छी quality रखती हैं। site structure वाकई प्रभावशाली है

  • शायद CDN का जादू, और साथ ही JS का न्यूनतम उपयोग (हालांकि मैंने अभी source नहीं देखा)

• मैंने हाल ही में इसी विषय पर एक blog post लिखी थीblog। उसमें 7B model को fine-tune कर GPT-4 से बेहतर करने वाले बड़े empirical study “LoRA Land” और पिछले 6 महीनों में fine-tuning trends कैसे बदले हैं, इस पर चर्चा की थी

• मैं सोच रहा हूं कि LoRA adapters के ज़रिए वे context elements — जैसे task standards, naming style preferences, reference materials, MCP definitions — जिन्हें अभी existing prompt में ज़रूर डालना पड़ता है, क्या model के अंदर डाले जा सकते हैं। Data बनाना भी आसान होगा: पहले मौजूदा context को जितना संभव हो उतना भरें, अलग-अलग prompts आज़माएं, और देखें response baseline से कैसे अलग है। फिर उन outputs को fine-tuning में input=“refactor {base model output}”, output=“{full-context model output}” के रूप में डाला जा सकता है। LoRA मूल रूप से combine करके इस्तेमाल करने के लिए डिज़ाइन किया गया था, इसलिए MCP को भी adapter के रूप में deploy करके on/off किया जा सकता है। मुझे लगता है इस तरीके से context poisoning तक रोकी जा सकती है

• मैं inference.net और schematron का developer हूं। कंपनियां जब LLM को वास्तविक products में लागू करती हैं, तो वे efficiency पर लगातार ज़्यादा ध्यान देने लगती हैं। developer के नज़रिए से, भले ही GPT-5-Super-AGI-Thinking-Max जैसे महंगे model के लिए भुगतान करना संभव हो, असली business efficiency भी देखता है। अगर 8 billion parameter वाला Llama model, GPT-5 data के आधार पर 48 घंटे के भीतर fine-tune होकर हर महीने 100,000 डॉलर बचा सकता हो, तो जाहिर है हर कोई उस मौके को पकड़ना चाहेगा

• अब लगता है कि ज़्यादातर कंपनियां सिर्फ simple prompts से हासिल होने वाली सीमा तक पहुंच चुकी हैं। उन्हें ऐसा model चाहिए जो उनकी अपनी vocabulary, tone, classification system और compliance rules को ठीक-ठीक जानता हो। speed और cost का महत्वपूर्ण होना भी सही है, और यही fine-tuning का मुख्य कारण है। लेकिन context management techniques के साथ collaboration भी संभव हो गया है। context size बढ़ने के साथ RAG ने fine-tuning की जगह ली, और हाल में बेहतर prompt design से उपयोगिता और बढ़ी है। FPGA बनाम CPU/GPU बहस की तरह, सर्वोच्च performance के लिए development cost और delivery risk की वजह से ज़्यादातर लोग high-end fine-tuning के फायदे नहीं उठा पाते