هذه ترجمة آلية للمستند الأصلي باللغة الإنجليزية. في حال وجود أي تعارض بين هذه الترجمة والنسخة الإنجليزية الأصلية، تُعتمد النسخة الإنجليزية. اقرأ النسخة الإنجليزية الأصلية
أداة إخفاء الهوية على الجهاز: البناء والقياس المرجعي
2026-05-22 · Caiioo Team
أردنا حل مشكلة الخصوصية المتمثلة في تدريب أنظمة الذكاء الاصطناعي على معلومات تحديد الهوية الشخصية الحقيقية والاحتفاظ بها. سياسات واتفاقيات "عدم الاحتفاظ بالبيانات" تقلل من المخاطر، لكنها مليئة بالاستثناءات. فهي تقول أساساً: "لن نخزن أي من أوامرك أو مخرجاتك باستثناء: (أدخل قائمة طويلة من الاستثناءات هنا: الأغراض الأمنية، المراقبة الحكومية، الاحتجاز القانوني، تطوير المنتجات، سجلات الأخطاء، تحسين الخدمات...)"
لحل هذه المشكلة، قمنا ببناء فلتر للبيانات الشخصية يعمل على جهاز المستخدم نفسه، يرى الرسالة قبل مغادرتها للجهاز، ويعيد نفس الإجابة التي كان المستخدم سيتلقاها لو تمت كتابتها بدون فلتر على الإطلاق.
لذا قمنا ببناء واحد. سيتضمن الإصدار القادم من Caiioo أداة Pseudonymizer. يمكن الوصول إليها من خلال أيقونة الدرع في دردشة الوكيل وكذلك الإعدادات.
توضح هذه الورقة البيضاء المنطق، والهندسة المعمارية، وعملية التقييم، ومبادئ التصميم وراء نظام تصفية الخصوصية الخاص بنا.
ما نسعى لتحقيقه
حماية الخصوصية العامة من خلال تقليل البيانات. عندما يتحدث المستخدم مع نموذج عن بُعد، لا يحتاج النموذج إلى اسم حقيقي، أو عنوان سكن، أو بريد إلكتروني حقيقي، أو رقم هاتف العميل للإجابة على سؤال المستخدم. إنه يحتاج إلى سياق السؤال، ويجب أن يبدو كسؤال حقيقي حتى لا يتجاهل نموذج LLM الاستعلام باعتباره مجرد اختبار. لذلك، يقوم الفلتر بتجريد المعرفات الحقيقية من البيانات المرسلة إلى AI ويعيد دمج القيم الحقيقية في طريق العودة. يرى النموذج أسماء ومعرفات اصطناعية؛ بينما يرى المستخدم المحادثة الحقيقية.
المساعدة في الامتثال لمعايير HIPAA. يستهدف الوضع الثاني المعرفات الـ 18 في قاعدة الملاذ الآمن (Safe Harbor) الخاصة بـ HIPAA (المادة 164.514) ومتغير مجموعة البيانات المحدودة (Limited Data Set) الأكثر مرونة. يمكن للطبيب، أو إداري الرعاية الصحية، أو أي شخص يعمل على سير عمل مغطى، التحدث إلى نموذج عام حول حالات حقيقية دون إرسال معلومات صحية محمية إلى AI. نحن لسنا مسؤول الامتثال للجهة المغطاة — ولكن يمكننا أن نكون الطبقة التي تمنع معلومات PHI من مغادرة الكمبيوتر المحمول في المقام الأول. توفر تقييماتنا معايير قابلة للقياس يمكن للمؤسسات استخدامها لتقييم مدى ملاءمة الفلتر لمعايير الامتثال والخصوصية الخاصة بها. إن جميع تدابير الخصوصية والأمن هي قرارات تقديرية تقع على عاتق المستخدم أو الكيان المستخدم.
لقد اخترنا كليهما لأن الهندسة التقنية هي نفسها، وحالة استخدام PHI هي في الواقع أسهل تقنياً بسبب استخدامها لكيانات مسماة متميزة، والتي يسهل حجبها مقارنة بالبيانات الأكثر عمومية في فئة البيانات الشخصية. كما يساعد فلترة HIPAA حقيقة أنها تكون بشكل عام باللغة الإنجليزية أو الإسبانية. نحن نكتشف المعرفات، ونستبدلها بأسماء مستعارة مستقرة ومعرفات بديلة بنفس التنسيق، ونستعيدها في طريق العودة، ولا نقوم أبداً بتسجيل القيم الحقيقية. تظل الخريطة بين المعلومات الاصطناعية والمعلومات الحقيقية على جهاز المستخدم فقط، بحيث يمكن للمستخدم قراءة معلومات حقيقية في ردود الوكيل. إن قائمة الفئات وبوابة السياسة هما ما يتغير بين الأوضاع.
لماذا نستخدم regex بالإضافة إلى التعلم الآلي، وليس أحدهما فقط
هناك تقنيتان أساسيتان للتصفية في أداة إخفاء الهوية الخاصة بنا: لغة حتمية للتعرف على الأنماط تسمى regex، ونماذج تعلم آلي مدربة.
تعتبر regex لا تُهزم في تنسيقات الأسطح. فعنوان البريد الإلكتروني له شكل محدد ([email protected]). وكذلك عنوان IP، وبطاقة الائتمان، ورقم IBAN، ورقم VIN، ورقم SSN (XXX-XX-XXXX)، ومفتاح API. إذا كان التنسيق موثوقاً، فإن regex تلتقطه بشكل حتمي في كل مرة، دون تحميل للنموذج وبدون تكلفة استدلال.
ومع ذلك، فإن regex لا فائدة منها في السياق. فعبارة "مخطط Sarah من الثلاثاء الماضي" تحتوي على شخص وتاريخ، ولكن لا يمكن تمييز أي منهما من خلال التنسيق وحده. وعبارة "المريض في 14 Elm" تحتوي على عنوان يتشابه مع آلاف العبارات التي ليست عناوين. وعبارة "رقم MRN الخاص بهم هو 7741032" تحتاج إلى الكلمات المحيطة بالرقم لتعطي أي معنى.
يتولى نموذج لغوي صغير مضبوط بدقة التعامل مع السياق — نموذجنا عبارة عن مشفر (encoder) بـ 110 مليون معلمة مدرب خصيصاً ومستخلص من نموذج لغوي صغير متعدد اللغات — . إنه يقرأ الجملة، وليس السلسلة الفرعية، وهو صغير بما يكفي ليعمل بسرعة فائقة على الجهاز، حتى على الهاتف المحمول.
توضح المعايير القياسية نقاط القوة المتكاملة للطبقتين. لقد قمنا بقياس أداء الطبقتين بشكل منفصل للتأكد من أن كل واحدة منهما تؤدي دورها بالفعل. في مجموعة أسئلة PrivacyBench-PD المكونة من 150 سؤالاً، حيث لم تُستخدم الأسئلة والأجوبة صراحةً لتدريب النموذج:
| الطبقة | معلومات PII التي تم التقاطها | معدل الالتقاط |
|---|---|---|
| Regex فقط | 205 / 670 | 30.6 % |
| ML فقط | 516 / 670 | 77.0 % |
| كلاهما (الإنتاج) | 625 / 670 | 93.3 % |
تفتقد regex وحدها ثلاثة أرباع المعرفات لأن معظم المعرفات في النصوص الواقعية ليست منظمة. ويفتقد ML وحده 16 نقطة مئوية كانت طبقة regex ستلتقطها — وهي الأشياء التي تعتمد بحتة على شكلها (بطاقة الائتمان تبدو كبطاقة ائتمان؛ وليس لدى النموذج أي إشارة إضافية ليضيفها). ومعاً، يغطيان ما لا يستطيع أي منهما تغطيته بمفرده.
بالنظر بعمق إلى الحالات التي تكون فيها كل طبقة حاسمة: عبر نفس المجموعة، تم التقاط 16 قيمة اختبار بواسطة regex فقط (رسائل البريد الإلكتروني، وعناوين IP، والحسابات المالية، والمعرفات المنظمة) و تم التقاط 327 قيمة بواسطة ML فقط (الأسماء، والمعرفات السياقية، والصياغات متعددة اللغات).
صغير، ذكي، سريع — ويعمل في كل مكان
كان علينا جعل الفلتر يعمل على الجهاز، وهو ما مثل تحدياً هندسياً.
يجب أن يكون صغيراً لأن تطبيقنا يعمل على الجهاز في العديد من الأنظمة: داخل إضافة Chrome، تطبيق macOS، تطبيق iOS، تطبيق Android، أو Windows و Linux. تبلغ الحزمة حوالي 113 ميجابايت لكل نموذج. هناك نموذجان — واحد للبيانات الشخصية العامة، وواحد للمعلومات الصحية المحمية — ووضع Safe Harbor يشغل كلاهما بالتوازي. من بين هذه الأنظمة، يعد جهاز Android منخفض المواصفات هو الأقل أداءً، ومع ذلك يعمل نظامنا بشكل جيد.
يجب أن يكون ذكياً لأن النتائج السلبية الخاطئة تسرب بيانات حقيقية إلى LLM عن بُعد، والنتائج الإيجابية الخاطئة تفسد المحادثة. يجب حجب الأسماء؛ بينما يجب عدم حجب الضمائر. يجب حجب بريد الطبيب الإلكتروني في موضوع محول؛ بينما تذييل [email protected] ربما لا ينبغي حجبه.
يجب أن يكون سريعاً لأنه يقع مباشرة في طريق كل رسالة يرسلها المستخدم أو يستقبلها. لقد قمنا بقياس التأخير في الرحلة الكاملة بأقل من 200 مللي ثانية على خيط معالجة واحد (CPU thread)، ومعظمها كان لعملية التجزئة (tokenization). على WebGPU وعلى Apple's Neural Engine، يكون التأخير ضئيلاً جداً مقارنة بتأخير الشبكة لاستدعاء LLM نفسه.
يجب أن يعمل في بيئات تشغيل متعددة لأن Caiioo متعدد المنصات. يعمل نفس النظام في إضافات Chrome، و macOS و iOS، و Android، وعلى Windows و Linux. نموذج كشف واحد، مكتبة regex واحدة، مدمج واحد، سياسة واحدة — سلوك متطابق عبر كل واجهة يعمل عليها Caiioo.
النتائج
بعد جولات من الاختبار والتدريب، استقررنا على الإصدار السادس عشر من نماذجنا. فيما يلي ثلاثة اختبارات قياسية (benchmarks)، كل منها يقيس جانباً مختلفاً.
مجموعة الاختبار الخاصة بنا، 150 سؤالاً لم يسبق للنموذج رؤيتها
قبل الاختبار مقابل المعايير العامة، قمنا بتشغيل فلتر Personal Data الخاص بنا مقابل مجموعة اختبار داخلية احتفظنا بها عمداً خارج بيانات التدريب — بحيث لم يسبق للكاشف رؤية أي من هذه الأسئلة من قبل. 150 سؤالاً مقسمة إلى أربع مجموعات (مقتطفات برمجية، نصوص وثائق، صياغات غير مألوفة مقصودة، و10 لغات غير الإنجليزية)، بالإضافة إلى مجموعة "سلبية" لا تحتوي على أي بيانات خاصة على الإطلاق (اختبار سلامة للتأكد من أننا لا نفرط في الحجب). مسار العمل المشترك بين regex و ML:
| الاختبار الفرعي | ما تم ضبطه | المعدل |
|---|---|---|
| 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 % |
(المجموعة السلبية لم تحتوي على بيانات خاصة للعثور عليها. قام الفلتر بحجب شيء واحد لم يكن ينبغي حجبه — وهو ما يتوافق مع أرقام الدقة المذكورة أدناه.)
نظام التقييم صارم: يجب أن تختفي كل قطعة متوقعة من البيانات الخاصة تماماً من المخرجات المحجوبة حتى يحصل السؤال على درجة. لا يوجد رصيد جزئي، ولا يوجد "قريب بما يكفي". هذا أقسى من الاختبارات القياسية التي تطلب من نموذج LLM آخر أن يكون هو الحكم (حيث تميل أحكام LLM إلى أن تكون سخية). للحصول على أرقام قابلة للمقارنة مباشرة مع الأنظمة الأخرى، راجع قسم المقارنة المباشرة أدناه.
PrivacyBenchHIPAA — 40 سؤالاً في الرعاية الصحية
يسرد كل سؤال معلومات صحية محمية يجب حجبها (الأسماء، أرقام السجلات الطبية، إلخ) وإشارات يجب الاحتفاظ بها (التواريخ، الجغرافيا، العمر إذا كان أقل من 90 — قاعدة HIPAA Limited Data Set). يتحقق المقيم من كلا الاتجاهين: هل قمنا بإزالة ما كان يجب إزالته، وهل تركنا ما كان يجب تركه؟
| الوضع | 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 فقط، وكلاهما معاً. يخبرنا هذا بالضبط عن التقنية التي تضبط أي نوع من المعرفات — وأين يحتاج كل منهما للآخر. أحدث تشغيل، 2026-05-20:
ملخص عبر جميع أوضاع الفلتر الثلاثة
| الوضع | الاستدعاء المشترك | الدقة | F2 | العينات |
|---|---|---|---|---|
| فلتر 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 = الأكثر حساسية).
| الفئة | المستوى | استدعاء Regex | استدعاء ML (خام) | الاستدعاء المشترك | العدد الذهبي |
|---|---|---|---|---|---|
| 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 |
بالنظر إلى النتائج، نجد أن التصميم ثنائي الطبقات يؤتي ثماره. تسجل العناوين البريدية وتواريخ الميلاد وأسماء الأشخاص ما بين 0-13% تحت regex وحده — لا يوجد نمط ثابت للمطابقة، لذا فإن نموذج ML وحده هو من يمكنه ضبطها. أما رسائل البريد الإلكتروني وأرقام الهواتف وعناوين IP والهويات الحكومية والهويات البيومترية والمواقع الجغرافية الدقيقة فتسجل 100% تحت regex وحده — وهي تنسيقات سطحية يحصل عليها نموذج ML تلقائياً. أما المعرفات عبر الإنترنت ومعرفات المركبات وأسرار المصادقة فهي مختلطة: يضبط regex الأشكال القياسية، ويضبط ML الباقي. يتجاوز الاستدعاء المشترك أو يعادل أياً من الطبقتين المنفردتين في كل فئة.
معرفات الأجهزة ومعرفات المؤسسات المتنوعة هي الفئات التي تقل عن 100%، ونحن نعرف السبب: هذه الفئات لديها أوسع مجموعة متنوعة من التنسيقات في النصوص الحقيقية. نفضل أن نكون صادقين بشأن الفئات التي ينخفض فيها الاستدعاء بدلاً من التظاهر بأن الفلتر مثالي في كل مكان.
فلتر HIPAA — وضع Limited Data Set الفرعي
يحافظ وضع Limited Data Set الفرعي على التواريخ والجغرافيا والأعمار 89 أو أقل حسب التصميم — وهي الإشارات التي يسمح HIPAA للمؤسسة بالاحتفاظ بها للبحث السريري والعمليات المشروعة.
| الفئة | المستوى | استدعاء Regex | استدعاء ML (خام) | الاستدعاء المشترك | العدد الذهبي |
|---|---|---|---|---|---|
| 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 |
تعتبر الصور حالة إخفاق معروفة — فالفلتر النصي فقط لا يمكنه رؤية ما بداخل الصورة. معلومات PHI في الصور هي مشكلة منفصلة لم نقم بإطلاق حل لها بعد. كل فئة أخرى في هذا الوضع هي بنسبة 100%.
فلتر HIPAA — وضع Safe Harbor الفرعي
يقوم Safe Harbor بإزالة كل ما كان وضع Limited Data Set سيحتفظ به — التواريخ، الأعمار فوق 89، والجغرافيا. للحصول على أقصى تغطية، فإنه يشغل كلا نموذجي الفلتر بالتوازي: النموذج الخاص بـ HIPAA والنموذج العام للبيانات الشخصية.
| الفئة | المستوى | استدعاء Regex | استدعاء ML (خام) | الاستدعاء المشترك | العدد الذهبي |
|---|---|---|---|---|---|
| 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%). لقد تركنا regex عمداً يتعامل مع كليهما في Safe Harbor: التواريخ لها شكل يضبطه regex في كل مرة، ولا نريد لنموذج احتمالي أن يخمن عتبة رقمية مثل ">89". القاعدة الحتمية أكثر موثوقية من مطالبة نموذج ML بتعلم نفس القاعدة.
الأرقام الإجمالية عبر جميع الفئات
بجمع كل ذلك: كيف يقارن مسار العمل الكامل (regex + ML معاً) بأي من الطبقتين بمفردها؟
| الوضع | الطبقات | الاستدعاء | الدقة | 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، التي نحتفظ بها عمداً حتى لا نعطل الروابط واستدعاءات الأدوات.
مقارنة مباشرة ضد فلاتر الخصوصية المخصصة الأخرى
المقارنة العادلة لفلتر خصوصية يعمل على الجهاز وبشكل فوري تقريباً مثل فلترنا هي ضد فلاتر الخصوصية الأخرى التي تعمل على الجهاز وبشكل فوري — وليس ضد نماذج LLM العملاقة المستضافة سحابياً والتي تستغرق ثوانٍ لكل رسالة وتحتاج إلى رحلة ذهاب وإياب عبر الشبكة. قمنا بتشغيل كل نظام في هذه الفئة ضد نفس مجموعات الاختبار، باستخدام نفس قواعد المطابقة. نفس المعيار للجميع.
فئة النظراء:
- openai/privacy-filter — فلتر الخصوصية المخصص مفتوح المصدر من OpenAI. حوالي 50 مليون معلمة، صغير بما يكفي ليعمل في أي متصفح حديث.
- piiranha-v1 — كاشف بـ 278 مليون معلمة من iiiorg. ترخيصه يقيده بالبحث والتقييم فقط (يمكننا قياسه، ولكن لا يمكن شحنه تجارياً).
- Microsoft Presidio — أداة الحجب مفتوحة المصدر الأكثر انتشاراً، تجمع بين مطابقة الأنماط التقليدية ونموذج لغوي صغير للسياق.
- عائلة GLiNER PII — عائلة من مصنفات الكيانات الصغيرة للأغراض العامة. تشحن Knowledgator متغيرات صغيرة (~44M)، أساسية (~86M)، وكبيرة (~304M)؛ أصدرت NVIDIA متغيراً بـ 570M في أكتوبر 2025.
- Caiioo في جميع الأوضاع الثلاثة (Personal Data، HIPAA Limited Data Set، HIPAA Safe Harbor).
الاستدعاء عبر جميع مجموعات الاختبار الخمس، مرتبة مع Caiioo أولاً:
| النظام | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 مناطق) |
|---|---|---|---|---|---|
| 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)، ويتعادل أو يتصدر في الاختبارات القياسية العامة، ويحتل المركز الثاني في اللغات المتعددة. في أصغر اختبار (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 استدعاءً بنسبة 100% في كل اختبار HIPAA — تم ضبط كل اسم مريض، وكل رقم سجل طبي، وكل تاريخ ميلاد، وكل رقم حساب. ثاني أفضل نظام هو openai/privacy-filter بنسبة 93.7% في PrivacyBenchHIPAA — فجوة قدرها 6.3 نقطة، في اختبار قياسي يمثل فيه كل إخفاق كشفاً حقيقياً للبيانات.
رقم ثانٍ يستحق القراءة: الإفراط في الحجب — حجب أشياء لم تكن في الواقع بيانات خاصة. الإفراط في الحجب ليس ضرراً بالخصوصية، بل هو تكلفة على سهولة الاستخدام. حجب الكثير من الأشياء يجعل استنتاج LLM أسوأ، وتتدهور الإجابة المعادة. يقوم Caiioo بالحجب دون داعٍ 1-24 مرة عبر مجموعات الاختبار. Presidio: 10-51. GLiNER من NVIDIA: 31-64 في اختبارات HIPAA وحدها. الدقة تهم بقدر الاستدعاء عندما يكون الهدف هو الحصول على أفضل إجابة ممكنة مع أقل قدر ممكن من التعرض للمخاطر.
ماذا عن مجرد استخدام نموذج LLM رائد كفلتر؟
يمكنهم ذلك — وفي الاستدعاء الخام، هم الفائزون. نماذج LLM الكبيرة للأغراض العامة (Llama 3.1 8B، Gemma 4، Qwen 3.5 9B، وما شابه)، سواء كانت تعمل في السحابة أو محلياً، يمكنها تسجيل 95-100% عبر كل اختبار بما في ذلك اللغات المتعددة. هذا خيار حقيقي للمستخدمين الذين يحتاجون إلى أقصى استدعاء ومستعدون لدفع ثمنه.
ومع ذلك، فإن العيوب حقيقية:
- إنه بطيء. ثوانٍ لكل رسالة بدلاً من أجزاء من الثانية. يقع الفلتر أمام كل رسالة يرسلها المستخدم.
- إما أن الرسالة تغادر جهاز المستخدم، أو يغادره النموذج. للفلترة في السحابة، يجب أن تذهب الرسالة إلى هناك — مما يهزم الغرض. وللفلترة على الجهاز، يتطلب الأمر تنزيل نموذج بحجم 1-17 جيجابايت.
- يمكن خداعه. يمكن إقناع النموذج التوليدي، في منتصف الرسالة، بعدم الحجب (هجوم "حقن الأوامر"). أما المصنف الصغير مثل فلترنا فلا يمكن خداعه.
- نفس المدخلات، مخرجات مختلفة. لا تعطي النماذج التوليدية دائماً نفس الإجابة مرتين. هذا يكسر رحلة الذهاب والإياب — فالحجب عند الإرسال وإلغاء الحجب عند العودة يعتمد على رسم نفس القيمة الحقيقية دائماً لنفس القيمة الوهمية.
تم بناء Caiioo للجانب الآخر من تلك المقايضة: فلتر صغير، يمكن التنبؤ به، يعمل في أقل من ثانية في المحرر قبل أن يضغط المستخدم على إرسال، وينتج دائماً نفس القيمة الوهمية لنفس القيمة الحقيقية داخل المحادثة، بحيث تظل رحلة الذهاب والإياب متماسكة. جدول فئة النظراء أعلاه هو المقارنة العادلة لهذا النوع من حالات الاستخدام.
العبرة بالنتائج
تُعد اختبارات الأداء نقطة انطلاق وليست خط النهاية. تم دمج الفلتر في ميزة Caiioo الجديدة: pseudonymizer — وهو المكون الذي يتوسط فعلياً بين المُحرر والنموذج.
إليك ما يحدث عندما يضغط المستخدم على إرسال.
- الاكتشاف (Detect). تعمل طبقة regex أولاً — فهي حتمية وسريعة للغاية (بأجزاء من الميكروثانية). ثم يعمل نموذج ML بعد ذلك على ما تبقى. إذا تداخلت الطبقتان في نفس النص، فإننا نستخدم قاعدة بسيطة: تتفوق regex في تنسيقات النصوص الظاهرة، بينما يتفوق ML في السياق.
- تمييز الهوية الذاتية مقابل الآخرين (Tag self vs. other). يقوم Caiioo بفصل المعرفات التي تشير إلى المستخدم عن المعرفات التي تشير إلى أشخاص آخرين. يمكن للمستخدم اختيار إخفاء أحدهما فقط، أو كليهما. الأسماء التي أضافها المستخدم إلى قاموسه الشخصي تُحتسب دائماً كـ "ذاتية" (self).
- الاستبدال (Substitute). تحصل كل قيمة حقيقية على اسم مستعار ثابت ومتوافق مع الأسلوب. فمثلاً، يصبح "Sarah Goldberg" هو "Maya Hartwell" — ويظل "Maya Hartwell" طوال المحادثة، حتى لا يتشتت استنتاج النموذج حول هذا الشخص عبر الردود المتتالية. يتم الاحتفاظ بجدول بحث (lookup table) من الحقيقي إلى المزيف على جهاز المستخدم، مشفراً بمفتاح من keychain الخاص بالمنصة.
- الإرسال (Send). يتلقى النموذج رسالة مزيفة بالكامل. لا يعبر أي معرف حقيقي الشبكة أبداً، ويسجل سجل التدقيق الخاص بنا الأعداد فقط — ولا يسجل القيم نفسها أبداً.
- الاستعادة (Restore). يتم إعادة تعيين الاستجابة المتدفقة (streaming response) فور وصولها. فاسم "Maya Hartwell" في رد النموذج يعود ليصبح "Sarah Goldberg" قبل أن يصل إلى الشاشة، ويُعرض مع علامة توهج صغيرة (glow pill) حتى يتمكن المستخدم من رؤية ما تمت حمايته بلمحة سريعة.
- استعادة وسائط الأدوات أيضاً (Restore tool arguments too). إذا استدعى النموذج أداة ما — مثل إرسال بريد إلكتروني، أو فتح تذكرة دعم، أو الكتابة في مستند — وكانت الوسائط (arguments) تحتوي على بيانات مزيفة، فإننا نستبدل القيم الحقيقية مرة أخرى قبل تشغيل الأداة. النموذج يقوم بالاستنتاج بناءً على البيانات المزيفة؛ بينما ينفذ الإجراء باستخدام القيمة الحقيقية.
لا يهتم الفلتر بنوع خدمة AI المستخدمة. فهو يعمل قبل أن تصل الرسالة إلى النموذج، لذا فإن OpenRouter، و Anthropic، و Google، و OpenAI، و Ollama المحلي، جميعهم يتلقون نفس البيانات المقنعة. إضافة مزود جديد لا يفتح ثغرة الخصوصية من جديد.
من يحميه
المستخدم. اسم المستخدم، وبريده الإلكتروني، وعنوانه، وهاتفه، وعنوان IP، والمعرفات الحيوية — الأشياء التي، عند جمعها معاً، تحدد هوية الشخص للمجمعين — لا تغادر الجهاز أبداً عندما يكون الفلتر مفعلاً.
الأشخاص الذين يتحدث عنهم المستخدم. تركز معظم أدوات الخصوصية على الشخص الذي يكتب، لكن ما يتجاهلونه هو "العقد الاجتماعي" — حقيقة أننا جميعاً نتحمل مسؤولية تجاه الآخرين كما تجاه أنفسنا. إن تقديم طلب مثل "يرجى تحليل سلوك السيد ساندرز بحثاً عن عدم الكفاءة" إلى LLM، حيث قد يتم تسجيله في سجلات النظام إلى الأبد، هو أمر غير مسؤول (وقد يكون تشهيرياً). إن طلب المساعدة من LLM بشأن Google Sheet يحتوي على 1,000 جهة اتصال تجارية يضعها جميعاً في مصيدة الاحتفاظ بالبيانات (بدرجات متفاوتة، اعتماداً على سياسة "عدم الاحتفاظ بالبيانات" الفعلية المعمول بها). يغطي فلتر Caiioo أيضاً أطرافاً ثالثة: العميل الذي يتم صياغة عقد له، المريض الذي يتم تحليل سجله، الزميل الذي تم لصق بريده الإلكتروني في السياق. هؤلاء لم يوافقوا على رؤية LLM عن بُعد لمعرفاتهم. يحترم الفلتر ذلك افتراضياً؛ ويمكن للمستخدم التبديل إلى "النفس فقط" أو "الآخرين فقط" إذا تطلب سير العمل ذلك.
الكيانات — الشركات، المستشفيات، المؤسسات. أرقام الحسابات، أرقام التراخيص، أرقام السجلات الطبية، تفاصيل التوجيه المالي، المعرفات الداخلية، مفاتيح API، قوائم العملاء. الشركة لديها نفس مصلحة تقليل البيانات التي لدى الشخص. الطبيب الذي يستخدم Caiioo لصياغة ملاحظة خروج لا يرسل رقم السجل الطبي للمريض إلى OpenAI. المحامي لا يرسل رقم حساب العميل إلى Anthropic. مهندس الدعم لا يرسل مفتاح API من سجل العميل إلى Google. الفلتر لا يسأل عما إذا كان المعرف ينتمي لشخص أو كيان — هو فقط يبقيه على الجهاز.
أقصى فائدة، أدنى تعرض
الهدف الأساسي هو ألا يشعر المستخدم بالفلتر.
تجبر معظم أدوات الخصوصية المستخدم على الاختيار: إما الحجب بقوة ومشاهدة إجابة النموذج وهي تزداد سوءاً، أو الحفاظ على قابلية استخدام الأمر ومشاهدة وعد الخصوصية وهو يتآكل. لقد رفضنا هذه المقايضة. لا يزال النموذج يتلقى أمراً كامل التكوين — يرى اسماً، ومكاناً، وتاريخاً، ورقم سجل طبي، وكل ذلك في المواقع النحوية الصحيحة. هو فقط يرى بيانات وهمية. تفكيره يظل متطابقاً؛ فقط النصوص هي التي تم مسحها.
الاستبدال المستقر هو ما يجعل ذلك يعمل. لأن نفس القيمة الحقيقية ترتبط دائماً بنفس القيمة الوهمية داخل المحادثة — عبر رسالة المستخدم، ونتيجة الأداة التي تعود مشيرة إلى ذلك الاسم، ورد النموذج السابق الذي ذكره — يكون لدى النموذج شخص أو مكان أو شيء متسق للتفكير فيه. المحادثات متعددة الأدوار لا تختلط. استدعاءات الأدوات لا تتعطل. الوكلاء الفرعيون يرثون خريطة المحادثة الأصلية ويبقون متسقين عبر المهمة بأكملها.
المخرجات التي يراها المستخدم هي المحادثة الحقيقية. البيانات التي يراها المزود هي خيال متسق. العمل يحدث في الفجوة بين هاتين الرؤيتين، والهدف — الهدف الوحيد — هو جعل تلك الفجوة غير مرئية.
فلتر الخصوصية الذي يعيق العمل سيتم إيقافه. فلتر الخصوصية الذي يختفي داخل سير العمل هو النوع الوحيد الذي يستحق الإطلاق.
هذا هو المعيار الذي بنينا على أساسه.