AI बिना Hype के: एक काम करने वाले इंजीनियर की गाइड

ज्यादातर AI कंटेंट ऑनलाइन दो शिविरों में गिरता है: superintelligence के बारे में डर, या दावे कि chatbot मंगलवार तक आपकी नौकरी ले लेगा। दोनों ही आपको कुछ शिप करने में मदद नहीं करते। यह गाइड दोनों को छोड़ता है और बताता है कि वास्तव में असली प्रोजेक्ट में AI टूल्स की मौजूदा पीढ़ी को कैसे इस्तेमाल करें, जिसमें सीमाएं स्पष्ट बताई गई हों।

एक LLM असल में क्या करता है

एक बड़ा भाषा मॉडल जैसे GPT-4 या Llama 3 एक sequence में अगली token की भविष्यवाणी करता है, जिसे विशाल मात्रा में टेक्स्ट पर प्रशिक्षित किया गया है। बस यही। कोई internal fact-checker नहीं है, sessions के बीच कोई persistent memory नहीं है (जब तक आप एक न बनाएं), और समझ नहीं है उस तरीके से जैसे कोई व्यक्ति समझता है। जब आप इससे कोई सवाल पूछते हैं, तो यह आपके prompt का एक सांख्यिकीय रूप से संभावित continuation बना रहा है।

यह व्यावहारिक रूप से महत्वपूर्ण है: मॉडल आत्मविश्वास से एक Python function बनाएगा जो एक library method को कॉल करता है जो मौजूद नहीं है, क्योंकि वह method ऐसा लगता है जैसे library के पास हो सकता है। हमेशा कोड चलाएं। हमेशा API reference check करें। मॉडल output को एक first draft के रूप में लें एक तेज़, अच्छी तरह से पढ़े गए intern से जो कभी-कभी बिना जाने बुरा करता है।

एक असली workflow: कोड के लिए एक LLM का उपयोग

यह एक pattern है जो काम करता है, बस ChatGPT से "मुझे एक app बनाओ" पूछने की जगह:

1. Function signature और docstring खुद लिखें, types और edge cases specify करते हुए।
2. मॉडल से उस exact spec के विरुद्ध इसे implement करने के लिए कहें।
3. अपने आप से अलग से tests लिखें — मॉडल को tests लिखने के लिए न कहें जो उसने अभी लिखा है, वह तुच्छ रूप से pass होने वाले tests लिखने की प्रवृत्ति रखेगा।
4. Tests चलाएं। Failures को नए prompts के रूप में वापस feed करें, vague "यह काम नहीं करता" statements नहीं।

def parse_duration(text: str) -> int:
    """
    '1h30m', '45s', '2d' जैसी strings को total seconds में parse करें।
    Invalid input पर ValueError raise करें।
    """

मॉडल को यह exact contract देना एक loose description से कहीं बेहतर output देता है, और यह आपको test करने के लिए कुछ concrete देता है।

Retrieval-augmented generation, सरल शब्दों में

RAG को एक buzzword की तरह फेंका जाता है लेकिन mechanism सरल है: मॉडल ने training के दौरान जो याद किया है उस पर निर्भर करने की जगह, आप query time पर relevant documents fetch करते हैं और उन्हें prompt में डालते हैं।

एक बुनियादी setup:

1. अपने documents को chunk करें (500-1000 tokens प्रत्येक एक common starting point है)।
2. हर chunk को एक मॉडल जैसे text-embedding-3-small या एक open model जैसे bge-small-en से embed करें।
3. Vectors को कहीं store करें जैसे pgvector के साथ Postgres, या एक dedicated store जैसे Qdrant।
4. Query time पर, user के सवाल को embed करें, एक similarity search चलाएं (cosine distance standard है), और top-k chunks को prompt के साथ pull करें question के साथ।

SELECT content FROM docs
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;

यही कारण है कि एक chatbot जिसे एक cutoff date तक data पर प्रशिक्षित किया गया है, अभी भी पिछले हफ्ते आपके internal wiki के बारे में सवालों का जवाब दे सकता है। यह आपकी कंपनी के बारे में reasoning नहीं कर रहा है — यह आपके documents को पढ़ रहा है और उन्हें summarize कर रहा है।

जहां classic ML अभी भी जीतता है

हर समस्या को एक transformer की जरूरत नहीं है। अगर आप structured tabular data से churn की भविष्यवाणी कर रहे हैं — account age, usage frequency, support tickets — एक gradient-boosted tree model जैसे XGBoost या LightGBM आमतौर पर एक LLM-based approach को outperform करेगा, घंटों की जगह मिनटों में train करेगा, और चलाने में एक fraction cost करेगा। scikit-learn's RandomForestClassifier या XGBoost के लिए reach करें एक API call के लिए reach करने से पहले, खासकर जब आपका data एक spreadsheet में fit हो और आपका target variable एक clean number या category हो।

Cost और latency design constraints हैं, afterthoughts नहीं

एक GPT-4-class call प्रति token असली पैसा खर्च करता है और return करने में असली seconds लेता है। अगर आप एक ऐसी feature बना रहे हैं जो हर page load पर हर user के लिए चलती है, तो यह तेज़ी से जुड़ता है और latency दिखाई देगी। Aggressively cache करें, एक छोटे model जैसे GPT-4o-mini या एक local Llama 3 8B का उपयोग करें ऐसी किसी चीज़ के लिए जिसे top-tier reasoning की जरूरत नहीं है, और महंगे मॉडल calls को अपनी pipeline के उन हिस्सों के लिए reserve करें जहां quality वास्तव में मायने रखती है।

जिस विफलता mode के बारे में किसी ने आपको चेतावनी नहीं दी

Models कम नहीं, ज़्यादा hallucinate करते हैं जब आप उनसे उन चीजों के लिए कहते हैं जो उनके training distribution से थोड़ी बाहर हैं — obscure library versions, internal company jargon, recent CVE numbers। अगर answer बिल्कुल सही होना चाहिए (एक security advisory, एक legal citation, एक medical dose), तो generation को अकेले trust न करें। हर बार एक primary source के विरुद्ध verify करें, और उस verification step को अपनी pipeline में build करें बजाय इसके कि इसे बाद में human review पर trust करें।

AI tooling सचमुच उपयोगी है एक बार जब आप इसे सोचने की उम्मीद करना बंद कर देते हैं और इसे एक fast pattern-matcher के रूप में treat करना शुरू करते हैं जिसे check करना होगा। Verification step को day one से build करें और आपको real value मिलेगा इसके बजाय confident nonsense की एक stream के।

अगर आप आगे जाना चाहते हैं, तो Korra Studio के Python और Data Science tracks को देखें fundamentals के लिए जो इन tools के साथ काम करना productive बनाते हैं।