এটি মূল ইংরেজি নথির একটি মেশিন অনুবাদ। এই অনুবাদ এবং মূল ইংরেজি সংস্করণের মধ্যে কোনো বিরোধ দেখা দিলে, ইংরেজি সংস্করণটিই প্রাধান্য পাবে। মূল ইংরেজি সংস্করণটি পড়ুন
অন-ডিভাইস সিউডোনিমাইজার (Pseudonymizer): তৈরি এবং বেঞ্চমার্ক করা হয়েছে
2026-05-22 · Caiioo Team
আমরা AI সিস্টেমের আসল ব্যক্তিগত তথ্য (PII) প্রশিক্ষণ এবং সংরক্ষণের গোপনীয়তা সমস্যার সমাধান করতে চেয়েছিলাম। "Zero Data Retention" পলিসি এবং চুক্তিগুলো ঝুঁকি কমায়, কিন্তু সেগুলো অনেক ব্যতিক্রমের দ্বারা সীমাবদ্ধ। সেগুলো মূলত বলে: "আমরা আপনার কোনো প্রম্পট বা আউটপুট সংরক্ষণ করব না, তবে এই ব্যতিক্রমগুলো ছাড়া: (নিরাপত্তা উদ্দেশ্য, সরকারি নজরদারি, আইনি বাধ্যবাধকতা, পণ্য উন্নয়ন, এরর লগ, পরিষেবার উন্নতি...)"
এটি সমাধান করার জন্য, আমরা একটি ব্যক্তিগত ডেটা ফিল্টার তৈরি করেছি যা ব্যবহারকারীর নিজস্ব মেশিনে চলে, ডিভাইস থেকে মেসেজ বের হওয়ার আগে সেটি দেখে এবং ব্যবহারকারী ফিল্টার ছাড়া মেসেজ পাঠালে যে উত্তর পেতেন ঠিক সেই উত্তরটিই নিশ্চিত করে।
তাই আমরা একটি তৈরি করেছি। Caiioo-এর পরবর্তী সংস্করণে Pseudonymizer অন্তর্ভুক্ত থাকবে। এটি এজেন্ট চ্যাটের শিল্ড আইকন এবং সেটিংসের মাধ্যমে অ্যাক্সেস করা যাবে।
এই হোয়াইট পেপারটি আমাদের গোপনীয়তা ফিল্টারিং সিস্টেমের যৌক্তিকতা, আর্কিটেকচার, মূল্যায়ন প্রক্রিয়া এবং ডিজাইনের নীতিগুলো তুলে ধরে।
আমরা যা করতে চেয়েছি
ডেটা মিনিমাইজেশনের মাধ্যমে সাধারণ গোপনীয়তা সুরক্ষা। যখন একজন ব্যবহারকারী একটি রিমোট মডেলের সাথে চ্যাট করেন, তখন ব্যবহারকারীর প্রশ্নের উত্তর দেওয়ার জন্য মডেলটির আসল নাম, বাড়ির ঠিকানা, আসল ইমেল বা গ্রাহকের ফোন নম্বরের প্রয়োজন হয় না। এর প্রয়োজন প্রশ্নের ধরন (shape), এবং এটিকে একটি আসল প্রশ্নের মতো হতে হবে যাতে LLM কোয়েরিটিকে একটি পরীক্ষা হিসেবে বাতিল করে না দেয়। তাই ফিল্টারটি AI-এর কাছে পাঠানো ডেটা থেকে আসল আইডেন্টিফায়ারগুলো সরিয়ে ফেলে এবং ফিরে আসার পথে আসল মানগুলো আবার যুক্ত করে দেয়। মডেলটি সিন্থেটিক নাম এবং আইডেন্টিফায়ার দেখে; ব্যবহারকারী আসল কথোপকথন দেখতে পান।
HIPAA কমপ্লায়েন্স সহায়তা। দ্বিতীয় মোডটি HIPAA Safe Harbor নিয়মের (§164.514) ১৮টি আইডেন্টিফায়ার এবং তুলনামূলক শিথিল Limited Data Set ভেরিয়েন্টকে লক্ষ্য করে। একজন ক্লিনিশিয়ান, একজন হেলথকেয়ার অ্যাডমিন, বা কভারড ওয়ার্কফ্লোতে কাজ করা যে কেউ AI-এর কাছে প্রোটেক্টেড হেলথ ইনফরমেশন না পাঠিয়েই আসল কেসগুলো নিয়ে একটি জেনারেল-পারপাস মডেলের সাথে কথা বলতে পারেন। আমরা কভারড এনটিটির কমপ্লায়েন্স অফিসার নই — তবে আমরা সেই লেয়ার হতে পারি যা PHI-কে ল্যাপটপ থেকে বের হতে বাধা দেয়। আমাদের মূল্যায়নগুলো পরিমাপযোগ্য বেঞ্চমার্ক প্রদান করে যা সংস্থাগুলো তাদের কমপ্লায়েন্স এবং গোপনীয়তার মানদণ্ডের জন্য ফিল্টারটির উপযুক্ততা যাচাই করতে ব্যবহার করতে পারে। সমস্ত গোপনীয়তা এবং নিরাপত্তা ব্যবস্থা হলো বিচারবুদ্ধিপ্রসূত সিদ্ধান্ত যা ব্যবহারকারী বা ব্যবহারকারী এনটিটির দায়িত্ব।
আমরা উভয়ই বেছে নিয়েছি কারণ এগুলোর ইঞ্জিনিয়ারিং একই, এবং PHI ব্যবহারের ক্ষেত্রটি প্রযুক্তিগতভাবে আসলে সহজ কারণ এতে সুনির্দিষ্ট নেমড এনটিটি (named entities) ব্যবহার করা হয়, যা Personal Data ক্যাটাগরির সাধারণ ডেটার তুলনায় রেড্যাক্ট (redact) করা সহজ। HIPAA ফিল্টারিংয়ের ক্ষেত্রে এটি সাধারণত ইংরেজি বা স্প্যানিশ ভাষায় হওয়ার বিষয়টিও সহায়ক। আমরা আইডেন্টিফায়ারগুলো শনাক্ত করি, একই ফরম্যাটে স্থিতিশীল ছদ্মনাম এবং প্রতিস্থাপিত আইডেন্টিফায়ার বসাই, ফিরে আসার পথে সেগুলো পুনরুদ্ধার করি এবং কখনোই আসল মানগুলো লগ করি না। সিন্থেটিক তথ্য এবং আসল তথ্যের মধ্যকার ম্যাপটি শুধুমাত্র ব্যবহারকারীর ডিভাইসেই থাকে, যাতে ব্যবহারকারী এজেন্টের প্রতিক্রিয়াগুলোতে আসল তথ্য পড়তে পারেন। মোড পরিবর্তনের সাথে সাথে শুধুমাত্র ক্যাটাগরি লিস্ট এবং পলিসি গেট পরিবর্তিত হয়।
কেন regex এবং machine learning উভয়ই প্রয়োজন, শুধু একটি নয়
আমাদের pseudonymizer-এ দুটি প্রধান ফিল্টার প্রযুক্তি রয়েছে: একটি ডিটারমিনিস্টিক প্যাটার্ন রিকগনিশন ল্যাঙ্গুয়েজ যাকে 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 এনকোডার যা একটি বহুভাষিক tiny language model থেকে ডিস্টিল করা হয়েছে। এটি সাবস্ট্রিং নয়, বরং পুরো বাক্যটি পড়ে এবং এটি আকারে যথেষ্ট ছোট হওয়ায় ডিভাইসে, এমনকি মোবাইল ফোনেও অত্যন্ত দ্রুত চলতে পারে।
বেঞ্চমার্কগুলো এই দুটি স্তরের পরিপূরক শক্তি প্রদর্শন করে। প্রতিটি স্তর আসলে কতটা কার্যকর তা নিশ্চিত করার জন্য আমরা আইসোলেশনে দুটি স্তরের বেঞ্চমার্ক করেছি। ১৫০টি প্রশ্নের PrivacyBench-PD সেটটিতে, যেখানে প্রশ্ন এবং উত্তরগুলো মডেলটিকে প্রশিক্ষণ দিতে স্পষ্টভাবে ব্যবহার করা হয়নি:
| Layer | PII caught | Caught rate |
|---|---|---|
| Regex only | 205 / 670 | 30.6 % |
| ML only | 516 / 670 | 77.0 % |
| Both (production) | 625 / 670 | 93.3 % |
শুধুমাত্র regex তিন-চতুর্থাংশ আইডেন্টিফায়ার মিস করে কারণ বাস্তব গদ্যের বেশিরভাগ আইডেন্টিফায়ার সুগঠিত নয়। শুধুমাত্র ML ১৬ শতাংশ পয়েন্ট মিস করে যা regex স্তরটি শনাক্ত করতে পারত — অর্থাৎ সেই জিনিসগুলো যা সম্পূর্ণরূপে তাদের আকৃতির ওপর নির্ভরশীল (একটি ক্রেডিট কার্ড দেখতে ক্রেডিট কার্ডের মতোই; এখানে মডেলের যোগ করার মতো বাড়তি কোনো সিগন্যাল নেই)। একত্রে তারা এমন সব ক্ষেত্র কভার করে যা একা কোনোটিই পারে না।
প্রতিটি স্তর কোথায় সিদ্ধান্তমূলক ভূমিকা রাখে তা গভীরভাবে পর্যবেক্ষণ করলে দেখা যায়: একই সেটের মধ্যে, ১৬টি টেস্ট ভ্যালু শুধুমাত্র regex দ্বারা শনাক্ত হয়েছে (ইমেল, IP, ফিন্যান্সিয়াল অ্যাকাউন্ট, স্ট্রাকচার্ড ID) এবং ৩২৭টি শুধুমাত্র ML দ্বারা শনাক্ত হয়েছে (নাম, প্রসঙ্গিক আইডেন্টিফায়ার, বহুভাষিক বাক্যাংশ)।
ছোট, বুদ্ধিমান, দ্রুত — এবং সব জায়গায় চলে
আমাদের ফিল্টারটিকে অন-ডিভাইস করতে হয়েছে, যা একটি ইঞ্জিনিয়ারিং চ্যালেঞ্জ ছিল।
এটি ছোট হতে হবে কারণ আমাদের অ্যাপ অনেক সিস্টেমে চলে: ব্রাউজার এক্সটেনশন, macOS অ্যাপ, iOS অ্যাপ, Android অ্যাপ, অথবা Windows এবং Linux-এ। প্রতিটি মডেলের বান্ডেল সাইজ প্রায় ১১৩ MB। এখানে দুটি মডেল রয়েছে — একটি সাধারণ ব্যক্তিগত ডেটার জন্য, অন্যটি সুরক্ষিত স্বাস্থ্য তথ্যের জন্য — এবং Safe Harbor মোড দুটিকেই সমান্তরালভাবে চালায়। এগুলোর মধ্যে একটি লো-এন্ড Android ডিভাইস সবচেয়ে কম পারফরম্যান্স দেয়, তবুও আমাদের সিস্টেম সেখানে ঠিকঠাক কাজ করে।
এটি বুদ্ধিমান হতে হবে কারণ ভুল নেগেটিভ হলে আসল ডেটা রিমোট LLM-এ ফাঁস হয়ে যায় এবং ভুল পজিটিভ হলে কথোপকথন নষ্ট হয়ে যায়। নাম অবশ্যই রিড্যাক্ট করতে হবে; কিন্তু সর্বনাম নয়। ফরোয়ার্ড করা থ্রেডে ডাক্তারের ইমেল রিড্যাক্ট করা উচিত; কিন্তু [email protected] ফুটার সম্ভবত নয়।
এটি দ্রুত হতে হবে কারণ এটি ব্যবহারকারীর পাঠানো বা গ্রহণ করা প্রতিটি মেসেজের মাঝখানে থাকে। আমরা পরিমাপ করেছি যে একটি একক CPU থ্রেডে রাউন্ড-ট্রিপ ওভারহেড ২০০ ms-এর কম, যার বেশিরভাগই টোকেনাইজেশন। WebGPU এবং Apple-এর Neural Engine-এ এটি LLM কলের নেটওয়ার্ক ল্যাটেন্সির তুলনায় অত্যন্ত সামান্য।
এটি একাধিক রানটাইমে চলতে হবে কারণ Caiioo মাল্টি-প্ল্যাটফর্ম। একই সিস্টেম Chrome এক্সটেনশন, macOS এবং iOS, Android এবং Windows ও Linux-এ চলে। একটি ডিটেকশন মডেল, একটি regex লাইব্রেরি, একটি মার্জার, একটি পলিসি — Caiioo যেখানেই চলে সবখানে অভিন্ন আচরণ করে।
স্কোরসমূহ
কয়েক রাউন্ড পরীক্ষা এবং প্রশিক্ষণের পর, আমরা আমাদের মডেলের ১৬তম সংস্করণে স্থির হয়েছি। নিচে তিনটি বেঞ্চমার্ক দেওয়া হলো, যার প্রতিটি ভিন্ন ভিন্ন বিষয় পরিমাপ করে।
আমাদের নিজস্ব টেস্ট সেট, ১৫০টি প্রশ্ন যা মডেলটি আগে কখনও দেখেনি
পাবলিক বেঞ্চমার্কের বিরুদ্ধে পরীক্ষা করার আগে, আমরা আমাদের Personal Data ফিল্টারটিকে একটি অভ্যন্তরীণ টেস্ট সেটের বিরুদ্ধে চালিয়েছি যা আমরা ইচ্ছাকৃতভাবে প্রশিক্ষণ ডেটা থেকে আলাদা রেখেছিলাম — যাতে ডিটেক্টরটি আগে কখনও এই প্রশ্নগুলোর কোনোটি না দেখে। ১৫০টি প্রশ্ন চারটি গ্রুপে বিভক্ত (code snippets, document prose, ইচ্ছাকৃতভাবে অপরিচিত শব্দবিন্যাস এবং ১০টি অ-ইংরেজি ভাষা), সাথে একটি "নেগেটিভ" গ্রুপ যাতে কোনো ব্যক্তিগত ডেটা নেই (এটি নিশ্চিত করার জন্য যে আমরা অতিরিক্ত রেড্যাক্ট বা তথ্য মুছে ফেলছি না)। সম্মিলিত 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 % |
| সবগুলো ৪টি পজিটিভ বেঞ্চ | 625 / 670 | 93.3 % |
(নেগেটিভ গ্রুপে খুঁজে পাওয়ার মতো কোনো ব্যক্তিগত ডেটা ছিল না। ফিল্টারটি একটি জিনিস মাস্ক করেছিল যা করা উচিত ছিল না — যা নিচের প্রিসিশন সংখ্যার সাথে সামঞ্জস্যপূর্ণ।)
গ্রেডারটি অত্যন্ত কঠোর: প্রশ্নের স্কোর পাওয়ার জন্য মাস্ক করা আউটপুট থেকে প্রতিটি প্রত্যাশিত ব্যক্তিগত ডেটা সম্পূর্ণভাবে অদৃশ্য হতে হবে। কোনো আংশিক ক্রেডিট বা "কাছাকাছি গেছে" এমন সুযোগ নেই। এটি সেইসব বেঞ্চমার্কের চেয়েও কঠোর যা অন্য একটি LLM-কে বিচারক হিসেবে ব্যবহার করে (LLM বিচারকরা সাধারণত উদার হয়ে থাকেন)। অন্যান্য সিস্টেমের সাথে সরাসরি তুলনামূলক সংখ্যার জন্য নিচের হেড-টু-হেড বিভাগটি দেখুন।
PrivacyBenchHIPAA — ৪০টি স্বাস্থ্যসেবা সংক্রান্ত প্রশ্ন
প্রতিটি প্রশ্নে সুরক্ষিত স্বাস্থ্য তথ্য (protected health information) তালিকাভুক্ত থাকে যা অবশ্যই রেড্যাক্ট করতে হবে (নাম, মেডিকেল রেকর্ড নম্বর ইত্যাদি) এবং কিছু সংকেত যা অবশ্যই রাখতে হবে (তারিখ, ভৌগোলিক অবস্থান, ৯০ বছরের কম বয়স হলে বয়স — HIPAA Limited Data Set নিয়ম অনুযায়ী)। গ্রেডারটি উভয় দিক পরীক্ষা করে: আমরা কি যা মুছে ফেলার কথা ছিল তা মুছেছি, এবং যা রাখার কথা ছিল তা কি রেখেছি?
| মোড (Mode) | PHI রেড্যাক্ট করা হয়েছে | রিটেইনড রাখা হয়েছে |
|---|---|---|
| Limited Data Set (তারিখ / ভূগোল / বয়স ≤৮৯ সংরক্ষণ) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (তারিখসহ সবকিছু রেড্যাক্ট করা) | 99 / 104 (95.2 %) | — |
Limited Data Set সাবমোডটি এই বেঞ্চমার্কে নিখুঁত ফলাফল দিয়েছে। Safe Harbor — যেখানে রেড্যাক্ট করার মতো তথ্য বেশি থাকে, তাই ভুল হওয়ার সম্ভাবনাও বেশি — সেখানে ৯৫.২% কভার করেছে।
আমাদের নিজস্ব ডেটাতে ক্যাটাগরি-ভিত্তিক ফলাফল, প্রতি মোডে ২০০টি স্যাম্পল
পাবলিক বেঞ্চমার্কগুলো সবকিছু একসাথে মিলিয়ে ফেলে। আমাদের অভ্যন্তরীণ টেস্ট ডেটা ফলাফলগুলোকে ক্যাটাগরি অনুযায়ী (নাম, ইমেল, ঠিকানা ইত্যাদি) ভাগ করে এবং প্রতিটি তিনটি উপায়ে চালায়: শুধুমাত্র regex, শুধুমাত্র ML, এবং উভয়ই একসাথে। এটি আমাদের স্পষ্টভাবে জানায় যে কোন প্রযুক্তি কোন ধরনের আইডেন্টিফায়ার ধরছে — এবং কোথায় একটির জন্য অন্যটির প্রয়োজন। সাম্প্রতিকতম রান, 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 |
এই সংখ্যাগুলোতে URL অন্তর্ভুক্ত নয়, যা আমরা ইচ্ছাকৃতভাবে রেখে দিই — একটি URL মুছে ফেললে "এই লিঙ্কটি ওপেন করুন" বা "ওই পেজটি ফেচ করুন"-এর মতো পরবর্তী কাজগুলো বাধাগ্রস্ত হবে। এই বিষয়ে নিচের ওয়ার্কফ্লো বিভাগে আরও বিস্তারিত রয়েছে।
প্রতি-ক্যাটাগরি টেবিলের আগে মূল চিত্র: প্রতিটি মোডে, একজন ব্যক্তিকে প্রকৃতপক্ষে শনাক্ত করে এমন আইডেন্টিফায়ারগুলো ১০০% বা তার কাছাকাছি সময়ে ধরা পড়ে। নাম, ইমেল, ফোন নম্বর, ডাক ঠিকানা, সরকারি আইডি, বায়োমেট্রিক আইডি, সুনির্দিষ্ট জিওলোকেশন, মেডিকেল রেকর্ড নম্বর, জন্ম তারিখ, সোশ্যাল সিকিউরিটি নম্বর — প্রতিটি স্যাম্পল এবং প্রতিটি টেস্টে ধরা পড়েছে। যেসব ক্যাটাগরিতে আমরা ১০০%-এর নিচে নেমেছি সেগুলো অনুমানযোগ্য: ডিভাইস আইডি (আসল টেক্সটে ফরম্যাটের বিশাল বৈচিত্র্য), বিবিধ প্রাতিষ্ঠানিক আইডি (লয়্যালটি নম্বর, এমপ্লয়ি আইডি — একই সমস্যা), এবং ফটো (একটি টেক্সট-অনলি ফিল্টার ছবির ভেতরে কী আছে তা দেখতে পায় না)। এগুলোর কোনোটিই "চার্টে থাকা নাম" বা "ড্রাফটে থাকা ইমেল"-এর মতো আইডেন্টিফায়ার নয় যা তথ্য ফাঁসের ক্ষেত্রে আসলে গুরুত্বপূর্ণ। উচ্চ-ঝুঁকিপূর্ণ ক্যাটাগরিগুলো নির্ভরযোগ্য।
Personal Data filter
সম্মিলিত রিকল (সেরাটি আগে) এবং তারপর রিস্ক টিয়ার (T1 = সবচেয়ে সংবেদনশীল) অনুযায়ী সাজানো।
| ক্যাটাগরি | টিয়ার | 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-এর অধীনে ০–১৩% স্কোর করে — কারণ এগুলোর মিলানোর মতো কোনো নির্দিষ্ট আকার নেই, তাই শুধুমাত্র ML মডেল এগুলো ধরতে পারে। ইমেল, ফোন নম্বর, IP, সরকারি আইডি, বায়োমেট্রিক আইডি এবং সুনির্দিষ্ট জিওলোকেশন শুধুমাত্র regex-এর অধীনে ১০০% স্কোর করে — যা ML মডেল সহজেই পেয়ে যায়। অনলাইন হ্যান্ডেল, ভেহিকল আইডি এবং অথেন্টিকেশন সিক্রেট মিশ্রিত ফলাফল দেয়: regex স্ট্যান্ডার্ড ফর্মগুলো ধরে ফেলে, ML বাকিগুলো ধরে। প্রতিটি ক্যাটাগরিতে সম্মিলিত রিকল একক স্তরের চেয়ে বেশি বা সমান।
ডিভাইস আইডি এবং বিবিধ প্রাতিষ্ঠানিক আইডি ক্যাটাগরিগুলো ১০০%-এর নিচে রয়েছে এবং আমরা জানি কেন: আসল টেক্সটে এগুলোর ফরম্যাটের ব্যাপক বৈচিত্র্য রয়েছে। আমরা যেসব ক্যাটাগরিতে রিকল কম সেখানে ফিল্টারটি নিখুঁত বলে দাবি না করে বরং সত্যটি প্রকাশ করতে পছন্দ করি।
HIPAA filter — Limited Data Set submode
Limited Data Set সাবমোডটি ডিজাইন অনুযায়ী তারিখ, ভূগোল এবং ৮৯ বা তার কম বয়স সংরক্ষণ করে — এগুলো সেই সংকেত যা HIPAA একটি সংস্থাকে বৈধ ক্লিনিকাল গবেষণা এবং অপারেশনের জন্য রাখার অনুমতি দেয়।
| ক্যাটাগরি | টিয়ার | 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 একটি আলাদা সমস্যা যা আমরা এখনও রিলিজ করিনি। এই মোডের অন্য প্রতিটি ক্যাটাগরি ১০০%-এ রয়েছে।
HIPAA filter — Safe Harbor submode
Safe Harbor সেই সবকিছু মুছে ফেলে যা Limited Data Set সাবমোড রেখে দিত — তারিখ, ৮৯ বছরের বেশি বয়স, ভূগোল। কঠোরতম কভারেজ পেতে এটি সমান্তরালভাবে উভয় ফিল্টার মডেল চালায়: HIPAA-নির্দিষ্ট এবং সাধারণ ব্যক্তিগত-ডেটা ফিল্টার।
| ক্যাটাগরি | টিয়ার | 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 ১০০%, ML ৩০%) এবং ৮৯ বছরের বেশি বয়স (regex ১০০%, ML ০%)। আমরা ইচ্ছাকৃতভাবে Safe Harbor-এ উভয়ই regex-কে সামলাতে দিয়েছি: তারিখের এমন একটি আকার আছে যা regex প্রতিবার ধরে ফেলে, এবং আমরা চাই না কোনো সম্ভাব্য মডেল ">৮৯"-এর মতো একটি সংখ্যাসূচক থ্রেশহোল্ড নিয়ে দ্বিধা করুক। 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 মডেলের (প্রসঙ্গের জন্য) সংমিশ্রণ প্রকৃতপক্ষে এমন কিছু প্রদান করে যা একক কোনো স্তর পারে না। এই পোস্টের শুরুতে উল্লিখিত ৯৭.৩% সংখ্যাটি একজন প্রকৃত ব্যবহারকারী যা পান তা প্রতিফলিত করে। উপরের টেবিলের সংখ্যাটি কিছুটা কম কারণ এতে URL ক্যাটাগরি অন্তর্ভুক্ত রয়েছে, যা আমরা ইচ্ছাকৃতভাবে সংরক্ষণ করি যাতে লিঙ্ক এবং টুল কলগুলো নষ্ট না হয়।
অন্যান্য ডেডিকেটেড প্রাইভেসি ফিল্টারের সাথে সরাসরি তুলনা
আমাদের মতো অন-ডিভাইস, তাৎক্ষণিক প্রাইভেসি ফিল্টারের জন্য সঠিক তুলনা হলো অন্যান্য অন-ডিভাইস, তাৎক্ষণিক প্রাইভেসি ফিল্টারের সাথে — বিশাল ক্লাউড-হোস্টেড LLM-এর সাথে নয় যা প্রতি মেসেজে কয়েক সেকেন্ড সময় নেয় এবং নেটওয়ার্ক রাউন্ড-ট্রিপের প্রয়োজন হয়। আমরা একই টেস্ট সেট এবং একই ম্যাচিং রুল ব্যবহার করে এই ক্লাসের প্রতিটি সিস্টেম চালিয়েছি। সবার জন্য একই মানদণ্ড।
সহকর্মী ক্লাস (Peer class):
- openai/privacy-filter — OpenAI-এর ওপেন-সোর্স ডেডিকেটেড প্রাইভেসি ফিল্টার। প্রায় ৫০ মিলিয়ন প্যারামিটার, যেকোনো আধুনিক ব্রাউজারে চালানোর মতো ছোট।
- piiranha-v1 — iiiorg থেকে একটি ২৭৮M-প্যারামিটার ডিটেক্টর। এর লাইসেন্স এটিকে শুধুমাত্র গবেষণা এবং মূল্যায়নের মধ্যে সীমাবদ্ধ রাখে (আমরা এটি পরিমাপ করতে পারি, কিন্তু বাণিজ্যিকভাবে পাঠাতে পারি না)।
- Microsoft Presidio — সবচেয়ে ব্যাপকভাবে ব্যবহৃত ওপেন-সোর্স রেডাক্টর, যা প্রসঙ্গের জন্য একটি ছোট ল্যাঙ্গুয়েজ মডেলের সাথে ঐতিহ্যগত প্যাটার্ন ম্যাচিংকে একত্রিত করে।
- GLiNER PII family — ছোট, সাধারণ-উদ্দেশ্যের এনটিটি ক্লাসিফায়ারের একটি পরিবার। Knowledgator ছোট (~44M), বেস (~86M), এবং লার্জ (~304M) ভেরিয়েন্ট সরবরাহ করে; NVIDIA অক্টোবর ২০২৫-এ একটি 570M ভেরিয়েন্ট রিলিজ করেছে।
- 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 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) ডেডিকেটেড-ফিল্টার ক্লাসে নেতৃত্ব দিচ্ছে, পাবলিক বেঞ্চমার্কে সমান বা এগিয়ে আছে এবং বহুভাষিক ক্ষেত্রে দ্বিতীয় অবস্থানে রয়েছে। ক্ষুদ্রতম টেস্টে (PrivacyBench PD-25, মাত্র ২৫টি প্রশ্ন) Caiioo এবং openai/privacy-filter ৯৬.২%-এ টাই করেছে। বহুভাষিক ক্ষেত্রে, openai/privacy-filter ৯৪.৯% নিয়ে এগিয়ে আছে এবং Caiioo ৯২.৬%-এ রয়েছে — যে ভাষায় আমরা সবচেয়ে পিছিয়ে আছি তা হলো চীনা; অন্য সব জায়গায় আমরা শীর্ষে বা তার কাছাকাছি আছি। যদি বহুভাষিক কভারেজ অত্যন্ত গুরুত্বপূর্ণ হয়, তবে openai/privacy-filter একটি ভালো বিকল্প। অন্য বেশিরভাগ কাজের জন্য Caiioo সেরা।
HIPAA ফলাফলটি সবচেয়ে উল্লেখযোগ্য। Caiioo-এর উভয় HIPAA মোড প্রতিটি HIPAA টেস্টে ১০০% রিকল অর্জন করেছে — প্রতিটি রোগীর নাম, প্রতিটি মেডিকেল রেকর্ড নম্বর, প্রতিটি জন্ম তারিখ, প্রতিটি অ্যাকাউন্ট নম্বর ধরা পড়েছে। দ্বিতীয় সেরা সিস্টেম হলো openai/privacy-filter যা PrivacyBenchHIPAA-তে ৯৩.৭% পেয়েছে — একটি ৬.৩ পয়েন্টের ব্যবধান, এমন একটি বেঞ্চমার্কে যেখানে প্রতিটি মিস মানেই বাস্তব জগতের তথ্য প্রকাশ।
আরেকটি সংখ্যা পড়ার মতো: ওভার-রেডাকশন — এমন জিনিস মাস্ক করা যা আসলে ব্যক্তিগত ডেটা ছিল না। ওভার-রেডাকশন কোনো প্রাইভেসি ক্ষতি নয়, এটি ব্যবহারের খরচ। খুব বেশি জিনিস মাস্ক করলে LLM-এর যুক্তি দেওয়ার ক্ষমতা কমে যায় এবং প্রাপ্ত উত্তরটি নিম্নমানের হয়। Caiioo টেস্ট সেটগুলোতে ১–২৪ বার অপ্রয়োজনীয়ভাবে মাস্ক করেছে। Presidio: ১০–৫১। NVIDIA-এর GLiNER: শুধুমাত্র HIPAA টেস্টেই ৩১–৬৪। যখন লক্ষ্য হয় সর্বনিম্ন এক্সপোজারের সাথে সেরা সম্ভাব্য উত্তর পাওয়া, তখন রিকলের মতোই প্রিসিশন গুরুত্বপূর্ণ।
ফিল্টার হিসেবে শুধু একটি ফ্রন্টিয়ার LLM ব্যবহার করলে কেমন হয়?
তারা পারে — এবং রিকলের ক্ষেত্রে তারা জয়ী হয়। বড় সাধারণ-উদ্দেশ্যের LLM (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B এবং অনুরূপ), ক্লাউডে বা লোকালি চললে বহুভাষিকসহ প্রতিটি টেস্টে ৯৫–১০০% স্কোর করতে পারে। এটি সেইসব ব্যবহারকারীদের জন্য একটি বাস্তব বিকল্প যাদের সর্বোচ্চ রিকল প্রয়োজন এবং এর জন্য মূল্য দিতে রাজি।
তবে এর কিছু বাস্তব অসুবিধা রয়েছে:
- এটি ধীরগতিসম্পন্ন। মিলিসেকেন্ডের পরিবর্তে প্রতি মেসেজে কয়েক সেকেন্ড সময় লাগে। ফিল্টারটি ব্যবহারকারীর পাঠানো প্রতিটি মেসেজের সামনে থাকে।
- হয় মেসেজটি ব্যবহারকারীর মেশিন ছেড়ে চলে যায়, অথবা মডেলটি আসে। ক্লাউডে ফিল্টার করতে হলে মেসেজটি সেখানে পাঠাতে হয় — যা মূল উদ্দেশ্যকেই ব্যাহত করে। অন-ডিভাইস ফিল্টার করতে ১–১৭ GB মডেল ডাউনলোড করতে হয়।
- এটিকে ফাঁকি দেওয়া সম্ভব। একটি জেনারেটিভ মডেলকে মেসেজের মাঝখানে রেড্যাক্ট না করার জন্য রাজি করানো যেতে পারে (একটি "prompt injection" অ্যাটাক)। আমাদের মতো একটি ছোট ক্লাসিফায়ারকে তা করা সম্ভব নয়।
- একই ইনপুট, ভিন্ন আউটপুট। জেনারেটিভ মডেল সবসময় দুবার একই উত্তর দেয় না। এটি রাউন্ড-ট্রিপকে নষ্ট করে দেয় — যাওয়ার পথে মাস্ক করা এবং ফেরার পথে আনমাস্ক করা এই বিষয়ের ওপর নির্ভর করে যে একই আসল ভ্যালু সবসময় একই ফেক ভ্যালুতে ম্যাপ হবে।
Caiioo এই ট্রেডঅফের অন্য দিকের জন্য তৈরি: একটি ক্ষুদ্র, অনুমানযোগ্য, সাব-সেকেন্ড ফিল্টার যা ব্যবহারকারী সেন্ড বাটন চাপার আগে কম্পোজারে চলে এবং যা একটি কথোপকথনের মধ্যে একই আসল ভ্যালুর জন্য সবসময় একই ফেক ভ্যালু তৈরি করে, যাতে রাউন্ড-ট্রিপটি সুসংগত থাকে। এই ধরনের ব্যবহারের ক্ষেত্রে উপরের পিয়ার-ক্লাস টেবিলটিই হলো সঠিক তুলনা।
আসল প্রমাণ কাজের মাধ্যমেই পাওয়া যায়
বেঞ্চমার্কগুলো কেবল একটি শুরুর বিন্দু, শেষ গন্তব্য নয়। ফিল্টারটি Caiioo-এর নতুন ফিচার: pseudonymizer-এর সাথে যুক্ত করা হয়েছে — এই উপাদানটি মূলত কম্পোজার এবং মডেলের মাঝখানে অবস্থান করে।
ব্যবহারকারী যখন সেন্ড (send) বাটনে চাপ দেন, তখন যা ঘটে তা নিচে দেওয়া হলো।
- Detect. প্রথমে রেজেক্স (regex) লেয়ারটি কাজ করে — এটি অত্যন্ত সুনির্দিষ্ট এবং মাইক্রোসেকেন্ডের মতো দ্রুত। এরপর যা অবশিষ্ট থাকে তার ওপর ML মডেল কাজ করে। যদি এই দুটি লেয়ার একই টেক্সটের ওপর ওভারল্যাপ করে, তবে আমরা একটি সহজ নিয়ম অনুসরণ করি: সারফেস ফরম্যাটের ক্ষেত্রে regex প্রাধান্য পায়, আর কনটেক্সটের ক্ষেত্রে ML প্রাধান্য পায়।
- Tag self vs. other. Caiioo এমন আইডেন্টিফায়ারগুলোকে আলাদা করে যা সরাসরি ব্যবহারকারীকে নির্দেশ করে এবং যা অন্য ব্যক্তিদের নির্দেশ করে। ব্যবহারকারী চাইলে কেবল একটি অথবা উভয়ই রিড্যাক্ট (redact) করতে পারেন। ব্যবহারকারী তার ব্যক্তিগত ডিকশনারিতে যে নামগুলো যুক্ত করেছেন, সেগুলো সবসময় "self" হিসেবে গণ্য হয়।
- Substitute. প্রতিটি আসল ভ্যালুর বিপরীতে একটি স্থিতিশীল এবং স্টাইল-ম্যাচড ছদ্মনাম (pseudonym) বসানো হয়। "Sarah Goldberg" হয়ে যায় "Maya Hartwell" — এবং পুরো কথোপকথন জুড়ে এটি "Maya Hartwell" হিসেবেই থাকে, যাতে ওই ব্যক্তিকে নিয়ে মডেলের যুক্তিনির্ভর বিশ্লেষণগুলো বিভিন্ন ধাপে খণ্ডিত না হয়ে যায়। আসল-থেকে-নকল ভ্যালুর একটি লুকআপ টেবিল ব্যবহারকারীর ডিভাইসে সংরক্ষিত থাকে, যা প্ল্যাটফর্মের কি-চেইন (keychain) থেকে প্রাপ্ত একটি কি (key) দিয়ে এনক্রিপ্ট করা থাকে।
- Send. মডেলটি সম্পূর্ণ একটি ফেক বা নকল মেসেজ গ্রহণ করে। কোনো আসল আইডেন্টিফায়ার কখনোই নেটওয়ার্ক অতিক্রম করে না এবং আমাদের অডিট লগ কেবল সংখ্যা রেকর্ড করে — কখনোই ভ্যালুগুলো নিজে নয়।
- Restore. স্ট্রিমিং রেসপন্স আসার সাথে সাথেই সেটিকে পুনরায় আগের অবস্থায় ম্যাপ করা হয়। মডেলের উত্তরের "Maya Hartwell" স্ক্রিনে পৌঁছানোর আগেই "Sarah Goldberg"-এ রূপান্তরিত হয়, যা একটি ছোট গ্লো পিল (glow pill) দিয়ে রেন্ডার করা হয় যাতে ব্যবহারকারী এক পলকেই বুঝতে পারেন কী সুরক্ষিত করা হয়েছে।
- Restore tool arguments too. যদি মডেল কোনো টুল কল করে — যেমন ইমেল পাঠানো, টিকিট ফাইল করা, বা কোনো ডক-এ লেখা — এবং আর্গুমেন্টগুলোতে যদি ফেক ভ্যালু থাকে, তবে টুলটি রান করার আগেই আমরা আসল ভ্যালুগুলো পুনরায় বসিয়ে দিই। মডেল ফেক ভ্যালুর ওপর ভিত্তি করে যুক্তি সাজায়; কিন্তু অ্যাকশনটি আসল ভ্যালু গ্রহণ করে।
ফিল্টারটি কোন AI সার্ভিস ব্যবহার করা হচ্ছে তার তোয়াক্কা করে না। মেসেজটি মডেলে পৌঁছানোর আগেই এটি কাজ করে, তাই OpenRouter, Anthropic, Google, OpenAI এবং লোকাল Ollama সবাই একই ধরনের মাস্কড পেলোড (masked payload) পায়। নতুন কোনো প্রোভাইডার যুক্ত করলেও প্রাইভেসির এই সুরক্ষা বলয় ভেঙে যায় না।
কাদের সুরক্ষা দেয়
ব্যবহারকারীকে। ব্যবহারকারীর নাম, ইমেল, ঠিকানা, ফোন, IP এবং বায়োমেট্রিক আইডেন্টিফায়ার — যে বিষয়গুলো একত্রে একজন ব্যক্তিকে শনাক্ত করতে পারে — ফিল্টার চালু থাকলে সেগুলো কখনোই ডিভাইস থেকে বের হয় না।
যাদের সম্পর্কে ব্যবহারকারী কথা বলেন। বেশিরভাগ গোপনীয়তা টুল টাইপ করা ব্যক্তির ওপর ফোকাস করে, কিন্তু তারা 'সামাজিক চুক্তি' উপেক্ষা করে — অর্থাৎ আমাদের নিজেদের পাশাপাশি অন্যদের প্রতিও দায়িত্ব রয়েছে। কোনো LLM-এ "মিস্টার সন্ডার্সের অযোগ্যতার জন্য তার আচরণ বিশ্লেষণ করুন" সাবমিট করা, যেখানে এটি অনির্দিষ্টকালের জন্য সিস্টেম লগে রেকর্ড হতে পারে, তা দায়িত্বজ্ঞানহীন (এবং সম্ভাব্য মানহানিকর)। ১,০০০ বিজনেস কন্টাক্ট আছে এমন একটি Google Sheet-এর জন্য LLM-এর সাহায্য চাওয়া মানে সেগুলোকে ডেটা-রিটেনশন জালে ফেলে দেওয়া। Caiioo-এর ফিল্টার থার্ড পার্টিদেরও কভার করে: যে ক্লায়েন্টের জন্য চুক্তি তৈরি করা হচ্ছে, যে রোগীর রেকর্ড বিশ্লেষণ করা হচ্ছে, বা যে সহকর্মীর ইমেল কনটেক্সটে পেস্ট করা হয়েছে। তারা তাদের আইডেন্টিফায়ার রিমোট LLM-কে দেখার অনুমতি দেয়নি। ফিল্টার ডিফল্টভাবে সেটি সম্মান করে; কাজের প্রয়োজনে ব্যবহারকারী চাইলে এটি "self only" বা "others only"-তে পরিবর্তন করতে পারেন।
প্রতিষ্ঠান — ব্যবসা, হাসপাতাল, ফার্ম। অ্যাকাউন্ট নম্বর, লাইসেন্স নম্বর, মেডিকেল রেকর্ড নম্বর, ফিন্যান্সিয়াল রাউটিং ডিটেইলস, ইন্টারনাল ID, API কী, কাস্টমার তালিকা। একজন ব্যক্তির মতো একটি ব্যবসারও ডেটা-মিনিমাইজেশন স্বার্থ রয়েছে। Caiioo ব্যবহার করে ডিসচার্জ নোট ড্রাফট করা একজন চিকিৎসক রোগীর মেডিকেল রেকর্ড নম্বর OpenAI-তে পাঠাচ্ছেন না। একজন আইনজীবী ক্লায়েন্টের অ্যাকাউন্ট নম্বর Anthropic-এ পাঠাচ্ছেন না। একজন সাপোর্ট ইঞ্জিনিয়ার কাস্টমার লগ থেকে API কী Google-এ পাঠাচ্ছেন না। ফিল্টারটি আইডেন্টিফায়ারটি কোনো ব্যক্তির নাকি প্রতিষ্ঠানের তা বিচার করে না — এটি কেবল সেটিকে ডিভাইসেই রাখে।
সর্বোচ্চ উপযোগিতা, সর্বনিম্ন প্রকাশ
মূল লক্ষ্য হলো ব্যবহারকারী যেন ফিল্টারটির উপস্থিতি অনুভব না করেন।
বেশিরভাগ গোপনীয়তা টুল একটি কঠিন পছন্দ করতে বাধ্য করে: কঠোরভাবে রিড্যাক্ট করুন এবং মডেলের উত্তরের মান কমতে দেখুন, অথবা প্রম্পট ব্যবহারযোগ্য রাখুন এবং গোপনীয়তার প্রতিশ্রুতি নষ্ট হতে দেখুন। আমরা এই আপস প্রত্যাখ্যান করেছি। মডেলটি এখনও একটি পূর্ণাঙ্গ প্রম্পট পায় — এটি সঠিক ব্যাকরণগত অবস্থানে নাম, স্থান, তারিখ, মেডিকেল রেকর্ড নম্বর দেখতে পায়। এটি কেবল নকল তথ্য দেখে। এর যুক্তি বা বিশ্লেষণ অভিন্ন থাকে; শুধু স্ট্রিংগুলো পরিবর্তন করা হয়।
স্টেবল সাবস্টিটিউশন (Stable substitution) এটি সম্ভব করে। যেহেতু একটি কথোপকথনে একই আসল মানের জন্য সবসময় একই নকল মান ম্যাপ করা হয় — ব্যবহারকারীর মেসেজ, টুলের রেজাল্ট এবং মডেলের আগের উত্তর সবখানেই — তাই মডেলটি একজন ব্যক্তি বা স্থান সম্পর্কে সুসংগতভাবে চিন্তা করতে পারে। মাল্টি-টার্ন কথোপকথন এলোমেলো হয়ে যায় না। টুল কল নষ্ট হয় না। সাব-এজেন্টরা মূল কথোপকথনের ম্যাপ উত্তরাধিকার সূত্রে পায় এবং পুরো টাস্ক জুড়ে সামঞ্জস্য বজায় রাখে।
ব্যবহারকারী যে আউটপুট দেখেন তা হলো আসল কথোপকথন। প্রোভাইডার যে ডেটা দেখে তা হলো একটি সুসংগত কাল্পনিক তথ্য। এই দুই দৃশ্যের মাঝখানের ফাঁকা জায়গায় কাজটি সম্পন্ন হয় এবং আমাদের একমাত্র লক্ষ্য হলো সেই ফাঁকা জায়গাটিকে অদৃশ্য করে তোলা।
একটি গোপনীয়তা ফিল্টার যা কাজের পথে বাধা হয়ে দাঁড়ায়, তা বন্ধ করে দেওয়া হবে। একটি গোপনীয়তা ফিল্টার যা কাজের ধারার সাথে মিশে যায়, সেটিই কেবল ব্যবহারের যোগ্য।
আমরা সেই মানদণ্ডেই এটি তৈরি করেছি।