AutoThink: अनुकूली reasoning से लोकल LLM प्रदर्शन में सुधार

• यह एक ऐसी तकनीक है जो लोकल LLM को क्वेरी की कठिनाई के अनुसार reasoning tokens समायोजित करने में मदद करती है, ताकि वही संसाधन इस्तेमाल करके अधिक कुशल उत्तर तैयार किए जा सकें
• हर क्वेरी को समान “सोचने का समय” देने के बजाय, इसे HIGH/LOW जटिलता में बांटा जाता है; जटिल reasoning के लिए 70~90% और सरल क्वेरी के लिए 20~40% tokens आवंटित किए जाते हैं
• Microsoft Phi-4 पेपर के Pivotal Token Search आधारित steering vector के जरिए numerical accuracy, self-correction, और thorough exploration जैसे reasoning patterns को प्रेरित किया जाता है
• DeepSeek-R1-Distill-Qwen-1.5B में GPQA-Diamond 21.72% बेसलाइन के मुकाबले बढ़कर 31.06% हुआ, यानी सापेक्ष 43% सुधार, और MMLU-Pro 25.58% से बढ़कर 26.38% हुआ
• यह DeepSeek, Qwen, और custom fine-tuned models जैसे लोकल reasoning models पर काम करता है, और API निर्भरता के बिना baseline approach से कम tokens इस्तेमाल करता है

---

क्वेरी के अनुसार reasoning संसाधनों का नियंत्रण

• AutoThink एक अनुकूली resource allocation तकनीक है जो लोकल LLM के reasoning संसाधनों को हर क्वेरी के लिए अलग तरह से वितरित करती है
• पहले क्वेरी को HIGH या LOW जटिलता में वर्गीकृत किया जाता है, फिर उसी के अनुसार reasoning token ratio समायोजित किया जाता है
  • जटिल reasoning: कुल tokens का 70~90%
  • सरल क्वेरी: कुल tokens का 20~40%
• steering vector, Pivotal Token Search से व्युत्पन्न है और generation के दौरान मॉडल की reasoning दिशा को मार्गदर्शित करता है
  • जिन व्यवहारों को प्रेरित किया जाता है उनमें numerical accuracy, self-correction, और thorough exploration शामिल हैं
• इसका implementation दो हिस्सों में बना है
  • एक अनुकूली classification framework जो retraining के बिना नई जटिलता श्रेणियां सीख सकता है
  • Pivotal Token Search का open source implementation

बेंचमार्क परिणाम और लागू होने का दायरा

• DeepSeek-R1-Distill-Qwen-1.5B में निम्नलिखित परिणाम दिखे
  • GPQA-Diamond: 31.06%, जो 21.72% बेसलाइन के मुकाबले सापेक्ष 43% सुधार है
  • MMLU-Pro: 26.38%, जो 25.58% बेसलाइन से अधिक है
  • baseline approach की तुलना में कम tokens इस्तेमाल हुए
• AutoThink को व्यापक रूप से लोकल reasoning models पर लागू किया जा सकता है
  • उदाहरण मॉडल: DeepSeek, Qwen, custom fine-tuned models
  • API निर्भरता नहीं
• संबंधित सामग्री
  • Technical paper
  • Code and examples
  • PTS implementation

[GN⁺]

Hacker News राय

• मैं यह स्पष्ट करना चाहता हूँ कि AutoThink की प्रेरणा उस अनुभव से शुरू हुई, जब मैंने देखा कि मौजूदा reasoning models कंप्यूट संसाधनों को बर्बाद करते हैं—2+2 क्या है? जैसे बेहद आसान सवालों पर भी वे जटिल गणितीय प्रमाण जितना ही सोचने का समय खर्च करते हैं, और यह अक्षमता साफ दिखती है। हैरानी की बात यह रही कि मैं अलग से जिस adaptive classification पर प्रयोग कर रहा था—जो बिना retraining के नई categories सीख सकता है—उसे Microsoft के Phi-4 पेपर में open source किए गए Pivotal Token Search के साथ मिलाया, और फिर उसमें dynamic token budget allocation लागू किया, तो उम्मीद से कहीं बड़ा performance improvement मिला। वास्तव में औसतन इस्तेमाल किए गए tokens की संख्या कम हुई, क्योंकि आसान queries बहुत जल्दी पूरी हो गईं और अतिरिक्त computation केवल जटिल queries को मिला। कुछ तकनीकी बिंदु: steering vector हर pattern के लिए 1MB से छोटा है, इसलिए memory overhead लगभग नहीं के बराबर है; classification process केवल लगभग 10ms latency जोड़ती है, जो नगण्य है; और target layer का चुनाव महत्वपूर्ण है, जहाँ ज़्यादातर models में बीच की layers 15~20 सबसे अच्छे परिणाम देती हैं। जिन बातों पर मैं feedback चाहता हूँ—क्या किसी ने इसी तरह के adaptive approaches आज़माए हैं, reasoning patterns को और उपयोगी ढंग से steer करने के तरीके, और optimal target layer को अपने-आप detect करने के ideas। implementation या results पर कोई भी सवाल हो तो पूछें

  • अब ज़रूरी नहीं कि ऐसा ही हो। क्या आपने Gemini 2.5 Pro इस्तेमाल किया है? आसान सवालों पर वह लगभग सोचता ही नहीं, जबकि coding questions पर लंबा logic article जैसा जवाब लिखता है। लगता है o3 भी ऐसा ही करता है

  • बधाई! LLM efficiency पर किसी भी तरह की कोशिश का मैं दिल से स्वागत करता हूँ। अभी तक मैं Mac Mini M4 पर MLX model से केवल सरल queries संभालता रहा हूँ, और जटिल queries को Nvidia 4090 पर भेजता हूँ—M4 की efficiency Nvidia की तुलना में सचमुच चौंकाने वाली है। मुझे लगता है Apple का MLX की दिशा में जाना सही है। मैं AutoThink के बारे में और पढ़ूँगा और इसे अपने personal workflow में integrate करने की भी योजना है

  • मेरा मानना है कि user prompt के बाद non-reasoning model का जवाब डालने वाला तरीका आज़माने लायक है—उदाहरण के लिए: “नीचे non-reasoning model ने यह सोचा है: ... क्या यही user को चाहिए?” जब non-reasoning version ही पर्याप्त हो, तब reasoning model भी शायद अपना जवाब और तेज़ी से तय कर सके

  • Claude Sonnet 3.5 में भी—और वह न तो सबसे नया 3.7 है, न 4—query complexity के अनुसार processing time साफ बदलता है। यानी वह भी dynamically processing time adjust करता दिखता है

• मुझे जिज्ञासा है कि सवालों को जटिल और सरल कैसे classify किया जा सकता है। जो सवाल ऊपर-ऊपर से आसान लगे, वह वास्तव में बहुत कठिन भी हो सकता है। उदाहरण के लिए, x³+y³+z³=42 का integer solution एक ऐसा सवाल है, जिस पर 100 साल से अधिक के बराबर computation resources लगे। या x/(y+z)+y/(z+x)+z/(x+y)=4 जैसी equation भी ऊपर से सरल दिखती है, लेकिन इसके ऐसे बहुत बड़े integer solutions हैं जिनके लिए elliptic curve theory चाहिए। समाधान संदर्भ लिंक

  • किसी problem की difficulty classify करना अपने-आप में अलग skill है—इसे वास्तविक solving ability से अलग सीखा जा सकता है। उदाहरण के लिए, ऊपर वाली equation को देखकर तुरंत तीन कठिन पहलू पहचानने चाहिए: integer domain, 3 variables, और cubic equation। ये तीनों एक साथ आ जाएँ तो difficulty बहुत बढ़ जाती है। अगर real numbers या complex numbers हों, variables कम हों, या degree कम हो, तो सवाल काफी आसान हो जाता है। हाँ, इसका मतलब यह नहीं कि सवाल ज़रूर कठिन ही होगा, लेकिन यह unsolved problem भी हो सकती है। मैं खुद इसे वास्तव में solve नहीं कर सकता, लेकिन मैंने इतनी समझ ज़रूर विकसित की है कि जानकारी कहाँ ढूँढनी है, इसलिए मुझे तुरंत एहसास हो जाता है कि यह बहुत मुश्किल है। शायद LLM भी ऐसे hints सीखकर, बिना असल में solve किए, problem difficulty classify करना सीख सकते हैं—या शायद वे यह पहले से जानते हों

  • इस संदर्भ में query difficulty को इस आधार पर परिभाषित किया गया है कि सही जवाब देने के लिए model ने ground-truth datasets (जैसे GSM8k) पर कितने tokens खर्च किए। adaptive classifier को इसी dataset पर train किया जाता है और inference के समय classification के लिए इस्तेमाल किया जाता है

• जब Claude 3.7 में extended thinking toggle आया था, तब मैंने भी इसी तरह का autothink POC बनाया था—यहाँ तक कि नाम भी autothink ही है
  github.com/NiloCK/autothink
  think-toggles-are-dumb ब्लॉग
  मेरे version में LLM पहले query difficulty को 0~100 score देता है, फिर उसी score के हिसाब से सोचने का budget linearly allocate किया जाता है। OP के काम की तुलना में यह जाहिर है कि सरल है, लेकिन quantitative results देखना सचमुच खुशी की बात है—बहुत बढ़िया काम!

• यह मुझे एक obvious optimization लगता है, इसलिए हैरानी होती है कि यह बदलाव अभी तक पहले क्यों नहीं हुआ। इसे अच्छी तरह समझाना और खुद implement करना, दोनों ही प्रभावशाली हैं

• QwQ या Qwen 3 जैसे reasoning models में, सच कहूँ तो मैंने results improve करने में ज़्यादा समय नहीं लगाया, बल्कि अलग-अलग prompts के साथ reasoning token output को constrain करने की कोशिश की। Gemma 3 27B QAT reasoning model नहीं है, लेकिन LLM chains या routes में इस्तेमाल करते समय instruction-following में बहुत अच्छा है, इसलिए इसे pre-classification या language optimization के लिए लगाया जा सकता है और बाद के चरण में असली reasoning के लिए इस्तेमाल किया जा सकता है। कई thinking tags के बीच intermediate answers को interleave करना भी संभव है। ऐसे model experiments में, सोचने वाले tokens को निष्कर्ष से अलग, problem solving के बीच के stepping-stone tokens के रूप में परिभाषित किया जाता है। कुछ tokens या विशेष अभिव्यक्तियों के इस्तेमाल को प्राथमिकता देने के निर्देश देने पर आम तौर पर results बेहतर हुए हैं, और AutoThink का dataset से सबसे अच्छा काम करने वाले tokens को अपने-आप चुनना शायद एक अधिक सामान्य और प्रभावी optimization साबित हो सकता है। हालाँकि, अगर pivot tokens बहुत ज़्यादा इस्तेमाल हों, तो benchmark questions पर overfitting का जोखिम है, इसलिए यह तरीका कितनी अच्छी तरह generalize करता है, यह अभी और देखना होगा। व्यक्तिगत रूप से मैं सावधानीपूर्वक word/token selection को कम लागत वाली लेकिन उच्च-प्रभाव optimization मानता हूँ, और AutoThink की generalization क्षमता को लेकर उत्साहित हूँ

• यह बहुत शानदार है कि छोटे models की वजह से छोटी teams और individual researchers भी अब बड़े AI labs से कम नहीं, बल्कि उतने ही आसानी से innovative approaches या experiments को साबित कर सकते हैं। जैसे-जैसे SML (Small Language Model) की प्रतिस्पर्धात्मकता बढ़ेगी, on-device संभव चीज़ों का दायरा कल्पना से कहीं अधिक फैल जाएगा

  • small language models (SML) की जगह शायद सही शब्द SLM होना चाहिए

• अगर आप दूसरों के लिए model host कर रहे हैं, तो बेहद सरल सवालों पर compute resources बचाना बहुत उपयोगी है। इस स्थिति में यह नुकसान हो सकता है कि model ऐसे सवालों को कुछ कम ध्यान से ले, लेकिन उसकी कीमत मैं नहीं चुकाता। इसके उलट, अगर मैं अपने PC पर खुद model चला रहा हूँ, तो GPU पर पहले ही बड़ा खर्च कर चुका हूँ, इसलिए मैं उपलब्ध संसाधनों का पूरा उपयोग करना चाहूँगा—सरल queries पर भी computation कम करना मुझे शायद पसंद न आए

• सोचने लायक अच्छा बिंदु है! हम भी AI crawler design में इस बात पर अंदरूनी चर्चा करने वाले हैं कि किसी site पर जाते समय वहाँ ज़्यादा queries भेजनी हैं या कम, यह dynamically पहचानना चाहिए। संदर्भ के लिए, हम samaritanscout.org हैं, जो अलग-अलग nonprofit sites पर पोस्ट किए गए सभी स्थानीय volunteer opportunities को एक जगह इकट्ठा करने वाला search engine project है

• मैं LLM और AI क्षेत्र में बहुत हाल ही में आया हूँ, लेकिन इस project में मेरी गहरी रुचि है। यह बात कि AutoThink समस्या की कठिनाई के अनुसार computation effort को adjust करके AI को ज़्यादा समझदारी से सोचने देता है, मुझे सहज रूप से बहुत प्रभावशाली लगती है—जैसे इंसान 2+2 जैसी चीज़ तुरंत हल कर देता है और केवल कठिन समस्याओं पर गंभीरता से सोचता है। token budget या steering vector जैसे तकनीकी पहलुओं को मैं अच्छी तरह नहीं समझता, लेकिन तेज़ और ज़्यादा smart दोनों बन जाने वाला यह तरीका मुझे आकर्षित करता है। मैं इसे आगे भी देखता रहूँगा

• मेरा मानना है कि LLMs के संदर्भ में सोचना या reasoning जैसे शब्दों का उपयोग न करना बेहतर होगा—इन दोनों शब्दों के अपने खास अर्थ और दार्शनिक संदर्भ हैं, जबकि वास्तव में LLM ऐसा सोचते या तर्क नहीं करते, बल्कि सिर्फ़ ज़्यादा computation (processor time) लगाकर output generate करते हैं

  • वह बहस अब निकल चुकी है। जैसे पहले computer शब्द इंसानी गणक के लिए इस्तेमाल होता था, लेकिन अब उसका अर्थ पूरी तरह मशीन हो गया है, वैसे ही यहाँ भी शब्द का अर्थ बदल गया है

  • यह ping जैसा है—जब हम किसी IP address को ping करते हैं, तो सचमुच किसी धातु के ढाँचे पर ध्वनि तरंग नहीं भेज रहे होते, फिर भी यह वास्तविक व्यवहार के अनुरूप एक रूपक के तौर on उपयोगी है। अगर रूपक काम का हो, तो उसका वास्तविकता से 1:1 मेल खाना ज़रूरी नहीं होता

  • मेरा worldview मूल रूप से materialist और deterministic है। फिर भी रोज़मर्रा की ज़िंदगी में मैं existentialism और थोड़ी spiritual संवेदनशीलता भी साथ रखता हूँ। व्यावहारिक नज़रिए से देखें तो ऐसे tools को अस्थायी रूप से anthropomorphic गुण दे देने से बातचीत आसान हो जाती है और tool को सहज रूप से समझना भी सरल हो जाता है। यह तरीका कभी-कभी अपनी सीमाएँ दिखाता है, लेकिन ऐसे समय में ज़्यादा analytical framework पर लौटना आसान रहता है—मैं ऐसा मानता हूँ