शब्द "zero-shot" और "few-shot" machine learning शोध परंपरा से आते हैं, जहाँ "shot" एक प्रशिक्षण उदाहरण को संदर्भित करता है। Classical ML में, आपको एक नया कार्य सिखाने के लिए हज़ारों या लाखों labeled उदाहरणों की आवश्यकता थी। बड़े भाषा मॉडलों के साथ revelation यह थी कि वे शून्य प्रशिक्षण उदाहरणों (zero-shot) या prompt में केवल कुछ demonstrations (few-shot) के साथ कार्य कर सकते हैं। इसे "in-context learning" कहा जाता है, और यह आधुनिक LLMs की सबसे remarkable क्षमताओं में से एक बना हुआ है — मॉडल को retrained या fine-tuned नहीं किया जा रहा है जब आप इसे prompt में उदाहरण देते हैं। यह अपने context में patterns को पहचान रहा है और उन्हें fly पर लागू कर रहा है।
Zero-shot सबसे अच्छा काम करता है जब कार्य कुछ ऐसी चीज़ पर साफ़ तरीके से map होता है जिसे मॉडल ने प्रशिक्षण में extensively देखा है। Sentiment analysis, translation, summarization, सरल classification — ये ऐसे कार्य हैं जिन्हें मॉडल ने pre-training के दौरान लाखों variations में encountered किया है, इसलिए एक स्पष्ट निर्देश अक्सर पर्याप्त होता है। "इस customer review को positive, negative, या neutral के रूप में classify करें" किसी भी आधुनिक फ्रंटियर मॉडल पर zero-shot काम करेगा क्योंकि मॉडल गहराई से समझता है कि classification, sentiment, और उन labels का क्या अर्थ है। जहाँ zero-shot विफल होता है वह असामान्य formats, domain-specific conventions, या ambiguous आवश्यकताओं वाले कार्यों पर है। यदि आपको मॉडल को अपनी कंपनी के proprietary XML schema में डेटा output करने की आवश्यकता है, तो एक bare निर्देश काम नहीं करेगा।
Few-shot prompting उस gap को भरता है। वास्तविक अनुरोध से पहले 2-5 input-output उदाहरण प्रदान करके, आप मॉडल को ठीक वही दिखाते हैं जो आप expect करते हैं। मॉडल pattern को pick up करता है — format, विवरण का स्तर, style, edge case handling — और इसे नए input पर लागू करता है। यह structured कार्यों के लिए remarkably शक्तिशाली है। एक विशिष्ट JSON format में messy text से entities निकालने की आवश्यकता है? clean JSON में mapped messy text के तीन उदाहरण दिखाएँ, फिर इसे नया text दें। natural-language dates ("अगला Tuesday," "March का दूसरा सप्ताह") को ISO 8601 में बदलने की आवश्यकता है? तीन उदाहरण आपको 95% रास्ता मिल जाते हैं। मॉडल अनिवार्य रूप से आपके उदाहरणों से एक function सीख रहा है, और यह बिना किसी gradient updates के inference समय पर ऐसा कर रहा है।
आपके few-shot उदाहरणों की quality मात्रा से अधिक मायने रखती है। तीन सावधानी से चुने गए उदाहरण जो विभिन्न edge cases को कवर करते हैं वे दस repetitive उदाहरणों से बेहतर प्रदर्शन करेंगे। यदि आपके कार्य में categories शामिल हैं, तो प्रति category कम से कम एक उदाहरण शामिल करें। यदि tricky boundary cases हैं, तो एक शामिल करें। और उदाहरणों का क्रम मायने रख सकता है — शोध ने दिखाया है कि मॉडल वे जो अंतिम उदाहरण देखते हैं उसके label की ओर biased हो सकते हैं, इसलिए अपने उदाहरणों को shuffle या balance करना worth है। एक व्यावहारिक tip: एक उदाहरण शामिल करें कि मॉडल को क्या करना चाहिए जब input ambiguous है या किसी category में fit नहीं होता, क्योंकि वह edge case production में लगातार आता है और एक unguided मॉडल बस अनुमान लगाएगा।
विचार करने के लिए एक लागत-quality trade-off है। हर few-shot उदाहरण आपके context window से tokens का उपभोग करता है और आपकी API लागतों में जोड़ता है। 200 tokens प्रत्येक के पाँच उदाहरण प्रति request 1,000 tokens हैं, जो scale पर जुड़ते हैं। कुछ टीमें विकास के दौरान few-shot prompting के साथ शुरू करती हैं, मापती हैं कि कौन से उदाहरण वास्तव में परिणामों में सुधार कर रहे हैं, और फिर pattern को एक clearer zero-shot निर्देश में distill करने की कोशिश करती हैं। अन्य dynamic few-shot चयन का उपयोग करते हैं — एक डेटाबेस में उदाहरणों की एक library संग्रहीत करना और हर विशिष्ट input के लिए सबसे प्रासंगिक को retrieve करना, जो अनिवार्य रूप से prompt engineering पर लागू RAG का एक lightweight रूप है। Sweet spot आपके कार्य की जटिलता, आपकी volume, और क्या एकरूपता या लागत आपके use case के लिए अधिक मायने रखती है पर निर्भर करता है।