#OPG قبل الشهر الماضي تلقيت مشروعًا خاصًا لتحليل بيانات على السلسلة. طلب الطرف الآخر مني تشغيل نموذج تجميع (Clustering) لسلوك التفاعل التاريخي لمحفظة “عملاق الجُيّرة”. لكن مصدر البيانات يتضمن سجلات تفاعل من أكثر من اثني عشر بروتوكولًا. إجمالي السجلات يقارب أكثر من عشرين ألفًا. والأهم من ذلك أن الطرف الآخر قال بوضوح إن عنوانات هذه المحافظ وتفاصيل المعاملات لا يجوز الإفصاح عنها. كان ردي الأولي هو استخدام عقد الاستدلال في <OpenGradient> عبر بيئة تنفيذ موثوقة (TEE)، لأن بيئة التنفيذ الموثوقة يمكنها ضمان أن البيانات تبقى مُشفّرة بالكامل طوال عملية الحساب، بحيث لا يمكن لمشغّل العقد الاطلاع على المدخلات الأصلية. كل ما احتجته هو تشفير البيانات عبر الـ SDK ثم إرسالها. بعد تشغيل النموذج، يتم إرجاع النتائج مع تقرير اعتماد/توثيق للأجهزة يثبت أن عملية الحساب لم يتم العبث بها. استغرق كامل الإجراء ما لا يزيد عن عشرين دقيقة تقريبًا، وكان أسرع بنحو الضعف مقارنةً بتجهيزي للتشغيل محليًا بنفسي. والأهم أن تقرير الاعتماد يمكن إرساله مباشرة للطرف الآخر كدليل على أمان البيانات، ما يوفر عناء الشرح المتبادل.
عندما كنت أتعامل سابقًا مع هذه البيانات الحساسة كنت دائمًا في حالة توتر، أخشى حدوث تسرب في أي مرحلة. إما أن أضطر لقضاء وقت طويل في عمليات إزالة/تقليل الحساسية (de-sensitization)، لكن دقة النتائج بعد إزالة الحساسية كانت تتراجع بشكل كبير. الآن، باستخدام حل <OpenGradient>، تصبح مشكلة الثقة محمولة على الإثبات عبر العتاد بدلًا من وعود شفوية من الأشخاص. هذا مفيد جدًا بالنسبة لي. ومع زيادة مرات الاستخدام، لاحظت أيضًا أنه لا يحل فقط مشكلة الخصوصية للبيانات، بل يجعل سير العمل كاملًا قابلًا للتتبع وقابلًا للتحقق.
في السابق، أدوات الذكاء الاصطناعي كانت إذا أدخلت لها بيانات “تختفي” النتائج ولا تعرف ما الذي مرّ به النظام بالفعل. لكن <OpenGradient> في كل مرة استدلال يرفق توقيعًا مشفرًا. يمكنك دائمًا العودة والتحقق مما إذا كانت النتيجة ناتجة فعلًا عن إصدار النموذج ذاته. إن هذا النوع من الشفافية له قيمة كبيرة في سيناريوهات التسليم التجاري. على الأقل عندما يشكك الآخرون في نتائجك، يمكنك تقديم دليل على السلسلة لإثبات ما حدث.
أنا حاليًا حوّلت جميع مهام التحليل الحساسة من هذا النوع إلى <@OpenGradient > للتشغيل. عند حساب التكلفة، كانت أقل قليلًا من استئجار عُقد GPU تقليدية، لأن كفاءة جدولة الحوسبة فيه أعلى، والهدر الناتج عن الموارد غير المستخدمة أقل. إذا كانت هناك لاحقًا احتياجات لتنظيف المزيد من البيانات أو ضبط (fine-tuning) النماذج، أخطط أيضًا لمواصلة استخدام هذا الحل. أما تلك الـ <$OPG > التي جمعتها فسأحتفظ بها كـ “وقود” لشبكة الاستخدام في المستقبل.
$ETH $BTC
عندما كنت أتعامل سابقًا مع هذه البيانات الحساسة كنت دائمًا في حالة توتر، أخشى حدوث تسرب في أي مرحلة. إما أن أضطر لقضاء وقت طويل في عمليات إزالة/تقليل الحساسية (de-sensitization)، لكن دقة النتائج بعد إزالة الحساسية كانت تتراجع بشكل كبير. الآن، باستخدام حل <OpenGradient>، تصبح مشكلة الثقة محمولة على الإثبات عبر العتاد بدلًا من وعود شفوية من الأشخاص. هذا مفيد جدًا بالنسبة لي. ومع زيادة مرات الاستخدام، لاحظت أيضًا أنه لا يحل فقط مشكلة الخصوصية للبيانات، بل يجعل سير العمل كاملًا قابلًا للتتبع وقابلًا للتحقق.
في السابق، أدوات الذكاء الاصطناعي كانت إذا أدخلت لها بيانات “تختفي” النتائج ولا تعرف ما الذي مرّ به النظام بالفعل. لكن <OpenGradient> في كل مرة استدلال يرفق توقيعًا مشفرًا. يمكنك دائمًا العودة والتحقق مما إذا كانت النتيجة ناتجة فعلًا عن إصدار النموذج ذاته. إن هذا النوع من الشفافية له قيمة كبيرة في سيناريوهات التسليم التجاري. على الأقل عندما يشكك الآخرون في نتائجك، يمكنك تقديم دليل على السلسلة لإثبات ما حدث.
أنا حاليًا حوّلت جميع مهام التحليل الحساسة من هذا النوع إلى <@OpenGradient > للتشغيل. عند حساب التكلفة، كانت أقل قليلًا من استئجار عُقد GPU تقليدية، لأن كفاءة جدولة الحوسبة فيه أعلى، والهدر الناتج عن الموارد غير المستخدمة أقل. إذا كانت هناك لاحقًا احتياجات لتنظيف المزيد من البيانات أو ضبط (fine-tuning) النماذج، أخطط أيضًا لمواصلة استخدام هذا الحل. أما تلك الـ <$OPG > التي جمعتها فسأحتفظ بها كـ “وقود” لشبكة الاستخدام في المستقبل.
$ETH $BTC