सॉफ़्टवेयर ख़रीदना
बिज़नेस सॉफ़्टवेयर में AI जोड़ना: यह कहाँ मदद करता है
AI जोड़ने की ज़्यादातर माँगें किसी डेमो से शुरू होती हैं। काम का सवाल इससे संकरा है: आज हाथ से होने वाला कौन-सा कदम पढ़ना, छाँटना, ढूँढना या मसौदा लिखना है — और ग़लत होने पर उसकी क़ीमत क्या है।
हम बिज़नेस सॉफ़्टवेयर में AI फ़ीचर बनाते हैं, और उन पर होने वाली बातचीत का अच्छा-ख़ासा हिस्सा इस सलाह पर ख़त्म होता है कि न बनाएँ। यह विनम्रता नहीं है। मॉडल एक ख़ास तरह के काम के लिए अच्छा औज़ार है, और बाकी सब के लिए महँगा और अनिश्चित। कुछ भी बनाने से पहले यह जान लेना कि कौन-सा काम किस तरह का है, यही ज़्यादातर मूल्य है।
जो ढर्रा ग़लत जाता है वह जाना-पहचाना है। कोई फ़ीचर इसलिए चुना जाता है कि वह डेमो में अच्छा दिखता है, आम तौर पर एक चैट बॉक्स, और उसे वहाँ जोड़ा जाता है जहाँ वह दिखे, न कि जहाँ हाथ का काम है। कोई तय नहीं करता कि सही जवाब कैसा दिखता है, इसलिए कोई नहीं बता सकता कि वह काम कर रहा है या नहीं। छह महीने बाद वह अब भी वहीं है और कोई उसका इस्तेमाल नहीं करता।
चार काम जो यह अच्छा करता है
बिज़नेस सॉफ़्टवेयर में अपनी जगह कमाने वाला लगभग हर AI फ़ीचर इन चार में से एक है, और हर एक उस व्यक्ति की जगह लेता है जो टेक्स्ट पढ़कर जो मिला उसे टाइप करता है।
- दस्तावेज़ पढ़नासप्लायर इनवॉइस, परचेज़ ऑर्डर, बैंक स्टेटमेंट और डिलीवरी चालान, संरचित फ़ील्ड में पढ़े जाते हैं। मॉडल पढ़ता है; फिर सामान्य कोड जाँचता है कि उसने क्या पढ़ा — कि लाइन के जोड़ मिलते हैं, कि GSTIN का स्वरूप सही है, कि सप्लायर मौजूद है। निकालने की ज़्यादातर ग़लतियाँ किसी के देखने से पहले इन्हीं जाँचों में पकड़ी जाती हैं।
- आने वाली चीज़ों को छाँटनापूछताछ, टिकट और ईमेल सही कतार में भेजे जाते हैं, ज़रूरत के हिसाब से टैग होते हैं, या वरिष्ठ व्यक्ति की ज़रूरत होने पर चिह्नित होते हैं। ग़लत अनुमान की क़ीमत बस दोबारा भेजना है, और यही इसे अच्छा पहला काम बनाता है।
- अपने ही रिकॉर्ड में चीज़ें ढूँढनाआपके दस्तावेज़ों, नीतियों और पुराने रिकॉर्ड से सवालों के जवाब, जवाब के बगल में स्रोत के हवाले के साथ। हवाले के बिना यह एक आत्मविश्वासी सार है जिसे कोई जाँच नहीं सकता; हवाले के साथ यह एक तेज़ खोज है।
- व्यक्ति के लिए मसौदाजवाब, कोटेशन के कवर लेटर, प्रोडक्ट विवरण और लंबी बातचीत के सार, किसी के सुधारने और मंज़ूर करने के लिए तैयार। बचत तभी असली है जब मसौदा सुधारना शून्य से लिखने से तेज़ हो, और केवल तभी।
जहाँ इसे फ़ैसला नहीं करना चाहिए
जो भी चीज़ गणना या नियम है, वह कोड में होनी चाहिए। पेरोल, GST, स्टॉक मूल्यांकन, ब्याज, छूट और पात्रता का एक ही सही जवाब होता है जिसे ऑडिटर दोबारा निकाल सके, जबकि मॉडल एक विश्वसनीय-सा जवाब देता है जो आम तौर पर सही होता है। आम तौर पर सही होना ऐसा मानक नहीं जिस पर कोई रिटर्न भर सके।
- टैक्स और वैधानिक गणनाएँ, भले ही मॉडल नियम को पूरी तरह समझा सके।
- वित्तीय या क़ानूनी असर वाली मंज़ूरियाँ, जैसे क्रेडिट सीमा, रिफ़ंड और राइट-ऑफ़।
- कोई भी चीज़ जहाँ एक ही इनपुट से हमेशा एक ही आउटपुट आना चाहिए।
- ऐसे तथ्य जो उसे दिए गए डेटा में नहीं हैं। जो वह देख नहीं सकता उसके बारे में पूछने पर मॉडल ख़ाली जगह को किसी सही-से लगने वाले जवाब से भर देता है।
शिप करने से पहले मापें
टिकने वाले AI फ़ीचर्स को बंद कर दिए जाने वालों से अलग करने वाली एक आदत है मूल्यांकन सेट, जो शिकायतों के बाद नहीं बल्कि फ़ीचर से पहले बनाया जाता है।
- असली मामले इकट्ठा करेंआपके अपने दस्तावेज़ों और संदेशों से, कठिन मामलों सहित — ख़राब स्कैन, हस्तलिपि, मिली-जुली भाषाएँ, वह सप्लायर जिसके इनवॉइस का लेआउट हर तिमाही बदल जाता है।
- सही जवाब लिख लेंहर मामले के लिए, एक सावधान व्यक्ति क्या निकालता। यह थकाऊ है, और यही वह कदम है जो उसके बाद की हर चीज़ संभव बनाता है।
- हर फ़ील्ड के हिसाब से मापें, कुल नहींजो इनवॉइस रीडर जोड़ सही और तारीख़ें ग़लत पढ़ता है, उसकी समस्या ख़ास और सुधारी जा सकने वाली है। सटीकता का एक कुल आँकड़ा इसे छिपा देता है।
- सीमा तय करेंतय भरोसे से नीचे का मामला आगे बढ़ने के बजाय किसी व्यक्ति के पास जाता है। सीमा एक कारोबारी फ़ैसला है, और यह आपका होना चाहिए।
- हर बदलाव पर दोबारा चलाएँनया प्रॉम्प्ट या नया मॉडल उसी सेट पर मापी गई तुलना बन जाता है, न कि ऐसा बदलाव जिसे करने की कोई हिम्मत न करे।
व्यक्ति की मंज़ूरी
हर AI फ़ीचर के लिए फ़ैसला चाहिए कि व्यक्ति के बिना क्या होगा। ज़्यादातर कारोबारी कामों के लिए सही शुरुआत है मंज़ूरी के लिए मसौदा बनाना और कभी बिना निगरानी के काम न करना, और इसे तभी बढ़ाना जब मापे गए आँकड़े इसकी इजाज़त दें।
मंज़ूरी का चरण तभी समय बचाता है जब जाँचना करने से तेज़ हो। इसका मतलब है आउटपुट के बगल में स्रोत दिखाना — निकाले गए फ़ील्ड के बगल में इनवॉइस की तस्वीर, जवाब के बगल में हवाला दिया गया पैराग्राफ़ — ताकि व्यक्ति दोबारा करे नहीं, बस पुष्टि करे। जो समीक्षा स्क्रीन किसी को मूल ढूँढने पर मजबूर करे, उसने चुपचाप बचत ख़त्म कर दी है।
लागत, गति और डेटा
- क़ीमत हर कॉल पर लगती है, इसलिए बिल मात्रा के साथ बढ़ता है। मासिक मात्रा और हर अनुरोध का आकार बनाने से पहले आँकें, पहले बिल के बाद नहीं।
- दोहराए जाने वाले काम को कैश करें, और आसान मामलों को छोटे, सस्ते मॉडल पर भेजें। ज़्यादातर मात्रा आसान मामलों की होती है।
- विलंब का बजट तय करें। व्यस्त स्क्रीन के भीतर कई सेकंड लेने वाला फ़ीचर इस्तेमाल नहीं होगा, उसके जवाब कितने भी अच्छे हों।
- तय करें कि कौन-सा डेटा आपके इन्फ्रास्ट्रक्चर से बाहर जा सकता है, और जो भेजना ज़रूरी नहीं उसे हटा दें। प्रॉम्प्ट में रखा व्यक्तिगत डेटा भी भारत के DPDP अधिनियम के तहत व्यक्तिगत डेटा ही है।
- प्रदाता की डेटा रखने और ट्रेनिंग की शर्तें जाँचें। एंटरप्राइज़ API शर्तें आम तौर पर भेजे गए डेटा पर ट्रेनिंग को बाहर रखती हैं; जहाँ यह काफ़ी न हो, वहाँ ओपन-वेट मॉडल आपके अपने सर्वर पर चल सकता है।
एक समझदार पहला प्रोजेक्ट
एक ऐसा काम चुनें जो बार-बार होता हो, कम जोखिम वाला हो और जाँचना आसान हो। सप्लायर इनवॉइस को परचेज़ एंट्री में पढ़ना, जिसे व्यक्ति मंज़ूर करे, अच्छा उदाहरण है: मात्रा असली है, ग़लती मंज़ूरी पर पकड़ी जाती है, और बचा समय मापना आसान है। मूल्यांकन सेट बनाएँ, इसे मंज़ूरी के चरण के पीछे शिप करें, और एक महीने बाद आँकड़े देखें।
अगर वे अच्छे हैं, तो अगला काम सही ठहराना आसान और बनाना तेज़ होता है, क्योंकि मूल्यांकन की आदत और समीक्षा स्क्रीन पहले से मौजूद हैं। अगर नहीं, तो आपने यह सस्ते में सीख लिया — और कभी-कभी सीख यह होती है कि समस्या एक ख़राब डिज़ाइन किया गया फ़ॉर्म था, जिसके लिए किसी मॉडल की ज़रूरत ही नहीं थी।