भाषा आवर्ती स्व-सुधार: लगभग 280 भाषाओं में कोड इंटेलिजेंस को अनथक मेहनत से निखारना
> हम लगभग 280 भाषाओं के लिए कोड इंटेलिजेंस सपोर्ट करते हैं। कोई इंसान इसका हाथ से ऑडिट नहीं कर सकता। इसलिए हमने एक भाषा आवर्ती स्व-सुधार लूप बनाया — स्पॉट-चेक, LLM-as-judge, एक चीज़ ठीक करो, दोबारा वैलिडेट करो — और इसे आइसोलेटेड एजेंट्स के एक फ़्लीट के साथ तब तक चलाते हैं जब तक एक्सट्रैक्शन वास्तव में सही न हो जाए, सिर्फ़ ग्रीन न हो।
इस पोस्ट में दिए गए आंकड़े प्रकाशन के समय (मई 2026) की सिस्टम स्थिति दर्शाते हैं। मौजूदा आंकड़ों के लिए हमारा टीम पेज देखें।
Maguyva लगभग 280 भाषाओं के सोर्स कोड से सिंबल, रेफ़रेंस, और एक डिपेंडेंसी ग्राफ एक्सट्रैक्ट करता है। हर भाषा एक कस्टम tree-sitter हैंडलर है — क्वेरी, हेयुरिस्टिक्स, एज केस — और हर हैंडलर अपने ही तरीक़े से सूक्ष्म रूप से ग़लत हो सकता है। एक मेथड कॉल जो रीड के रूप में उत्सर्जित हो जाए। एक फ़ंक्शन जो ग़लत संलग्न स्कोप को दे दिया जाए। एक रिलेशनशिप जो सिरे से मौजूद ही न हो।
यह हाथ से ऑडिट नहीं किया जा सकता। कोई भी टीम 280 ग्रामर में एक्सट्रैक्शन आउटपुट पढ़कर ख़राब एज नहीं पकड़ सकती। तो दिलचस्प सवाल यह नहीं है कि “क्या हमारा एक्सट्रैक्शन सही है” — यह है कि “इतने बड़े विस्तार पर, बिना हर लूप में इंसान को शामिल किए, आप यह पता कैसे लगाते हैं कि वह ग़लत है।” हमारा जवाब है भाषा आवर्ती स्व-सुधार: भाषा एजेंट्स से संचालित एक क्वालिटी लूप, जज के रूप में काम करता एक LLM, और एक नियम जिसे हम बार-बार सीखते रहते हैं: ग्रीन होना सही होने के बराबर नहीं है।
ग्रीन होना सही नहीं है
हर भाषा के पास एक फ़िक्स्चर सुइट है, और एक रिलीज़ गेट उसे पांच आयामों पर स्कोर करता है — सटीकता, संरचनात्मक अखंडता, पूर्णता, गुणवत्ता, और परफ़ॉर्मेंस। कोई भाषा GREEN तभी बनती है जब, अपने फ़िक्स्चर पर, precision ≥ 0.95, recall ≥ 0.99, और F1 ≥ 0.97 हो, साथ ही सांख्यिकीय भरोसे के लिए कम-से-कम 20 अपेक्षित एज हों। इससे नीचे यह YELLOW या RED है, और यह शिप नहीं होती।
वह गेट ज़रूरी तो है, लेकिन पर्याप्त नहीं। फ़िक्स्चर उन्हीं फ़िक्स्चर के विरुद्ध वैलिडेट करते हैं जो हमने लिखे। वे उन मामलों को दर्ज करते हैं जिनके बारे में हम पहले ही सोच चुके थे। कोई हैंडलर अपने फ़िक्स्चर पर बेदाग़ हो सकता है और फिर भी ऐसे पैटर्न को बिगाड़ सकता है जो सिर्फ़ असली कोड में दिखाई देता है — कोई मैक्रो मुहावरा, कोई जेनेरिक-बाउंड मेथड, कोई भाषा फ़ीचर जिसके लिए किसी ने फ़िक्स्चर नहीं लिखा। GREEN का मतलब है कि फ़िक्स्चर पास हो गए। इसका मतलब यह नहीं कि कोई असली रिपॉज़िटरी साफ़-सुथरे तरीक़े से एक्सट्रैक्ट होती है। तो लूप को फ़िक्स्चर पीछे छोड़कर जंगल की ओर देखना पड़ता है।
भीतरी लूप: स्पॉट-चेक, जज, फ़िक्स, साबित करो
कोर लूप एक बार में एक भाषा चलाता है:
┌──────────────────────────────────────────────────────────┐
│ │
▼ │
1. corpus run ── clone real-world repos, extract relationships │
│ │
▼ │
2. spot-check 100 edges (seed 42, then seed 123 to cross-check) │
│ │
▼ │
3. LLM judge classifies every sampled edge: │
CORRECT · FALSE_POSITIVE · TYPE_ERROR · │
SCOPE_ERROR · METADATA_ERROR │
│ │
▼ │
4. fix ONE thing — handler .py, .scm query, or config │
│ │
▼ │
5. re-validate — F1 + re-classify + manifest diff (no regressions)│
│ │
better? ──no──► revert, try a different fix ────────────────────┤
│ yes │
▼ │
6. promote the fix into fixtures (a permanent regression guard) ──┘
कुछ चीज़ें इसे थ्रैशिंग के बजाय काम करने लायक़ बनाती हैं।
जज एजेंट है, कोई API कॉल नहीं। जब हम कहते हैं “LLM-as-judge,” तो हमारा मतलब है कि भाषा एजेंट ख़ुद हर सैंपल की गई एज को असली सोर्स के विरुद्ध पढ़ता है और उसे एक तय पांच-श्रेणी रूब्रिक से वर्गीकृत करता है: क्या यह एज सही है, एक फ़ॉल्स पॉज़िटिव है, सही रिलेशनशिप है लेकिन ग़लत टाइप के साथ, ग़लत स्कोप से जुड़ी है, या ग़लत मेटाडेटा ले जा रही है? वह रूब्रिक ही पूरा खेल है — “23% एरर रेट” तब तक बेमानी है जब तक आपको पता न हो कि वे असली दोष हैं या जज की ग़लत गिनती।
एक चीज़ ठीक करो, फिर उसे साबित करो। हर इटरेशन ठीक एक एडिटेबल एसेट को बदलता है, फिर एक तय हार्नेस के विरुद्ध दोबारा चलता है और बदलाव को तभी बनाए रखता है जब F1 सुधरे और दोबारा वर्गीकरण बेहतर दिखे। अगर ऐसा नहीं होता, तो वह वापस पलट जाता है। अटकलबाज़ी वाले एडिट का कोई बैच नहीं, कोई “बेहतर होना चाहिए” नहीं। कोई बदलाव अपनी जगह कमाता है या ख़त्म हो जाता है। और जब कोई फ़िक्स टिक जाता है, तो उसे फ़िक्स्चर सुइट में प्रमोट कर दिया जाता है — ताकि जो बग उसने ठीक किया वह चुपचाप कभी वापस न आ सके। यही प्रमोशन चरण है जो लूप को सिर्फ़ दोहराव की जगह आवर्ती बनाता है: हर पास अगले पास के वैलिडेशन के लिए ओरेकल को और मज़बूत करता है।
वह सबक़ जिसे हम बार-बार सीखते रहते हैं: मेट्रिक्स ओवर-रिपोर्ट करते हैं
यहां वह जाल है, जिसमें हम सीधे जा फंसे। सेकंडरी कॉर्पस मेट्रिक्स — कितनी बार किसी एक्सट्रैक्ट किए गए टारगेट का कोई रिज़ॉल्व करने योग्य सिंबल नहीं होता, कितने सिंबल “अनाथ” दिखते हैं, वगैरह — समस्याओं को बहुत ज़्यादा ओवर-रिपोर्ट करते हैं। वे ज़्यादातर पैराडाइम आर्टिफ़ैक्ट हैं, बग नहीं।
सबसे साफ़ उदाहरण: llvm ने एक बार 73% “सोर्स-बिना-सिंबल” रेट दिखाई और उसे विनाशकारी क़रार दे दिया गया। हमने गहराई से देखा। असली सटीकता 98.5% थी। “मिसिंग सिंबल” लगभग सभी वैध बाहरी रेफ़रेंस थे — स्टैंडर्ड लाइब्रेरी में, फ़्रेमवर्क में, ऐसे कोड में जो रिपॉज़िटरी के बाहर रहता है, किए गए कॉल। यह मेट्रिक भाषा की एक विशेषता माप रहा था, हैंडलर का कोई दोष नहीं। Zig, COBOL, और Odin जैसी भाषाएं 65–70% “अनाथ” रेट दिखाती हैं और पूरी तरह सही हैं; COBOL में शून्य असली त्रुटियां थीं।
अगर हमने उन आंकड़ों को काम की दिशा तय करने दी होती, तो हम उन हैंडलर को “ठीक” करने में हफ़्तों बिता देते जो पहले से ही सही थे, और उन भाषाओं को नज़रअंदाज़ कर देते जिनमें ख़ामोश, असली बग थे। नतीजा सीधा है: कुल मिलाकर मेट्रिक्स ज़्यादा-से-ज़्यादा एक मोटा ट्राइएज सिग्नल हैं। असली क्वालिटी सिग्नल एज क्लासिफ़िकेशन के साथ स्पॉट-चेक है — असली रिपॉज़िटरी में असली एज को देखना और उन्हें एक-एक करके परखना। अंतर्ज्ञान पर डेटा, लेकिन तभी जब आपको पता हो कि कौन-सा डेटा सच बोल रहा है।
बाहरी लूप: एक फ़्लीट, कोई मैराथन नहीं
280 भाषाओं में एक बार में एक भाषा चलाने में हमेशा लग जाता, इसलिए भीतरी लूप को एक बाहरी लूप में लपेट दिया गया है जो कई भाषाओं को समानांतर में चलाता है।
pick a wave of near-GREEN / high-error languages
│
▼
fan out 10–15 agents, each ISOLATED in its own git worktree,
each grinding ONE language, committing to its own branch
│
▼
orchestrator integrates serially: file-scoped apply, then
`manifest diff` — any cross-language regression blocks the batch
│
▼
gated push (reviewed and confirmed) ──► rotate to the next wave
हर एजेंट एक डिस्पोज़ेबल worktree में काम करता है ताकि वे एक-दूसरे के रास्ते में न आएं। ऑर्केस्ट्रेटर उनके फ़िक्स को एक-एक करके इंटीग्रेट करता है, हर एक फ़ुल-मैनिफ़ेस्ट रिग्रेशन चेक के पीछे: कोई बदलाव जो अपनी ही भाषा की मदद करे लेकिन चुपचाप तीन और को तोड़ दे, लैंड नहीं होता। कुछ भी पुश होने से पहले इंटीग्रेशन गेटेड और कन्फ़र्म्ड होता है — रिग्रेशन गेट तय करता है कि क्या सुरक्षित है, कोई इंसान अब भी तय करता है कि क्या शिप होगा। फिर पूल अगली भाषाओं के सेट पर घूम जाता है और पूरी प्रक्रिया फिर से चलती है।
अब भी क्या अधूरा है
जज ग़लत हो सकता है, और ग़लती की एक दिशा होती है: बहुत कम कॉन्टेक्स्ट के साथ चल रहा एजेंट ओवर-रिपोर्ट करता है। एक बैच में, आठ भाषाओं को 5–20% एरर पर फ़्लैग किया गया; जांच करने पर सिर्फ़ एक असली प्रति-भाषा बग निकला — बाक़ी भाषा के अपने सिमेंटिक्स को चूकने से हुई जज की ग़लतियां थीं (एक सोर्स लाइन जो वैध रूप से कई एज उत्सर्जित करती है, पैरामीटर बाइंडिंग जिन्हें असाइनमेंट के रूप में मॉडल किया गया, हर आइडेंटिफ़ायर-प्रति-रेफ़रेंस वाली भाषाएं)। यही वजह है कि हम दो सीड के साथ सैंपल करते हैं और क्रॉस-चेक करते हैं, और यही वजह है कि जज और फ़िक्स्चर के बीच असहमति को सबसे दिलचस्प सिग्नल माना जाता है, कोई तय फ़ैसला नहीं — कभी-कभी ग़लत चीज़ ख़ुद फ़िक्स्चर होता है।
हम लक्ष्य के बारे में भी ईमानदार हैं। लक्ष्य शून्य असली त्रुटियां हैं, बस — लेकिन “शून्य” वह दिशा है जिसकी ओर हम भाषा-दर-भाषा अनथक मेहनत करते हैं, कोई ऐसा बॉक्स नहीं जिसे चेक कर दिया जाए। हमेशा कोई और रिपॉज़िटरी किसी और मुहावरे के साथ मौजूद रहती है।
दावा नहीं, अर्जित
Maguyva किसी एजेंट के लिए जो कुछ भी करता है — कोई सिंबल खोजना, कोई डिपेंडेंसी ट्रेस करना, उद्धृत कोड के साथ किसी सवाल का जवाब देना — यह सब नीचे मौजूद एक्सट्रैक्शन के सही होने पर टिका है। 280 भाषाओं में, “सही” होने का दावा नहीं किया जा सकता; इसे असली कोड के विरुद्ध लगातार अर्जित करना पड़ता है। लूप ही वह तरीक़ा है जिससे हम इसे अर्जित करते हैं: एक ऑटोनॉमस स्पॉट-चेक-और-फ़िक्स चक्र जो अपने ही मेट्रिक्स को शक की नज़र से देखता है, हर बदलाव को साबित करता है, और हर फ़िक्स को अगले रिग्रेशन के ख़िलाफ़ एक गार्ड में बदल देता है। यह चमकदार नहीं है। यह वह काम है जो हमें “हम आपकी भाषा सपोर्ट करते हैं” कहने और उसका मतलब निभाने की इजाज़त देता है। ग्रीन होना आसान है। सही होना अर्जित किया जाता है।
जुड़ी हुई रीडिंग
Maguyva की बिल्ड लॉग से और लेख
हमने कोड सर्च को voyage-4-large में क्यों अपग्रेड किया_
हमने अपनी कोड एम्बेडिंग को voyage-4-large पर शिफ़्ट किया — जो फ़िलहाल पब्लिक RTEB कोड रिट्रीवल लीडरबोर्ड में शीर्ष पर है। ईमानदार वर्ज़न: वह ट्रेड-ऑफ़ जो हम करते हैं, हम वास्तव में क्या इंडेक्स करते हैं, और हम प्रीमियम एम्बेडिंग के लिए भुगतान क्यों करते हैं।
मल्टी-मोडल फ़्यूज़न सर्च: हर क्वेरी के लिए सही रिट्रीवर चुनना_
"parseConfig कहां परिभाषित है" जैसी क्वेरी को "auth कैसे काम करता है" से अलग तरह की सर्च चाहिए। Maguyva इंटेंट को वर्गीकृत करता है, उसके हिसाब से चार रिट्रीवल मोडैलिटी को वेट देता है, और नतीजों को वेटेड Reciprocal Rank Fusion से जोड़ता है।
एजेंट ऑब्ज़र्वेबिलिटी: Hooks, Alloy, और Grafana_
हमने Claude Code और Codex को OpenTelemetry और Alloy के साथ एक ही Grafana स्टैक में जोड़ा, फिर एजेंट व्यवहार की समस्याओं को उनके स्रोत पर खोजने और ठीक करने के लिए ट्रेस और लॉग का उपयोग किया।