اكتشفت أثناء مراجعة مقال على بلوجر أن الذكاء الاصطناعي قد يرفض محتوى صحيحًا بالكامل، لا بسبب خطأ في المقال، بل بسبب قراءة خاطئة لشكل الروابط داخل واجهة الدردشة.
هذا الخلط ليس نادرًا كما بدا لي في البداية. عندما يراجع نموذج ذكاء اصطناعي مقالًا يحتوي على روابط داخلية، فإنه يقرأ النص كما يظهر أمامه في نافذة المحادثة، لا كما سيُعرض فعليًا بعد النشر. الفرق بين الحالتين قد يبدو تفصيلًا بسيطًا، لكنه كافٍ لأن يصدر النموذج حكمًا خاطئًا بعدم صلاحية المقال للنشر، رغم أن كل شيء يعمل بشكل سليم في بيئة بلوجر الحقيقية.
ما الذي حدث في تجربتي؟
أرسلت مقالًا جاهزًا للمراجعة، وكانت الروابط الداخلية تظهر وتعمل بشكل صحيح داخل بلوجر. لكن النموذج تعامل مع شكل الروابط كما ظهرت داخل واجهة الدردشة، واعتبرها مكسورة أو متداخلة، ثم أصدر حكمًا بعدم النشر بناءً على هذه الملاحظة.
المشكلة لم تكن في المقال نفسه، ولا في كود بلوجر، ولا في الروابط الداخلية. الخطأ كان في قراءة النموذج لطريقة عرض النص داخل المحادثة، ثم تحويل هذا الانطباع البصري إلى حكم نهائي على جودة المقال.
أين كان الخطأ فعلًا؟ في الواجهة لا في بلوجر
في حالات كثيرة، تكون الروابط الداخلية سليمة تمامًا من الناحية التقنية. المشكلة تظهر فقط في طريقة عرضها داخل واجهة الدردشة، حيث قد يبدو الرابط متداخلًا مع نص آخر أو مقطوعًا بسبب التفاف السطر. النموذج يفسر هذا الشكل البصري على أنه خلل حقيقي، بينما لو تم فتح المعاينة الفعلية أو الكود الخام داخل بلوجر لظهر الرابط سليمًا من البداية.
تقييم الروابط الداخلية يجب أن يعتمد دائمًا على المعاينة الفعلية أو الكود المصدر، لا على الشكل الذي يظهر به النص في نافذة المحادثة. هذا الفرق تحديدًا هو ما يفصل بين مراجعة دقيقة ومراجعة تتكئ على انطباع بصري خاطئ.
كيف ظهر Hallucination في هذه التجربة؟
عندما يُذكر مصطلح Hallucination، يفكر معظم الناس في معلومة مختلقة، مثل تاريخ غير صحيح أو اسم غير موجود. لكن هذا المفهوم يمتد إلى مراجعة المحتوى نفسها. يحدث Hallucination في هذا السياق عندما يخترع النموذج مشكلة تحريرية أو تقنية لا وجود لها أصلًا، مثل الادعاء بأن الروابط الداخلية متداخلة أو تالفة رغم أنها تعمل بشكل صحيح داخل بلوجر.
الفارق هنا مهم: النموذج لا يكذب بمعنى القصد، لكنه يبني استنتاجًا من معطيات ناقصة أو مشوهة، ثم يقدم هذا الاستنتاج بثقة كأنه حقيقة مؤكدة.
لماذا كان الحكم False Negative؟
False Negative يعني ببساطة رفض شيء صحيح بسبب تفسير خاطئ. في هذه الحالة، كان المقال قابلًا للنشر من الناحية التقنية والتحريرية، لكن النموذج رفضه استنادًا إلى مشكلة غير موجودة في الروابط. النتيجة حكم سلبي بلا سبب فعلي، وهو ما يختلف تمامًا عن رفض مبرر لمقال يحتوي فعلًا على أخطاء.
الخطورة في هذا النوع من الأخطاء أنها تبدو مقنعة. المستخدم يثق في تقييم النموذج، فيبدأ في البحث عن حل لمشكلة لا وجود لها، بينما المقال كان جاهزًا للنشر منذ البداية.
المشكلة الأكبر: تجاهل تعليمات الذاكرة
المشكلة لا تقف عند سوء قراءة الرابط داخل الواجهة. في بعض الحالات تمتد إلى تجاهل تعليمات محفوظة مسبقًا في الذاكرة، كانت تنص بوضوح على عدم تكرار هذه الملاحظة تحديدًا حول الروابط الداخلية. حين يعيد النموذج نفس الملاحظة رغم وجود توجيه صريح يمنعها، فهذا يشير إلى خلل في ما يُعرف بـ Context Retention، أو بشكل أدق في Prompt Compliance، أي التزام النموذج بتعليمات محددة سبق تثبيتها.
هذا النوع من الخطأ أخطر من الخطأ الأول، لأنه لا يتعلق بمرة واحدة عابرة، بل بتكرار ملاحظة كان يفترض أنها أُغلقت نهائيًا.
كيف تفرّق بين خطأ حقيقي في الرابط وخطأ عرض داخل واجهة الدردشة؟
قبل قبول أي ملاحظة من نموذج ذكاء اصطناعي حول روابط داخلية، يفيد اتباع خطوات بسيطة:
- افحص الرابط داخل بلوجر أو في المعاينة الفعلية للمقال قبل أي تعديل.
- جرب الرابط مباشرة وتأكد من أنه يفتح الصفحة الصحيحة المقصودة.
- راجع الكود المصدر فقط بعد ثبوت وجود مشكلة فعلية، لا قبل ذلك.
- لا تحكم على سلامة الرابط من شكله داخل نافذة المحادثة وحدها.
- لا تبدأ في تعديل الأكواد بناءً على افتراض لم يثبت بعد في بيئة النشر.
هذه الخطوات تحول عملية المراجعة من ثقة عمياء في تقييم النموذج إلى تحقق فعلي يوفر وقتًا كان سيُهدر في إصلاح مشكلة غير موجودة.
مثال واقعي يوضح المشكلة
يرسل صاحب موقع مقالًا يحتوي على روابط داخلية صحيحة تمامًا. يقرأ النموذج شكل الرابط داخل واجهة الدردشة بطريقة خاطئة، فيظن أن هناك تداخلًا أو كسرًا فيه. بناءً على هذا الانطباع، يصدر حكمًا بعدم صلاحية المقال للنشر، رغم أن الروابط تعمل دون أي مشكلة داخل بلوجر. بعد ذلك يقترح النموذج إصلاحات لم تكن مطلوبة أصلًا، فيضيع وقت صاحب الموقع في معالجة خطأ لم يكن موجودًا من البداية.
ومع تزايد اعتماد المستخدمين على أدوات المحادثة في البحث والمراجعة وصناعة المحتوى، يصبح فهم تأثير ChatGPT على البحث وزيارات المواقع ضروريًا لأصحاب المدونات الذين يبنون قراراتهم في النشر والتحسين على مخرجات هذه الأدوات.
ما أثر هذا الخطأ على وقت صاحب الموقع؟
الأثر لم يكن مجرد ملاحظة غير دقيقة. عندما يصدر النموذج حكمًا خاطئًا بعدم النشر، يبدأ صاحب الموقع في مراجعة روابط وأكواد لا تحتاج إلى تعديل أصلًا. هنا يتحول الذكاء الاصطناعي من أداة توفير وقت إلى سبب مباشر في إهداره.
الخطأ يصبح أكثر إزعاجًا عندما يكون المستخدم قد أوضح مسبقًا أن الروابط تظهر صحيحة داخل بلوجر، وأن طريقة عرضها داخل المحادثة لا يجب أن تُستخدم كدليل على وجود خلل.
كيف تكتب بلاغًا يفهمه المطورون وفرق QA؟
بلاغ جيد لا يكتفي بعبارة عامة مثل "النموذج أخطأ"، بل يوضح طبيعة الخطأ بدقة تسمح لفريق QA بتتبعه. صياغة مفيدة في هذا السياق تكون على النحو التالي: حدث Memory failure لأن النموذج تجاهل تعليمات محفوظة مسبقًا، ووقع بالتوازي في Hallucinated issue حين افترض وجود مشكلة في الروابط الداخلية بسبب UI parsing problem. النتيجة كانت تقييمًا من نوع False Negative ورفضًا غير مبرر Incorrect rejection لمقال صحيح، مصحوبًا بجهد إصلاح مهدر Wasted remediation effort في اقتراح تعديلات لم تكن مطلوبة أصلًا.
هذا النوع من التوثيق يفيد المطورين أكثر من أي شكوى عامة، لأنه يفصل بين مصدر المشكلة الأول وهو قراءة الواجهة، والمصدر الثاني وهو تجاهل الذاكرة، بدلًا من خلطهما في ملاحظة واحدة غامضة.
ما الذي يجب أن يتغير في أدوات مراجعة المحتوى؟
أدوات الذكاء الاصطناعي المستخدمة في مراجعة المحتوى تحتاج إلى تمييز أوضح بين عرض النص داخل واجهة الدردشة وبيئة النشر الفعلية، وعدم إصدار حكم نهائي على أي عنصر تقني قبل التحقق منه بشكل مباشر. احترام التعليمات المحفوظة مسبقًا في الذاكرة يجب أن يكون شرطًا أساسيًا لا اختياريًا، إلى جانب تقديم مستوى ثقة واضح مع كل ملاحظة تقنية بدلًا من عرضها كحقيقة مطلقة. الفصل بين مشكلة مؤكدة فعليًا وملاحظة تحتاج فحصًا إضافيًا هو ما يحدد الفارق بين أداة مراجعة موثوقة وأخرى تصدر أحكامًا متسرعة.
ولفهم الخلفية الأوسع لهذه الأدوات وكيف تطورت خلال الفترة الأخيرة، يساعد دليل أساسيات الذكاء الاصطناعي وأحدث أدواته في توضيح كيف انتقلت هذه النماذج من مساعدات بسيطة إلى أنظمة تشارك فعليًا في الكتابة والمراجعة واتخاذ القرار.
وليست كل النماذج متشابهة في طريقة التعامل مع السياق أو النصوص الطويلة أو الروابط المضمنة داخلها، ولهذا تساعد مقارنة أفضل أدوات الذكاء الاصطناعي في فهم الفروق الفعلية بين الأدوات قبل الاعتماد على أي منها في مراجعة محتوى جاهز للنشر.
وهنا تظهر تكلفة الخطأ بوضوح أكبر؛ فالمسألة لا تتعلق بملاحظة واحدة عابرة، بل بوقت يُهدر في إصلاحات غير مطلوبة أصلًا، وهي زاوية قريبة مما ورد في تجربة وهم الإنتاجية مع الذكاء الاصطناعي، حين تبدو الأداة مفيدة ظاهريًا بينما تستهلك الجهد فعليًا في نتائج سطحية أو مضللة.
ما الذي خرجت به من هذه التجربة؟
خرجت من هذه التجربة بقاعدة واضحة: لا يجب الاعتماد على حكم الذكاء الاصطناعي في مشكلات الروابط إلا بعد التحقق من بيئة النشر الفعلية. شكل الرابط داخل واجهة الدردشة ليس دليلًا كافيًا على وجود خلل، خصوصًا إذا كانت الروابط تعمل داخل بلوجر.
الأهم أن تجاهل الذاكرة في مثل هذه الحالات ليس خطأ بسيطًا، لأنه يجعل النموذج يكرر ملاحظة سبق حسمها. لذلك يحتاج أي بلاغ للمطورين إلى وصف المشكلة بدقة باعتبارها Memory failure وHallucinated issue و False Negative evaluation، لا مجرد مراجعة ضعيفة لمقال واحد.