- CoRT(Chain of Recursive Thoughts) एक ऐसा प्रोजेक्ट है जिसमें AI मॉडल जवाब को एक बार में तय नहीं करता, बल्कि खुद कई बार विकल्प बनाकर उनका मूल्यांकन करता है और फिर अंतिम जवाब चुनता है
- इसका कार्य-प्रवाह शुरुआती response generation, आवश्यक thinking rounds की संख्या तय करना, हर round में 3 विकल्प बनाना, पूरे responses का मूल्यांकन करना, और सबसे अच्छे response का चयन करने से बना है
- Mistral 3.1 24B पर टेस्ट करने पर, खासकर programming tasks में, छोटे मॉडल के मानक पर response quality में बड़ा सुधार दिखाया गया
- Web UI अभी शुरुआती development stage में है, और Windows में
start_recthink.bat, Linux में pip, npm, recthink_web.py execution flow का उपयोग होता है
- मुख्य components हैं self-evaluation, competitive alternative generation, iterative refinement, और dynamic thinking depth, और प्रोजेक्ट MIT license के तहत जारी किया गया है
CoRT क्या करता है
- CoRT एक ऐसा तरीका है जो AI मॉडल को अपने response की recursive review करने, विकल्प तैयार करने, और फिर सबसे बेहतर जवाब चुनने में सक्षम बनाता है
- इसका लक्ष्य यह है कि AI अपने पहले दिए गए जवाब को ज्यों का त्यों इस्तेमाल न करे, बल्कि खुद उस पर संदेह करे और दोबारा कोशिश करने की प्रक्रिया को दोहराए
- README इसे “AI battle royale” की तरह बताता है, जहां कई candidate responses में से बचा हुआ जवाब अंतिम परिणाम के रूप में इस्तेमाल होता है
जवाब बनाने का तरीका
- processing flow निम्न चरणों से मिलकर बना है
- AI initial response बनाता है
- AI आवश्यक thinking rounds की संख्या तय करता है
- हर round में 3 alternative responses बनाता है
- सभी responses का मूल्यांकन करता है
- सबसे अच्छा response चुनता है
- अंतिम response, बार-बार विकल्प बनाने और मूल्यांकन करने के बाद चुना गया परिणाम होता है
टेस्ट और उदाहरण
- Mistral 3.1 24B पर CoRT लागू करके टेस्ट किया गया
- README के अनुसार, CoRT वाला version, बिना CoRT वाले version की तुलना में खासकर programming tasks में बेहतर परिणाम देता है
- उदाहरण के तौर पर Mistral 3.1 24B + CoRT और Mistral 3.1 24B non CoRT के result images शामिल हैं
चलाने का तरीका
- Web UI अभी शुरुआती development stage में है
- Windows में
start_recthink.bat खोलकर dependencies install होने तक इंतज़ार करने का निर्देश दिया गया है
- Linux पर चलाने की प्रक्रिया इस प्रकार है
pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py
- एक नए shell में frontend चलाया जाता है
cd frontend
npm start
सीधे चलाना और components
- सीधे चलाने के लिए dependencies install करें,
OPENROUTER_API_KEY सेट करें, और फिर Python script चलाएँ
pip install -r requirements.txt
export OPENROUTER_API_KEY="your-key-here"
python recursive-thinking-ai.py
- प्रोजेक्ट जिन चार मुख्य तत्वों पर ज़ोर देता है, वे इस प्रकार हैं
-
Self-evaluation
- Competitive alternative generation
- Iterative refinement
- Dynamic thinking depth
- योगदान PR के रूप में स्वीकार किए जाते हैं, और license MIT है
1 टिप्पणियां
Hacker News की रायें
कई बार यह ट्रेंड दिखता है कि कई models को एक-दूसरे के खिलाफ खड़ा कर देने या झुंड में चलाने से collective intelligence जादू की तरह पैदा हो जाएगी, लेकिन खुद प्रयोग करने और ASU/Microsoft Research का काम देखने के बाद मैं एक ज्यादा सरल निष्कर्ष पर पहुंचा: LLM दूसरे LLM के validator के रूप में बहुत खराब हैं
Subbarao Kambhampati की “(How) Do LLMs Reason/Plan?” प्रस्तुति में GPT-4, जब तक symbolic SAT solver जज के रूप में शामिल नहीं होता, एक साबित तौर पर गलत graph coloring proof को आत्मविश्वास के साथ बना देता है https://www.youtube.com/watch?v=0u2hdSpNS2o
Stechly आदि का पेपर quantifies करता है कि GPT-4 से अपने ही जवाब की आलोचना करवाने पर accuracy उल्टे गिरती है, और बाहरी sound verifier जोड़ने पर planning और puzzle tasks में कुल मिलाकर लगभग 30 percentage points का सुधार होता है https://arxiv.org/abs/2402.08115
यानी मौजूदा autoregressive models के लिए verification, generation से ज्यादा कठिन है, और ऐसे checkers चाहिए जो compiler, linter, SAT solver, answer dataset की तरह सचमुच दुनिया के बारे में reasoning करें
इसलिए कई LLM को stack करने का तरीका आम तौर पर खास मदद नहीं करता। “LLM-Modulo” position paper भी मानता है कि autoregressive models अपनी verification या long-term planning खुद नहीं कर सकते, और उन्हें high-recall idea generator की तरह treat करके एक single, sound verifier में wrap करना चाहिए https://arxiv.org/abs/2402.01817
खुद test करने पर पाया कि 5-model debate को एक strong model और verifier से बदलना बेहतर है: answer समान या बेहतर रहते हैं, और latency व orchestration का बोझ बहुत कम होता है
किताबें या फिल्में अच्छा उदाहरण हैं: यह कहना आसान है कि character shallow है, लेकिन गहरा और दिलचस्प character बनाना हैरान करने वाला कठिन है
software engineering में भी ऐसा ही है; security vulnerability खोजने का prompt पाने वाला LLM generated code में संभावित vulnerable spots बता सकता है
लेकिन अगर आप किसी दूसरे LLM से math proof में reasoning error ढूंढने की उम्मीद करें, तो असल में उसे पूरी reasoning फिर से करनी पड़ेगी, इसलिए meaningful performance improvement होगा या नहीं, इस पर संदेह है
LangChain या LlamaIndex जैसे frameworks में भी यह RAG pipeline evaluation में गहराई से शामिल है https://arxiv.org/abs/2411.15594
मुझे उत्सुकता है कि LLM से generated code के लिए unit tests भी बनवाए जाएं, और फिर मौजूदा application unit tests समेत सब चलाए जाएं, तो कैसा रहेगा
code compile होता है या नहीं, unit tests pass होते हैं या नहीं—यह verify करने से कुछ हद तक evidence-based verification संभव है, और AI test results पढ़कर अपनी गलतियां सुधारने में उनका उपयोग कर सकता है
corpus data training single-digit scale की छलांग ला सकती है, लेकिन observation और adaptation वाले OODA loop के साथ interaction data training कहीं ज्यादा शक्तिशाली है
अगर मैं AI कर रहा होता तो शायद यही करता। हालांकि असल में मैं BrowserBox बना रहा हूं
generate-and-test के लिए भरोसेमंद, अपेक्षाकृत तेज और memory-efficient checking algorithm चाहिए, और यह खासकर तब उपयोगी होता है जब केवल सही answers generate करने वाला exact generation algorithm धीमा हो या बहुत memory इस्तेमाल करे
यहां generator LLM है, और checker या “verifier” compiler, linter, SAT solver, answer dataset आदि हैं
generate-and-test trial and error से भी जुड़ा है, और trial and error शायद Paleolithic era से ही मौजूद रहा होगा
कभी-कभी मैं यह तरीका अपनाता हूं: पहले AI चैट मॉडल से समस्या का जवाब दिलवाता हूं, और फिर उससे यह रिपोर्ट लिखवाता हूं कि वह जवाब सही क्यों है, इस तरह कि शुरुआती समस्या या तकनीकी क्षेत्र न जानने वाला व्यक्ति या AI भी उसे समझ सके
उसके बाद समस्या न जानने वाले दूसरे AI मॉडल से रिपोर्ट को grade करवाता हूं, और उससे ऐसी रिपोर्ट लिखवाता हूं जिसमें वह उस explanation की मांग करे जो मूल मॉडल ने नहीं दी, या logic में inconsistency बताए
इस रिपोर्ट को वापस मूल मॉडल को देता हूं और जरूरी जानकारी या सुधारों को शामिल करके जवाब फिर से लिखवाता हूं, फिर इसे तब तक दोहराता हूं जब तक दूसरा मॉडल convince न हो जाए या पहला मॉडल सभी change requests शामिल न कर ले
यह बहुत crude है, लेकिन जिन मामलों में मैंने आजमाया, उनमें काफी अच्छे नतीजे मिले
final plan आमतौर पर कहीं ज्यादा balanced और सोचा-समझा बनता है
दिलचस्प बात यह है कि यह technique खुद पर लागू करने पर भी अच्छी तरह काम करती है। plan को दोबारा देखने से पहले flaws ढूंढना सच में मददगार होता है
मसलन एक tech-focused, एक marketing-focused, और एक personal goals से जुड़े context वाली
एक ही सवाल को अलग-अलग context वाली chats में डालना उसी समस्या को कई perspectives से देखने जैसा है, और conclusions भी context के हिसाब से काफी अलग हो सकते हैं
idea काफी अच्छा लगा था, लेकिन token usage काफी बढ़ने की संभावना है
साथ ही चिंता यह है कि अगर judge के तौर पर इस्तेमाल होने वाला LLM शुरू से ही पर्याप्त अच्छा जवाब नहीं बना सकता, तो उसे सही तरह से grade करने में भी दिक्कत हो सकती है
मैं इसे बड़े scale पर always-on debate senate के रूप में आजमाना चाहूंगा
हर बार prompt का जवाब देने के बजाय, deadlines वाली हो सकने वाली task list देकर senate को काम करने देना, sub-tasks के लिए groups में बंटना, results को challenge करना और suggestions देना—ऐसा तरीका
इससे आगे, analysts का tree बनाया जा सकता है, जहां parent node केवल तभी suggestions ऊपर भेजे जब उसे लगे कि नीचे का analysis खास तौर पर insightful है
मैंने साफ देखा है कि model को किसी खास perspective से समस्या approach करने को कहने पर नतीजे बेहतर या खराब हो सकते हैं। अलग-अलग perspectives और उन नतीजों की critical analysis साथ में बनाई जाए तो impressive results मिल सकते हैं
यह तरीका बहुत बड़ी संख्या में tokens बनाएगा, लेकिन per-token cost ऐसी दिशा में जा रही है कि यह feasible हो सके। AI-only IRC server बनाने की संभावना भी है, जिसमें कोई भी अपना model connect कर सके और उसे shared discussion room की तरह इस्तेमाल किया जा सके
जब समय लगाकर try करने के बाद अटककर वापस आता, तो वह हल्के से कहता, “हां, सही है, आपने अच्छा पकड़ा! आप लगभग पहुंच गए हैं! अगला step X और Y है”, और फिर पहले जैसा detailed tutorial दे देता, बस गलत flags जैसे हिस्सों को थोड़ा बदल देता
ऐसा लगता था जैसे किसी जरूरत से ज्यादा उत्साही intern से deal कर रहा हूं जो अपना काम verify किए बिना फेंक देता है, और मुझे लगता है कि पहले bot के सामने दूसरा bot बैठाकर उससे “क्या तुम्हें सच में पक्का है?” पूछवाने से यह काफी बेहतर हो सकता है
इसे Civilization II के advisors concept से प्रेरित होकर बनाया था, और यह काफी ठीक चला, लेकिन single LLM Mistral से बंधे होने की limitation कुछ हद तक थी
और यह मेरे computer को जला देने जितना heavy था
पर्याप्त time और tokens देने पर यह क्या बना पाएगा, देखना दिलचस्प होगा
एक बहुत सरल और limited strategy जो मैं अक्सर इस्तेमाल करता हूं: message के आखिर में जोड़ देता हूं, “जवाब देने से पहले tags के अंदर एक बार सोचो, tags के अंदर एक बार self-critique करो, और अंत में final answer लिखो”
यह काफी अच्छा काम करता है। इसी तरह सिर्फ “proposal की सबसे बड़ी 5 problems ढूंढो” कहना भी ठीक है, लेकिन 5 को force करने पर वह अक्सर कुछ न कुछ ढूंढ ही लेता है, भले ही उनमें से ज्यादातर कम relevant हों
step 1 में plan बनवाता हूं, step 2 में plan की flaws identify करवाता हूं, step 3 में flaws को शामिल करके plan update करवाता हूं
मैं अक्सर जो दूसरे सवाल पूछता हूं वे हैं “हमने क्या miss किया?”, “performance, security, legal, cost के लिहाज से considerations क्या हैं?”
“और कुछ?” जैसे leading prompts भी कुछ बार repeat किए जा सकते हैं, खासकर अगर consider करने वाले topics guide कर दिए जाएं। हर बार खत्म होने पर उन considerations को शामिल करके plan refresh करवाता हूं
शीर्षक से जो उम्मीद थी, उससे थोड़ा अलग है। लगा था कि यह साफ तौर पर विरोधात्मक प्रक्रिया होगी
मैंने इसे खुद आजमाया नहीं है और पता नहीं काम करेगा भी या नहीं। लेकिन ChatGPT से अलग-अलग prompts में “XYZ सच है, वजह समझाओ” और “XYZ झूठ है, वजह समझाओ” पूछकर देखना कि कौन-सा पक्ष ज्यादा भरोसेमंद लगता है, मददगार होता है
https://github.com/evalstate/fast-agent
समझ नहीं आता कि कोई इसे नया क्यों मानेगा। शायद यह HN की हालत दिखाता है
approach खुद अच्छा लगता है, लेकिन सीधे कभी भी यह संकेत नहीं देना चाहिए कि “तुम गलत हो”। आम तौर पर वह बस मान लेता है कि वह गलत है
बल्कि जब ऐसी स्थिति में भी वह सचमुच विरोध करके अपना बचाव करता है, तो वह ज्यादा प्रभावशाली लगता है
ऐसे experiments काफी मजेदार हैं, इसलिए मैं एक Unreal Engine blueprint-style graph editor बना रहा हूं जिससे लोग ऐसे workflows design कर सकें
user prompt एक agent में जाता है और शुरुआती कोशिश बनाता है, फिर वह conversation history दूसरे system prompt वाले “agent” को दी जाती है जो सख्त critic बनता है, pass/fail signal देता है, और critic के pass मानने तक loop चलता है, फिर user को output मिलता है
आदर्श रूप से एक छोटी website होगी जो आपके अपने LLM endpoint को call करे और workflow graph को save/load/share करने दे
Mistral Small 3.1 और Gemma 3 स्थानीय रूप से चल सकने वाले पहले आधे-उतने सक्षम models जैसे लगते हैं, लेकिन वह क्षमता सिर्फ बीज है; उसे लगातार track पर रखने के लिए framework चाहिए
अगर iterative loop के अंदर Python execute करने की अनुमति देकर उसे दुनिया explore करने को कहें, तो वह news जैसी चीजें download करके पढ़ना शुरू कर देता है
उदाहरण के लिए, GPT को बदतमीज होने का निर्देश देने पर Gemini की बकवास या कमजोर सोच पकड़ने की क्षमता को GPT में कुछ हद तक mimic किया जा सका। लगता है शिष्टता बहुत-सी मूल्यवान चीजें छान देती है
लेकिन output पढ़ने में अप्रिय हो जाता है। Gemini ने शायद इसे training में दो चरणों में संभाला और पहले चरण को private “thinking” बनाकर हल किया
इसलिए मेरे हिसाब से जरूरत 2-step approach की है, जो उस “mean” output को थोड़ा इंसानी अंदाज में polish करे। इस तरह काम करने पर थोड़े समय से ज्यादा में काफी थकान होती है
अलग-अलग LLM personalities वाली group chat UI भी बहुत valuable लगती है। message object format हर message में name रखने जैसी चीजों के साथ कई users और कई AIs को ध्यान में रखता हुआ लगता है, लेकिन मैंने अभी तक ऐसी UI नहीं देखी
कई providers का support हो तो और अच्छा। उनकी strengths अलग-अलग होती हैं, यह second opinion लेने जैसा है
consortium वही prompt कई models को parallel में भेजता है, और सभी responses को एक moderator model के पास evaluation के लिए भेजता है। moderator तय करता है कि और iteration चाहिए या नहीं
confidence threshold या minimum iteration count तक पहुंचने तक उसे जबरन और iterations करवाने के लिए भी configure किया जा सकता है
llm-openrouter में मेरे बनाए PR का इस्तेमाल करके कई model options समेत model aliases save किए जा सकते हैं। उदाहरण के लिए
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researcherकी तरह online research specialist बना सकते हैंदूसरे members को JSON mode में entity extraction करने दिया जा सकता है, और किसी और member को blind draft लिखने दिया जा सकता है। moderator इन सबका इस्तेमाल करके अच्छा जवाब synthesize करता है
हमें जल्दी से इन GPUs को green power पर चलाने का तरीका ढूंढना होगा। नहीं तो AIs tic-tac-toe के optimal solution पर आपस में debate करते-करते धरती को पिघला देंगे
कभी-कभी यह बहुत छोटे task को खत्म करने का सबसे आसान तरीका होता है, लेकिन backend cost का फर्क काफी बड़ा होना ही है। user अंत में बिल्कुल परवाह नहीं करेगा, क्योंकि उसे यह वास्तविक नहीं लगता
यह बात पहले ही तथ्य जैसी मान ली गई है कि AI को खुद अपने खिलाफ लगातार चलना होगा
मेरे हिसाब से machine learning models से नए ideas निकलवाने का तरीका यही है
self-debate के जरिए उन सभी ideas के बारे में diagonalize करना जिन्हें पहले ही आजमाकर छोड़ दिया गया है, लेकिन कुछ consistency constraints बनाए रखना। जाहिर है, यह कहने जितना आसान नहीं है
Conway's Game of Life जैसा, लेकिन rules वाले रंगीन squares की जगह कुछ weights वाले LLMs लगातार आपस में बातें करते रहें, और कहीं न कहीं से speech या action के रूप में उभर आएं
https://news.ycombinator.com/item?id=43835798
यह आखिर कहाँ तक जाएगा? क्या हर कुछ घंटों में standup meetings करने वाली AI agent scrum team बनेगी?
क्या हम ऐसे agents से सरकारी bureaucracy की नकल बना देंगे जो पूरे दिन किसी विषय पर debate करके सबसे अच्छा viewpoint ढूँढते रहें?
अलग-अलग roles वाले AI agents एक scrum team चला रहे थे, और हर agent prompt इस तरह बनाया गया था कि वह सबका विरोध करे या अपने viewpoint को बेहद critical तरीके से पेश करे; अंतिम फैसला एक mediator करता था
presenter का दावा था कि यह उनके लिए अच्छा काम करता था
इंसानों के अनुभव और perspectives अलग-अलग होते हैं, हालांकि LLM में यह उतना नहीं होता। फिर भी कभी-कभी बस एक अलग टोपी काफी होती है। जैसे code reviewer और coder के फर्क की तरह
किसी दिन एक ऐसा बिंदु आएगा जहाँ effect flat हो जाएगा, और उस बिंदु को तय करने के लिए AI committee भी बन जाएगी
आखिर वे समुद्र को उबालना तो नहीं चाहेंगे
अच्छा है कि इसे आसानी से fork करके इसके साथ experiment किया जा सकता है
मैंने अभी-अभी Nash Equilibrium जोड़कर “prompt engineering” को multi-agent negotiation के रूप में दोबारा framing करने वाला अपना iteration शुरू किया है। जानना चाहूँगा कि बाकी लोग क्या सोचते हैं
https://github.com/faramarz/NECoRT/
मेरा आकलन है कि enterprise LLMs को अतिरिक्त compute cost से बड़ी दिक्कत नहीं होगी, और वे कई modeling optimizations के जरिए जटिल financials को tune करने की दिशा को ज्यादा पसंद करेंगे
public repositories और contributions से मैं बहुत परिचित नहीं हूँ, इसलिए अगर मैं कुछ गलत कर रहा हूँ तो अच्छा होगा कि कोई बता दे
इरादा original codebase को fork करके theory test करने और आखिर में इसे PR के रूप में submit करने का है