Prompt API

 (developer.chrome.com)
5 पॉइंट द्वारा GN⁺ 1 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chrome में बिल्ट-इन Gemini Nano को natural language अनुरोध भेजने वाला एक web API है, जिसे Q&A, classification, content filtering, schedule extraction और contact extraction जैसे कामों में इस्तेमाल किया जा सकता है
  • इस्तेमाल से पहले अलग से model download करना ज़रूरी है, और यह तभी काम करता है जब support किए गए OS, storage space, GPU या CPU memory जैसी runtime conditions पूरी हों
  • session को LanguageModel.availability() से उपलब्धता जांचने के बाद create() से तैयार किया जाता है, और initialPrompts·append()·clone() के जरिए context को आगे बढ़ाया या branch किया जा सकता है
  • input के रूप में text, image, audio लिए जा सकते हैं और output में अभी केवल text समर्थित है; prompt() पूरा response लौटाता है, जबकि promptStreaming() streaming response लौटाता है
  • responseConstraint आधारित structured output, context window management, permission policy और multimodal processing तक शामिल करते हुए यह browser के अंदर on-device AI चलाने का execution model देता है

अवलोकन

  • यह Chrome में बिल्ट-इन Gemini Nano को natural language अनुरोध भेजने वाली API के रूप में काम करता है, और web page आधारित Q&A, article classification, content filtering, schedule extraction और contact extraction जैसे उपयोग संभव बनाता है
  • model के लिए, भले ही API Chrome में बिल्ट-इन हो, अलग download ज़रूरी है, और पहली बार इस्तेमाल से पहले Google की Generative AI Prohibited Uses Policy देखनी चाहिए
  • generative AI इस्तेमाल करने से पहले People + AI Guidebook देखना recommended है
  • TypeScript typing @types/dom-chromium-ai package से मिल सकती है
  • Chrome Extensions developers को expired origin trial permission aiLanguageModelOriginTrial हटानी होगी

हार्डवेयर और runtime conditions

  • Prompt API·Summarizer API·Writer API·Rewriter API·Proofreader API Chrome में तभी काम करते हैं जब कुछ specific conditions पूरी हों
  • supported operating systems हैं Windows 10/11, macOS 13+, Linux और ChromeOS; ChromeOS का support Chromebook Plus devices पर Platform 16389.0.0 या उससे ऊपर होने पर मिलता है
  • Chrome for Android, iOS और non-Chromebook Plus devices का ChromeOS अभी Gemini Nano आधारित APIs को support नहीं करता
  • storage के लिए Chrome profile वाले volume पर कम से कम 22GB खाली space होना चाहिए
  • model GPU या CPU पर चल सकता है
    • GPU के लिए 4GB से अधिक VRAM चाहिए
    • CPU के लिए 16GB या अधिक RAM और कम से कम 4 CPU cores चाहिए
    • audio input इस्तेमाल करने वाली Prompt API के लिए GPU ज़रूरी है
  • network की ज़रूरत सिर्फ शुरुआती model download के समय unmetered या non-cellular connection के रूप में होती है
    • उसके बाद model इस्तेमाल करने के लिए network connection की ज़रूरत नहीं होती
    • model इस्तेमाल करते समय data Google या किसी third party को नहीं भेजा जाता
  • model का size browser updates के साथ बदल सकता है, और current size chrome://on-device-internals में देखा जा सकता है
  • download के बाद अगर खाली storage 10GB से कम रह जाए, तो model device से हटा दिया जाता है, और conditions फिर पूरी होने पर दोबारा download किया जाता है

शुरुआत और model तैयारी

  • availability को LanguageModel.availability() से जांचा जा सकता है
  • availability() को वही same options देने चाहिए जो बाद में prompt() या promptStreaming() में दिए जाएंगे
    • कुछ models specific modality या language को support नहीं कर सकते, इसलिए options का match होना महत्वपूर्ण है
  • model download और session creation, user activation की पुष्टि के बाद create() से शुरू होते हैं
  • अगर download चल रहा हो, तो progress events लेकर user को download status बताना चाहिए
  • localhost पर Chrome flags enable करने से built-in AI APIs इस्तेमाल की जा सकती हैं
    • chrome://flags/#optimization-guide-on-device-model
    • chrome://flags/#prompt-api-for-gemini-nano-multimodal-input
    • इसके बाद Relaunch या Chrome restart ज़रूरी है
    • error आने पर localhost troubleshooting देखी जा सकती है

session creation और basic settings

  • session LanguageModel.create() से बनाया जाता है
  • Chrome Extensions के लिए Prompt API में session के हिसाब से topK और temperature को option के रूप में adjust किया जा सकता है
    • default और maximum values LanguageModel.params() से देखी जा सकती हैं
    • यह feature सिर्फ Chrome Extensions या sampling parameters origin trial इस्तेमाल करने पर लागू होता है
  • params() defaultTopK, maxTopK, defaultTemperature, maxTemperature लौटाता है
  • नया session initialize करते समय topK और temperature को दोनों साथ specify करना होगा या दोनों छोड़ने होंगे
  • create() में signal field के जरिए AbortSignal देकर session को abort किया जा सकता है

context और prompt construction

  • initialPrompts के जरिए पिछली बातचीत का context देकर browser restart के बाद saved session को जारी रखा जा सकता है
  • prompt array में system, user, assistant roles साथ में डाले जा सकते हैं
  • आखिरी assistant message में prefix: true देने पर response का कुछ हिस्सा पहले से भरकर किसी specific output format की ओर guide किया जा सकता है
    • उदाहरण के लिए, TOML code block की शुरुआत की string पहले से डालकर output format को स्थिर किया जा सकता है
  • session बनाने के बाद append() से अतिरिक्त context पहले से जोड़ा जा सकता है
    • initialPrompts से अलग, session creation के बाद भी context accumulate किया जा सकता है
    • append() prompt के validate, process और add होने के बाद fulfill होता है
    • अगर prompt जोड़ा नहीं जा सकता, तो promise reject हो जाता है

input/output modalities और multilingual support

  • session creation के समय expectedInputs और expectedOutputs से expected input/output formats और languages सेट किए जा सकते हैं
  • expectedInputs का type text, image, audio को support करता है
  • expectedOutputs का type अभी सिर्फ text की अनुमति देता है
  • language को languages array से set किया जाता है, और Prompt API "en", "ja", "es" स्वीकार करता है
    • अतिरिक्त language support development में है
    • input side पर system prompt language और एक या अधिक user prompt languages डाली जा सकती हैं
    • output side पर एक या अधिक output languages डाली जा सकती हैं
  • unsupported input या output मिलने पर "NotSupportedError" DOMException हो सकता है

multimodal input

structured output और constraints

  • prompt() या promptStreaming() के responseConstraint में JSON Schema डालकर structured output इस्तेमाल किया जा सकता है
  • संबंधित feature structured output में देखा जा सकता है
  • उदाहरण में boolean schema देकर post pottery से जुड़ी है या नहीं, इसका जवाब सिर्फ true या false में दिलाया जाता है
  • implementation में JSON Schema या regular expression को message के हिस्से के रूप में भी डाला जा सकता है, लेकिन इस स्थिति में वह context window का हिस्सा उपयोग करेगा
  • session.measureContextUsage() में responseConstraint option देकर यह मापा जा सकता है कि constraint context का कितना उपयोग कर रहा है
  • omitResponseConstraintInput option का इस्तेमाल करने पर इस behavior से बचा जा सकता है
    • इस स्थिति में prompt के भीतर desired output format के बारे में guidance साथ देना recommended है

prompt execution mode

  • अगर short response expected हो, तो prompt() का उपयोग कर पूरा result एक बार में लिया जा सकता है
  • अगर long response expected हो, तो promptStreaming() का उपयोग कर partial results को streaming में लिया जा सकता है
  • promptStreaming() एक ReadableStream लौटाता है
  • prompt() और promptStreaming() दोनों दूसरे argument में signal लेकर running prompt को abort कर सकते हैं

session management

  • हर session बातचीत का context बनाए रखता है, इसलिए पिछले interactions बाद के responses में reflect होते हैं
  • हर session के पास process किए जा सकने वाले tokens की maximum संख्या होती है, और session.contextUsage तथा session.contextWindow से current usage और limit देखी जा सकती है
  • अगर नया prompt context window से आगे निकल जाए, तो system prompt को छोड़कर बातचीत का शुरुआती हिस्सा question-answer pair units में हटाया जाता है ताकि जगह बन सके
  • ऐसी स्थिति को session के contextoverflow event से detect किया जा सकता है
  • अगर conversation history हटाने पर भी पर्याप्त tokens नहीं मिलते, तो prompt() या promptStreaming() QuotaExceededError के साथ fail हो जाते हैं, और कुछ भी हटाया नहीं जाता
    • requested: input द्वारा लिए गए tokens की संख्या
    • contextWindow: उपलब्ध tokens की संख्या
  • अधिक जानकारी के लिए session management देखी जा सकती है

session cloning और termination

  • clone() से existing session की copy बनाकर conversation branching की जा सकती है
  • cloned session existing context और initial prompts को बनाए रखता है
  • clone() भी signal field के जरिए AbortSignal ले सकता है
  • session की ज़रूरत न रहे, तो destroy() से resources release किए जा सकते हैं
  • session destroy होने पर उसे दोबारा इस्तेमाल नहीं किया जा सकता, और चल रही execution भी रुक जाती है
  • session creation में समय लग सकता है, इसलिए अगर बार-बार prompts भेजने हों तो session बनाए रखना बेहतर हो सकता है

permission policy और runtime environment constraints

  • default रूप से Prompt API केवल top-level window और उसी origin वाले iframe में इस्तेमाल की जा सकती है
  • cross-origin iframe को Permission Policy के allow="language-model" attribute से access delegate किया जा सकता है
  • अभी Prompt API को Web Workers में इस्तेमाल नहीं किया जा सकता
    • क्योंकि हर worker के लिए permissions policy state जांचने वाला responsible document तय करना जटिल है

demos और reference materials

performance और feedback

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 일 전
Hacker News की राय

  • यह API मेरे लंबे समय से सोचे जा रहे de-snarkifier आइडिया के लिए बिल्कुल सही लगती है
    सोशल मीडिया बौद्धिक रूप से उत्तेजक हो सकता है और उससे बहुत कुछ सीखा भी जा सकता है, लेकिन चाहें या न चाहें, विचारधारात्मक बहसों और फ्लेमवार में खिंच जाना बहुत आसान है। इंटरनेट पर अजनबियों से भावनात्मक ऊर्जा खर्च करके लड़ना लगभग मानवीय पूंजी की बर्बादी जैसा है
    अगर ऐसी API हो, तो ब्राउज़र एक्सटेंशन के ज़रिए किसी पोस्ट को दिखाने से पहले सिर्फ आक्रामक या तंजभरे वाक्यांशों को नरम किया जा सकता है, जबकि तथ्यात्मक जानकारी जस की तस रखी जा सकती है। इससे भी आगे बढ़कर, जितना अधिक आक्रामक टोन हो, उसे उतना ही हास्यास्पद या अयोग्य सुनाई देने वाला बनाया जा सकता है
    तब पढ़ने वाले लोग अजनबियों के व्यक्तिगत हमलों से बचे रहेंगे, और लिखने वालों की भी बदतमीज़ी से पेश आने की प्रेरणा कम हो जाएगी। अगर सब ऐसे फ़िल्टर इस्तेमाल करें, तो कौन ज़्यादा घटिया व्यवहार करता है इसकी होड़ भी खत्म हो जाएगी

    • यह लिखित संचार का Soylent जैसा है
      पोषण तो पूरा है, लेकिन स्वाद में कुछ खास नहीं
    • ऐसे टूल का मुझे सच में इंतज़ार है। यह इंटरनेट की empty calories हटाकर आज के लोकप्रिय प्लेटफ़ॉर्म्स का इस्तेमाल काफ़ी कम कर सकता है
      मुझे तो बस इतना चाहिए कि सारे clickbait titles और विज्ञापन हट जाएँ, और सिर्फ सूखे, तथ्यात्मक शीर्षक दिखें
      किसी भी विषय पर एक मुख्य लेख और कुछ सार्थक टिप्पणियाँ काफी हैं, बाकी ज़्यादातर ऐसा शोर है जिसे मैं देखना ही नहीं चाहता
      सोशल मीडिया की हालत अभी इतनी खराब है कि मैं लगभग इसका इस्तेमाल नहीं करता, सिर्फ HN अपवाद था, लेकिन अब यहाँ भी AI की भरमार के साथ वही दिशा दिख रही है। फिर भी हर दो हफ़्ते में कुछ घंटे बर्बाद कर ही देता हूँ, और वह भी पूरी तरह छोड़ देना चाहता हूँ
      आदर्श रूप से मैं चाहता हूँ कि 98% कंटेंट फ़िल्टर या समरी होकर गायब हो जाए, और समय के साथ इंटरनेट सिर्फ तब इस्तेमाल हो जब मैं जानबूझकर कुछ खोज रहा हूँ। मूल रूप से मैं इंटरनेट के मनोरंजन पहलू का अधिकांश हिस्सा हटाना चाहता हूँ ताकि समय और ऊर्जा को वास्तविक दुनिया और किताबों जैसे उच्च-गुणवत्ता स्रोतों की ओर मोड़ा जा सके
    • YouTube पर ऐसा कुछ पहले से है, और मैं DeArrow इस्तेमाल करता हूँ
      यह एक्सटेंशन क्राउडसोर्सिंग के ज़रिए सनसनीखेज़ी कम करने की कोशिश करता है, हालांकि मुझे लगता है कि इसके कुछ टॉप योगदानकर्ता LLM bots भी हो सकते हैं
    • दिलचस्प आइडिया है, खोजबीन करने लायक लगता है
      बस ऐसी चीज़ें जब वास्तविक दुनिया से टकराती हैं तो परिणाम अनिश्चित होते हैं, और अगर यह काम भी करे तो शायद वैसा नहीं करेगी जैसा शुरुआत में सोचा गया था
    • मैं Chrome की built-in AI APIs का PM हूँ, और यह de-snarkifier आइडिया मुझे वाकई बहुत पसंद आया, साथ ही इसमें व्यापक रुचि भी दिख रही है
      मैं खुद को रोक नहीं पाया और जल्दी में Snarknada का एक प्रोटोटाइप बना डाला, ताकि low-latency patterns और accuracy की संभावनाओं को साथ में देख सकूँ
      ऐसे use case में on-device सही क्यों है, इसकी वजह यही है। अगर पूरे infinite scroll feed को cloud API से नरम बनाना हो, तो token cost डेवलपर के लिए असहनीय हो जाएगी। ऊपर से यह भी स्वाभाविक है कि लोग अपने निजी feed या DM को tone साफ़ करने के लिए किसी third-party server पर भेजना नहीं चाहेंगे
      इसे डिवाइस के अंदर ले आने से high-frequency Semantic Mutation पहली बार लागत और तकनीकी दृष्टि से व्यावहारिक हो सकती है। अगर कोई इसे मेरे खिलौना-जैसे PM prototype से ज़्यादा गंभीरता से बनाता है और कहीं ठोस friction point सामने आता है, तो मैं ज़रूर सुनना चाहूँगा। इससे roadmap prioritization में मदद मिलेगी
      [1]: अगर आप coding agents (Cursor, Claude Code आदि) इस्तेमाल करते हैं, तो https://www.npmjs.com/package/built-in-ai-skills-md-agent-md की ओर इशारा करने की सलाह दूँगा। बहुत से models अब पुराने हो चुके window.ai namespace पर train हुए हैं, इसलिए यह skill file उन्हें मौजूदा API सही ढंग से इस्तेमाल करने में मदद करती है

  • मैंने इस API design के काम का नेतृत्व किया था, और retirement से पहले इससे जुड़ी design considerations पर एक लेख भी लिखा था
    https://domenic.me/builtin-ai-api-design/

    • अल्पकाल और दीर्घकाल में आप इस API के target use cases को कैसे देखते हैं, यह जानने की जिज्ञासा है
      और यह भी कि ऐसी चीज़ बनाते समय browsers आपस में W3C स्तर पर नहीं, बल्कि व्यावहारिक तौर पर कुछ साझा बिंदुओं पर तालमेल बैठाने की कोशिश करते हैं या नहीं। आखिर यह उद्योग काफ़ी छोटा है
    • retirement की बधाई

  • यह सच में काम करता है, और मैं इसे local inference के लिए पहले ही ship कर चुका हूँ
    search जैसी low-end LLM tasks में यह गरीब आदमी के ollama जैसा काम कर सकता था। सबसे बड़ा फायदा यह है कि यह मुफ़्त है, privacy बनाए रखता है, और user को लगभग कुछ भी नहीं करना पड़ता, इसलिए non-technical users तक local inference पहुँचाने के लिए अच्छा है
    लेकिन वास्तविक user experience अच्छा नहीं है। model download का आकार browser से ही कई गुना बड़ा है, और first token मिलने से पहले यह पूरा process खत्म होना पड़ता है
    जब तक operating system स्थिर रूप से pre-baked models उपलब्ध नहीं कराता और ऐसी APIs उनसे जुड़ नहीं पातीं, तब तक इसका समाधान मुश्किल लगता है

    • यह Prompt API इस्तेमाल करने वाली सभी sites के बीच साझा होने वाला one-time download है
      बड़ी समस्या यह है कि ज़्यादातर सामान्य PCs पर model बहुत छोटा और धीमा है। मैंने infocom text adventure के वाक्यों को real time में बदलने की कोशिश की थी, लेकिन अभी कई PCs पर यह इतना धीमा है कि व्यावहारिक नहीं है
    • अगला बड़ा रुझान शायद ऐसा software subscription premium हो सकता है जिसमें कई 5090 लगाकर बेचे जाएँ
    • अगर यह MoE model हो, तो expert layers को ज़रूरत पड़ने पर network से HTTP range query के ज़रिए लाया जा सकता है
      यह कुछ वैसा ही है जैसे bittorrent अलग-अलग hosts से file pieces लाता है। shared layers तो फिर भी डाउनलोड करनी होंगी, लेकिन time-to-first-token को कुल size के बजाय active size के अनुपात में रखा जा सकता है
      बेशक तब यह पूरी तरह offline inference नहीं रहेगा, लेकिन browser web feature के लिए शायद यह निर्णायक चिंता न हो
    • उम्मीद है कि दुनिया ऐसी न बने जहाँ operating system भरोसेमंद तरीके से preinstalled models डालने लगे
    • यह वाकई अच्छा है
      लेकिन अगर model browser से बहुत बड़ा है और first token से पहले डाउनलोड ज़रूरी है, तो क्या इसका मतलब lazy download है? अगर पहली बार call करने वाले users को उसी समय download पूरा होने तक इंतज़ार करना पड़े, तो user experience काफ़ी भयानक लगेगा
      यह भी जानना चाहूँगा कि क्या Chrome confusion कम करने के लिए download status dialog जैसा कुछ दिखाता है, और disk usage लगभग कितना होता है

  • ऊपर-ऊपर से तो लगता है कि यह Gemini Nano इस्तेमाल कर रहा है, लेकिन नवीनतम Gemma 4 E2B/E4B कहीं बेहतर दिखते हैं, इसलिए फिलहाल quantized version को extension के रूप में वितरित करना ज़्यादा अच्छा हो सकता है

    • Gemini Nano-1: 46% MMLU, 1.8B
    • Gemini Nano-2: 56% MMLU, 3.25B
    • Gemma4 E2B: 60.0% MMLU, 2.3B
    • Gemma4 E4B: 69.4% MMLU, 4.5B
      स्रोत:
    • https://huggingface.co/google/gemma-4-E2B-it
    • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
    • अभी अंदरूनी स्थिति तो नहीं जानता, लेकिन जब मैं इस टीम में था, तब नवीनतम छोटे Google models को Chrome में बहुत तेज़ी से लाया जाता था
      अगर Gemma 4 या उसके अनुरूप Gemini Nano अभी Chrome में नहीं है, तो मेरा अनुमान है कि जल्द आ जाएगा
      और यह लेख 2025-09-21 को आख़िरी बार अपडेट हुआ था, और उस समय तक यह पहले ही Gemini Nano 3 था
    • हाँ
      इसमें लिखा है कि Prompt API browser के भीतर मौजूद Gemini Nano को natural language requests भेजने का तरीका है
    • Prompt API browser में उपलब्ध model का इस्तेमाल करती है
      Edge में शायद यह Phi4 होगा

  • यह कुछ हद तक ऐसा भी लगता है कि कोई दुर्भावनापूर्ण JS script अनजान visitors पर token generation का बोझ डाल सकती है
    यह भी दिलचस्प होगा कि क्या बड़े prompts को छोटे हिस्सों में बाँटकर कई browsers को भेजा जा सकता है, और हर browser सिर्फ छोटा हिस्सा process करे, ताकि subagent pattern या RLM जैसी किसी संरचना से उपयोगी distributed result बन सके

    • मेहनत के मुकाबले फायदा बहुत कम लगता है
      technical और business infrastructure भी बेहद जटिल हो जाएगा, और अगर सच में user browsers पर prompts offload करने हैं, तो शायद सीधे Chrome API का ठीक से इस्तेमाल करना बेहतर होगा। यह भी संदेह है कि ऐसे low-end models पर server-side prompts offload करना वास्तव में कितनी बार सार्थक साबित होगा
      और अगर सच में ऐसा करना हो, तो WebGPU भी काफ़ी समय से मौजूद है
    • छोटे models से token generation की लगभग कोई कीमत नहीं है

  • यह एक proper Model API की दिशा में कदम जैसा लगता है, लेकिन अभी बहुत छोटा कदम है
    इससे Apple के Foundation Models भी याद आते हैं
    कई AI integrations text communication या chat style पर केंद्रित हैं, लेकिन वास्तव में बहुत-सा software non-text interfaces में भी लाभ उठा सकता है
    अंततः OS और browser को model-management APIs देनी चाहिए, ताकि apps एक सरल interface के माध्यम से on-device models और remote models तक पहुँच सकें
    अगर यह cross-platform standard बन जाए तो बहुत अच्छा होगा, और इसे mobile तक भी पहुँचना होगा, इसलिए व्यवहारिक रूप से इसे आगे बढ़ाने की सबसे अधिक क्षमता Apple और Google के पास ही लगती है। Meta पीछे से आए या उल्टा पहले कदम उठाए, यह अलग बात है
    मुख्य बात यह है कि यह किसी खास प्रचारित model तक सीमित नहीं होना चाहिए
    apps को query करके उपयुक्त model चुन पाने में सक्षम होना चाहिए
    (1) https://developer.apple.com/documentation/foundationmodels

    • Apple के Foundation Models कागज़ पर अच्छे लगते हैं, लेकिन असल में देखें तो 4k context window अटकाती है
      बेशक अभी यह शुरुआती दौर में है

  • https://github.com/mozilla/standards-positions/issues/1067

  • हम इसे Hackday retrospective summary के लिए इस्तेमाल कर रहे हैं
    https://remotehack.space/previous-hacks/
    यह एक छोटा script है जो RSS feed पढ़कर body text से summary बनाता है, और static site के साथ काफ़ी अच्छी तरह फिट बैठता है। कभी आगे चलकर मैं इसे बढ़ाकर उसी content पर अलग-अलग सवाल पूछने लायक बनाना चाहूँगा

  • browser से accessible local LLM privacy के लिहाज़ से अच्छा है, लेकिन अगर हर browser इस API के पीछे अलग model लगाता है, तो testing nightmare अभी से भी बदतर हो सकता है
    आखिरकार ज़्यादातर implementations शायद Gemini Nano को ध्यान में रखकर बनेंगी, तो यह भी सोचने वाली बात है कि क्या इससे users और ज़्यादा Chrome की ओर खिंचेंगे

    • testing fragmentation ही असली समस्या है
      व्यवहार में prompts model-agnostic नहीं होते, इसलिए Gemini Nano 3 v2025 के लिए बारीकी से tune किया गया prompt, Gecko पक्ष के model पर चुपचाप खराब प्रदर्शन दे सकता है। लेकिन API तो branching के लिए capability detection तक नहीं देती
      यह WebGL से भी बदतर है, जहाँ कम-से-कम extension support query किया जा सकता था। किसी feature को ऐसे ship करना कि वह browser के पीछे छिपे model की prompt quality पर निर्भर हो, जबकि उसका नाम और version भी न पता हो, वैसा है जैसे ऐसा software जारी करना जिसकी functionality user द्वारा इंस्टॉल किए गए dictionary पर निर्भर करती हो

  • मुझे लगता है Gemini Nano के weights, Gemma के विपरीत, open नहीं हैं
    अगर किसी ने पहले से नहीं किया है, तो मैं model weights dump करके देखना चाहूँगा