استخدام نماذج لغة كبيرة في أوكسايد: تحليل لأربع أدوار رئيسية تختلف استخدامات نماذج لغة كبيرة (LLMs) بشكل كبير، كما تختلف آثار هذه الاستخدامات وفقًا لذلك، مما يستدعي فصل وتقييم عدة جوانب رئيسية لاستخدام هذه النماذج. النماذج كقراء تمتلك نماذج لغة كبيرة كفاءة استثنائية في فهم النصوص، حيث تستطيع معالجة الوثائق وتفسيرها بدقة فورية. هذا يجعلها أداة قوية جدًا في تلخيص المستندات أو الإجابة على أسئلة محددة حول مستندات طويلة مثل مواصفات تقنية أو وثائق بيانات. ومن المفارقات أن هذه النماذج تكون خاصةً فعالة في تقييم مدى تأثير الذكاء الاصطناعي نفسه في إنشاء المستندات التي تُستخدم لتقييمه. على الرغم من أن استخدام النماذج كمساعدات في الفهم لا يحمل عواقب سلبية كبيرة، إلا أنه يحمل تحذيرًا مهمًا: عند رفع مستند إلى نموذج مُستضاف (مثل ChatGPT أو Claude أو Gemini)، يجب ضمان خصوصية البيانات، وبشكل خاص ضمان عدم استخدام النموذج لهذا المستند في تدريب إصدارات مستقبلية له. غالبًا ما يكون هذا الخيار مفعلًا افتراضيًا (أي أن النموذج يحتفظ بحق استخدام البيانات في التدريب)، ويمكن التحكم فيه عبر الإعدادات، رغم أن بعض الشركات تستخدم صيغًا مبهمة لتبرير ذلك. على سبيل المثال، تصف OpenAI هذا الخيار بشكل مباشر بأنه "تحسين النموذج للجميع"، مما يجعل من يرفض هذا التدريب يبدو وكأنه يرفض المساهمة في التطور العام، رغم أنه مجرد خيار خصوصية. تحذير إضافي: لا ينبغي استخدام النماذج كأداة لاستبدال القراءة الفعلية عند توقع ذلك اجتماعيًا. على سبيل المثال، يمكن لـ LLMs أن تُسهم في تقييم المواد المرشحة وفقًا لـ RFD3، لكن يجب أن تُستخدم كأداة مساعدة، لا كبديل عن العين البشرية والتفكير البشري. النماذج ككاتبات رغم كفاءة النماذج في القراءة والتحرير، فإن كتابتها تُعد مختلطة في الجودة. في أفضل الأحوال، تكون نصوصها مكررة ومتكررة في التعبيرات، وفي أسوأ الأحوال، تزخر بعلامات تُظهر أن النص مُولَّد تلقائيًا. ماذا يُعد مشكلة في ذلك؟ أولاً، من يُدرك هذه العلامات (وعدد هؤلاء يزداد) سيعتبرها محرجة — كأن الكاتب يمشي بـ"مُلَفَّت" عقله مفتوحة. لكن هناك مشكلات أعمق: النصوص المولَّدة تُضعف مصداقية الكاتب، وتحوّل التفكير وراء النص إلى موضع شك. إذا كان النص مُولَّدًا تلقائيًا، فهل الأفكار كذلك؟ القارئ لا يمكنه التأكد، وغالبًا ما تُفقد الثقة. هناك أيضًا انتهاك لعقد اجتماعي: في عالم ما قبل LLMs، كان من المفترض أن الكاتب هو من بذل الجهد الأكبر، لأن الكتابة أصعب من القراءة. القارئ، عند مواجهة صعوبة، يفترض أن الكاتب فهم الفكرة جيدًا، وبالتالي من واجبه بذل جهد لفهمها. لكن إذا كان النص مُولَّدًا تلقائيًا، يُصبح من المستحيل افتراض أن الكاتب فهم الفكرة، لأن من الممكن أن يكون هو نفسه لم يقرأ ما أُنتج. في أحسن الأحوال، تكون النتائج أخطاء مُتَوَهِّمة (مُتَوَهِّمة بوضوح) وسريعًا ما تُرفض. وفي أسوأ الأحوال، تنشأ حالة من التناقض المعرفي: مشكلة لا يوجد لها حل لأنها في الواقع لا توجد. هذا يُربك القارئ: لماذا يبذل جهدًا في القراءة أكثر مما بذله الكاتب في الكتابة؟ يمكن تجاوز هذه المخاطر، لكنها خطيرة جدًا: الكتابة أداة أساسية لبناء الثقة، وهذه الثقة يمكن أن تُهدم بسرعة إذا لم نُعبِّر بصوتنا الخاص. في أوكسايد، هناك سبب ميكانيكي إضافي لعدم الاعتماد على LLMs في الكتابة: لأن عملية التوظيف لدينا تُركّز على مهارات الكتابة، ونعرف أن كل فرد في الشركة قادر على الكتابة. ولدينا المرونة لطلب مستوى عالٍ من الجودة، نظرًا لقدرتنا الفعلية. لذا، تُعدّ قواعدنا العامة عدم استخدام LLMs في الكتابة، لكن هذا لا يعني حظرًا مطلقًا. لا يمنع استخدام النموذج كجزء من عملية الكتابة، شريطة أن نُدرك مسؤوليتنا تجاه أنفسنا، وتجاه أفكارنا، وتجاه القارئ. النماذج كمطوّرين برمجيات تُعدّ LLMs ممتازة في كتابة الشيفرة البرمجية، لدرجة أن بعض المخاوف تُصوَّر كأنها قد تُلغي المهنة بالكامل. لكن كما هو الحال مع الكتابة، هناك مخاطر واضحة. على عكس الكتابة، التي يجب أن تكون نصًا ناضجًا قبل إدخاله إلى النموذج لتحسين جودته، فإن LLMs يمكن أن تكون فعالة جدًا في كتابة الشيفرة من الصفر، خاصةً في المهام التجريبية أو المؤقتة أو غير المهمة. كلما اقترب الكود من النظام الذي يتم تشغيله، زادت الحاجة إلى الحذر. حتى في مهام بسيطة مثل كتابة اختبارات، يمكن للنموذج أن ينحرف بسهولة إلى تفاصيل غير منطقية. مع ذلك، تبقى الأدوات مفيدة جدًا وتوفر طيفًا واسعًا من الاستخدامات في تطوير البرمجيات، ولا ينبغي تجاهلها. أينما تُستخدم شيفرة مولَّدة تلقائيًا، تصبح مسؤولية المهندس مطلقة. كجزء من هذه المسؤولية، يصبح المراجعة الذاتية ضرورية: لا يمكن أن تُراجع شيفرة مولَّدة تلقائيًا من قبل فريق آخر ما لم يُراجعها المهندس المُسؤول بنفسه. علاوةً على ذلك، بمجرد دخول الشيفرة إلى دورة المراجعة، يجب تقليل أو إيقاف استخدام التوليد التلقائي: إذا تم معالجة ملاحظات المراجعة بحذف الشيفرة وإعادة توليد كل شيء، تصبح عملية المراجعة التكرارية مستحيلة. باختصار، عند استخدام LLMs لكتابة الشيفرة، يجب أن تظل المساءلة، والصرامة، والتعاطف، والعمل الجماعي في المقدمة.
استخدام النماذج اللغوية الكبيرة (LLMs) يختلف حسب الغرض، ويحمل تداعيات متفاوتة حسب السياق. في شركة أوكسايد، تم تحليل استخدامات هذه النماذج في ثلاث مجالات رئيسية: القراءة، والكتابة، والبرمجة. في دور القارئ، تُظهر LLMs كفاءة استثنائية في فهم النصوص، سواء لاستخلاص ملخصات أو الإجابة على أسئلة دقيقة حول وثائق فنية مثل مواصفات الأجهزة أو البيانات الفنية. لكن هذا الاستخدام يحمل تحذيرًا مهمًا: عند رفع مستند إلى منصات LLM مثل ChatGPT أو Claude أو Gemini، يجب التأكد من خصوصية البيانات، وبخاصة أن النموذج لن يستخدم هذا المحتوى لتدريب إصداراته المستقبلية. بعض المنصات تُفعّل هذا التدريب افتراضيًا — مثلما تسميها OpenAI "تحسين النموذج للجميع"، وهو تعبير يُضفي طابعًا سلبيًا على من يرفضه، رغم أنه يُعدّ انتهاكًا لخصوصية البيانات. كما يجب التذكير بأن استخدام LLMs في فهم الوثائق لا يُعوّض عن قراءة الإنسان للنص، خاصة في السياقات المهنية أو التوظيفية، حيث يُتوقع التقييم البشري، وليس الاعتماد على الآلة. أما في مجال الكتابة، فإن الأداء غير متساوٍ. بينما يمكن لـ LLMs مساعدة في التحرير، فإن كتابتها الأصلية غالبًا ما تكون مملة، ومتكررة، وتحتوي على علامات تدل على أنها مولدة آليًا. هذا لا يُعدّ مجرد عيب جماليًا، بل يُهدد مصداقية الكاتب وصدق أفكاره. إذا كان النص مولّدًا آليًا، يتساءل القارئ: هل الفكرة حقيقية؟ هل الكاتب فهمها؟ هذا يُضعف العقد الاجتماعي بين الكاتب والقارئ، حيث يُفترض أن الكاتب بذل جهدًا أكبر من القارئ. عندما يُستخدم LLM في الكتابة، يُفقد هذا التوازن، وقد يُولد قراءة مُربكة أو فوضوية، خاصة إذا كانت النصوص تحتوي على تناقضات أو "هلوسات" من النموذج. في أوكسايد، حيث يُعتبر التميّز في الكتابة جزءًا أساسيًا من عملية التوظيف، يُفضل التمسك بكتابة الإنسان، مع السماح بمساعدة LLM كأداة تحرير أو توليد أفكار أولية، ولكن لا يُسمح بالاعتماد الكامل عليها. في مجال البرمجة، تُظهر LLMs قدرات مذهلة في كتابة الكود، خاصة في المهام التجريبيّة أو الثانوية. لكن مع اقتراب الكود من النظام المُنتَج، يتطلب الأمر حذرًا أكبر. حتى في كتابة الاختبارات، قد يُنتج النموذج كودًا غير منطقي أو غير دقيق. ومع ذلك، لا يمكن تجاهل فائدتها، خاصة في تسريع العمليات وتقديم حلول أولية. لكن المسؤولية تبقى على المهندس: يجب أن يراجع الكود المولّد بنفسه قبل أي مراجعة من زملائه. كما يجب تجنب إعادة إنتاج الكود بشكل كامل بناءً على تعليقات المراجعة، لأن ذلك يُفسد عملية التحسين التدريجي. في النهاية، استخدام LLM في البرمجة يتطلب روحًا من المسؤولية، والدقة، والتفاهم الجماعي، لا سيما أن الكود يُعدّ جزءًا حيويًا من الثقة والجودة في المنتج النهائي. باختصار، LLMs أداة قوية، لكنها تتطلب وعيًا أخلاقيًا وتقنيًا، خاصة في بيئات تتطلب التميز والثقة مثل أوكسايد.
