مطالبات مقيّدة بإحكام بواجهة Google API، وأقواس في كل مكان: براءة اختراع يبدو أنها من توليد الذكاء الاصطناعي

قرأت مؤخرًا مجموعة من مطالبات براءة اختراع، وكلما تقدّمت في القراءة ازداد تقطيب حاجبيّ. فالمطالبات بعد التعديل لم تكتفِ بربط الخصائص التقنية ربطًا محكمًا بواجهة Google API بعينها، بل حُشرت في المطالبة المستقلة أيضًا كومة كبيرة من الإضافات بين قوسين. وأمام كتابة كهذه، كان أول ما خطر في بالي: هذه على الأرجح مسودة وُلِّدت بالذكاء الاصطناعي.

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

طريقة لمعالجة المعلومات قائمة على واجهة حوارية، يُنفّذها خادم مزوّد بمعالج واحد على الأقل، وتشمل:

(a) استقبال أمر غير مهيكل (نص بلغة طبيعية، أو تحويل الصوت إلى نص، أو رسالة وسائط متعددة) يُصدره المستخدم عبر برنامج مراسلة فورية (مثل LINE أو Messenger أو Slack أو غيرها من المنصات ذات وظيفة الاستدعاء الراجع Webhook)؛

(b) إرساله إلى نموذج ذكاء اصطناعي أول (مثل نموذج LLM بمعمارية Transformer) لتنفيذ تحليل النية، وإخراج أمر مهيكل (مثل JSON) يتضمن نية المهمة (البحث، التلخيص، الدمج) ومعاملًا أولَ واحدًا على الأقل (كلمة مفتاحية، نطاق زمني، نوع ملف)؛

(c) قيام وحدة منطق التوجيه، بحسب نية المهمة، بالتحديد الذاتي والاستدعاء الديناميكي لواجهة برمجة تطبيقات واحدة على الأقل لخدمة تخزين سحابي (مثل Google Drive API) بوصفها مصدر معلومات داخليًا، ولواجهة برمجة تطبيقات محرك بحث على الإنترنت (مثل Google Search API) بوصفها مصدر معلومات خارجيًا، للحصول على التوالي على معلومات ملخّصة عن الملفات الخاصة (ملخصات دلالية متجهية أو مقاطع نصية أساسية) وعلى نتائج بحث عامة (عناوين صفحات الويب، أو مقتطفات الملخصات، أو نصوص المواد الصوتية والمرئية)؛

(d) تنظيف بيانات الطرفين وتنسيقها، ودمجها في سياق شامل مهيكل (Context)، وتحسين ترتيبها وفقًا لحدّ نافذة السياق في النموذج؛

(e) إرسال السياق الشامل والأمر المهيكل إلى نموذج ذكاء اصطناعي ثانٍ (قد يكون مطابقًا للنموذج الأول أو مختلفًا عنه) لإجراء التوليف والاستدلال وإعادة التركيب، وتوليد ناتج نهائي من معلومات مدمجة بعمق (تقرير مهيكل، أو ملخص مصوّر، أو رسالة رد)، وإعادته إلى المستخدم عبر واجهة برمجة تطبيقات دفع الرسائل الخاصة ببرنامج المراسلة الفورية.

موضعان يبعثان على القلق بمجرد رؤيتهما

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

المشكلة الثانية أن المطالبة المستقلة محشوّة بالأقواس. الأقواس في الأصل تُستعمل للتمثيل أو للإضافة، لكن حين يظهر في مطالبة مستقلة واحدة هذا الكمّ من الإضافات المتراكمة طبقة فوق طبقة، تُقرأ وكأن أحدهم أفرغ فيها دفعة واحدة كل الاحتمالات التي خطرت في ذهنه، دون أن يفكّر حقًا على نحو واضح في السؤال: أيٌّ منها هي الخصائص التقنية التي لا غنى عنها لتحديد الاختراع؟

هذه في الحقيقة ظاهرة من ظواهر العصر

ما أريد الحديث عنه ليس الإشارة إلى قضية بعينها، بل الظاهرة العامة التي تكشف عنها هذه الطريقة في الكتابة.

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

وغير المتخصص، حين يرى مطالبة مكتوبة بطول واكتمال، يميل إلى الظن بأن «الحماية شاملة»؛ لكن المشكلة الحقيقية كثيرًا ما تختبئ تحديدًا في هذا «الظهور بمظهر المكتمل». فنطاق البراءة لا تزداد قيمته كلما ازدادت كلماته، بل إن كل خاصية تقنية تُكتب فيه تتحول إلى حبل يلتفّ حول صاحبها حين يحين وقت المطالبة بالحق.

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