أساسيات النماذج اللغوية للمختبِرين

لماذا يهم

كل آلية من هذه الآليات مصدر للعيوب. فأخذ العيّنات (Sampling) يجعل المدخل نفسه يعطي إجابات مختلفة، ونافذة السياق (Context window) تحدد ما يراه النموذج، وحدود المخرجات تقطع الإجابات، وموجّه النظام نص لا قاعدة مُلزِمة، واستدعاء الأداة يحوّل النص المولَّد إلى فعل. والمختبِر الذي لا يعرف ذلك إما أن يكتب اختبارات مطابقة حرفية تفشل عشوائياً، وإما أن يقبل عبارة «الذكاء الاصطناعي هكذا» فيمرّر عيوباً حقيقية.

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

الرموز ونافذة السياق

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

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

حين تتجاوز المحادثة النافذة، يقتطعها التطبيق أو يلخّصها، وإلا فشل الطلب، وقد تضيع تعليمة أو رقم طلب ذُكر في البداية. والحد الأقصى لرموز المخرجات (Max output tokens) حدّ منفصل: فالإجابة التي تبلغه تنقطع، وكثيراً ما يحدث ذلك في منتصف الجملة، ويذكر ذلك سبب التوقف (Stop reason) في الاستجابة. وكلا الحدّين قيمة حدّية، فطبّق عليهما تحليل القيم الحدّية، وبمدخلات طويلة بالعربية والهندية أيضاً؛ ويساعدك نص حشو مولَّد تقيسه بأداة String Length Counter على تكبير المدخل خطوة بخطوة.

Illustrative split (every tokenizer differs):
  "Where is my order 5521?"  ->  Where| is| my| order| 55|21|?   (7 tokens)

Context budget for one request (example model with a 16,000-token window)
  System prompt                            1,200
  Tool definitions (3 tools)                 900
  Conversation so far (18 messages)       11,500
  New customer message                       400
  Reserved for the answer (max output)     2,000
  Total                                   16,000   <- window full

جرّبها: عدّاد طول السلاسل النصية جرّبها: مولّد Lorem Ipsum

كيف يُختار الرمز التالي: درجة الحرارة وأخذ العيّنات

في كل خطوة يعطي النموذج كل رمز في مفرداته احتمالاً لأن يكون التالي. ويُسمّى أخذ الرمز الأرجح دائماً فكّ الترميز الجشع (Greedy decoding)؛ أما كثير من التطبيقات فتأخذ عيّنة، أي تختار عشوائياً بنسبة الاحتمالات، فتختلف الإجابات من تشغيل لآخر.

تعيد درجة الحرارة (Temperature) تحجيم هذه الاحتمالات: ما دون ⁦1⁩ يفضّل الرمز الأرجح، وما فوق ⁦1⁩ يمنح الرموز الأقل ترجيحاً فرصاً أكبر. ويُبقي top-p، أو أخذ العيّنات النووي (Nucleus sampling)، أصغر مجموعة من الرموز الأرجح يبلغ مجموع احتمالاتها p على الأقل؛ ويُبقي top-k أرجح k رموز. ولا يقبل كل نموذج كل معامل، فسجّل القيم المرسلة فعلاً.

في المثال أدناه سياسة المتجر ⁦30⁩ يوماً، ومع ذلك يُختار رقم خاطئ في نحو تشغيل من كل أربعة عند درجة الحرارة ⁦1.0⁩، وفي أربعة من كل عشرة عند ⁦2.0⁩، والإجابة الطويلة تتضمن مئات من هذه الاختيارات. وخفض درجة الحرارة يقلل التباين لكنه عملياً لا يضمن مخرجات متطابقة. فاختبر بإعدادات الإنتاج، وشغّل الحالات المهمة عدة مرات، وقارن التشغيلات، مثلاً بأداة Text Diff.

Context: "... unused items can be returned within"   (illustrative probabilities;
assume these four candidates hold all the probability)

Next token       temperature 0.5   temperature 1.0   temperature 2.0
" 30"                      91.5%             70.0%             48.6%
" 14"                       7.5%             20.0%             26.0%
" 7"                        0.9%              7.0%             15.4%
" thirty"                   0.2%              3.0%             10.1%

Wrong number (14 or 7)      8.4%             27.0%             41.3%

جرّبها: مقارنة النصوص (Diff)

موجّه النظام واستخدام الأدوات

الطلب قائمة رسائل لكل منها دور. ويحمل موجّه النظام (System prompt)، الذي يسميه بعض المزوّدين رسالة النظام أو رسالة المطوّر، تعليمات التطبيق: الدور والقواعد والنطاق واللغة والصيغة. وتُدرَّب النماذج على إعطائه الأولوية، لكنه غير مُلزِم: إنه نص في السياق نفسه مع مدخلات المستخدم. فقد يخفق النموذج في اتباعه، وقد يحاول نص المستخدم أو مستند ما تجاوزه، وهذا حقن الموجّهات (Prompt injection، البند LLM01:2025 في OWASP Top 10 لتطبيقات LLM)، وقد يتسرّب محتواه (System Prompt Leakage، البند LLM07:2025). فأبقِ الأسرار خارجه، وطبّق الصلاحيات والأسعار والحدود في الكود.

في استخدام الأدوات (Tool use)، أو استدعاء الدوال (Function calling)، يصف التطبيق كل أداة باسم ووصف ومخطط JSON Schema لمعاملاتها، وهو مستند يحدد الحقول والأنواع والقيم المسموح بها في المعاملات، ويُكتب هو نفسه بصيغة JSON، أي الصيغة النصية التي تكتب البيانات حقولاً مسمّاة وقيماً، مثل {"order_id": "5521"}، وتتبادلها معظم الواجهات البرمجية على الويب. والنموذج لا يشغّل شيئاً أبداً: بل يعيد طلباً منظّماً لاستدعاء أداة بمعاملات ولّدها هو، فيتحقق التطبيق منها ويشغّل الأداة ويعيد النتيجة في طلب جديد. وعامل المعاملات المولَّدة كمدخلات غير موثوقة؛ فقد تأتي بصيغة خاطئة، أو بصيغة صحيحة ومعنى خاطئ، كرقم طلب لم يذكره العميل قط. وتتحقق أداة JSON Schema Validator من المعاملات المسجّلة مقابل المخطط. والأدوات التي تغيّر شيئاً هي حيث تحوّل الوكالة المفرطة (Excessive agency، البند LLM06:2025) الإجابة الخاطئة إلى فعل خاطئ.

Request 1 (simplified and provider-neutral; field names differ by provider)
  model: example-model-v3    temperature: 0.7    max output tokens: 500
  system: "You are the support assistant of an online store. Answer in the
           customer's language. Hand every refund request to a human agent."
  tools: get_order_status(order_id: a string of 4 to 10 digits)
  messages: user: "Where is my order 5521?"

Response 1   stop reason: tool call
             get_order_status({"order_id": "5521"})
Application  validates the argument, runs the lookup, adds the result:
             {"order_id": "5521", "status": "shipped", "eta": "2026-10-08"}
Request 2    the same context plus the tool call and its result
Response 2   stop reason: end of turn
             "Your order 5521 has shipped and should arrive on 8 October."

جرّبها: مدقّق JSON Schema

أنماط الإخفاق الشائعة

تقع معظم عيوب LLM في عائلات قليلة، تعود كل منها إلى إحدى الآليات السابقة؛ وتسمية الآلية تدلّ على الإصلاح وعلى اختبار الانحدار.

• الهلوسة (Hallucination): محتوى سلس وواثق لكنه خاطئ أو بلا سند، مثل سياسة أو حالة طلب مختلَقة، وتسمّيها وثيقة ⁦NIST AI 600-1⁩ الاختلاق (Confabulation). فالنموذج ينتج نصاً مرجّحاً لا حقائق متحقَّقاً منها، فاختبر أسئلة لا تتوفر إجابتها، وتوقّع «لا أعرف» أو تحويلاً إلى موظف.
• انحراف التعليمات (Instruction drift): لغة خاطئة أو صيغة خاطئة أو نصيحة خارج النطاق، وغالباً في أواخر المحادثات الطويلة. ورفض طلب مشروع إخفاق أيضاً.
• عدم الاتساق (Inconsistency): المدخل نفسه يُقبل في تشغيل ويُرفض في آخر؛ وفي قرار يجب أن يكون ثابتاً، التقلّب نفسه هو العيب.
• الاقتطاع وضياع السياق (Truncation and lost context): إجابة مقطوعة عند حدّ المخرجات مع JSON غير مغلق، أو معلومة اختفت بعد اقتطاع السجل.
• المخرجات المنظّمة المعيبة (Malformed structured output): JSON غير صالح، أو حقول ناقصة أو زائدة، أو نص حول JSON يكسر المحلّل.
• أخطاء استخدام الأدوات: استدعاء خاطئ أو مفقود، ومعاملات مختلَقة، وخطأ أداة تغطيه نتيجة مختلَقة، وحلقات تكرار، أو فعل دون التأكيد المطلوب.
• الحقن والتسرّب: نص من مستخدم أو صفحة أو مستند يتجاوز التعليمات أو يستخرج موجّه النظام؛ ويقدّم دليل اختبار أمان LLM اختبارات آمنة لذلك.

مثال تطبيقي: تتبّع إجابة خاطئة واحدة حتى سببها

يشتكي عميل من أن مساعد الدعم وعده بوصول طلبه الثاني «غداً» مع أنه لم يُشحن. وبدلاً من الإبلاغ بأن «البوت يختلق التواريخ»، يقرأ المختبِر الطلب المسجَّل لتلك الجولة من المحادثة كما أُرسل فعلاً.

إنها الرسالة ⁦31⁩، «وماذا عن الطلب الثاني؟»، ولا يوجد استدعاء أداة في الاستجابة. كان رقم الطلب قد ذُكر في الرسالة ⁦3⁩، لكن التطبيق يحتفظ بآخر ⁦20⁩ رسالة فقط، فلم تكن لدى النموذج قيمة للمعامل الإلزامي order_id، وبدلاً من أن يسأل كتب إجابة تبدو مقنعة. وعند درجة الحرارة ⁦0.7⁩ أعطت إعادة إرسال الطلب المسجَّل خمس مرات تاريخاً مختلَقاً أربع مرات وسؤالاً عن رقم الطلب مرة واحدة.

• تقرير الخطأ: إصدار النموذج والموجّه، والمعاملات، والطلب بعد الاقتطاع، وسبب التوقف، وعبارة «تاريخ مختلَق في ⁦4⁩ من ⁦5⁩ تشغيلات»، والسبب: الاقتطاع أسقط رقم الطلب، والموجّه لا يتضمن قاعدة لحالة غيابه.
• اختبارات جديدة: محادثة من ⁦30⁩ رسالة لا يظهر فيها رقم الطلب إلا في الرسالة ⁦3⁩، وسؤال دون أي رقم طلب. النتيجة المتوقعة في كل تشغيل: يبحث المساعد عن الطلب أو يسأل عن الرقم، ولا يذكر تاريخاً أبداً دون نتيجة من الأداة.
• سؤال للفريق: هل يجب أن تبقى المعلومات الأساسية، مثل أرقام الطلبات، في السياق بعد اقتطاع السجل؟

أسئلة شائعة

المراجع

• Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026منهج ISTQB التخصصي لاختبار الأنظمة المبنية على الذكاء الاصطناعي، ويشمل أنظمة تعلّم الآلة والذكاء الاصطناعي التوليدي.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)NIST · 2024ملف الذكاء الاصطناعي التوليدي ضمن إطار AI RMF: مخاطر خاصة بالنماذج التوليدية مثل الاختلاق وسلامة المعلومات، وإجراءات مقترحة لإدارتها.
• OWASP Top 10 for LLM Applications 2025OWASP Gen AI Security Project · 2025أخطر عشرة مخاطر أمنية في تطبيقات النماذج اللغوية الكبيرة (LLM01:2025–LLM10:2025)، بدءاً بحقن الموجّهات والإفصاح عن المعلومات الحساسة.
• Certified Tester Specialist Level – Testing with Generative AI (CT-GenAI)ISTQBمنهج ISTQB لاستخدام النماذج اللغوية الكبيرة عبر عملية الاختبار — الاتجاه المقابل لاختبار أنظمة الذكاء الاصطناعي.