نظير Jev موجود بالفعل لدى OpenAI وGemini: ما الذي يحمي الشركة الناشئة حين ينسخ الذكاء الاصطناعي كل شيء

تبني شركة ناشئة أداة ناجحة، وبعد فترة تظهر ميزة مشابهة في واجهات API التابعة للمختبرات الكبرى. هذا ما حدث بالفعل مع Jev، وهو مصنّف رخيص وسريع: فقد طرحت OpenAI وGemini نظائر له. يقول المتابعون إن معايرتها ما زالت أضعف من النموذج الأصلي، لكنها صالحة للاستخدام الآن.

ما الذي نُسخ بالضبط

المصنّف نموذج صغير وسريع. هو لا يكتب مقالات، بل يجيب عن سؤال ضيق: إلى أي فئة ينتمي الطلب، وهل تُمرَّر الرسالة، وهل يلزم التصعيد. لا حاجة إلى نموذج كبير لمثل هذه المهام، ولذلك يحسمها عاملا السرعة والسعر. تُظهر الروابط الواردة في المنشور أن وثائق OpenAI وكذلك AI Studio من Google باتت تتضمن أقسامًا عن decisions، أي عن فئة مشابهة من المهام.

والخلاصة العملية بسيطة. إذا بنيتم جزءًا من منتجكم حول تصنيف رخيص، فقد صار أمامكم خيار جديد. لكن تحقّقوا من المعايرة على بياناتكم أنتم، فبحسب الآراء هنا تتأخر النسخ حاليًا عن الأصل.

يُنسخ كل ما يستحق النسخ

يؤكد صاحب القناة أن هذا سيحدث مع أي شركة ناشئة واعدة. وفي أسوأ الأحوال يمكن توجيه وكيل برمجي (ذكر المنشور Fable وAstra) إلى المنتج نفسه وإلى جميع منشورات الشركة العلنية، وطلب تكرار التقنية. والنموذج سيفعل ذلك.

الاعتراضات معروفة. هل سيكرّر 100% من الوظائف؟ ولماذا تحتاجون إلى 100% إذا كان المطلوب 10% فقط؟ ومن سيتولى الصيانة؟ النموذج نفسه. يمكن الطعن في كل جواب من هذه الأجوبة، لكنها ستكفي كثيرًا من المشترين.

ولا يتحدث المؤلف عن الأمر نظريًا. فريقه في BitGN يبني Company Brain ويبدأ بالفعل بتطبيقه في شركات أخرى. وخلف النظام 9 أشهر من البحث والتطوير والتحسين. ويعرف يقينًا أن أكثر من فريق وجّه Fable أو Codex إلى كل المواد وواجهات API المتاحة لتكرار النظام. ولا سبيل إلى إيقاف ذلك: الملفات التنفيذية تتسرب، ومن واجهات API والوثائق تُستعاد المصادر وتُعاد كتابتها.

أين نبحث إذن عن الحماية

خلاصة المؤلف أن الميزة التنافسية ينبغي ألا تقوم على الإغلاق. وقد نشر بنفسه الكلمات المفتاحية للطبقة التقنية في Company Brain: FoundationDB وLMDB، والاختبار الحتمي (deterministic testing)، وحقن الأعطال (fault injection) وإعادة التشغيل (replay)، ومجموعات التغييرات غير القابلة للتعديل (immutable changesets)، وعزل اللقطات (snapshot isolation)، وOCC، والتفويض القائم على القدرات (capability-based)، وحزم SDK ذات إصدارات لكل شركة، والبحث الذي يراعي صلاحيات الوصول، وتدقيق منشأ البيانات. وهذا جزء صغير من القائمة. يستطيع أي وكيل قراءتها، ويرى المؤلف أن ذلك طبيعي.

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

يخطط الفريق حاليًا للإصدار التالي من Company Brain ليتوسع بصورة أفضل في الشركات الكبيرة.

ماذا نفعل بذلك عمليًا

ثلاثة أسئلة ينبغي طرحها على الفريق قبل الإطلاق لا بعده:

• إذا قرأ الوكيل واجهة API والوثائق والمدونة لدينا، فما الذي في المنتج لن يستطيع تكراره؟
• ما الذي يتراكم لدينا مع الوقت ولا يوجد في المستودع: البيانات، وخبرة التطبيق، والمعايرة على حالات واقعية، وثقة العملاء؟
• هل نستطيع كشف المعمارية بهدوء؟ إن لم نستطع، فربما لا خندق لدينا.

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

القيود

هذا رأي ممارس صاحب مصلحة: فهو يبيع تقنيته الخاصة، ولا يورد المنشور أرقامًا عن مدى إحلال النسخ فعليًا محل الأصل. وعن نظائر Jev لا يوجد سوى «يقول الناس»، دون قياسات مستقلة للمعايرة. كما أن فرضية «نحتاج فقط إلى 10% من الوظائف» لا تناسب الجميع: ففي القطاعات الخاضعة للتنظيم والتكاملات المعقدة تكون الشمولية مهمة. لكن الاتجاه واضح: إذا كان الوكيل يكرّر المنتج انطلاقًا من الوثائق، فلم يعد الرهان وحده على «نحن الأوائل» يحمي.