FunSearch: LLM का उपयोग करके गणित और विज्ञान में नई खोजें

(deepmind.google)

1 पॉइंट द्वारा GN⁺ 2023-12-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Google DeepMind का FunSearch pre-trained LLM और automatic evaluator को मिलाकर, गणित और कंप्यूटर साइंस की समस्याओं में verify किए जा सकने वाले नए समाधान code के रूप में खोजता है
LLM नए program बनाता है और automatic evaluator उन्हें score देता है, फिर high-score program को वापस pool में डालकर evolutionary iteration के जरिए समाधान बेहतर किए जाते हैं
cap set problem में इसने कुछ settings में अब तक मिले सबसे बड़े cap set खोजे, और ऐसे scale पर भी performance दिखाई जिसे मौजूदा state-of-the-art computational solvers संभालना मुश्किल मानते हैं
यही approach online bin packing पर भी लागू हुई, जहां data characteristics के हिसाब से tuned program ने existing heuristics की तुलना में उतने ही items को कम bins में pack किया
Output इंसानों द्वारा पढ़े जा सकने वाले छोटे programs होते हैं, इसलिए researchers समाधान की structure की समीक्षा कर सकते हैं और problem setting को बेहतर करने वाले human-AI collaboration में इसका उपयोग कर सकते हैं

FunSearch का मूल आइडिया

FunSearch गणित और कंप्यूटर साइंस में नए समाधान खोजने के लिए computer code में लिखे functions को explore करता है
नाम इस बात से आया है कि यह functions की खोज करता है
क्योंकि LLM गलत factual जानकारी बना सकते हैं, FunSearch creative proposals देने वाले LLM को automatic evaluator के साथ जोड़ता है ताकि गलत ideas को filter किया जा सके
यह कठिन open scientific और mathematical problems में LLM से नई discovery करने का पहला उदाहरण माना जाता है

Evolutionary iteration structure

User पहले problem description को code के रूप में लिखता है
- इसमें program को evaluate करने की प्रक्रिया शामिल होती है
- program pool initialize करने के लिए seed program भी साथ रखा जाता है
हर iteration में current program pool का एक हिस्सा LLM को input दिया जाता है
- LLM existing program के आधार पर नया program generate करता है
- नया program automatic execution और evaluation से गुजरता है
- high-score program को फिर से program database में add किया जाता है
User कभी भी अब तक मिला highest-score program निकाल सकता है
FunSearch ने Google PaLM 2 का उपयोग किया, लेकिन code पर trained अन्य LLMs के साथ भी compatible है
कठिन combinatorial problems से निपटने के लिए search structure को भी मजबूत किया गया
- problem के general knowledge से शुरू करके नई discovery के लिए जरूरी core ideas पर focus करता है
- ideas की diversity बढ़ाकर stagnation से बचता है
- evolution process को parallel run करके efficiency बढ़ाता है

Cap set problem में परिणाम

पहला application cap set problem था, जिसने दशकों से कई research क्षेत्रों के mathematicians को परेशान किया है
यह problem high-dimensional grid में ऐसे points के set, यानी cap set, का maximum size खोजने की चुनौती है जिसमें कोई भी तीन points एक straight line पर न हों
यह extremal combinatorics की अन्य समस्याओं के लिए model की भूमिका भी निभाता है
संभावित cases की संख्या तेजी से universe के atoms की संख्या से भी बड़ी हो जाती है, इसलिए brute-force computation काम नहीं करता
FunSearch ने program के रूप में solutions generate करके, कुछ settings में अब तक मिले सबसे बड़े cap set खोजे
यह परिणाम पिछले 20 वर्षों में cap set size में सबसे बड़ी increase के बराबर है, और problem scale उन क्षेत्रों में भी बेहतर performance दिखाता है जो existing state-of-the-art computational solvers की current capability से आगे हैं
इसने दिखाया कि intuition बनाना कठिन होने वाली combinatorial problems में existing results से आगे जाया जा सकता है, और आगे चलकर समान combinatorics theory problems और communication theory जैसे क्षेत्रों तक इसके बढ़ने की संभावना है

इंसानों द्वारा समझे जा सकने वाले छोटे programs

FunSearch सिर्फ answer lists देने वाला black box नहीं है, बल्कि ऐसे programs generate करता है जो दिखाते हैं कि solution कैसे constructed है
यह science के उस सामान्य तरीके से भी मेल खाता है जिसमें नई discoveries या phenomena को generation process के रूप में explain किया जाता है
FunSearch कम Kolmogorov complexity वाले concise programs में expressed solutions को prefer करता है
- Kolmogorov complexity उस सबसे छोटे computer program की length है जो solution output करता है
- छोटे programs बहुत बड़े objects को describe कर सकते हैं, जिससे needle-in-a-haystack जैसे large-scale problems तक scale करने में मदद मिलती है
- Program output researchers के लिए समझना आसान होता है
कुछ high-scoring output code में दिलचस्प symmetry देखी गई, और इसके आधार पर problem setting को refine करके बेहतर solutions मिले
Jordan Ellenberg ने कहा कि FunSearch “attack strategy विकसित करने का पूरी तरह नया mechanism” देता है, और generated solutions numbers की list की तुलना में conceptually कहीं अधिक rich हैं

Online bin packing पर application

FunSearch को practical computer science problem bin packing पर भी apply किया गया
Bin packing अलग-अलग size के items को यथासंभव कम bins में रखने की problem है
Real-world applications में container loading और datacenters में cost घटाने के लिए compute jobs allocation जैसे examples शामिल हैं
Online bin packing को आमतौर पर human experience पर आधारित heuristics से handle किया जाता है
- Size, timing और capacity अलग होने वाली specific situations के लिए ruleset खोजना मुश्किल हो सकता है
FunSearch cap set problem से बहुत अलग problem होने के बावजूद आसानी से set up हो गया, और data characteristics के हिसाब से automatically adjusted programs बनाए
Generated program ने existing heuristics की तुलना में उतने ही items को कम bins में pack किया
Neural networks या reinforcement learning जैसे अन्य AI approaches भी कठिन combinatorial problems में effective हो सकते हैं, लेकिन deployment के लिए काफी resources की जरूरत हो सकती है
FunSearch inspect और deploy करने में आसान code output करता है, इसलिए यह ऐसे solutions बना सकता है जिन्हें अलग-अलग real-world industrial systems में शामिल किया जा सके

2024 update और expansion

दिसंबर 2024 में प्रकाशित arXiv report ने दिखाया कि FunSearch approach का उपयोग combinatorial competitive programming में human performance को amplify करने के लिए किया जा सकता है
Codeforces जैसी traditional coding competitions time और memory constraints के भीतर classic algorithm problems के complete solutions मांगती हैं
Combinatorial competitions किसी एक सही answer के बजाय, संभव सबसे अच्छे approximate solution को खोजने वाली complex problems से deal करती हैं
यह approach top percentile participants द्वारा खोजे गए solutions से बेहतर solutions बना सकता है
इसमें collaboration structure इस्तेमाल होती है जहां human programmer solution code का backbone लिखता है, और LLM उसे control करने वाले functions को creatively evolve करता है
General LLMs के improve होने के साथ code-specialized model की जरूरत नहीं रही, और Gemini 1.5 Flash को आधार के रूप में इस्तेमाल किया जा सकता है
Competitive programming के अलावा, FunSearch का उपयोग Bayesian optimization framework में functions को बेहतर optimize करने का तरीका खोजने में भी किया गया

LLM-based discovery की दिशा

FunSearch दिखाता है कि अगर LLM की hallucination रोकने की व्यवस्था हो, तो LLM का उपयोग नई mathematical discovery के साथ-साथ महत्वपूर्ण real-world problems के संभावित solutions generate करने में भी किया जा सकता है
Science और industry की पुरानी या नई समस्याओं में, LLM-based तरीकों से effective और customized algorithms generate करना आम हो सकता है
FunSearch LLMs की overall progress के साथ improve हो सकता है, और अलग-अलग scientific और engineering problems तक अपनी capability बढ़ाने की दिशा में expand किया जाएगा

1 टिप्पणियां

GN⁺ 2023-12-15

Hacker News की राय

यहाँ LLM कितना ज़रूरी है, यह जानने की जिज्ञासा है
देखने में तो लगता है कि LLM की भूमिका बस दिए गए type signature का पालन करने वाले Python function जैसे कुछ भरोसेमंद लगने वाले विकल्प बनाना है
लेकिन ऐसा भी लग सकता है कि LLM के बिना भी दिए गए type signature को संतुष्ट करने वाले सही random Python function बनाए जा सकते हैं। यह [1] जैसी exercise होगी, बस कहीं अधिक जटिल language के लिए, और संभव है कि constrained language लिखने में आसान हो। PushGP [2] जैसा तरीका भी काम कर सकता है
सवाल ये हैं: (1) यहाँ LLM की अतिरिक्त value क्या है, क्या यह convergence के लिए ज़रूरी evaluations की संख्या को बहुत घटाता है, और अगर हाँ तो कैसे, (2) क्या इसी समस्या पर दूसरी genetic programming techniques कम competitive हैं और कम fitness वाले solutions देती हैं, (3) अगर अधिक पारंपरिक genetic programming समान fitness तक पहुँच जाए तो LLM training cost को शामिल करने पर कुल compute cost में क्या अंतर पड़ता है
[1] http://www.davidmontana.net/papers/stgp.pdf
[2] https://faculty.hampshire.edu/lspector/push.html
- executable programs का state space, उपयोगी programs की तुलना में बहुत बड़ा होता है
  सिर्फ बंदर और typewriter से काम नहीं चलेगा; यहाँ Palm2 इसलिए इस्तेमाल होता है क्योंकि candidates random नहीं बल्कि plausible होने चाहिए। मकसद बेतुके programs पर समय बर्बाद न करना है
  इसके अलावा random program generation पर आधारित genetic algorithms में cold start समस्या बहुत बड़ी होती है। अगर सभी candidates की fitness 0 हो, तो शुरुआत में, और शायद अंत तक भी, प्रगति न होने की आशंका रहती है
- खोजा गया function यहाँ है: https://github.com/google-deepmind/funsearch/blob/main/cap_s...
  मैं genetic algorithms का बहुत बड़ा जानकार नहीं हूँ, लेकिन इतना तो नहीं लगता कि genetic algorithm इसे खोज ही न पाए। हाँ, अगर किसी ने वास्तव में इसे बहुत आज़माया हो, तो यह जानकर हैरानी होगी
  दूसरी ओर, paper के appendix A.2 में दिखाया गया है कि LLM के बिना genetic approach में LLM approach की तुलना में काफी अधिक manual design की ज़रूरत पड़ सकती है
- genetic algorithms, constraints लगाने पर भी, बहुत सारे अर्थहीन programs बना देते हैं। पर्याप्त मेहनत से syntax को तो ज़्यादातर सही किया जा सकता है, लेकिन बात वहीं तक रहती है
  यहाँ LLM जो फ़र्क लाता है, वह यह है कि वह संभावित mutation space को मोटे तौर पर semantic रूप से plausible programs तक सीमित कर देता है
  तीसरे बिंदु पर, trained LLM बहुत सारे उद्देश्यों में उपयोगी होते हैं, इसलिए scratch से उन्हें train करने की लागत को amortize करने पर वह उतनी बड़ी नहीं रह जाती। FunSearch framework के हिसाब से fine-tune करने की अतिरिक्त लागत हो सकती है, लेकिन fine-tuning cost काफ़ी छोटी होती है। इस framework में इसका उपयोग केवल genetic programming की तुलना में फ़ायदेमंद होने की संभावना है
- inductive program synthesis में search space इतना बड़ा है कि यह दशकों से लगभग रुका हुआ था। वजह यह थी कि बहुत छोटे programs से आगे बढ़ना मुश्किल था
  LLM search space को बहुत कम कर देते हैं। हाँ, वे कई बार उसे गलत दिशा में भी सीमित करते हैं, लेकिन उसके बाद inductive program synthesis से fine-tune और test किया जा सकता है। LLM के बिना, मेरी जानकारी में, यह तरीका फिलहाल संभव नहीं है, क्योंकि तब बहुत तुच्छ मामलों में भी अरबों पूरी तरह बेतुके programs को test करना पड़ेगा
- मुझे लगा था कि stochastic gradient descent और LLM, genetic programming की तुलना में कहीं तेज़ी से converge करते हैं। random search से तो वे निश्चित ही बहुत तेज़ हैं
महत्वपूर्ण संदर्भ यह है कि इस खोज ने दिखाया कि combinatorics में एक संख्या, जो पिछले साल तक 2.218~2.756 के दायरे में मानी जाती थी, अब 2.2202~2.756 के बीच है
यह सुधार तर्क-केंद्रित गणितीय proof से ज़्यादा, विशेष गुणों वाली खास sequences खोजकर हासिल किया गया
इसका मतलब यह नहीं कि यह कम rigorous है
यह examples बनाने का एक दिलचस्प और शायद उपयोगी तरीका है, और व्यावहारिक रूप से यह LLM के साथ genetic algorithm जैसा ही है
Subbarao की “self-play” पर टिप्पणी: https://twitter.com/rao2z/status/1728121216479949048
पोस्ट के अनुसार FunSearch, LLM से संचालित evolutionary method का उपयोग करता है ताकि high-scoring ideas को बढ़ावा दिया जा सके और आगे विकसित किया जा सके। ये ideas computer programs के रूप में होते हैं, इसलिए इनका automatic execution और evaluation संभव है
उपयोगकर्ता समस्या का वर्णन code के रूप में लिखता है। इस वर्णन में program को evaluate करने की प्रक्रिया और program pool को initialize करने के लिए seed programs शामिल होते हैं
हर iteration में FunSearch मौजूदा pool से कुछ programs चुनता है, LLM उन्हें रचनात्मक रूप से विस्तार देकर नए programs बनाता है, और नए programs का अपने-आप evaluation होता है। सबसे अच्छे programs फिर मौजूदा pool में वापस जोड़ दिए जाते हैं, जिससे self-improvement loop बनता है
web search में evaluator की भूमिका के लिए pplx.ai और phind.com का कुछ वैसा ही उपयोग होता है। आप सवाल पूछते हैं, देखते हैं कि वे कौन-से संदर्भ और web links लाते हैं, फिर सवाल को refine करते हैं या follow-up questions पूछते हैं ताकि और गहरी या अलग सामग्री मिल सके। reddit या Google खंगालने की तुलना में यह छिपे हुए रत्न ढूँढने में बेहतर काम करता है
Tech Twitter पर भी शानदार content बहुत है, इसलिए अब जब Grok सबके लिए खुला है, उम्मीद है लोग इसे research में आज़माएँगे
https://twitter.com/gfodor/status/1735348301812383906
ऐसा कहा गया है, “अगर DeepMind ने निर्णायक रूप से यह साबित कर दिया है कि neural networks सच में नया ज्ञान उत्पन्न कर सकते हैं, तो यह आग के बाद की सबसे महत्वपूर्ण खोज है।”
अगर सच में ऐसा है, तो हैरानी होती है कि फिर सब लोग इसी बारे में बात क्यों नहीं कर रहे। यह बात भी प्रभावशाली है कि यह PaLM 2 से किया गया, जो GPT-4 या Gemini से कम उन्नत है। लगता है कि अगर अगली कुछ पीढ़ियों के मॉडल इस तरीके का इस्तेमाल करें, तो वे क्या कर सकते हैं, यह बहुत बड़ा हो सकता है
- यहाँ कठिन काम evolutionary algorithm कर रहा है
  LLM बस random mutation operator की जगह ले रहा है, यानी उससे लगभग इतना ही कहा जा रहा है: “इस 20-line Python में कोई उचित बदलाव सुझाओ।” नए ज्ञान के निर्माण का श्रेय neural network को देना कुछ ज़्यादा उदार आकलन लगता है
  इसके अलावा, सिर्फ यह नहीं कि “बनाना कठिन और evaluate करना आसान” जैसी संरचना चाहिए, बल्कि यह समस्या की प्रकृति पर भी बहुत निर्भर है। जिस हिस्से को evolve करना है, उसे एक बहुत छोटे Python function में तोड़ा जा सकना चाहिए
- मैंने सचमुच ज़ोर से “वाह!” कहा
  यह कि LLM high-dimensional geometry में 20 साल से ठहरे हुए क्षेत्र के लिए नया समाधान खोज सकता है, यह सिर्फ चुराए गए training data के टुकड़ों को विश्वसनीय ढंग से जोड़ देने से बहुत आगे की बात है
  यह संकेत देता है कि अगर हम सही तरह से prompt करना और evaluate करना सीख लें, तो LLM की क्षमताओं में छिपी हुई गहराई है
  यह उम्मीदों को बहुत पीछे छोड़ देने वाला नतीजा है। कौन जानता है कि अगले prompt और random seed के पीछे कौन-सी खोज छिपी हो
- neural networks बहुत पहले से “नया ज्ञान” उत्पन्न कर सकते थे
  LLM भी ऐसा ही कर सकते हैं: https://www.nature.com/articles/s41587-022-01618-2
- पेपर के अनुसार FunSearch अभी उन समस्याओं पर सबसे अच्छा काम करता है जिनमें ये गुण हों
  a) efficient evaluator हो, b) सुधार की मात्रा को मापने वाला rich score feedback हो, यानी सिर्फ binary signal न हो, c) ऐसा ढांचा दिया जा सके जिसमें evolve करने के लिए कोई isolated हिस्सा हो
  उदाहरण के लिए theorem-proving generation इस दायरे से बाहर है। क्योंकि यह स्पष्ट नहीं है कि वहाँ पर्याप्त रूप से समृद्ध score signal कैसे दिया जाए
- यह उदाहरण नए algorithms या functions खोजने तक अपेक्षाकृत सीमित लगता है
  यह बेहतरीन काम है, लेकिन आग की खोज, और उसके बीच की असंख्य चीज़ों, जैसे electricity, की तुलना में उसी स्तर का नहीं लगता
संक्षेप में, जब program template/skeleton और fitness function दिए गए हों, तो LLM से programs की population बनाई जाती है, और अलग-अलग k versions से नया program बनाने वाले prompts इस्तेमाल किए जाते हैं; उन्होंने पाया कि k=2 अच्छा काम करता है। यह थोड़ा जैविक-सा लगता है। फिर input पर programs चलाए जाते हैं और fitness function से score दिया जाता है, और evolution के लिए island model इस्तेमाल होता है
सिद्धांततः prompt कुछ ऐसा होगा
def foo_v1(a, b): ...
def foo_v2(a, b): ...
# foo_v1과 foo_v2를 사용해 새 함수를 만들어 줘. {{ THIS }}처럼 이중 중괄호 안에 있는 것만 바꿀 수 있어
def foo(a, b): return a + {{}}
नया परिणाम पाने के लिए LLM को लगभग 1e6 बार ही बुलाना पड़ा, तो यह काफ़ी प्रभावशाली रूप से कम संख्या है। यह भी कहा गया है कि evaluation/scoring में कुछ मिनट लगते हैं
यहाँ depth और breadth के बीच trade-off पर सोचा जा सकता है। यह individual programs और populations को score करने में latency और throughput से जुड़ता है। क्या होगा अगर सभी programs के लिए memoization किया जाए? अगर loss function को multidimensional रखा जाए, ताकि input या input buckets के हिसाब से एक-एक dimension हो, तो शायद पहले अलग-अलग क्षेत्रों में अच्छा प्रदर्शन करने वाली program populations मिल सकें और बाद में उन्हें जोड़ा जा सके
यह भी जिज्ञासा है कि cap set कितने दुर्लभ हैं, इस बारे में पहले से कोई prior knowledge थी या नहीं। पहले computational कोशिशें हुई थीं और वे विफल रही थीं या नहीं, यह भी जानने की इच्छा है, लेकिन जो भी हो, यह शानदार है
Twitter / X पोस्ट को दूसरे शब्दों में कहें, तो आगे चीज़ें सिर्फ बेहतर ही होंगी
यानी AI capability monotonically increasing है, और दशकों से ऐसी ही है, और इस मामले में क्षमता recursive self-improvement भी कर रही है। हम पहले ही AI autocomplete, AI-based refactoring, और comments में AI द्वारा auto-generated code review diff से coding productivity में व्यक्तिगत रूप से लगभग 20~30% सुधार देख रहे हैं
लगता है AI अभी कुछ वैसा दौर में है जैसा 90s में Intel था। कोड को 2x तेज़ बनाना हो तो बस Intel CPU के अगले revision का इंतज़ार करना होता था। अब वही भूमिका AI models निभा रहे हैं। अगर coding, customer support, bug triage जैसी business flows के कुछ हिस्से LLM systems से जोड़ दिए जाएँ, तो system “improvement” लगभग model name बदलने जितनी बात रह जाती है
शुरुआती integration के बाद, बहुत कम मेहनत में आने वाले कुछ वर्षों तक “सब कुछ जादू की तरह थोड़ा-थोड़ा बेहतर होता जाएगा” जैसी स्थिति की उम्मीद की जा सकती है
- मेरी नज़र में blog post या linked paper में ऐसा कुछ नहीं कहा गया है
  खासकर LLM इस्तेमाल करने वाले और न करने वाले परिणामों की तुलना नहीं की गई। मेरी समझ के अनुसार, यह पेपर LLM का उपयोग करके शायद दिए गए type signature का पालन करने वाले Python kernel functions उत्पन्न करने में genetic programming के परिणाम दिखाता है। इस काम के लिए LLM अनिवार्य नहीं हैं
  इसलिए यहाँ LLM वास्तव में कुछ विशेष कर रहा है या नहीं, यह अभी भी एक खुला प्रश्न है
जिन समस्याओं पर काम किया गया, उनमें से एक cap set problem थी
https://en.m.wikipedia.org/wiki/Cap_set
यह समस्या high-dimensional lattice में ऐसे सबसे बड़े point set, यानी cap set, को खोजने की है जिसमें कोई भी तीन बिंदु एक ही सीधी रेखा पर न हों। यह महत्वपूर्ण है क्योंकि यह extremal combinatorics की अन्य समस्याओं के लिए model का काम करता है। extremal combinatorics इस बात का अध्ययन करता है कि संख्याओं, graphs, या अन्य objects के संग्रह कितने बड़े या छोटे हो सकते हैं। इस समस्या पर brute-force computation काम नहीं करती। क्योंकि जिन संभावनाओं पर विचार करना पड़ता है उनकी संख्या बहुत जल्दी ब्रह्मांड के परमाणुओं की संख्या से भी आगे निकल जाती है
FunSearch ने program के रूप में समाधान उत्पन्न किए, और कुछ settings में अब तक खोजे गए सबसे बड़े cap set पाए। यह पिछले 20 वर्षों में cap set size में सबसे बड़ी बढ़त थी। साथ ही, यह समस्या ऐसे पैमाने तक बढ़ जाती है जो मौजूदा state-of-the-art computational solvers की क्षमता से बहुत आगे है, इसलिए FunSearch ने उन solvers को पीछे छोड़ दिया
यह जानने की जिज्ञासा है कि symbolic reasoning को LLM के साथ कैसे integrate किया जाए, या क्या यह संभव भी है
- हम अभी यही कर रहे हैं। यह सिर्फ संभव ही नहीं, बल्कि trial-and-error generation से आगे जाने वाले applications के लिए आवश्यक भी है
- यह कुछ हद तक ASU के Lab V2 द्वारा explored neuro-symbolic विचारों के समानांतर भी लगता है
- LEAN
हाल की DeepMind की FunSearch पेपर ने इस बात पर ज़ोर दिया कि कोड सुधार जनरेट करने के लिए pre-trained बड़े language model का उपयोग किया गया था
दिलचस्प बात यह है कि मुख्य LLM, PaLM2 model family पर आधारित Codey था, लेकिन supplementary materials में open source LLM StarCoder का भी उल्लेख है
लेकिन FunSearch के GitHub repository में ऐसे LLM implementation शामिल नहीं हैं। उदाहरण के लिए, sampler.py में यह कोड है
```
class LLM:  
"""Language model that predicts continuation of provided source code."""

def __init__(self, samples_per_prompt: int) -> None:  
self._samples_per_prompt = samples_per_prompt

def _draw_sample(self, prompt: str) -> str:  
"""Returns a predicted continuation of `prompt`."""  
raise NotImplementedError('Must provide a language model.')  
```
यह कोड दिखाता है कि बाहरी LLM implementation की ज़रूरत है। अगर StarCoder का सफलतापूर्वक उपयोग किया गया था, तो उसके या उससे मिलते-जुलते open source LLM के लिए integration guide या basic implementation का न होना आश्चर्यजनक है। अगर ऐसी सामग्री होती, तो शोध की पुनरुत्पादकता और accessibility काफ़ी बेहतर हो सकती थी
यह सत्यापित किया जा सकने वाला नया ज्ञान है या नहीं, इससे अलग, model size या दूसरे regulatory उपायों के ज़रिए AI access को सीमित करने के सवाल पर यह एक दिलचस्प case study है
ऐसे प्रतिबंध उन कंपनियों को अनुचित बढ़त देते हैं जो नया ज्ञान या प्रकृति के नियम खोज लेने के बाद भी उन्हें साझा किए बिना monetize कर सकती हैं

FunSearch: LLM का उपयोग करके गणित और विज्ञान में नई खोजें

FunSearch का मूल आइडिया

Evolutionary iteration structure

Cap set problem में परिणाम

इंसानों द्वारा समझे जा सकने वाले छोटे programs

Online bin packing पर application

2024 update और expansion

LLM-based discovery की दिशा

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

1 टिप्पणियां

Hacker News की राय