हर एजेंसी इसका जवाब इतनी बड़ी सीमा बताकर देती है कि उसका कोई उपयोग नहीं होता, क्योंकि ईमानदार जवाब उन बातों पर निर्भर करता है जिन्हें उन्होंने अभी देखा नहीं है। इसलिए यहाँ उस संख्या के पीछे की रूपरेखा है: AI के काम के चार आम प्रकारों में क्या शामिल होता है, आप इनमें से कौन-सा चाहते हैं, और हर प्रकार की लागत किन बातों से बढ़ती है।
नीचे दी गई लागतें पैसों के बजाय इंजीनियर-सप्ताह में हैं। दरें बाज़ार और काम करने वाले व्यक्ति के अनुसार अलग होती हैं, और डॉलर में कीमत बताने वाला पेज पढ़ने वाले ज़्यादातर लोगों के लिए उसी दिन ग़लत होगा। इसकी तुलना उस दर से गुणा करें जिस पर आप विचार कर रहे हैं। ये इस तरह के काम के हमारे अनुभव पर आधारित अनुमान हैं, उद्योग का सर्वेक्षण नहीं।
AI के काम के चार प्रकार
हमें मिलने वाले लगभग हर अनुरोध में इनमें से कोई एक या दो प्रकार एक साथ होते हैं। आप कौन-सा चाहते हैं, यह तय करना सही लागत जानने की दिशा में सबसे बड़ा क़दम है—और किसी से बात करने से पहले आप यह कर सकते हैं।
| प्रकार | यह क्या करता है | पहले प्रोडक्शन संस्करण तक |
|---|---|---|
| आपकी अपनी सामग्री से जवाब | कर्मचारी या ग्राहक सवाल पूछते हैं; सिस्टम आपके दस्तावेज़ों से जवाब देता है और उनके स्रोत बताता है | 4–8 इंजीनियर-सप्ताह |
| जानकारी निकालना और वर्गीकृत करना | इनवॉइस, ईमेल, टिकट या फ़ॉर्म को व्यवस्थित फ़ील्ड या श्रेणियों में बदलता है | 3–6 इंजीनियर-सप्ताह |
| काम करने वाला एजेंट | सिर्फ़ टेक्स्ट तैयार करने के बजाय आपके सिस्टमों में कार्रवाई करता है | 8–16 इंजीनियर-सप्ताह |
| आपके उत्पाद के भीतर एक मॉडल | उपयोगकर्ता के डिवाइस या आपके अपने सर्वर पर चलता है, किसी थर्ड-पार्टी API के बिना | 10–20 इंजीनियर-सप्ताह |
आख़िरी दो की लागत-सीमा बड़ी है, क्योंकि दोनों AI से बाहर की चीज़ों पर निर्भर करते हैं। एजेंट को बनाना उतना ही संभव है जितने अच्छे वे API हों जिनके ज़रिए उसे कार्रवाई करनी है; और डिवाइस पर चलने वाले मॉडल की सीमाएँ उस हार्डवेयर से तय होती हैं जिसे आप समर्थन देने का फ़ैसला करते हैं।
लागत असल में किन चीज़ों से तय होती है
जानकारी निकालने वाले एक व्यावहारिक वर्कफ़्लो के लिए हमारी इनवॉइस डेटा निकालने की मार्गदर्शिका और कस्टम इनवॉइस प्रोसेसिंग ऑटोमेशन सेवादेखें: जानकारी लेना, पुष्टि करना, कर्मचारियों से समीक्षा करवाना और आपके अकाउंटिंग सिस्टम में डेटा भेजना।
इनमें से कोई भी चीज़ मॉडल नहीं है। मॉडल चुनने में एक हफ़्ते का मूल्यांकन लगता है, फिर कॉन्फ़िगरेशन फ़ाइल में एक पंक्ति। अगर किसी प्रस्ताव में इसे मुख्य सवाल बताया गया है, तो यह उस प्रस्ताव के बारे में एक चेतावनी है।
- आपके डेटा की स्थिति। यह सबसे बड़ा कारक है। साफ़-सुथरे, मौजूदा और व्यवस्थित दस्तावेज़ एक ही जगह हों, तो लागत कम होती है। चार ऐसे रिकॉर्ड सिस्टम जो आपस में मेल न खाते हों, स्कैन किए हुए PDF और 2023 के बाद से अपडेट न हुई विकि—यह महँगा मामला है। इसमें डेटा पर काम करना पड़ता है, जिसकी आपको वैसे भी ज़रूरत होती।
- इसे कितना सटीक होना चाहिए। “ऐसा ड्राफ़्ट बनाता है जिसे कोई व्यक्ति जाँचता है” और “बिना निगरानी के कार्रवाई करता है” के बीच बड़ा फ़र्क है। दूसरी स्थिति के लिए माप, विफलताओं को संभालने और ग़लती होने पर सुरक्षित रहने के तरीक़े चाहिए—बजट यहीं खर्च होता है।
- यह कितने सिस्टमों से जुड़ता है। हर इंटीग्रेशन के अपने प्रमाणीकरण, रेट लिमिट और त्रुटि के मामले होते हैं। दो आम बात है। छह एक अलग प्रोजेक्ट है।
- क्या मूल्यांकन की ज़िम्मेदारी कोई लेगा। अगर आपकी टीम में कोई यह नहीं बता सकता कि जवाब अच्छा था या नहीं, तो हमें पहले वह व्यवस्था बनानी होगी। यह करना फ़ायदेमंद है, लेकिन मुफ़्त नहीं।
- डेटा कहाँ जा सकता है। “हमारा डेटा हमारे इंफ्रास्ट्रक्चर से बाहर नहीं जा सकता” एक जायज़ पाबंदी और डिज़ाइन का अहम पहलू है। आमतौर पर इसका मतलब है कि आप ओपन-वेट मॉडल होस्ट करेंगे। इससे कुछ क्षमताओं के बदले नियंत्रण मिलता है और होस्टिंग की लागत आपकी तरफ़ आ जाती है।
चलाने की वह लागत जिसे लोग भूल जाते हैं
बनाने का अनुमान बजट नहीं होता। लॉन्च के बाद भी तीन तरह की लागत जारी रहती है, और आमतौर पर योजना में सिर्फ़ पहली शामिल होती है।
- उपयोग। हर अनुरोध की लागत, जो वॉल्यूम के साथ बढ़ती है। पायलट स्तर पर सस्ती होती है, इसलिए प्रोडक्शन स्तर पर लोगों को चौंकाती है। आर्किटेक्चर तय करने से पहले अपने पायलट से 10 गुना वॉल्यूम पर लागत का अनुमान लगाएँ।
- मूल्यांकन और निगरानी। आपकी सामग्री बदलने और प्रदाताओं के मॉडल अपडेट करने से गुणवत्ता घट-बढ़ सकती है। इस पर नज़र रखने के लिए किसी व्यवस्था की ज़रूरत है।
- प्रदाता के बदलाव। प्रदाता अपने समय पर मॉडल बंद करते हैं। मॉडल बदलने के लिए हर साल कुछ दिनों का काम मानकर चलें, और ऐसा डिज़ाइन न बनाएँ जिससे बदलना मुश्किल हो।
प्रूफ़ ऑफ़ कॉन्सेप्ट की लागत कितनी होनी चाहिए और उसे क्या साबित करना चाहिए
दो से चार हफ़्ते। इससे ज़्यादा समय लगे, तो वह प्रूफ़ ऑफ़ कॉन्सेप्ट नहीं, बल्कि बिना योजना वाला प्रोजेक्ट है।
अहम बात यह है कि इसका मक़सद क्या है। प्रूफ़ ऑफ़ कॉन्सेप्ट का अंत डेमो से नहीं, फ़ैसले से होना चाहिए—और यह पक्का करने का तरीक़ा है कि शुरू होने से पहले सफलता का मापदंड लिख लें और यह भी कि वह पूरा न होने पर आप क्या करेंगे। “इसे कम-से-कम 85% टिकट सही वर्गीकृत करने चाहिए; अगर ऐसा न हो तो हम रुक जाएँगे” एक प्रूफ़ ऑफ़ कॉन्सेप्ट है। “देखें कि AI हमारे लिए क्या कर सकता है” एक वर्कशॉप है।
इससे वह चीज़ भी तैयार होनी चाहिए जिसकी बाद में आपको ज़रूरत पड़ेगी: सही जवाबों वाले कुछ असली, लेबल किए हुए उदाहरण। यह टेस्ट सेट मौजूदा मॉडल के बाद भी काम आएगा और अगला फ़ैसला लेने की लागत घटाएगा।
हर विक्रेता से पूछने लायक सवाल
- 1. किस वजह से इसकी लागत आपके अनुमान से दोगुनी हो सकती है?
- 2. हम किसी संख्या से कैसे जानेंगे कि यह काम कर रहा है, और इसे कौन मापेगा?
- 3. हमारे पायलट से दस गुना वॉल्यूम पर हर महीने इसकी लागत कितनी होगी?
- 4. आपके चुने हुए मॉडल को बंद किए जाने पर क्या होगा?
- 5. हमारा डेटा कहाँ जाता है और कितने समय तक रखा जाता है?
- 6. जवाब न मालूम होने पर सिस्टम क्या करता है?
- 7. अंत में कोड, प्रॉम्प्ट और मूल्यांकन सेट का मालिक कौन होगा?
छठा सवाल सबसे ज़्यादा बताता है। जिस सिस्टम के पास इसका जवाब नहीं होगा, वह पूरे आत्मविश्वास से कुछ गढ़ देगा—और इसी तरह ऐसे प्रोजेक्ट उन लोगों का भरोसा खो देते हैं जिनके लिए उन्हें बनाया गया था।
कब खुद नहीं बनाना चाहिए
तीन ऐसी स्थितियाँ जिनमें हम आपको खुद बनाने से मना करेंगे, क्योंकि यह बात पहले बता देना हम दोनों के लिए कम ख़र्चीला है।
- कहीं भी प्रक्रिया लिखी नहीं है। अगर कोई भी व्यक्ति नियमों का वर्णन नहीं कर सकता, तो प्रोजेक्ट की शुरुआत AI से नहीं, बल्कि संचालन से जुड़े काम से होगी।
- यह महीने में केवल दस बार होता है। किसी दुर्लभ काम को ऑटोमेट करने से उस ऑटोमेशन को बनाए रखने की लागत शायद ही कभी वसूल होती है।
- कोई मौजूदा उत्पाद पहले से यह काम करता है। अगर आपका डेटा आपको दूसरों से अलग नहीं बनाता, तो इसे खरीदें। इसे दोबारा बनाने के पैसे लेने के बजाय हम आपको यही बताना पसंद करेंगे।
हमारा काम करने का तरीका
हम एजेंसी नहीं, इंजीनियरों की एक छोटी टीम हैं: आप कोड लिखने वाले लोगों से बात करते हैं, बीच में कोई अकाउंट मैनेजर नहीं होता और हम सोच-समझकर काम चुनते हैं। AI के क्षेत्र में इसका मतलब है LLM इंटीग्रेशन, आपकी अपनी सामग्री से जानकारी ढूँढ़ना, एजेंट और आपके खुद होस्ट किए हुए मॉडल तैनात करना—साथ ही .NET, Python, TypeScript और क्लाउड से जुड़ा वह काम जो हमारे बाकी स्टूडियो में होता है।
हम अपना Windows सॉफ़्टवेयर भी बनाते हैं, जिसमें शामिल है एक टेक्स्ट असिस्टेंट, जो भाषा मॉडल पूरी तरह उपयोगकर्ता के PC पर चलाता हैइसलिए डिवाइस पर चलने वाले और निजता की पाबंदियों वाले समाधान हमारे लिए महज़ सैद्धांतिक नहीं हैं।
बताएँ कि आप क्या बनाना चाहते हैं
समाधान के बजाय समस्या का वर्णन करें—आज कोई क्या करता है, कितनी बार करता है और ग़लती होने पर क्या लागत आती है। आपको एक कारोबारी दिन के भीतर दायरे और लागत के साथ जवाब मिलेगा, या यह वजह कि हमें क्यों लगता है कि आपको इसे नहीं बनाना चाहिए।