المستوى: مبتدئ — مناسب لأي حد بيستخدم Claude أو ChatGPT في كود لأول مرة، وعايز يفهم باراميتر واحد بيغيّر سلوك الموديل كله.

لو طلبت من Claude "اقترحلي اسم لمشروع Todo" وجابلك "إنجاز"، وسألته نفس السؤال بعد دقيقة وجابلك "خطوة"، ده مش عطل في الموديل. ده باراميتر اسمه temperature بتقدر تتحكم فيه من سطر كود واحد. لو ضبطته صح، بتوفر على نفسك ساعات debugging و 30% من تكلفة الـ retries.

Temperature في الذكاء الاصطناعي بالظبط بيعمل إيه؟

المشكلة باختصار

لو بتبني فيتشر "ولّد رد إيميل تلقائي" في تطبيقك، وكل مرة Claude بيرد بشكل مختلف، الـ unit tests بتفشل والمستخدم بيتلخبط. لو طفّيت العشوائية تمامًا في كل حتة، التطبيق بقى مكرر وأي حد بيستخدمه مرتين بيلاحظ. الحل وسط، وده الباراميتر اللي بيتحكم فيه. اللي بيحصل فعلاً إن أغلب المطورين بيسيبوه على القيمة الافتراضية ومبيلمسوش، ودي السبب الرئيسي إن تطبيقاتهم بترجّع JSON بأخطاء عشوائية.

المثال اللي هيخلّيك تفهمها فورًا (للمبتدئ)

تخيّل إنك دخلت مطعم، وقلت للجرسون: "هاتلي طبق". الجرسون عنده ٣ طرق يرد بيهم:

• الجرسون الممل (temperature = 0): دايمًا بيجيبلك نفس الطبق — الأكثر مبيعًا في المطعم. لو سألته ١٠٠ مرة، هيجيبلك كشري ١٠٠ مرة. متوقّع ١٠٠%.
• الجرسون المتوازن (temperature = 1): بيختار من أعلى ٥ أطباق مبيعًا، بنسب احتمالية. مرة كشري، مرة فراخ، مرة محشي. متنوّع بس مش غريب.
• الجرسون المغامر (temperature = 2): ممكن يجيبلك أي حاجة في القايمة، حتى الأطباق اللي محدش بيطلبها. ممكن يبدع، وممكن يجيبلك حاجة مالهاش لازمة.

ده بالظبط اللي بيحصل جوّه الموديل. كل توكن جاي، الموديل عنده توزيع احتمالي على عشرات الآلاف من التوكنز الممكنة. Temperature بتغيّر شكل التوزيع ده — بتخلّيه حاد ومركّز على الأعلى، أو مفرود وعادل بين كل الخيارات.

التعريف العلمي (بعد ما فهمت الفكرة)

الموديل قبل ما يطلع كل توكن، بيحسب قيمة اسمها logit لكل توكن في الـ vocabulary (في Claude حوالي ٢٠٠ ألف توكن). الـ logits دي بتعدّي على دالة softmax عشان تتحوّل لاحتمالات تجميعها = ١.

Temperature بتدخل في المعادلة بالشكل ده:

probabilities = softmax(logits / T)

لمّا T = 1، ما فيش تأثير. لمّا T < 1، التوزيع بيبقى أكثر حدة — التوكن الأعلى احتمالًا بياخد نسبة أكبر بكتير. لمّا T > 1، التوزيع بيبقى أكثر تساويًا — التوكنز الأقل احتمالًا بتاخد فرصة حقيقية تطلع.

الافتراض هنا إنك بتستخدم نموذج بيدعم temperature direct (Claude، GPT، Gemini، Llama). لو بتستخدم نموذج open-source local، اسم الباراميتر هو نفسه بس مكانه في الكود مختلف.

كود Python شغّال يقارن القيم

import anthropic

client = anthropic.Anthropic()
prompt = "اقترحلي اسم لتطبيق todo بالعربي، اسم واحد بس"

print("=== Temperature = 0 (متوقّع) ===")
for i in range(3):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=20,
        temperature=0,
        messages=[{"role": "user", "content": prompt}]
    )
    print(f"Run {i+1}: {response.content[0].text.strip()}")

print("\n=== Temperature = 1.0 (متنوّع) ===")
for i in range(3):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=20,
        temperature=1.0,
        messages=[{"role": "user", "content": prompt}]
    )
    print(f"Run {i+1}: {response.content[0].text.strip()}")

المخرج المتوقّع من تجربة فعلية على Claude Sonnet 4.6:

• T=0: "إنجاز" — "إنجاز" — "إنجاز" (نفس الإجابة ٣ مرات).
• T=1: "إنجاز" — "خطوة" — "نظّم" (٣ إجابات مختلفة).

متى تستخدم كل قيمة (الجدول اللي محتاجه فعلاً)

• 0 إلى 0.3: استخراج بيانات من نص (مثلًا اسم العميل من إيميل)، تصنيف، توليد JSON منظّم، إجابة سؤال له إجابة واحدة صحيحة، ترجمة.
• 0.4 إلى 0.7: شرح مفهوم تقني، كتابة وثائق، تلخيص مقال، الرد على سؤال دعم فني عام.
• 0.8 إلى 1.0: كتابة إبداعية، عصف ذهني، توليد بدائل، اقتراح أسماء أو تيجلاينز.
• أكتر من 1.0: نادر جدًا. ممكن في تجارب فنية أو شعر، بس بنسبة عالية الناتج هيبقى غير مفهوم.

الـ Trade-off اللي محدش بيقوله

أفضل طريقة تفهم الباراميتر ده إنك تعرف إن temperature = 0 مش "حل سحري للاتساق". بتكسب تكرار النتيجة بنسبة عالية جدًا. بتخسر إنك بتدفع نفس التكلفة لكل request حتى لو الإجابات هتكون متطابقة (في الحالة دي، استخدم prompt caching). كمان بتخسر القدرة على إعطاء المستخدم تجربة مش رتيبة لو الفيتشر بطبيعته بيحتاج تنوع.

على الجانب التاني، temperature = 1 بيكسبك تنوّع، بس بيخسّرك القدرة تكتب unit tests deterministic للمخرج. الحل العملي إنك تكتب tests على شكل النتيجة (مثلًا "هل ده JSON صحيح؟ هل فيه field اسمه email؟") بدل ما تكتبها على القيمة الحرفية.

متى لا تستخدم temperature = 0

لو الفيتشر بتاعك حرفيًا "ولّد ٥ اقتراحات مختلفة لاسم"، أو "اقترح ٣ بدائل لرسالة الترحيب"، أو "اعمل عصف ذهني لـ ١٠ أفكار"، temperature = 0 هيرجّعلك نفس الـ ٥ اقتراحات لكل المستخدمين، أو الأسوأ — هيكرر نفس الاقتراح ٥ مرات بصياغات متشابهة. هنا 0.8 هي القيمة الصح، لإنها بتدّي الموديل مساحة استكشاف من غير ما يخرج عن الموضوع.

كمان لو بتبني تطبيق محادثة (chatbot) للترفيه أو للتعليم التفاعلي، temperature = 0 هيخلّي الردود مملّة وبتحس إن في robot قاعد قدامك. خلّيها بين 0.6 و 0.8.

الخطوة التالية

افتح أكبر تطبيق عندك بيستخدم Claude أو GPT دلوقتي. دوّر على كل مكان فيه استدعاء للـ API. لكل استدعاء اسأل نفسك سؤال واحد: "هل ده لازم يكون نفس الجواب كل مرة، ولا التنوع مفيد؟" غيّر temperature على أساس الإجابة. لو لقيت تطبيقك بيرجّع JSON أحيانًا فيه أخطاء صياغة، نزّل القيمة لـ 0 وقيس نسبة الأخطاء قبل وبعد. لو نزلت أكتر من ٧٠%، يبقى ده كان السبب.

المصادر

• Anthropic Messages API Reference — Temperature parameter
• "The Curious Case of Neural Text Degeneration" — Holtzman et al., 2019 (نظرية sampling في LLM)
• OpenAI Chat Completions API — Temperature
• Hugging Face — Generation Strategies (شرح softmax + temperature)