मॉडल मूल्य निर्धारण ठीक दिखने पर भी एजेंटिक एआई महंगा क्यों लगता है?
बहुत सी सार्वजनिक एजेंट-लागत शिकायतें वास्तव में मॉडल शिकायतें नहीं हैं। वे रनटाइम शिकायतें हैं। जब तक कोई टीम कहती है "एजेंट एआई बहुत महंगा है," तब तक वास्तविक गुणक आमतौर पर दोहराया गया संदर्भ, बड़े निर्देश, पूर्ण-फ़ाइल रीड, पुष्टिकरण लूप और सीरियल टूल कॉल होते हैं जो एक समय में एक कदम के लिए उचित लगते हैं और प्रति सफल कार्य की गणना करने पर बेतुके लगते हैं।
विक्रेता समस्या होने से पहले यह एक वर्कफ़्लो समस्या है
सबसे स्पष्ट संकेत लाइव से आया r/AI_Agents चर्चा: बिल्डर्स विशाल सिस्टम प्रॉम्प्ट, फुल-फाइल रीड्स, सीरियल टूल चेन और "सिर्फ चेकिंग" लूप का वर्णन करते हैं जो मॉडल के निर्णय-योग्य कुछ भी उत्पन्न करने से पहले उसी कार्य पर ढेर सारी लागत डालते हैं। यह कोई बेंचमार्क कहानी नहीं है. यह एक रनटाइम डिज़ाइन कहानी है।
यही पैटर्न अन्यत्र भी दिखता है। एक अलग में r/LangChain धागाविफलता मोड में बार-बार पहचान फ़ाइलें और टूल विवरण प्रत्येक लूप पर इंजेक्ट किया गया था। में एक r/LocalLLaMA धागा, कार्य शुरू होने से पहले ही अपशिष्ट रेपो ओरिएंटेशन के रूप में दिखाई दिया। अलग-अलग उपकरण, एक ही अर्थशास्त्र।
वास्तव में क्या चीज़ स्टैक को महँगा महसूस कराती है
महँगा हिस्सा अक्सर एक बड़ा संकेत नहीं होता है। यह वही लागत है जिसका भुगतान बार-बार किया जाता है:
बार-बार संदर्भ एकत्र करना। बार-बार निर्देश. वर्कफ़्लो में प्रत्येक छोटी शाखा के बाद वही फ़ाइलें दोबारा पढ़ी जाती हैं। टूल कॉल जिन्हें बैच किया जा सकता था, लेकिन क्रमबद्ध किया गया था। पुष्टिकरण लूप जो टोकन बजट लीक होने पर हार्नेस को सुरक्षित महसूस कराते हैं।
यही कारण है कि "प्रति टोकन सस्ता" अभी भी एक महंगी प्रणाली में बदल सकता है। प्रति टोकन मूल्य एक इनपुट है। प्रति सफल कार्य की लागत वह परिचालन संख्या है जो वास्तव में मायने रखती है।
टीमों को आगे क्या मापना चाहिए
यदि आप वास्तविक गुणक खोजना चाहते हैं, तो केवल प्रदाता खर्च को मापना बंद करें और कार्य रन को मापना शुरू करें। प्रत्येक रन को एक कार्य आईडी दें। प्रथम-स्पर्श संदर्भ, अंतिम-स्पर्श संदर्भ, टूल कॉल की संख्या, बार-बार स्थिर पेलोड का आकार, पुनः प्रयास, और क्या अंतिम आर्टिफैक्ट रखने के लिए पर्याप्त उपयोगी था, को ट्रैक करें। एक बार जब यह मौजूद हो जाता है, तो अपशिष्ट पैटर्न आमतौर पर छिपना बंद कर देते हैं।
यहीं पर __TRH_PH_0__ सर्वोत्तम रूप से फिट बैठता है: एक वादे के रूप में नहीं कि प्रत्येक वर्कफ़्लो जादुई रूप से सस्ता हो जाएगा, बल्कि यह विश्लेषण करने के एक तरीके के रूप में कि आउटपुट गुणवत्ता को उचित ठहराने से पहले उपयोग का विस्तार कहां होता है।
व्यावहारिक अगला कदम
ऐसा वर्कफ़्लो चुनें जो पहले से ही महंगा लगता हो। लॉगिंग चालू करके इसे एक बार चलाएँ। सेटअप, नेविगेशन, बार-बार पेलोड, पुनः प्रयास और अंतिम उपयोगी कार्य पर खर्च किए गए टोकन को मैप करें। फिर अगले रन से एक दोहराया गया पेलोड, एक नियंत्रण लूप और एक अनावश्यक रीड हटा दें। यह आमतौर पर आपको किसी अन्य मॉडल-तुलना स्प्रेडशीट से अधिक सिखाएगा।