पुराने रिसर्च आइडिया पर Autoresearch चलाना

 (ykumar.me)
4 पॉइंट द्वारा GN⁺ 2026-03-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Autoresearch सिस्टम एक constraint optimization loop संरचना है जिसमें LLM एजेंट train.py को बार-बार संशोधित करके प्रदर्शन सुधारता है, और hypothesis बनाने से लेकर evaluation तक का स्वचालित चक्र चलाता है
  • प्रयोग container-आधारित sandbox environment में चलाए गए, जिससे network access और arbitrary code execution को रोका गया
  • Ukiyo-eVG dataset का उपयोग करते हुए लगभग 11,000 जापानी woodblock print images और annotation जानकारी को training में इस्तेमाल किया गया, और CLIP-आधारित मॉडल ने Mean Rank 34.30, R@5 लगभग 53% प्रदर्शन हासिल किया
  • मुख्य सुधार temperature parameter को ढीला करने (-113 Mean Rank) और hyperparameter tuning (-30 Mean Rank) से आए, और एक दिन में 42 प्रयोगों में 13 commits के जरिए 54% प्रदर्शन सुधार दर्ज हुआ
  • LLM एजेंट स्पष्ट रूप से परिभाषित search space में प्रभावी रहा, लेकिन structural changes के बाद अस्थिरता बढ़ी, जिससे पूर्ण autonomous research की सीमाएं सामने आईं

मुख्य आइडिया

  • Autoresearch LLM एजेंट-केंद्रित constraint optimization loop संरचना है, जिसमें एजेंट train.py को संशोधित करते हुए evaluation metrics को बार-बार बेहतर बनाता है
    • एजेंट program.md में दिए गए निर्देश पढ़ता है और scratchpad.md को working notes की तरह इस्तेमाल करके प्रयोग प्रक्रिया दर्ज करता है
  • खोज कई phases में बनी है; शुरुआत hyperparameter tuning से होती है, फिर छोटे structural changes, और बाद में कम से कम constraints के साथ free exploration तक बढ़ती है
  • पूरा loop hypothesis बनाना → code संशोधन → training → evaluation → commit या rollback → दोहराव की चक्रीय संरचना में डिज़ाइन किया गया है
  • हर experiment को लगभग 5 मिनट के भीतर पूरा करने की सीमा रखी गई, ताकि तेज़ iteration हो और overfitting से बचाव हो
  • एजेंट समय सीमा के भीतर train.py को स्वतंत्र रूप से संशोधित कर सकता है

  • Sandboxing

    • arbitrary code execution के जोखिम को रोकने के लिए training loop को container environment में चलाया गया और network access बंद किया गया
    • run.sh पूरा experiment flow संभालता है, और Claude Code केवल train.py और program.md को ही संशोधित कर सकता है
    • सीधे Python चलाना, pip install करना, network access, git push आदि सभी सीमित थे
    • संबंधित implementation GitHub repository में सार्वजनिक है

Dataset

  • मूल research में इस्तेमाल हुए medical X-ray dataset तक पहुंच न होने के कारण, नया Ukiyo-eVG dataset इस्तेमाल किया गया
    • इसमें लगभग 11,000 जापानी woodblock print images और phrase-bounding box annotations शामिल हैं
    • bounding boxes को Gaussian heatmaps में बदलकर model input में जोड़ा गया, और यह मूल eCLIP paper के expert attention mechanism जैसा तरीका था
  • heatmaps मॉडल को खास क्षेत्रों पर ध्यान केंद्रित करने के लिए प्रेरित करते हैं

Claude Code के साथ प्रयोग सेटअप

  • Claude Code ने मौजूदा research code को नवीनतम Python environment के लिए upgrade किया, नया dataset loading और experiment loop scaffolding लिखा
  • cross-validation splits, evaluation logic, और program.md के शुरुआती ideas सेट किए गए
  • evaluation metric के रूप में Mean Rank इस्तेमाल किया गया, जबकि अंतिम रिपोर्ट में Recall@K भी साथ दिया गया
    • Mean Rank का उपयोग सहज निर्णय के लिए किया गया, लेकिन यह भी कहा गया कि outliers के प्रति कम संवेदनशील Median Rank शायद अधिक उपयुक्त होता
  • Model configuration: CLIP backbone के रूप में ViT-Small(22M) + DistilBERT(66M) + HeatmapProcessor, कुल लगभग 90M parameters
    • training: 800 steps (लगभग 3 मिनट/experiment, RTX 4090 पर)
    • evaluation: 1,000-image test set पर Mean Rank और Recall@K मापा गया
    • baseline performance: Val Mean Rank 344.68, img→txt R@1 17.2%, txt→img R@1 16.5%

प्रयोग परिणाम

  • एक दिन में कुल 42 experiments हुए, जिनमें 13 commits और 29 rollbacks किए गए
    • Mean Rank 344.68 से घटकर 157.43 हुआ, यानी 54% कमी
  • पूरे dataset पर अंतिम training करने पर, test score validation score से अधिक निकला
    • यह संकेत देता है कि छोटे 800-step experiments underfitting की स्थिति में थे
  • अंतिम test performance: Mean Rank 34.30, img→txt R@5 53.0%, txt→img R@5 51.4%

मुख्य सुधार बिंदु

  • Temperature clamp में बदलाव (-113 Mean Rank)

    • code में मौजूद trainable temperature parameter को 2 पर fix किया गया था, जिसे एजेंट ने ढीला किया और प्रदर्शन में बड़ा सुधार मिला
    • पूरे सुधार में यह सबसे बड़ा single effect था

  • Optuna++ (-30 Mean Rank)

    • इसके बाद के सुधार मुख्य रूप से hyperparameter tuning से आए
    • projection dimension बढ़ाने और learning rate को दोबारा समायोजित करने से अतिरिक्त 30-point सुधार मिला
    • इंसान द्वारा बार-बार किए जाने वाले उबाऊ काम एजेंट ने अधिक तेज़ और व्यवस्थित ढंग से किए

  • घटते प्रतिफल का चरण

    • चरण 4 (structural changes) के बाद LLM की hypothesis success rate तेज़ी से घटी
    • attention mechanism बदलने या moonshot ideas आज़माने की अधिकांश कोशिशें विफल रहीं
    • खोज के अंतिम हिस्से में कई प्रयास अधिक random हो गए

  • Sandbox का महत्व

    • Claude Code कभी-कभी permissions भूलकर गलत bash calls करने की कोशिश करता था, या training के इंतज़ार के दौरान loop रोक देता था, यानी अस्थिर व्यवहार दिखाता था
    • पूरी तरह autonomous execution की अब भी सीमाएं हैं

समापन अवलोकन

  • पूरी प्रक्रिया में शुरुआती 90% हिस्सा सुचारु रहा, लेकिन अंतिम 10% में काफी हस्तक्षेप की ज़रूरत पड़ी
  • LLM एजेंट स्पष्ट रूप से परिभाषित search space के भीतर प्रभावी रूप से ML research कर सकता है
  • Autoresearch का commit-rollback loop एक structured exploration strategy के रूप में उपयोगी है
  • लेकिन जैसे ही इसे अज्ञात क्षेत्रों तक बढ़ाया जाता है, optimization loop अस्थिर हो जाता है
  • संभव है कि प्रति experiment केवल एक बदलाव की अनुमति देने वाली सीमा बड़े आइडिया exploration के लिए बहुत कड़ी रही हो
    • भविष्य में planning phase जोड़ना या subagents लाना संभावित सुधार दिशाओं के रूप में सुझाया गया
  • experiment समाप्त होने के बाद, Claude Code के साथ सहयोग रोज़मर्रा की सामान्य स्थिति में लौटते हुए समाप्त हुआ

आभार

  • Ukiyo-eVG dataset: लगभग 11K जापानी woodblock print images और phrase-bounding box annotations शामिल
  • Autoresearch: Andrej Karpathy के मूल आइडिया पर आधारित

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

1 टिप्पणियां

 
GN⁺ 2026-03-24
Hacker News की राय

  • अगर मुख्य लिंक धीमा हो तो archive.is version आज़माने का सुझाव दिया गया

  • मैं अक्सर LLM का उपयोग मौजूदा रिसर्च को एक्सप्लोर करने या किसी समस्या को अलग तरीके से सोचने के लिए करता हूँ
    नतीजों का 90% मेरे डोमेन के काम का नहीं होता, लेकिन बाकी 10% काफ़ी उपयोगी रहा
    लेकिन agent रखकर LLM की सुझाई हर चीज़ को सच में आज़माना बहुत महँगा ($$$) पड़ता है
    सुझावों की सूची में अक्सर ऐसे niche libraries होती हैं जिनका मेंटेनेंस नहीं हो रहा
    दूसरी ओर, कंपनी के “expert consultants” भी इसी तरह के बेतुके सुझाव दे देते हैं, इसलिए अच्छा हो अगर कोई agent उनकी जगह यह झेले

    • agent की वैल्यू इस बात में है कि यूज़र के आराम करते समय वह अपने-आप experiment दोहराता रह सकता है
      लेकिन इसका मतलब तभी है जब एक test जल्दी हो जाए। मेरे काम में एक test में आधा दिन लग जाता है, इसलिए इसे रात भर चलाना मुश्किल है
    • जानना चाहूँगा कि आप किस डोमेन में काम करते हैं
    • मुझे लगता है LLM उन छोटे वाक्यों या उन हिस्सों में उपयोगी है जिन्हें याद रखना झंझट हो और गलत भी हो जाएँ तो फ़र्क न पड़े
      जो लोग MCP server या AGENTS.md जैसी चीज़ें सेट करते हैं, उन्हें देखकर लगता है कि LLM जैसा प्रचार किया जाता है वैसा काम नहीं करता
      किसी खास workflow के लिए इसे अच्छे से tune किया जाए तो यह शानदार हो सकता है, लेकिन यह scale कर पाएगा या नहीं, इस पर शक है
      अगर training और infrastructure को भारी funding सहारा न दे, तो क्या यह टिकाऊ business model बन पाएगा?
    • लागत समस्या हो सकती है। मैं Claude Code हल्के तौर पर उपयोग करता हूँ, और Max plan में भी tokens लगभग खत्म ही नहीं होते

  • “agent ने hyperparameter optimization algorithm की तरह व्यवहार किया” यह अभिव्यक्ति प्रभावशाली लगी
    असली बात program.md नाम की एक system prompt file है, जिसमें “train.py सुधारो → training चलाओ → evaluation करो → result दर्ज करो” का दोहराव होता है
    बाकी तो बस कोई भी मनमाना ML model है

  • चल रहे code को LLM को देकर bug fix, performance measurement, और test coverage evaluation दोहराना हमारी टीम का standard approach है
    हर iteration में अलग model इस्तेमाल करने से नया नज़रिया मिलता है, यह अच्छा लगा

    • सोच रहा हूँ कि क्या इस तरीके को किसी खास language या framework के लिए specialized local LLM training पर लागू किया जा सकता है

  • समझ नहीं आया कि “Autoresearch” इतना चर्चा में क्यों आ गया
    मुझे हमेशा लगता था कि AI/ML में bottleneck data quality या computing resources होते हैं, नहीं पता यह उन्हें बेहतर करता है या नहीं

    • सच कहें तो ऐसी कोशिशें पहले भी होती रही हैं। AutoML उसका एक उदाहरण है, लेकिन व्यवहार में वह बहुत सफल नहीं हुआ
      Bayesian optimization या Gaussian Process जैसे approaches भी थे, लेकिन अंत में random search ज़्यादा बेहतर निकला
      फ़र्क यह है कि LLM साहित्य पढ़कर कॉमन-सेंस आधारित reasoning कर सकता है
      यह परफेक्ट नहीं है, लेकिन मौजूदा तरीकों से बेहतर होने की संभावना है
    • फ़र्क यह भी है कि यह सिर्फ़ hyperparameter tuning से आगे जाकर non-parametric structural changes भी कर सकता है
      यह पूरी तरह नया विचार नहीं है, लेकिन उम्मीद यही लगती है कि यह कम brute-force होगा
    • “Swarm optimization” जैसी पुरानी तकनीकें भी हैं, लेकिन LLM की खासियत यह है कि वह पुरानी रिसर्च सीखकर महत्वपूर्ण आयामों पर ध्यान केंद्रित कर सकता है
      यानी जो रिसर्च कोई पहले कर चुका है, LLM उसका उपयोग कर सकता है
    • “data या compute bottleneck हैं” इस बात से सहमत नहीं हूँ
      ML का मूल उद्देश्य वही input X लेकर बेहतर function mapping खोजना है
      सिर्फ़ compute बढ़ाने से समस्या हल नहीं होती
    • आखिरकार Autoresearch का मतलब है सोचने की प्रक्रिया ही LLM को सौंप देना

  • नतीजे के तौर पर यह काम कर गया। LLM ने bugs ढूँढे और optimization भी किया

    • लेकिन असल में ज़्यादातर सुधार bug fixes + Optuna tuning की वजह से थे
      ऐसी चीज़ें Claude Code से भी जल्दी की जा सकती हैं
      लगता है Autoresearch की असली वैल्यू architecture exploration में होगी
      जानना चाहूँगा कि क्या किसी ने इसे exploratory modeling में इस्तेमाल किया है

  • commit log (GitHub लिंक) देखा तो ज़्यादातर काम hyperparameter tuning ही था
    उस हिसाब से tokens पर खर्च ($$$) बेकार लगा

    • अगर Autoresearch में cost estimation और ranking step जोड़ दिया जाए ताकि इंसान review के बाद execution करे, तो यह ज़्यादा efficient हो सकता है
      LoRa adapter के ज़रिए cost feedback देने जैसे सुधार भी संभव हैं
    • सच तो यह है कि Optuna या skopt जैसे open source tools से GPU के बिना भी यह किया जा सकता है

  • मूल paper में medical X-ray data इस्तेमाल हुआ था, लेकिन access न होने की वजह से उसकी जगह Ukiyo-eVG (जापानी woodblock prints की 11K images) इस्तेमाल की गई
    यह बदलाव थोड़ा अजीब लगा। मुफ़्त medical image datasets तो Cancer Imaging Archive में भी काफ़ी हैं

    • बात सही है। लेकिन medical data किसी agent को सौंपना बोझिल लगा, और मैं domain transfer भी आज़माना चाहता था

  • मैं चाहता था कि कोई ऐसा experiment करे, इसलिए यह देखकर अच्छा लगा कि किसी ने सच में किया
    “training खत्म होने का इंतज़ार करते-करते थककर बातचीत बंद कर दी” वाला हिस्सा मज़ेदार था
    नतीजे साझा करने के लिए धन्यवाद

    • जवाब में धन्यवाद कहा गया और बताया कि पढ़कर मज़ा आया

  • यह automated research से ज़्यादा structured trial-and-error जैसा लगता है
    आखिर में सबसे अहम चीज़ evaluation metric की quality है। अगर वह कमज़ोर है, तो आप बस गलत दिशा में और तेज़ी से optimize करेंगे

    • अच्छी fitness function design करना पहले भी मुश्किल था और आज भी है
    • एक राय यह भी है कि आखिर यही तो scientific methodology है