كيف يؤثر تنظيف البيانات الشخصية على وكلاء LLM: تجربة Hivetrace Dataclean

تنظيف البيانات الشخصية قبل إرسالها إلى وكيل LLM يبدو عادة خطوة واضحة نحو الأمان، لكن تكلفة هذا الحل ليست دائماً واضحة. في مقال في Habr AI، اختبر المؤلفون مقدار التغيير في عمل وكيل مصرفي إذا تلقى أقنعة أو أسماء مستعارة بدلاً من الأسماء الكاملة الحقيقية والمعرفات الأخرى.

حيث ينشأ الصراع في وكلاء LLM

يعمل وكلاء LLM بشكل متزايد مع سيناريوهات المستخدم حيث البيانات الشخصية ضرورية: الطلبات المصرفية والدعم والتأمين والمستندات وسجل المعاملات. في هذه النقطة، تواجه كل فريق خياراً بين خطرين. الأول — نقل البيانات الحساسة إلى النموذج كما هي والتعامل مع أسئلة الخصوصية والامتثال والأمان الداخلي. الثاني — تنظيف الإدخال لكن فقدان جزء من السياق الذي يعتمد عليه الوكيل منطقه واكتشاف العلاقات بين الكيانات ودقة الإجراءات.

"إلى أي مدى يتدهور الوكيل إذا رأى 'PERSON_1' أو 'XXXXXXXX' بدلاً من

'إيفانوف إيفان'؟"

في الواقع العملي، هذا ليس جدلاً أكاديمياً بل مهمة هندسية. إذا توقف النظام عن فهم أن نفس العميل يظهر في عدة أماكن في الطلب، فإن ذلك يؤثر ليس فقط على جودة النص بل على منطق العمل: توجيه الحالات والتحقق من بيانات الاعتماد وتفسير الحالات والتحقق من تسلسل الخطوات. لذلك، السؤال ليس أطروحة عامة "إخفاء الهوية مفيد" أو "إخفاء الهوية يعيق" بل إجابة قابلة للقياس لفئة محددة من الوكلاء وطريقة محددة للتنظيف.

كيف تم اختبار الفرضية

لاختبار الفرضية، نشر المؤلفون وكيل مصرفي بسيط وقاموا بدمج Hivetrace Dataclean معه. ثم أرسلوا للوكيل 102 طلب تركيبي في ثلاث متغيرات لبيانات الإدخال: بدون تعديل وبالإخفاء والأسماء المستعارة. هذا التصميم مفيد لأنه يزيل الضوضاء من سجلات المستخدمين الحقيقية ويوفر مقارنة يتم التحكم فيها. في كل حالة، يحل الوكيل نفس المهمة لكنه يرى أشكالاً مختلفة من المعرفات والأسماء والسمات الشخصية الأخرى.

طريقة التقييم مهمة بشكل خاص. استخدم المؤلفون DeepEval في وضع LLM-as-a-judge، أي أنهم قارنوا ليس الانطباعات الذاتية من زوج من الردود بل حاولوا توسيم الجودة من خلال حلقة تحقق واحدة. بالنسبة للبحث التطبيقي السريع، هذا نهج معقول: لا يجعل الاستنتاجات "حقيقة مطلقة" لكنه يسمح برؤية حيث يكون التدهور ملحوظاً مباشرة وحيث يحتفظ الوكيل بالفائدة حتى بعد تنظيف الحقول الحساسة.

ثلاثة أوضاع للبيانات

جوهر التجربة ليس مجرد التحقق مما إذا كان الوكيل "يعمل أم لا يعمل" بعد إخفاء الهوية، بل مقارنة مستويات مختلفة من فقدان السياق. هذا مهم بشكل خاص لأنظمة LLM التي تعتمد ليس فقط على معنى الكلمات بل على العلاقات المستقرة بين الكيانات داخل حوار أو مستند واحد. الإخفاء الكامل والأسماء المستعارة تبدو متشابهة للنموذج فقط للوهلة الأولى: في المهمة الفعلية، هذه إشارات مختلفة.

• البيانات النظيفة — السيناريو الأساسي بدون تشويه.
• إخفاء مثل XXXXXXXX — أقصى خصوصية وأقل دلالة.
• أسماء مستعارة مثل PERSON_1 — تخفي الهوية لكن تحافظ على العلاقات.
• 102 طلب تركيبي لكل وضع — فرصة للمقارنة النزيهة.

من مثل هذا الاختبار، تحصل الفريق عادة على ليس حظراً عاماً أو إذن بل خريطة المقايضات. إذا كان الوكيل يحتاج فقط على القصد العام للمستخدم، قد يكون الإخفاء الصارم مقبولاً. إذا اعتمد المنطق على نفس الكائن يتكرر عبر عدة أجزاء، فغالباً ما تبدو الأسماء المستعارة خياراً أكثر عملياً. هذا هو بالضبط السبب في أن هذه الفحوصات مفيدة بشكل خاص قبل نشر الوكلاء في البنوك والعاملين في التكنولوجيا المالية والطب وأي عملية حيث الأخطاء على البيانات الشخصية تصبح مكلفة بسرعة.

ما يعنيه ذلك

الاستنتاج الرئيسي من المقال هو أن سؤال إخفاء الهوية لوكلاء LLM لا يمكن حله على مستوى الحدس. قبل الإنتاج، تحتاج إلى قياس منفصل لكيفية تأثير طريقة التنظيف المحددة على سيناريو محدد: فهم الطلبات والحفاظ على العلاقات بين الكيانات والجودة الإجمالية للرد. بالنسبة للفريق الذي يبني وكلاء AI في المجالات الحساسة، هذا لم يعد خياراً بل جزء أساسي من الهندسة المعمارية وحلقة الاختبار.