سطح المكتب بلا T9: لماذا حدث ذلك وكيف يمكن أن تصلحه نماذج LLM

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

لماذا حصل الهاتف على التصحيح التلقائي ولم يحصل عليه الحاسوب

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

على سطح المكتب الصورة معاكسة. فلوحة المفاتيح الفعلية أدق، والأخطاء في الغالب أقل، ولا توجد حاجة ملحّة. إضافة إلى ذلك، يصل النص إلى المتصفحات وبيئات التطوير IDE وتطبيقات المراسلة والطرفيات وحزم المكتب، ولكل منها محرّك نصوص خاص به. وليست هناك نقطة واحدة يمكن عندها اعتراض الإدخال وتعديل الكلمة بدقة. ويضطر المطوّر إلى العمل عبر accessibility API أو عبر خطافات (hooks) على مستوى النظام. وهذا أسلوب هش، ويختلف من نظام تشغيل إلى آخر، وكثيرًا ما يتعطّل في الحقول المحمية.

وهناك أيضًا مسألة الثقة. فالبرنامج الذي يقرأ كل ما يُكتب يشبه، بحكم تعريفه، برنامج تسجيل ضغطات المفاتيح (keylogger). وبالنسبة إلى بيانات العمل، هذا عائق جدي: فالمستشارون القانونيون وأقسام الأمن سيحظرون مثل هذه الأداة بكل سرور.

ما الذي تغيّره النماذج اللغوية

يعتمد التصحيح التلقائي الكلاسيكي على قاموس وإحصاءات n-gram. وهو يصحّح أخطاء الكتابة داخل الكلمة جيدًا، لكنه يفهم السياق بصورة سيئة: فلا يميّز بين «ложить» و«класть» بحسب معنى العبارة، ويتعثر في المصطلحات المهنية. أما النموذج اللغوي فينظر إلى الجملة كاملة ويقدّر أي كلمة تناسب موضعها. وقد نقلت Apple بالفعل التصحيح التلقائي في iOS إلى نموذج من نوع المحوّلات (transformer)، وظهرت في macOS اقتراحات مدمجة لإكمال الجملة. وهذا يعني أن كبرى الشركات المصنّعة مستعدة لنقل ذلك إلى سطح المكتب، وإن كانت تفعل ذلك بحذر حتى الآن وفي الغالب لمجموعة محدودة من اللغات.

ويرتبط التغيير الرئيسي بالحجم. فالنماذج التي تضم بضعة مليارات من المعاملات، مثل فئة Phi-3-mini ذات 3.8 مليار، تعمل الآن على حاسوب محمول دون الحاجة إلى السحابة. وهذا يزيل جزءًا من مشكلة الخصوصية: فالنص لا يغادر الجهاز. وتبقى مشكلتا زمن الاستجابة والموارد.

وتبدو المعايير المرجعية لأداة كهذه على النحو التالي:

• زمن استجابة الاقتراح: نحو 100 مللي ثانية، وإلا تأخر عن وتيرة الكتابة؛
• حجم النموذج: من مئات الملايين إلى بضعة مليارات من المعاملات، بصيغة مكمّاة (quantized)؛
• العمل دون اتصال بالإنترنت، ودون إرسال النص إلى خادم؛
• دعم اللغة الروسية بحالاتها الإعرابية وحرية ترتيب الكلمات فيها، حيث تخطئ النماذج الضعيفة أكثر؛
• إعداد استثناءات لكلمات المرور والطرفية والشيفرة.

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

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

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