OODA लूप और चार स्तंभ
आर्किटेक्चर। एक निरंतर चक्र में चार सॉफ़्टवेयर कंपोनेंट्स — और कारण कि यह एक पाइपलाइन के बजाय एक चक्र क्यों है।
60 सेकंड में
OODA लूप और चार स्तंभ
आर्किटेक्चर। एक निरंतर चक्र में चार सॉफ़्टवेयर कंपोनेंट्स — और कारण कि यह एक पाइपलाइन के बजाय एक चक्र क्यों है।
डायग्राम के किसी भी बॉक्स पर टैप करें
सिस्टम जो कुछ भी देख सकता है, उसे ग्रहण करता है: टेक्स्ट, कोड, फ़ाइलें, API रिस्पॉन्स, स्क्रीन पिक्सल, लॉग्स, टूल आउटपुट। इसका एकमात्र काम दुनिया को ऐसे टोकन में बदलना है जिसे कोर पढ़ सके। सुरक्षा नोट: यह एकमात्र ऐसी जगह भी है जहाँ अविश्वसनीय कंटेंट आपके सिस्टम में प्रवेश करता है। मॉड्यूल 8 की हर चीज़ यहीं से जुड़ती है।
यह एक लूप क्यों होना चाहिए
- 1
कार्रवाई करने से दुनिया बदल जाती है
पहले कदम के बाद, स्थिति बदल जाती है। कार्रवाई करने से पहले बनाई गई योजना निष्पादित होते ही पुरानी पड़ जाती है। - 2
गलतियाँ ही जानकारी हैं
एक पाइपलाइन असफलता को एक अंत मानती है। एक लूप इसे अब तक सीखी गई सबसे उपयोगी चीज़ मानता है। - 3
आगे बढ़ने के साथ-साथ लक्ष्य छोटे हिस्सों में बंटते हैं
आप किसी ऐसे काम की पूरी योजना नहीं बना सकते जिसे आप अभी तक समझे नहीं हैं। लूप सिस्टम को काम करने की कोशिश करते हुए उप-लक्ष्यों (sub-goals) को खोजने देता है। - 4
रुकने के लिए एक निर्णय की आवश्यकता होती है
एक पाइपलाइन तब रुकती है जब उसके कदम खत्म हो जाते हैं। एक लूप तब रुकता है जब लक्ष्य पूरा हो जाता है, बजट खत्म हो जाता है, या कोई इंसान हस्तक्षेप करता है — और आपको इन तीनों को लागू करना होगा।
वास्तविक सॉफ़्टवेयर के रूप में चार स्तंभ
| स्तंभ | कोड में यह क्या है | आम गलती |
|---|---|---|
| परसेप्शन | पार्सर, लोडर, API क्लाइंट, OCR | जो कुछ ग्रहण करता है उस पर भरोसा करना |
| वर्किंग मेमोरी | स्टेट के लिए Postgres, रिट्रीवल के लिए pgvector | केवल रिट्रीवल बनाना, स्टेट नहीं |
| कॉग्निटिव कोर | मॉडल कॉल + वेरिफायर + पार्सर | यह मान लेना कि यही पूरा सिस्टम है |
| एक्शन लूप | टूल रजिस्ट्री, एक्ज़ीक्यूटर, सैंडबॉक्स, बजट | कोई सीमा नहीं, कोई लॉग नहीं, कोई अनडू नहीं |
और देखें और पढ़ें
लैब
एक OODA लूप जहाँ आप कोड में हर चरण को इंगित कर सकते हैं।
समस्या
def observe(env) -> Observation: ...
def orient(obs, state) -> Context: ...
def decide(ctx) -> Action: ...
def act(action) -> Result: ...आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1प्रोडक्शन में चारों चरणों में से किसे बदलना सबसे कठिन होना चाहिए, और क्यों?दिखाएं
अक्सर पूछे जाने वाले सवाल
क्या OODA, ReAct या Plan-and-Execute से बेहतर है?
वे अलग-अलग प्राथमिकताओं के साथ एक ही स्वरूप हैं। ReAct बारी-बारी से सोचने (reasoning) और काम करने (acting) को जोड़ता है; Plan-and-Execute पहले योजना बनाता है फिर चलाता है; OODA स्पष्ट रूप से orient चरण का नाम लेता है, जो इसका वास्तविक योगदान है — यह आपको यह पूछने पर मजबूर करता है कि स्टेट कहाँ रहता है।
प्लानिंग कहाँ फिट होती है?
Decide के अंदर। कंपाउंडिंग-एरर समस्या (मॉड्यूल 30) के कारण लंबी योजनाएं नाजुक होती हैं, इसलिए टिकाऊ पैटर्न यह है: कुछ कदमों की योजना बनाएं, एक निष्पादित करें, देखें, फिर से योजना बनाएं। केवल अगली कार्रवाई के लिए प्रतिबद्ध हों, पूरे रास्ते के लिए नहीं।
यह एक सामान्य प्रोग्राम से कैसे अलग है?
एक सामान्य प्रोग्राम का decide चरण वह कोड होता है जो आपने लिखा है और जिसे आप पढ़ सकते हैं। यहाँ यह एक मॉडल है जिसके अगले निर्णय का आप अनुमान नहीं लगा सकते। बाकी सब कुछ — लूप, स्टेट, टूल्स — साधारण सॉफ़्टवेयर है, यही वजह है कि आपके नियंत्रण (controls) वहीं होने चाहिए।
क्या मुझे वेक्टर डेटाबेस की आवश्यकता है?
शुरुआत के लिए नहीं। एक साधारण स्टेट टेबल और एक सूची के साथ शुरू करें। रिट्रीवल तब जोड़ें जब आप उस विशिष्ट चीज़ की ओर इशारा कर सकें जिसे सिस्टम भूल गया था। वेक्टर स्टोर अक्सर सबसे पहले बनाई जाने वाली और सबसे आखिर में ज़रूरत पड़ने वाली चीज़ होते हैं।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।