LLM के साथ एक साल तक बनाते हुए सीखे गए सबक

• बड़े भाषा मॉडल (LLM) का उपयोग करके डेवलपमेंट के लिए यह एक रोमांचक समय है
  • पिछले 1 साल में LLM वास्तविक applications के लिए "काफी अच्छे" स्तर तक पहुंच गए हैं, और हर साल बेहतर और सस्ते होते जा रहे हैं
  • social media demos के साथ, अनुमान है कि 2025 तक AI में लगभग 200 अरब डॉलर का निवेश होगा
  • vendors के API की वजह से LLM पहले से अधिक सुलभ हो गए हैं, जिससे सिर्फ ML engineers और scientists ही नहीं बल्कि हर कोई products में intelligence बना सकता है
• AI के साथ बनाना शुरू करने की बाधा कम हुई है, लेकिन demo से आगे बढ़कर प्रभावी products और systems बनाना अब भी कठिन है
• हम पिछले 1 साल से निर्माण कर रहे हैं, और इस प्रक्रिया में हमने कई कठिनाइयाँ देखी हैं
  • हम जो सीखे हैं उसे साझा करना चाहते हैं ताकि आप हमारी गलतियों से बच सकें और तेज़ी से iterate कर सकें
• यह लेख तीन भागों में बना है:
  1. Tactical (सामरिक): prompting, RAG, workflow engineering, evaluation और monitoring के लिए कुछ व्यवहारिक प्रथाएँ
     • यह LLM के साथ काम करने वाले practitioners या weekend projects करने वालों के लिए लिखा गया है
  2. Operational (संचालनात्मक): product launch से जुड़े संगठनात्मक और रोज़मर्रा के मुद्दे, और प्रभावी टीम कैसे बनाई जाए
     • यह उन product/tech leaders के लिए है जो टिकाऊ और स्थिर deployment करना चाहते हैं
  3. Strategic (रणनीतिक): "PMF से पहले GPU नहीं", "model नहीं system पर फोकस करें" जैसी रायों के साथ दीर्घकालिक, व्यापक दृष्टिकोण और iteration के तरीके
     • यह founders और executives को ध्यान में रखकर लिखा गया है
• इस guide का लक्ष्य LLM का उपयोग करके सफल products बनाने के लिए एक व्यावहारिक मार्गदर्शिका बनना है
  • यह हमारे अपने अनुभव से निकली है और पूरे industry से उदाहरण प्रस्तुत करती है

[सामरिक: LLM उपयोग का मूल]

• इस section में हम उभरते हुए LLM stack के मुख्य components के लिए best practices साझा करते हैं
  • इसमें quality और reliability बढ़ाने के लिए prompting tips, outputs का मूल्यांकन करने की strategies, और grounding बेहतर करने के लिए retrieval-augmented generation के ideas शामिल हैं
  • साथ ही हम human-in-the-loop workflows को कैसे design किया जाए, यह भी देखेंगे

सामरिक 1. Prompting

• नई application विकसित करते समय हम prompting से शुरुआत करने की सिफारिश करते हैं
  • prompting के महत्व को कम या ज़्यादा आँकना आसान है
  • सही prompting techniques का ठीक से इस्तेमाल किया जाए तो उनसे बहुत आगे तक जाया जा सकता है, इसलिए अक्सर इसे कम आँका जाता है
  • वहीं prompt-based applications को सही ढंग से काम कराने के लिए prompt के आसपास काफी engineering भी चाहिए होती है, इसलिए कभी-कभी इसे ज़रूरत से ज़्यादा आँका जाता है

बुनियादी prompting techniques का पूरा लाभ उठाने पर फोकस करें

• कुछ prompting techniques ऐसी हैं जो अलग-अलग models और tasks में performance सुधारने में लगातार मदद करती हैं
  • इनमें N-shot prompts + in-context learning, Chain-of-Thought, और प्रासंगिक resources देना शामिल है
• N-shot prompts और in-context learning
  • N-shot prompts के जरिए in-context learning का विचार यह है कि LLM को task के कुछ demonstrations और ऐसे examples दिए जाएँ जो output को आपकी अपेक्षा के अनुरूप करें
  • अगर N बहुत कम हो, तो model उन खास examples पर ज़रूरत से ज़्यादा अटक सकता है और उसकी generalization क्षमता घट सकती है
  • अनुभव के आधार पर N ≥ 5 का लक्ष्य रखें, और कई दर्जन examples तक जाने से न डरें
  • examples अपेक्षित input distribution का प्रतिनिधित्व करने चाहिए
  • पूरा input-output pair देना हमेशा ज़रूरी नहीं है; कई मामलों में वांछित output के examples ही पर्याप्त होते हैं
  • अगर आप ऐसा LLM इस्तेमाल कर रहे हैं जो tool use को support करता है, तो N-shot examples में भी वही tools इस्तेमाल होने चाहिए जिन्हें आप agent से इस्तेमाल करवाना चाहते हैं
• Chain-of-Thought (CoT) prompting
  • CoT prompting में LLM को अंतिम उत्तर देने से पहले अपनी सोचने की प्रक्रिया समझाने के लिए प्रोत्साहित किया जाता है
  • इसे ऐसे समझ सकते हैं जैसे आप LLM को एक sketchpad दे रहे हों ताकि उसे सब कुछ memory में ही न करना पड़े
  • मूल approach सिर्फ निर्देशों में "चरण-दर-चरण सोचें" जैसे वाक्यांश जोड़ना था, लेकिन हमने पाया कि CoT को और अधिक specific बनाना मददगार होता है
  • 1–2 वाक्यों की specificity जोड़ने से अक्सर hallucination की दर काफी कम हो जाती है
  • हाल में इस बात पर सवाल उठे हैं कि क्या यह technique उतनी शक्तिशाली है जितना लोग मानते हैं
  • साथ ही CoT इस्तेमाल होने पर reasoning के दौरान वास्तव में क्या होता है, इस पर भी काफी बहस है
  • फिर भी, जहाँ संभव हो, यह प्रयोग करने लायक technique है
• प्रासंगिक resources देना
  • प्रासंगिक resources देना model के knowledge base को बढ़ाने, hallucination कम करने और user trust बढ़ाने का एक शक्तिशाली mechanism है
  • यह अक्सर Retrieval Augmented Generation (RAG) के जरिए किया जाता है
  • model को ऐसे text snippets देना जिन्हें वह सीधे अपने response में उपयोग कर सके, एक आवश्यक technique है
  • प्रासंगिक resources देते समय केवल उन्हें शामिल कर देना पर्याप्त नहीं है
    • आपको model को यह निर्देश देना चाहिए कि वह resources के उपयोग को प्राथमिकता दे, उनका सीधे संदर्भ ले, और कभी-कभी यह भी बताए कि जब resources पर्याप्त न हों
  • ये बातें agent responses को resource corpus में "ground" करने में मदद करती हैं

input और output को संरचित करें

• structured input और output model को input बेहतर समझने और ऐसे outputs लौटाने में मदद करते हैं जिन्हें downstream systems के साथ भरोसेमंद तरीके से जोड़ा जा सके
  • input में serialization format जोड़ने से context के tokens के बीच संबंध, कुछ खास tokens के लिए अतिरिक्त metadata (जैसे type), या request को model के training data में मौजूद समान examples से जोड़ने में मदद मिल सकती है
  • उदाहरण के लिए, इंटरनेट पर SQL लिखने से जुड़े कई सवाल SQL schema बताने से शुरू होते हैं
    • इसलिए Text-to-SQL के लिए प्रभावी prompting में structured schema definitions शामिल होनी चाहिए
• structured output भी इसी तरह का उद्देश्य पूरा करते हैं, लेकिन वे system के downstream components के साथ integration को आसान बनाते हैं
  • Instructor और Outlines structured output के लिए अच्छी तरह काम करते हैं
    • (अगर आप LLM API SDK ला रहे हैं तो Instructor का उपयोग करें, और अगर self-hosted model के लिए Huggingface ला रहे हैं तो Outlines का उपयोग करें)
  • structured input tasks को स्पष्ट रूप से व्यक्त करते हैं और training data के format से मिलते-जुलते होते हैं, इसलिए बेहतर output की संभावना बढ़ती है
• structured input का उपयोग करते समय ध्यान रखें कि हर LLM family की अपनी पसंदीदा शैली होती है
  • Claude <xml> को पसंद करता है, जबकि GPT Markdown और JSON को पसंद करता है
  • XML का उपयोग करने पर आप <response> tag देकर Claude के response को पहले से भर भी सकते हैं

छोटे prompts बनाएं जो एक काम बहुत अच्छी तरह करें

• software में एक आम anti-pattern/code smell वह "God Object" है जो सब कुछ करने वाली एक single class या function होती है
  • यही बात prompts पर भी लागू होती है
• prompts आमतौर पर सरल रूप में शुरू होते हैं
  • आप कुछ वाक्यों के निर्देश और कुछ examples से शुरुआत कर सकते हैं
  • लेकिन performance सुधारने और अधिक edge cases संभालने की कोशिश में complexity बढ़ती जाती है
    • और निर्देश, multi-step reasoning, दर्जनों examples आदि जुड़ते जाते हैं
  • अंत में शुरुआत का सरल prompt 2,000 tokens का Frankenstein बन जाता है
    • ऊपर से, अधिक सामान्य और intuitive inputs पर performance उल्टा घट जाती है
    • GoDaddy ने इस समस्या को LLM बनाते समय सीखे गए सबकों में नंबर 1 बताया है
• जैसे आप systems और code को सरल रखने की कोशिश करते हैं, वैसे ही prompts भी सरल होने चाहिए
  • meeting transcript summarizer के लिए एक single all-in-one prompt उपयोग करने के बजाय, इसे इस तरह चरणों में बाँटा जा सकता है
    • मुख्य decisions, action items, और owners को structured format में निकालें
    • निकाली गई details को मूल transcript से मिलाकर consistency जाँचें
    • structured details से एक concise summary तैयार करें
• परिणामस्वरूप, आप एक single prompt को कई सरल, focused और समझने में आसान prompts में बाँट देते हैं
  • इस तरह बाँटने पर अब हर prompt को अलग-अलग iterate और evaluate किया जा सकता है

context tokens बनाना

• एजेंट को वास्तव में भेजे जाने वाले context की मात्रा के बारे में धारणाओं पर दोबारा विचार करना और उन्हें चुनौती देना चाहिए
  • Michelangelo की तरह context की मूर्ति गढ़ने के बजाय, अनावश्यक सामग्री को हटाकर मूर्ति को उभरने देना चाहिए
  • RAG संभावित रूप से प्रासंगिक संगमरमर के सभी ब्लॉक इकट्ठा करने का एक व्यापक तरीका है, लेकिन जो चाहिए उसे निकालने के लिए आप क्या कर रहे हैं?
• यह पाया गया कि मॉडल को भेजे जाने वाले अंतिम prompt को लेकर, उसे सभी context construction, meta prompting, और RAG results के साथ एक खाली पेज पर रखकर पढ़ना context पर पुनर्विचार करने में मदद करता है
  • इस तरीके से दोहराव, आत्म-विरोधी भाषा, और गलत format वाले हिस्सों की पहचान की जा सकती है
• एक और प्रमुख optimization context की संरचना है
  • Bag-of-docs representation इंसानों के लिए मददगार नहीं है, इसलिए यह मानकर नहीं चलना चाहिए कि यह एजेंट के लिए अच्छा होगा
  • context के हर हिस्से के बीच के संबंधों को उभारने और extraction को जितना संभव हो उतना सरल बनाने के लिए context को कैसे व्यवस्थित किया जाए, इस पर सावधानी से विचार करना चाहिए

रणनीति 2. सूचना पुनर्प्राप्ति / RAG

• prompting के अलावा, LLM को steer करने का एक और प्रभावी तरीका यह है कि prompt के हिस्से के रूप में knowledge दिया जाए
  • इससे LLM दिए गए context पर ground होता है, और यही in-context learning में उपयोग होता है
  • इसे Retrieval-Augmented Generation (RAG) कहा जाता है
  • practitioners ने पाया है कि RAG knowledge देने और output सुधारने में प्रभावी है, और fine-tuning की तुलना में बहुत कम मेहनत और लागत लेता है
  • RAG उतना ही अच्छा होता है जितनी retrieved documents की relevance, density, और detail होती है

RAG output की गुणवत्ता retrieved documents की गुणवत्ता पर निर्भर करती है, और कुछ कारकों पर विचार किया जा सकता है

• पहला और सबसे स्पष्ट metric है "relevance"
  • इसे आमतौर पर Mean Reciprocal Rank (MRR) या Normalized Discounted Cumulative Gain (NDCG) जैसे ranking metrics से मापा जाता है
  • MRR यह आकलन करता है कि सिस्टम ranked list में पहले relevant result को कितनी अच्छी तरह रखता है, जबकि NDCG सभी results की relevance और position दोनों को ध्यान में रखता है
  • ये इस बात को मापते हैं कि सिस्टम relevant documents को ऊपर और irrelevant documents को नीचे rank करने में कितना सक्षम है
  • उदाहरण के लिए, अगर movie review summary बनाने के लिए user summaries retrieve की जा रही हैं, तो किसी खास फिल्म की reviews को ऊपर rank करना और दूसरी फिल्मों की reviews को बाहर रखना बेहतर होगा
  • पारंपरिक recommendation systems की तरह, retrieved items की ranking इस बात पर काफी असर डालती है कि LLM downstream task को कैसे करता है
  • प्रभाव मापने के लिए retrieved items को shuffle करके RAG-आधारित task चलाएँ और देखें कि RAG output कैसा perform करता है
• दूसरा है "information density"
  • अगर दो documents समान रूप से relevant हैं, तो अधिक संक्षिप्त और कम अप्रासंगिक विवरण वाले document को प्राथमिकता देनी चाहिए
  • movie वाले उदाहरण पर लौटें, तो movie script और सभी user reviews को व्यापक अर्थ में relevant माना जा सकता है
  • फिर भी, high-rated reviews और editorial reviews में information density अधिक होने की संभावना है
• अंत में, document में दिए गए "detail level" पर विचार करें
  • कल्पना कीजिए कि आप natural language से SQL query जनरेट करने के लिए RAG system बना रहे हैं
    • column names वाले table schema को context के रूप में देना ही पर्याप्त हो सकता है
    • लेकिन अगर column descriptions और कुछ representative values भी शामिल की जाएँ तो?
  • अतिरिक्त detail, LLM को tables के अर्थ को बेहतर समझने और अधिक सटीक SQL जनरेट करने में मदद कर सकती है

keyword search को न भूलें, और इसे baseline तथा hybrid search के लिए उपयोग करें

• embedding-आधारित RAG demos व्यापक होने के कारण, information retrieval क्षेत्र के दशकों के research और solutions को भूलना या नज़रअंदाज़ करना आसान है
  • फिर भी, embeddings निस्संदेह एक शक्तिशाली tool हैं, लेकिन वे हर समस्या का समाधान नहीं हैं
• keyword-based search के फायदे
  • पहला, embeddings उच्च-स्तरीय semantic similarity पकड़ने में उत्कृष्ट हैं, लेकिन अधिक विशिष्ट और keyword-based queries में कठिनाई हो सकती है, जैसे जब user किसी नाम (उदा. Ilya), acronym (उदा. RAG), या ID (उदा. claude-3-sonnet) को खोजता है
    • BM25 जैसी keyword-based search इसी उद्देश्य के लिए स्पष्ट रूप से डिजाइन की गई है
    • users लंबे समय से keyword-based search का उपयोग करते आए हैं, इसलिए वे इसे स्वाभाविक मानते हैं; अगर वे जिस document को खोज रहे हैं वह वापस न आए, तो उन्हें निराशा हो सकती है
  • दूसरा, keyword search में यह समझना अधिक सहज होता है कि कोई document क्यों retrieve हुआ
    • क्योंकि query से मेल खाने वाले keywords देखे जा सकते हैं
    • इसके विपरीत, embedding-based search कम interpretable होती है
  • तीसरा, Lucene या OpenSearch जैसे दशकों से optimized और battle-tested systems के कारण keyword search आमतौर पर computationally अधिक efficient होती है
• अधिकतर मामलों में hybrid approach सबसे प्रभावी होती है
  • obvious matches के लिए keyword matching का उपयोग करें, और synonyms, hypernyms, spelling errors, तथा multimodal (उदा. image और text) के लिए embeddings का उपयोग करें
  • Shortwave ने यह साझा किया है कि उन्होंने अपनी RAG pipeline कैसे बनाई, जिसमें query rewriting, keyword + embedding search, ranking आदि शामिल हैं

नए knowledge के लिए fine-tuning की तुलना में RAG को प्राथमिकता दें

• RAG और fine-tuning दोनों का उपयोग नई जानकारी को LLM में शामिल करने और विशिष्ट tasks पर performance सुधारने के लिए किया जा सकता है
  • तो पहले किसे आज़माना चाहिए?
• RAG के फायदे
  • हालिया research के अनुसार RAG बेहतर हो सकता है
  • एक study में RAG और unsupervised fine-tuning (जिसे continued pretraining भी कहा जाता है) की तुलना MMLU और current affairs के subset पर की गई
    • RAG ने training के दौरान देखे गए knowledge और पूरी तरह नए knowledge, दोनों पर fine-tuning की तुलना में लगातार बेहतर performance दिखाई
  • एक अन्य paper में agriculture dataset पर RAG और supervised fine-tuning की तुलना की गई
    • इसी तरह, RAG का performance improvement fine-tuning से बड़ा था, खासकर GPT-4 में यह अधिक स्पष्ट था (paper की table 20 देखें)
  • performance gains के अलावा, RAG के कई practical फायदे हैं
    • पहला, continued pretraining या fine-tuning की तुलना में retrieval index को up-to-date रखना अधिक आसान और सस्ता है
    • दूसरा, अगर retrieval index में harmful या biased content वाला कोई problematic document हो, तो उस document को आसानी से हटाया या संशोधित किया जा सकता है
  • साथ ही, RAG का R documents को retrieve करने के तरीके पर अधिक सूक्ष्म नियंत्रण देता है
    • उदाहरण के लिए, अगर आप कई organizations के लिए RAG system host कर रहे हैं, तो retrieval index को partition करके यह सुनिश्चित किया जा सकता है कि हर organization केवल अपने index के documents ही retrieve कर सके
    • इससे एक organization की जानकारी गलती से दूसरी organization के सामने उजागर होने से बचाया जा सकता है

long-context models, RAG को बेकार नहीं बना देंगे

• Gemini 1.5 अधिकतम 1 करोड़ टोकन आकार की context window देता है, इसलिए कुछ लोगों ने RAG के भविष्य पर सवाल उठाने शुरू कर दिए हैं
  • 1 करोड़ टोकन की context window मौजूदा RAG frameworks के अधिकांश हिस्से को अनावश्यक बना देती है
    • बस डेटा को context में डालें और सामान्य तरीके से मॉडल से बातचीत करें
  • कल्पना कीजिए कि इसका startups, agents, और langchain projects पर क्या असर होगा, जहाँ अधिकांश engineering effort RAG पर लगाया जाता है
    • एक वाक्य में कहें तो, 1 करोड़ context RAG को खत्म कर देता है
• RAG की लगातार ज़रूरत
  • यह सच है कि long context कई documents के analysis या PDFs के साथ chat जैसे use cases में game changer हो सकता है, लेकिन RAG के अंत की खबरें बहुत बढ़ा-चढ़ाकर कही गई हैं
    • पहला, 1 करोड़ टोकन की context window होने पर भी, मॉडल में कौन-सी जानकारी देनी है यह चुनने का तरीका अब भी ज़रूरी है
    • दूसरा, needle-in-a-haystack evaluation से आगे बढ़कर, मॉडल इतने बड़े context पर प्रभावी ढंग से reasoning कर सकता है, इसका ठोस data अभी तक नहीं दिखा है
    • इसलिए अच्छे retrieval और ranking के बिना, मॉडल को ध्यान भटकाने वाली जानकारी से overload करने या context window को पूरी तरह असंबंधित जानकारी से भर देने का जोखिम बना रहता है
• अंत में, लागत का सवाल भी है
  • Transformer की inference cost context length के साथ quadratic रूप से बढ़ती है, या memory और time दोनों में linear रूप से बढ़ती है
  • सिर्फ इसलिए कि कोई मॉडल किसी organization के पूरे Google Drive को पढ़ सकता है, इसका मतलब यह नहीं कि हर सवाल का जवाब देने से पहले ऐसा करना अच्छा विचार है
  • RAM के इस्तेमाल की तुलना पर विचार करें
    • कई दर्जन terabytes RAM वाले computing instances मौजूद हैं, फिर भी हम अब भी disk से read और write करते हैं
• इसलिए अभी RAG को कूड़ेदान में मत फेंकिए
  • context window का आकार बढ़ने पर भी यह pattern उपयोगी बना रहेगा

रणनीति 3. Workflow tuning और optimization

• LLM को prompt देना सिर्फ शुरुआत है
  • LLM का पूरा फायदा उठाने के लिए single prompt से आगे बढ़कर workflows अपनाने होंगे
  • उदाहरण के लिए, किसी जटिल एकल task को कई सरल tasks में कैसे बाँटा जा सकता है?
  • fine-tuning या caching performance बढ़ाने और latency/cost घटाने में कब मदद करती है?
• इस section में proven strategies और real-world examples साझा किए गए हैं, ताकि LLM workflows को optimize और build करने में मदद मिल सके

Step-by-step, multi-turn "Flow" बड़े performance gains दे सकता है

• हम पहले से जानते हैं कि एक बड़े prompt को कई छोटे prompts में बाँटने से बेहतर नतीजे मिल सकते हैं
  • AlphaCodium इसका एक उदाहरण है
    • single prompt से multi-step workflow पर जाने से इसने CodeContests में GPT-4 की accuracy (pass@5) को 19% से बढ़ाकर 44% कर दिया
  • workflow में यह शामिल है
    • समस्या पर विचार
    • public tests पर reasoning
    • संभावित solutions बनाना
    • संभावित solutions की ranking
    • synthetic tests बनाना
    • public और synthetic tests पर solutions को iterate करना
• स्पष्ट लक्ष्य वाले छोटे tasks सबसे अच्छे agent या flow prompts बनाते हैं
  • हर agent prompt में structured output माँगना ज़रूरी नहीं है, लेकिन structured output उस system के interface में बहुत मदद करता है जो agent की environment के साथ interaction को coordinate करता है
• आज़माने लायक बातें
  • जितना संभव हो उतना सख्ती से specified explicit planning step
    • पहले से परिभाषित plans में से चुनने पर विचार करें
  • मूल user prompt को agent prompt के रूप में फिर से लिखना
    • इस प्रक्रिया में information loss हो सकता है, इसलिए सावधान रहें
  • linear chains, DAGs, और state machines के रूप में agent behavior
    • अलग-अलग dependencies और logical relationships अलग-अलग scale के लिए अधिक या कम उपयुक्त हो सकते हैं
    • क्या अलग-अलग task architectures में performance optimization हासिल की जा सकती है?
  • plan validation
    • plans में यह निर्देश शामिल हो सकते हैं कि final output को सही ढंग से काम करने लायक बनाने के लिए दूसरे agents के responses का मूल्यांकन कैसे किया जाए
  • fixed upstream state के साथ prompt engineering
    • सुनिश्चित करें कि agent prompts का मूल्यांकन उन अलग-अलग variations के विरुद्ध हो रहा है जो पहले उत्पन्न हो सकती हैं

फिलहाल deterministic workflows को प्राथमिकता दें

• AI agents user requests और environment पर dynamic तरीके से प्रतिक्रिया दे सकते हैं, लेकिन उनका non-deterministic स्वभाव deployment को कठिन बना देता है
  • agent द्वारा किए गए हर step के fail होने की संभावना होती है, और errors से recover होने की संभावना कम रहती है
  • इसलिए multi-step task को सफलतापूर्वक पूरा करने की agent की संभावना steps की संख्या बढ़ने के साथ geometrically घटती जाती है
  • नतीजतन, agents बनाने वाली teams को reliable agents deploy करने में कठिनाई होती है
• एक promising approach यह है कि agent system पहले deterministic plan बनाए और फिर उसे structured और reproducible तरीके से execute करे
  • पहले step में, high-level goal या prompt दिए जाने पर agent एक plan बनाता है
  • फिर उस plan को deterministic तरीके से execute किया जाता है
  • इससे हर step को अधिक predictable और reliable बनाया जा सकता है
  • फायदे
    • generated plans को agent को prompt देने या fine-tune करने के लिए few-shot samples के रूप में इस्तेमाल किया जा सकता है
    • deterministic execution system को अधिक reliable बनाती है, जिससे testing और debugging आसान हो जाती है। साथ ही failures को plan के किसी specific step तक trace किया जा सकता है
    • generated plans को directed acyclic graph (DAG) के रूप में व्यक्त किया जा सकता है, जो static prompts की तुलना में समझने और नई situations के अनुसार ढलने में आसान है
• सबसे सफल agent builders वे लोग हो सकते हैं जिनके पास junior engineers को manage करने का मजबूत अनुभव हो
  • क्योंकि plan generation की प्रक्रिया काफी हद तक junior को निर्देश देने और manage करने जैसी होती है
  • जैसे आप junior को अस्पष्ट और खुले-ended direction की जगह स्पष्ट goals और specific plans देते हैं, वैसे ही agents के साथ भी करना चाहिए
• आखिरकार, reliable और काम करने वाले agents का मूल संभवतः यहाँ मिलेगा
  • अधिक structured और deterministic approach अपनाने में,
  • और prompts सुधारने तथा models को fine-tune करने के लिए data इकट्ठा करने में
• इसके बिना, आप ऐसे agents बना सकते हैं जो कभी-कभी बहुत अच्छा काम करें, लेकिन औसतन users को निराश करें और retention कम कर दें

Temperature parameter से आगे जाकर विविध outputs प्राप्त करना

• मान लीजिए आपके पास ऐसा task है जिसमें LLM output में विविधता चाहिए
  • हो सकता है आप ऐसा LLM pipeline लिख रहे हों जो user द्वारा पहले खरीदे गए products की सूची को देखकर catalog से खरीदने के लिए products सुझाए
  • आप देख सकते हैं कि prompt को कई बार चलाने पर recommendations बहुत समान आ रही हैं
  • इसलिए आप LLM request का Temperature parameter बढ़ा सकते हैं
• Temperature parameter बढ़ाने से LLM responses अधिक विविध हो जाते हैं
  • sampling के समय next token की probability distribution अधिक flat हो जाती है, जिससे वे tokens भी ज़्यादा चुने जाते हैं जिन्हें सामान्यतः चुने जाने की संभावना कम होती है
• लेकिन temperature बढ़ाने पर output diversity से जुड़े कुछ failure modes सामने आ सकते हैं
  • उदाहरण के लिए, catalog के कुछ products उपयुक्त हो सकते हैं, लेकिन LLM उन्हें output में न दे
  • यदि LLM training के दौरान सीखी बातों के आधार पर prompt को follow करने की अधिक संभावना रखता है, तो वही कुछ products outputs में disproportionately अधिक दिख सकते हैं
  • temperature बहुत ज़्यादा होने पर ऐसे outputs बन सकते हैं जो अस्तित्वहीन products या अर्थहीन सामग्री का उल्लेख करें
• temperature बढ़ाने से यह गारंटी नहीं मिलती कि LLM अपेक्षित probability distribution, जैसे uniform random, से outputs sample करेगा
• फिर भी output diversity बढ़ाने के लिए कुछ और tricks हैं
  • सबसे आसान तरीका है prompt के भीतर मौजूद elements को adjust करना
    • उदाहरण के लिए, यदि prompt template में past purchases जैसी items की list शामिल है, तो हर बार इन items को prompt में डालते समय उनका order shuffle करना काफ़ी फर्क ला सकता है
  • हाल के outputs की छोटी सूची बनाए रखना भी duplication रोकने में मदद करता है
    • product recommendation वाले उदाहरण में, आप LLM को इस हालिया सूची की items सुझाने से बचने के लिए कह सकते हैं, या हाल की suggestions से मिलते-जुलते outputs को reject करके फिर से sample कर सकते हैं, जिससे responses और विविध हो जाएँगे
  • एक और प्रभावी strategy है prompt में इस्तेमाल की जाने वाली phrasing को विविध बनाना
    • उदाहरण के लिए, "ऐसी items चुनें जिन्हें user नियमित रूप से इस्तेमाल करना पसंद करेगा" या "ऐसे products चुनें जिन्हें user अपने दोस्तों को recommend करने की अधिक संभावना रखता है" जैसे वाक्यांश शामिल करने से focus बदल सकता है और recommended products की विविधता पर असर पड़ सकता है

caching को कम आँका गया है

• कैशिंग समान input के लिए response को दोबारा compute करने की जरूरत खत्म करके लागत कम करती है और generation latency हटाती है
  • साथ ही, यदि response पहले से guardrail किया गया है, तो ऐसे validated response देने से हानिकारक या अनुपयुक्त content देने का जोखिम कम हो सकता है
• कैशिंग के लिए एक सरल approach यह है कि processing में मौजूद item के लिए एक unique ID इस्तेमाल की जाए, जैसे नई article या product review को summarize करते समय
  • जब request आए, तो देखा जा सकता है कि cache में summary पहले से मौजूद है या नहीं
    • अगर है, तो उसे तुरंत return किया जा सकता है; नहीं है, तो generate, guardrail और serve करने के बाद future requests के लिए cache में store किया जा सकता है
• अधिक open-ended queries के लिए, search क्षेत्र की उन techniques को अपनाया जा सकता है जो open-ended input पर भी caching का उपयोग करती हैं
  • autocomplete और spell correction जैसी सुविधाएँ user input को normalize करके cache hit rate बढ़ाने में मदद करती हैं

finetune (फाइन-ट्यूनिंग) की जरूरत कब पड़ती है

• कुछ ऐसे tasks हो सकते हैं जहाँ सबसे चतुराई से design किया गया prompt भी पर्याप्त नहीं होता
  • उदाहरण के लिए, काफी prompt engineering के बाद भी system अभी तक reliable और high-quality output लौटाने से दूर हो सकता है
  • ऐसे में किसी specific task के लिए model को fine-tune करना पड़ सकता है
• सफल fine-tuning के उदाहरण
  • Honeycomb का Natural Language Query Assistant
    • शुरुआत में context learning के लिए n-shot examples के साथ एक "programming manual" prompt में दिया गया था
    • यह ठीक से काम करता था, लेकिन model को fine-tune करने से domain-specific language की syntax और rules पर बेहतर output मिल सकता है
  • Rechat की Lucy
    • LLM को बहुत specific format में response generate करना होता है, जिसमें structured data और unstructured data दोनों शामिल होते हैं ताकि frontend सही तरह render कर सके
    • इसे लगातार सही तरीके से काम कराने के लिए fine-tuning जरूरी है
• fine-tuning प्रभावी हो सकती है, लेकिन इसकी लागत काफी होती है
  • fine-tuning data पर annotation करना, model को fine-tune और evaluate करना, और अंततः उसे self-host करना पड़ता है
  • इसलिए यह विचार करना चाहिए कि अधिक upfront cost वाकई उसके लायक है या नहीं
• अगर prompting से 90% तक पहुँचा जा सकता है, तो fine-tuning में निवेश करना जरूरी नहीं भी हो सकता
  • लेकिन अगर fine-tune करने का फैसला लेते हैं, तो human-annotated data इकट्ठा करने की लागत कम करने के लिए synthetic data पर generate और fine-tune किया जा सकता है, या open source data से bootstrap किया जा सकता है

रणनीति 4. evaluation और monitoring

• LLM evaluation एक minefield बन सकता है
  • LLM के input और output arbitrary text होते हैं, और जो task सेट किया जाता है वह भी विविध होता है
  • फिर भी, सख्त और सावधानीपूर्ण evaluation महत्वपूर्ण है
    • यह संयोग नहीं है कि OpenAI के technical leaders evaluation में शामिल होते हैं और individual evaluations पर feedback देते हैं
• LLM application evaluation के लिए कई तरह की definitions और simplifications की जरूरत होती है
  • यह सिर्फ unit testing हो सकता है, या observability जैसा कुछ, या सिर्फ data science
  • हमने पाया कि ये सभी दृष्टिकोण उपयोगी हैं
• इस section में evaluation और monitoring pipeline बनाते समय महत्वपूर्ण बिंदुओं पर सीखे गए lessons दिए गए हैं

वास्तविक input-output samples से कुछ assertion-आधारित unit tests बनाएं

• production में input और output के samples से unit tests (यानी assertion) बनाएं, और कम से कम 3 मानदंडों के आधार पर output के लिए expectations सेट करें
  • 3 मानदंड मनमाने लग सकते हैं, लेकिन शुरुआत के लिए यह एक practical संख्या है
    • इससे कम होने पर task पर्याप्त रूप से defined नहीं हो सकता, या general chatbot की तरह बहुत open-ended हो सकता है
  • इन unit tests या assertions को pipeline में होने वाले बदलावों, जैसे prompt edit, RAG के जरिए नया context जोड़ना, या अन्य modifications, से trigger होना चाहिए
• उन assertions से शुरुआत करने पर विचार करें जो हर response में शामिल या excluded होने वाली phrases या ideas को specify करते हैं
  • साथ ही, यह जाँचने पर भी विचार करें कि शब्दों, items, या sentences की संख्या एक range के भीतर है या नहीं
  • अन्य तरह के generation के लिए assertions अलग दिख सकते हैं
    • उदाहरण के लिए, code generation का मूल्यांकन करने की एक मजबूत विधि execution evaluation है, जिसमें generated code को चलाकर यह देखा जाता है कि runtime state user request के लिए पर्याप्त है या नहीं
• उदाहरण के लिए, अगर user foo नाम का नया function माँगता है, तो agent द्वारा generated code चलाने के बाद foo को call किया जा सकना चाहिए
• execution evaluation की एक चुनौती यह है that agent code अक्सर target code की तुलना में runtime को थोड़े अलग रूप में छोड़ता है
  • assertion को सबसे कमजोर मान्य assumption तक "relax" करना, जो किसी भी valid answer को संतुष्ट कर सके, प्रभावी हो सकता है
• ग्राहकों के लिए intended तरीके से product का खुद उपयोग करना (यानी "dogfooding") वास्तविक data में failure modes पर insight दे सकता है
  • यह approach न सिर्फ संभावित कमजोरियों की पहचान करने में मदद करती है, बल्कि ऐसे उपयोगी production samples भी देती है जिन्हें evaluation में बदला जा सकता है

LLM-as-Judge कुछ हद तक काम कर सकता है, लेकिन यह सर्व万能 नहीं है

• LLM-as-Judge वह approach है जिसमें एक शक्तिशाली LLM का उपयोग दूसरे LLM के output का मूल्यांकन करने के लिए किया जाता है, और कुछ लोग इसे संदेह की नजर से देखते हैं
• फिर भी, सही implementation होने पर LLM-as-Judge मानव निर्णय के साथ पर्याप्त correlation हासिल कर सकता है, और कम से कम यह पहले से समझ बनाने में मदद कर सकता है कि नया prompt या technique कैसे perform कर सकता है
  • खासकर pairwise comparisons (जैसे control group vs treatment group) में, LLM-as-Judge आमतौर पर direction सही पकड़ता है, लेकिन जीत/हार की magnitude noisy हो सकती है
• LLM-as-Judge का अधिकतम लाभ उठाने के लिए सुझाव
  • pairwise comparison का उपयोग
    • LLM से किसी single output को Likert scale पर rate करने के बजाय, उसे दो options दें और बेहतर वाले को चुनने के लिए कहें
    • इससे आमतौर पर अधिक stable results मिलते हैं
  • position bias को control करना
    • दिए गए options का क्रम LLM के निर्णय को bias कर सकता है
    • इसे कम करने के लिए, हर pairwise comparison दो बार चलाएँ और हर बार pair का क्रम बदल दें
    • swapping के बाद जीत को सही option के खाते में जोड़ना चाहिए
  • tie की अनुमति देना
    • कुछ मामलों में दोनों options समान रूप से अच्छे हो सकते हैं
    • इसलिए LLM को tie घोषित करने की अनुमति दें, ताकि उसे मनमाने तरीके से winner चुनना न पड़े
  • Chain-of-Thought का उपयोग
    • final preference बताने से पहले LLM से उस निर्णय की व्याख्या करने को कहना evaluation reliability बेहतर कर सकता है
    • bonus के तौर पर, इससे कमजोर लेकिन तेज LLM का उपयोग करते हुए भी समान परिणाम मिल सकते हैं
    • क्योंकि pipeline का यह हिस्सा अक्सर batch mode में होता है, CoT से होने वाली अतिरिक्त latency समस्या नहीं बनती
  • response length को control करना
    • LLM लंबे responses की ओर झुकाव रखता है
    • इसे कम करने के लिए, सुनिश्चित करें कि response pairs की लंबाई लगभग समान हो
• LLM-as-Judge का एक खास तौर पर मजबूत उपयोग regression के खिलाफ नई prompt strategy की जाँच करना है
  • यदि आपने production results का एक संग्रह track किया है, तो कभी-कभी उन्हीं production examples को नई prompt strategy के साथ फिर से चलाकर और LLM-as-Judge का उपयोग करके जल्दी से आंका जा सकता है कि नई strategy कहाँ कठिनाई झेल सकती है
• LLM-as-Judge के एक सरल लेकिन प्रभावी approach का उदाहरण
  • बस LLM response, judge की critique (यानी CoT), और final result को log करें
  • फिर stakeholders के साथ इसकी समीक्षा करें और improvement के क्षेत्रों की पहचान करें
  • 3 iterations के बाद human और LLM के बीच agreement 68% से बढ़कर 94% हो गया
• लेकिन LLM-as-Judge सर्व万能 नहीं है
  • सबसे शक्तिशाली models भी भाषा के कुछ सूक्ष्म पहलुओं का reliable मूल्यांकन नहीं कर पाते
• हमने यह भी पाया कि पारंपरिक classifiers और reward models, LLM-as-Judge की तुलना में अधिक accuracy हासिल कर सकते हैं, जबकि उनकी cost और latency कम होती है
  • code generation के मामले में LLM-as-Judge, execution evaluation जैसी अधिक direct evaluation strategies की तुलना में कमजोर हो सकता है

generation results के evaluation के लिए "intern test"

• जनरेट किए गए परिणामों का मूल्यांकन करते समय निम्नलिखित "इंटर्न टेस्ट" का उपयोग करना अच्छा है
  • यदि संदर्भ सहित language model को दिया गया सटीक input संबंधित विषय के एक औसत विश्वविद्यालय छात्र को असाइनमेंट के रूप में दिया जाए, तो क्या वह उसे सफलतापूर्वक कर पाएगा?
  • इसमें कितना समय लगेगा?
• यदि उत्तर नहीं है
  • अगर वजह यह है कि LLM के पास आवश्यक ज्ञान की कमी है, तो संदर्भ को अधिक समृद्ध बनाने के तरीकों पर विचार करें
  • अगर संदर्भ सुधारने पर भी समस्या हल नहीं होती, तो यह आधुनिक LLMs के लिए बहुत कठिन कार्य हो सकता है
• यदि उत्तर हाँ है लेकिन समय लगता है
  • आप कार्य की जटिलता कम करने की कोशिश कर सकते हैं
    • क्या इसे छोटे भागों में तोड़ा जा सकता है?
    • कार्य के किन पहलुओं को और अधिक template किया जा सकता है?
• यदि उत्तर हाँ है और इसे जल्दी किया जा सकता है
  • डेटा में गहराई से देखते समय
    • मॉडल क्या गलत कर रहा है?
    • क्या विफलताओं के पैटर्न मिल सकते हैं?
  • मॉडल से जवाब देने से पहले या बाद में खुद से अपनी व्याख्या करने के लिए कहें

किसी एक विशेष evaluation पर अत्यधिक ज़ोर देने से समग्र प्रदर्शन घट सकता है

"जब कोई मापदंड लक्ष्य बन जाता है, तो वह अच्छा मापदंड नहीं रह जाता।" - Goodhart का नियम

• इसका एक उदाहरण Needle-in-a-Haystack (NIAH) evaluation है
  • मूल evaluation इस बात को मापने में मदद करता था कि संदर्भ का आकार बढ़ने पर मॉडल recall कैसे बदलता है और सुई की स्थिति के अनुसार recall पर क्या असर पड़ता है
  • लेकिन इस पर इतना अधिक ज़ोर दिया गया कि इसे Gemini 1.5 रिपोर्ट के Figure 1 के रूप में पेश किया गया
  • इस evaluation में Paul Graham के essays को दोहराने वाले लंबे दस्तावेज़ में एक विशेष वाक्यांश ("The special magic {city} number is: {number}") डाला जाता है, फिर मॉडल से उस magic number को याद करने के लिए कहा जाता है
• कुछ मॉडल लगभग पूर्ण recall हासिल करते हैं, लेकिन यह सवाल बना रहता है कि क्या NIAH वास्तव में वास्तविक applications के लिए आवश्यक reasoning और recall क्षमता को दर्शाता है
• अधिक व्यावहारिक scenarios पर विचार करें
  • यदि 1 घंटे की meeting transcript दी जाए, तो क्या LLM मुख्य निर्णयों और अगले कदमों का सारांश दे सकता है और हर item को सही ज़िम्मेदार व्यक्ति से जोड़ सकता है?
  • यह कार्य साधारण याद रखने से आगे बढ़कर जटिल चर्चा को समझने, प्रासंगिक जानकारी पहचानने और सारांश तैयार करने की क्षमता भी मांगता है, इसलिए यह अधिक यथार्थवादी है
• व्यावहारिक NIAH evaluation का उदाहरण
  • डॉक्टर-रोगी video call transcript का उपयोग करके LLM से मरीज की दवाओं के बारे में पूछना
  • साथ ही अधिक चुनौतीपूर्ण NIAH भी शामिल था, जैसे pizza toppings के लिए espresso में डुबोए गए खजूर, नींबू, बकरी के चीज़ जैसी random सामग्री से जुड़े वाक्यांश डालना
  • दवा वाले कार्य में recall लगभग 80% था, जबकि pizza वाले कार्य में 30%
• NIAH evaluation पर अत्यधिक ज़ोर देने से extraction और summarization कार्यों का प्रदर्शन कम हो सकता है
  • क्योंकि ऐसे LLMs को हर वाक्य पर ध्यान देने के लिए fine-tune किया जाता है, वे असंबंधित विवरणों और distractions को भी महत्वपूर्ण मानने लग सकते हैं
  • फिर वे अंतिम output में शामिल हो सकते हैं (जबकि उन्हें नहीं होना चाहिए!)
• यह बात अन्य evaluations और use cases पर भी लागू हो सकती है
  • उदाहरण के लिए summarization
    • यदि factual consistency पर ज़ोर दिया जाए, तो ऐसे summaries बन सकते हैं जो कम विशिष्ट हों (और इसलिए तथ्य से असंगत होने की संभावना भी कम हो) लेकिन कम प्रासंगिक भी हों
    • इसके विपरीत, यदि writing style और eloquence पर ज़ोर दिया जाए, तो अधिक चमकदार marketing-टाइप भाषा बन सकती है, जो factual inconsistency पैदा कर सकती है

annotation को binary task या pairwise comparison में सरल बनाना

• मॉडल output पर open-ended feedback देना या Likert scale पर उसका मूल्यांकन करना संज्ञानात्मक रूप से कठिन होता है
  • परिणामस्वरूप, एकत्रित डेटा human evaluators के बीच भिन्नता के कारण अधिक noisy हो जाता है, और इसलिए कम उपयोगी बनता है
• अधिक प्रभावी तरीका है कार्य को सरल बनाना और annotators पर पड़ने वाला संज्ञानात्मक बोझ कम करना
  • दो कार्य जो अच्छी तरह काम करते हैं, वे हैं binary classification और pairwise comparison
• binary classification में annotator से मॉडल के output पर सरल हाँ/नहीं का निर्णय देने को कहा जाता है
  • उदाहरण के लिए पूछा जा सकता है कि क्या बना हुआ summary source document के तथ्यों से मेल खाता है, क्या सुझाया गया उत्तर प्रासंगिक है, क्या उसमें हानिकारकता शामिल है, आदि
  • Likert scale की तुलना में binary निर्णय अधिक सटीक होते हैं, evaluators के बीच अधिक consistency देते हैं, और throughput भी अधिक होता है
  • जैसे Doordash ने yes/no सवालों की एक श्रृंखला के माध्यम से menu items को tag करने के लिए labeling queue सेट की
• pairwise comparison में annotator को मॉडल के दो responses दिए जाते हैं और पूछा जाता है कि इनमें कौन बेहतर है
  • चूँकि लोगों के लिए A या B को अलग-अलग score देने की तुलना में यह कहना आसान होता है कि "A, B से बेहतर है", इसलिए इससे अधिक तेज़ और अधिक विश्वसनीय annotation मिलती है (Likert scale की तुलना में)
• Llama2 meetup में Llama2 paper के लेखकों में से एक Thomas Scialom ने पुष्टि की कि pairwise comparison, लिखे हुए responses जैसे supervised fine-tuning data इकट्ठा करने की तुलना में अधिक तेज़ और सस्ता है
  • पहले की लागत प्रति unit $3.5 थी और दूसरे की प्रति unit $25

(reference-free, जहाँ reference की आवश्यकता नहीं) evaluation और guardrails को परस्पर विनिमेय रूप से इस्तेमाल किया जा सकता है

• guardrails अनुचित या हानिकारक content को पकड़ने में मदद करते हैं, जबकि evaluations मॉडल output की गुणवत्ता और सटीकता मापने में मदद करते हैं
  • reference-free evaluation के मामले में इन्हें एक ही सिक्के के दो पहलू माना जा सकता है
    • reference-free evaluation वह evaluation है जो मानव द्वारा लिखे गए उत्तर जैसे किसी "golden" reference पर निर्भर हुए बिना, केवल input prompt और मॉडल के response के आधार पर output गुणवत्ता का मूल्यांकन कर सकता है
• reference-free evaluation का उदाहरण: summarization evaluation
  • summary की factual consistency और relevance का मूल्यांकन करने के लिए केवल input document को देखना पर्याप्त है
  • यदि summary इन मानदंडों पर कम score करता है, तो आप उसे उपयोगकर्ता को न दिखाने का निर्णय ले सकते हैं, जिससे evaluation प्रभावी रूप से guardrail बन जाता है
• reference-free "translation" evaluation:
  • मानव अनुवाद reference के बिना भी translation की गुणवत्ता का मूल्यांकन किया जा सकता है, इसलिए इसे फिर guardrail के रूप में उपयोग किया जा सकता है

LLM तब भी output लौटाते हैं जब उन्हें नहीं लौटाना चाहिए

• LLM के साथ काम करते समय एक बड़ी चुनौती यह है कि LLM अक्सर तब भी output बना देते हैं जब उन्हें नहीं बनाना चाहिए
  • इससे हानिरहित लेकिन निरर्थक responses, या फिर harmfulness या खतरनाक सामग्री जैसे अधिक गंभीर दोष पैदा हो सकते हैं
  • उदाहरण के लिए यदि किसी दस्तावेज़ से कोई विशेष attribute या metadata निकालने को कहा जाए, तो LLM आत्मविश्वास के साथ कोई value लौटा सकता है, भले ही वह value वास्तव में मौजूद न हो
  • या संदर्भ में English के अलावा किसी अन्य भाषा का दस्तावेज़ दिए जाने पर मॉडल उसी गैर-English भाषा में जवाब दे सकता है
• आप LLM को "लागू नहीं" या "मालूम नहीं" जैसे responses लौटाने के लिए prompt कर सकते हैं, लेकिन यह पूर्ण समाधान नहीं है
  • जहाँ log probabilities उपलब्ध हों, वहाँ भी वे output गुणवत्ता का खराब संकेतक हैं
    • log probabilities यह दर्शाती हैं कि output में token के आने की संभावना कितनी है, लेकिन वे बने हुए text की सटीकता को नहीं दर्शातीं
  • बल्कि query का उत्तर देने और सुसंगत response बनाने के लिए प्रशिक्षित instruction-tuned models में log probabilities अच्छी तरह calibrated नहीं हो सकतीं
    • इसलिए ऊँची log probability यह दिखा सकती है कि output प्रवाहपूर्ण और सुसंगत है, लेकिन इसका अर्थ यह नहीं कि वह सटीक या प्रासंगिक है
• सावधानीपूर्वक prompt engineering कुछ हद तक मदद कर सकती है, लेकिन इसे ऐसे मज़बूत guardrails के साथ पूरक करना चाहिए जो अवांछित outputs का पता लगाएँ और उन्हें filter/regenerate कर सकें
  • उदाहरण के लिए OpenAI एक content moderation API देता है जो hate speech, self-harm, या sexual outputs जैसे unsafe responses की पहचान कर सकता है
  • इसी तरह personally identifiable information (PII) पहचानने के लिए भी कई packages उपलब्ध हैं
• guardrails का एक लाभ यह है कि वे use case से काफ़ी हद तक स्वतंत्र होते हैं, इसलिए किसी विशेष भाषा के सभी outputs पर व्यापक रूप से लागू किए जा सकते हैं
  • साथ ही, सटीक retrieval के माध्यम से यदि कोई प्रासंगिक document न मिले, तो system निर्णायक रूप से "मुझे नहीं पता" कह सकता है
• LLM कभी-कभी वहाँ output नहीं बना पाते जहाँ output अपेक्षित होता है
  • यह कई कारणों से हो सकता है, साधारण समस्याओं जैसे API provider की लंबी latency से लेकर अधिक जटिल समस्याओं तक, जैसे content moderation filter द्वारा output को block कर दिया जाना
• इसलिए debugging और monitoring के लिए inputs और (संभवतः output की अनुपस्थिति सहित) को लगातार log करना महत्वपूर्ण है

hallucination एक जिद्दी समस्या है

• कंटेंट safety या PII से जुड़ी खामियां बहुत ध्यान पाती हैं, इसलिए वे कम ही होती हैं, जबकि factual inconsistency लगातार बनी रहती है और उसका पता लगाना ज्यादा कठिन होता है
  • यह अधिक सामान्य है और इसकी baseline incidence rate 5~10% है, और LLM providers से मिली सीख के अनुसार summary जैसे सरल कामों में भी इसे 2% से नीचे लाना कठिन हो सकता है
• इसे हल करने के लिए prompt engineering (generation upstream) और factual inconsistency guardrails (generation downstream) को जोड़ा जा सकता है
  • prompt engineering के मामले में CoT जैसी तकनीकें LLM को अंतिम output लौटाने से पहले अपनी reasoning समझाने के लिए कहकर hallucination कम करने में मदद करती हैं
  • इसके बाद factual inconsistency guardrails लागू करके summary की factuality का आकलन किया जा सकता है और hallucination को filter या regenerate किया जा सकता है
• कुछ मामलों में hallucination का deterministic तरीके से पता लगाया जा सकता है
  • RAG retrieval के resources का उपयोग करते समय, यदि output structured हो और यह पहचाना जा सके कि resource क्या है, तो मैन्युअली यह जांचना संभव होना चाहिए कि वह input context से sourced है या नहीं

[ऑपरेशंस: रोज़मर्रा (Day-to-Day) और संगठनात्मक समस्याएं ]

ऑपरेशंस 1. डेटा

• जैसे सामग्री की गुणवत्ता खाना कैसा बनेगा यह तय करती है, वैसे ही input data की गुणवत्ता machine learning systems की performance को सीमित करती है
• साथ ही output data ही यह जानने का एकमात्र तरीका है कि product काम कर रहा है या नहीं
• सभी लेखक हर हफ्ते कुछ घंटे input और output को बारीकी से देखते हैं ताकि data distribution (modes, edge cases, model की सीमाएं) को बेहतर समझ सकें

development-production bias की जांच

• पारंपरिक machine learning pipeline में errors का एक सामान्य कारण training-serving skew है
  • यह तब होता है जब training के लिए इस्तेमाल किया गया data उस data से अलग होता है जिसका सामना model को production में करना पड़ता है
• LLM को training या fine-tuning के बिना भी इस्तेमाल किया जा सकता है, इसलिए training set नहीं होता, लेकिन development-production data skew जैसी मिलती-जुलती समस्या फिर भी उत्पन्न होती है
  • मूल रूप से, development के दौरान जिस data पर system को test किया जाता है, उसे उस data को reflect करना चाहिए जिसका system production में सामना करेगा
    • अन्यथा production accuracy गिर सकती है
• LLM development-production skew को दो प्रकारों में बांटा जा सकता है: structural skew और content-based skew
  • structural skew में format mismatch जैसी समस्याएं शामिल हैं, जैसे list-type values वाले JSON dictionary और JSON list के बीच अंतर, inconsistent casing, typos या sentence fragments जैसी errors
    • ये errors unpredictable model performance तक ले जा सकती हैं, क्योंकि अलग-अलग LLMs को specific data formats पर train किया जाता है और prompts मामूली बदलावों के प्रति बहुत sensitive हो सकते हैं
  • content-based या "semantic" skew data के अर्थ या context में अंतर को दर्शाता है
• पारंपरिक ML की तरह, LLM input-output pairs के बीच skew को समय-समय पर मापना उपयोगी है
  • input और output length या specific format requirements (जैसे JSON या XML) जैसे simple metrics बदलावों को track करने का आसान तरीका हैं
• अधिक "advanced" skew detection के लिए, input-output pairs की embeddings को cluster करके semantic skew का पता लगाने पर विचार करें, जैसे कि users जिन topics पर चर्चा कर रहे हैं उनमें बदलाव, जो यह संकेत दे सकता है कि users ऐसे क्षेत्रों की खोज कर रहे हैं जिनसे model पहले expose नहीं हुआ था
• prompt engineering जैसे बदलावों का test करते समय, सुनिश्चित करें कि holdout dataset up-to-date हो और सबसे हाल के user interactions के प्रकारों को reflect करता हो
  • उदाहरण के लिए, यदि production inputs में typos आम हैं, तो वे holdout data में भी होने चाहिए
• skew को केवल numbers से मापने के बजाय outputs का qualitative evaluation करना भी फायदेमंद है
  • model के outputs की नियमित समीक्षा करना (जिसे बोलचाल में "vibe check" कहा जाता है) यह सुनिश्चित करता है कि results अपेक्षाओं पर खरे उतरें और users की जरूरतों के लिए प्रासंगिक बने रहें
• skew checks में non-determinism को शामिल करना भी उपयोगी है
  • test dataset के हर input के लिए pipeline को कई बार चलाकर और सभी outputs का विश्लेषण करके, उन anomalies को पकड़ने की संभावना बढ़ जाती है जो केवल कभी-कभी दिखाई देती हैं

हर दिन LLM input-output samples की जांच करना

• LLMs dynamic हैं और लगातार evolve हो रहे हैं
  • उनकी प्रभावशाली zero-shot capabilities और अक्सर संतोषजनक outputs के बावजूद, LLMs के failure modes बहुत कम अनुमानित होते हैं
• custom tasks के लिए, LLM की performance की intuitive समझ विकसित करने हेतु data samples की नियमित समीक्षा करना आवश्यक है
  • production के input-output pairs LLM applications के "real things, real places" (genchi genbutsu) हैं, और उनका कोई विकल्प नहीं है
• हालिया research इस बात पर जोर देती है कि developers जितना अधिक data के साथ interact करते हैं, "अच्छे" और "खराब" outputs के बारे में उनकी धारणा बदलती जाती है (अर्थात criteria drift)
  • developers LLM outputs का मूल्यांकन करने के लिए कुछ criteria पहले से तय कर सकते हैं, लेकिन ये predefined criteria अक्सर अधूरे होते हैं
• उदाहरण के लिए, development के दौरान prompts को इस तरह update किया जा सकता है कि अच्छे responses की संभावना बढ़े और खराब responses की संभावना घटे
  • evaluation, re-evaluation और criteria updates की यह iterative process इसलिए जरूरी है क्योंकि outputs को सीधे देखे बिना LLM behavior या human preferences की भविष्यवाणी करना कठिन है
• इसे प्रभावी ढंग से संभालने के लिए LLM inputs और outputs को log करना चाहिए
  • हर दिन इन logs के samples की जांच करने से नए patterns या failure modes की जल्दी पहचान करके अनुकूलन किया जा सकता है
  • नया issue मिलते ही उसके लिए तुरंत assertion या eval लिखा जा सकता है
• इसी तरह, failure mode की परिभाषा में कोई भी update evaluation criteria में परिलक्षित होना चाहिए
  • ये "vibe checks" गलत outputs के संकेत हैं, और code तथा assertions इन्हें operationalize करते हैं
• अंत में, इस mindset को socialized किया जाना चाहिए
  • उदाहरण के लिए, on-call rotation में input और output review या annotation जोड़ना

ऑपरेशंस 2. models के साथ काम करना

• LLM APIs का उपयोग करने का अर्थ है कि आप कुछ providers की intelligence पर निर्भर हैं
  • यह अच्छी बात हो सकती है, लेकिन यह dependency performance, latency, throughput और cost के लिहाज से trade-offs भी लाती है
• साथ ही, पिछले एक साल में लगभग हर महीने नए और बेहतर models आए हैं, इसलिए पुराने models को हटाकर नए models पर migrate करते समय product को update करने के लिए तैयार रहना चाहिए
  • यह section उन lessons को साझा करता है जो ऐसी technology का उपयोग करते समय मिले, जिस पर आपका पूरा control नहीं होता, यानी ऐसी technology जिसे आप self-host और manage नहीं कर सकते
• अधिकांश real-world use cases में LLM का output किसी न किसी machine-readable format के जरिए downstream applications द्वारा consume किया जाएगा
  • उदाहरण के लिए, real-estate CRM ReChat को frontend पर widgets render करने के लिए structured responses चाहिए
  • इसी तरह, product strategy idea generation tool Boba को title, summary, feasibility score और time range fields वाले structured output की जरूरत होती है
  • अंत में, LinkedIn ने साझा किया कि LLM को YAML generate करने तक कैसे constrain किया गया, जिसका उपयोग यह तय करने के लिए होता है कि कौन-सी technology इस्तेमाल करनी है और technology को call करने के लिए कौन-से parameters देने हैं
• यह application pattern Postel's law का एक चरम संस्करण है
  • जो चीज़ आप स्वीकार करते हैं (arbitrary natural language) उसमें उदार रहें, और जो चीज़ आप भेजते हैं (typed machine-readable objects) उसमें conservative रहें
  • इसलिए उम्मीद है कि यह पैटर्न काफी durable साबित होगा
• फिलहाल Instructor और Outlines, LLMs से structured output प्राप्त करने के de facto standards हैं
  • यदि आप LLM API (जैसे Anthropic, OpenAI) का उपयोग कर रहे हैं, तो Instructor का उपयोग करें, और यदि आप self-hosted model (जैसे Huggingface) का उपयोग कर रहे हैं, तो Outlines का उपयोग करें

models के बीच prompt migration एक पीड़ादायक काम है

• कभी-कभी बहुत सावधानी से बनाया गया prompt एक मॉडल पर शानदार काम करता है, लेकिन दूसरे मॉडल पर ठीक से काम नहीं कर सकता
  • यह सिर्फ अलग-अलग model providers के बीच स्विच करते समय ही नहीं, बल्कि उसी मॉडल के अलग versions में upgrade करते समय भी हो सकता है
• उदाहरण के लिए, Voiceflow ने पाया कि gpt-3.5-turbo-0301 से gpt-3.5-turbo-1106 पर migrate करने से intent classification task में 10% performance गिरावट आई
  • (खुशकिस्मती से, उनके पास evals थे!)
• इसी तरह GoDaddy ने देखा कि 1106 version में upgrade करने पर gpt-3.5-turbo और gpt-4 के बीच performance gap सकारात्मक दिशा में कम हो गया
  • (या अगर आप चीजों को आधा भरा गिलास मानकर नहीं देखते, तो नए upgrade के साथ gpt-4 की बढ़त घटने पर निराश भी हो सकते हैं)
• इसलिए अगर आपको models के बीच prompts migrate करने हों, तो यह मानकर चलें कि इसमें सिर्फ API endpoint बदलने से अधिक समय लगेगा
  • यह मत मानिए कि वही prompt जोड़ देने से वैसे ही या बेहतर results मिलेंगे
• साथ ही, भरोसेमंद और automated evals migration से पहले और बाद में task performance मापने में मदद करती हैं और manual validation के लिए ज़रूरी मेहनत को कम करती हैं

मॉडल versioning और pinning

• हर machine learning pipeline में "कुछ भी बदलो, तो सब कुछ बदल जाता है"
  • यह खास तौर पर तब और भी प्रासंगिक होता है जब हम large language models (LLM) जैसे उन components पर निर्भर हों जिन्हें हमने खुद train नहीं किया और जो हमारी जानकारी के बिना बदल सकते हैं
• अच्छी बात यह है कि कई model providers किसी specific model version, जैसे gpt-4-turbo-1106, को "pin" करने का विकल्प देते हैं
  • इससे आप model weights के किसी खास version का उपयोग कर सकते हैं ताकि वह बदले नहीं
• production में model version pin करने से model behavior में अप्रत्याशित बदलावों से बचा जा सकता है
  • इससे ग्राहकों की उन शिकायतों से बचने में मदद मिल सकती है जो model बदलने पर बहुत ज़्यादा verbose output या दूसरे अनपेक्षित failure modes की वजह से पैदा हो सकती हैं
• इसके अलावा, एक "shadow pipeline" बनाए रखने पर विचार करें जो production setup को mirror करे लेकिन नवीनतम model version का उपयोग करे
  • इससे आप नए releases के साथ सुरक्षित तरीके से experiment और testing कर सकते हैं
• इन नए models पर output की stability और quality verify करने के बाद, आप production environment में model version को भरोसे के साथ update कर सकते हैं

वह सबसे छोटा model चुनें जो काम पूरा कर सके

• किसी नए application पर काम करते समय उपलब्ध सबसे बड़े और सबसे शक्तिशाली model का उपयोग करने का लालच होता है
  • लेकिन एक बार यह साबित हो जाए कि task तकनीकी रूप से संभव है, तो यह आज़माना फ़ायदेमंद होता है कि क्या छोटे model से भी मिलते-जुलते results हासिल किए जा सकते हैं
• छोटे models के फायदे हैं कम latency और कम cost
  • वे कमज़ोर हो सकते हैं, लेकिन Chain-of-Thought, n-shot prompting, और in-context learning जैसी techniques छोटे models को उनकी सामान्य क्षमता से बेहतर प्रदर्शन करने में मदद कर सकती हैं
• LLM API से आगे बढ़कर, किसी specific task के लिए fine-tuning भी performance सुधारने में मदद कर सकती है
• कुल मिलाकर, छोटे models का उपयोग करने वाला सावधानी से डिज़ाइन किया गया workflow, single बड़े model के output quality से मेल खा सकता है या उसे पार भी कर सकता है, जबकि वह तेज़ और सस्ता भी हो
  • उदाहरण के लिए, यह ट्वीट एक किस्सा साझा करता है कि कैसे Haiku + 10-shot prompt ने zero-shot Opus और GPT-4 को पीछे छोड़ा
• लंबे समय में, output quality, latency और cost के बेहतर संतुलन के लिए छोटे models के साथ flow engineering के और उदाहरण सामने आने की उम्मीद है
• एक और उदाहरण साधारण classification task का है
  • DistilBERT (6.7 करोड़ parameters) जैसे lightweight models आश्चर्यजनक रूप से मजबूत baseline हैं
  • 40 करोड़ parameters वाला DistilBART एक और बेहतरीन विकल्प है
    • open source data पर fine-tune करने पर, यह 0.84 ROC-AUC के साथ hallucinations की पहचान कर सकता है और latency तथा cost के 5% से भी कम पर अधिकांश LLMs को पीछे छोड़ सकता है
• मुख्य बात यह है कि छोटे models को नज़रअंदाज़ नहीं करना चाहिए
  • हर समस्या पर विशाल model लगा देना आसान है, लेकिन थोड़ी रचनात्मकता और प्रयोग के साथ हम अक्सर अधिक efficient solutions खोज सकते हैं

संचालन 3. उत्पाद

• नई technology नई संभावनाएँ देती है, लेकिन शानदार product बनाने के सिद्धांत स्थायी होते हैं
  • इसलिए, भले ही आप पहली बार किसी नई समस्या को हल कर रहे हों, product design के लिए पहिया दोबारा बनाने की ज़रूरत नहीं है
• मजबूत product fundamentals पर LLM application development आधारित करने से बहुत कुछ हासिल किया जा सकता है
  • इससे हम उन लोगों को वास्तविक value दे सकते हैं जिनकी हम सेवा करते हैं

शुरुआत से ही design को शामिल करें

• designers होने से आप इस बारे में समझते हैं और गहराई से सोचते हैं कि product कैसे बनाया जाए और users के सामने कैसे पेश किया जाए
  • कभी-कभी designers को सिर्फ चीज़ों को सुंदर बनाने वाले लोगों के रूप में रूढ़िबद्ध कर दिया जाता है
  • लेकिन वे सिर्फ user interface ही नहीं, बल्कि यह भी फिर से सोचते हैं कि established rules और paradigms को तोड़कर भी user experience को कैसे बेहतर बनाया जा सकता है
• designers खास तौर पर users की ज़रूरतों को अलग-अलग रूपों में पुनर्गठित करने में माहिर होते हैं
  • इन रूपों में से कुछ को हल करना दूसरों की तुलना में आसान होता है, इसलिए वे AI solutions के लिए अधिक या कम अवसर दे सकते हैं
• कई दूसरे products की तरह, AI product बनाना उस technology के इर्द-गिर्द नहीं होना चाहिए जो उसे चलाती है, बल्कि उस काम के इर्द-गिर्द होना चाहिए जिसे किया जाना है
• अपना ध्यान खुद से ऐसे सवाल पूछने पर रखें
  • "यूज़र इस product से कौन-सा काम करवाना चाहता है? क्या वह काम chatbot के लिए उपयुक्त है? autocomplete का क्या? शायद कुछ और बेहतर हो सकता है!"
• मौजूदा design patterns और उनका किए जाने वाले काम से क्या संबंध है, इस पर विचार करें
  • ये वे मूल्यवान assets हैं जिन्हें designers टीम की क्षमताओं में जोड़ते हैं

human-in-the-loop के लिए UX design

• अच्छी quality annotations पाने का एक तरीका यह है कि user experience (UX) में Human-in-the-Loop (HITL) को एकीकृत किया जाए
  • अगर users आसानी से feedback और corrections दे सकें, तो तुरंत output बेहतर किया जा सकता है और model improvement के लिए उपयोगी data भी इकट्ठा किया जा सकता है
• एक e-commerce platform की कल्पना करें जहाँ users products upload करते हैं और उन्हें classify करते हैं
  • UX को डिजाइन करने के कई तरीके हो सकते हैं
    1. user मैन्युअली सही product category चुनता है, और LLM समय-समय पर नए products की जाँच करके backend में गलत classification को ठीक करता है
    2. user कोई category नहीं चुनता, और LLM समय-समय पर backend में products को classify करता है, जिसमें संभावित errors शामिल हो सकते हैं
    3. LLM real time में product category सुझाता है, और user ज़रूरत के अनुसार उसे verify और update कर सकता है
• तीनों approaches में LLM शामिल है, लेकिन ये बहुत अलग UX प्रदान करते हैं
  • पहला approach शुरुआती बोझ user पर डालता है और LLM बाद की processing check की भूमिका निभाता है
  • दूसरा approach user से कोई effort नहीं मांगता, लेकिन transparency या control नहीं देता
  • तीसरा approach सही संतुलन बनाए रखता है
    • LLM पहले से category suggest करके user का cognitive load कम करता है, और product को classify करने के लिए हमारी taxonomy सीखने की ज़रूरत नहीं रहती
    • साथ ही, user को suggestions review और edit करने की सुविधा देकर product classification के अंतिम निर्णय का नियंत्रण मज़बूती से user के हाथ में रहता है
  • bonus के तौर पर, तीसरा approach model improvement के लिए एक स्वाभाविक feedback loop बनाता है
    • अच्छी suggestions स्वीकार कर ली जाती हैं (positive label) और खराब suggestions update की जाती हैं (negative के बाद positive label)
• suggestion, user verification, और data collection का यह pattern कई applications में आम तौर पर देखा जाता है
  • coding assistant: user suggestions को accept कर सकता है (strong positive), accept करके adjust कर सकता है (positive), या ignore कर सकता है (negative)
  • Midjourney: user image को upscale और download कर सकता है (strong positive), image में बदलाव कर सकता है (positive), या नई image set generate कर सकता है (negative)
  • chatbot: user response पर like (positive) या dislike (negative) दे सकता है, या अगर response बहुत खराब हो तो response को regenerate करने का विकल्प चुन सकता है (strong negative)
• feedback explicit भी हो सकता है और implicit भी
  • explicit feedback वह जानकारी है जो user product के अनुरोध के जवाब में देता है
  • implicit feedback वह जानकारी है जो user interactions से सीखी जाती है, बिना इसके कि user जानबूझकर feedback दे
• coding assistant और Midjourney implicit feedback के उदाहरण हैं, और likes तथा dislikes explicit feedback हैं
  • अगर UX को coding assistant और Midjourney की तरह अच्छी तरह design किया जाए, तो product और model improvement के लिए बहुत सारा implicit feedback इकट्ठा किया जा सकता है

निर्दयता से requirements hierarchy को प्राथमिकता देना

• जब demo को production में deploy करने के बारे में सोचते हैं, तो निम्नलिखित requirements पर विचार करना चाहिए
  • reliability: 99.9% uptime, structured output compliance
  • harmlessness: offensive, NSFW, या अन्य harmful content generate न करना
  • factual consistency: दिए गए context के प्रति वफादार रहना और facts को विकृत न करना
  • usefulness: user की ज़रूरतों और requests के लिए relevant होना
  • scalability: latency SLA, supported throughput
  • cost: क्योंकि budget असीमित नहीं होता
  • अन्य: security, privacy, fairness, GDPR, DMA आदि
• अगर इन सभी requirements को एक साथ हल करने की कोशिश करेंगे, तो कुछ भी launch नहीं कर पाएँगे
  • इसलिए priorities तय करनी होंगी। निर्दयता से।
• इसका मतलब है यह साफ़ करना कि कौन-सी non-negotiable चीज़ें हैं जिनके बिना product काम नहीं करेगा या viable नहीं रहेगा, जैसे reliability और harmlessness
  • MVP (Minimum Lovable Product) की पहचान करना महत्वपूर्ण है
• यह स्वीकार करना होगा कि पहला version perfect नहीं होगा, और उसे launch करके iterate करना होगा

use case के अनुसार risk tolerance स्तर समायोजित करना

• language model और applications के लिए review का स्तर तय करते समय use case और target audience को ध्यान में रखना चाहिए
  • अगर यह medical या financial advice देने वाला customer-facing chatbot है, तो safety और accuracy के लिए बहुत ऊँचे standards की ज़रूरत होगी
    • गलतियाँ या गलत output वास्तविक नुकसान पहुँचा सकते हैं और भरोसा खो सकते हैं
  • लेकिन recommendation system जैसे कम critical applications, या content classification या summarization जैसे internal-facing applications में, बहुत कठोर requirements अक्सर ज़्यादा value नहीं जोड़ते और सिर्फ progress को धीमा करते हैं
• यह हाल की a16z report के अनुरूप है, जिसमें कहा गया है कि कई companies external applications की तुलना में internal LLM applications में अधिक तेज़ी से आगे बढ़ रही हैं
  • internal productivity के लिए AI के साथ experiment करके organizations controlled environment में risk management सीखते हुए value हासिल करना शुरू कर सकते हैं
  • फिर, confidence बनने पर वे customer-facing use cases तक विस्तार कर सकते हैं

संचालन 4. टीम और भूमिकाएँ (Roles)

• किसी भी job function को परिभाषित करना आसान नहीं होता, लेकिन इस नए क्षेत्र में काम के लिए job description लिखना और भी कठिन है
  • overlapping titles के Venn diagram या job descriptions के सुझावों को मैं छोड़ रहा हूँ
  • हालांकि, मैं AI engineer जैसी नई भूमिका के अस्तित्व को स्वीकार करूँगा और उस पर चर्चा करूँगा
• महत्वपूर्ण बात यह है कि बाकी टीम और responsibilities को कैसे बाँटा जाना चाहिए, इस पर चर्चा की जाए

tools नहीं, process पर ध्यान दें

• LLM जैसे नए paradigm का सामना होने पर software engineers अक्सर tools को प्राथमिकता देते हैं
  • परिणामस्वरूप, वे उस problem और process को नज़रअंदाज़ कर देते हैं जिसे tool हल करने की कोशिश कर रहा था
  • ऐसा करते हुए, कई engineers accidental complexity अपना लेते हैं, जिसके team की long-term productivity पर नकारात्मक प्रभाव पड़ते हैं
• उदाहरण के लिए, यह लेख बताता है कि एक specific tool किस तरह large language models के लिए prompts को automatically generate कर सकता है
  • तर्क यह है कि जो engineers पहले problem-solving methodology या process को समझे बिना ऐसे tools का उपयोग करते हैं, वे अंततः अनावश्यक technical debt उठा लेते हैं (IMHO, बिलकुल सही)
• accidental complexity के अलावा, tools अक्सर अपर्याप्त रूप से specified होते हैं
  • उदाहरण के लिए, harmfulness, conciseness, tone आदि के लिए general evaluators के साथ "LLM evaluation toolbox" देने वाला LLM evaluation tools उद्योग बढ़ रहा है
  • मैं देखता हूँ कि कई teams अपने domain के specific failure modes पर critical thinking किए बिना ऐसे tools अपना लेती हैं
• इसके विपरीत, EvalGen domain-specific evaluations बनाने की process सिखाने पर केंद्रित है, जिसमें users को rubric specification, data labeling, evaluation validation आदि हर step में गहराई से शामिल किया जाता है
  • software users को निम्नलिखित workflow के माध्यम से guide करता है
• EvalGen द्वारा guide की जाने वाली LLM evaluation बनाने की best practices
  1. domain-specific tests को define करना (जो prompt से automatically bootstrap होते हैं)
     • code या LLM-as-a-Judge के साथ assertions के रूप में define किए जाते हैं
  2. tests को human judgment के साथ align करने के महत्व को समझना, ताकि user verify कर सके कि tests intended rubric को capture करते हैं
  3. system (जैसे prompts) बदलने पर tests को iterate करना
• EvalGen developers को evaluation building process के लिए एक mental model देता है, लेकिन उन्हें किसी specific tool से बाँधता नहीं है
  • AI engineers को यह context देने के बाद, अक्सर वे simpler tools चुनने या अपने tools खुद बनाने का निर्णय लेते हैं
• prompt writing और evaluation के अलावा, LLM के components इतने अधिक हैं कि यहाँ उन सभी को सूचीबद्ध नहीं किया जा सकता
  • लेकिन यह महत्वपूर्ण है कि AI engineers tools अपनाने से पहले process को समझने की कोशिश करें

हमेशा experiment करें

• ML प्रोडक्ट्स प्रयोगों से गहराई से जुड़े होते हैं
  • इसका मतलब सिर्फ A/B टेस्ट और randomized controlled trials नहीं, बल्कि सिस्टम के सबसे छोटे संभव घटकों में बदलाव करके बार-बार offline evaluation करना भी है
  • हर कोई evaluation को लेकर इतना उत्साहित इसलिए है क्योंकि यह वास्तव में reliability और confidence से ज़्यादा, experimentation को संभव बनाता है!
    • evaluation जितना बेहतर होगा, उतनी तेज़ी से प्रयोगों को दोहराया जा सकेगा, और इसलिए सिस्टम के सबसे अच्छे version तक उतनी जल्दी पहुँचा जा सकेगा
• क्योंकि प्रयोग अब बहुत सस्ते हो गए हैं, इसलिए एक ही समस्या को हल करने के लिए अलग-अलग approaches आज़माना सामान्य बात है
  • data collection और model training की ऊँची लागत अब कम से कम रह गई है
    • prompt engineering की लागत इंसानी समय से थोड़ा ही अधिक है
  • टीम को इस तरह तैयार करें कि हर कोई prompt engineering की बुनियाद सीख सके
    • इससे हर किसी को प्रयोग करने के लिए प्रोत्साहन मिलता है और पूरे संगठन में अलग-अलग ideas पैदा होते हैं
• सिर्फ exploration के लिए प्रयोग न करें, exploitation के लिए भी प्रयोगों का इस्तेमाल करें!
  • क्या किसी नए task का working version मौजूद है?
    • सोचें कि टीम का कोई दूसरा व्यक्ति इसे किसी और तरीके से approach करे
  • किसी ऐसे दूसरे तरीके से आज़माएँ जो शायद तेज़ हो
  • quality बढ़ाने के लिए Chain-of-Thought या Few-Shot जैसी prompting techniques की जाँच करें
  • यह सुनिश्चित करें कि tools प्रयोगों में बाधा न बनें
    • अगर बन रहे हों, तो जो खरीदा है उसे फिर से बनाएं या बेहतर करें
• product/project planning के दौरान evaluation बनाने और कई प्रयोग चलाने के लिए अलग से समय रखें
  • engineering product के लिए product spec के बारे में सोचें, और उसमें evaluation के लिए साफ़ मानदंड जोड़ें
• roadmap बनाते समय प्रयोगों के लिए लगने वाले समय को कम न आँकें
  • production approval मिलने से पहले development और evaluation के कई rounds की अपेक्षा करें

हर किसी को नई AI तकनीकों का उपयोग करने के लिए सशक्त बनाना

• generative AI का adoption बढ़ने के साथ, आप चाहते हैं कि सिर्फ विशेषज्ञ ही नहीं बल्कि पूरी टीम यह महसूस करे कि वह इस नई तकनीक को समझ और उपयोग कर सकती है
  • LLM कैसे काम करते हैं, इसकी intuition विकसित करने का इससे बेहतर तरीका नहीं है (जैसे latency, failure modes, UX)
  • LLM अपेक्षाकृत आसानी से सुलभ हैं
    • pipeline की performance बेहतर करने के लिए coding जानना ज़रूरी नहीं है; हर कोई prompt engineering और evaluation के जरिए योगदान दे सकता है
• इसका एक बड़ा हिस्सा education है
  • आप prompt engineering की बुनियाद से शुरू कर सकते हैं, जहाँ n-shot prompting और CoT जैसी techniques मॉडल को मनचाहे output की दिशा में condition करने में मदद करती हैं
• जिन लोगों के पास ज्ञान है, वे LLM के ज़्यादा technical पहलुओं पर भी सिखा सकते हैं, जैसे कि LLM मूलतः autoregressive होते हैं
  • यानी input tokens parallel में process होते हैं, लेकिन output tokens sequentially generate होते हैं
  • इसलिए latency, input length की तुलना में output length का function होती है
    • UX design करते समय और performance expectations तय करते समय यह एक अहम विचार है
• प्रयोग और exploration के लिए hands-on अवसर भी दिए जा सकते हैं
  • hackathon कैसा रहेगा?
    • पूरी टीम का कुछ दिनों तक speculative projects पर hack करना महँगा लग सकता है, लेकिन नतीजे आपको चौंका सकते हैं
  • एक टीम ने hackathon के जरिए 3 साल के roadmap का लगभग पूरा काम 1 साल में कर लिया
    • दूसरी टीम के लिए hackathon ने LLM की वजह से अब संभव हुए paradigm-shifting UX को जन्म दिया, जो अब इस साल और उसके बाद की priority बन गया है

"AI engineering ही सब कुछ है" वाले जाल में न फँसें

• जब कोई नया job title उभरता है, तो शुरू में उससे जुड़ी क्षमताओं को बढ़ा-चढ़ाकर आँकने की प्रवृत्ति होती है
  • अक्सर इससे बाद में दर्दनाक सुधार करने पड़ते हैं, जब उस job की वास्तविक scope स्पष्ट होती है
  • इस क्षेत्र के नए लोग और hiring managers बढ़ा-चढ़ाकर दावे कर सकते हैं या अवास्तविक उम्मीदें पाल सकते हैं
• पिछले 10 वर्षों में इसके कुछ उल्लेखनीय उदाहरण रहे हैं
  • data scientist: "ऐसा व्यक्ति जो हर software engineer से बेहतर statistics जानता हो और हर statistician से बेहतर software engineering करता हो"
  • machine learning engineer (MLE): machine learning पर software engineering-केंद्रित नज़रिया
• शुरुआत में बहुत से लोगों ने मान लिया कि data-driven projects के लिए सिर्फ data scientists ही काफ़ी होंगे
  • लेकिन बाद में यह साफ़ हुआ कि data scientists को data products को प्रभावी ढंग से विकसित और deploy करने के लिए software engineers और data engineers के साथ मिलकर काम करना पड़ता है
• यही ग़लतफ़हमी AI engineer जैसी नई role में भी फिर से दिखाई दी, और कुछ टीमों ने मान लिया कि AI engineers ही उनकी पूरी ज़रूरत हैं
  • जबकि वास्तव में machine learning या AI products बनाने के लिए कई तरह की specialized roles चाहिए होती हैं
• हमने 12 से अधिक कंपनियों के साथ AI products पर सलाहकारी काम किया है, और लगातार देखा है कि वे "AI engineering ही सब कुछ है" वाली सोच के जाल में फँस जाती हैं
  • नतीजतन, वे अक्सर product बनाने के लिए ज़रूरी अहम पहलुओं को नज़रअंदाज़ कर देती हैं, और product demo से आगे scale करने में संघर्ष करता है
• उदाहरण के लिए evaluation और measurement, सिर्फ vibe check से आगे बढ़कर product को scale करने के लिए बेहद महत्वपूर्ण हैं
  • प्रभावी evaluation के लिए ज़रूरी skills, पारंपरिक रूप से machine learning engineers की कुछ ताक़तों से मेल खाते हैं
    • सिर्फ AI engineers वाली टीम में इन skills की कमी होने की संभावना ज़्यादा होती है
• सह-लेखक Hamel Husain ने data bias detection और domain-specific evaluation design से जुड़े हालिया काम में इन skills के महत्व को समझाया है
• AI product बनाने की यात्रा में किन तरह की roles की ज़रूरत होती है और कब
  1. पहले product बनाने पर ध्यान दें
  • इसमें AI engineers शामिल हो सकते हैं, लेकिन वे अनिवार्य नहीं हैं
  • AI engineers product (UX, plumbing आदि) का prototype बनाने और तेज़ी से iterate करने में उपयोगी होते हैं
  2. इसके बाद सिस्टम को instrument करें और data collect करके सही foundation बनाएं
  • data के type और scale के आधार पर platform engineers और/या data engineers की ज़रूरत पड़ सकती है
  • साथ ही, इस data को query और analyze करने की systems भी होनी चाहिए ताकि समस्याओं को debug किया जा सके
  3. इसके बाद AI system को optimize करें
  • इसमें ज़रूरी नहीं कि model training शामिल ही हो
  • basics में metric design, evaluation systems बनाना, experiments चलाना, RAG retrieval optimize करना, probabilistic systems को debug करना जैसे चरण शामिल हैं
  • MLE इस क्षेत्र में बहुत सक्षम होते हैं (हालाँकि AI engineers भी यह skill सीख सकते हैं)
  • अगर शुरुआती चरण पूरे नहीं हुए हैं, तो MLE को hire करना आम तौर पर उचित नहीं होता
• इसके अलावा, हमेशा domain experts की ज़रूरत होती है
  • छोटी कंपनियों में आदर्श रूप से founding team को यह role निभाना चाहिए, और बड़ी कंपनियों में product managers यह काम कर सकते हैं
• roles की progression और timing को समझना महत्वपूर्ण है
  • ग़लत समय पर लोगों को hire करना (जैसे MLE को बहुत जल्दी hire करना) या ग़लत क्रम में build करना, समय और पैसे की बर्बादी है और attrition का कारण बनता है
• साथ ही, चरण 1-2 में MLE से नियमित check-in करते रहना (लेकिन उन्हें full-time hire न करना) कंपनी को सही foundation बनाने में मदद करता है

[रणनीति: LLM का उपयोग करके निर्माण में पीछे न छूटने का तरीका]

• सफल product development के लिए बिना सोचे-समझे prototypes बनाना या नवीनतम models और trends के पीछे भागना पर्याप्त नहीं है; इसके लिए सोच-समझकर planning और prioritization चाहिए
• AI product development के दौरान build बनाम buy जैसे प्रमुख trade-offs की समीक्षा करनी चाहिए
• शुरुआती LLM application development के लिए एक "playbook" पेश किया गया है

रणनीति 1: PMF से पहले GPU नहीं

• किसी बेहतरीन product के लिए सिर्फ किसी और के API पर एक thin wrapper बना देना काफ़ी नहीं है
• लेकिन उलटी दिशा में की गई गलती की कीमत और भी ज़्यादा हो सकती है
  • पिछले साल, बिना किसी स्पष्ट product vision या target market के model training और customization पर भारी venture capital खर्च किया गया
  • एक कंपनी ने तो पूरे 6 billion dollar की Series A funding भी जुटा ली
• यह section समझाता है कि तुरंत अपना खुद का model train करना शुरू करना क्यों ग़लती है, और self-hosting की भूमिका पर भी विचार करता है

शुरुआत से (लगभग) दोबारा training करना सार्थक नहीं है

• अधिकांश संगठनों के लिए शुरू से LLM को pretrain करना प्रोडक्ट डेवलपमेंट से भटका हुआ एक अव्यावहारिक काम है
  • मशीन लर्निंग इन्फ्रास्ट्रक्चर के विकास और रखरखाव में बहुत अधिक संसाधन लगते हैं
    • इसमें डेटा संग्रह, मॉडल ट्रेनिंग और मूल्यांकन, डिप्लॉयमेंट आदि शामिल हैं
  • यदि आप product-market fit को सत्यापित करने के चरण में हैं, तो ऐसा प्रयास मुख्य प्रोडक्ट डेवलपमेंट से संसाधनों को भटका देता है
  • भले ही computing resources, डेटा और तकनीकी क्षमता मौजूद हो, pretrain किया गया LLM कुछ ही महीनों में पुराना पड़ सकता है
• BloombergGPT का उदाहरण
  • वित्तीय कार्यों के लिए विशेषीकृत LLM BloombergGPT को 363B tokens पर pretrain किया गया था
  • AI engineering के 4 और ML product व research के 5 सहित कुल 9 full-time कर्मचारियों का भारी प्रयास इसमें लगा
  • इसके बावजूद, एक साल के भीतर वह उसी काम में gpt-3.5-turbo और gpt-4 से पीछे रह गया
• ऐसे उदाहरण संकेत देते हैं कि अधिकांश वास्तविक applications में LLM को शुरू से pretrain करना संसाधनों का सर्वोत्तम उपयोग नहीं है
  • इसके बजाय, टीमों के लिए अपनी विशिष्ट आवश्यकताओं के अनुसार उपलब्ध सबसे शक्तिशाली open source मॉडल को fine-tune करना बेहतर है
• बेशक, अपवाद भी हैं
  • Replit का code model code generation और understanding के लिए विशेष रूप से pretrain किए जाने का एक बेहतरीन उदाहरण है
  • pretraining की वजह से उसने CodeLlama7b जैसे बड़े मॉडलों से बेहतर प्रदर्शन दिखाया
  • लेकिन जैसे-जैसे अधिक शक्तिशाली मॉडल जारी हुए, उसकी उपयोगिता बनाए रखने के लिए लगातार निवेश की आवश्यकता पड़ी

ज़रूरत सिद्ध होने तक fine-tuning से बचें

• अधिकांश संगठनों में fine-tuning रणनीतिक सोच से अधिक FOMO(Fear Of Missing Out, छूट जाने का डर) से संचालित होती है
  • संगठन "सिर्फ एक wrapper" कहे जाने की आलोचना से बचने के लिए बहुत जल्दी fine-tuning में निवेश कर देते हैं
  • वास्तव में, fine-tuning को उस भारी उपकरण की तरह तैनात किया जाना चाहिए जिसे तभी इस्तेमाल किया जाए जब पर्याप्त उदाहरण इकट्ठे हो जाएँ कि दूसरे approaches पर्याप्त नहीं हैं
• एक साल पहले कई टीमों ने fine-tuning को लेकर उत्साह दिखाया था, लेकिन बहुत कम टीमों को product-market fit मिला और अधिकांश ने अपने फैसले पर पछतावा किया
  • यदि आप fine-tuning करने जा रहे हैं, तो base model में सुधार होने पर उसे बार-बार दोहराने के लिए तैयार रहना होगा
    • नीचे दिए गए "मॉडल प्रोडक्ट नहीं है" और "LLMOps बनाना" देखें
• वे स्थितियाँ जहाँ fine-tuning वास्तव में सही विकल्प हो सकती है
  • जब ऐसे डेटा की ज़रूरत हो जो मौजूदा मॉडल ट्रेनिंग में इस्तेमाल किए गए अधिकांश खुले web-scale datasets में उपलब्ध न हो
  • जब आप पहले से ऐसा MVP बना चुके हों जो दिखाता हो कि मौजूदा मॉडल पर्याप्त नहीं हैं
  • लेकिन सावधान रहें: यदि बेहतरीन training data मॉडल बनाने वालों के लिए भी आसानी से उपलब्ध नहीं है, तो आपको वह कहाँ से मिलेगा?
• LLM-आधारित applications science fair project नहीं हैं
  • उनमें निवेश भी रणनीतिक लक्ष्यों और प्रतिस्पर्धी अलगाव में उनके योगदान के अनुपात में होना चाहिए

inference API से शुरुआत करें, लेकिन self-hosting से न डरें

• LLM API का उपयोग startups को शुरुआत से अपना मॉडल train किए बिना language modeling capabilities को आसानी से अपनाने और integrate करने देता है
  • Anthropic, OpenAI जैसे providers ऐसे सामान्य API देते हैं जो कुछ पंक्तियों के code से प्रोडक्ट में intelligence जोड़ सकते हैं
  • इन सेवाओं का उपयोग करने से प्रयास कम होता है और ग्राहक के लिए value creation पर ध्यान केंद्रित किया जा सकता है, जिससे ideas validate करना और product-market fit तक तेज़ी से iterate करना संभव होता है
• लेकिन database की तरह managed services भी scale और requirements बढ़ने पर हर use case के लिए उपयुक्त नहीं रहतीं
  • वास्तव में, healthcare और finance जैसे regulated industries में, या contractual obligations तथा confidentiality requirements के कारण, self-hosting ही ऐसा एकमात्र तरीका हो सकता है जिससे confidential/personal data को network के बाहर भेजे बिना मॉडल का उपयोग किया जा सके
• self-hosting inference providers द्वारा लगाए गए rate limits, model deprecation, usage restrictions जैसी बाधाओं को भी पार कर देता है
  • self-hosting मॉडल पर पूर्ण नियंत्रण देता है, जिससे अलग और उच्च-गुणवत्ता वाले systems बनाना आसान होता है
• अंत में, self-hosting, खासकर fine-tuning, बड़े पैमाने पर लागत भी घटा सकती है
  • उदाहरण के लिए, Buzzfeed ने open source LLM को fine-tune करके लागत में 80% कमी का मामला साझा किया था

रणनीति 2: बेहतर की ओर iterate करना

• लंबे समय तक प्रतिस्पर्धात्मक बढ़त बनाए रखने के लिए मॉडल से आगे बढ़कर उन चीज़ों पर विचार करना होगा जो प्रोडक्ट को अलग बनाती हैं
• execution speed महत्वपूर्ण है, लेकिन वही एकमात्र लाभ नहीं होना चाहिए

मॉडल प्रोडक्ट नहीं है, बल्कि उस मॉडल के आसपास बना सिस्टम ही प्रोडक्ट है

• जो टीमें खुद मॉडल नहीं बनातीं, उनके लिए innovation की तेज़ रफ्तार एक वरदान है
  • क्योंकि वे context size, reasoning capability, और price-performance जैसी चीज़ों में सुधार खोजते हुए नए मॉडलों पर migrate कर बेहतर प्रोडक्ट बना सकती हैं
  • यह प्रगति इतनी लगातार है कि लगभग अनुमानित लगती है
  • कुल मिलाकर, मॉडल सिस्टम का सबसे कम टिकाऊ component होने की संभावना है
• इसके बजाय, प्रयास उन हिस्सों पर केंद्रित होना चाहिए जो स्थायी value दे सकते हैं
  • Evals: अलग-अलग मॉडलों में task performance को विश्वसनीय रूप से मापने के लिए
  • Guardrails: मॉडल चाहे जो हो, अवांछित outputs को रोकने के लिए
  • Caching: मॉडल को पूरी तरह bypass करके latency और लागत घटाने के लिए
  • Data flywheel: ऊपर की हर चीज़ में दोहरावदार सुधार चलाने के लिए
  • ये components कच्ची मॉडल क्षमता की तुलना में प्रोडक्ट quality के लिए कहीं गहरी moat बनाते हैं
• लेकिन इसका मतलब यह नहीं कि application layer में बनाना जोखिम-मुक्त है
  • यदि OpenAI या कोई अन्य model provider व्यवहार्य enterprise software देने जा रहा है, तो वहाँ अनावश्यक रूप से गहराई तक न जाएँ जहाँ वे जल्द ही खुद समाधान दे सकते हैं
• उदाहरण के लिए, कुछ टीमों ने proprietary models से structured outputs validate करने के लिए custom tools बनाने में निवेश किया
  • यहाँ न्यूनतम निवेश महत्वपूर्ण है, लेकिन बहुत गहराई से निवेश करना समय का अच्छा उपयोग नहीं है
  • OpenAI को function calling माँगे जाने पर valid function call सुनिश्चित करना ही चाहिए, क्योंकि हर ग्राहक यही चाहेगा
  • यहाँ "रणनीतिक देरी" लागू करें, केवल वही बनाएँ जो बिल्कुल आवश्यक है, और provider की capabilities बढ़ने का इंतज़ार करें

छोटे से शुरू करें और भरोसा कमाएँ

• ऐसा प्रोडक्ट बनाना जो हर किसी के लिए सब कुछ बनने की कोशिश करे, औसतपन का नुस्खा है
• एक प्रभावशाली प्रोडक्ट बनाने के लिए कंपनियों को ऐसे sticky experience बनाने में विशेषज्ञता हासिल करनी चाहिए जो उपयोगकर्ताओं को बार-बार वापस लाएँ
• ऐसा सामान्य RAG system सोचिए जिसका लक्ष्य उपयोगकर्ता के हर प्रश्न का उत्तर देना हो
  • specialization की कमी का अर्थ है कि सिस्टम ताज़ा जानकारी को प्राथमिकता नहीं दे सकता, domain-specific formats parse नहीं कर सकता, या किसी विशिष्ट task की बारीकियों को नहीं समझ सकता
  • परिणामस्वरूप, उपयोगकर्ता को सतही और अविश्वसनीय अनुभव मिलता है, जो उसकी ज़रूरतें पूरी नहीं करता और वह छोड़कर चला जाता है
• इसे हल करने के लिए, किसी विशिष्ट domain और use case पर ध्यान केंद्रित करना होगा
  • breadth की जगह depth जोड़ते हुए scope को संकीर्ण करना चाहिए
  • इससे ऐसे domain-specific tools बनाए जा सकते हैं जो उपयोगकर्ता से जुड़ाव पैदा करें
• specialization के ज़रिए सिस्टम की capabilities और limitations को ईमानदारी से बताया जा सकता है
  • सिस्टम क्या कर सकता है और क्या नहीं, इस बारे में पारदर्शी होना self-awareness दिखाता है, उपयोगकर्ता को समझने में मदद करता है कि उसे सबसे अधिक value कहाँ मिल सकती है, और अंततः output पर भरोसा और confidence बनाता है

LLMOps बनाएँ, लेकिन सही कारणों से: तेज़ iteration

• DevOps मूल रूप से reproducible workflow, shift-left, या two-pizza teams को सशक्त बनाने के बारे में नहीं है। YAML फ़ाइलें लिखना तो बिल्कुल भी नहीं
• DevOps का मतलब है काम और उसके परिणामों के बीच feedback loop को छोटा करना, ताकि गलतियों के बजाय सुधार जमा होते जाएँ
  • इसकी जड़ें lean startup movement के ज़रिए lean manufacturing और Toyota Production System तक जाती हैं, जहाँ single-minute die exchange और kaizen पर ज़ोर दिया गया था
• MLOps ने DevOps के रूप को ML पर लागू किया
  • इसमें reproducible experiments और model builders को deploy करने में सक्षम बनाने वाले all-in-one tool suites शामिल हैं। YAML फ़ाइलें भी बहुत हैं
• लेकिन एक उद्योग के रूप में MLOps ने DevOps के कार्य को नहीं अपनाया। इसने models और production में inference तथा interactions के बीच feedback gap को कम नहीं किया
• सौभाग्य से, LLMOps क्षेत्र prompt management जैसी मामूली समस्याओं से आगे बढ़कर continuous improvement की दिशा में मुड़ा है, जो production monitoring और evals जैसी उन कठिन समस्याओं तक पहुँचता है जो iteration में रुकावट डालती हैं
• chat और coding models के लिए neutral और crowdsourced evals हेतु interactive arenas पहले से मौजूद हैं। यह सामूहिक और iterative improvement का बाहरी loop है
  • LangSmith, Log10, LangFuse, W&B Weave, HoneyHive जैसे tools न सिर्फ production में system outputs का data इकट्ठा और व्यवस्थित करने का वादा करते हैं, बल्कि development के साथ गहराई से integrate होकर उसी system को बेहतर बनाने में उसका उपयोग करने का भी वादा करते हैं। इन tools को अपनाएँ या खुद बनाइए

ऐसे LLM features मत बनाइए जिन्हें खरीदा जा सकता है

• ज़्यादातर सफल businesses, LLM business नहीं हैं। साथ ही, ज़्यादातर businesses में LLM से सुधार के अवसर मौजूद हैं
• ये दोनों अवलोकन अक्सर leaders को गुमराह करते हैं, जिससे वे लागत बढ़ाते हुए और गुणवत्ता घटाते हुए systems को जल्दबाज़ी में LLM से retrofit कर देते हैं और दिखावटी, vanity-driven "AI" features के साथ उन्हें ship कर देते हैं। अब डरावना चमकदार icon तैयार है
• इसका बेहतर तरीका है: उन LLM applications पर ध्यान देना जो वास्तव में product goals के अनुरूप हों और core operations को मज़बूत करें
• आइए टीम के समय को बर्बाद करने वाली कुछ गलत कोशिशों पर विचार करें
  • business के लिए custom text-to-SQL feature बनाना
  • documents के साथ बातचीत कर सकने वाला chatbot बनाना
  • company knowledge base को customer support chatbot के साथ integrate करना
• ऊपर दी गई चीज़ें LLM applications की hello world हैं, लेकिन इन्हें किसी product company द्वारा खुद बनाना तर्कसंगत नहीं है
  • यह कई businesses में साझा होने वाली सामान्य समस्या है, जहाँ promising demos और reliable components के बीच बड़ा अंतर होता है, और यह software companies का पारंपरिक क्षेत्र है
  • जिन सामान्य समस्याओं को अभी Y Combinator batch में बड़े पैमाने पर हल किया जा रहा है, उन पर कीमती R&D resources लगाना बर्बादी है
• अगर यह घिसा-पिटा business advice लगता है, तो वजह यह है कि मौजूदा hype wave के उत्साह में "LLM" जैसी चीज़ों को cutting-edge differentiator समझ लेना आसान है, और उन applications को नज़रअंदाज़ कर देना भी आसान है जो पहले से साधारण हो चुकी हैं

AI को loop में रखिए, इंसान को केंद्र में रखिए

• आज के LLM-आधारित applications नाज़ुक हैं। इन्हें भारी मात्रा में safety measures और defensive engineering चाहिए, फिर भी ये अनुमान लगाना कठिन बने रहते हैं। इसके बावजूद, जब इन्हें कड़े दायरे में रखा जाए, तो ये applications बेहद उपयोगी हो सकते हैं। इसका मतलब है कि LLM user workflows को तेज़ करने के लिए बेहतरीन tools बनते हैं
• आप कल्पना करना चाह सकते हैं कि LLM-आधारित applications workflows को पूरी तरह replace कर देंगे या job functions को संभाल लेंगे, लेकिन आज सबसे प्रभावी paradigm human-computer centaur है (Centaur chess)
  • सक्षम इंसान, जब अपने तेज़ उपयोग के लिए ट्यून की गई LLM capabilities के साथ जुड़ता है, तो काम करने की productivity और संतुष्टि दोनों में बड़ा सुधार हो सकता है
  • LLM का एक प्रतिनिधि application, GitHub CoPilot, इस workflow की शक्ति साबित कर चुका है
    • "कुल मिलाकर, developers ने कहा कि GitHub Copilot और GitHub Copilot Chat का उपयोग करने पर coding आसान हो गई, errors कम हुए, readability, reusability और conciseness बेहतर हुए, और code को maintain करना और resilient बनाना आसान हुआ।" - Mario Rodriguez, GitHub
• लंबे समय से ML पर काम कर रहे लोग जल्दी से "human-in-the-loop" के विचार तक पहुँच सकते हैं, लेकिन इतनी जल्दी मत कीजिए
  • HITL machine learning एक ऐसा paradigm है जो इस बात को सुनिश्चित करने के लिए human experts पर आधारित है कि ML model अपेक्षा के अनुसार काम करे
  • यहाँ जो प्रस्तावित किया जा रहा है, वह उससे जुड़ा हुआ है, लेकिन अधिक सूक्ष्म है। LLM-आधारित systems आज अधिकांश workflows की मुख्य driving force नहीं होने चाहिए; उन्हें सिर्फ एक resource होना चाहिए
• इंसान को केंद्र में रखकर यह पूछना कि LLM workflow को कैसे support कर सकता है, product और design decisions पर काफ़ी अलग प्रभाव डालता है
  • अंततः, आप उन competitors से अलग product बनाएँगे जो हर ज़िम्मेदारी को जल्दी से LLM को outsource करना चाहते हैं — यानी बेहतर product, अधिक उपयोगी और कम जोखिम वाला product

रणनीति 3. prompting, eval, और data collection से शुरुआत करें

• पिछले section में हमने तकनीकों और सलाह की पूरी ताकत झोंक दी थी। यह आत्मसात करने के लिए बहुत है
  • अगर कोई टीम LLM product बनाना चाहती है, तो उसे कहाँ से शुरू करना चाहिए?
• पिछले 1 साल में हमने इतना देखा है कि भरोसे के साथ कह सकें कि सफल LLM applications एक consistent trajectory का पालन करते हैं। इस section में हम इस बुनियादी "getting started" playbook को देखेंगे
• मुख्य विचार है सरल शुरुआत करना और ज़रूरत पड़ने पर complexity जोड़ना
  • Rule of Thumb: sophistication के हर स्तर के लिए आम तौर पर पिछले चरण की तुलना में कम-से-कम एक order of magnitude अधिक मेहनत लगती है। इसे ध्यान में रखते हुए...

prompt engineering पहली प्राथमिकता है

• prompt engineering से शुरुआत करें
  • tactics section में पहले चर्चा की गई सभी तकनीकों का उपयोग करें
  • Chain-of-thought, n-shot examples, और structured inputs/outputs लगभग हमेशा अच्छे विचार होते हैं
  • कमज़ोर model से performance निचोड़ने से पहले सबसे capable model के साथ prototype बनाएँ
• केवल तब fine-tuning पर विचार करें जब prompt engineering से वांछित performance level हासिल न हो
  • यह ज़्यादा बार तब होगा जब non-functional requirements (जैसे data privacy, complete control, cost) proprietary models के उपयोग को रोकें और self-hosting की माँग करें
  • ध्यान रखें कि वही privacy requirements fine-tuning के लिए user data के उपयोग को भी न रोक दें

evals बनाएँ और data flywheel शुरू करें

• जो टीमें अभी शुरुआत कर रही हैं, उन्हें भी evals की ज़रूरत है। वरना यह पता नहीं चलेगा कि prompt engineering काफ़ी है या नहीं, या fine-tuned model base model को replace करने के लिए तैयार है या नहीं
• प्रभावी evals task-specific होते हैं और intended use case को दर्शाते हैं
  • हमारी सिफ़ारिश के अनुसार evals का पहला स्तर unit tests है
  • ये सरल assertions ज्ञात या परिकल्पित failure modes को पकड़ने और शुरुआती design decisions लेने में मदद करते हैं
  • classification, summarization आदि के लिए अन्य task-specific evals भी देखें
• unit tests और model-based evals उपयोगी हैं, लेकिन वे human evaluation की ज़रूरत को replace नहीं करते
  • लोगों को model/product का उपयोग करने और feedback देने दें
  • इससे दोहरे उद्देश्य पूरे होते हैं: वास्तविक performance और defect rate को मापना, और साथ ही उच्च-गुणवत्ता वाला annotated data इकट्ठा करना, जिसका उपयोग आगे चलकर model को fine-tune करने में किया जा सके
  • इससे समय के साथ compound होने वाला positive feedback loop, या data flywheel, बनता है
    • model performance का मूल्यांकन करने या defects खोजने के लिए human evaluation
    • annotated data का उपयोग कर model को fine-tune करना या prompt को update करना
    • दोहराना
• उदाहरण के लिए, LLM-generated summaries में defects का audit करते समय आप हर sentence के लिए factual inconsistency, irrelevance, या poor style की पहचान करने वाले granular feedback labels दे सकते हैं
  • फिर इन factual inconsistency annotations का उपयोग hallucination classifier train करने के लिए, या relevance annotations का उपयोग relevance reward model train करने के लिए किया जा सकता है
• LinkedIn ने hallucinations, responsible AI violations, coherence आदि का अनुमान लगाने के लिए model-based evaluators के उपयोग के सफल उदाहरण साझा किए हैं
• समय के साथ मूल्य बढ़ाने वाली assets बनाकर, evals का निर्माण केवल operational expense से बदलकर strategic investment में किया जा सकता है, और इसी प्रक्रिया में data flywheel भी बनाया जा सकता है

रणनीति 4. कम-लागत cognition की high-level trend (The high-level trend of low-cost cognition)

• 1971 में Xerox PARC के शोधकर्ताओं ने नेटवर्क से जुड़े personal computer की उस दुनिया की भविष्यवाणी की थी जिसमें हम आज रहते हैं
  • उन्होंने उस भविष्य को जन्म देने में योगदान दिया, क्योंकि उसे संभव बनाने वाली तकनीकों (Ethernet, graphic rendering, mouse, window आदि) के आविष्कार में उनकी केंद्रीय भूमिका थी
• उन्होंने एक सरल अभ्यास भी किया
  • उन्होंने ऐसे applications को देखा जो बेहद उपयोगी थे (जैसे: video display) लेकिन अभी किफायती नहीं थे (video display चलाने लायक पर्याप्त RAM की कीमत हजारों डॉलर थी)
  • फिर उन्होंने उस तकनीक के ऐतिहासिक price trends (Moore's Law जैसे) को देखा और अनुमान लगाया कि वह तकनीक कब किफायती होगी
• LLM तकनीक के लिए भी यही किया जा सकता है, भले ही यह प्रति डॉलर transistor count जितना साफ-सुथरा न हो
  • लंबे समय से इस्तेमाल हो रहे लोकप्रिय benchmark (जैसे: Massively-Multitask Language Understanding dataset) और एक consistent input approach (5-shot prompting) चुनें
  • फिर समय के साथ इस benchmark पर अलग-अलग performance levels वाले language models को चलाने की लागत की तुलना करें
• स्थिर लागत पर क्षमता तेज़ी से बढ़ रही है। स्थिर क्षमता स्तर पर लागत तेज़ी से घट रही है
  • OpenAI के davinci model के API के रूप में जारी होने के बाद के 4 वर्षों में, 10 लाख tokens (इस दस्तावेज़ की लगभग 100 प्रतियों) के पैमाने पर उस काम के बराबर प्रदर्शन देने वाले model को चलाने की लागत $20 से घटकर 10 सेंट से भी कम हो गई है। इसका half-life सिर्फ 6 महीने है
  • इसी तरह मई 2024 तक API providers के जरिए या खुद Meta के LLaMA 3 8B को चलाने की लागत सिर्फ 20 सेंट प्रति 10 लाख tokens है, और यह OpenAI के text-davinci-003, यानी ChatGPT को संभव बनाने वाले model, जैसी performance दिखाता है
  • यही model नवंबर 2023 के अंत में लॉन्च के समय भी लगभग $20 प्रति 10 लाख tokens पड़ता था। सिर्फ 18 महीनों में दो अंकों का अंतर आ गया। यही वह अवधि है जिसमें Moore's Law सिर्फ साधारण doubling की भविष्यवाणी करता
• अब ऐसे LLM applications पर विचार करें जो बेहद उपयोगी हैं (जैसे Park et al की तरह generative video game characters चलाना), लेकिन अभी किफायती नहीं हैं (जिनकी अनुमानित लागत $625 प्रति घंटा है)
  • उस paper के अगस्त 2023 में प्रकाशित होने के बाद से लागत लगभग एक अंक घटकर करीब $62.50 प्रति घंटा रह गई है
  • 9 महीने बाद इसके $6.25 प्रति घंटा तक गिरने की उम्मीद की जा सकती है
• दूसरी ओर, जब Pac-Man 1980 में रिलीज़ हुआ था, तब आज के $1 में कुछ मिनटों या कई दसियों मिनट तक खेलने लायक credits खरीदे जा सकते थे। यानी 6 games per hour, या $6 per hour
  • यह napkin calculation संकेत देती है कि आकर्षक LLM-enhanced game experiences 2025 के आसपास आर्थिक रूप से व्यवहार्य हो जाएंगे
• यह रुझान नया है और सिर्फ कुछ साल पुराना है। फिर भी अगले कुछ वर्षों में इसके धीमा पड़ने की उम्मीद करने का लगभग कोई कारण नहीं है
  • भले ही हम algorithm और dataset वाले low-hanging fruit, जैसे प्रति parameter ~20 tokens के "Chinchilla ratio" से आगे scaling, का उपयोग कर लें, फिर भी data center के भीतर और silicon stack में गहरे innovation और investment इस अंतर को भर देंगे
• और यही शायद सबसे महत्वपूर्ण रणनीतिक तथ्य है
  • आज जो floor demos या research papers पूरी तरह अव्यावहारिक लगते हैं, वे कुछ वर्षों बाद premium features बनेंगे और उसके तुरंत बाद commodity बन जाएंगे
  • इसे ध्यान में रखकर systems और organizations बनाने चाहिए

[0 से 1 तक जाने वाले demos अब काफी हैं। अब 1 से N तक जाने वाले products बनाने का समय है]

• LLM demos बनाना सचमुच मज़ेदार है। कुछ lines of code, एक vector database, और सावधानी से लिखे गए prompts से "magic" पैदा हो जाता है
• पिछले 1 साल में इस magic की तुलना internet, smartphone, यहाँ तक कि printing press से भी की गई है
• दुर्भाग्य से, जैसा कि real software shipping का काम कर चुके लोग जानते हैं, नियंत्रित माहौल में चलने वाले demo और बड़े पैमाने पर भरोसेमंद ढंग से काम करने वाले product के बीच बहुत बड़ा अंतर होता है
• कल्पना करना और demo बनाना आसान है, लेकिन उसे product बनाना बेहद कठिन है
  • उदाहरण के लिए autonomous driving: किसी कार को एक block तक खुद चलाते दिखाना आसान है, लेकिन उसे product बनाने में 10 साल लगते हैं - Andrej Karpathy
• autonomous vehicles का उदाहरण लें
  • 1988 में neural network से चलने वाली पहली car सामने आई
  • 25 साल बाद Andrej Karpathy ने Waymo में पहला demo ride लिया
  • उसके 10 साल बाद कंपनी को driverless operation की अनुमति मिली
  • prototype से commercial product तक पहुँचने में 35 साल की कठोर engineering, testing, refinement, और regulatory navigation लगी
• उद्योग और अकादमिक जगत में पिछले 1 साल के उतार-चढ़ाव को देखते हुए: LLM applications के लिए 1वाँ साल (Year 1 of N for LLM applications)
  • उम्मीद है कि हमने जो सबक सीखे हैं—evaluation, prompt engineering, guardrails जैसी tactics से लेकर operational skills, team building, और किन क्षमताओं को in-house बनाना है जैसी strategic perspectives तक—वे साल 2 और उसके बाद मददगार होंगे
  • हम इस रोमांचक नई तकनीक को मिलकर आगे बढ़ाने के लिए उत्सुक हैं

[inthelife]

कंटेंट अच्छा लगा, इसलिए बाद में भी देखते रहने के लिए मैंने इसे Mindmap में बना दिया ^^;

https://drive.google.com/file/d/…

[hheungsu]

बहुत ही शानदार लेख है!! शुरुआत से अंत तक इसमें ऐसी कई उपयोगी बातें हैं जिन पर बार-बार सोचने लायक है। ऐसा नायाब लेख अनुवाद करके साझा करने के लिए धन्यवाद!!

[nutella]

इस समय के लिहाज़ से यह वाकई बहुत मददगार है।

[komanabi]

Megastudy ख़त्म हो गया, Omega 3 आ रहा है!!!

[ssifood]

अब Skynet खत्म हो चुका है, MegaStudy आ रहा है।

[my0075425]

अब मानवता का अंत है, Skynet आ रहा है!!

[zihado]

मूल लेख के लेखक का करियर भी दिलचस्प था
https://hi.news.hada.io/topic?id=1626

[eungook]

वाह.. यह बेहद प्रेरक है.. परिचय के लिए धन्यवाद

[humblebee]

यह वाकई एक शानदार लेख है जिसमें अंतर्दृष्टि और अनुभव बहुत जीवंत रूप से महसूस होते हैं! मुझे लगता है कि यह मेरे और मेरी टीम के लिए बहुत मददगार होगा। मैंने इसे बहुत रुचि से पढ़ा। धन्यवाद ☺️