अंतिम समीक्षा: जून 2026
AI-103 परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक चैट सुविधा उच्च मात्रा में, छोटे, सरल चरणों और कम लेटेंसी व लागत बजट के साथ चलती है।
फ्रंटियर LLM के बजाय Foundry मॉडल कैटलॉग से Phi जैसे छोटे भाषा मॉडल (SLM) को डिप्लॉय करें।
क्यों: SLM संकीर्ण कार्यों के लिए लागत और लेटेंसी कम करते हैं; जटिल तर्क के लिए बड़े LLM को आरक्षित रखें। मॉडल का आकार कार्य से मिलाएं, ब्रांड से नहीं।
एक single agent को एक ही अनुरोध में उपयोगकर्ता द्वारा अपलोड की गई छवियों और टेक्स्ट पर तर्क करना होगा।
Foundry कैटलॉग में एक multimodal मॉडल (जैसे GPT-4o फैमिली) चुनें, बजाय इसके कि एक vision मॉडल को टेक्स्ट-ओनली LLM में जोड़ा जाए।
क्यों: नेटिव multimodal मॉडल एक ही प्रॉम्प्ट में छवि और टेक्स्ट स्वीकार करते हैं; एक टेक्स्ट-ओनली मॉडल एक लॉस-कैप्शन हैंड-ऑफ को मजबूर करता है जो विज़ुअल विवरण खो देता है।
उत्तर एक निजी कॉर्पोरेट नॉलेज बेस पर आधारित होने चाहिए, न कि मॉडल के pretraining पर।
एक retrieval लेयर बनाएं: Azure AI Search में corpus को vector embeddings के साथ इंडेक्स करें और उस इंडेक्स पर RAG के माध्यम से मॉडल को ग्राउंड करें।
क्यों: Grounding inference पर पुनः प्राप्त, उद्धृत संदर्भ को इंजेक्ट करता है; fine-tuning ज्ञान को statically रूप से बेक करता है और इसे आसानी से उद्धृत या अपडेट नहीं कर सकता।
एक agent को आंतरिक REST APIs को कॉल करने और एक इंडेक्स किए गए डॉक्यूमेंट स्टोर से भी पुनः प्राप्त करने की आवश्यकता है।
APIs को agent tools (function/OpenAPI) के रूप में रजिस्टर करें और Foundry agent पर AI Search इंडेक्स को ज्ञान स्रोत के रूप में अटैच करें।
क्यों: Tools agent को कार्रवाई की क्षमता देते हैं; knowledge sources grounded retrieval देते हैं। वे अलग-अलग एकीकरण सतहें हैं, एक ही कनेक्टर नहीं।
कई टीमों को साझा शासन के तहत पृथक agent configs, कनेक्शन और डिप्लॉयमेंट की आवश्यकता है।
प्रति-टीम Foundry प्रोजेक्ट्स के साथ एक Foundry हब का उपयोग करें; प्रत्येक प्रोजेक्ट अपने कनेक्शन, डिप्लॉयमेंट और एक्सेस को स्कोप करता है।
क्यों: हब नेटवर्किंग, नीति और साझा संसाधनों को केंद्रीकृत करता है; प्रोजेक्ट एक ऐप या टीम के लिए workspace unit है। टीमों के बीच एक प्रोजेक्ट साझा न करें।
एक प्रोडक्शन ऐप को मॉडल डिप्लॉयमेंट के लिए अनुमानित डेटा रेजिडेंसी और आरक्षित throughput की आवश्यकता है।
रेजिडेंसी-संवेदनशील, उच्च-throughput वाले वर्कलोड के लिए Global डिप्लॉयमेंट के बजाय Standard (क्षेत्रीय) या Provisioned Throughput (PTU) डिप्लॉयमेंट का उपयोग करें।
क्यों: Global डिप्लॉयमेंट क्षमता के लिए किसी भी क्षेत्र में रूट करते हैं; Standard क्षेत्र को पिन करता है, और PTU स्थिर लेटेंसी के लिए क्षमता आरक्षित करता है। रेजिडेंसी और SLA आवश्यकताओं के अनुसार चुनें।
प्रॉम्प्ट और agent परिभाषाओं को समीक्षा और रोलबैक के साथ dev से prod में जाना चाहिए।
प्रॉम्प्ट फ्लो / agent परिभाषाओं को एक repo में कोड के रूप में स्टोर करें और उन्हें Azure DevOps या GitHub Actions पाइपलाइन के साथ वातावरण के माध्यम से बढ़ावा दें।
क्यों: प्रॉम्प्ट्स और agent config को versioned artifacts के रूप में मानें; prod में मैन्युअल पोर्टल एडिट्स का कोई ऑडिट ट्रेल या रोलबैक पथ नहीं होता है।
ट्रैफ़िक के एक बड़े प्रवाह से मॉडल डिप्लॉयमेंट के खिलाफ 429 त्रुटियां उत्पन्न होती हैं।
डिप्लॉयमेंट के TPM/RPM कोटा को बढ़ाएँ जहाँ उपलब्ध हो, exponential backoff के साथ क्लाइंट-साइड retry जोड़ें, और गारंटीड क्षमता के लिए PTU डिप्लॉयमेंट पर विचार करें।
क्यों: कोटा प्रति मिनट टोकन की सीमा है; backoff क्षणिक थ्रॉटलिंग को सुचारू करता है। कोटा योजना के बिना duplicate संसाधनों को शुरू करने से bottleneck बस स्थानांतरित हो जाता है।
खर्च अप्रत्याशित है और लंबे RAG प्रॉम्प्ट्स का प्रभुत्व है।
अधिकतम आउटपुट टोकन को सीमित करें, retrieved context को top-k तक ट्रिम करें, reusable सिस्टम संदर्भ को कैश करें, और Azure Monitor में प्रति डिप्लॉयमेंट टोकन उपयोग को ट्रैक करें।
क्यों: लागत इनपुट और आउटपुट टोकन के साथ बढ़ती है; संदर्भ और आउटपुट को कम करना सीधा लीवर है। क्षेत्र या SKU को बदलना प्रति-टोकन मूल्य को शायद ही कभी सार्थक रूप से बदलता है।
कई हफ्तों के दौरान, प्रोडक्शन में उत्तर की गुणवत्ता और grounding fidelity खराब होती दिख रही है।
नमूना किए गए लाइव ट्रैफ़िक पर groundedness, relevance और coherence के लिए Foundry में निरंतर ऑनलाइन मूल्यांकन चलाएँ और स्कोर ड्रॉप्स पर अलर्ट करें।
क्यों: निर्धारित evaluators ऐसे drift का पता लगाते हैं जिन्हें आप raw latency metrics में नहीं देख सकते हैं; अकेले CPU/latency डैशबोर्ड कभी भी grounding regression को प्रकट नहीं करते हैं।
RAG उत्तर पुराने हो जाते हैं क्योंकि नए दस्तावेज़ पुनः प्राप्त नहीं किए जा रहे हैं।
AI Search indexer की रन हिस्ट्री और डॉक्यूमेंट काउंट्स की निगरानी करें; incremental indexing को शेड्यूल करें और failed indexer runs पर अलर्ट करें।
क्यों: जब indexer फेल हो जाता है या पीछे रह जाता है तो retrieval गुणवत्ता चुपचाप टूट जाती है; मॉडल-साइड मेट्रिक्स ठीक दिखते हैं क्योंकि डेटा पाइपलाइन में अंतर होता है।
एक ऐप को कॉन्फ़िग में किसी रहस्य के बिना Foundry मॉडल डिप्लॉयमेंट को कॉल करना होगा।
ऐप पर एक managed identity सक्षम करें और इसे "Cognitive Services OpenAI User" भूमिका प्रदान करें; API keys के बजाय Entra ID टोकन के साथ प्रमाणित करें।
क्यों: Keyless Entra auth leakable secrets को हटाता है और RBAC को केंद्रीकृत करता है; Key Vault में भी API keys को स्टोर करने से अभी भी एक key rotate और protect करने के लिए बची रहती है।
Foundry ट्रैफ़िक को कभी भी सार्वजनिक इंटरनेट पर नहीं जाना चाहिए।
Foundry संसाधन और dependencies को private endpoints के पीछे रखें, सार्वजनिक नेटवर्क एक्सेस को अक्षम करें, और private DNS zones के माध्यम से हल करें।
क्यों: Private endpoints VNet पर ट्रैफ़िक को पिन करते हैं; फ़ायरवॉल IP allow-lists अभी भी सार्वजनिक endpoints पर रूट करते हैं और कमजोर अलगाव हैं।
जनरेटेड प्रतिक्रियाओं में कभी-कभी घृणित या हिंसक सामग्री शामिल होती है।
hate, sexual, violence, और self-harm श्रेणियों के लिए उचित गंभीरता thresholds के साथ डिप्लॉयमेंट पर एक Azure AI Content Safety फ़िल्टर लागू करें।
क्यों: Content फ़िल्टर प्रॉम्प्ट्स और completions को सर्वर-साइड पर स्क्रीन करते हैं; केवल एक सिस्टम-प्रॉम्प्ट निर्देश पर निर्भर रहना jailbreaks द्वारा आसानी से बाईपास किया जा सकता है।
एक autonomous agent अपरिवर्तनीय क्रियाएँ निष्पादित कर सकता है जैसे कि refund जारी करना।
उच्च-प्रभाव वाले tools के लिए human-in-the-loop अनुमोदन गेट कॉन्फ़िगर करें और agent को अनुमत कार्रवाइयों के allow-listed सेट तक सीमित करें।
क्यों: अनुमोदन मोड और tool-access constraints स्वायत्तता को सीमित करते हैं; एक अनियंत्रित autonomous agent के पास विनाशकारी tool call पर कोई ब्रेक नहीं होता है।
Auditors को यह देखने की आवश्यकता है कि कौन से स्रोतों और tool calls ने एक निश्चित उत्तर दिया है।
प्रति अनुरोध प्रॉम्प्ट्स, retrieved citations, tool invocations और आउटपुट कैप्चर करने के लिए Foundry (OpenTelemetry) में tracing सक्षम करें।
क्यों: एंड-टू-एंड traces provenance और reproducibility प्रदान करते हैं; अकेले aggregate token metrics एक ही उत्तर की reasoning chain का पुनर्निर्माण नहीं कर सकते हैं।
एक backend सेवा को Foundry प्रोजेक्ट में परिभाषित मॉडल और agents को कॉल करना होगा।
मॉडल और agent क्लाइंट प्राप्त करने के लिए प्रोजेक्ट कनेक्शन स्ट्रिंग और DefaultAzureCredential के साथ Azure AI Foundry SDK (AIProjectClient) का उपयोग करें।
क्यों: प्रोजेक्ट क्लाइंट कनेक्शन और डिप्लॉयमेंट को केंद्रीकृत रूप से हल करता है; प्रति-मॉडल endpoints और keys को हार्डकोड करना प्रोजेक्ट governance को बाईपास करता है।
नीति दस्तावेज़ों पर आधारित एक Q&A ऐप बनाएँ।
दस्तावेज़ों को embed और इंडेक्स करें, प्रति क्वेरी top-k chunks पुनः प्राप्त करें, और उन्हें cite-your-sources निर्देश के साथ चैट completion में context के रूप में पास करें।
क्यों: RAG retraining के बिना ज्ञान को वर्तमान और उद्धृत करने योग्य रखता है; प्रॉम्प्ट में पूर्ण corpus को पास करने से context window और लागत बढ़ जाती है।
बातचीत के दौरान मॉडल को लाइव ऑर्डर स्थिति देखनी होगी।
JSON schema के साथ एक tool परिभाषित करें, मॉडल को tool call उत्सर्जित करने दें, इसे सर्वर-साइड निष्पादित करें, और परिणाम मॉडल को संक्षेप में प्रस्तुत करने के लिए लौटाएँ।
क्यों: Function/tool calling मॉडल को वास्तविक प्रणालियों को deterministically रूप से लागू करने देता है; स्थिति का "अनुमान" लगाने के लिए कहने से fabrications उत्पन्न होते हैं।
एक कार्य को अंतिम उत्तर से पहले कई आश्रित tool calls की आवश्यकता होती है।
एक tool-use लूप चलाएँ: प्रत्येक tool परिणाम को वापस मॉडल में फीड करें और तब तक iterate करें जब तक कि वह अधिकतम iteration कैप के साथ अंतिम संदेश वापस न कर दे।
क्यों: Iterative tool loops multistep reasoning का समर्थन करते हैं; एक single round trip आश्रित लुकअप को चेन नहीं कर सकता है, और एक uncapped लूप नियंत्रण से बाहर हो सकता है।
शिपिंग से पहले, यह निर्धारित करें कि एक RAG ऐप कितनी बार hallucinate करता है या विषय से भटक जाता है।
एक labeled test set पर groundedness, relevance और coherence के लिए Foundry evaluators चलाएँ और threshold scores पर release को गेट करें।
क्यों: Built-in evaluators मापने योग्य गुणवत्ता और सुरक्षा संकेत देते हैं; कुछ नमूनों को सरसरी तौर पर देखने से व्यवस्थित fabrication नहीं पकड़ में आती है।
एक support agent को एक स्पष्ट persona, लक्ष्यों और सीमाओं के साथ परिभाषित करें।
agent के सिस्टम निर्देश (भूमिका, लक्ष्य, अस्वीकृति नियम) सेट करें और केवल वही tools संलग्न करें जिनकी उसे अपने दायरे के लिए आवश्यकता है।
क्यों: सख्त निर्देश और न्यूनतम tool एक्सेस agent को कार्य पर बनाए रखते हैं; व्यापक निर्देश और प्रत्येक tool scope creep और असुरक्षित कार्यों को आमंत्रित करते हैं।
एक agent को एक सत्र के भीतर बातचीत के दौरान context याद रखना चाहिए।
Foundry Agent Service threads का उपयोग करें, जो प्रति बातचीत संदेश इतिहास को बनाए रखते हैं ताकि प्रत्येक run पिछली बातचीत देख सके।
क्यों: Threads प्रबंधित बातचीत स्मृति प्रदान करते हैं; प्रत्येक कॉल पर मैन्युअल रूप से पूरे ट्रांसक्रिप्ट को फिर से भेजना नाजुक है और गलत तरीके से truncate करना आसान है।
एक agent को custom plumbing के बिना web grounding और कोड execution की आवश्यकता है।
हाथ से integrations को रोल करने के बजाय Grounding with Bing Search और Code Interpreter जैसे built-in Foundry agent tools संलग्न करें।
क्यों: Managed tools out of the box शासित और समर्थित होते हैं; custom reimplementations रखरखाव जोड़ते हैं और platform safety controls को छोड़ देते हैं।
एक प्राथमिक agent को बिलिंग प्रश्नों को एक विशेष बिलिंग agent को सौंपना चाहिए।
connected agents का उपयोग करें: बिलिंग agent को एक tool के रूप में उजागर करें जिसे मुख्य agent कॉल कर सकता है, ताकि यह उप-कार्यों को विशेषज्ञों को रूट कर सके।
क्यों: Connected agents hierarchical delegation को सक्षम करते हैं; प्रत्येक डोमेन को एक मेगा-agent में cramming से निर्देश bloated हो जाते हैं और सटीकता खराब होती है।
एक वर्कफ़्लो को एक planner, एक researcher, और एक writer की आवश्यकता होती है जो साझा स्थिति के साथ सहयोग करते हैं।
उन्हें एक multi-agent फ्रेमवर्क (Semantic Kernel / AutoGen on Foundry) के साथ एक परिभाषित orchestration pattern और साझा context का उपयोग करके ऑर्केस्ट्रेट करें।
क्यों: फ्रेमवर्क turn-taking, state और termination का प्रबंधन करते हैं; agents के बीच ad-hoc स्ट्रिंग पासिंग में कोई समन्वय या स्टॉप कंडीशन नहीं होती है।
एक agent रात भर unattended चलता है और अकेले जोखिम भरे काम नहीं करना चाहिए।
इसे allow-listed tools, प्रति-कार्य बजट, content फ़िल्टर और एक checkpoint के साथ बांधें जो अनुमोदन के लिए उच्च-प्रभाव वाले चरणों को escalate करता है।
क्यों: Layered safeguards स्वायत्तता को सुरक्षित रखते हैं; पूर्ण tool एक्सेस और बिना अनुमोदन गेट के एक autonomous लूप अपरिवर्तनीय क्षति का कारण बन सकता है।
एक agent कार्य के बीच-बीच में रुक-रुक कर विफल हो जाता है और आपको विफल होने वाले चरण का पता लगाना होगा।
विफल tool या गलत तर्क का पता लगाने के लिए Foundry में run के traced steps और tool-call inputs/outputs का निरीक्षण करें।
क्यों: Step-level traces यह इंगित करते हैं कि एक run कहाँ टूटा; एक एकल अंतिम त्रुटि संदेश यह छुपाता है कि वास्तव में कौन सा tool call या reasoning step विफल हुआ।
आउटपुट असंगत हैं और formatting निर्देशों को अनदेखा करते हैं।
एक स्पष्ट सिस्टम संदेश, few-shot उदाहरण और स्पष्ट आउटपुट बाधाओं का उपयोग करें; सख्त आकार के लिए, structured outputs / JSON schema सक्षम करें।
क्यों: Structured prompting और schema-enforced outputs परिणामों को विश्वसनीय बनाते हैं; temperature बढ़ाना या आँख बंद करके पुनः प्रयास करना instruction-following को ठीक नहीं करता है।
एक creative कॉपी कार्य बहुत दोहराव वाला लगता है; एक डेटा-extraction कार्य बहुत यादृच्छिक है।
creative कार्य के लिए temperature/top-p बढ़ाएँ और extraction के लिए उन्हें 0 की ओर कम करें ताकि इसे deterministic बनाया जा सके।
क्यों: Sampling params विविधता और determinism के बीच व्यापार करते हैं; जब पैरामीटर सेटिंग वास्तविक कारण हो तो मॉडल बदलना overkill है।
एक reasoning agent कठिन कार्यों पर टालने योग्य तर्क त्रुटियां करता है।
एक reflection / self-critique चरण जोड़ें जहाँ agent अपने ड्राफ्ट की समीक्षा और संशोधन करता है, या इस चरण के लिए एक reasoning मॉडल का उपयोग करें।
क्यों: Chain-of-thought और self-critique कठिन-कार्य सटीकता में सुधार करते हैं; एक एकल फॉरवर्ड पास को अपनी गलती पकड़ने का कोई मौका नहीं मिलता है।
ऑपरेशंस को प्रोडक्शन में प्रति अनुरोध टोकन खर्च, लेटेंसी और सुरक्षा संकेतों की आवश्यकता है।
ऐप से Azure Monitor / Application Insights में OpenTelemetry traces और मेट्रिक्स उत्सर्जित करें, टोकन, लेटेंसी और content-safety फ़्लैग कैप्चर करें।
क्यों: एकीकृत observability लागत, प्रदर्शन और सुरक्षा को एक साथ बांधती है; मैन्युअल रूप से लॉग scraping एक धीमी बारी को उसके टोकन उपयोग से सहसंबंधित नहीं कर सकता।
एक ऐप सस्ती classification को कभी-कभी जटिल तर्क के साथ मिलाता है।
कई डिप्लॉयमेंट को ऑर्केस्ट्रेट करें: सरल बारीकियों को SLM पर रूट करें और एक ऐप लेयर के पीछे एक frontier LLM पर कठिन बारीकियों को escalate करें।
क्यों: मॉडल रूटिंग प्रति बारी लागत और गुणवत्ता को अनुकूलित करता है; हर चीज के लिए एक premium मॉडल का उपयोग करना आसान बहुमत के लिए अधिक भुगतान करता है।
एक मार्केटिंग ऐप को टेक्स्ट प्रॉम्प्ट्स से मूल छवियां जनरेट करनी होंगी।
एक image-generation मॉडल (जैसे Foundry कैटलॉग में DALL-E / GPT-image) को डिप्लॉय करें और इसे टेक्स्ट प्रॉम्प्ट और आकार पैरामीटर के साथ कॉल करें।
क्यों: Generative image मॉडल नए दृश्यों को संश्लेषित करते हैं; Image Analysis (vision) API केवल मौजूदा छवियों का वर्णन करता है, यह उन्हें बना नहीं सकता।
मौजूदा उत्पाद फ़ोटो के केवल बैकग्राउंड को बदलें, उत्पाद को अक्षुण्ण रखते हुए।
स्रोत छवि के साथ image edit (inpainting) endpoint का उपयोग करें और एक मास्क जो केवल संपादन योग्य क्षेत्र को चिह्नित करता है।
क्यों: एक मास्क संपादन को painted क्षेत्र तक सीमित करता है; एक सादा text-to-image कॉल पूरे फ्रेम को पुनर्जीवित करता है और मूल उत्पाद को खो देता है।
एक टेक्स्ट विवरण से छोटे जनरेटेड वीडियो क्लिप बनाएँ।
प्रॉम्प्ट, अवधि और रिज़ॉल्यूशन पैरामीटर के साथ Foundry कैटलॉग में Sora जैसे text-to-video मॉडल का उपयोग करें।
क्यों: वीडियो generation एक अलग मॉडल परिवार है; image मॉडल single frames आउटपुट करते हैं और temporal गति उत्पन्न नहीं कर सकते।
उपयोगकर्ता अपलोड की गई चार्ट छवि के बारे में free-form प्रश्न पूछते हैं।
विजुअल प्रश्न उत्तर और प्राकृतिक भाषा उत्तर के लिए छवि और प्रश्न को एक multimodal LLM (GPT-4o) पर भेजें।
क्यों: Multimodal चैट ओपन विजुअल QA को संभालता है; fixed-taxonomy image tagging लेबल्स लौटाता है, मनमाने प्रश्नों के उत्तर नहीं।
हजारों छवियों के लिए पहुंच के लिए वर्णनात्मक alt टेक्स्ट स्वचालित रूप से जनरेट करें।
बड़े पैमाने पर मानव-पठनीय विवरण उत्पन्न करने के लिए Image Analysis caption / dense-captions क्षमता का उपयोग करें।
क्यों: Captioning सीधे संक्षिप्त alt टेक्स्ट उत्पन्न करता है; object detection bounding boxes लौटाता है जिन्हें अभी भी prose में बदलने की आवश्यकता होती है।
लंबे रिकॉर्ड किए गए वीडियो से structured fields और segment-level insights निकालें।
टाइमलाइन पर structured, schema-defined आउटपुट प्राप्त करने के लिए वीडियो analyzer के साथ Azure AI Content Understanding का उपयोग करें।
क्यों: Content Understanding modalities में grounded structured आउटपुट उत्पन्न करता है; frame-by-frame image calls टाइमलाइन-जागरूक संरचना नहीं देते हैं।
एक multimodal agent उपयोगकर्ता छवियों को पढ़ता है जिनमें छिपे हुए निर्देश टेक्स्ट हो सकते हैं।
प्रॉम्प्ट शील्ड्स / indirect-injection detection सक्षम करें और छवियों के भीतर टेक्स्ट को untrusted डेटा के रूप में मानें, निर्देशों के रूप में नहीं।
क्यों: एम्बेडेड छवि टेक्स्ट एक क्लासिक indirect prompt-injection वेक्टर है; OCR'd टेक्स्ट को सीधे सिस्टम प्रॉम्प्ट में पास करने से हमलावर agent को hijack कर सकते हैं।
ईमेल से नाम, तारीखें और मात्राएँ एक typed JSON रिकॉर्ड में खींचें।
एक लक्ष्य JSON schema के साथ एक LLM को प्रॉम्प्ट करें और structured outputs सक्षम करें ताकि प्रत्येक फ़ील्ड एक निश्चित आकार में लौटाया जाए।
क्यों: Schema-constrained LLM extraction खुले प्रारूपों को संभालता है और parseable JSON की गारंटी देता है; नाजुक regex प्राकृतिक-भाषा विविधता पर टूट जाती है।
लंबे सपोर्ट ट्रांसक्रिप्ट्स का एक संक्षिप्त, फिर से लिखा गया सारांश उत्पन्न करें।
लंबाई और फोकस निर्देश के साथ abstractive summarization के लिए एक LLM का उपयोग करें, या Language सेवा summarization skill का उपयोग करें।
क्यों: Abstractive summaries सार को paraphrase करती हैं; extractive sentence-picking केवल वाक्यों की नकल करता है और समग्र बिंदु को मिस कर सकता है।
भावना के अनुसार ग्राहक संदेशों को वर्गीकृत करें और आक्रामक स्वर को फ़्लैग करें।
polarity को लेबल करने और स्वर का पता लगाने के लिए एक LLM (या Language sentiment API) का उपयोग करें, एक श्रेणी और confidence लौटाते हुए।
क्यों: Sentiment/tone विश्लेषण परिभाषित लेबलों के साथ एक classification कार्य है; लेबल schema के बिना free-text generation को downstream पर रूट करना मुश्किल है।
30 भाषाओं में उच्च मात्रा में UI स्ट्रिंग्स को सटीक और सस्ते में अनुवादित करें।
बल्क, deterministic अनुवाद के लिए Azure AI Translator का उपयोग करें; nuanced, context-heavy passages के लिए एक LLM को आरक्षित करें।
क्यों: Translator विशेष रूप से निर्मित, सस्ता और बड़े पैमाने पर सुसंगत है; प्रति स्ट्रिंग एक LLM की लागत अधिक होती है और रनों के दौरान स्वर में भिन्नता आ सकती है।
एक voice agent को वास्तविक समय में कॉलर ऑडियो को ट्रांसक्राइब करना होगा।
agent पाइपलाइन में टेक्स्ट फीड करने के लिए Speech सेवा real-time speech-to-text (या fast transcription) का उपयोग करें।
क्यों: Streaming STT लाइव बातचीत के लिए कम-लेटेंसी आंशिक ट्रांसक्रिप्ट प्रदान करता है; बैच transcription ऑफ़लाइन फ़ाइलों के लिए है, लाइव टर्न के लिए नहीं।
Transcription उत्पाद नामों और चिकित्सा jargon को गलत सुनता है।
विशेष शब्दावली की पहचान को बढ़ावा देने के लिए domain ऑडियो और phrase lists के साथ एक Custom Speech मॉडल को प्रशिक्षित करें।
क्यों: Custom Speech ध्वनिक/भाषा मॉडल को आपकी शर्तों के अनुकूल बनाता है; आधार मॉडल को आपके निजी jargon का कोई एक्सपोजर नहीं है।
agent को स्वाभाविक लगने वाले बोले गए ऑडियो के साथ उत्तर देना चाहिए।
prosody, pauses और उच्चारण को नियंत्रित करने के लिए एक उपयुक्त आवाज और SSML के साथ neural Text to Speech का उपयोग करें।
क्यों: Neural TTS प्लस SSML सजीव, नियंत्रणीय भाषण उत्पन्न करता है; SSML के बिना सादा टेक्स्ट संख्याओं और नामों पर सपाट वाक्यांश देता है।
Vector-only retrieval सटीक keyword और कोड-identifier मैचों को मिस करता है।
मर्ज किए गए परिणामों को पुनर्व्यवस्थित करने के लिए semantic ranking के साथ Azure AI Search (vector plus keyword) में hybrid search का उपयोग करें।
क्यों: Hybrid प्लस semantic reranking अकेले किसी भी signal से बेहतर है; pure vector search शाब्दिक शब्दों को मिस कर सकता है, pure keyword paraphrase को मिस करता है।
corpus में स्कैन किए गए PDFs शामिल हैं जिनका टेक्स्ट selectable नहीं है।
indexing skillset में एक OCR cognitive skill (Document Intelligence / Vision) जोड़ें ताकि chunking और embedding से पहले स्कैन किया गया टेक्स्ट निकाला जा सके।
क्यों: OCR enrichment retrieval के लिए छवियों से टेक्स्ट को सतह पर लाता है; raw scanned PDF को इंडेक्स करने से कुछ भी searchable नहीं मिलता है।
ingestion के दौरान आपको प्रति दस्तावेज़ OCR, key-phrase extraction और अनुवाद लागू करने की आवश्यकता होती है।
आवश्यक cognitive skills को chaining करने वाले एक AI Search skillset को परिभाषित करें, आउटपुट को इंडेक्स फ़ील्ड में प्रोजेक्ट करते हुए जिन्हें indexer पॉपुलेट करता है।
क्यों: एक skillset इंडेक्स समय पर enrichment को declaratively ऑर्केस्ट्रेट करता है; इसे प्रति क्वेरी ऐप कोड में करने से काम दोहराया जाता है और पुन: उपयोग टूट जाता है।
आप चाहते हैं कि chunking और embedding को इंडेक्स पाइपलाइन के अंदर संभाला जाए, न कि ऐप कोड में।
दस्तावेज़ों को विभाजित करने और indexing और query समय पर एक embedding मॉडल को कॉल करने के लिए AI Search integrated vectorization का उपयोग करें।
क्यों: Integrated vectorization ingest और query के बीच chunking/embedding को सुसंगत रखता है; custom client-side embedding मॉडल बेमेल के जोखिम में है।
विविध लेआउट वाले invoices से structured fields निकालें।
एक Document Intelligence prebuilt invoice मॉडल का उपयोग करें, या एक custom मॉडल को प्रशिक्षित करें, ताकि confidence और bounding regions के साथ typed fields वापस मिल सकें।
क्यों: Document Intelligence लेआउट को समझता है और typed fields लौटाता है; एक OCR-only डंप raw टेक्स्ट देता है जिसमें कोई फ़ील्ड semantics नहीं होती है।
आपको RAG के लिए मिश्रित दस्तावेज़ों का एक स्वच्छ, grounded markdown प्रतिनिधित्व चाहिए।
structured / markdown आउटपुट उत्पन्न करने के लिए Content Understanding analyzers का उपयोग करें जो headings, tables और field grounding को संरक्षित करता है।
क्यों: Grounded markdown retrieval के लिए संरचना और citations को बरकरार रखता है; flattened plain text tables और section context को खो देता है जिसकी मॉडल को आवश्यकता होती है।
एक Foundry agent को रन टाइम पर आपके enriched search index से पुनः प्राप्त करना होगा।
AI Search index को agent पर एक knowledge source / tool के रूप में जोड़ें ताकि प्रत्येक run पुनः प्राप्त, उद्धृत परिणामों में उत्तरों को ग्राउंड करे।
क्यों: इंडेक्स को एक agent tool के रूप में वायर करने से लाइव grounded retrieval मिलता है; निर्देशों में static स्निपेट्स चिपकाना corpus के साथ वर्तमान नहीं रह सकता।