> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/roboflow/roboflow-hi/support/getting-help-faster-what-to-include-in-a-support-request.md). # Support अनुरोध में क्या शामिल करें Roboflow Support team समस्याओं को तेज़ी से हल करता है जब किसी अनुरोध में समस्या को दोहराने के लिए पर्याप्त विवरण शामिल हो। नीचे अपनी स्थिति ढूँढें और संपर्क करते समय सूचीबद्ध जानकारी शामिल करें। ## हमेशा क्या शामिल करें समस्या का प्रकार चाहे जो भी हो, ये पाँच चीज़ें हर support case को तेज़ करती हैं: 1. **Project और workspace**: workspace ID या प्रभावित Project या workspace का direct link। (जब आप email से submit करते हैं तब यह ज़रूरी है; अन्यथा यह आमतौर पर हमारे पास अपने आप होता है.) 2. **Workspace access**: [Roboflow Support team को अपने workspace का access दें](/roboflow/roboflow-hi/support/sharing-a-workspace-with-roboflow-support.md). 3. **सटीक error**: शब्दशः error message या response body, paraphrase नहीं। 4. **समय-सीमा**: विशिष्ट UTC timestamps, "कल" नहीं। 5. **आपने क्या आज़माया**: हर प्रयास और उसका परिणाम। ## Inference API Errors आपका production application से HTTP 4xx या 5xx responses मिलने लगते हैं `serverless.roboflow.com`. Error messages में "Internal error," "Model is temporarily not ready - retry request," "Could not acquire model manager lock," या 30 seconds के बाद timeouts शामिल हो सकते हैं। Failure rates अचानक बढ़ जाती हैं, अक्सर समय की एक संकरी खिड़की के भीतर। ये errors platform-side infrastructure incidents, load के दौरान memory से model eviction, या client-side request patterns से उत्पन्न हो सकते हैं जो capacity को overwhelm कर देते हैं। समय-सीमा और request log के बिना, सटीक issue तक पहुँचना मुश्किल होता है। सबसे ज़्यादा क्या मदद करता है: * failures की सटीक time window, timezone या UTC offset सहित। ("2026-05-22 12:30–12:40 UTC" "इस सुबह" की तुलना में बहुत आसान है.) * पूरा inference endpoint URL (उदाहरण: `https://serverless.roboflow.com/test-endpoint/11` के लिए [Serverless API](/roboflow/roboflow-hi/deploy/serverless-hosted-api-v2.md), या `name.deployment@roboflow.com` एक [dedicated deployment](/roboflow/roboflow-hi/deploy/dedicated-deployments.md)). * error responses का screenshot या log export, जिसमें HTTP status codes, response bodies, और timestamps दिखें। आपके application या monitoring dashboard का screenshot जो event दिखाता हो, आदर्श है। * window के दौरान अनुमानित request volume: कुल कितनी requests भेजी गईं, कितनी failed हुईं, और sending pattern (burst बनाम steady). * क्या failures अभी भी जारी हैं या ठीक हो चुके हैं। * क्या failed requests के लिए credits consumed हुए थे। उदाहरण submission: > "2026-05-22 को 11:20 और 11:35 AM UTC के बीच पर hit करते समय हमें लगभग 90% failure rate दिखाई दी। उस समय हम लगभग 150 requests/hour भेज रहे थे। Errors ने HTTP 503 के साथ body {\\"message\\":\\"Internal error.\\"} लौटाई। संलग्न है हमारे application log का screenshot। लगता है failure लगभग 11:40 AM पर अपने आप ठीक हो गया। हमारा workspace id fleet-pulse है। क्या failed requests के लिए हमसे billing की गई?" ## Inference Performance Problems Inference server सही तरीके से चलता है लेकिन अपेक्षा से अधिक memory खपत करता है, समय के साथ बढ़ता जाता है, load के तहत धीमा हो जाता है, या आपके use case के लिए अस्वीकार्य रूप से उच्च latency पैदा करता है। आम variants में Jetson device पर घंटों में memory का अनियंत्रित रूप से बढ़ना, बड़े model का first request पर load होने में बहुत समय लगना, या parallel batch requests के दौरान throughput का गिरना शामिल है। Memory और latency model architecture, batch size, concurrency settings, image dimensions, hardware, और [inference server](/roboflow/roboflow-hi/deploy/self-hosted-deployment.md) version पर निर्भर करते हैं। लगभग हर variable मायने रखता है। सबसे ज़्यादा क्या मदद करता है: * Inference server version: exact Docker image tag (उदाहरण: `roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6`). * Hardware specs: GPU model, total RAM, और क्या आप Jetson पर हैं और कौन-सा JetPack version है। * लोड किए गए हर model के Model IDs और types (उदाहरण: `object-detection-5gavt/16`, YOLOv8-s, ViT 224×224), साथ ही क्या device के लिए TRT packages मौजूद हैं। * Client configuration: `max_concurrent_requests`, `max_batch_size`, और client side पर batches कैसे बनाए जाते हैं। * समय के साथ memory या CPU usage graph जो degradation pattern दिखाए (उदाहरण: `jtop`, `htop`, या लगभग एक घंटे तक memory दिखाने वाला monitoring tool का screenshot). * सामान्य image size KB में, या यदि ज्ञात हो तो सटीक pixel dimensions। * प्रयोग में लिए गए environment variable overrides (उदाहरण: `USE_INFERENCE_MODELS=True/False`). * पहले से आज़माए गए steps, जिनमें version rollbacks और flag changes शामिल हैं, और हर एक का प्रभाव। उदाहरण submission: > "हम NVIDIA Jetson AGX Orin (JetPack 5.1.1) पर roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6 चला रहे हैं। हम एक साथ 7 models load करते हैं: 2 YOLOv8-s object detection और 5 ViT classification models। लगभग 2 घंटे production load (max\_concurrent\_requests=10, max\_batch\_size=100, image size \~50KB) के बाद memory 8GB से बढ़कर लगभग 15GB हो जाती है। संलग्न है jtop graph। हमने USE\_INFERENCE\_MODELS=False सेट करने की कोशिश की, जिससे memory लगभग आधी हो गई लेकिन accuracy भी घट गई।" ## Serverless Workflow Errors एक Roboflow [Workflow](/roboflow/roboflow-hi/workflows/what-is-workflows.md) (Workflows UI या `serverless.roboflow.com/infer/workflows/...`) errors लौटाता है, time out होता है, या अप्रत्याशित परिणाम देता है। Errors HTTP 500 "Internal error," 502 "Bad gateway," या ऐसे silent failures हो सकते हैं जहाँ jobs चलते हुए दिखाई देते हैं लेकिन कोई data वापस नहीं मिलता। यह साधारण model inference failures से अलग है: इसमें आम तौर पर multi-step pipelines, custom Python blocks, या complex block chains शामिल होते हैं। Workflows pipeline के किसी भी step पर fail हो सकते हैं। कौन-सा block दोषपूर्ण है, कितनी requests भेजी गईं और किस pattern में, और exact workflow definition जानने से root cause संकुचित हो जाता है। सबसे ज़्यादा क्या मदद करता है: * पूरा workflow URL (उदाहरण: `https://serverless.roboflow.com/infer/workflows/test/test-workflow`). * failures कब हुईं, timestamps और हर time window में अनुमानित request counts सहित, का breakdown। * failing requests के लिए HTTP status codes और full response bodies। सिर्फ "500 Internal Error" की तुलना में पूरा response body बहुत अधिक उपयोगी है। * क्या failures total हैं (सभी requests fail होती हैं) या partial (कुछ सफल होती हैं)। * [Roboflow Support team के लिए Workspace access](/roboflow/roboflow-hi/support/sharing-a-workspace-with-roboflow-support.md), ताकि हम workflow definition और server-side logs की जाँच कर सकें। * failures शुरू होने से पहले workflow में किए गए कोई भी recent changes (नए blocks जोड़े गए, models बदले गए, image inputs बदले गए)। * batch jobs के लिए: [batch job](/roboflow/roboflow-hi/deploy/batch-processing.md) ID "Activity" section से, expected बनाम actual output record count, और job duration। उदाहरण submission: > " पर हमारा workflow 2026-05-25 को 12:33 और 12:40 UTC के बीच 195 requests में से 170 HTTP 500 responses लौटा रहा था। Requests लगभग 15-15 के bursts में आ रही थीं। सभी failures के लिए response body {\\"message\\":\\"Internal error.\\"} था। Workflow लगभग 10 मिनट बाद अपने आप ठीक हो गया। हमने हाल ही में workflow नहीं बदला है। मैंने को workspace access दे दिया है।" ## Model Training Issues एक [training](/roboflow/roboflow-hi/train/train.md) job बिल्कुल fail हो जाता है, अटक जाता है, बिना विवरण वाला generic error popup दिखाता है, trained model बनाए बिना credits consume करता है, या training के बाद model अप्रत्याशित व्यवहार करता है (उदाहरण: max detections अपेक्षा से कम हैं, या बड़े dataset पर training version generation के दौरान hang हो जाती है). Training failures dataset की विशेषताओं (corrupt images, label format problems, class imbalances), resource constraints, या platform bugs से आ सकते हैं। Support team को आपके विशिष्ट project और dataset को देखना होगा। सबसे ज़्यादा क्या मदद करता है: * जिस model type और size को आपने train करने की कोशिश की (उदाहरण: RF-DETR Nano, YOLOv8-L, SAM3). * model का नाम या प्रभावित model का direct link (उदाहरण: `app.roboflow.com/my-workspace/my-project/models/my-model`). * training के लिए उपयोग किया गया dataset version number। * error message शब्दशः, paraphrase करने के बजाय पूरा copy और paste किया हुआ। यदि यह popup में दिखाई देता है, तो उसका screenshot लें। * यदि UI में दिखाई दे रहा हो तो training job ID। * क्या failed attempt के लिए credits charged किए गए थे। * dataset version में images और classes की संख्या। * failure से पहले dataset में किए गए कोई भी recent changes (नई images जोड़ी गईं, class names बदले गए, preprocessing settings बदली गईं). * foundation model fine-tuning के लिए (उदाहरण: SAM): dataset size, उपयोग किया गया prompt type, और प्रक्रिया के किस हिस्से में यह crash हुआ। उदाहरण submission: > "workspace baz-co में project foo-bar के dataset version 3 पर model YOLOv8-L के लिए training job हर बार generic popup error के साथ fail हो जाता है, और आगे कोई विवरण नहीं दिखता। dataset में 12 classes में लगभग 2,400 images हैं। मुझसे दो failed attempts के लिए credits चार्ज किए गए हैं। यहाँ error popup का screenshot है। Workspace access support को दे दिया गया है।" ## Dataset & Image Visibility Issues जो images upload की गई थीं वे dataset view में दिखाई नहीं देतीं (header count ब्राउज़ करते समय वास्तव में दिखाई देने वाली संख्या से अलग होता है), labeling के बाद dataset में जोड़ी गई images गायब हो जाती हैं, dataset version preparation अनिश्चित काल तक अटक जाती है, या batch ZIP upload सफल दिखता है लेकिन images accessible नहीं होतीं। इन issues में अक्सर backend log inspection की आवश्यकता होती है। Support team को एक सटीक project identifier और आदर्श रूप से specific upload event का record चाहिए। सबसे ज़्यादा क्या मदद करता है: * संख्याओं में अंतर: platform कितनी images दिखाता है बनाम dataset tab ब्राउज़ करने पर वास्तव में कितनी दिखाई देती हैं (उदाहरण: "Header कहता है 1,004 images लेकिन ब्राउज़ करने पर केवल 368 दिखती हैं"). * upload कब हुआ, जिससे platform events के साथ correlation करने में मदद मिलती है। * प्रयोग किया गया upload method: browser में drag-and-drop, Python SDK, REST API, ZIP upload, या mobile app। * batch या ZIP uploads के लिए: यदि उपलब्ध हो तो "Activity" section से batch job ID। * discrepancy दिखाने वाला screenshot (header count बनाम browse view). उदाहरण submission: > "workspace abc\_def में मेरा project foo\_bar\_2 project header में 1,004 images दिखाता है लेकिन जब मैं dataset tab खोलता हूँ तो केवल 368 दिखाई देती हैं। मैंने images को 2026-05-25 को लगभग 9 AM EST पर drag-and-drop के जरिए upload किया था। Workspace access दे दिया गया है। Screenshot संलग्न है।" ## Roboflow App UI Errors annotation editor के बाहर Roboflow web app में कुछ सही से काम नहीं कर रहा: pages load नहीं होतीं या spinner पर अटकी रहती हैं, dataset version delete करने जैसी actions पूरी होती हुई दिखती हैं लेकिन कोई प्रभाव नहीं होता, settings panels नहीं खुलते, uploads activity queue में अटक जाते हैं, usage dashboard render नहीं होता, या buttons कोई response नहीं देते। UI bugs अक्सर पीछे चल रहे किसी failed या धीमे network request, या JavaScript error, से होते हैं, जिसे visible interface सीधे नहीं दिखाती। Browser के developer tools network और JavaScript स्तर पर क्या गलत हो रहा है, यह उजागर करते हैं। सबसे ज़्यादा क्या मदद करता है: * bug को दिखाने वाली screen recording (Loom, video, या GIF). इन मामलों के लिए यह सबसे मूल्यवान artifact है। * browser network request log का screenshot, जो दिखाता है कि कोई requests fail हो रही हैं या लंबे समय से चल रही हैं। देखें [इसे खोलने के लिए Chrome's network panel documentation](https://developer.chrome.com/docs/devtools/network) ; अन्य browsers में भी समान tools होते हैं। * browser console log में कोई errors। देखें [इसे access करने के लिए Chrome's console documentation](https://developer.chrome.com/docs/devtools/console/log) ; अन्य browsers में भी समान tools होते हैं। * आपका browser name और version (उदाहरण: macOS 14.4 पर Chrome 124). * step-by-step reproduction steps: आपने क्या क्लिक किया, किस क्रम में, एक fresh page load से शुरू करते हुए। * क्या bug हाल ही में दिखाई दिया, और क्या यह आपके द्वारा नोट किए गए किसी platform update के साथ मेल खाता है। * exact expected behavior बनाम actual behavior। * क्या issue लगातार है या बीच-बीच में होता है। उदाहरण submission: > "project `test-project` के dataset tab में `test-workspace`), version 3 पर 'Delete version' क्लिक करने पर success toast दिखता है लेकिन version सूची में बना रहता है। network log screenshot में एक `DELETE` request लौटती हुई दिखाई देती है `500 Internal Server Error`. Console दिखाता है `Uncaught TypeError: Cannot read properties of undefined`. Browser: Ubuntu 22.04 पर Firefox 126. Normal और private दोनों windows में reproduced. Screen recording संलग्न है." ## Annotation Tool Bugs Roboflow annotation editor में कोई tool गलत तरीके से व्यवहार करता है: keyboard shortcuts काम करना बंद कर देते हैं, एक tool चुनने पर दूसरा वापस आ जाता है, undo (Ctrl+Z) अपेक्षा से अधिक चीज़ें delete कर देता है, Label Assist अनिश्चित काल तक loading करता रहता है, या annotations जब उन्हें save होना चाहिए तब save नहीं होते। Annotation bugs अक्सर browser-specific, OS-specific, या हाल के platform deployments के कारण होते हैं। Screen recording लगभग हमेशा लिखित विवरण से अधिक जानकारीपूर्ण होती है। सबसे ज़्यादा क्या मदद करता है: * bug को दिखाने वाली screen recording (Loom, video, या GIF). Annotation behavior को शब्दों में समझाना कठिन और दिखाना आसान होता है, इसलिए इन मामलों के लिए यह सबसे मूल्यवान artifact है। * browser network request log का screenshot, जो दिखाता है कि कोई requests fail हो रही हैं या लंबे समय से चल रही हैं। देखें [इसे खोलने के लिए Chrome's network panel documentation](https://developer.chrome.com/docs/devtools/network) ; अन्य browsers में भी समान tools होते हैं। * browser console log में कोई errors। देखें [इसे access करने के लिए Chrome's console documentation](https://developer.chrome.com/docs/devtools/console/log) ; अन्य browsers में भी समान tools होते हैं। * आपका browser name और version (उदाहरण: macOS 14.4 पर Chrome 124). * project type (Object Detection, Instance Segmentation, Classification, आदि) और उपयोग में लिया गया specific annotation tool (polygon, polyline, bounding box, smart polygon). * keyboard shortcut या action जो bug को trigger करता है, step-by-step reproduction steps के साथ। * क्या issue सभी images को प्रभावित करता है या specific images को। यदि specific हों, तो project link और image name या ID साझा करें। * क्या bug हाल ही में दिखाई दिया, और क्या यह आपके द्वारा नोट किए गए किसी platform update के साथ मेल खाता है। * exact behavior expected बनाम वास्तव में क्या होता है। * क्या issue लगातार है या बीच-बीच में होता है। उदाहरण submission: > "project my-test-project और my-other-test-project (workspace test-workspace) में polyline tool में हाल ही में शामिल की गई तीन bugs हैं: (1) polyline tool active होने पर Ctrl+scroll से zoom करने पर bounding box tool पर switch हो जाता है; (2) Ctrl+Z अब केवल last point के बजाय पूरी annotation delete कर देता है; (3) Esc दबाने पर अब annotation discard करने के बजाय save हो जाती है। यहाँ दो Loom recordings हैं जो हर behavior दिखाती हैं: \[link 1], \[link 2]. Browser: Windows 11 पर Chrome 124." ## API Authentication Errors model inference endpoints, Roboflow Python SDK, या HTTP API को की गई API calls 403 Forbidden लौटाती हैं और संदेश कुछ ऐसा होता है: "Missing or insufficient permissions." यह plan upgrade के तुरंत बाद, private model access करने की कोशिश में, या API key rotate होने के बाद हो सकता है। 403 errors गलत या expired API key, workspace-level key के बजाय project-level key (या इसके उलट) का उपयोग, ऐसी plan से model access करना जिसमें वह feature शामिल नहीं है, या plan upgrade के बाद permissions propagating में देरी के कारण हो सकते हैं। सबसे ज़्यादा क्या मदद करता है: * पूरा error response: केवल status code नहीं, बल्कि complete HTTP status code और response body। SDK errors के लिए, पूरा Python traceback। * जिस endpoint या SDK method को call किया जा रहा है (उदाहरण: `detect.roboflow.com/model-name/version`, `InferenceHTTPClient`, `CLIENT.infer()`). * model ID और version number। * प्रयोग में ली जा रही API key का type, workspace या project। Key स्वयं साझा न करें, केवल type बताएं। * क्या key हाल ही में rotate की गई थी या plan हाल ही में बदला गया था। * एक redacted code snippet जिसमें दिखाया गया हो कि आप API call कैसे बनाते हैं, और actual key को एक placeholder जैसे `YOUR_API_KEY`. * क्या यह पहले काम करता था, और क्या बदला। उदाहरण submission: > "जब मैं को call करता हूँ तो मुझे HTTPError: 403 Client Error: Forbidden मिल रहा है। मैं workspace-level API key का उपयोग कर रहा हूँ। यह कल Free Plan से Core में upgrade करने के बाद शुरू हुआ। Model private है। यहाँ पूरा Python traceback है: \[paste]. Workspace my-test-workspace है। Workspace access दे दिया गया है." ## Account Access Problems आप Roboflow में log in नहीं कर पा रहे: login page लगातार loading कर रहा है, Google [SSO](/roboflow/roboflow-hi/workspaces/single-sign-on-sso.md) login blocked है, forgotten-password reset काम नहीं कर रहा, या account locked है क्योंकि connected Google account उपलब्ध नहीं है। Access issues अक्सर उपयोग किए जा रहे specific email या identity provider से जुड़े होते हैं। ये Google की तरफ OAuth scope changes या browser/extension interference के कारण भी हो सकते हैं। सबसे ज़्यादा क्या मदद करता है: * जिस account तक आप पहुँचने की कोशिश कर रहे हैं उससे जुड़ा email address। * login method: email और password, Google SSO, या GitHub SSO। * exact error message या behavior: "page keeps loading," "invalid credentials," "account not found," या कोई specific error code। * error state का screenshot। * browser name और version, और क्या आपने incognito/private window या अलग browser आज़माया है। * क्या यह नई issue है या हमेशा से ऐसा ही रहा है (उदाहरण: newly created account बनाम existing account जो काम करना बंद कर गया). ## Workspace & Project Management Issues आप नहीं कर पा रहे [एक workspace delete](/roboflow/roboflow-hi/workspaces/delete-a-workspace.md) या project (deletion button कुछ करता हुआ दिखाई नहीं देता या error लौटाता है), workspace गलती से गलत plan में upgrade हो गया है, ownership transfer नहीं हो रही, billing failure के बाद projects inaccessible हो जाते हैं, image upload limit hit हो जाती है, या एक [public project](/roboflow/roboflow-hi/datasets/make-a-project-public.md) गलती से private data expose कर देता है। सबसे ज़्यादा क्या मदद करता है: * वह specific action जो fail हो रही है और देखा गया error message या behavior। * error state या अवांछित project state का screenshot। * deletion issues के लिए: पुष्टि करें कि आपने workspace के भीतर सभी projects और images पहले ही delete कर दिए हैं, जो अक्सर आवश्यक शर्त होती है। * accidental upgrades के लिए: उस workspace की IDs जो upgrade हुआ था और जिसकी वास्तव में इच्छा थी, दोनों, तथा change का अनुमानित समय। * image limit issues के लिए: workspace में वर्तमान में कितनी images हैं और दिखाया गया limit क्या है। ## Credits & Usage Issues Credits अपेक्षा से तेज़ी से खत्म हो रहे हैं, failed training jobs या failed inference के लिए credits charge हो रहे हैं, या [usage dashboard](/roboflow/roboflow-hi/billing/credits/view-credit-usage.md) load नहीं हो रहा। सबसे ज़्यादा क्या मदद करता है: * वह workspace name जहाँ credit issue हुई। * अप्रत्याशित credit consumption की अनुमानित date और time। * किस operation ने credits consume किए: inference calls, training, या batch processing। * क्या कोई ज्ञात [platform incident](/roboflow/roboflow-hi/support/roboflow-status-and-uptime.md) consumption spike के साथ मेल खाता है, और क्या आपने उस समय errors देखे। * consumption spike दिखाने वाला usage dashboard का screenshot। ## Data Privacy & Account Deletion के अनुरोध [account delete करने](/roboflow/roboflow-hi/support/account-deletion.md) और उससे जुड़े सभी personal data (GDPR erasure requests), अधूरी data deletion जहाँ account deletion के बाद भी images सार्वजनिक रूप से accessible रहती हैं, या public Universe से किसी specific project को हटाने के अनुरोध। सबसे ज़्यादा क्या मदद करता है: * delete किए जाने वाले account का email address। * पुष्टि कि account deletion आगे बढ़ने से पहले account के भीतर सभी projects और workspaces delete कर दिए गए हैं, जो आवश्यक है। * GDPR requests के लिए: अनुरोध के legal basis का एक statement और उन data का विवरण जो आपको लगता है कि अभी भी accessible हैं। * किसी specific public Universe resource का link जिसे हटाया जाना चाहिए, और क्यों, इसका explanation। ## Security Issues एक API key गलती से expose हो गई थी (उदाहरण: public GitHub repo में commit कर दी गई या chat में साझा कर दी गई), या किसी security researcher ने Roboflow platform में कोई vulnerability पाई। {% hint style="warning" %} यदि कोई key expose हो जाती है, तो तुरंत उसे अपने Roboflow workspace settings में rotate करें। Rotating से compromised key invalid हो जाती है। फिर exposure के अनुमानित समय के साथ support को सूचित करें ताकि हम किसी unauthorized use का audit कर सकें। {% endhint %} exposed keys के लिए, शामिल करें: * पुष्टि कि key पहले ही rotate की जा चुकी है। * वह अनुमानित date और time जब key expose हुई थी, और किस channel के माध्यम से। * क्या exposure window के दौरान unauthorized API usage का कोई evidence है। vulnerability reports के लिए, clear description of the vulnerability, reproduction steps, और potential impact के साथ पर email करें। --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.roboflow.com/roboflow/roboflow-hi/support/getting-help-faster-what-to-include-in-a-support-request.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.