Skip to main content
आपका प्रॉम्प्ट प्रोवाइडर तक पहुँचने से पहले हमारे माध्यम से गुजरता है। चार फ़ील्ड यह तय करते हैं कि हम इसके साथ क्या करते हैं। प्रोवाइडर को कॉल करने से पहले हम इन चारों को बॉडी से हटा देते हैं, ताकि प्रोवाइडर इन्हें कभी न देखे। पहले तीन केवल Managed Keys पर चलते हैं। आपकी अपनी keys पर हम आपके अनुरोध को बिना किसी बदलाव के आगे भेज देते हैं। मास्किंग और मॉडरेशन पहले आपके अनुरोध को पढ़ते हैं, फिर आपके संगठन के डिफ़ॉल्ट को, फिर बंद हो जाते हैं। ट्रेस स्टोरेज केवल अनुरोध को पढ़ता है और कुछ नहीं।

​
PII मास्किंग

प्रोवाइडर तक पहुँचने से पहले हम आपके प्रॉम्प्ट में व्यक्तिगत डेटा को मास्क कर सकते हैं। प्रत्येक मिलान [EMAIL_1] जैसे एक स्थिर प्लेसहोल्डर बन जाता है, ताकि मॉडल अभी भी लोगों को अलग-अलग पहचान सके। इसमें ईमेल, फ़ोन नंबर और कार्ड नंबर जैसे अन्य पैटर्न शामिल हैं।
आपके संगठन द्वारा चालू की गई मास्किंग को छोड़ने के लिए एक अनुरोध पर false भेजें। यदि मास्किंग चालू है और यह विफल हो जाती है, तो हम अनुरोध को बिना मास्क किए भेजने के बजाय 500 pii_masking_failed के साथ रोक देते हैं।

​
मॉडरेशन

भेजने से पहले हम एक प्रॉम्प्ट में हानिकारक सामग्री की जाँच कर सकते हैं। एक ब्लॉक किया गया प्रॉम्प्ट 403 moderation_blocked लौटाता है और किसी प्रोवाइडर तक नहीं पहुँचता।

​
ट्रेस स्टोरेज

हम आपके प्रॉम्प्ट और उत्तरों को एन्क्रिप्टेड रूप से स्टोर कर सकते हैं, ताकि लॉग्स पेज उन्हें दिखा सके। केवल आपका अनुरोध इसे चालू करता है। एक प्रबंधित अनुरोध अन्यथा वही रखता है जो एक BYOK अनुरोध रखता है, जो बिलिंग डेटा है और कुछ नहीं।
फ़ील्ड के बिना बाद का अनुरोध कुछ भी नया स्टोर नहीं करता है। जो आपने पहले से स्टोर किया है वह तब तक रहता है जब तक आप उसे लॉग्स पेज पर हटा नहीं देते।

​
प्रॉम्प्ट कैशिंग

हम सीधे Anthropic रूट पर हर Claude अनुरोध को कैश करते हैं। एक दोहराया गया प्रीफ़िक्स फिर सामान्य इनपुट कीमत के दसवें हिस्से पर बिल किया जाता है। कैश लिखने में इनपुट कीमत का 1.25 गुना खर्च होता है। एक प्रीफ़िक्स जिसे आप कभी दोबारा उपयोग नहीं करते हैं, उसकी कीमत 25 प्रतिशत अधिक होती है। इसलिए आप कैशिंग बंद कर सकते हैं।
आपके अपने मार्कर हमेशा जीतते हैं। यदि आपके अनुरोध में कोई cache_control है, तो हम उसे आगे भेज देते हैं और अपना कुछ भी नहीं जोड़ते। एक अनुरोध जो कैश करने के लिए बहुत छोटा है, वह बस अनकैश्ड चलता है। प्रतिक्रिया अपने उपयोग ब्लॉक में cached_tokens और cache_write_tokens की रिपोर्ट करती है।

​
प्रबंधित keys पर पहचान फ़ील्ड

Managed Keys पर हम प्रोवाइडर को कॉल करने से पहले चार पहचान फ़ील्ड को आपके संगठन ID के एक स्थिर हैश से बदल देते हैं। एक प्रोवाइडर हमारे क्रेडेंशियल पर जो पहचान देखता है, वह हमसे आनी चाहिए, इसलिए ये एकमात्र फ़ील्ड हैं जिन्हें हम आगे भेजने के बजाय बदलते हैं।
  • user
  • safety_identifier
  • prompt_cache_key
  • metadata.user_id
आपकी अपनी key पर हम चारों को वैसे ही आगे भेज देते हैं जैसे आपने उन्हें भेजा था। हम metadata में हर दूसरी key को वैसे ही छोड़ देते हैं। Workers AI बॉडी पर कोई पहचान फ़ील्ड नहीं लेता है, इसलिए हम इसके बजाय हैश को अनुरोध से ही जोड़ देते हैं। Gemini, Vertex और Bedrock कोई पहचान फ़ील्ड नहीं लेते हैं जिसे हम सेट कर सकें। उन तीन रूट्स पर हम आपका हटा देते हैं और उसके स्थान पर कुछ भी नहीं भेजते।

​
टूल कॉल IDs में एक आरक्षित मार्कर

Gemini को प्रत्येक टूल कॉल के साथ एक सिग्नेचर को फिर से चलाने की आवश्यकता होती है, इसलिए हम इसे टूल कॉल ID के अंदर रखते हैं। हम आपको जो ID देते हैं वह <id>::gsig::<signature> जैसी दिखती है, और किसी अन्य प्रोवाइडर के देखने से पहले हम सिग्नेचर को वापस हटा देते हैं। आपकी अपनी IDs बिना किसी बदलाव के पास हो जाती हैं, भले ही उनमें :: शामिल हो। एक चीज़ जिससे बचना है वह है आपके द्वारा बनाई गई ID के अंदर शाब्दिक टेक्स्ट ::gsig::, क्योंकि हम इसे अपना मानेंगे और ID को छोटा कर देंगे।

​
Gemini मॉडलों पर फ़ाइल नाम

आप एक दस्तावेज़ को इनलाइन, base64 बाइट्स के रूप में या data: URL के रूप में भेज सकते हैं। एक Gemini मॉडल पर हम Google को मीडिया प्रकार और बाइट्स भेजते हैं, और हम filename और file_id को छोड़ देते हैं। Google के दस्तावेज़ प्रारूप में उनके लिए कोई फ़ील्ड नहीं है और यह ऐसे अनुरोध को अस्वीकार करता है जिसमें वे हों। मॉडल बाइट्स को पढ़ता है और कभी कोई नाम नहीं देखता, इसलिए आपके द्वारा भेजा गया कुछ भी नहीं खोता है। हर दूसरे प्रोवाइडर को अभी भी नाम मिलता है।