রিজনিং টাস্ক ডিজাইন: টাস্ক ভাগ করা, যুক্তির সারাংশ ও মধ্যবর্তী স্কিমা

কিছু টাস্কে একটা পরিষ্কার লেখা দরকার। অন্যগুলোতে কয়েকটা তথ্য খুঁজে বের করতে হয়, নিয়ম দিয়ে মেলাতে হয়, তারপর সিদ্ধান্তে পৌঁছাতে হয়; সেখানে একটা ধাপের ভুল আত্মবিশ্বাসী কিন্তু ভুল উত্তর দেয়। প্রম্পটের ডিজাইন এই পার্থক্য অনুসরণ করা উচিত। এই পাতা দেখায় দুই ধরনের টাস্ক কীভাবে আলাদা করবেন, কঠিন টাস্ককে যাচাই করা যায় এমন ধাপে কীভাবে ভাগ করবেন, আর যে গল্প বিশ্বাস করতে হয় তার বদলে যাচাইযোগ্য ব্যাখ্যা কীভাবে চাইবেন।

আপনার Python ৩.১২ বা তার পরের ভার্সন লাগবে, আর শুধু স্ট্যান্ডার্ড লাইব্রেরি। ব্লকগুলো ভেরিয়েবল ভাগ করে নেয়, তাই পরপর টাইপ করুন। কোডের "মডেল" ফাংশনগুলো টয় প্রোভাইডার (toy provider): ছোট, নির্দিষ্ট ফল দেওয়া বদলি, যা যাচাইকে পুনরাবৃত্তিযোগ্য করে। আসল মডেল আরও অনির্দিষ্ট, আর সেজন্যই টেস্ট করতে হয়; টয়ের ফল কখনোই আসল মডেল সম্পর্কে প্রমাণ নয়।

যা শিখবেন

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

সরল জেনারেশন, না বহুধাপের রিজনিং

সরল জেনারেশন আর বহুধাপের রিজনিং টাস্ক আলাদা করুন। সরল জেনারেশনে অনেক রকম আউটপুটই গ্রহণযোগ্য, আর ফল পড়েই বিচার করা যায়: এই বাক্যটা নতুন করে লিখুন, তিনটা হেডলাইন প্রস্তাব করুন। বহুধাপের রিজনিংয়ে উত্তর নির্ভর করে একটা নির্দিষ্ট ক্রমে মেলানো কয়েকটা তথ্যের ওপর, আর মাঝের একটা ধাপ ভুল হলেও শেষ উত্তর সুন্দর শোনায়: একটা রিটার্নে রিফান্ড পাওয়া যাবে কি না ঠিক করুন আর পরিমাণ হিসাব করুন। দ্বিতীয় ধরনটা নিঃশব্দে ব্যর্থ হয়।

কঠিনতা ও ভুলের খরচ দিয়ে টাস্ক শ্রেণিবদ্ধ করুন

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

TASKS = [  # (task, dependent steps, cost of an error)
    ("Rewrite a two-line apology calmly", 1, "low"),
    ("Pull the invoice number out of an email", 1, "high"),
    ("Draft three newsletter headlines", 1, "low"),
    ("Decide a return and compute the refund", 4, "high"),
    ("Plan shift cover from five notes", 3, "low"),
]


def route(steps, cost):
    design = "direct instruction" if steps == 1 else "explicit subtasks"
    if cost == "high":
        design += " + independent check" + (" + human review" if steps != 1 else "")
    return design


for task, steps, cost in TASKS:
    print(task.ljust(42), str(steps), cost.ljust(5), route(steps, cost))

Rewrite a two-line apology calmly          1 low   direct instruction
Pull the invoice number out of an email    1 high  direct instruction + independent check
Draft three newsletter headlines           1 low   direct instruction
Decide a return and compute the refund     4 high  explicit subtasks + independent check + human review
Plan shift cover from five notes           3 low   explicit subtasks

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

সরল টাস্কে সরাসরি নির্দেশ

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

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

First analyse the tone of this apology in depth, then list its weaknesses, then plan a
rewrite, then rewrite it, then evaluate your rewrite and improve it again: "Sorry, we messed up."

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

Rewrite this apology in a calm, professional tone, in two sentences or fewer:
"Sorry, we messed up."

কী বদলাল: ভালো প্রম্পট লক্ষ্য, টোন ও দৈর্ঘ্য বলেছে, আর এক ধাপের টাস্কে কিছু যোগ না করা পাঁচটা ধাপ বাদ দিয়েছে। বাঁচানো পরিশ্রম রাখুন সেই টাস্কের জন্য, যেখানে কাঠামো সত্যিই দরকার।

সাবটাস্কে ভাগ করুন এবং নির্ভরতা ঠিক করুন

জটিল টাস্ককে স্পষ্ট সাবটাস্কে ভাগ করুন, এবং সাবটাস্কগুলোর মধ্যে নির্ভরতা সংজ্ঞায়িত করুন। আমাদের চলমান সমস্যা একটা রিটার্ন অনুরোধ, যাতে দুটো নিয়ম: R1, ডেলিভারির ৩০ দিনের মধ্যে রিটার্ন করতে হবে; R2, প্রতিটা খোলা ইউনিটের জন্য ইউনিট দামের ১০% রিস্টকিং ফি। কাজ পাঁচ ভাগে ভাগ হয়। খেয়াল করুন, এর তিনটা মডেল কল নয়, সাধারণ কোড: নিয়মের মান, তারিখের হিসাব আর টাকার অঙ্ক। তারিখ ও টাকা প্রোগ্রামে হিসাব করা ভালো, যা প্রতিবার একই উত্তর দেয়। (একই ধারণা আছে মূল প্যাটার্ন ২: ভাগ করা, সমালোচনা ও সংশোধন পাতায়।)

from graphlib import CycleError, TopologicalSorter

SUBTASKS = {  # name: (done by, needs)
    "policy": ("code", []),
    "extract": ("model", []),
    "eligible": ("code", ["extract", "policy"]),
    "amount": ("code", ["extract", "eligible", "policy"]),
    "reply": ("model", ["eligible", "amount"]),
}


def rounds(subtasks):
    sorter = TopologicalSorter({name: needs for name, (_, needs) in subtasks.items()})
    sorter.prepare()
    out = []
    while sorter.is_active():
        ready = sorted(sorter.get_ready())
        out.append(ready)
        sorter.done(*ready)
    return out


for i, batch in enumerate(rounds(SUBTASKS), 1):
    print(f"round {i}:", ", ".join(f"{n} ({SUBTASKS[n][0]})" for n in batch))
try:
    rounds(dict(SUBTASKS, policy=("code", ["reply"])))
except CycleError as error:
    print("cycle between:", sorted(set(error.args[1])))

round 1: extract (model), policy (code)
round 2: eligible (code)
round 3: amount (code)
round 4: reply (model)
cycle between: ['amount', 'eligible', 'policy', 'reply']

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

মধ্যবর্তী আউটপুট স্কিমা

মধ্যবর্তী আউটপুট স্কিমা দিন। প্রতিটা মডেল ধাপ নির্দিষ্ট ফিল্ডসহ একটা ছোট রেকর্ড ফেরত দেবে, আর পরের ধাপ সেটা পড়ার আগে আপনার কোড তা যাচাই করবে। এখানে এক্সট্র্যাকশন ধাপকে ছয়টা ফিল্ড ফেরত দিতে হবে; টাকা থাকে দুই দশমিকের স্ট্রিং হিসেবে, যাতে float রাউন্ডিং না ঢোকে। এক্সট্র্যাক্টর একটা টয় বদলি; toy_extract_sloppy এমন একটা ধাপ নকল করে যে সঠিক বিষয়বস্তু ভুল টাইপে ফেরত দেয়।

import json
import re
from datetime import date
from decimal import ROUND_HALF_UP, Decimal


def is_iso(v):
    try:
        date.fromisoformat(v)
        return True
    except (TypeError, ValueError):
        return False


STAGE1 = {
    "item": lambda v: isinstance(v, str) and v != "",
    "qty": lambda v: type(v) is int and v in range(1, 1000),
    "unit_price": lambda v: isinstance(v, str) and re.fullmatch(r"\d+\.\d\d", v) is not None,
    "delivered": is_iso,
    "returned": is_iso,
    "opened_units": lambda v: type(v) is int and v in range(0, 1000),
}
MESSAGE = ("Hi, I am Lena. I bought 2 Trail Lamp at 24.50 each, delivered 2026-09-20. "
           "I opened one and want to return both on 2026-10-05.")


def problems(record, schema):
    out = [f"missing: {k}" for k in schema if k not in record]
    out += [f"bad value: {k}={record[k]!r}" for k, ok in schema.items() if k in record and not ok(record[k])]
    return out + [f"unexpected: {k}" for k in sorted(record) if k not in schema]


def toy_extract(text):  # stand-in for the extraction model
    qty, item, price, delivered, returned = re.search(
        r"bought (\d+) (.+?) at (\d+\.\d\d) each, delivered (\S+)\. .*return both on (\S+)\.", text).groups()
    return {"item": item, "qty": int(qty), "unit_price": price, "delivered": delivered,
            "returned": returned, "opened_units": 1}  # "I opened one"


def toy_extract_sloppy(text):  # stand-in that returns the right content in the wrong types
    return dict(toy_extract(text), qty="2", delivered="20 Sep")


def decide(rec):
    days = (date.fromisoformat(rec["returned"]) - date.fromisoformat(rec["delivered"])).days
    if days not in range(0, 31):
        return {"eligible": False, "rule": "R1", "days": days}
    price = Decimal(rec["unit_price"])
    fee = (price * Decimal("0.10") * rec["opened_units"]).quantize(Decimal("0.01"), ROUND_HALF_UP)
    return {"eligible": True, "rule": "R2", "days": days, "fee": str(fee),
            "refund": str(price * rec["qty"] - fee)}


def chain(message, extractor):
    record = extractor(message)
    bad = problems(record, STAGE1)
    return {"stopped_at": "extract", "problems": bad} if bad else decide(record)


for extractor in (toy_extract, toy_extract_sloppy):
    print(extractor.__name__, json.dumps(chain(MESSAGE, extractor), sort_keys=True))

toy_extract {"days": 15, "eligible": true, "fee": "2.45", "refund": "46.55", "rule": "R2"}
toy_extract_sloppy {"problems": ["bad value: qty='2'", "bad value: delivered='20 Sep'"], "stopped_at": "extract"}

ভালো এক্সট্র্যাক্টর পার হয়ে যায়: রিটার্ন ডেলিভারির ১৫ দিন পরে, একটা খোলা ইউনিটের ফি ২.৪৫, আর রিফান্ড ৪৬.৫৫। অগোছালো এক্সট্র্যাক্টর প্রথম ধাপেই থামে, খারাপ ফিল্ডের নামসহ, তাই কোনো ভুল মান তারিখ ও টাকার কোডে পৌঁছায় না। নামসহ থামা ভুল রিফান্ডের চেয়ে ডিবাগ করা সস্তা। একটা শেয়ার্ড হেল্পারসহ পূর্ণ চেইন আছে প্রম্পট চেইনিং: ধাপ, নির্দিষ্ট স্কিমা ও promptlab হেল্পার পাতায়।

যাচাইযোগ্য প্রমাণসহ সংক্ষিপ্ত যুক্তি

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

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

Decide whether the return is eligible, using only the rules and the customer message.
Rules:
R1. Return within 30 days of delivery.
R2. Restocking fee: 10% of the unit price for each opened unit.
Return JSON with these keys: decision ("approve", "reject" or "ask"), rule (deciding rule id),
evidence (up to 3 quotes copied exactly from the message), rationale (at most 25 words).
If a needed fact is missing, use "ask" and name the fact in the rationale.

কী বদলাল: মডেলকে একটা নিয়মের দিকে আর ইনপুটের হুবহু শব্দের দিকে নির্দেশ করতে হবে, দৈর্ঘ্য সীমিত, আর তথ্য না থাকলে অনুমোদিত একটা বেরোনোর পথ আছে। এবার একটা সাধারণ ব্যর্থতা। এই নমুনা উত্তর শুধু উদাহরণ:

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

{"decision": "approve", "rule": "R2",
 "evidence": ["delivered 2026-09-20", "the box was damaged"],
 "rationale": "Returned within 30 days and the item arrived damaged, so a fee does not apply."}

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

POLICY = {"R1": "Return within 30 days of delivery.", "R2": "Restocking fee, opened units."}


def check_explanation(source, out):
    issues = [] if out.get("rule") in POLICY else [f"unknown rule: {out.get('rule')!r}"]
    issues += [f"quote not in the message: {q!r}" for q in out.get("evidence", []) if q not in source]
    if len(out.get("rationale", "").split()) > 25:
        issues.append("rationale is longer than 25 words")
    return issues


good = {"decision": "approve", "rule": "R2", "evidence": ["delivered 2026-09-20", "I opened one"],
        "rationale": "Returned after 15 days, inside 30. One unit was opened, so one fee applies."}
invented = dict(good, evidence=["delivered 2026-09-20", "the box was damaged"])
for record in (good, invented):
    print(check_explanation(MESSAGE, record) or "explanation checks pass")

explanation checks pass
["quote not in the message: 'the box was damaged'"]

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

চেইন-অফ-থট অনুরোধের সীমা

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

প্রোভাইডার নোট (২০২৬-১০-১২ অনুযায়ী): OpenAI ডকুমেন্ট করে যে রিজনিং টোকেন API-র মধ্য দিয়ে দেখা যায় না, কনটেক্সটে জায়গা নেয়, আউটপুট টোকেন হিসেবে বিল হয় এবং আউটপুট-টোকেন সীমায় গোনা হয়, তাই দৃশ্যমান কোনো লেখা আসার আগেই রেসপন্স অসম্পূর্ণ অবস্থায় শেষ হতে পারে। Anthropic ডকুমেন্ট করে যে থিঙ্কিং টোকেন আউটপুট হিসেবে বিল হয় এবং সর্বোচ্চ-টোকেন সীমায় গোনা হয়, দেখানো থিঙ্কিং লেখা একটা সারাংশ, কখনোই কাঁচা চেইন অফ থট নয়, আর স্কিমা-সীমাবদ্ধ আউটপুটে ধাপে ধাপে রিজনিং চাইলে প্রত্যাখ্যান ঘটতে পারে; তারা বদলে ছোট ব্যাখ্যা চাইতে পরামর্শ দেয়। Google ডকুমেন্ট করে যে থট সারাংশ ঐচ্ছিক এবং বিল হয় পুরো থট টোকেনে। বর্তমান ডকুমেন্টেশন দেখে নিন।

সরাসরি প্রম্পট, না ধাপে ধাপে নির্দেশ

সরাসরি প্রম্পটিং আর স্পষ্ট ধাপে ধাপে নির্দেশ তুলনা করুন। "Think step by step" সব মডেলের জন্য সর্বজনীন উন্নতিকারক নয়। একই সিদ্ধান্ত-প্রম্পটের তিনটা সংস্করণ নিচে, প্রতিটা একই কেসে চালানোর প্রম্পট হিসেবে দেওয়া।

প্রম্পট:

Direct: Decide the refund using rules R1 and R2. Return JSON with decision, refund and a
rationale of at most 25 words.

প্রম্পট:

Stepwise: Step 1, list the two dates. Step 2, count the days. Step 3, compare with the 30-day
rule. Step 4, apply the fee to opened units. Show each step, then return the JSON.

প্রম্পট:

Outcome: Goal: a correct refund decision. Constraints: use only R1 and R2 and the message; use
exact quotes as evidence. Output: JSON with decision, refund, evidence, rationale (25 words).

প্রোভাইডার নোট (২০২৬-১০-১২ অনুযায়ী): OpenAI-এর রিজনিং গাইড সুপারিশ করে স্পষ্ট লক্ষ্য, শক্ত কনস্ট্রেইন্ট ও স্পষ্ট আউটপুট চুক্তি, এবং প্রতিটা মধ্যবর্তী ধাপ বেঁধে দিতে নিষেধ করে। Anthropic-এর গাইড নির্দিষ্ট ধাপের বদলে সাধারণ নির্দেশ পছন্দ করে, আর ম্যানুয়াল চেইন-অফ-থটকে থিঙ্কিং বন্ধ থাকলে ফলব্যাক মনে করে। Google-এর গাইড বলে ফেরত দেওয়া রেসপন্সে মডেলকে রিজনিং ধাপ রূপরেখা বা বিশদ করতে বলা সাধারণত দরকার নেই। ২০২৫ সালের একটা সমীক্ষা (Meincke et al.) আগের মডেলে দেখেছে, রিজনিং-নয় এমন মডেলে চেইন-অফ-থটে গড়ে ছোট উন্নতি, কিন্তু উত্তর কম সামঞ্জস্যপূর্ণ ও টোকেন বেশি, আর রিজনিং মডেলে উন্নতি বড়জোর সামান্য। এটাকে দিক হিসেবে পড়ুন, আপনার মডেলের সংখ্যা হিসেবে নয়। বর্তমান ডকুমেন্টেশন দেখে নিন।

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

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

রিফান্ড ও ক্লেইম ডেস্ক, ইনভয়েস অনুমোদন আর যোগ্যতা যাচাই, সবখানে নিয়মের সঙ্গে তথ্য মেলাতে হয়। যে টিমগুলো এটা ভালো করে, তারা নিয়ম রাখে কোডে বা রিভিউ করা নিয়ম-তালিকায়, মডেলকে দিয়ে এলোমেলো লেখা থেকে নির্দিষ্ট রেকর্ড পড়ায়, আর নিয়মের আইডি ও উদ্ধৃতি দিয়ে সিদ্ধান্তকে অনুসরণযোগ্য রাখে। রিভিউয়ার তখন একটা কেস খুলে কয়েক সেকেন্ডে প্রমাণ যাচাই করতে পারেন।

সাধারণ ভুল

1. বহুধাপের সিদ্ধান্তে একটাই বড় প্রম্পট ব্যবহার। যেকোনো ধাপের ভুল লুকিয়ে যায়। টাস্ক ভাগ করুন এবং প্রতিটা ধাপের আউটপুট যাচাই করুন।
2. কোডে সহজে করা যায় এমন অঙ্ক বা তারিখের হিসাব মডেলকে দিয়ে করানো। যোগফল, তারিখ আর নির্ভুল নিয়মের জন্য প্রোগ্রাম ব্যবহার করুন।
3. লেখা যুক্তিকে প্রমাণ ভাবা। এটা তৈরি করা লেখা। নিয়মের আইডি ও হুবহু উদ্ধৃতি চান, এবং সেগুলো যাচাই করুন।
4. প্রতিটা প্রম্পটে "think step by step" বসানো। এতে টোকেন খরচ হয়, কাজে না-ও আসতে পারে, আর মডেলের নিজের থিঙ্কিং মোডের সঙ্গে সংঘাত হতে পারে। নিজের কেসে টেস্ট করুন।
5. সহজ টাস্কে অতিরিক্ত কাঠামো। স্পষ্ট আউটপুটের এক ধাপের টাস্কে সরাসরি নির্দেশই যথেষ্ট।

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

এই পাতার কোড ব্যবহার করুন; ব্লকগুলো একই নেমস্পেস ভাগ করে। অনুশীলনগুলো Beginner টিউটোরিয়ালের সারসংক্ষেপ ও তথ্য নিষ্কাশন: সারাংশ, মূল তথ্য ও প্রমাণ পাতা এবং এই টিউটোরিয়ালের প্রোভাইডারের পার্থক্য ও পোর্টেবিলিটি: গাইড পড়া ও একাধিক মডেলে টেস্ট পাতার প্রোভাইডার-পার্থক্যের চেকগুলো আবার ছোঁয়।

1. সহজ। এই তিন টাস্ককে ধাপ আর ভুলের খরচ দিয়ে মাপুন, তারপর প্রতিটার জন্য route কল করুন: "একটা শুভেচ্ছা অনুবাদ করুন" (১, low), "নীতির সঙ্গে বেতন-স্লিপের যোগফল মেলান" (৩, high), "একটা মিটিংয়ের সারাংশ লিখুন" (১, low)।
2. মাঝারি। STAGE1-এ একটা আবশ্যিক ফিল্ড currency (তিনটা বড় হাতের অক্ষরের স্ট্রিং) যোগ করুন। toy_extract-এর আউটপুটে problems চালান এবং বলুন এক্সট্র্যাকশন প্রম্পটে কী বদলাবেন।
3. কঠিন। "একটা ভ্রমণ খরচের দাবি অনুমোদন বা প্রত্যাখ্যান" টাস্কের জন্য একটা ভাগ-করা নকশা বানান, এই অংশগুলো দিয়ে: দাবিটা রেকর্ডে পড়া, সীমা খুঁজে নেওয়া, এক মুদ্রায় রূপান্তর, তুলনা, আর নোট লেখা। এটা SUBTASKS-ধাঁচের ডিকশনারি হিসেবে লিখুন, রাউন্ডগুলো ছাপুন, আর চিহ্নিত করুন কোন সাবটাস্ক কোড হওয়া উচিত।

উত্তর

সহজ। প্রত্যাশিত নকশা: শুভেচ্ছা সরাসরি নির্দেশ; বেতন-স্লিপ যাচাই স্বাধীন যাচাই ও মানুষের রিভিউসহ স্পষ্ট সাবটাস্ক; মিটিংয়ের সারাংশ সরাসরি নির্দেশ। চালিয়ে নিশ্চিত হন:

for steps, cost in ((1, "low"), (3, "high"), (1, "low")):
    print(route(steps, cost))

direct instruction
explicit subtasks + independent check + human review
direct instruction

পাস চেকলিস্ট: আপনি শব্দ নয়, নির্ভরশীল ধাপ গুনেছেন; বেতন-স্লিপকে সবচেয়ে শক্ত নকশা দিয়েছেন কারণ সেখানে ভুলের খরচ বেশি।

মাঝারি।

STAGE1["currency"] = lambda v: isinstance(v, str) and re.fullmatch(r"[A-Z]{3}", v) is not None
print(problems(toy_extract(MESSAGE), STAGE1))

['missing: currency']

পাস চেকলিস্ট: সমস্যার তালিকা ঠিক অনুপস্থিত ফিল্ডটার নাম বলেছে; আপনি ঠিক করেছেন এক্সট্র্যাকশন প্রম্পটে বলা থাকবে কোন মুদ্রা-চিহ্ন বা শব্দ কোন কোডে যায়, আর মুদ্রা না বলা থাকলে কী ফেরত দেবে (যেমন একটা null, যা চেইন থামিয়ে সিদ্ধান্ত মানুষের হাতে দেয়)।

কঠিন। একটা সম্ভাব্য সমাধান:

CLAIM = {
    "read": ("model", []),
    "limit": ("code", []),
    "convert": ("code", ["read"]),
    "compare": ("code", ["convert", "limit"]),
    "note": ("model", ["compare"]),
}
for i, batch in enumerate(rounds(CLAIM), 1):
    print(f"round {i}:", ", ".join(f"{n} ({CLAIM[n][0]})" for n in batch))

round 1: limit (code), read (model)
round 2: convert (code)
round 3: compare (code)
round 4: note (model)

পাস চেকলিস্ট: দাবি পড়া আর সীমা খোঁজা স্বাধীন, তাই দুটোই রাউন্ড ১-এ; রূপান্তর, তুলনা ও সীমা খোঁজা কোড, কারণ এগুলো নির্ভুল হতে হবে; শুধু এলোমেলো লেখা পড়া আর নোট লেখায় মডেল; কোনো চক্র নেই, আর প্রতিটা মডেল ধাপের পরের ধাপের সামনে একটা আউটপুট স্কিমা আছে।

সারসংক্ষেপ

• সরল জেনারেশন পড়েই বিচার করা যায়; বহুধাপের রিজনিং নিঃশব্দে ব্যর্থ হয় এবং প্রতিটা ধাপে চেক চায়। ধাপের সংখ্যা ও ভুলের খরচ থেকে ডিজাইন বেছে নিন।
• সরল টাস্কে সরাসরি নির্দেশ ব্যবহার করুন। কঠিন টাস্ক লিখিত নির্ভরতাসহ সাবটাস্কে ভাগ করুন, আর তারিখ ও টাকার মতো নির্ভুল কাজ কোডকে দিন।
• প্রতিটা মধ্যবর্তী ফলের জন্য ছোট স্কিমা ঠিক করুন এবং প্রথম খারাপ ফিল্ডেই চেইন থামান।
• নিয়মের আইডি ও হুবহু উদ্ধৃতিসহ ছোট যুক্তি চান, আর যা যাচাই করা যায় তা যাচাই করুন; দৃশ্যমান লেখা লুকানো রিজনিংয়ের রেকর্ড নয়।
• "Think step by step" কিছু মডেলের জন্য একটা হাতিয়ার, নিয়ম নয়। নিজের কেসে সরাসরি, ধাপে ধাপে আর আউটকাম-কেন্দ্রিক সংস্করণ টেস্ট করুন।

এরপর: রিজনিংয়ের ট্রেড-অফ: ধাপে ধাপে প্রম্পট, যাচাই, থামার শর্ত ও খরচ প্ল্যান ও চেকলিস্ট তুলনা করে, স্বাধীন চেক যোগ করে, এবং একই টাস্ক সেটে নির্ভুলতা ও খরচ মাপে।