यह मूल अंग्रेजी दस्तावेज़ का मशीन अनुवाद है। इस अनुवाद और मूल अंग्रेजी संस्करण के बीच किसी भी विवाद की स्थिति में, अंग्रेजी संस्करण ही मान्य होगा। मूल अंग्रेजी संस्करण पढ़ें
ऑन-डिवाइस स्यूडोनिमाइज़र (Pseudonymizer): निर्माण और बेंचमार्किंग
2026-05-22 · Caiioo Team
हम वास्तविक व्यक्तिगत रूप से पहचान योग्य जानकारी को प्रशिक्षित करने और बनाए रखने वाले AI सिस्टम की गोपनीयता समस्या को हल करना चाहते थे। "Zero Data Retention" नीतियां और समझौते जोखिम को कम करते हैं, लेकिन वे अपवादों से भरे हुए हैं। वे अनिवार्य रूप से कहते हैं: "हम आपके किसी भी प्रॉम्प्ट या आउटपुट को स्टोर नहीं करेंगे सिवाय: (यहाँ अपवादों की एक बड़ी सूची दर्ज करें: सुरक्षा उद्देश्य, सरकारी निगरानी, मुकदमेबाजी, उत्पाद विकास, त्रुटि लॉग, सेवाओं में सुधार...)"
इसे हल करने के लिए, हमने एक व्यक्तिगत डेटा फ़िल्टर बनाया है जो उपयोगकर्ता की अपनी मशीन पर चलता है, डिवाइस छोड़ने से पहले संदेश को देखता है, और वही उत्तर देता है जो उपयोगकर्ता को बिना फ़िल्टर के टाइप करने पर प्राप्त होता।
इसलिए हमने एक बनाया। Caiioo के अगले संस्करण में Pseudonymizer शामिल होगा। एजेंट चैट में शील्ड आइकन के साथ-साथ सेटिंग्स के माध्यम से सुलभ।
यह श्वेत पत्र हमारे गोपनीयता फ़िल्टरिंग सिस्टम के पीछे के तर्क, आर्किटेक्चर, मूल्यांकन प्रक्रिया और डिज़ाइन सिद्धांतों की रूपरेखा तैयार करता है।
हम क्या करने के लिए निकले हैं
डेटा न्यूनीकरण द्वारा सामान्य गोपनीयता सुरक्षा। जब कोई उपयोगकर्ता किसी रिमोट मॉडल के साथ चैट करता है, तो मॉडल को उपयोगकर्ता के प्रश्न का उत्तर देने के लिए वास्तविक नाम, घर का पता, वास्तविक ईमेल या ग्राहक के फोन नंबर की आवश्यकता नहीं होती है। इसे प्रश्न के स्वरूप की आवश्यकता होती है, और इसे एक वास्तविक प्रश्न की तरह दिखने की आवश्यकता होती है ताकि LLM उस क्वेरी को एक परीक्षण मानकर खारिज न कर दे। इसलिए, फ़िल्टर AI को भेजे गए डेटा से वास्तविक पहचानकर्ताओं को हटा देता है और वापस आते समय वास्तविक मानों को वापस जोड़ देता है। मॉडल सिंथेटिक नाम और पहचानकर्ता देखता है; उपयोगकर्ता वास्तविक बातचीत देखता है।
HIPAA अनुपालन सहायता। दूसरा मोड HIPAA Safe Harbor नियम (§164.514) के 18 पहचानकर्ताओं और अधिक उदार Limited Data Set संस्करण को लक्षित करता है। एक चिकित्सक, एक स्वास्थ्य सेवा व्यवस्थापक, या कवर किए गए वर्कफ़्लो पर काम करने वाला कोई भी व्यक्ति संरक्षित स्वास्थ्य जानकारी (PHI) को AI को भेजे बिना वास्तविक मामलों के बारे में सामान्य-उद्देश्य वाले मॉडल से बात कर सकता है। हम कवर की गई इकाई के अनुपालन अधिकारी नहीं हैं — लेकिन हम वह परत बन सकते हैं जो PHI को लैपटॉप से बाहर जाने से रोकती है। हमारे मूल्यांकन मापने योग्य बेंचमार्क प्रदान करते हैं जिनका उपयोग संगठन अपने अनुपालन और गोपनीयता मानकों के लिए फ़िल्टर की उपयुक्तता का आकलन करने के लिए कर सकते हैं। सभी गोपनीयता और सुरक्षा उपाय निर्णय लेने के मामले हैं जो उपयोगकर्ता या उपयोगकर्ता इकाई की जिम्मेदारी हैं।
हमने दोनों को इसलिए चुना क्योंकि इंजीनियरिंग समान है, और PHI उपयोग का मामला वास्तव में तकनीकी रूप से आसान है क्योंकि इसमें विशिष्ट नामित संस्थाओं (named entities) का उपयोग किया जाता है, जिन्हें Personal Data श्रेणी के अधिक सामान्य डेटा की तुलना में संपादित (redact) करना आसान होता है। HIPAA फ़िल्टरिंग को इस तथ्य से भी मदद मिलती है कि यह आम तौर पर English या Spanish में होती है। हम पहचानकर्ताओं का पता लगाते हैं, उसी प्रारूप में स्थिर छद्म नाम (pseudonyms) और प्रतिस्थापित पहचानकर्ता रखते हैं, वापस आते समय उन्हें पुनर्स्थापित करते हैं, और वास्तविक मानों को कभी लॉग नहीं करते हैं। सिंथेटिक जानकारी और वास्तविक जानकारी के बीच का मैप केवल उपयोगकर्ता के डिवाइस पर रहता है, ताकि उपयोगकर्ता एजेंट की प्रतिक्रियाओं में वास्तविक जानकारी पढ़ सके। श्रेणियों की सूची और नीति द्वार (policy gate) वे चीजें हैं जो मोड के बीच बदलती हैं।
क्यों regex और machine learning दोनों, और केवल इनमें से कोई एक नहीं
हमारे pseudonymizer में दो मुख्य फ़िल्टर तकनीकें हैं: एक नियतात्मक (deterministic) पैटर्न पहचान भाषा जिसे regex कहा जाता है, और प्रशिक्षित machine learning मॉडल।
सतही प्रारूपों (surface formats) पर regex अपराजेय है। एक ईमेल पते का एक आकार होता है ([email protected])। वैसे ही एक IP, क्रेडिट कार्ड, IBAN, VIN, SSN (XXX-XX-XXXX), और API key का भी होता है। यदि प्रारूप विश्वसनीय है, तो regex इसे हर बार नियतात्मक रूप से पकड़ लेता है, जिसमें कोई मॉडल लोड नहीं होता और न ही कोई इनफरेंस लागत आती है।
हालाँकि, संदर्भ (context) के मामले में regex पूरी तरह विफल है। "Sarah's chart from last Tuesday" में एक व्यक्ति और एक तारीख है, लेकिन इनमें से किसी को भी केवल उनके प्रारूप से नहीं पहचाना जा सकता। "The patient at 14 Elm" में एक पता है जो हज़ारों गैर-पतों के समान हो सकता है। "Their MRN is 7741032" को अर्थपूर्ण होने के लिए संख्या के आसपास के शब्दों की आवश्यकता होती है।
एक छोटा fine-tuned भाषा मॉडल संदर्भ को संभालता है — हमारा मॉडल एक विशेष रूप से प्रशिक्षित 110M-parameter वाला एनकोडर है जिसे एक बहुभाषी लघु भाषा मॉडल से डिस्टिल किया गया है। यह सबस्ट्रिंग के बजाय पूरे वाक्य को पढ़ता है और इतना छोटा है कि किसी डिवाइस, यहाँ तक कि मोबाइल फोन पर भी अत्यंत तेज़ी से चल सकता है।
बेंचमार्क इन दोनों परतों की पूरक शक्तियों को दर्शाते हैं। हमने दोनों परतों का अलग-अलग परीक्षण किया ताकि यह सुनिश्चित हो सके कि प्रत्येक परत वास्तव में अपना योगदान दे रही है। 150-प्रश्नों वाले PrivacyBench-PD सेट पर, जहाँ प्रश्नों और उत्तरों का उपयोग मॉडल को प्रशिक्षित करने के लिए स्पष्ट रूप से नहीं किया गया था:
| परत | पकड़ी गई PII | पकड़ने की दर |
|---|---|---|
| केवल Regex | 205 / 670 | 30.6 % |
| केवल ML | 516 / 670 | 77.0 % |
| दोनों (production) | 625 / 670 | 93.3 % |
केवल regex तीन-चौथाई पहचानकर्ताओं को छोड़ देता है क्योंकि वास्तविक गद्य (prose) में अधिकांश पहचानकर्ता संरचित नहीं होते हैं। केवल ML उन 16 प्रतिशत अंकों को छोड़ देता है जिन्हें regex परत पकड़ लेती — वे चीज़ें जो पूरी तरह से अपने आकार पर निर्भर हैं (एक क्रेडिट कार्ड क्रेडिट कार्ड जैसा दिखता है; मॉडल के पास जोड़ने के लिए कोई अतिरिक्त संकेत नहीं होता)। साथ मिलकर वे उस हिस्से को कवर करते हैं जिसे कोई भी अकेला कवर नहीं कर सकता।
गहराई से देखने पर कि प्रत्येक परत कहाँ निर्णायक है: उसी सेट में, 16 परीक्षण मान केवल regex द्वारा पकड़े गए (ईमेल, IP, वित्तीय खाते, संरचित ID) और 327 केवल ML द्वारा पकड़े गए (नाम, संदर्भात्मक पहचानकर्ता, बहुभाषी वाक्यांश)।
छोटा, स्मार्ट, तेज़ — और हर जगह चलता है
हमें फ़िल्टर को ऑन-डिवाइस चलाना था, जो एक इंजीनियरिंग चुनौती थी।
इसे छोटा होना चाहिए क्योंकि हमारा ऐप कई प्रणालियों पर ऑन-डिवाइस चलता है: ब्राउज़र एक्सटेंशन, macOS ऐप, iOS ऐप, Android ऐप, या Windows और Linux के अंदर। बंडल प्रति मॉडल लगभग 113 MB है। दो मॉडल हैं — एक सामान्य व्यक्तिगत डेटा के लिए, एक संरक्षित स्वास्थ्य जानकारी के लिए — और Safe Harbor मोड दोनों को समानांतर में चलाता है। इनमें से, एक लो-एंड Android डिवाइस सबसे कम प्रदर्शन करने वाला है, फिर भी हमारा सिस्टम ठीक काम करता है।
इसे स्मार्ट होना चाहिए क्योंकि गलत नकारात्मक (false negatives) वास्तविक डेटा को रिमोट LLM तक लीक कर देते हैं और गलत सकारात्मक (false positives) बातचीत को खराब कर देते हैं। नामों को संपादित किया जाना चाहिए; सर्वनामों को नहीं। फॉरवर्ड किए गए थ्रेड में डॉक्टर के ईमेल को संपादित किया जाना चाहिए; [email protected] फुटर को शायद नहीं।
इसे तेज़ होना चाहिए क्योंकि यह उपयोगकर्ता द्वारा भेजे जाने वाले या प्राप्त होने वाले प्रत्येक संदेश के रास्ते में सीधे बैठता है। हमने एकल CPU थ्रेड पर 200 ms से कम के राउंड-ट्रिप ओवरहेड को मापा, जिसमें ज्यादातर टोकनाइजेशन था। WebGPU और Apple के Neural Engine पर यह LLM कॉल की नेटवर्क लेटेंसी की तुलना में बहुत छोटा है।
इसे कई रनटाइम में चलना चाहिए क्योंकि Caiioo मल्टी-प्लेटफ़ॉर्म है। वही सिस्टम Chrome एक्सटेंशन, macOS और iOS, Android, और Windows और Linux पर चलता है। एक डिटेक्शन मॉडल, एक regex लाइब्रेरी, एक मर्जर, एक पॉलिसी — हर सतह पर समान व्यवहार जहाँ Caiioo चलता है।
स्कोर (The scores)
परीक्षण और प्रशिक्षण के कई दौरों के बाद, हमने अपने मॉडल के 16वें संस्करण को अंतिम रूप दिया। नीचे तीन बेंचमार्क दिए गए हैं, जिनमें से प्रत्येक अलग-अलग पहलुओं को मापता है।
हमारा अपना टेस्ट सेट, 150 प्रश्न जो मॉडल ने पहले कभी नहीं देखे
सार्वजनिक बेंचमार्क के विरुद्ध परीक्षण करने से पहले, हमने अपने Personal Data फ़िल्टर को एक आंतरिक टेस्ट सेट पर चलाया जिसे हमने जानबूझकर प्रशिक्षण डेटा से बाहर रखा था — ताकि डिटेक्टर ने इनमें से किसी भी प्रश्न को पहले कभी न देखा हो। 150 प्रश्नों को चार समूहों (code snippets, दस्तावेज़ गद्य, जानबूझकर अपरिचित वाक्यांश, और 10 गैर-अंग्रेजी भाषाएं) में विभाजित किया गया, साथ ही एक "negative" समूह जिसमें कोई निजी डेटा नहीं है (यह जांचने के लिए कि हम ज़रूरत से ज़्यादा रेडैक्ट तो नहीं कर रहे)। संयुक्त regex + ML पाइपलाइन:
| सब-बेंच (Sub-bench) | पकड़े गए (Caught) | दर (Rate) |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| सभी 4 पॉजिटिव बेंच | 625 / 670 | 93.3 % |
(नेगेटिव समूह में खोजने के लिए कोई निजी डेटा नहीं था। फ़िल्टर ने एक ऐसी चीज़ को मास्क किया जिसे नहीं करना चाहिए था — जो नीचे दिए गए प्रिसिजन (precision) आंकड़ों के अनुरूप है।)
ग्रेडर सख्त है: प्रश्न को स्कोर करने के लिए निजी डेटा के प्रत्येक अपेक्षित हिस्से को मास्क किए गए आउटपुट से पूरी तरह गायब होना चाहिए। कोई आंशिक क्रेडिट नहीं, कोई "काफी करीब" नहीं। यह उन बेंचमार्क की तुलना में अधिक कठोर है जो किसी अन्य LLM को जज बनने के लिए कहते हैं (LLM जज उदार होते हैं)। अन्य प्रणालियों के साथ सीधे तुलनीय आंकड़ों के लिए, नीचे दिया गया हेड-टू-हेड सेक्शन देखें।
PrivacyBenchHIPAA — 40 स्वास्थ्य सेवा प्रश्न
प्रत्येक प्रश्न संरक्षित स्वास्थ्य जानकारी (PHI) को सूचीबद्ध करता है जिसे रेडैक्ट किया जाना चाहिए (नाम, मेडिकल रिकॉर्ड नंबर, आदि) और वे संकेत जिन्हें रखा जाना चाहिए (तारीखें, भूगोल, 90 वर्ष से कम आयु — HIPAA Limited Data Set नियम)। ग्रेडर दोनों दिशाओं में जाँच करता है: क्या हमने वह हटाया जो हमें हटाना चाहिए था, और क्या हमने उसे छोड़ दिया जिसे हमें छोड़ना चाहिए था?
| मोड (Mode) | PHI रेडैक्ट किया गया | रिटेन्ड (Retained) रखा गया |
|---|---|---|
| Limited Data Set (तारीखें / भूगोल / आयु ≤89 सुरक्षित रखें) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (तारीखों सहित सब कुछ रेडैक्ट करें) | 99 / 104 (95.2 %) | — |
Limited Data Set सबमोड इस बेंचमार्क पर सटीक है। Safe Harbor — जिसमें रेडैक्ट करने के लिए अधिक चीज़ें हैं, इसलिए चूकने की अधिक संभावना है — 95.2% को कवर करता है।
हमारे अपने डेटा पर श्रेणी-दर-श्रेणी परिणाम, प्रति मोड 200 नमूने
सार्वजनिक बेंचमार्क सब कुछ एक साथ मिला देते हैं। हमारा आंतरिक परीक्षण डेटा परिणामों को श्रेणी (नाम, ईमेल, पते, इत्यादि) के आधार पर विभाजित करता है और प्रत्येक को तीन तरीकों से चलाता है: केवल regex, केवल ML, और दोनों एक साथ। यह हमें सटीक रूप से बताता है कि कौन सी तकनीक किस प्रकार के पहचानकर्ता को पकड़ रही है — और कहाँ प्रत्येक को दूसरे की आवश्यकता है। नवीनतम रन, 2026-05-20:
सभी तीन फ़िल्टर मोड का सारांश
| मोड (Mode) | कंबाइंड रिकॉल (Combined recall) | प्रिसिजन (Precision) | F2 | नमूने (Samples) |
|---|---|---|---|---|
| Personal Data फ़िल्टर | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA फ़िल्टर — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA फ़िल्टर — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
इन आंकड़ों में URL शामिल नहीं हैं, जिन्हें हम जानबूझकर छोड़ देते हैं — URL को हटाने से "इस लिंक को खोलें" या "उस पेज को लाएं" जैसे डाउनस्ट्रीम कार्य बाधित हो जाएंगे। इसके बारे में अधिक जानकारी नीचे वर्कफ़्लो सेक्शन में दी गई है।
प्रति-श्रेणी तालिकाओं से पहले की बड़ी तस्वीर: हर मोड में, वे पहचानकर्ता जो वास्तव में किसी व्यक्ति की पहचान करते हैं, 100% या उसके करीब पकड़े जाते हैं। नाम, ईमेल, फोन नंबर, डाक पते, सरकारी आईडी, बायोमेट्रिक आईडी, सटीक जियोलोकेशन, मेडिकल रिकॉर्ड नंबर, जन्म तिथि, सोशल सिक्योरिटी नंबर — हर नमूने, हर परीक्षण पर पकड़े गए। वे श्रेणियां जहां हम 100% से नीचे गिरते हैं, वे अनुमानित हैं: डिवाइस आईडी (वास्तविक टेक्स्ट में प्रारूपों की विशाल विविधता), विविध संस्थागत आईडी (लॉयल्टी नंबर, कर्मचारी आईडी — वही समस्या), और फोटो (एक टेक्स्ट-ओनली फ़िल्टर यह नहीं देख सकता कि इमेज के अंदर क्या है)। इनमें से कोई भी "चार्ट पर नाम" या "ड्राफ्ट में ईमेल" जैसा पहचानकर्ता नहीं है जो वास्तव में लीकेज के लिए मायने रखता है। उच्च-जोखिम वाली श्रेणियां विश्वसनीय हैं।
Personal Data फ़िल्टर
कंबाइंड रिकॉल (सबसे अच्छा पहले), फिर जोखिम स्तर (T1 = सबसे संवेदनशील) द्वारा क्रमबद्ध।
| श्रेणी (Category) | स्तर (Tier) | Regex रिकॉल | ML रिकॉल (raw) | कंबाइंड रिकॉल | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
विश्लेषण करने पर, दो-परत वाला डिज़ाइन रंग ला रहा है। डाक पते, जन्म तिथियां और व्यक्तियों के नाम अकेले regex के तहत 0-13% स्कोर करते हैं — मिलान करने के लिए कोई निश्चित आकार नहीं है, इसलिए केवल ML मॉडल ही उन्हें पकड़ सकता है। ईमेल, फोन नंबर, IP, सरकारी आईडी, बायोमेट्रिक आईडी और सटीक जियोलोकेशन अकेले regex के तहत 100% स्कोर करते हैं — ये ऐसे सतही प्रारूप हैं जिन्हें ML मॉडल आसानी से प्राप्त कर लेता है। ऑनलाइन हैंडल, वाहन आईडी और ऑथेंटिकेशन सीक्रेट मिश्रित हैं: regex मानक रूपों को पकड़ता है, ML बाकी को। कंबाइंड रिकॉल हर श्रेणी में उस एकल परत के बराबर या उससे अधिक है जो अधिक मजबूत है।
डिवाइस आईडी और विविध संस्थागत आईडी 100% से नीचे की श्रेणियां हैं, और हम जानते हैं क्यों: वास्तविक टेक्स्ट में इनके प्रारूपों की सबसे विस्तृत विविधता होती है। हम उन श्रेणियों के बारे में ईमानदार होना पसंद करेंगे जहां रिकॉल कम होता है, बजाय इसके कि यह दिखावा करें कि फ़िल्टर हर जगह सटीक है।
HIPAA फ़िल्टर — Limited Data Set सबमोड
Limited Data Set सबमोड डिज़ाइन के अनुसार तारीखों, भूगोल और 89 या उससे कम उम्र को सुरक्षित रखता है — ये वे संकेत हैं जिन्हें HIPAA एक संगठन को वैध नैदानिक अनुसंधान और संचालन के लिए रखने की अनुमति देता है।
| श्रेणी (Category) | स्तर (Tier) | Regex रिकॉल | ML रिकॉल (raw) | कंबाइंड रिकॉल | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
तस्वीरें एक ज्ञात चूक हैं — एक टेक्स्ट-ओनली फ़िल्टर यह नहीं देख सकता कि इमेज के अंदर क्या है। Image-PHI एक अलग समस्या है जिसे हमने अभी तक शिप नहीं किया है। इस मोड में हर दूसरी श्रेणी 100% पर है।
HIPAA फ़िल्टर — Safe Harbor सबमोड
Safe Harbor उन सभी चीज़ों को हटा देता है जिन्हें Limited Data Set सबमोड ने रखा होता — तारीखें, 89 से अधिक उम्र, भूगोल। सख्त कवरेज प्राप्त करने के लिए, यह दोनों फ़िल्टर मॉडल को समानांतर में चलाता है: HIPAA-विशिष्ट और सामान्य व्यक्तिगत-डेटा वाला।
| श्रेणी (Category) | स्तर (Tier) | Regex रिकॉल | ML रिकॉल (raw) | कंबाइंड रिकॉल | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
दो दिलचस्प पंक्तियाँ सामान्य तारीखें (regex 100%, ML 30%) और 89 से अधिक उम्र (regex 100%, ML 0%) हैं। हमने जानबूझकर Safe Harbor में regex को दोनों को संभालने दिया: तारीखों का एक आकार होता है जिसे regex हर बार पकड़ लेता है, और हम नहीं चाहते कि एक संभाव्य (probabilistic) मॉडल ">89" जैसी संख्यात्मक सीमा पर दोबारा विचार करे। ML मॉडल को वही नियम सिखाने की तुलना में एक नियतात्मक (deterministic) नियम अधिक विश्वसनीय है।
सभी श्रेणियों में समग्र आंकड़े
सब कुछ जोड़कर: पूरी पाइपलाइन (regex + ML एक साथ) अकेले किसी भी परत की तुलना में कैसी है?
| मोड (Mode) | परतें (Layers) | रिकॉल (Recall) | प्रिसिजन (Precision) | F2 |
|---|---|---|---|---|
| Personal Data | केवल regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | केवल ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | दोनों (पूर्ण) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | केवल regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | केवल ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | दोनों (पूर्ण) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | केवल regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | केवल ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | दोनों (पूर्ण) | 92.4 % | 88.9 % | 91.7 % |
Personal Data फ़िल्टर की "पूर्ण" पंक्ति हर मीट्रिक पर दोनों एकल-परत संस्करणों को हरा देती है — regex (सतही प्रारूपों के लिए) को ML मॉडल (संदर्भ के लिए) के साथ जोड़ना वास्तव में कुछ ऐसा प्रदान करता है जो अकेले कोई भी परत नहीं कर सकती। इस पोस्ट में पहले दी गई 97.3% की हेडलाइन वह संख्या है जो दर्शाती है कि एक वास्तविक उपयोगकर्ता को क्या मिलता है। ऊपर दी गई तालिका में संख्या थोड़ी कम है क्योंकि इसमें URL श्रेणी शामिल है, जिसे हम जानबूझकर सुरक्षित रखते हैं ताकि हम लिंक और टूल कॉल को न तोड़ें।
अन्य समर्पित प्राइवेसी फ़िल्टर के साथ आमने-सामने की तुलना
हमारे जैसे ऑन-डिवाइस, लगभग-तत्काल प्राइवेसी फ़िल्टर के लिए उचित तुलना अन्य ऑन-डिवाइस, लगभग-तत्काल प्राइवेसी फ़िल्टर के साथ है — न कि विशाल क्लाउड-होस्टेड LLMs के साथ जो प्रति संदेश सेकंड लेते हैं और जिन्हें नेटवर्क राउंड-ट्रिप की आवश्यकता होती है। हमने इस श्रेणी के प्रत्येक सिस्टम को समान टेस्ट सेट के विरुद्ध, समान मिलान नियमों का उपयोग करके चलाया। सभी के लिए समान मानक।
सहकर्मी श्रेणी (The peer class):
- openai/privacy-filter — OpenAI का ओपन-सोर्स समर्पित प्राइवेसी फ़िल्टर। लगभग 50 मिलियन पैरामीटर, किसी भी आधुनिक ब्राउज़र में चलने के लिए पर्याप्त छोटा।
- piiranha-v1 — iiiorg का 278M-पैरामीटर डिटेक्टर। इसका लाइसेंस इसे केवल अनुसंधान और मूल्यांकन तक सीमित करता है (हम इसे माप सकते हैं, लेकिन इसे व्यावसायिक रूप से शिप नहीं किया जा सकता)।
- Microsoft Presidio — सबसे व्यापक रूप से तैनात ओपन-सोर्स रेडैक्टर, जो संदर्भ के लिए एक छोटे भाषा मॉडल के साथ पारंपरिक पैटर्न मिलान को जोड़ता है।
- GLiNER PII family — छोटे, सामान्य-उद्देश्य वाले इकाई क्लासिफायर का एक परिवार। Knowledgator छोटे (~44M), बेस (~86M), और बड़े (~304M) वेरिएंट शिप करता है; NVIDIA ने अक्टूबर 2025 में 570M वेरिएंट जारी किया।
- Caiioo तीनों मोड में (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor)।
सभी पांच टेस्ट सेटों में रिकॉल, Caiioo के साथ पहले क्रमबद्ध:
| सिस्टम (System) | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 locales) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo दो सबसे बड़े परीक्षणों (PD-200 और PHI-200) पर समर्पित-फ़िल्टर श्रेणी में सबसे आगे है, सार्वजनिक बेंचमार्क पर बराबरी करता है या आगे रहता है, और बहुभाषी (multilingual) पर दूसरे स्थान पर है। सबसे छोटे परीक्षण (PrivacyBench PD-25, केवल 25 प्रश्न) पर Caiioo और openai/privacy-filter 96.2% पर बराबर हैं। बहुभाषी पर, openai/privacy-filter अभी भी 94.9% के साथ आगे है और Caiioo 92.6% पर है — वह भाषा जहाँ हम सबसे पीछे हैं वह चीनी है; बाकी हर जगह हम शीर्ष पर या उसके करीब हैं। यदि बहुभाषी कवरेज मिशन-क्रिटिकल है, तो openai/privacy-filter एक उचित विकल्प है। इस श्रेणी के अधिकांश अन्य वर्कलोड के लिए, Caiioo बेहतर है।
HIPAA परिणाम मुख्य आकर्षण है। दोनों Caiioo HIPAA मोड प्रत्येक HIPAA परीक्षण पर 100% रिकॉल प्राप्त करते हैं — प्रत्येक रोगी का नाम, प्रत्येक मेडिकल रिकॉर्ड नंबर, जन्म की प्रत्येक तिथि, प्रत्येक खाता संख्या पकड़ी जाती है। दूसरा सबसे अच्छा सिस्टम PrivacyBenchHIPAA पर 93.7% के साथ openai/privacy-filter है — 6.3-पॉइंट का अंतर, एक ऐसे बेंचमार्क पर जहाँ हर चूक एक वास्तविक दुनिया का खुलासा है।
पढ़ने लायक एक दूसरी संख्या: ओवर-रेडैक्शन (over-redaction) — उन चीज़ों को मास्क करना जो वास्तव में निजी डेटा नहीं थीं। ओवर-रेडैक्शन प्राइवेसी का नुकसान नहीं है, यह उपयोगिता की लागत है। बहुत अधिक चीज़ों को मास्क करें और LLM का तर्क (reasoning) खराब हो जाता है, और लौटाया गया उत्तर निम्न स्तर का होता है। Caiioo टेस्ट सेटों में 1-24 बार अनावश्यक रूप से मास्क करता है। Presidio: 10-51। NVIDIA का GLiNER: अकेले HIPAA परीक्षणों पर 31-64। प्रिसिजन उतना ही मायने रखता है जितना रिकॉल, जब लक्ष्य कम से कम जोखिम के साथ सर्वोत्तम संभव उत्तर प्राप्त करना हो।
फ़िल्टर के रूप में केवल एक फ्रंटियर LLM का उपयोग करने के बारे में क्या?
वे कर सकते हैं — और रॉ रिकॉल पर, वे जीतते हैं। बड़े सामान्य-उद्देश्य वाले LLMs (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B, और इसी तरह), चाहे क्लाउड में चल रहे हों या स्थानीय रूप से, बहुभाषी सहित हर परीक्षण में 95-100% स्कोर कर सकते हैं। यह उन उपयोगकर्ताओं के लिए एक वास्तविक विकल्प है जिन्हें अधिकतम रिकॉल की आवश्यकता है और वे इसके लिए भुगतान करने को तैयार हैं।
हालाँकि, कमियां वास्तविक हैं:
- यह धीमा है। मिलीसेकंड के बजाय प्रति संदेश सेकंड। फ़िल्टर उपयोगकर्ता द्वारा भेजे जाने वाले प्रत्येक संदेश के सामने बैठता है।
- या तो संदेश उपयोगकर्ता की मशीन छोड़ देता है, या मॉडल। क्लाउड में फ़िल्टर करने के लिए, संदेश को वहां जाना पड़ता है — जो उद्देश्य को ही विफल कर देता है। ऑन-डिवाइस फ़िल्टर करने के लिए 1-17 GB मॉडल डाउनलोड करने की आवश्यकता होती है।
- इसे धोखा दिया जा सकता है। एक जनरेटिव मॉडल को संदेश के बीच में रेडैक्ट न करने के लिए मनाया जा सकता है (एक "prompt injection" हमला)। हमारे जैसा छोटा क्लासिफायर ऐसा नहीं कर सकता।
- समान इनपुट, अलग आउटपुट। जनरेटिव मॉडल हमेशा दो बार एक ही उत्तर नहीं देते हैं। यह राउंड-ट्रिप को तोड़ देता है — बाहर जाते समय मास्किंग और वापस आते समय अनमास्किंग इस बात पर निर्भर करती है कि समान वास्तविक मान हमेशा समान नकली मान पर मैप हो।
Caiioo उस ट्रेडऑफ़ के दूसरे पक्ष के लिए बनाया गया है: एक छोटा, अनुमानित, सब-सेकंड फ़िल्टर जो उपयोगकर्ता द्वारा सेंड दबाने से पहले कंपोज़र में चलता है, और जो बातचीत के भीतर समान वास्तविक मान के लिए हमेशा समान नकली मान उत्पन्न करता है, ताकि राउंड-ट्रिप सुसंगत रहे। ऊपर दी गई सहकर्मी-श्रेणी तालिका उस प्रकार के उपयोग के मामले के लिए सटीक तुलना है।
प्रत्यक्ष प्रमाण ही सबसे बड़ा प्रमाण है
बेंचमार्क एक शुरुआत है, अंतिम लक्ष्य नहीं। यह फ़िल्टर Caiioo की नई विशेषता: pseudonymizer में एकीकृत है — वह घटक जो वास्तव में कंपोज़र और मॉडल के बीच स्थित होता है।
जब उपयोगकर्ता सेंड (send) दबाता है, तो यहाँ बताया गया है कि क्या होता है।
- Detect. रेगेक्स (regex) लेयर सबसे पहले चलती है — यह नियतात्मक (deterministic) और माइक्रोसेकंड-तेज़ है। इसके बाद जो कुछ भी बचता है उस पर ML मॉडल चलता है। यदि दोनों लेयर टेक्स्ट के एक ही हिस्से पर ओवरलैप होती हैं, तो हम एक सरल नियम का उपयोग करते हैं: सरफेस फॉर्मेट पर रेगेक्स जीतता है, संदर्भ (context) पर ML जीतता है।
- Tag self vs. other. Caiioo उन पहचानकर्ताओं को अलग करता है जो उपयोगकर्ता को संदर्भित करते हैं और जो अन्य लोगों को संदर्भित करते हैं। उपयोगकर्ता केवल एक, या दोनों को रिडैक्ट (redact) करना चुन सकता है। उपयोगकर्ता द्वारा व्यक्तिगत डिक्शनरी में जोड़े गए नाम हमेशा "self" माने जाते हैं।
- Substitute. प्रत्येक वास्तविक वैल्यू को एक स्थिर, स्टाइल-मैच छद्म नाम (pseudonym) मिलता है। "Sarah Goldberg", "Maya Hartwell" बन जाती है — और पूरी बातचीत के दौरान "Maya Hartwell" ही रहती है, ताकि उस व्यक्ति के बारे में मॉडल का तर्क (reasoning) अलग-अलग टर्न में खंडित न हो। एक रियल-टू-फेक लुकअप टेबल उपयोगकर्ता के डिवाइस पर रखी जाती है, जो प्लेटफॉर्म के कीचेन (keychain) की एक कुंजी के साथ एन्क्रिप्टेड होती है।
- Send. मॉडल को पूरी तरह से नकली संदेश प्राप्त होता है। कोई भी वास्तविक पहचानकर्ता कभी भी नेटवर्क पार नहीं करता है, और हमारा ऑडिट लॉग केवल गणना (counts) रिकॉर्ड करता है — कभी भी वैल्यू स्वयं नहीं।
- Restore. स्ट्रीमिंग रिस्पॉन्स आते ही उसे वापस मैप किया जाता है। मॉडल के उत्तर में "Maya Hartwell" स्क्रीन पर पहुँचने से पहले "Sarah Goldberg" बन जाती है, जिसे एक छोटे ग्लो पिल (glow pill) के साथ रेंडर किया जाता है ताकि उपयोगकर्ता एक नज़र में देख सके कि क्या सुरक्षित किया गया था।
- Restore tool arguments too. यदि मॉडल किसी टूल को कॉल करता है — ईमेल भेजना, टिकट फाइल करना, किसी डॉक में लिखना — और तर्कों (arguments) में नकली वैल्यू होती हैं, तो हम टूल चलने से पहले वास्तविक वैल्यू को वापस प्रतिस्थापित कर देते हैं। मॉडल नकली वैल्यू पर तर्क करता है; क्रिया (action) वास्तविक वैल्यू लेती है।
फ़िल्टर को इस बात से कोई फर्क नहीं पड़ता कि कौन सी AI सेवा उपयोग में है। यह संदेश मॉडल तक पहुँचने से पहले ही चल जाता है, इसलिए OpenRouter, Anthropic, Google, OpenAI, और एक स्थानीय Ollama सभी को एक जैसा मास्क किया हुआ पेलोड मिलता है। एक नया प्रदाता जोड़ने से गोपनीयता में कोई सेंध नहीं लगती।
यह किसकी रक्षा करता है
उपयोगकर्ता। एक उपयोगकर्ता का नाम, ईमेल, पता, फोन, IP और बायोमेट्रिक पहचानकर्ता — वे चीजें जो मिलकर एक एग्रीगेटर के लिए व्यक्ति की पहचान करती हैं — फ़िल्टर चालू होने पर कभी भी डिवाइस नहीं छोड़ती हैं।
वे लोग जिनके बारे में उपयोगकर्ता बात करता है। अधिकांश गोपनीयता उपकरण टाइप करने वाले व्यक्ति पर ध्यान केंद्रित करते हैं, लेकिन वे जिसे अनदेखा करते हैं वह 'सामाजिक अनुबंध' है — यह तथ्य कि हम स्वयं के साथ-साथ दूसरों के प्रति भी जिम्मेदारी निभाते हैं। LLM को "कृपया अक्षमता के लिए मिस्टर सॉन्डर्स के आचरण का विश्लेषण करें" सबमिट करना, जहाँ इसे अनिश्चित काल के लिए सिस्टम लॉग में रिकॉर्ड किया जा सकता है, गैर-जिम्मेदाराना (और संभावित रूप से मानहानिकारक) है। एक Google Sheet के साथ मदद के लिए LLM से पूछना जिसमें 1,000 व्यावसायिक संपर्क हैं, उन सभी को डेटा-रिटेंशन फ्लाईपेपर में जमा कर देता है। Caiioo का फ़िल्टर तीसरे पक्षों को भी कवर करता है: वह क्लाइंट जिसके लिए अनुबंध तैयार किया जा रहा है, वह रोगी जिसके रिकॉर्ड पर विचार किया जा रहा है, वह सहकर्मी जिसका ईमेल संदर्भ में पेस्ट किया गया था। उन्होंने रिमोट LLM को अपने पहचानकर्ता देखने के लिए सहमति नहीं दी। फ़िल्टर डिफ़ॉल्ट रूप से उसका सम्मान करता है; यदि वर्कफ़्लो की आवश्यकता हो तो उपयोगकर्ता "केवल स्वयं" या "केवल अन्य" पर स्विच कर सकता है।
संस्थाएं — व्यवसाय, अस्पताल, फर्में। खाता संख्या, लाइसेंस संख्या, मेडिकल रिकॉर्ड संख्या, वित्तीय रूटिंग विवरण, आंतरिक ID, API कुंजियाँ, ग्राहक रोस्टर। एक व्यवसाय का डेटा-न्यूनतमीकरण हित वैसा ही होता है जैसा एक व्यक्ति का होता है। डिस्चार्ज नोट तैयार करने के लिए Caiioo का उपयोग करने वाला एक चिकित्सक रोगी का मेडिकल रिकॉर्ड नंबर OpenAI को नहीं भेज रहा है। एक वकील क्लाइंट का खाता नंबर Anthropic को नहीं भेज रहा है। एक सपोर्ट इंजीनियर ग्राहक के लॉग से API कुंजी Google को नहीं भेज रहा है। फ़िल्टर यह नहीं पूछता कि पहचानकर्ता किसी व्यक्ति का है या किसी संस्था का — यह बस इसे डिवाइस पर रखता है।
अधिकतम उपयोगिता, न्यूनतम जोखिम
पूरी बात यह है कि उपयोगकर्ता को फ़िल्टर को महसूस नहीं करना चाहिए।
अधिकांश गोपनीयता उपकरण एक विकल्प चुनने के लिए मजबूर करते हैं: आक्रामक रूप से संपादित करें और मॉडल के उत्तर को खराब होते देखें, या प्रॉम्प्ट को उपयोगी रखें और गोपनीयता के वादे को टूटते हुए देखें। हमने उस समझौते को खारिज कर दिया। मॉडल को अभी भी एक पूर्ण प्रॉम्प्ट मिलता है — वह सही व्याकरणिक स्थितियों में एक नाम, एक स्थान, एक तारीख, एक मेडिकल रिकॉर्ड नंबर देखता है। वह बस नकली देखता है। उसका तर्क समान है; केवल स्ट्रिंग्स को साफ किया जाता है।
स्थिर प्रतिस्थापन (Stable substitution) ही इसे काम करने योग्य बनाता है। क्योंकि एक ही वास्तविक मान हमेशा एक बातचीत के भीतर एक ही नकली पर मैप होता है — उपयोगकर्ता के संदेश में, उस नाम का संदर्भ देने वाले टूल परिणाम में, मॉडल के पहले के उत्तर में जिसने इसका उल्लेख किया था — मॉडल के पास तर्क करने के लिए एक सुसंगत व्यक्ति, स्थान या वस्तु होती है। मल्टी-टर्न बातचीत गड़बड़ नहीं होती है। टूल कॉल नहीं टूटते हैं। सब-एजेंट मूल बातचीत के मैप को इनहेरिट करते हैं और पूरे कार्य में सुसंगत रहते हैं।
उपयोगकर्ता जो आउटपुट देखता है वह वास्तविक बातचीत है। प्रदाता जो डेटा देखता है वह एक सुसंगत कल्पना है। काम उन दो दृश्यों के बीच के अंतर में होता है, और लक्ष्य — एकमात्र लक्ष्य — उस अंतर को अदृश्य बनाना है।
एक गोपनीयता फ़िल्टर जो रास्ते में आता है उसे बंद कर दिया जाएगा। एक गोपनीयता फ़िल्टर जो वर्कफ़्लो में विलीन हो जाता है, वही भेजने लायक है।
यही वह मानक है जिसके लिए हमने इसे बनाया है।