স্যাম্পলিং ও রিজনিং কন্ট্রোল: temperature, top-p, effort ও পুনরাবৃত্তিযোগ্যতা

অনেক গাইড বলে "নির্ভুল উত্তরের জন্য temperature কম রাখুন"। এই পরামর্শ পুরোনো, আর এটা দুটো আলাদা জিনিস গুলিয়ে ফেলে: মডেলের বাছাই কতটা এলোমেলো, আর উত্তরটা সত্য কি না। এই পাতা দুটোকে আলাদা করে। দেখবেন প্রম্পট কী নিয়ন্ত্রণ করে আর সেটিং কী করে, temperature ও top-p কী করে, কেন কোনো সেটিং না-থাকতে বা প্রত্যাখ্যাত হতে পারে, এবং পুনরাবৃত্তিযোগ্যতা ধরে না নিয়ে কীভাবে মাপবেন।

কোডে স্ট্যান্ডার্ড লাইব্রেরি আর promptlab ব্যবহার হয়েছে। এখানকার স্যাম্পলার একটা টয় প্রোভাইডার (toy provider), মানে বানানো স্কোরের একটা স্ট্যান্ড-ইন, যাতে একটা সেটিংয়ের প্রভাব বারবার একই রকম দেখানো যায়। এটা আসল মডেল নয়, আর এর সংখ্যা আসল মডেল সম্পর্কে কিছু বলে না। আসল মডেল কম অনুমানযোগ্য, তাই নিজে মাপতে হয়।

যা শিখবেন

• প্রম্পট নির্দেশ আর ইনফারেন্স সেটিংয়ের পার্থক্য, এবং প্রম্পটের একটা বাক্য কেন সেটিং বদলাতে পারে না।
• স্যাম্পলারে temperature ও top-p কী বদলায় এবং কী বদলাতে পারে না।
• কেন এলোমেলোভাব আর নির্ভুলতা এক নয়, এবং কয়েকটা রানের মধ্যে পুনরাবৃত্তিযোগ্যতা কীভাবে তুলনা করবেন।
• রিজনিং-এফোর্ট কন্ট্রোল ও আউটপুট-দৈর্ঘ্যের সম্পর্ক, এবং কেন দুটো মডেলে একই প্যারামিটার ধরে নেবেন না।
• সেটিং বদলানোর আগে প্রোভাইডারের বর্তমান ডকুমেন্টেশন কীভাবে পড়বেন।

প্রম্পট নির্দেশ বনাম ইনফারেন্স সেটিং

প্রম্পট নির্দেশ হলো মডেলের পড়া লেখা: কাজ, ফরম্যাট, নিয়ম। ইনফারেন্স সেটিং (inference setting) হলো প্রম্পটের পাশে অনুরোধে বা অ্যাপের কন্ট্রোলে পাঠানো মান: কতটা এলোমেলোভাবে টোকেন বাছবে, আউটপুট কত লম্বা হতে পারবে, কতটা ভাববে। মডেল সেটিং পড়তে পারে না, আর প্রম্পটের ভেতর থেকে সেটিং বদলানো যায় না।

দুর্বল প্রম্পট:

Use temperature 0 and top-p 0.1 and give me the most accurate answer.

এই প্রম্পট স্যাম্পলিং কিছুই বদলায় না। মডেল শুধু শব্দগুলো পড়ে, আর "most accurate" একটা ফাঁকা অনুরোধ। কাজটা কাজের ভেতরেই বলুন, আর সেটিং যেখানে থাকে সেখানে দিন।

ভালো প্রম্পট:

Classify the review as POSITIVE, NEGATIVE or MIXED. Reply with the label only.
If the review has both praise and a complaint, the label is MIXED.
### REVIEW
The screen is great, but the battery lasts half a day.

স্যাম্পলিং কন্ট্রোল হিসেবে temperature ও top-p

মডেল প্রতিটা সম্ভাব্য পরের টোকেনকে স্কোর দেয়, আর একটা স্যাম্পলার (sampler) একটা বেছে নেয়। Temperature বাছাইয়ের আগে স্কোরগুলোকে নতুন করে মাপে: কম মানে সর্বোচ্চ স্কোরের পছন্দগুলো আরও প্রবল, বেশি মানে সম্ভাবনা অন্যগুলোর ওপর ছড়ায়। Top-p (nucleus sampling-ও বলা হয়) সবচেয়ে ছোট সেই শীর্ষ দলটা রাখে যার সম্ভাবনার যোগফল p-এ পৌঁছায়, বাকিটা বাদ দেয়। দুটোই কোন টোকেন বাছা যাবে তা বদলায়; কোনোটাই জ্ঞান যোগ করে না। নিচের টয় কলকবজা দেখায়। স্কোরগুলো বানানো, আর প্রথম প্রশ্নে একটা ভুল উত্তর শীর্ষে বসানো, যেমন একটা প্রচলিত ভুল শিখে-ফেলা মডেলের হতে পারে।

import math, random
from collections import Counter
from promptlab import Client, ProviderError

SCORES = {   # invented raw scores of a toy "model" for each candidate answer
    "capital of Australia": {"Sydney": 2.0, "Canberra": 1.6, "Melbourne": 0.5, "Perth": -1.0},
    "capital of France": {"Paris": 3.0, "Lyon": 1.0, "Marseille": 0.5, "Nice": 0.0},
}
TRUTH = {"capital of Australia": "Canberra", "capital of France": "Paris"}

def probs(scores, temperature=1.0, top_p=1.0):
    """Softmax with temperature, then keep the smallest top set whose probability reaches top_p."""
    if temperature <= 0:
        return {max(scores, key=scores.get): 1.0}
    weights = {k: math.exp(v / temperature) for k, v in scores.items()}
    total = sum(weights.values())
    kept, mass = {}, 0.0
    for k in sorted(weights, key=weights.get, reverse=True):
        kept[k] = weights[k] / total
        mass += kept[k]
        if mass >= top_p:
            break
    norm = sum(kept.values())
    return {k: v / norm for k, v in kept.items()}

def toy_sampler(messages, temperature=1.0, top_p=1.0, seed=0, **settings):
    """Stand-in model: samples one answer from the toy scores. It has no idea what is true."""
    p = probs(SCORES[messages[-1]["content"]], temperature, top_p)
    return random.Random(seed).choices(list(p), weights=list(p.values()))[0]

client = Client(toy_sampler)
def run(question, n=200, **settings):
    return Counter(client.complete([{"role": "user", "content": question}], seed=i, **settings).text for i in range(n))

print(f"{'question':22} {'temp':>4} {'top_p':>5}  {'correct':>7}  {'most common answer (share)'}")
for q in SCORES:
    for t, tp in [(0, 1.0), (0.3, 1.0), (1.0, 1.0), (1.0, 0.5), (2.0, 1.0)]:
        c = run(q, temperature=t, top_p=tp)
        top, k = c.most_common(1)[0]
        print(f"{q:22} {t:>4} {tp:>5}  {c[TRUTH[q]] / 200:7.0%}  {top} ({k / 200:.0%})")

question               temp top_p  correct  most common answer (share)
capital of Australia      0   1.0       0%  Sydney (100%)
capital of Australia    0.3   1.0      21%  Sydney (79%)
capital of Australia    1.0   1.0      31%  Sydney (54%)
capital of Australia    1.0   0.5       0%  Sydney (100%)
capital of Australia    2.0   1.0      34%  Sydney (41%)
capital of France         0   1.0     100%  Paris (100%)
capital of France       0.3   1.0     100%  Paris (100%)
capital of France       1.0   1.0      80%  Paris (80%)
capital of France       1.0   0.5     100%  Paris (100%)
capital of France       2.0   1.0      57%  Paris (57%)

এলোমেলোভাব নির্ভুলতা নয়

টেবিলটা প্রশ্ন ধরে পড়ুন। ফ্রান্সের ক্ষেত্রে পছন্দের উত্তর ঠিক, তাই এলোমেলোভাব কমালে ঠিক উত্তর বেশি আসে। অস্ট্রেলিয়ার ক্ষেত্রে পছন্দের উত্তর ভুল: temperature 0-তে টয় ২০০ বারের ২০০ বারই ভুল উত্তর দেয়, পুরোপুরি পুনরাবৃত্তিযোগ্য আর পুরোপুরি ভুল। temperature বাড়ালে ঠিক উত্তর মাঝে মাঝে আসে, কিন্তু শুধু এজন্য যে ভুল পছন্দটা দুর্বল হয়; ফ্রান্সে একই পরিবর্তনে উত্তর খারাপ হয়। Top-p 0.5 লেজ কেটে অস্ট্রেলিয়ার ঠিক উত্তরটাও সরিয়ে দেয়। শিক্ষাটা "temperature বাড়াও" নয়। শিক্ষা হলো, স্যাম্পলিং সেটিং বদলায় বৈচিত্র্য; সত্য আসে মডেলের জ্ঞান, আপনার উৎস ও আপনার যাচাই থেকে।

প্রচলিত পরামর্শে দুটো সংশোধন। কম temperature উত্তরকে বেশি সত্য করে না। আর আসল সার্ভিসে temperature 0 হুবহু একই আউটপুটের গ্যারান্টি দেয় না: কম এলোমেলোভাব আউটপুটকে বেশি সদৃশ করে, আর প্রোভাইডাররা শব্দে-শব্দে পুনরাবৃত্তির প্রতিশ্রুতি দেয় না। আপনার প্রোভাইডারের ভাষা দেখে নিন।

স্যাম্পলিং কন্ট্রোল অসমর্থিত বা সীমিত হলে

কিছু মডেল, বিশেষ করে রিজনিং মডেল, স্যাম্পলিং সেটিং প্রত্যাখ্যান বা উপেক্ষা করে। আপনার কোডকে এটা আশা করতে হবে: সেটিং একটা অনুরোধ, যা ব্যর্থ হতে পারে।

প্রোভাইডার নোট (২০২৬-১০-১২ অনুযায়ী): OpenAI-এর latest-model গাইড বলে, রিজনিং এফোর্ট none না হলে temperature, top_p ও top_logprobs সরিয়ে ফেলতে; পরিবারের কিছু মডেল এফোর্ট none নেয় না, তাই সেগুলোতে এগুলো সবসময়ই অনুপলব্ধ। Anthropic-এর মাইগ্রেশন গাইড বলে, বর্তমান মডেলে ডিফল্টের বাইরের temperature, top_p বা top_k দিলে 400 এরর আসে; সরিয়ে ফেলুন। Google-এর Gemini 3 ডকুমেন্টেশন এগুলো ডিফল্ট মানে রাখার জোরালো সুপারিশ করে এবং বলে 1.0-এর নিচের temperature লুপিং ঘটাতে পারে। এই বক্তব্যগুলো মডেল-ভিত্তিক এবং বদলায়; পুরোনো রেফারেন্স পাতায় প্যারামিটারগুলো এখনও সাধারণ বলে তালিকাভুক্ত থাকতে পারে। বর্তমান ডকুমেন্টেশন দেখে নিন।

একটা ছোট র‍্যাপার ব্যাপারটা স্পষ্ট করে: সেটিং দিয়ে চেষ্টা করুন, প্রত্যাখ্যাত হলে সেটিং ছাড়া আবার চালান, আর কী বাদ গেল লিখে রাখুন। এখানকার সীমিত প্রোভাইডার একটা স্ট্যান্ড-ইন, যা প্যারামিটার প্রত্যাখ্যান করা মডেলের মতো আচরণ করে।

def toy_restricted(messages, **settings):
    """Stand-in for a model that rejects sampling settings, like a 400 error."""
    bad = sorted(set(settings) & {"temperature", "top_p", "top_k"})
    if bad:
        raise ValueError(f"unsupported parameter(s): {', '.join(bad)}")
    return "Canberra"

def call_with_fallback(client, messages, **settings):
    """Try with the settings; if rejected, retry once without them and report what was dropped."""
    try:
        return client.complete(messages, **settings).text, []
    except ProviderError:
        return client.complete(messages).text, sorted(settings)

print(call_with_fallback(Client(toy_restricted), [{"role": "user", "content": "capital of Australia"}], temperature=0.2, top_p=0.9))
print(call_with_fallback(Client(toy_sampler), [{"role": "user", "content": "capital of France"}], temperature=0.2))

('Canberra', ['temperature', 'top_p'])
('Paris', [])

প্রথম লাইনে উত্তর আর বাদ-যাওয়া দুটো সেটিং দেখা যায়; দ্বিতীয় লাইনে কিছু বাদ যায়নি। ফলের সঙ্গে বাদ-যাওয়া তালিকা লগ করুন, কারণ "রানটা ডিফল্ট স্যাম্পলিংয়ে হয়েছে" আপনার পরীক্ষার অংশ।

কয়েকটা রানে পুনরাবৃত্তিযোগ্যতার তুলনা

পুনরাবৃত্তিযোগ্যতা (repeatability) মানে একই প্রম্পটের বারবার রান কতবার একমত হয়। মাপুন: প্রম্পটটা কয়েকবার চালান, আউটপুট নর্মালাইজ করুন (ট্রিম, ছোট হাতের অক্ষর, লেবেল বের করা), আর সবচেয়ে প্রচলিত উত্তরের ভাগ গুনুন। প্রথম টেবিলের শেষ কলাম ঠিক এটাই। temperature 0.3-তে টয়ে অস্ট্রেলিয়ার উত্তর ৭৯% একমত ছিল; 2.0-তে ৪১%। আসল মডেলে প্রতি কেসে তিন থেকে দশ রান সস্তা শুরু।

পুনরাবৃত্তিযোগ্যতা বাড়াতে নবের ওপর ভরসা না করে কাজ সংকীর্ণ করুন: নির্দিষ্ট লেবেল তালিকা, নির্দিষ্ট আউটপুট ফরম্যাট, যেখানে আছে সেখানে স্কিমা-সীমাবদ্ধ আউটপুট, এবং উদাহরণ। একটা প্রোভাইডারের সামঞ্জস্য-নির্দেশনাও স্যাম্পলিং সেটিংয়ের বদলে নির্দিষ্ট ফরম্যাট, উদাহরণ, স্ট্রাকচার্ড আউটপুট, রিট্রিভাল ও চেইনিংয়ের দিকে ইঙ্গিত করে। প্রম্পট চেইনিং: ধাপ, নির্দিষ্ট স্কিমা ও promptlab হেল্পার এর চেইনিং দিকটা দেখিয়েছিল।

নমুনা উত্তর (উদাহরণ মাত্র; আপনারটা আলাদা হবে):

Run 1: MIXED
Run 2: MIXED
Run 3: Mixed - praise for the screen, a complaint about the battery.
Run 4: MIXED

কী লক্ষ করবেন: রান ৩-এর অর্থ একই, কিন্তু আকৃতি আলাদা। সাধারণ সমতা-চেক এটাকে অমিল গুনবে। আগে নর্মালাইজ করুন, তারপর তুলনা করুন, আর ঠিক করুন বাড়তি শব্দ ফরম্যাট-নিয়মের ব্যর্থতা কি না।

রিজনিং-এফোর্ট কন্ট্রোল ও আউটপুট বাজেট

কিছু মডেলে উত্তরের আগে কতটা ভাববে তা ঠিক করা যায়। এটা একটা রিজনিং-এফোর্ট (reasoning-effort) কন্ট্রোল: একদিকে গতি ও খরচ, অন্যদিকে কঠিন কাজে মানের মধ্যে একটা ডায়াল। এটা স্যাম্পলিং কন্ট্রোল নয়, আর ভালো উত্তরের গ্যারান্টি দেয় না। অন্য সেটিংয়ের মতোই ব্যবহার করুন: নিজের কেসে মাপুন, একবারে একটাই বদলান।

ভাবনা থেকে তৈরি হয় লুকানো বা সংক্ষিপ্ত রিজনিং টোকেন। এগুলো সাধারণত আউটপুট হিসেবে বিল হয় এবং কনটেক্সট উইন্ডোর জায়গা নেয়, যদিও দৃশ্যমান উত্তর ছোট হতে পারে। তাই দৃশ্যমান দৈর্ঘ্য আর রিজনিং বাজেট আলাদা জিনিস, এবং একটা আউটপুট সীমা দুটোর ওপর একসঙ্গে খাটতে পারে। সীমা ভাবনার জন্য ছোট হলে উত্তর খালি বা কাটা আসতে পারে। নিচের টয় বানানো আকার দিয়ে প্রভাবটা দেখায়।

def toy_effort(effort, cap=600):
    """Stand-in: hidden reasoning tokens use the same output budget as the visible answer (invented sizes)."""
    reasoning = {"low": 50, "medium": 300, "high": 900}[effort]
    visible = max(0, min(250, cap - reasoning))
    return {"effort": effort, "reasoning": reasoning, "visible": visible, "complete": visible == 250}

for e in ("low", "medium", "high"):
    print(toy_effort(e))

{'effort': 'low', 'reasoning': 50, 'visible': 250, 'complete': True}
{'effort': 'medium', 'reasoning': 300, 'visible': 250, 'complete': True}
{'effort': 'high', 'reasoning': 900, 'visible': 0, 'complete': False}

একই সীমায় সর্বোচ্চ এফোর্ট দৃশ্যমান উত্তরের জন্য কোনো জায়গা রাখে না। লেখা ব্যবহারের আগে সবসময় স্টপ স্ট্যাটাস দেখুন (কাটা উত্তর স্বাভাবিক শেষ থেকে আলাদা করে জানানো হয়)।

প্রোভাইডার নোট (২০২৬-১০-১২ অনুযায়ী): OpenAI কয়েক স্তরের reasoning.effort দেয়, যা মডেল-ভেদে আলাদা, এবং রিজনিং টোকেন ইউজেজ ডিটেইলসে জানানো হয়। Anthropic অ্যাডাপ্টিভ থিংকিং ও একটা effort সেটিং বর্ণনা করে; ম্যানুয়াল budget_tokens deprecated এবং নতুনতম মডেলে 400 এরর দেয়, আর কিছু মডেলে থিংকিং সবসময় চালু থাকতে পারে। Google thinking_level ব্যবহার করে (পুরোনো ডকুমেন্টে টোকেন বাজেটের বর্ণনা ছিল)। আপনার মডেলের জন্য বর্তমান ডকুমেন্টেশন দেখুন।

সব মডেলে একই প্যারামিটার ধরে নেবেন না

সেটিং বদলানোর আগে প্রোভাইডারের বর্তমান ডকুমেন্টেশন পড়ুন

সেটিংয়ে হাত দেওয়ার আগে একটা ছোট রুটিন:

1. আপনার ঠিক মডেলের পাতা খুলুন; অন্য মডেলের গাইড আপনার জন্য ভুল হতে পারে।
2. খুঁজুন: কোন প্যারামিটার গৃহীত, তাদের ডিফল্ট, এবং "remove" বা "recommended default" লেখা কোনো মন্তব্য।
3. পরীক্ষার নোটে মডেল আইডেন্টিফায়ার, সেটিং ও তারিখ লিখে রাখুন।
4. একটা সেটিং বদলান, একই কেস কয়েকবার চালান, তুলনা করুন। প্রম্পট ক্যাশিং ও খরচ: স্থির প্রিফিক্স, ব্যবহারের ডেটা ও আনুমানিক হিসাব এই এক্সপেরিমেন্ট বানায়।

কাজের জায়গায় এটা কোথায় দেখা যায়

টিকেট ক্লাসিফাই করা টিম প্রতিবার একই লেবেল চায়। লেখকেরা বিভিন্ন বিকল্প চান। বিশ্লেষকেরা কঠিন সমস্যায় মডেল আরও ভাবুক চান। প্রতিটা প্রয়োজনের আলাদা হাতিয়ার: সামঞ্জস্যের জন্য সংকীর্ণ প্রম্পট ও ফরম্যাট, বৈচিত্র্যের জন্য "give me five options" নির্দেশ, আর ভাবনার জন্য যেখানে আছে সেখানে এফোর্ট কন্ট্রোল। ভেন্ডর মডেল বদলালে দেখে নিন আপনার সেটিং এখনও গৃহীত কি না।

সাধারণ ভুল

• নির্ভুলতার সমাধান হিসেবে কম temperature ব্যবহার। এতে ভুল উত্তরও পুনরাবৃত্ত হয়। উৎস ও যাচাই ঠিক করুন।
• প্রম্পটে "temperature 0" লেখা। মডেল এটাকে লেখা হিসেবে পড়ে; সেটিং বদলায় না।
• temperature 0-তে হুবহু একই আউটপুট আশা করা। প্রতিশ্রুতি নেই। নর্মালাইজ করে তুলনা করুন।
• সব মডেলে স্যাম্পলিং সেটিং হার্ড-কোড করা। যে মডেল প্রত্যাখ্যান করে তাতে কল ভেঙে যায়। র‍্যাপ ও লগ করুন।
• ভাবনা-করা মডেলে ছোট আউটপুট সীমা দেওয়া। লুকানো রিজনিং বাজেট খেয়ে উত্তর কেটে দিতে পারে।

নিজে চেষ্টা করুন

পাতার ব্লকগুলো ক্রমানুসারে একটা Python ফোল্ডারে চালান, পাশে promptlab.py রেখে।

1. সহজ। দুই বাক্যে ব্যাখ্যা করুন চ্যাট প্রম্পটে "Set temperature to 0" লিখলে কেন কিছুই হয় না।
2. মাঝারি। run দিয়ে "capital of Australia" ও "capital of France"-এর জন্য temperature 0.1 ও 1.5 তুলনা করুন। কোন প্রশ্ন কম temperature-এ ভালো হয়, এবং কেন এটা সাধারণ নিয়ম নয়?
3. কঠিন। agreement(question, runs, **settings) লিখুন, যা সবচেয়ে প্রচলিত উত্তরের ভাগ ফেরত দেয়, এবং ফ্রান্সের প্রশ্নে তিনটা কনফিগারেশন থেকে বাছতে এটা ব্যবহার করুন। একটা নিয়ম যোগ করুন: যে কনফিগারেশনে ঠিক উত্তর কম, বেশি একমত হলেও তা বাদ।

উত্তর

সহজ। মডেল বাক্যটাকে সাধারণ লেখা হিসেবে পড়ে; স্যাম্পলিং সেটিং আলাদা অনুরোধ-মান বা অ্যাপ কন্ট্রোল হিসেবে যায়, এবং মডেল তা বদলাতে পারে না। পাস চেকলিস্ট: লেখা ও সেটিংয়ের পার্থক্য বলা আছে; সেটিং আসলে কোথায় থাকে তা বলা আছে।

মাঝারি।

for q in SCORES:
    for t in (0.1, 1.5):
        c = run(q, temperature=t)
        print(f"{q:22} temp {t}: correct {c[TRUTH[q]] / 200:.0%}")

capital of Australia   temp 0.1: correct 0%
capital of Australia   temp 1.5: correct 34%
capital of France      temp 0.1: correct 100%
capital of France      temp 1.5: correct 68%

ফ্রান্স কম temperature-এ ভালো হয় কারণ তার সর্বোচ্চ-স্কোর উত্তর ঠিক; অস্ট্রেলিয়া খারাপ হয় কারণ তার সর্বোচ্চ-স্কোর উত্তর ভুল। সেটিং মডেলের আগে থেকে পছন্দ-করা জিনিসকেই বাড়ায়। পাস চেকলিস্ট: দুটো প্রশ্নই তুলনা করা হয়েছে; কারণ হলো টয়ের স্কোরে ঠিক উত্তরের অবস্থান; আসল মডেল নিয়ে কোনো দাবি নেই।

কঠিন।

def agreement(question, runs=200, **settings):
    c = run(question, runs, **settings)
    return c.most_common(1)[0][1] / runs, c["Paris"] / runs

for cfg in [dict(temperature=0.0), dict(temperature=1.0), dict(temperature=1.0, top_p=0.5)]:
    agree, correct = agreement("capital of France", **cfg)
    print(cfg, f"agree {agree:.0%} correct {correct:.0%}", "REJECT" if correct < 1 else "ok")

{'temperature': 0.0} agree 100% correct 100% ok
{'temperature': 1.0} agree 80% correct 80% REJECT
{'temperature': 1.0, 'top_p': 0.5} agree 100% correct 100% ok

পাস চেকলিস্ট: একমত হওয়া ও ঠিক হওয়া আলাদা মাপা হয়েছে; বাতিলের নিয়ম ঠিক-হওয়ার ওপর; উত্তরে বলা আছে শুধু একমত হওয়া দেখলে এমন কনফিগারেশন বাছা হতে পারে যা পুনরাবৃত্তভাবে ভুল, এবং একটা টয় আসল মডেলের সেটিং ঠিক করতে পারে না।

সারসংক্ষেপ

• প্রম্পটে থাকে কাজ; সেটিং আলাদা অনুরোধ-মান। প্রম্পট সেটিং বদলাতে পারে না।
• Temperature ও top-p বৈচিত্র্য বদলায়। সত্য যোগ করে না, আর temperature 0 হুবহু একই আউটপুটের গ্যারান্টি নয়।
• কিছু মডেল স্যাম্পলিং সেটিং সীমিত বা প্রত্যাখ্যান করে; কল র‍্যাপ করুন এবং কী প্রয়োগ হলো লগ করুন।
• বারবার রান ও নর্মালাইজ করা তুলনায় পুনরাবৃত্তিযোগ্যতা মাপুন; সংকীর্ণ কাজ ও নির্দিষ্ট ফরম্যাটে তা বাড়ান।
• রিজনিং এফোর্ট ও আউটপুট সীমা লুকানো রিজনিং টোকেনের মাধ্যমে একে অন্যকে প্রভাবিত করে; স্টপ স্ট্যাটাস দেখুন।
• কোনো সেটিং বদলানোর আগে আপনার ঠিক মডেলের বর্তমান ডকুমেন্টেশন পড়ুন।

এরপর: প্রম্পট ক্যাশিং ও খরচ: স্থির প্রিফিক্স, ব্যবহারের ডেটা ও আনুমানিক হিসাব, যেখানে নিয়ন্ত্রিত সেটিংস এক্সপেরিমেন্ট চালিয়ে ক্যাশ ব্যবহার ও খরচ দেখবেন।