PlanCompiler: A Deterministic Compilation Architecture for Structured Multi-Step LLM Pipelines
यह शोध पत्र PlanCompiler को प्रस्तुत करता है, जो एक नियत (deterministic) संकलन आर्किटेक्चर है जो एक टाइप किए गए नोड रजिस्ट्री और स्टैटिक वैलिडेशन के माध्यम से योजना (planning) को निष्पादन (execution) से अलग करता है ताकि निष्पादन योग्य पायथन कोड उत्पन्न किया जा सके, जिससे संरचित बहु-चरणीय LLM वर्कफ़्लो पर फ्री-फॉर्म कोड जनरेशन बेसलाइन की तुलना में काफी अधिक विश्वसनीयता, कम लागत और प्रतिस्पर्धी विलंबता (latency) प्राप्त होती है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक जटिल मशीन बनाने की कोशिश कर रहे हैं, जैसे कि एक कॉफी मेकर जो आपका मेल भी छाँट सके और आपके लिए धन्यवाद नोट भी लिख सके।
यदि आप एक बहुत बुद्धिमान लेकिन थोड़े अराजक सहायक (एक मानक लार्ज लैंग्वेज मॉडल, या LLM) से कहें कि "बस इसे बना दो," तो वह कुछ ऐसा कर सकता है:
- वह कॉफी वाले हिस्से के लिए एक रेसिपी लिखेगा।
- वह मेल वाले हिस्से के लिए एक रेसिपी लिखेगा।
- वह नोट वाले हिस्से के लिए एक रेसिपी लिखेगा।
समस्या: वह सहायक व्यक्तिगत रेसिपी लिखने में तो बहुत अच्छा है, लेकिन वह यह सुनिश्चित करने में बहुत खराब है कि वे रेसिपी आपस में कैसे जुड़ती हैं। हो सकता है कि कॉफी की रेसिपी कहे "गर्म पानी डालें," लेकिन मेल वाली रेसिपी "ठंडे पानी" की अपेक्षा करती हो। हो सकता है कि वे एक ही कप के लिए अलग-अलग नामों का उपयोग करें। हो सकता है कि वे एक नए प्रकार के पेंच (screw) का आविष्कार कर दें जो अस्तित्व में ही नहीं है। जब आप पूरी मशीन चलाने की कोशिश करते हैं, तो यह टूट जाती है क्योंकि हिस्से आपस में फिट नहीं होते, और त्रुटियाँ जमा होती रहती हैं जब तक कि पूरी चीज़ क्रैश न हो जाए।
समाधान: PlanCompiler
यह पेपर पेश करता है PlanCompiler को, जो एक "रचनात्मक लेखक" के बजाय एक सख्त निर्माण फोरमैन (construction foreman) या एक कंपाइलर (एक ऐसा टूल जो ब्लूप्रिंट को एक काम करने वाली मशीन में बदल देता है) की तरह कार्य करता है।
यह कैसे काम करता है, यहाँ एक सरल उपमा दी गई है:
1. "लेगो बॉक्स" (द रजिस्ट्री)
AI को नए उपकरण या सामग्री आविष्कार करने देने के बजाय, PlanCompiler उसे लेगो ब्रिक्स का एक निश्चित बॉक्स देता है।
- आप केवल बॉक्स में मौजूद ब्रिक्स का ही उपयोग कर सकते हैं (जैसे, "लाल ब्लॉक," "नीला ब्लॉक," "कनेक्टर")।
- AI एक "उड़ने वाला ब्लॉक" या "जादुई गोंद" का आविष्कार नहीं कर सकता।
- हर ब्रिक का एक विशिष्ट आकार और एक विशिष्ट कार्य होता है।
2. "आर्किटेक्ट" (द प्लानर)
AI का एकमात्र काम आर्किटेक्ट होना है। वह आपके अनुरोध को देखता है ("एक कॉफी मेल सॉर्टर बनाओ") और कहता है:
"ठीक है, मैं एक लाल ब्लॉक का उपयोग करूँगा, फिर एक नीला ब्लॉक, और फिर एक कनेक्टर। मैं उन्हें इसी क्रम में जोड़ूँगा।"
वह इस बात का कोड नहीं लिखता कि ब्लॉक्स कैसे काम करते हैं; वह बस यह तय करता है कि कौन से ब्लॉक्स का उपयोग करना है और उन्हें कैसे जोड़ना है।
3. "सुरक्षा निरीक्षक" (द वैलिडेटर)
इससे पहले कि कोई निर्माण शुरू करे, एक सुरक्षा निरीक्षक आर्किटेक्ट के ब्लूप्रिंट की जाँच करता है। यही जादुई हिस्सा है। निरीक्षक सात सख्त जाँच करता है:
- "क्या आपने ऐसा ब्रिक इस्तेमाल किया जो बॉक्स में नहीं है?" (नहीं।)
- "क्या ब्रिक्स के आकार वहाँ मेल खाते हैं जहाँ आपने उन्हें जोड़ा है?" (हाँ।)
- "क्या क्रम तार्किक है, या आपने एक ऐसा लूप बना दिया है जहाँ मशीन अपनी ही पूंछ का पीछा कर रही है?" (कोई लूप नहीं।)
- "क्या आप एक आवश्यक पेंच लगाना भूल गए?" (नहीं।)
यदि ब्लूप्रिंट इनमें से किसी भी जाँच में विफल रहता है, तो परियोजना को तुरंत अस्वीकार कर दिया जाता है। कोई निर्माण नहीं होता। यह "खामोशी से टूटी हुई मशीन" की समस्या को रोकता है।
4. "फैक्ट्री" (द कंपाइलर)
एक बार जब ब्लूप्रिंट निरीक्षण पास कर लेता है, तो एक फैक्ट्री रोबोट कार्यभार संभाल लेता है। वह अब AI से मदद नहीं माँगता। वह बस स्वीकृत ब्लूप्रिंट को देखता है और पहले से बने लेगो टुकड़ों को ठीक वैसे ही जोड़ देता है जैसा कि बनाया गया है। क्योंकि टुकड़े पहले से बने हुए हैं और कनेक्शन सख्त हैं, इसलिए मशीन का सही ढंग से बनना सुनिश्चित है।
यह बेहतर क्यों है? (परिणाम)
इस पेपर ने मानक AI विधियों (AI को सब कुछ शुरू से लिखने देने) के मुकाबले 300 अलग-अलग कार्यों पर इसका परीक्षण किया।
- मानक AI (अराजक लेखक): यह शुरू करने में तेज़ था लेकिन अक्सर विफल रहा। इसने नकली उपकरण बनाए, गलत नामों का उपयोग किया, या बीच में भ्रमित हो गया। यह लगभग 67% बार सफल हुआ।
- PlanCompiler (फोरमैन): यह योजना बनाने में थोड़ा धीमा था, लेकिन क्योंकि इसने पहले ब्लूप्रिंट की जाँच की, इसलिए यह 93% बार सफल हुआ।
लागत:
- मानक AI महंगा था क्योंकि यह अक्सर विफल होने वाली बड़ी, जटिल कोड लिखने की कोशिश करता रहता था, जिससे हर प्रयास पर बहुत पैसा बर्बाद होता था।
- PlanCompiler प्रति सफल कार्य 76 गुना सस्ता था। इसने सावधानी से योजना बनाने में थोड़ा पैसा खर्च किया, जिससे विफल प्रयासों पर लगने वाले भारी खर्च की बचत हुई।
"ग्लिच" जो शेष रह गए
इस सख्त प्रणाली के बावजूद, AI अभी भी दो विशिष्ट तरीकों से गलतियाँ करता था:
- "लूपहोल" (Loophole) ट्रिक: कभी-कभी AI एक जटिल गणितीय कार्य (जैसे वस्तुओं को गिनना) करने के लिए, एक ऐसे हिस्से में कच्चा SQL क्वेरी (एक डेटाबेस कमांड) डालने की कोशिश करता था जिसे एक साधारण ब्लॉक होना चाहिए था। यह काम तो कर गया, लेकिन परिणाम वैसा नहीं था जैसा बॉस चाहता था।
- "भ्रमित लेबल" (Confused Label) त्रुटि: कभी-कभी AI इस बात को लेकर भ्रमित हो जाता था कि "डेटाबेस हैंडल" क्या है और "फ़ाइल पाथ" क्या है, जैसे चाबी और दरवाजे के बीच भ्रमित होना। सुरक्षा निरीक्षक ने अधिकांश को पकड़ लिया, लेकिन कुछ बच निकले।
मुख्य निष्कर्ष
यह पेपर तर्क देता है कि जटिल, बहु-चरणीय कार्यों के लिए, हमें केवल AI को "रचनात्मक होने" के लिए नहीं कहना चाहिए। इसके बजाय, हमें इसे एक सख्त, पूर्व-निर्धारित प्रणाली के भीतर काम करने के लिए मजबूर करना चाहिए जहाँ यह चरणों की योजना बनाता है, एक कंप्यूटर ब्लूप्रिंट की त्रुटियों के लिए जाँच करता है, और फिर एक मशीन इसे बनाती है।
यह "AI के सही होने की उम्मीद करने" को "पहले गणित की जाँच करके AI के सही होने की गारंटी देने" में बदल देता है। यह एक दोस्त से "कार ठीक करने" के लिए कहने और एक मैकेनिक को पुर्जों को बदलने के लिए एक विशिष्ट चेकलिस्ट देने के बीच का अंतर है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।