AI प्रोडक्ट वैसा मत बनाइए जैसा बाकी सब बना रहे हैं
(builder.io)- कई AI प्रोडक्ट ChatGPT जैसे बाहरी मॉडल को API से कॉल करने वाले wrapper बनकर रह जाते हैं, जिससे differentiation, cost, speed, और customization के जोखिम सीधे प्रोडक्ट के भीतर आ जाते हैं
- साधारण LLM कॉल वाला तरीका जल्दी बनाया जा सकता है, लेकिन उसे कोई भी कॉपी कर सकता है, और अगर OpenAI वही फीचर ChatGPT में जोड़ दे तो unique value बचाए रखना मुश्किल हो जाता है
- general-purpose LLM चलाने की लागत ऊंची होती है; GitHub Copilot जैसे प्रोडक्ट में $10 प्रति माह लेने पर भी औसत लागत $20 पड़ सकती है, और कुछ users पर $80 प्रति माह तक खर्च आ सकता है
- Builder के Visual Copilot ने Figma design को code में बदलने के लिए पहले सिर्फ LLM वाला तरीका आजमाया, लेकिन response delay और quality limits की वजह से अपनी toolchain पर स्विच किया
- व्यावहारिक रूप से पहले सामान्य code से समस्या हल करना, और सिर्फ उन संकरे हिस्सों में specialized AI model लगाना जिन्हें standard code से संभालना कठिन है, ज्यादा तेज, सस्ता और controllable होता है
साधारण LLM wrapper तरीके की सीमाएँ
- आज बन रहे कई AI प्रोडक्ट दूसरे मॉडल के ऊपर बने wrapper जैसे हैं, जो ChatGPT API को natural language input भेजते हैं और natural language output पाते हैं
- implementation आसान होता है और दिलचस्प फीचर जल्दी बनाए जा सकते हैं, लेकिन अगर प्रोडक्ट की unique value advanced AI tech पर टिकी हो तो copying का जोखिम बहुत बढ़ जाता है
- PDF chat app जैसे मामलों में एक व्यक्ति कुछ बनाता है, फिर कई लोग वैसा ही app बना लेते हैं, और बाद में OpenAI उसे सीधे ChatGPT में जोड़ देता है; ऐसा तब होता है जब differentiated technology कमज़ोर हो
- अगर आपका प्रोडक्ट सिर्फ एक बटन दबाकर ChatGPT को request भेजता है और response user को दिखा देता है, तो उसकी defensibility सबसे कम होती है
- अगर आपकी अपनी technology काफ़ी मजबूत हो और LLM सिर्फ छोटा लेकिन अहम सहायक हिस्सा हो, तो स्थिति बेहतर होती है, लेकिन cost और speed की समस्याएँ फिर भी बनी रहती हैं
लागत और speed, productization की व्यावहारिक बाधाएँ हैं
- LLM ने व्यापक generality पाने के लिए खुद को बड़ा और complex बनाया है, और उसी अनुपात में उसे चलाने की लागत भी बढ़ी है
- Wall Street Journal के अनुसार GitHub Copilot users से $10 प्रति माह लेता था, लेकिन औसत लागत $20 थी, और कुछ users ने GitHub पर $80 प्रति माह तक का खर्च डाला
- कई प्रोडक्ट्स को पूरे इंटरनेट पर train किए गए विशाल मॉडल की ज़रूरत नहीं होती; training scope का 99.9% किसी खास use case से असंबंधित हो सकता है
- ऐसी स्थिति बन सकती है जहाँ users जितना भुगतान करना चाहते हैं, उससे ज़्यादा LLM-based service चलाने में खर्च हो
- speed भी product experience को बहुत प्रभावित करती है
- ChatGPT की तरह जहाँ words एक-एक करके पढ़े जाते हैं, वहाँ धीमा output कुछ हद तक स्वीकार्य है
- लेकिन उन apps में जहाँ workflow के अगले step पर जाने से पहले पूरा response चाहिए, delay सीधे usability को खराब करता है
- Builder के Visual Copilot ने design को high-quality code में बदलने के लिए LLM conversion आजमाया, लेकिन पूरे design spec को डालकर token-by-token नया representation पाने में कई मिनट लगते थे, इसलिए यह व्यावहारिक नहीं था
- LLM जो representation लौटाता था वह इंसानों के पढ़ने लायक रूप में नहीं होता था, इसलिए loading state भी लगभग साधारण spinner जैसी लगती थी, और user experience अच्छा नहीं था
सिर्फ fine-tuning से customization पर्याप्त नहीं होता
- LLM fine-tuning को support करते हैं, इसलिए उन्हें कुछ हद तक मनचाही दिशा में समायोजित किया जा सकता है
- Builder ने Figma design को input और code को output बनाकर fine-tuning लागू की, लेकिन बहुत सारे examples देने पर भी quality बेहतर नहीं हुई
- नतीजा यह हुआ कि तरीका धीमा, महंगा और कम-गुणवत्ता वाला बना रहा, इसलिए दूसरा रास्ता चाहिए था
- चुना गया विकल्प अपनी toolchain बनाना था
- fine-tuned LLM
- खुद लिखा गया custom compiler
- खुद train किया गया model
- आजकल अपना model train करना सिर्फ data scientist या machine learning Ph.D. तक सीमित काम नहीं है; उचित अनुभव वाला developer भी यह कर सकता है
- यह approach ज्यादा तेज, ज्यादा reliable, और ज्यादा सस्ता व differentiated product बनाने में मदद करती है
जटिल AI प्रोडक्ट एक विशाल मॉडल नहीं, बल्कि toolchain से बनते हैं
- AI प्रोडक्ट्स को लेकर एक आम गलतफहमी यह है कि एक ही smart model सारी core technology को संभाल लेता है
- self-driving car भी ऐसी नहीं होती कि camera, sensor, और GPS input एक ही विशाल AI को दिया जाए और वह सीधे right turn जैसा action output कर दे
- वास्तव में कई specialized models और सामान्य code आपस में जुड़े होते हैं
- computer vision model objects को ढूंढते और पहचानते हैं
- predictive decision models दूसरे लोगों के व्यवहार का अनुमान लगाते हैं
- natural language processing models voice commands को समझते हैं
- और बहुत सारा सामान्य code व logic मिलकर final result बनाते हैं
- self-driving car बहुत ज्यादा जटिल उदाहरण है; सामान्य AI product शुरू करते समय इतनी complexity की ज़रूरत नहीं होती
- car features भी एक साथ पूर्ण रूप में नहीं आए; वे auto-parking, proximity auto-stop जैसे features से शुरू हुए और फिर lane departure correction व full driving decisions तक layers जुड़ती गईं
- software की तरह AI features भी एक layer के ऊपर अगली layer जोड़ते हुए बनाए जाते हैं
पहले सामान्य code से हल करें, फिर ज़रूरत वाली जगहों पर specialized AI जोड़ें
- Visual Copilot approach में एक अहम शुरुआत यह है कि शुरू से AI का इस्तेमाल न किया जाए
- सामान्य programming से problem space को explore करें, और पहले यह पहचानें कि वास्तव में specialized model कहाँ चाहिए
- Figma data को बड़े पैमाने पर model में डालकर सीधे finished code पाने वाला “supermodel” approach बहुत जटिल है
- support करने के लिए frameworks अनेक हैं
- styling options और customization बहुत हैं
- नए data को शामिल करते हुए लगातार retrain करना कठिन है
- यह इतना complex, slow, और expensive हो सकता है कि product launch करना ही मुश्किल हो जाए
- Builder ने पहले यह खोजा कि AI के बिना कहाँ तक पहुँचा जा सकता है
- हर design node को code में व्यक्त किए जा सकने वाले target में बदलना था
- image, background, foreground जैसे elements को बारीकी से समझना था
- किसी भी input को responsive बनाने के तरीकों को बहुत सटीक ढंग से संभालना था
- hand-written logic से ऐसे कई refined algorithms बनाए गए, जैसे vertically stacked items को flex column और साथ-साथ रखी items को flex row बनाना
- standard code की सीमा जहाँ आकर खत्म हुई, वहीं AI जोड़ा गया
- उदाहरण के लिए कौन-सी layers को एक image में merge करना चाहिए, यह auto-detect करना इंसानी perception के लिए आसान है, लेकिन imperative JavaScript code से आसान नहीं था
- object detection जैसे अच्छी तरह स्थापित model types को Google Vertex AI जैसे products में GUI से चुनकर, data तैयार करके upload करने के तरीके से train किया जा सकता है
- data generation के लिए इंटरनेट का उपयोग किया जा सकता है
- puppeteer से browser में website खोली जाती है और screenshot लिया जाता है
- HTML को traverse करके
imgtags ढूंढे जाते हैं - image position को output data और webpage screenshot को input data की तरह इस्तेमाल किया जाता है
- इस तरह child image coordinates और original image मिलते हैं, जिन्हें object detection model के training data के रूप में इस्तेमाल किया जा सकता है
- code और specialized AI model को जोड़ने पर design चुनकर Generate code क्लिक करने के बाद लगभग 1 second रुकते ही Builder.io पर पहुँचा जा सकता है
- Builder में पूरी तरह responsive website और customizable high-quality code मिलता है, साथ ही कई frameworks और options का support भी
अपने model पर नियंत्रण होने से मिलने वाले product फायदे
- अपना model होने पर आप सिर्फ बाहरी मॉडल को wrap करने तक सीमित नहीं रहते, बल्कि model को लगातार बेहतर भी बना सकते हैं
- अगर आप सिर्फ OpenAI जैसे बाहरी मॉडल पर निर्भर हैं, तो यह गारंटी नहीं दे सकते कि वह किसी खास use case में कब ज्यादा smart, तेज, या सस्ता होगा
- prompt engineering और fine-tuning से मिलने वाला control भी सीमित होता है
- Visual Copilot अभी beta में है, इसलिए कुछ designs अभी भी सही से import नहीं होते, लेकिन user feedback के आधार पर रोज़ improvements deploy किए जा रहे हैं
- अपनी technology पर control होने से privacy की ज़रूरतों को बेहतर ढंग से पूरा किया जा सकता है
- बड़े privacy-focused enterprises अक्सर बताते हैं कि वे OpenAI या OpenAI इस्तेमाल करने वाले products का उपयोग नहीं कर सकते
- उनकी यह मांग होती है कि data किसी unauthorized system में न जाए
- Builder पूरी technology को control करता है, इसलिए उच्च privacy standards लागू कर सकता है
- LLM stage अनिवार्य नहीं, लगभग वैकल्पिक है, इसलिए उसे बंद भी किया जा सकता है
- enterprise अपने LLM भी जोड़ सकते हैं
- पूरी तरह in-house model
llama2fork- अपना enterprise OpenAI instance
- या कोई दूसरा model
- AI का उपयोग जितना कम हो सके उतना कम करना चाहिए, और सामान्य code को तेज, reliable, deterministic, तथा debug, fix, manage और test करने में आसान आधार बने रहना चाहिए
- product का जादू पूरे सिस्टम को AI से बदल देने में नहीं, बल्कि छोटे लेकिन निर्णायक हिस्सों में AI model इस्तेमाल करने में है
1 टिप्पणियां
Hacker News की राय
लेख के समग्र आशय से मैं सहमत हूँ, लेकिन लेखक ने जो implementation तरीका सुझाया है, शायद मैं उसे नहीं चुनूँगा
मेरा निष्कर्ष यह है कि LLM पर बहुत ज़्यादा निर्भर नहीं होना चाहिए। सौंपे जाने वाले काम के दायरे में भी, और किसी एक खास LLM से बँधने से भी बचना सही है
उदाहरण के लिए, अगर आप अंदरूनी तौर पर OpenAI का इस्तेमाल करें भी, तो ChatGPT से सीधी टक्कर लेने वाला प्रोडक्ट लंबी अवधि में नुकसानदेह हो सकता है। अगर आप ऐसा ऐप बनाते हैं जो chatbot से होटल और flight बुक कराता है, तो कभी न कभी ChatGPT, Microsoft, या Google वही सुविधा इससे बेहतर देकर छोटे बिज़नेस को अप्रासंगिक बना सकते हैं
OpenAI SDK जैसी चीज़ों पर ज़रूरत से ज़्यादा निर्भर होना भी समय की बर्बादी लगता है, और सीधे REST API कॉल करना ज़्यादा लचीला है
हालांकि tool chain में compiler जोड़ना अलग मुद्दा है। हर बार compiler जोड़ने पर अनावश्यक जटिलता और किसी खास tool पर निर्भरता बढ़ती है। React या Svelte से काम चल सकता है, तो component cross-compiler का इस्तेमाल करना ऐसा लगता है जैसे web app बनाने के लिए सीखने वाली एक और चीज़ बढ़ गई हो
मुझे लगता है कि लेख का अंतिम संदेश “अपने लक्ष्य तक पहुँचने के लिए सबसे efficient tool chain बनाओ” होना चाहिए। बहुत सारे tools जोड़ देने से अपने आप value नहीं बनती, और न ही सिर्फ इसलिए value बनती है कि बाकी सब लोग वही कर रहे हैं। यह बात सिर्फ LLM app integration पर नहीं, बल्कि पूरे software engineering पर लागू होती है
AI इसे कैसे अलग बनाएगा, और क्या अंत में यह भी उन्हीं सीमाओं से नहीं टकराएगा, यह मुझे स्पष्ट नहीं है
यह अनोखा होगा और आसानी से कॉपी भी नहीं होगा, लेकिन जिन languages को support करना है उन्हें देखते हुए maintenance cost बहुत भारी होगी
यह अतिरिक्त abstraction layer थोड़ा factory-factory-factory जैसा एहसास देती है
बल्कि AI में flight search से भी ज़्यादा specialization की गुंजाइश है
specialized work chatbots में, अब जबकि base language understanding काफ़ी अच्छी हो चुकी है, generic language model की quality सबसे अहम तत्व नहीं रह जाती। मेरी पसंद के हिसाब से ढला हुआ और संबंधित niche APIs से integrated travel booking chatbot, सिर्फ सवाल थोड़े बेहतर parse करने वाले उस generic tool से आसानी से नहीं हारेगा जो Expedia से सब कुछ बुक कराने की कोशिश करता है
ऐसे बाज़ार में एक बार अच्छी recommendation या बुरी recommendation मिलने के आधार पर brand loyalty या विरक्ति भी पैदा होती है, इसलिए इसे winner-takes-all के क़रीब मानना भी कठिन है
ब्लॉग पोस्ट का असली सार तो वह था ही नहीं
उनका प्रोडक्ट Figma design files को React code में अपने आप बदलने वाला tool है। इस समस्या को सामान्य code से हल करने का साधन ही compiler है
वे सबको compiler इस्तेमाल करने के लिए नहीं कह रहे
इस संदर्भ में compiler पर सामान्य आलोचना ठीक से फिट नहीं बैठती। विकल्प यह है कि ChatGPT को compiler की तरह इस्तेमाल किया जाए, और लेख में काफ़ी भरोसेमंद ढंग से कहा गया है कि वह उससे भी बदतर है। या फिर क्या मतलब यह है कि React code generate करने वाला प्रोडक्ट ही खराब है
यह सोचने पर मजबूर करने वाला लेख है, और मैं इस बात से सहमत हूँ कि “जितना संभव हो उतनी देर तक AI का इस्तेमाल मत करो”
AI का इस्तेमाल उन कामों के लिए करना सबसे अच्छा है जो सिर्फ AI से ही संभव हैं। अगर कोई feature बनाने या समस्या हल करने का AI के बिना तरीका है, तो वही बेहतर है
अब जब लगभग हर किसी को top-tier models तक लगभग समान पहुँच मिल गई है, तो अच्छे products की परिभाषा अंततः AI से बाहर की चीज़ों—यानी workflow, UI, user experience, performance जैसे पुराने तत्वों—से ही होगी
लेकिन “अपना खुद का model train करो” वाली सलाह को लेकर मुझे भरोसा नहीं है। यह product को जल्दी पुराना बना देने का रास्ता हो सकता है। थोड़ी देर के लिए differentiation मिल सकता है, लेकिन 6~12 महीनों में अगर OpenAI या बहुत ज़्यादा पूँजी वाला कोई competitor उससे कहीं बेहतर model ले आए, तो वह differentiated model सीधे technical debt बन जाएगा
छोटे startup के लिए models पर compete करने की कोशिश बहुत बड़ा distraction लगती है। यह Postgres या MySQL इस्तेमाल करने के बजाय खुद का database बनाने जैसा है। बेशक moat और copy करना मुश्किल product ज़रूरी है, लेकिन वह ऐसा क्षेत्र होना चाहिए जहाँ उपलब्ध resources के साथ आप वास्तविक रूप से सर्वश्रेष्ठ बन सकें
फिर ChatGPT आया, और competitors का सारा काम पल भर में पुराना पड़ गया, जबकि वह कुछ ही हफ़्तों में AI features में उनकी बराबरी कर सका
क्या बनाना चाहिए, इस पर वह सही था, बस वजह ग़लत थी, और नतीजे में बिज़नेस को बहुत बड़ा फायदा हुआ
differentiation वास्तव में काफ़ी महत्वपूर्ण तत्व है
यह अच्छी पोस्ट है, और लगता है कि ज़्यादातर नए AI startup पर लागू होगी। मेरी सलाह तो यह है कि शुरू से AI product ही मत बनाइए
“X product” वाला फ्रेमवर्क बहुत कम ही ग्राहकों के लिए मूल्य बनाने की दिशा में ले जाता है। जैसे web3 product, observability product, machine vision product, AI product वगैरह
जैसे हर अच्छे startup idea में होता है, असली बात यह है कि किसी उभरती हुई तकनीक को इस्तेमाल करने की इच्छा में समस्या पर उसे जबरन फिट न किया जाए, बल्कि शुरुआत वास्तविक user needs से हो। किसी hype-चढ़ी तकनीक पर UI चिपका देने से user needs पूरी नहीं हो जातीं
मैं यह बात LLM से नफरत की वजह से नहीं कह रहा, लेकिन ऑफलाइन जिन ज़्यादातर लोगों को मैं जानता हूँ, उन्हें product के रूप में chatbot से interact करना पसंद नहीं है। हाल ही में घर बदलते समय मुझे energy, water, और internet providers के customer support bots से निपटना पड़ा, और वे सब भयानक थे
“GPT शानदार है” से शुरुआत करके custom chatbot बनाना, मेरी नज़र में, न तो वास्तविक user needs हल करता है और न ही टिकाऊ business बनाता है
यह पता लगाना भी कि कोई समस्या इतनी वास्तविक है कि उस पर technology cost खर्च की जाए, कई technologists के comfort zone से बाहर होता है। हम मान लेते हैं कि समस्या असली है, या उससे भी बुरा, यह आशा करते हैं कि वह असली हो, और सीधे solution पर कूद पड़ते हैं। क्योंकि बनाना हमारा परिचित क्षेत्र है
यह रवैया या प्रक्रिया अपने-आप में गलत नहीं है। technologists ने जब भी वास्तविक समस्याएँ हल की हैं, कई बार वह असली समस्या बनाते, iterate करते, और छोड़ते जाने की प्रक्रिया में संयोग से सामने आई है
इसलिए technologists के लिए वास्तविक समस्या ढूँढने का सबसे अच्छा तरीका, problem discovery पर बहुत देर तक टिके रहने से बेहतर, एक बेहतर launch-iterate-stop cycle रखना हो सकता है। ऐसा cycle जो मौजूदा usage देखकर future का अनुमान लगाए, और जल्दी तय करे कि क्या नहीं बनाना है
कई technology leaders की biographies पढ़ने के बाद, मुझे लगता है कि उन्हें अलग करने वाली मुख्य क्षमता यह थी कि वे बहुत बुनियादी MVP से शुरू करके, कम समय में future demand के प्रति अपनी intuition को exponential तरीके से refine कर लेते थे
कुछ साल पहले भी chatbot थे, और लगभग हर बड़ी company के पास उनके लिए strategy थी। सोच यह थी कि call center staff को काफी कम किया जा सकता है और customer experience बेहतर बनाया जा सकता है
समस्या सिर्फ conversation quality की नहीं थी। बहुत से users के लिए महत्वपूर्ण बात सिर्फ अपने सवाल का जवाब पाना नहीं, बल्कि यह मानवीय जुड़ाव महसूस करना भी था कि सामने कोई इंसान उनकी बात सुन रहा है
मैं चाहता बस यह हूँ कि काम जितनी जल्दी हो सके हो जाए; इससे फर्क नहीं पड़ता कि सामने सच में कोई इंसान है या नहीं
अब तक chatbot मददगार इसलिए नहीं रहे, क्योंकि उन्होंने प्रक्रिया में समय और झुंझलाहट ही बढ़ाई है। पहला कदम अक्सर chatbot से फोन नंबर उगलवाना या किसी तरह agent तक पहुँच पाना होता था
बेशक OpenAI से पहले के chatbot बहुत खराब थे। लेकिन अगर OpenAI के बाद chatbot सचमुच इतने शानदार हैं, तो मुझे समझ नहीं आता कि लोग उनका इस्तेमाल क्यों न करें
कुछ साल पहले यह blockchain था। अगला क्या होगा, पता नहीं, लेकिन यह साफ दिख रहा है कि LinkedIn का “technologist” network crypto startup से AI startup की तरफ शिफ्ट हो चुका है
यह launch speed के बदले बहुत बड़ा tradeoff लगता है
अगर launch करने में 6–12 महीने लगते हैं, तो तब तक दूसरी teams hosted models का सीधे इस्तेमाल करके दो बार iterate कर चुकी होंगी और अपना वास्तविक customer base बना चुकी होंगी। और तब आप पहले customer को v0.1 दिखाएँगे, और वह कहेगा कि उसे तो वास्तव में कुछ और चाहिए था
तब बात prompt को थोड़ा-बहुत बदलने की नहीं रहेगी, बल्कि compiler और toolchain, stack के ऊपर और नीचे, सब कुछ फिर से code करना पड़ेगा
अगर आपको अपने customers और requirements की वाकई बहुत अच्छी समझ है, तो यह ठीक हो सकता है, लेकिन ऐसी आसान स्थिति में भी generic और महँगे होने के बावजूद hosted models से concept को जल्दी validate क्यों नहीं किया जाता, इस पर मुझे ज़्यादा संदेह है। यह उसी तरह की समस्या है जैसे कहा जाता है कि premature optimization सारी बुराइयों की जड़ है
technology और pipeline की बहुत बात थी, लेकिन अगर यह स्पष्ट ही नहीं है कि कौन-सा product बनाना है और कौन-सी problem हल करनी है, तो उसका कोई मतलब नहीं
यह वैसा ही है जैसे users के सामने इस पर बहस करना कि SOAP बेहतर है या REST। users को इससे फर्क नहीं पड़ता कि आपने इसे कैसे बनाया है
आप competition के नज़रिये से इसे ज़रूरत से ज़्यादा सोच रहे हैं। बस ऐसी चीज़ बनाइए जिसे आसानी से copy न किया जा सके
उसके कई तरीके हो सकते हैं, लेकिन competition के नज़रिये से ज़रूरी नियम बस वही एक है
लगभग हर vertical market में कुल market का करीब 100% हिस्सा अभी भी खुला पड़ा है
technical differentiation सिर्फ एक छोटा हिस्सा है; उससे पहले महत्वपूर्ण चीज़ reach है
यह 1 billion users तक पहुँचने की race है, और हमारे जैसे B2B के लिए शायद 1 million users तक पहुँचने की race। साथ ही यह सबसे बेहतर value की race है—यानी कौन-सी problem हल होती है और user experience कैसा है—न कि सबसे बेहतर technical specs की race
अगर आपका differentiation ऐसी चीज़ है जिसे दूसरे लोग OAI इस्तेमाल करके copy नहीं कर सकते, तो OAI इस्तेमाल करना भी सुरक्षित है
अगर आपका एकमात्र differentiation सिर्फ OAI इस्तेमाल करना है, तो आप वैसे भी खत्म हैं
कुल मिलाकर, जो स्थिति अंत में पेश की गई है, उससे मैं broadly सहमत हूँ। हमारा product भी state machine जैसे control flow के भीतर LLM का इस्तेमाल करता है, और वह अच्छी तरह काम करता है
लेकिन लेखक की भावना से मैं सहमत नहीं हूँ। अगर कोई developer सिर्फ ChatGPT web UI इस्तेमाल कर चुका है, तो उसे “AI wrapper” technology को 100% छूकर और बनाकर देखना चाहिए
क्योंकि top-tier models की सीमाएँ खुद ढूँढने से पहले यह देख पाना मुश्किल है कि पारंपरिक software stack के भीतर LLM को कहाँ और कैसे इस्तेमाल करना चाहिए
लेखक की company भी आखिरकार इसी रास्ते से गुज़री लगती है। शुरुआत में उन्होंने Figma-to-code LLM-based prototype बनाया, वह “कुछ हद तक” चला, और फिर process की खामियाँ दिखने लगीं
इसलिए मेरा मानना है कि GPT-4-Vision जैसी किसी चीज़ से “AI-based trading card grading system” हो या जो भी आप बनाना चाहें, पहले उसे बनाकर देखना बेहतर है, और फिर builder.io की तरह उसे वास्तविक product की तरह काम कराने का तरीका ढूँढना चाहिए
लगता है कि जल्द ही AI कई तरह के software में built-in हो जाएगा। उस समय यह वाकई शानदार भी होगा और डरावना भी
एक आसान उदाहरण email client है। अगर कोई निर्णय या पुष्टि मांगता है, तो AI सवाल निकालकर radio button दिखा सकता है
उदाहरण: प्रस्तावित मीटिंग समय स्वीकार करें: [शुक्रवार 10:00] [सोमवार 11:30] [दूसरा समय सुझाएँ]
George पूछ रहा है कि क्या वह draft प्रकाशित कर सकता है: [हाँ] [नहीं]
Zendesk जैसे customer support ticket software में शायद पहले से ही AI है। बहुत-सी support requests का जवाब शायद पहले ही लगभग अपने-आप दिया जा रहा होगा
HR विभाग भी AI से job applications छाँट सकता है, इंटरनेट पर उम्मीदवार के बारे में अतिरिक्त जानकारी खोज सकता है, और फिर standardized database entries बना सकता है। बेशक, इसमें बहुत खामियाँ हो सकती हैं
दिलचस्प बात ऐसे ही applications हैं, कोई और ChatGPT extension या plugin नहीं
हर नए email पर pipeline चलाकर उससे कुछ actions suggest करवाने का इरादा है
अभी दिमाग में कई approaches चल रही हैं, लेकिन यह पहले से काफी संभव लग रहा है
प्रस्तावना थोड़ी ज़्यादा चमकदार और बढ़ा-चढ़ाकर लिखी हुई लगती है। उदाहरण के लिए, LLM इतने महंगे भी नहीं हैं, Copilot हर user पर घाटा कर रहा है वाला WSJ दावा बहुत भरोसेमंद नहीं लगता, और यह भी कहना मुश्किल है कि LLM हमेशा “दर्दनाक रूप से धीमे” होते हैं
फिर भी, लेख की असली सलाह काफ़ी उचित है
जहाँ तक संभव हो, ज़्यादा से ज़्यादा हिस्से code से संभालो, और जो code से नहीं हो सकता उसके लिए specialized AI इस्तेमाल करो
यह समझदारी की बात है, लेकिन कोई खास नई बात नहीं
उम्मीद थी कि इसमें यह और गहराई से बताया जाएगा कि वास्तव में उपयोगी और अच्छे AI products कैसे बनाए जाएँ। हाल में Humane launch जैसी कई कोशिशें हुई हैं, लेकिन अभी तक सफलताएँ ज़्यादा नहीं दिखतीं
यह लेख AI products कैसे बनाए जाएँ, इस पर काफ़ी केंद्रित है, लेकिन व्यक्तिगत रूप से मुझे लगता है कि “AI products” की सफलता और विफलता का फ़ैसला differentiation, cost, speed, या model customization से ज़्यादा इस बात पर निर्भर करता है कि वे वास्तव में उपयोगी हैं या नहीं
दुर्भाग्य से, अब तक मैंने जो ज़्यादातर products देखे हैं, वे ऐसी solutions लगते हैं जो किसी problem की तलाश में हों
मुझे लगता है कि अभी companies को अपने product के इस्तेमाल में सबसे उबाऊ और दोहराए जाने वाले हिस्सों को पहचानना चाहिए, और देखना चाहिए कि AI से उन्हें reliably कैसे सरल बनाया जा सकता है
हर hype cycle की तरह, अगर आपके पास सिर्फ हथौड़ा है, तो हर चीज़ कील जैसी दिखती है
कुछ समय पहले वह हथौड़ा blockchain था, और अब AI है
अगर आप blockchain के वादों से प्रभावित होने लायक़ भोले थे, तो यह देखकर निराश होना स्वाभाविक है कि AI कोई ऐसा जल्दी अमीर बनाने वाला pyramid scheme नहीं है जो बिना समय, ऊर्जा, या मौलिक सोच के आपको लाखों डॉलर कमा दे
अगर आप सिर्फ वही ढूँढ रहे हैं, तो आप निराश होते रहेंगे, और होना भी चाहिए
AI में blockchain की तुलना में कहीं ज़्यादा कुछ है। दोनों को एक ही स्तर पर रखना यह दिखाता है कि आप दोनों में से किसी को भी ठीक से नहीं समझते