تلعب واجهات برمجة التطبيقات (APIs) دورًا متزايد الأهمية في كل من العالمين الظاهري والمادي بفضل تطوير التقنيات مثل الهندسة المعمارية الموجهة للخدمة والحوسبة السحابية وإنترنت الأشياء (IoT). شارك زملائنا من قسم Microsoft Research اليوم أفضل ممارساتهم في مجال واجهات اللغة الطبيعية (واجهات اللغة الطبيعية). انضم الآن!
توفر خدمات الويب السحابية والويب والطقس والرياضة والتمويل البيانات والخدمات للمستخدمين النهائيين عبر واجهة برمجة تطبيقات الويب ، بينما تتيح أجهزة إنترنت الأشياء للأجهزة الأخرى على الشبكة استخدام وظائفها.
عادة ، يتم استخدام واجهات برمجة التطبيقات في برامج مختلفة: تطبيقات سطح المكتب ومواقع الويب وتطبيقات الهاتف المحمول. كما أنها تخدم المستخدمين من خلال واجهة مستخدم رسومية (GUI). ساهمت الواجهات الرسومية بشكل كبير في تعميم أجهزة الكمبيوتر ، ولكن مع تطور تكنولوجيا الكمبيوتر ، أصبحت قيودها العديدة أكثر وضوحًا. نظرًا لأن الأجهزة تصبح أصغر حجمًا وأكثر قدرة على الحركة وأكثر ذكاءً ، يتم وضع المزيد والمزيد من الطلبات على الشاشة الرسومية على الشاشة ، على سبيل المثال ، مع الأجهزة المحمولة أو الأجهزة المتصلة بإنترنت الأشياء.
يضطر المستخدمون أيضًا إلى التعود على مجموعة واسعة من الواجهات الرسومية عند استخدام الخدمات والأجهزة المختلفة. وكلما زاد عدد الخدمات والأجهزة المتاحة ، زادت تكلفة التدريب وتكييف المستخدمين. تُظهر واجهات اللغة الطبيعية (NLI) إمكانات كبيرة كأداة ذكية واحدة لمجموعة واسعة من الخدمات والأجهزة من جانب الخادم. تمتلك NLI قدرات مذهلة لتحديد نية المستخدم والتعرف على المعلومات السياقية ، مما يجعل التطبيقات ، مثل المساعدين الافتراضيين ، أكثر ملاءمة للمستخدمين.
درسنا واجهات اللغة الطبيعية لواجهات برمجة التطبيقات (NL2API). على عكس NLI للأغراض العامة مثل المساعدين الظاهريين ، حاولنا فهم كيفية إنشاء NLIs لواجهات برمجة تطبيقات الويب الفردية ، مثل API لخدمة التقويم. في المستقبل ، ستتمكن NL2APIs هذه من إضفاء الطابع الديمقراطي على واجهة برمجة التطبيقات ، مما يساعد المستخدمين على التفاعل مع أنظمة البرامج. يمكنهم أيضًا حل مشكلة قابلية التوسع للمساعدين الافتراضيين للأغراض العامة من خلال تمكين التطوير الموزع. تعتمد فائدة المساعد الافتراضي بشكل كبير على اتساع قدراته ، أي على عدد الخدمات التي يدعمها.
ومع ذلك ، فإن دمج خدمات الويب في مساعد افتراضي واحد في كل مرة هو عمل شاق للغاية. إذا كان لدى مزودي خدمة الويب الفرديين طريقة سهلة لإنشاء NLIs لواجهات برمجة التطبيقات الخاصة بهم ، فيمكن تقليل تكاليف التكامل بشكل كبير. لن يضطر المساعد الافتراضي إلى التعامل مع واجهات مختلفة لخدمات الويب المختلفة. سيكون كافياً بالنسبة له ببساطة أن يدمج NL2APIs الفردية ، التي تحقق التوحيد بفضل اللغة الطبيعية. يمكن لـ NL2API أيضًا تسهيل تطوير خدمات الويب ، وأنظمة برمجة التوصيات ومساعدة API. وبالتالي ، لا يتعين عليك حفظ العدد الكبير من واجهات برمجة التطبيقات المتاحة على الويب وبناء الجملة.
الشكل 1. طرق لإنشاء واجهة لغة طبيعية لواجهة برمجة التطبيقات. على اليسار: تُعلم الطرق التقليدية نماذج إدراك اللغة للتعرف على النوايا بلغة طبيعية ، وتتعلم النماذج الأخرى استخراج الخلايا المرتبطة بكل نية ، ثم تتطابق يدويًا مع طلبات واجهة برمجة التطبيقات. صحيح: يمكن لأسلوبنا ترجمة اللغة الطبيعية مباشرة إلى طلبات API.تتمثل المهمة الرئيسية لـ NL2API في التعرف على التعبيرات في اللغة الطبيعية للمستخدم وترجمتها إلى طلب API. لنكون أكثر دقة ، ركزنا على واجهات برمجة تطبيقات الويب التي تم إنشاؤها على غرار بنية REST ، أي واجهة برمجة تطبيقات RESTful. تُستخدم واجهات برمجة التطبيقات RESTful على نطاق واسع في خدمات الويب وأجهزة إنترنت الأشياء وكذلك في تطبيقات الهواتف الذكية. يتم عرض مثال من Microsoft Graph API في الشكل 1.
يوضح الجانب الأيسر من الشكل الطريقة التقليدية لبناء لغة طبيعية ، حيث نقوم بتعليم نماذج إدراك اللغة للتعرف على النوايا ، ونماذج أخرى لاستخراج الخلايا المرتبطة بكل نية ، ثم مطابقتها يدويًا مع طلبات API عن طريق كتابة التعليمات البرمجية. بدلاً من ذلك (كما هو موضح في الجانب الأيمن من الشكل) ، يمكننا أن نتعلم كيفية ترجمة التعبيرات من لغة طبيعية مباشرة إلى طلبات API. كجزء من الدراسة ، نستخدم نظامنا لواجهات برمجة التطبيقات من حزمة
Microsoft Graph API . تسمح واجهات برمجة تطبيقات Microsoft Graph Web للمطورين بالوصول إلى البيانات المعززة للإنتاجية: البريد والتقويم وجهات الاتصال والمستندات والأدلة والأجهزة والمزيد.
الشكل 2. تسمح واجهات برمجة تطبيقات Microsoft Graph Web للمطورين بالوصول إلى البيانات التي توفر إنتاجية متزايدة: البريد والتقويم وجهات الاتصال والمستندات والأدلة والأجهزة والمزيد.أحد متطلبات النموذج الذي نقوم بتطويره هو القدرة على إنشاء واجهة مستخدم مفصلة. لا تفعل معظم NLI الموجودة القليل لمساعدة المستخدمين إذا لم يتم التعرف على الفريق بشكل صحيح. نقترح أن تجربة المستخدم الأكثر تفصيلاً قد تجعل NLI أكثر ملاءمة بشكل ملحوظ.
قمنا بتطوير نموذج معياري يعمل على أساس "من التسلسل إلى التسلسل" (انظر الشكل 3) لتوفير تفاعل مفصل مع NLI. للقيام بذلك ، نستخدم بنية تعمل على مبدأ "من تسلسل إلى تسلسل" ، ولكن في نفس الوقت نقوم بتقسيم نتيجة فك التشفير إلى عدة وحدات مفسرة تسمى الوحدات.
تحاول كل وحدة نمطية توقع نتيجة محددة مسبقًا ، على سبيل المثال ، باستخدام معلمة محددة بناءً على عبارة تم تلقيها في NL2API. بعد مقارنة بسيطة ، يمكن للمستخدمين بسهولة فهم نتيجة التوقعات لأي وحدة نمطية والتفاعل مع النظام على مستوى معياري. تنتج كل وحدة في نموذجنا نتائج متسقة ، وليست حالة مستمرة.
الشكل 3. نموذج معياري يعمل من تسلسل إلى تسلسل. تقوم وحدة التحكم بتنشيط العديد من الوحدات النمطية ، كل منها ينشئ معلمة.الوحدات: أولا نحدد ما هي الوحدة. الوحدة النمطية هي شبكة عصبية متخصصة مصممة لأداء مهمة محددة للتنبؤ بتسلسل. في NL2API ، تتوافق وحدات مختلفة مع معلمات مختلفة. على سبيل المثال ، في GET-Messages API ، ستكون الوحدات هي FILTER (المرسل) و FILTER (isRead) و SELECT (المرفقات) و ORDERBY (ReceiverDateTime) و SEARCH وما إلى ذلك. تتمثل مهمة الوحدة في التعرف على البيان الوارد وإنشاء معلمة كاملة إذا تم تنشيطها. لهذا ، يجب على الوحدة النمطية تحديد قيم المعلمة الخاصة بها بناءً على العبارة الواردة.
على سبيل المثال ، إذا كانت العبارة الواردة تبدو مثل "رسائل غير مقروءة حول أطروحة الدكتوراه" ، فيجب أن تتنبأ وحدة SEARCH بأن قيمة معلمة SEARCH هي "أطروحة الدكتوراه" وأن تولد معلمة "أطروحة دكتوراة" الكاملة كمتسلسل إخراج. على سبيل القياس ، يجب أن تتذكر وحدة FILTER (isRead) أن عبارات مثل "رسائل البريد الإلكتروني غير المقروءة" و "رسائل البريد الإلكتروني التي لم تتم قراءتها" و "رسائل البريد الإلكتروني غير المقروءة" تشير إلى أن قيمة المعلمة يجب أن تكون "False" .
من الطبيعي أن تكون الخطوة التالية هي إنشاء وحدات فك التشفير التي تحدد ما يجب التركيز عليه ، كما هو الحال في نموذج "من التسلسل إلى التسلسل" المعتاد. ومع ذلك ، بدلاً من وحدة فك ترميز واحدة ، يتم استخدامها لكل شيء ، لدينا الآن العديد من أجهزة فك التشفير ، كل منها متخصص في التنبؤ بمعلمات محددة. علاوة على ذلك ، نظرًا لأن لكل وحدة نمطية مصطلحات محددة بوضوح ، يصبح من السهل جدًا تكوين تفاعل المستخدم على مستوى الوحدة.
المنسق: سيتم استخدام عدد قليل فقط من الوحدات النمطية لكل عبارة تمهيدية. مهمة المنظم هي تحديد الوحدات التي سيتم تشغيلها. وبالتالي ، فإن المنظم هو أيضًا جهاز فك التشفير الذي يحدد ما يستحق التركيز عليه. من خلال ترميز عبارة وتحويلها إلى إدخال ، فإنها تنشئ سلسلة من الوحدات تسمى الدائرة. ثم تقوم الوحدات بإنشاء المعلمات المقابلة لها ، وأخيرًا ، يتم دمج المعلمات لتشكيل الطلب النهائي إلى API.
من خلال تقسيم عملية التنبؤ المعقدة في نموذج "التسلسل إلى التسلسل" القياسي إلى وحدات تنبؤ صغيرة ومتخصصة للغاية تسمى الوحدات ، سيكون من السهل شرح نموذج التنبؤ للمستخدمين. وبعد ذلك ، باستخدام ملاحظات المستخدمين ، سيكون من الممكن تصحيح أخطاء التنبؤ المحتملة على أدنى مستوى. في دراستنا ، نختبر فرضيتنا بمقارنة NLI التفاعلي مع نسختها غير التفاعلية ، سواء من خلال المحاكاة أو من خلال التجارب التي تشمل الأشخاص الذين يستخدمون واجهات برمجة التطبيقات العاملة حقًا. يمكننا أن نثبت أنه مع NLIs التفاعلية ، يحقق المستخدمون النجاح في كثير من الأحيان وبشكل أسرع ، مما يؤدي إلى مستويات أعلى من رضا المستخدمين.
قريبًا جدًا ، سننشر
مقالًا يوضح تفاصيل إنشاء واجهات اللغة الطبيعية لواجهة برمجة تطبيقات الويب. ترقبوا!