یہ اصل انگریزی دستاویز کا مشینی ترجمہ ہے۔ اس ترجمے اور اصل انگریزی ورژن کے درمیان کسی بھی تضاد کی صورت میں، انگریزی ورژن ہی معتبر تصور ہوگا۔ اصل انگریزی ورژن پڑھیں
آن-ڈیوائس سیوڈونیمائزر (Pseudonymizer): تعمیر اور بینچ مارکنگ
2026-05-22 · Caiioo Team
ہم AI سسٹمز کے حقیقی ذاتی طور پر قابل شناخت معلومات پر تربیت حاصل کرنے اور اسے برقرار رکھنے کے رازداری کے مسئلے کو حل کرنا چاہتے تھے۔ "زیرو ڈیٹا ریٹینشن" پالیسیاں اور معاہدے خطرے کو کم کرتے ہیں، لیکن وہ استثنیٰ سے بھرے ہوئے ہیں۔ وہ بنیادی طور پر کہتے ہیں: "ہم آپ کے کسی بھی پرامپٹ یا آؤٹ پٹ کو محفوظ نہیں کریں گے سوائے: (یہاں استثنیٰ کی ایک لمبی فہرست درج کریں: سیکیورٹی مقاصد، حکومتی نگرانی، قانونی چارہ جوئی، پروڈکٹ ڈویلپمنٹ، ایرر لاگز، خدمات کو بہتر بنانا...)"
اسے حل کرنے کے لیے، ہم نے ایک ذاتی ڈیٹا فلٹر بنایا جو صارف کی اپنی مشین پر چلتا ہے، پیغام کو آلے سے باہر جانے سے پہلے دیکھتا ہے، اور وہی جواب واپس لاتا ہے جو صارف کو فلٹر کے بغیر ٹائپ کرنے پر ملتا۔
چنانچہ ہم نے ایک فلٹر بنایا۔ Caiioo کے اگلے ورژن میں Pseudonymizer شامل ہوگا۔ یہ ایجنٹ چیٹ میں شیلڈ آئیکن کے ساتھ ساتھ سیٹنگز کے ذریعے بھی دستیاب ہے۔
یہ وائٹ پیپر ہمارے پرائیویسی فلٹرنگ سسٹم کے پیچھے موجود منطق، فن تعمیر، تشخیص کے عمل اور ڈیزائن کے اصولوں کا خاکہ پیش کرتا ہے۔
ہم نے کیا کرنے کا عزم کیا ہے
ڈیٹا کی کم سے کم فراہمی کے ذریعے عمومی رازداری کا تحفظ۔ جب کوئی صارف کسی ریموٹ ماڈل کے ساتھ چیٹ کرتا ہے، تو ماڈل کو صارف کے سوال کا جواب دینے کے لیے اصل نام، گھر کا پتہ، اصل ای میل، یا گاہک کے فون نمبر کی ضرورت نہیں ہوتی۔ اسے سوال کی ہیئت کی ضرورت ہوتی ہے، اور اسے ایک حقیقی سوال کی طرح نظر آنا چاہیے تاکہ LLM اس سوال کو محض ایک ٹیسٹ سمجھ کر مسترد نہ کر دے۔ اس لیے، فلٹر AI کو بھیجے گئے ڈیٹا سے اصل شناخت کنندگان کو ہٹا دیتا ہے اور واپسی پر اصل اقدار کو دوبارہ جوڑ دیتا ہے۔ ماڈل مصنوعی نام اور شناخت کنندگان دیکھتا ہے؛ صارف اصل گفتگو دیکھتا ہے۔
HIPAA تعمیل میں معاونت۔ دوسرا موڈ HIPAA Safe Harbor رول (§164.514) کے 18 شناخت کنندگان اور اس سے کم سخت Limited Data Set ورژن کو نشانہ بناتا ہے۔ ایک طبیب (clinician)، ہیلتھ کیئر ایڈمنسٹریٹر، یا کوئی بھی شخص جو کسی کورڈ ورک فلو پر کام کر رہا ہو، وہ AI کو محفوظ شدہ صحت کی معلومات (PHI) بھیجے بغیر حقیقی کیسز کے بارے میں عام مقصد کے ماڈل سے بات کر سکتا ہے۔ ہم کورڈ ہستی (covered entity) کے کمپلائنس آفیسر نہیں ہیں — لیکن ہم وہ تہہ بن سکتے ہیں جو PHI کو لیپ ٹاپ سے باہر جانے سے روکتی ہے۔ ہماری تشخیصات ایسے پیمائش کے قابل بینچ مارکس فراہم کرتی ہیں جنہیں تنظیمیں اپنی تعمیل اور رازداری کے معیارات کے لیے فلٹر کی موزونیت کا اندازہ لگانے کے لیے استعمال کر سکتی ہیں۔ رازداری اور سیکورٹی کے تمام اقدامات فیصلے پر مبنی ہوتے ہیں جو صارف یا صارف کے ادارے کی ذمہ داری ہیں۔
ہم نے دونوں کا انتخاب اس لیے کیا کیونکہ ان کی انجینئرنگ ایک جیسی ہے، اور PHI کا استعمال درحقیقت تکنیکی طور پر زیادہ آسان ہے کیونکہ اس میں واضح نامزد اداروں (named entities) کا استعمال ہوتا ہے، جنہیں Personal Data کے زمرے میں موجود عمومی ڈیٹا کے مقابلے میں حذف کرنا زیادہ آسان ہے۔ HIPAA فلٹرنگ میں اس حقیقت سے بھی مدد ملتی ہے کہ یہ عام طور پر انگریزی یا ہسپانوی میں ہوتی ہے۔ ہم شناخت کنندگان کا پتہ لگاتے ہیں، ان کی جگہ مستحکم فرضی نام اور اسی فارمیٹ میں متبادل شناخت کنندگان استعمال کرتے ہیں، واپسی پر انہیں بحال کرتے ہیں، اور کبھی بھی اصل اقدار کو لاگ نہیں کرتے۔ مصنوعی معلومات اور اصل معلومات کے درمیان نقشہ (map) صرف صارف کے ڈیوائس پر رہتا ہے، تاکہ صارف ایجنٹ کے جوابات میں اصل معلومات پڑھ سکے۔ زمرہ جات کی فہرست اور پالیسی گیٹ وہ چیزیں ہیں جو مختلف موڈز کے درمیان تبدیل ہوتی ہیں۔
صرف ریجیکس (regex) یا صرف مشین لرننگ کے بجائے دونوں کا استعمال کیوں؟
ہمارے سیوڈونیمائزر (pseudonymizer) میں فلٹر کی دو اہم ٹیکنالوجیز موجود ہیں: ایک ڈیٹرمینسٹک پیٹرن ریکگنیشن زبان جسے regex کہا جاتا ہے، اور تربیت یافتہ مشین لرننگ ماڈلز۔
سطحی فارمیٹس (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" میں نمبر کے ارد گرد موجود الفاظ ہی اسے کوئی معنی دیتے ہیں۔
سیاق و سباق کو سنبھالنے کے لیے ایک چھوٹا فائن ٹیونڈ لینگویج ماڈل کام کرتا ہے — ہمارا ماڈل ایک خاص طور پر تربیت یافتہ 110M-parameter انکوڈر ہے جسے ایک کثیر لسانی چھوٹے لینگویج ماڈل سے کشید کیا گیا ہے —۔ یہ سب اسٹرنگ کے بجائے پورے جملے کو پڑھتا ہے اور اتنا چھوٹا ہے کہ کسی بھی ڈیوائس، یہاں تک کہ موبائل فون پر بھی انتہائی تیزی سے چل سکتا ہے۔
بینچ مارکس ان دونوں تہوں کی تکمیلی طاقتوں کی وضاحت کرتے ہیں۔ ہم نے ان دونوں تہوں کا الگ الگ تجربہ کیا تاکہ اس بات کو یقینی بنایا جا سکے کہ ہر تہہ واقعی اپنا کام کر رہی ہے۔ 150 سوالات پر مشتمل PrivacyBench-PD سیٹ پر، جہاں سوالات اور جوابات کو واضح طور پر ماڈل کی تربیت کے لیے استعمال نہیں کیا گیا تھا:
| تہہ (Layer) | پکڑی گئی PII | پکڑنے کی شرح |
|---|---|---|
| صرف Regex | 205 / 670 | 30.6 % |
| صرف ML | 516 / 670 | 77.0 % |
| دونوں (پروڈکشن) | 625 / 670 | 93.3 % |
صرف regex تین چوتھائی شناخت کنندگان (identifiers) کو چھوڑ دیتا ہے کیونکہ حقیقی تحریر میں زیادہ تر شناخت کنندگان منظم (structured) نہیں ہوتے۔ صرف ML ان 16 فیصد پوائنٹس کو چھوڑ دیتا ہے جنہیں regex کی تہہ پکڑ لیتی — وہ چیزیں جو خالصتاً اپنی شکل کی وجہ سے پہچانی جاتی ہیں (ایک کریڈٹ کارڈ کریڈٹ کارڈ کی طرح لگتا ہے؛ ماڈل کے پاس اس میں شامل کرنے کے لیے کوئی اضافی سگنل نہیں ہوتا)۔ یہ دونوں مل کر وہ سب کچھ کور کرتے ہیں جو ان میں سے کوئی بھی اکیلے نہیں کر سکتا۔
گہرائی سے جائزہ لینے پر کہ ہر تہہ کہاں فیصلہ کن ثابت ہوتی ہے: اسی ڈیٹا سیٹ میں، 16 ٹیسٹ ویلیوز صرف regex کے ذریعے پکڑی گئیں (ای میلز، IPs، مالیاتی اکاؤنٹس، اسٹرکچرڈ IDs) اور 327 صرف ML کے ذریعے پکڑی گئیں (نام، سیاق و سباق پر مبنی شناخت کنندگان، کثیر لسانی جملے)۔
چھوٹا، ذہین، تیز — اور ہر جگہ چلتا ہے
ہمیں فلٹر کو آلے پر چلانا تھا، جو کہ ایک انجینئرنگ چیلنج تھا۔
اسے چھوٹا ہونا چاہیے کیونکہ ہماری ایپ کئی سسٹمز پر چلتی ہے: براؤزر ایکسٹینشن، macOS ایپ، iOS ایپ، Android ایپ، یا Windows اور Linux کے اندر۔ بنڈل فی ماڈل تقریباً 113 MB ہے۔ دو ماڈلز ہیں — ایک عام ذاتی ڈیٹا کے لیے، ایک محفوظ صحت کی معلومات کے لیے — اور Safe Harbor موڈ دونوں کو متوازی طور پر چلاتا ہے۔ ان میں سے، ایک لو-اینڈ Android آلہ سب سے کم کارکردگی والا ہے، پھر بھی ہمارا سسٹم ٹھیک کام کرتا ہے۔
اسے ذہین ہونا چاہیے کیونکہ غلط منفی (false negatives) ریموٹ LLM کو حقیقی ڈیٹا لیک کر دیتے ہیں اور غلط مثبت (false positives) گفتگو کو خراب کر دیتے ہیں۔ ناموں کو چھپانا ضروری ہے؛ ضمیروں (pronouns) کو نہیں۔ فارورڈ شدہ تھریڈ میں ڈاکٹر کا ای میل چھپایا جانا چاہیے؛ [email protected] فوٹر شاید نہیں ہونا چاہیے۔
اسے تیز ہونا چاہیے کیونکہ یہ صارف کے بھیجے گئے یا موصول ہونے والے ہر پیغام کے راستے میں براہ راست بیٹھتا ہے۔ ہم نے ایک سنگل CPU تھریڈ پر راؤنڈ ٹرپ اوور ہیڈ 200 ms سے کم ناپا، جس میں زیادہ تر ٹوکنائزیشن تھی۔ WebGPU اور Apple کے Neural Engine پر یہ LLM کال کی نیٹ ورک لیٹنسی کے مقابلے میں بہت معمولی ہے۔
اسے متعدد رن ٹائمز میں چلنا چاہیے کیونکہ Caiioo ملٹی پلیٹ فارم ہے۔ یہی سسٹم Chrome ایکسٹینشنز، macOS اور iOS، Android، اور Windows اور Linux پر چلتا ہے۔ ایک ڈیٹیکشن ماڈل، ایک regex لائبریری، ایک مرجر، ایک پالیسی — ہر اس جگہ پر یکساں برتاؤ جہاں Caiioo چلتا ہے۔
اسکورز (The scores)
ٹیسٹنگ اور ٹریننگ کے کئی مراحل کے بعد، ہم نے اپنے ماڈلز کے 16ویں ورژن پر اتفاق کیا۔ ذیل میں تین بینچ مارکس (benchmarks) دیے گئے ہیں، جن میں سے ہر ایک مختلف پہلو کی پیمائش کرتا ہے۔
ہمارا اپنا ٹیسٹ سیٹ، 150 سوالات جو ماڈل نے پہلے کبھی نہیں دیکھے
عوامی بینچ مارکس کے خلاف ٹیسٹ کرنے سے پہلے، ہم نے اپنے Personal Data فلٹر کو ایک اندرونی ٹیسٹ سیٹ پر چلایا جسے ہم نے جان بوجھ کر ٹریننگ ڈیٹا سے باہر رکھا تھا — تاکہ ڈیٹیکٹر نے ان میں سے کوئی بھی سوال پہلے کبھی نہ دیکھا ہو۔ 150 سوالات کو چار گروپس میں تقسیم کیا گیا (code snippets، دستاویز کی نثر، جان بوجھ کر غیر مانوس جملے، اور 10 غیر انگریزی زبانیں)، اس کے علاوہ ایک "منفی" گروپ جس میں کوئی نجی ڈیٹا موجود نہیں ہے (یہ چیک کرنے کے لیے کہ ہم ضرورت سے زیادہ ڈیٹا حذف تو نہیں کر رہے)۔ مشترکہ 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 ججز عام طور پر فراخ دل ہوتے ہیں)۔ دوسرے سسٹمز کے خلاف براہ راست موازنہ کرنے والے اعداد و شمار کے لیے، نیچے دیا گیا آمنے سامنے (head-to-head) والا حصہ دیکھیں۔
PrivacyBenchHIPAA — صحت کی دیکھ بھال کے 40 سوالات
ہر سوال محفوظ شدہ صحت کی معلومات (PHI) کی فہرست دیتا ہے جسے حذف کیا جانا چاہیے (نام، میڈیکل ریکارڈ نمبر وغیرہ) اور وہ اشارے جنہیں برقرار رکھا جانا چاہیے (تاریخیں، جغرافیہ، 90 سال سے کم عمر — HIPAA Limited Data Set کا اصول)۔ گریڈر دونوں سمتوں میں چیک کرتا ہے: کیا ہم نے وہ سب ہٹا دیا جو ہمیں ہٹانا چاہیے تھا، اور کیا ہم نے اسے چھوڑ دیا جسے ہمیں چھوڑنا چاہیے تھا؟
| موڈ (Mode) | PHI حذف شدہ | برقرار رکھا گیا |
|---|---|---|
| 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، اور دونوں ایک ساتھ۔ یہ ہمیں بتاتا ہے کہ کون سی ٹیکنالوجی کس قسم کے شناخت کنندہ (identifier) کو پکڑ رہی ہے — اور کہاں ایک کو دوسرے کی ضرورت ہے۔ تازہ ترین رن، 2026-05-20:
تینوں فلٹر موڈز کا خلاصہ
| موڈ (Mode) | مشترکہ ریکال (Recall) | درستگی (Precision) | F2 | نمونے |
|---|---|---|---|---|
| Personal Data filter | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA filter — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA filter — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
ان اعداد و شمار میں URLs شامل نہیں ہیں، جنہیں ہم جان بوجھ کر چھوڑ دیتے ہیں — کسی URL کو ختم کرنے سے بعد کے اقدامات جیسے "یہ لنک کھولیں" یا "وہ صفحہ حاصل کریں" متاثر ہوں گے۔ اس بارے میں مزید تفصیل نیچے ورک فلو والے حصے میں ہے۔
زمرہ وار جدولوں سے پہلے کی بڑی تصویر: ہر موڈ میں، وہ شناخت کنندگان جو حقیقت میں کسی شخص کی شناخت کرتے ہیں، 100% یا اس کے قریب پکڑے جاتے ہیں۔ نام، ای میلز، فون نمبرز، ڈاک کے پتے، سرکاری IDs، بائیومیٹرک IDs، درست جغرافیائی محل وقوع، میڈیکل ریکارڈ نمبرز، تاریخ پیدائش، سوشل سیکیورٹی نمبرز — ہر نمونے، ہر ٹیسٹ پر پکڑے گئے۔ وہ زمرے جہاں ہم 100% سے نیچے گرتے ہیں وہ قابل پیش گوئی ہیں: ڈیوائس IDs (حقیقی متن میں فارمیٹس کی بہت بڑی قسم)، متفرق ادارہ جاتی IDs (لائلٹی نمبرز، ملازم IDs — وہی مسئلہ)، اور تصاویر (صرف متن والا فلٹر تصویر کے اندر نہیں دیکھ سکتا)۔ ان میں سے کوئی بھی وہ شناخت کنندہ نہیں ہے جیسے "چارٹ پر نام" یا "ڈرافٹ میں ای میل" جو حقیقت میں ڈیٹا لیک ہونے کے لیے اہم ہیں۔ زیادہ خطرے والے زمرے قابل اعتماد ہیں۔
Personal Data filter
مشترکہ ریکال (بہترین پہلے)، پھر رسک ٹائر (T1 = سب سے زیادہ حساس) کے لحاظ سے ترتیب دیا گیا۔
| زمرہ (Category) | ٹائر | Regex ریکال | ML ریکال (خام) | مشترکہ ریکال | 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 ماڈل ہی انہیں پکڑ سکتا ہے۔ ای میلز، فون نمبرز، IPs، سرکاری IDs، بائیومیٹرک IDs، اور درست جغرافیائی محل وقوع صرف regex کے تحت 100% اسکور کرتے ہیں — یہ وہ ظاہری فارمیٹس ہیں جو ML ماڈل کو آسانی سے مل جاتے ہیں۔ آن لائن ہینڈلز، گاڑیوں کے IDs، اور تصدیقی راز (authentication secrets) ملے جلے ہیں: regex معیاری شکلوں کو پکڑتا ہے، ML باقی کو۔ ہر زمرے میں، مشترکہ ریکال اس واحد تہہ سے ملتی ہے یا اس سے بہتر ہوتی ہے جو زیادہ مضبوط ہو۔
ڈیوائس IDs اور متفرق ادارہ جاتی IDs وہ زمرے ہیں جو 100% سے نیچے ہیں، اور ہمیں معلوم ہے کیوں: حقیقی متن میں ان کے فارمیٹس کی سب سے زیادہ اقسام ہوتی ہیں۔ ہم ان زمروں کے بارے میں ایماندار رہنا پسند کریں گے جہاں ریکال کم ہے بجائے اس کے کہ یہ دکھاوا کریں کہ فلٹر ہر جگہ بہترین ہے۔
HIPAA filter — Limited Data Set submode
Limited Data Set سب موڈ ڈیزائن کے مطابق تاریخوں، جغرافیہ اور 89 سال یا اس سے کم عمر کو محفوظ رکھتا ہے — یہ وہ اشارے ہیں جنہیں HIPAA کسی تنظیم کو جائز طبی تحقیق اور آپریشنز کے لیے رکھنے کی اجازت دیتا ہے۔
| زمرہ (Category) | ٹائر | Regex ریکال | ML ریکال (خام) | مشترکہ ریکال | 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 filter — Safe Harbor submode
Safe Harbor وہ سب کچھ ہٹا دیتا ہے جسے Limited Data Set سب موڈ نے محفوظ رکھا ہوتا — تاریخیں، 89 سال سے زیادہ عمر، جغرافیہ۔ سخت ترین کوریج حاصل کرنے کے لیے، یہ دونوں فلٹر ماڈلز کو متوازی طور پر چلاتا ہے: HIPAA کے لیے مخصوص اور عام ذاتی ڈیٹا والا۔
| زمرہ (Category) | ٹائر | Regex ریکال | ML ریکال (خام) | مشترکہ ریکال | 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" جیسی عددی حد پر شک کرے۔ ایک متعین (deterministic) اصول ML ماڈل کو وہی اصول سکھانے سے زیادہ قابل اعتماد ہے۔
تمام زمروں میں مجموعی اعداد و شمار
سب کو جمع کرنے پر: مکمل پائپ لائن (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 کے ساتھ جو فی پیغام سیکنڈز لیتے ہیں اور جنہیں نیٹ ورک راؤنڈ ٹرپ کی ضرورت ہوتی ہے۔ ہم نے اس کلاس کے ہر سسٹم کو انہی ٹیسٹ سیٹس پر، انہی مماثلت کے اصولوں کا استعمال کرتے ہوئے چلایا۔ سب کے لیے ایک ہی معیار۔
ہم عصر کلاس:
- 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) — ان چیزوں کو ماسک کرنا جو حقیقت میں نجی ڈیٹا نہیں تھیں۔ ضرورت سے زیادہ حذف کرنا پرائیویسی کا نقصان نہیں ہے، بلکہ یہ استعمال کی لاگت (usability cost) ہے۔ بہت زیادہ چیزوں کو ماسک کر دیں تو LLM کی استدلال کی صلاحیت خراب ہو جاتی ہے، اور واپس ملنے والا جواب ناقص ہوتا ہے۔ Caiioo نے ٹیسٹ سیٹس میں 1–24 بار غیر ضروری طور پر ماسک کیا۔ Presidio: 10–51۔ NVIDIA کا GLiNER: صرف HIPAA ٹیسٹوں پر 31–64۔ درستگی (Precision) اتنی ہی اہم ہے جتنی ریکال، جب مقصد کم سے کم افشا کے ساتھ بہترین ممکنہ جواب حاصل کرنا ہو۔
کیا صرف ایک فرنٹیر LLM کو فلٹر کے طور پر استعمال کرنا کیسا ہے؟
وہ کر سکتے ہیں — اور خام ریکال پر، وہ جیت جاتے ہیں۔ بڑے عام مقصد کے LLMs (Llama 3.1 8B، Gemma 4، Qwen 3.5 9B، اور اسی طرح کے)، جو کلاؤڈ یا مقامی طور پر چل رہے ہوں، کثیر لسانی سمیت ہر ٹیسٹ میں 95–100% اسکور کر سکتے ہیں۔ یہ ان صارفین کے لیے ایک حقیقی آپشن ہے جنہیں زیادہ سے زیادہ ریکال کی ضرورت ہے اور وہ اس کی قیمت ادا کرنے کے لیے تیار ہیں۔
تاہم، اس کی خامیاں بھی حقیقی ہیں:
- یہ سست ہے۔ ملی سیکنڈز کے بجائے فی پیغام سیکنڈز۔ فلٹر صارف کے بھیجے گئے ہر پیغام کے سامنے ہوتا ہے۔
- یا تو پیغام صارف کی مشین سے باہر جاتا ہے، یا ماڈل۔ کلاؤڈ میں فلٹر کرنے کے لیے، پیغام کو وہاں جانا پڑتا ہے — جو مقصد کو ہی ختم کر دیتا ہے۔ آن ڈیوائس فلٹر کرنے کے لیے 1–17 GB کا ماڈل ڈاؤن لوڈ کرنے کی ضرورت ہوتی ہے۔
- اسے دھوکہ دیا جا سکتا ہے۔ ایک تخلیقی (generative) ماڈل کو پیغام کے درمیان میں حذف نہ کرنے پر آمادہ کیا جا سکتا ہے (ایک "prompt injection" حملہ)۔ ہمارے جیسے چھوٹے کلاسیفائر کو نہیں کیا جا سکتا۔
- وہی ان پٹ، مختلف آؤٹ پٹ۔ تخلیقی ماڈل ہمیشہ دو بار ایک ہی جواب نہیں دیتے۔ یہ راؤنڈ ٹرپ کو خراب کر دیتا ہے — جاتے ہوئے ماسک کرنا اور واپسی پر ان ماسک کرنا اس بات پر منحصر ہے کہ وہی اصل قدر ہمیشہ اسی فرضی قدر سے جڑی رہے۔
Caiioo اس تجارتی توازن (tradeoff) کے دوسرے رخ کے لیے بنایا گیا ہے: ایک ننھا، قابل پیش گوئی، سب سیکنڈ فلٹر جو صارف کے سینڈ بٹن دبانے سے پہلے کمپوزر میں چلتا ہے، اور جو گفتگو کے اندر ایک ہی اصل قدر کے لیے ہمیشہ وہی فرضی قدر پیدا کرتا ہے، تاکہ راؤنڈ ٹرپ مربوط رہے۔ اوپر دیا گیا ہم عصر کلاس کا جدول اس قسم کے استعمال کے کیس کے لیے بالکل درست موازنہ ہے۔
اصل حقیقت عمل سے ظاہر ہوتی ہے
Benchmarks صرف ایک نقطہ آغاز ہیں، منزل نہیں۔ یہ فلٹر Caiioo کے نئے فیچر: pseudonymizer میں شامل ہے — وہ جزو جو درحقیقت کمپوزر اور ماڈل کے درمیان کام کرتا ہے۔
جب صارف سینڈ (send) کا بٹن دباتا ہے تو یہ عمل ہوتا ہے:
- Detect. سب سے پہلے regex لیئر چلتی ہے — یہ حتمی (deterministic) اور مائیکرو سیکنڈ کی رفتار سے تیز ہے۔ اس کے بعد جو کچھ بچتا ہے اس پر ML ماڈل چلتا ہے۔ اگر دونوں لیئرز متن کے ایک ہی حصے پر اوورلیپ کریں، تو ہم ایک سادہ اصول استعمال کرتے ہیں: ظاہری فارمیٹس پر regex غالب رہتا ہے، اور سیاق و سباق (context) پر ML غالب رہتا ہے۔
- Tag self vs. other. Caiioo ان شناخت کنندگان (identifiers) کو الگ کرتا ہے جو صارف سے متعلق ہیں ان سے جو دوسرے لوگوں سے متعلق ہیں۔ صارف کسی ایک کو، یا دونوں کو حذف (redact) کرنے کا انتخاب کر سکتا ہے۔ وہ نام جو صارف نے اپنی ذاتی ڈکشنری میں شامل کیے ہیں وہ ہمیشہ "self" شمار ہوتے ہیں۔
- Substitute. ہر اصل ویلیو کو ایک مستقل اور اسٹائل سے مطابقت رکھنے والا فرضی نام (pseudonym) دے دیا جاتا ہے۔ "Sarah Goldberg" بن جاتی ہے "Maya Hartwell" — اور پوری گفتگو کے دوران "Maya Hartwell" ہی رہتی ہے، تاکہ اس شخص کے بارے میں ماڈل کی منطق (reasoning) مختلف مراحل میں بکھر نہ جائے۔ اصل سے فرضی ناموں کا ایک لک اپ ٹیبل صارف کے ڈیوائس پر محفوظ رکھا جاتا ہے، جو پلیٹ فارم کی کی-چین (keychain) سے حاصل کردہ کلید کے ذریعے انکرپٹڈ ہوتا ہے۔
- Send. ماڈل کو مکمل طور پر ایک فرضی پیغام موصول ہوتا ہے۔ کوئی بھی اصل شناخت کنندہ کبھی نیٹ ورک پار نہیں کرتا، اور ہمارا آڈٹ لاگ صرف تعداد ریکارڈ کرتا ہے — کبھی بھی اصل ویلیوز کو محفوظ نہیں کرتا۔
- Restore. جیسے ہی اسٹریمنگ رسپانس موصول ہوتا ہے، اسے واپس اصل پر میپ کر دیا جاتا ہے۔ ماڈل کے جواب میں موجود "Maya Hartwell" اسکرین پر پہنچنے سے پہلے "Sarah Goldberg" بن جاتی ہے، جسے ایک چھوٹے گلو پِل (glow pill) کے ساتھ دکھایا جاتا ہے تاکہ صارف ایک نظر میں دیکھ سکے کہ کیا چیز محفوظ کی گئی تھی۔
- Restore tool arguments too. اگر ماڈل کسی ٹول کو کال کرتا ہے — جیسے ای میل بھیجنا، ٹکٹ فائل کرنا، یا کسی دستاویز میں لکھنا — اور اس کے آرگیومنٹس میں فرضی نام شامل ہوں، تو ہم ٹول چلنے سے پہلے اصل ویلیوز کو واپس تبدیل کر دیتے ہیں۔ ماڈل فرضی ناموں پر غور و فکر کرتا ہے؛ جبکہ ایکشن اصل ویلیو پر لیا جاتا ہے۔
فلٹر کو اس سے کوئی فرق نہیں پڑتا کہ کون سی AI سروس استعمال ہو رہی ہے۔ یہ پیغام ماڈل تک پہنچنے سے پہلے ہی چل جاتا ہے، اس لیے OpenRouter، Anthropic، Google، OpenAI، اور مقامی Ollama سب کو ایک جیسا ماسک شدہ ڈیٹا (payload) ملتا ہے۔ کسی نئے فراہم کنندہ (provider) کو شامل کرنے سے پرائیویسی میں کوئی رخنہ پیدا نہیں ہوتا۔
یہ کس کی حفاظت کرتا ہے
صارف۔ صارف کا نام، ای میل، پتہ، فون، IP، اور بائیومیٹرک شناخت کنندگان — وہ چیزیں جو مجموعی طور پر کسی شخص کی شناخت کرتی ہیں — فلٹر آن ہونے پر کبھی بھی آلے سے باہر نہیں جاتیں۔
وہ لوگ جن کے بارے میں صارف بات کرتا ہے۔ زیادہ تر پرائیویسی ٹولز ٹائپ کرنے والے شخص پر توجہ مرکوز کرتے ہیں، لیکن وہ جس چیز کو نظر انداز کرتے ہیں وہ 'سوشل کنٹریکٹ' ہے — یہ حقیقت کہ ہم دوسروں کے ساتھ ساتھ اپنے آپ کے لیے بھی ذمہ دار ہیں۔ LLM کو یہ جمع کروانا کہ "براہ کرم مسٹر سانڈرز کے طرز عمل کا نااہلی کے لیے تجزیہ کریں"، جہاں اسے سسٹم لاگز میں غیر معینہ مدت کے لیے ریکارڈ کیا جا سکتا ہے، غیر ذمہ دارانہ (اور ممکنہ طور پر ہتک آمیز) ہے۔ کسی ایسی Google Sheet کے لیے LLM سے مدد مانگنا جس میں 1,000 کاروباری رابطے ہوں، ان سب کو ڈیٹا برقرار رکھنے والے نظام میں ڈال دیتا ہے۔ Caiioo کا فلٹر تیسرے فریقوں کا بھی احاطہ کرتا ہے: وہ کلائنٹ جس کے لیے معاہدہ تیار کیا جا رہا ہے، وہ مریض جس کے ریکارڈ پر غور کیا جا رہا ہے، وہ ساتھی جس کا ای میل سیاق و سباق میں پیسٹ کیا گیا تھا۔ انہوں نے ریموٹ LLM کو اپنے شناخت کنندگان دیکھنے کی رضامندی نہیں دی تھی۔ فلٹر ڈیفالٹ طور پر اس کا احترام کرتا ہے؛ اگر ورک فلو کی ضرورت ہو تو صارف "صرف خود" یا "صرف دوسرے" پر سوئچ کر سکتا ہے۔
ادارے — کاروبار، ہسپتال، فرمیں۔ اکاؤنٹ نمبر، لائسنس نمبر، میڈیکل ریکارڈ نمبر، مالیاتی روٹنگ کی تفصیلات، اندرونی IDs، API کلیدیں، کسٹمر لسٹیں۔ ایک کاروبار کی ڈیٹا کو کم سے کم کرنے میں وہی دلچسپی ہوتی ہے جو ایک شخص کی ہوتی ہے۔ Caiioo کا استعمال کرتے ہوئے ڈسچارج نوٹ تیار کرنے والا طبی ماہر مریض کا میڈیکل ریکارڈ نمبر OpenAI کو نہیں بھیج رہا۔ ایک وکیل کلائنٹ کا اکاؤنٹ نمبر Anthropic کو نہیں بھیج رہا۔ ایک سپورٹ انجینئر کسٹمر کے لاگ سے API کلید Google کو نہیں بھیج رہا۔ فلٹر یہ نہیں پوچھتا کہ شناخت کنندہ کسی شخص کا ہے یا کسی ادارے کا — یہ بس اسے آلے پر رکھتا ہے۔
زیادہ سے زیادہ افادیت، کم سے کم نمائش
پورا مقصد یہ ہے کہ صارف کو فلٹر کا احساس نہیں ہونا چاہیے۔
زیادہ تر پرائیویسی ٹولز ایک انتخاب پر مجبور کرتے ہیں: جارحانہ طور پر ڈیٹا چھپائیں اور ماڈل کے جواب کو خراب ہوتے دیکھیں، یا پرامپٹ کو قابل استعمال رکھیں اور پرائیویسی کے وعدے کو ختم ہوتے دیکھیں۔ ہم نے اس سمجھوتے کو مسترد کر دیا۔ ماڈل کو اب بھی ایک مکمل پرامپٹ ملتا ہے — وہ ایک نام، ایک جگہ، ایک تاریخ، ایک میڈیکل ریکارڈ نمبر دیکھتا ہے، سب کچھ درست گرامر کے ساتھ۔ وہ صرف فرضی چیزیں دیکھتا ہے۔ اس کی منطق وہی رہتی ہے؛ صرف سٹرنگز کو صاف کیا جاتا ہے۔
مستحکم متبادل (Stable substitution) ہی اسے ممکن بناتا ہے۔ چونکہ ایک ہی حقیقی قدر ہمیشہ ایک گفتگو کے دوران ایک ہی فرضی قدر سے جڑتی ہے — صارف کے پیغام میں، ٹول کے نتیجے میں جو اس نام کا حوالہ دیتا ہے، ماڈل کے پہلے جواب میں جس نے اس کا ذکر کیا تھا — اس لیے ماڈل کے پاس غور کرنے کے لیے ایک مربوط شخص، جگہ یا چیز ہوتی ہے۔ کثیر مرحلہ گفتگو (Multi-turn conversations) گڈ مڈ نہیں ہوتی۔ ٹول کالز نہیں ٹوٹتیں۔ ذیلی ایجنٹس (Sub-agents) اصل گفتگو کا نقشہ وراثت میں پاتے ہیں اور پورے کام کے دوران مستقل مزاج رہتے ہیں۔
صارف جو آؤٹ پٹ دیکھتا ہے وہ حقیقی گفتگو ہوتی ہے۔ فراہم کنندہ جو ڈیٹا دیکھتا ہے وہ ایک مربوط افسانہ ہوتا ہے۔ کام ان دونوں نظریات کے درمیان فرق میں ہوتا ہے، اور مقصد — واحد مقصد — اس فرق کو پوشیدہ بنانا ہے۔
ایک پرائیویسی فلٹر جو راستے میں رکاوٹ بنے اسے بند کر دیا جائے گا۔ ایک پرائیویسی فلٹر جو ورک فلو میں گھل مل جائے وہی بھیجنے کے قابل ہے۔
یہ وہ معیار ہے جس پر ہم نے اسے بنایا ہے۔