सेवा
AI इंटीग्रेशन सेवाएँ
वहाँ लगाया जाए जहाँ काम घटे, वहाँ नहीं जहाँ डेमो अच्छा लगे।
उन टीमों के लिए जो AI को उन्हीं सिस्टम के भीतर चाहती हैं जो वे पहले से चला रही हैं, और वह भी ख़ास कामों के लिए: दस्तावेज़ पढ़ना, जो आए उसे वर्गीकृत करना, अपने ही डेटा पर सवालों के जवाब देना, और ऐसा मसौदा तैयार करना जिसे बाद में कोई व्यक्ति मंज़ूर करे। मूल्यांकन और लागत नियंत्रण के साथ बनाया गया, क्योंकि जिस फ़ीचर को कोई माप न सके उस पर कोई भरोसा भी नहीं कर सकता।
फ़ैसला
यह कब सही फ़ैसला है।
ज़्यादातर AI फ़ीचर दो ही तरह से विफल होते हैं। वे वहाँ जोड़े जाते हैं जहाँ वे दिखते हैं, वहाँ नहीं जहाँ समय बचाते हैं; और वे यह जाने बिना भेज दिए जाते हैं कि उनका आउटपुट सही है या नहीं। बीस में से एक बार ग़लत रहने वाला समराइज़र बिना समराइज़र के भी बदतर है, क्योंकि वह बीसवाँ मामला ही ग्राहक तक पहुँचता है।
दूसरी विफलता है लागत और लेटेंसी का प्रोडक्शन में पता चलना। जो प्रॉम्प्ट टेस्टिंग में ठीक लगता है वह रोज़ दस हज़ार कॉल पर महँगा हो जाता है, और नौ सेकंड लेने वाला फ़ीचर चाहे कितना भी अच्छा हो, इस्तेमाल नहीं होगा। ये दोनों डिज़ाइन की शर्तें हैं, और दोनों को शुरू में संभालना सस्ता है व बाद में जोड़ना मुश्किल।
हम तकनीक से नहीं, काम से शुरू करते हैं: कौन सा काम हाथ से हो रहा है, कितनी बार, और ग़लत होने पर उसकी क़ीमत क्या है। फिर हम फ़ीचर से पहले एक मूल्यांकन सेट बनाते हैं, ताकि यह सवाल कि यह काम करता है या नहीं, एक जवाब पा सके। अक्सर सही जवाब यह निकलता है कि किसी मॉडल की ज़रूरत ही नहीं, और हम यही कह देते हैं।
आपको क्या मिलता है
काम में क्या शामिल है।
दस्तावेज़ से डेटा निकालना
इनवॉइस, परचेज़ ऑर्डर, स्टेटमेंट और फ़ॉर्म संरचित फ़ील्ड में पढ़े जाते हैं, और भरोसे का स्तर सामने रखा जाता है ताकि कम भरोसे वाली चीज़ें चुपचाप आगे बढ़ने के बजाय किसी व्यक्ति तक जाएँ।
वर्गीकरण और रूटिंग
आने वाली पूछताछ, टिकट और दस्तावेज़ सही क़तार में भेजे जाते हैं, और नियम अपारदर्शी नहीं बल्कि जाँचे जा सकने वाले रहते हैं।
अपने ही डेटा पर खोज
आपके दस्तावेज़ों और रिकॉर्ड पर ऐसी खोज जो अपने स्रोत बताती है, ताकि जवाब पर भरोसा करने के बजाय उसे जाँचा जा सके।
मसौदा, जिस पर व्यक्ति की मंज़ूरी ज़रूरी
जवाब, सारांश और विवरण किसी व्यक्ति की मंज़ूरी के लिए तैयार किए जाते हैं। यह जाँच-द्वार एक डिज़ाइन फ़ैसला है, कोई अस्वीकरण नहीं।
लॉन्च से पहले मूल्यांकन
एक लेबल किया हुआ सेट और मापी गई सफलता दर, ताकि प्रॉम्प्ट या मॉडल बदलना अटकल नहीं, एक तुलना बने।
लागत और लेटेंसी पर नियंत्रण
कैशिंग, कठिनाई के हिसाब से मॉडल रूटिंग, और बजट अलर्ट — क्योंकि प्रति-कॉल दाम महीने के अंत में ऐसा बिल बनते हैं जिसका किसी ने हिसाब नहीं लगाया था।
स्टैक
हम इसे किससे बनाते हैं।
हर प्रोजेक्ट के हिसाब से चुने हुए। यहाँ कुछ भी डिफ़ॉल्ट रूप से नहीं लगाया जाता, और जो टीम आगे इसे संभालेगी वह समस्या जितनी ही मायने रखती है।
मॉडल
Claude, GPT या कोई ओपन-वेट मॉडल, हर काम के लिए ब्रांड नहीं बल्कि मापी गई गुणवत्ता और लागत देखकर चुना गया।
रिट्रीवल
जहाँ काफ़ी हो वहाँ pgvector के साथ PostgreSQL, और जहाँ पैमाना माँगे वहाँ अलग वेक्टर स्टोर।
ऑर्केस्ट्रेशन
पहली पसंद सादा, पढ़ा जा सकने वाला कोड। भारी-भरकम एजेंट फ़्रेमवर्क तभी, जब वे अपनी डीबगिंग लागत वसूल करें।
मूल्यांकन
पाइपलाइन में चलने वाले वर्ज़न वाले टेस्ट सेट, ताकि गिरावट किसी ग्राहक को नहीं, CI को पता चले।
गोपनीयता
डेटा कहाँ रहेगा, कितने समय रखा जाएगा और क्या हटाया जाएगा — यह पहली कॉल से पहले तय होता है, इस सवाल सहित कि कोई अनुरोध आपके इंफ़्रास्ट्रक्चर से बाहर जा भी सकता है या नहीं।
तुलना
ऊपर से जोड़ा गया AI बनाम ऐसा AI जो अपनी जगह कमाता है।
ज़्यादातर AI फ़ीचर दो ही तरह से विफल होते हैं: वहाँ जोड़े जाते हैं जहाँ वे दिखते हैं, वहाँ नहीं जहाँ समय बचाते हैं; और यह जाने बिना भेज दिए जाते हैं कि उनका आउटपुट सही है या नहीं।
| पहलू | सामान्य तौर पर जोड़ा गया AI | हम इसे कैसे बनाते हैं |
|---|---|---|
| यह कहाँ जाता है | जहाँ डेमो अच्छा लगे — डैशबोर्ड पर एक चैट बॉक्स | जहाँ हाथ से होने वाला काम सचमुच है, जो आमतौर पर दिखावटी नहीं होता |
| यह जानना कि यह काम करता है | किसी ने दो-चार बार आज़माया और ठीक लगा | आपके असली मामलों से बना लेबल किया हुआ सेट, और लॉन्च से पहले मापी गई सफलता दर |
| जब उसे ठीक से पता न हो | फिर भी जवाब दे देता है, उसी आत्मविश्वास से जितना सही होने पर | आपकी तय सीमा से नीचे के मामले किसी व्यक्ति के पास जाते हैं, और वह सीमा आप तय करते हैं |
| लागत | पहले महीने के बिल पर पता चलती है | डिस्कवरी के दौरान अनुमानित, कैशिंग, मॉडल रूटिंग और बजट अलर्ट के साथ |
| लेटेंसी | प्रोडक्शन में पता चलती है, जिसके बाद फ़ीचर चुपचाप इस्तेमाल होना बंद हो जाता है | एक तय संख्या वाली डिज़ाइन शर्त, क्योंकि नौ सेकंड लेने वाला फ़ीचर इस्तेमाल नहीं होगा |
| प्रॉम्प्ट या मॉडल बदलना | ऐसा बदलाव जिसे कोई परख नहीं सकता, इसलिए कोई करने की हिम्मत नहीं करता | उसी टेस्ट सेट पर मापी गई तुलना, जो CI में चलती है |
यह कैसे चलता है
पहली बातचीत से लाइव होने तक।
इस तरह के काम के लिए अनुमानित। पायलट वैकल्पिक नहीं है — जब तक इस्तेमाल करने वाले यह न कहें कि यह टिकता है, कुछ भी स्विच नहीं किया जाता।
- 1 हफ़्ता
काम कहाँ है, यह पहचानें
कौन सा काम हाथ से हो रहा है, कितनी बार, और ग़लत होने पर उसकी क़ीमत क्या है। कभी-कभी जवाब कोई नियम या बेहतर फ़ॉर्म होता है, और हम यह कह देते हैं।
- 1 हफ़्ता
मूल्यांकन सेट तैयार करें
असली मामले, लेबल किए हुए, फ़ीचर बनने से पहले। इसके बिना सुधार और गिरावट में फ़र्क़ करने का कोई तरीक़ा नहीं।
- 3-5 हफ़्ते
बनाएँ और मापें
इंटीग्रेशन, मानवीय जाँच-द्वार, कैशिंग और लागत नियंत्रण, हर बदलाव पर उसी सेट के विरुद्ध मापे हुए।
- 2-3 हफ़्ते
पायलट और ट्यूनिंग
असली मात्रा के एक हिस्से पर लाइव, जाँच-द्वार सख़्त रखते हुए, और उसे तभी ढीला किया जाता है जब मापे गए आँकड़े इसकी इजाज़त दें।
लॉन्च के बाद
क्या बदलता है।
- जिस हाथ के काम को हटाने के लिए यह बना था, वह सचमुच हट जाता है — केवल सहारा नहीं बनता।
- कम भरोसे वाले मामले चुपचाप निकल जाने के बजाय किसी व्यक्ति तक पहुँचते हैं, और यही बात फ़ीचर को बिना निगरानी चलने लायक़ बनाती है।
- प्रॉम्प्ट या मॉडल बदलना जुआ नहीं, एक तुलना बन जाता है।
- महीने का बिल वह आँकड़ा होता है जिसका किसी ने पहले अनुमान लगाया था, कोई अचानक झटका नहीं।
जानबूझकर गुणात्मक रूप में बताया गया। हम ऐसे प्रतिशत सुधार प्रकाशित नहीं करते जिन्हें हम किसी नामित क्लाइंट से, उनकी सहमति के साथ, जोड़ न सकें।
सवाल
आम सवाल।
क्या हमारा डेटा किसी और का मॉडल ट्रेन करने में इस्तेमाल होगा?
जिन कॉन्फ़िगरेशन में हम तैनात करते हैं, उनमें नहीं। एंटरप्राइज़ API शर्तें भेजे गए डेटा पर ट्रेनिंग से मना करती हैं, और जहाँ यह स्वीकार्य न हो वहाँ हम आपके अपने इंफ़्रास्ट्रक्चर पर ओपन-वेट मॉडल चलाते हैं। यह किसी भी इंटीग्रेशन से पहले तय होता है।
आप कैसे जानते हैं कि AI सही है?
फ़ीचर भेजने से पहले हम आपके असली मामलों से एक लेबल किया हुआ मूल्यांकन सेट बनाते हैं और उसी पर मापते हैं। तय सीमा से नीचे की हर चीज़ आगे बढ़ने के बजाय किसी व्यक्ति के पास जाती है, और वह सीमा आप तय करते हैं।
इसे चलाने की लागत कितनी है?
यह मात्रा और चुने गए मॉडल पर निर्भर करता है, और हम इसका अनुमान लॉन्च के बाद नहीं, डिस्कवरी के दौरान लगाते हैं। कैशिंग, आसान मामलों को सस्ते मॉडल पर भेजना, और महीने का बजट अलर्ट — ये सब निर्माण का हिस्सा हैं।
क्या हमें AI की ज़रूरत भी है?
अक्सर नहीं। एक सही जगह लगाया नियम, एक बेहतर फ़ॉर्म या एक तय रिपोर्ट उन समस्याओं का बड़ा हिस्सा सुलझा देती है जिन्हें AI की समस्या मान लिया जाता है — लागत के एक अंश में और बिना किसी अनिश्चितता के। जब ऐसा हो, हम आपको बता देंगे।
क्या आप हमारे अपने इंफ़्रास्ट्रक्चर पर मॉडल चला सकते हैं?
हाँ, ओपन-वेट मॉडल के साथ, जहाँ डेटा कहाँ रहेगा या अनुबंध की शर्तें ऐसा माँगें। सौदा यह है कि गुणवत्ता और संचालन का बोझ बनाम नियंत्रण — और इसे सिद्धांत पर नहीं, आपके असली काम पर मापे गए नतीजों पर तय करना चाहिए।
अगर AI किसी ग्राहक के सामने ग़लती कर दे तो?
यही रोकने के लिए मानवीय जाँच-द्वार और भरोसे की सीमा मौजूद हैं, और ये दोनों फ़ीचर भेजने से पहले लिए गए डिज़ाइन फ़ैसले हैं, बाद में जोड़ा गया कोई अस्वीकरण नहीं। जहाँ ग़लत होने की क़ीमत ज़्यादा हो, वहाँ सही सेटिंग यह है कि मसौदा मंज़ूरी के लिए बने और बिना निगरानी कोई काम कभी न हो।