@SpaceandTime بدأ الذكاء الاصطناعي يشتري البيانات بنفسه، لكنه لا يعرف حتى أنه أخطأ في الحساب
خلال اليومين الماضيين، ربطتُ وكيلًا للاستعلام عن البيانات ببيئة تجريبية وطرحْت عليه عشرات الأسئلة. أكثر ما أزعجني لم يكن إجاباته الخاطئة، بل أن نبرته عند الخطأ مطابقة تمامًا لنبرته عند الإجابة الصحيحة. إصدار Enterprise الذي أطلقته Space and Time في 9 نوفمبر يصيب هذا الجانب المؤلم تحديدًا. الفكرة بسيطة: تُجرى العمليات الحسابية على بيانات خاصة، وتُنتَج إيصال مشفّر باسم Proof of SQL، ثم يتحقق التطبيق من الإيصال قبل تمرير النتيجة إلى الوكيل، وبعد التحقق يُسمح للوكيل بالتصرف. تبقى البيانات داخل قاعدة البيانات، ويمكن التحقق من عملية الحساب. هذه العبارة ستصبح باهظة القيمة عندما تبدأ الوكلاء باستدعاء واجهات API من تلقاء نفسها.
المسار الذي جرّبته بنفسي كان أن أضيف جدولًا من بيانات العمل، ثم أرسل استعلامًا باستخدام SDK، وأحصل على النتيجة والإثبات، وبعدها أتحقق منهما في عقد على السلسلة. استغرق إنجاح العملية للمرة الأولى نحو نصف يوم. لم تكن العقبة في التشفير، بل في إعداد البيئة وفي ضرورة أن تحدد مسبقًا أي جدول يستحق إثباته. هذا الحاجز موجود فعلًا، لكنه يمنحك شيئًا مهمًا جدًا: لم تعد صحة النتيجة تعتمد على الشخص الذي تثق به.
مقارنةً بحلول تقديم الأسعار من نوع Chainlink، فهي تخبرك بقيمة رقم ما الآن، أما SXT فتخبرك بالمعيار المستخدم لحسابه والجدول الذي حُسب منه. وبالمقارنة مع لوحات العرض المخصصة للقراءة فقط مثل Dune، فالفرق أن الأخيرة لا تستطيع أن تقدم لك سوى لقطة شاشة، بينما الأولى تستطيع أن تقدم لك إيصالًا. اتخاذ الذكاء الاصطناعي قراراته اعتمادًا على لقطة شاشة مسألة وقت لا أكثر قبل أن تقع المشكلة.
وهناك أثر جانبي لم يخطر ببالي في البداية. بوجود الإثبات، يمكن إعادة تشغيل كل قرار يتخذه الوكيل، وعند وقوع مشكلة يمكن تحديد الاستعلام بعينه والبيانات التي استخدمها. يصبح تحديد المسؤولية أنظف من تقليب السجلات، لكنه أيضًا أغلى. لذلك لا أهتم كثيرًا بمدى رواج القصة التي يرويها الآن. ما يهمني هو: عندما يبدأ الوكيل فعلًا باستدعاء واجهات API وإنفاق المال لشراء البيانات، من سيتمكن من فرض رسوم مرور عند طبقة الإيصال؟ #sxt $SXT
خلال اليومين الماضيين، ربطتُ وكيلًا للاستعلام عن البيانات ببيئة تجريبية وطرحْت عليه عشرات الأسئلة. أكثر ما أزعجني لم يكن إجاباته الخاطئة، بل أن نبرته عند الخطأ مطابقة تمامًا لنبرته عند الإجابة الصحيحة. إصدار Enterprise الذي أطلقته Space and Time في 9 نوفمبر يصيب هذا الجانب المؤلم تحديدًا. الفكرة بسيطة: تُجرى العمليات الحسابية على بيانات خاصة، وتُنتَج إيصال مشفّر باسم Proof of SQL، ثم يتحقق التطبيق من الإيصال قبل تمرير النتيجة إلى الوكيل، وبعد التحقق يُسمح للوكيل بالتصرف. تبقى البيانات داخل قاعدة البيانات، ويمكن التحقق من عملية الحساب. هذه العبارة ستصبح باهظة القيمة عندما تبدأ الوكلاء باستدعاء واجهات API من تلقاء نفسها.
المسار الذي جرّبته بنفسي كان أن أضيف جدولًا من بيانات العمل، ثم أرسل استعلامًا باستخدام SDK، وأحصل على النتيجة والإثبات، وبعدها أتحقق منهما في عقد على السلسلة. استغرق إنجاح العملية للمرة الأولى نحو نصف يوم. لم تكن العقبة في التشفير، بل في إعداد البيئة وفي ضرورة أن تحدد مسبقًا أي جدول يستحق إثباته. هذا الحاجز موجود فعلًا، لكنه يمنحك شيئًا مهمًا جدًا: لم تعد صحة النتيجة تعتمد على الشخص الذي تثق به.
مقارنةً بحلول تقديم الأسعار من نوع Chainlink، فهي تخبرك بقيمة رقم ما الآن، أما SXT فتخبرك بالمعيار المستخدم لحسابه والجدول الذي حُسب منه. وبالمقارنة مع لوحات العرض المخصصة للقراءة فقط مثل Dune، فالفرق أن الأخيرة لا تستطيع أن تقدم لك سوى لقطة شاشة، بينما الأولى تستطيع أن تقدم لك إيصالًا. اتخاذ الذكاء الاصطناعي قراراته اعتمادًا على لقطة شاشة مسألة وقت لا أكثر قبل أن تقع المشكلة.
وهناك أثر جانبي لم يخطر ببالي في البداية. بوجود الإثبات، يمكن إعادة تشغيل كل قرار يتخذه الوكيل، وعند وقوع مشكلة يمكن تحديد الاستعلام بعينه والبيانات التي استخدمها. يصبح تحديد المسؤولية أنظف من تقليب السجلات، لكنه أيضًا أغلى. لذلك لا أهتم كثيرًا بمدى رواج القصة التي يرويها الآن. ما يهمني هو: عندما يبدأ الوكيل فعلًا باستدعاء واجهات API وإنفاق المال لشراء البيانات، من سيتمكن من فرض رسوم مرور عند طبقة الإيصال؟ #sxt $SXT
