Tool use আর function calling — LLM থেকে কাজ

এই পর্বের desktop run: Python 3.12, torch 2.15.0, transformers 5.22.2, jsonschema 4.26.0, লেখার সময়ে। Model Qwen/Qwen2.5-0.5B-Instruct (CPU-তে) আর Qwen/Qwen2.5-1.5B-Instruct (GPU-তে), দুটিই Apache 2.0, token ছাড়া নামানো যায়। চারটি tool, ৫টি অর্ডার আর ৪০টি প্রশ্ন এই পর্বের জন্য হাতে লেখা কাল্পনিক বাজারঘর ডেটা; নীতির নথিগুলো এই মডিউলের যৌথ কাল্পনিক সাহায্য-কেন্দ্র (৪০টি নথি)। সব tool sandbox-এ: কোনো network নেই, “বার্তা পাঠানো” শুধু একটি স্থানীয় log ফাইলে লেখা। সব সংখ্যা একটি স্থানীয় run-এর, ছোট model-এর; বড় hosted পণ্য অন্যভাবে আচরণ করতে পারে, আর এই পাতার কোনো সংখ্যা দিয়ে কোনো পণ্যের মান বিচার করা যায় না। LLM-এর মূল ধারণা AI-এর ভিত্তি কোর্সের পর্ব ৭০-এ, JSON Schema আর যাচাই পর্ব ৬২-এ।

১ · Tool use কী — প্রস্তাব model-এর, কাজ আপনার কোডের

LLM নিজে শুধু লেখা তৈরি করে (AI-এর ভিত্তি কোর্সের পর্ব ৭০)। বাজারঘরের গ্রাহক যখন জিজ্ঞেস করেন “আমার অর্ডার BG-10231 কোথায়?”, উত্তরটি model-এর ওজনে নেই, আছে বাজারঘরের database-এ। প্রশ্নটি model-কে সরাসরি দিলে সে বানিয়ে লিখতে পারে, যাকে পর্ব ৫২-এ hallucination বলেছি। Tool calling (function calling নামেও পরিচিত) এই ফাঁক পূরণ করে: model-কে কয়েকটি tool-এর তালিকা দেওয়া হয়, আর model দরকার মনে করলে উত্তরের বদলে একটি structured অনুরোধ লেখে।

পর্ব ৬২-এ দেখেছেন, model-কে JSON Schema মেনে উত্তর দেওয়ানো যায়। Tool calling সেই কৌশলেরই আরেক ব্যবহার, কিন্তু একটি বড় পার্থক্য আছে: এখানে JSON একটি কাজ চালায়। অর্ডার দেখা নিরীহ; গ্রাহককে বার্তা পাঠানো, টাকা ফেরত দেওয়া বা অর্ডার বাতিল করা নিরীহ নয়। তাই এই পর্বের মূল প্রশ্ন: model-এর প্রস্তাব থেকে নিরাপদে কাজ পর্যন্ত কীভাবে যাবেন।

চিত্রে লক্ষ করুন, “tool চলে” ঘরটি model-এর বাইরে। Model কখনো database ছোঁয় না; সে শুধু লেখে। এই সীমারেখাটিই নিরাপত্তার ভিত্তি: model যা-ই লিখুক, আপনার কোড ঠিক করে কোনটি চলবে। একই tool-ব্যবহার বহু ধাপে, পরিকল্পনাসহ চালালে তাকে agent বলে; সেটি পর্ব ৭২ · Agent — পরিকল্পনা, memory আর বহু ধাপের কাজ-এ। এই পর্ব এক বা দুই ধাপের tool ব্যবহারে।

২ · Tool-এর সংজ্ঞা আর chat template — model আসলে কী দেখে

এই পর্বের বাজারঘর সহকারীর চারটি tool, সবই sandbox-এ, মানে শুধু স্থানীয় ফাইল নিয়ে কাজ করে; কোনো network বা আসল বার্তা নেই:

প্রতিটি tool-এর তিনটি অংশ: নাম, বর্ণনা (কখন ব্যবহার করবেন, কখন নয়) আর argument-এর JSON Schema. Schema পড়ার নিয়ম পর্ব ৬২-এ; এখানে নতুন হলো বর্ণনা, কারণ model tool বাছাই করে মূলত নাম আর বর্ণনা পড়ে। Tool-এর তালিকা model-এর কাছে কোনো বিশেষ পথে যায় না। Hugging Face-এর apply_chat_template(messages, tools=tools) তালিকাটিকে model-এর শেখা ছাঁচে লেখা বানিয়ে system বার্তার ভেতরে বসায়। Qwen2.5-এর template-এ যা হয় (সত্যিকারের run, একটি tool রেখে বাকিগুলো “…” দিয়ে ছোট করা):

<|im_start|>system
আপনি বাজারঘর নামের অনলাইন দোকানের সহায়তা-সহকারী। … জিজ্ঞেস করুন।

# Tools

You may call one or more functions to assist with the user query.

You are provided with function signatures within <tools></tools> XML tags:
<tools>
{"type": "function", "function": {"name": "lookup_order", "description": "Look up
 the current status, district, ETA and total of ONE bazarghar order. Use only
 when the user gives an order id like BG-10231. If no id is given, ask for it
 instead of calling.", "parameters": {"type": "object", "properties":
 {"order_id": {"type": "string", "pattern": "^BG-[0-9]{5}$", …}}, …}}}
…
</tools>

For each function call, return a json object with function name and arguments
within <tool_call></tool_call> XML tags:
<tool_call>
{"name": <function-name>, "arguments": <args-json-object>}
</tool_call><|im_end|>
<|im_start|>user
আমার অর্ডার BG-10231 এখন কোথায়?<|im_end|>
<|im_start|>assistant

Model-এর পছন্দের ধরন template-এ লেখা: <tool_call> ট্যাগের ভেতরে {"name": …, "arguments": {…}}. আপনার কোড এই ট্যাগ খুঁজে JSON তোলে। Hosted API-তে এই কাজ server করে আর আলাদা ঘরে দেয় (§৪), কিন্তু ভেতরের ধারণা একই: model একটি বিশেষ ধরনের লেখা লেখে, আর কেউ তা parse করে।

৩ · একটি পূর্ণ round trip — প্রশ্ন থেকে উত্তর পর্যন্ত

নিচের stepper-এর প্রতিটি লেখা আর সংখ্যা সত্যিকারের run থেকে: Qwen2.5-0.5B-Instruct, CPU-তে, greedy decoding, পুরো বর্ণনাসহ tool. প্রশ্ন “আমার অর্ডার BG-10231 এখন কোথায়?” আর কোড একটি ছোট loop: model-এর উত্তরে <tool_call> থাকলে যাচাই করে চালায়, ফল যোগ করে আবার ডাকে; না থাকলে সেটিই শেষ উত্তর।

শেষ ধাপটি এই পর্বের একটি মূল শিক্ষা। Tool calling hallucination কমায়, কারণ তথ্য আসে database থেকে; কিন্তু শেষ উত্তর তখনো model লেখে, আর সে ফলটি বদলে বা বাড়িয়ে লিখতে পারে। তাই যে তথ্য গ্রাহকের কাছে গুরুত্বপূর্ণ (অবস্থা, টাকা, তারিখ), সেগুলো অনেক অ্যাপ model-এর লেখায় না রেখে tool-এর ফল থেকে সরাসরি একটি ছাঁচে বসায়, আর model শুধু ভদ্র বাক্যটুকু লেখে। উত্তরের সঙ্গে উৎসের মিল মাপার পদ্ধতি পর্ব ৭০ · RAG মূল্যায়ন-এ, faithfulness নামে।

৪ · ছয়টি API-র নথিতে tool calling, আর MCP

Hosted API-তে একই চক্র চলে, শুধু ঘরের নাম আলাদা। নিচের সারণি প্রতিটি কোম্পানির নিজের API নথি থেকে, লেখার সময়ে (নভেম্বর ২০২৬) পড়া; নাম আর নিয়ম পরিবর্তন হতে পারে, ব্যবহারের আগে নথিটি নিজে মিলিয়ে নিন। যে বিষয় পড়া পাতায় খুঁজে পাইনি, সেখানে “নথিতে পাইনি” লেখা। সারণিটি কে “ভালো” তা বলে না।

সারণির চারটি শিক্ষা সরাসরি কোডে লাগে। এক, অনেক API-তে arguments একটি লেখা, object নয়; json.loads ব্যর্থ হতে পারে, তাই parse-এর ভুলও ধরতে হয়। দুই, প্রতিটি ডাকের একটি id, আর ফল ফেরত দিতে হয় সেই id মিলিয়ে; Kimi-র নথি সতর্ক করে, না মিললে error. তিন, parallel ডাক অনেক API-তে নিজে থেকে চালু; আপনার কোড একটির বদলে তালিকা ধরে চলবে। চার, Anthropic-এর নথি tool-এর ফলকে অবিশ্বস্ত লেখা হিসেবে দেখতে বলে, কারণ ওয়েবপাতা বা ইমেইলের ভেতরে নির্দেশ লুকিয়ে থাকতে পারে (indirect prompt injection, পর্ব ৬৪)। নিচে অনুরোধের আকার, নথির কাঠামো অনুসরণ করে লেখা; চালানো হয়নি, কারণ এখানে কোনো API key নেই।

# নমুনা (চালানো হয়নি): দুই ধরনের প্রথম পালা, model-এর নাম নিজে বসান
# Claude Messages API: model-এর উত্তরে tool_use block আসে
{"model": "…", "max_tokens": 512, "tools": [{"name": "lookup_order",
  "description": "…", "input_schema": {"type": "object",
  "properties": {"order_id": {"type": "string"}}, "required": ["order_id"]}}],
 "messages": [{"role": "user", "content": "BG-10231 কোথায়?"}]}
# পরের অনুরোধে ফল ফেরত (user বার্তা)
{"role": "user", "content": [{"type": "tool_result",
  "tool_use_id": "toolu_…", "content": "{\"status\": \"পথে আছে\"}"}]}

# Chat Completions ধাঁচ (DeepSeek, Kimi): ফল একটি tool বার্তা
{"role": "tool", "tool_call_id": "call_…", "content": "{\"status\": \"পথে আছে\"}"}

MCP — tool যুক্ত করার একটি খোলা protocol

ওপরের সারণিতে প্রতিটি API-র নিজের আকার। ধরুন বাজারঘর তার অর্ডার-সিস্টেম পাঁচটি আলাদা AI অ্যাপে যুক্ত করতে চায়; প্রতিটির জন্য আলাদা সংযোগ লিখতে হবে। MCP (Model Context Protocol) এই সমস্যার একটি উত্তর। এর অফিসিয়াল সাইট (modelcontextprotocol.io, লেখার সময়ে পড়া) নিজেকে AI অ্যাপকে বাইরের সিস্টেমে যুক্ত করার একটি open-source মান বলে, আর তুলনা দেয় USB-C পোর্টের সঙ্গে। Anthropic ২০২৪ সালের নভেম্বরে এটি প্রকাশ করে; এখন সাইটের তালিকায় Claude, ChatGPT, VS Code, Cursor সহ বহু client-এর সমর্থনের কথা আছে, আর সারণি দেখায় চারটি API-তে remote MCP server যুক্ত করার ঘর আছে।

সাইটের architecture পাতা অনুযায়ী মূল ধারণা: host হলো AI অ্যাপ, যে প্রতিটি server-এর জন্য একটি client বানায়। Server তিন ধরনের জিনিস দেয়: tools (চালানো যায় এমন function), resources (পড়ার তথ্য) আর prompts (ছাঁচ)। বার্তা JSON-RPC 2.0-এ; client tools/list দিয়ে tool-এর তালিকা নেয় (প্রতিটিতে name, description, inputSchema), আর tools/call দিয়ে চালায়। পরিবহন দুই রকম: একই যন্ত্রে stdio, দূরে Streamable HTTP. লেখার সময়ের সংস্করণ 2026-07-28. খেয়াল করুন, MCP ঠিক করে কীভাবে tool পাওয়া আর ডাকা যায়; model কোন tool ডাকবে, argument ঠিক কি না, কাজটি নিরাপদ কি না, সেগুলো তখনো host-এর দায়িত্ব। OpenAI-এর MCP নির্দেশিকাও ডেটা বদলানোর মতো tool-এ অনুমতি চালু রাখতে বলে।

৫ · Registry, dispatcher আর argument যাচাই

Model-এর লেখা tool-ডাককে ওয়েবসাইটের form থেকে আসা ডেটার মতো দেখুন: বাইরের ইনপুট, আগে পরীক্ষা (ফুল-স্ট্যাক ওয়েব ফ্রেমওয়ার্ক কোর্সের পর্ব ২৭)। দুটি অংশ লাগে। Registry: অনুমোদিত নামের তালিকা, প্রতিটির function আর argument-এর নিয়ম। Dispatcher: যে কোড ডাকটি parse করে, registry-তে খোঁজে, নিয়ম মেলায়, তারপর চালায় বা স্পষ্ট error ফেরত দেয়। Model যে নামই লিখুক, registry-র বাইরে কিছু চলে না।

নিচের কোডে dispatcher নিজে লেখা, যাতে প্রতিটি নিয়ম চোখে পড়ে; আসল কাজে schema-র জন্য jsonschema বা Pydantic নিন (পর্ব ৬২)। ইনপুট হলো Qwen2.5-0.5B-Instruct-এর সত্যিকারের সাতটি output, §৮-এর run থেকে বেছে তোলা, হুবহু; পাতার ভেতরে ফাইল হিসেবে রাখা।

import json, re, math
ORDERS = {"BG-10231": "পথে আছে", "BG-10312": "প্যাক হচ্ছে", "BG-10588": "বাতিল"}  # sandbox-এর নকল ডেটা
DIST = ["ঢাকা", "চট্টগ্রাম", "রাজশাহী", "খুলনা", "সিলেট", "বরিশাল", "রংপুর", "ময়মনসিংহ", "কুমিল্লা", "গাজীপুর"]
def charge(district, weight_kg):                      # সাহায্য-কেন্দ্রের নিয়ম
    return {"ঢাকা": 60, "গাজীপুর": 90}.get(district, 120 + 20 * max(0, math.ceil(weight_kg - 1)))
REG = {  # registry: নাম → (function, argument-এর নিয়ম)
    "lookup_order": (lambda order_id: ORDERS[order_id], {"order_id": ("pat", r"BG-[0-9]{5}")}),
    "delivery_charge": (charge, {"district": ("enum", DIST), "weight_kg": ("num", (0, 20))})}

def dispatch(raw):
    m = re.search(r"<tool_call>\s*(.*?)\s*</tool_call>", raw, re.S)
    if not m: return "tool-ডাক নেই → সরাসরি উত্তর"
    try:
        call = json.loads(m.group(1))
    except json.JSONDecodeError as e:
        return f"✘ JSON নয়: {e.msg}"
    name, args = call.get("name"), call.get("arguments")
    if name not in REG: return f"✘ অজানা tool '{name}'"
    fn, rules = REG[name]
    if not isinstance(args, dict): return "✘ arguments object নয়"
    bad = [f"'{k}' নেই" for k in rules if k not in args] + [f"বাড়তি '{k}'" for k in args if k not in rules]
    for k, (kind, r) in rules.items():
        v = args.get(k)
        if k not in args: continue
        if kind == "pat" and not (isinstance(v, str) and re.fullmatch(r, v)): bad.append(f"{k} ধাঁচে মেলে না")
        if kind == "enum" and v not in r: bad.append(f"{k}={v!r} তালিকায় নেই")
        if kind == "num" and (type(v) not in (int, float) or not r[0] < v <= r[1]): bad.append(f"{k} সীমার বাইরে")
    if bad: return "✘ " + "; ".join(bad)
    if name == "lookup_order" and args["order_id"] not in ORDERS:   # ব্যবসার নিয়ম
        return f"✘ অর্ডার {args['order_id']} পাওয়া যায়নি"
    return f"✔ চলল: {name}({', '.join(map(repr, args.values()))}) → {fn(**args)}"

for o in json.load(open("outs.json", encoding="utf-8")):
    print(f"[{o['id']}] {o['q']}\n     {dispatch(o['out'])}")

[o1] আমার অর্ডার BG-10231 এখন কোথায়?
     ✔ চলল: lookup_order('BG-10231') → পথে আছে
[c2] Sylhet e 3.5 kg parcel er delivery charge koto?
     ✘ district='Sylhet' তালিকায় নেই
[c3] ঢাকার ভেতরে আধা কেজির প্যাকেটে ডেলিভারি চার্জ কত?
     ✔ চলল: delivery_charge('ঢাকা', 4) → 60
[p1] পণ্য ফেরত দেওয়ার নিয়ম কী?
     ✘ 'weight_kg' নেই
[m4] customer of BG-10588 ke janan je order cancel hoyeche
     ✘ অজানা tool 'cancel_order'
[n5] ডেলিভারি চার্জ কত?
     ✘ অর্ডার BG-47865 পাওয়া যায়নি
[n2] হ্যালো
     tool-ডাক নেই → সরাসরি উত্তর

এবার [c2]-এর যাচাই ধাপে ধাপে, আর error-এর পরে model কী করল।

৬ · Error ফেরত, retry আর parallel ডাক

যাচাই ব্যর্থ হলে তিনটি পথ, পর্ব ৬২-এর repair-retry-র মতোই: নিজে মেরামত (alias, বাংলা অঙ্ক), ভুলের বার্তা model-কে ফেরত দিয়ে আবার সুযোগ, আর সীমা পার হলে মানুষ বা “জানি না”. নথিগুলোও দ্বিতীয় পথ বলে: Anthropic-এর নথি ভুলের ফলে is_error: true দিতে আর বার্তায় কী ভুল ও এরপর কী করতে হবে তা লিখতে বলে; সে নথি অনুযায়ী Claude দরকারি argument না পেলে ২–৩ বার ঠিক করে আবার চেষ্টা করে। ছোট open model-এ কী হয়, আমরা মেপেছি।

একই ০.৫B model, পুরো বর্ণনাসহ tool, ৪০টি প্রশ্ন, loop-এ সর্বোচ্চ ৪টি model ডাক (সত্যিকারের run): মোট ৭৮টি ডাক, কোনো প্রশ্ন সীমায় পৌঁছায়নি। ৮টি প্রশ্নে প্রথম ডাকই অবৈধ ছিল, আর ভুলের বার্তা পাওয়ার পর ৮টির একটিতেও model সংশোধিত বৈধ ডাক লেখেনি। ৩টিতে ইংরেজিতে প্রশ্ন ফিরিয়ে দিয়েছে (“correct district name”, “correct tool name”), বাকিগুলোতে অসংলগ্ন বাংলা; দুটিতে লেখা ২৫৬ token-এর সীমা ছুঁয়েছে, প্রতিটি প্রায় ২১ সেকেন্ড। একটিতে (লালাচার নামের অচেনা জেলা) model ভারতের রাজ্যের নামে বানানো চার্জের লম্বা তালিকা লিখেছে; পাতায় তা দেখানো হলো না। শিক্ষা: এই আকারের model-এ ভুলের বার্তা ফেরত দেওয়া প্রায় শুধু খরচ, তাই retry-এর সীমা ছোট রাখুন আর কোডের মেরামত আগে চালান। বড় model-এর আচরণ আলাদা হতে পারে; §৮-এ ১.৫B-এর ফল।

Parallel ডাক-ও এই run-এ এসেছে: “BG-10231 আর BG-10457 দুটো অর্ডারের অবস্থা জানান” প্রশ্নে model এক পালায় দুটি <tool_call> লিখেছে। নিচের কোড loop-টি সত্যিকারের output দিয়ে আবার চালায়, যাতে বার্তার তালিকা কীভাবে বাড়ে আর ডাকের id কীভাবে মেলে, তা দেখা যায়।

import json, re
ORDERS = {"BG-10231": {"status": "পথে আছে"}, "BG-10457": {"status": "ডেলিভারি হয়েছে"}}
DIST = ["ঢাকা", "চট্টগ্রাম", "রাজশাহী", "খুলনা", "সিলেট"]          # তালিকা ছোট করা
def run_tool(name, args):                                        # sandbox
    if name == "lookup_order":
        return ORDERS.get(args.get("order_id"), {"error": "order not found"})
    if name == "delivery_charge" and args.get("district") not in DIST:
        return {"error": f"district {args.get('district')!r} not allowed. Fix it or ask the user."}
    return {"error": f"unknown tool {name!r}"}

def loop(question, model_turns, max_calls=4):
    msgs = [{"role": "user", "content": question}]
    for n, out in enumerate(model_turns[:max_calls], 1):          # model-এর সত্যিকারের লেখা
        msgs.append({"role": "assistant", "content": out})
        calls = [json.loads(b) for b in re.findall(r"<tool_call>\s*(.*?)\s*</tool_call>", out, re.S)]
        if not calls:
            return msgs, n                                        # ডাক নেই: শেষ উত্তর
        for k, c in enumerate(calls):
            cid = f"call_{n}_{k}"        # Qwen id দেয় না; কোড বানায়, ফল মেলানোর জন্য
            msgs.append({"role": "tool", "id": cid, "content": run_tool(c["name"], c["arguments"])})
    return msgs, max_calls

for t in json.load(open("loops.json", encoding="utf-8")):
    msgs, n = loop(t["q"], t["turns"])
    print(f"== {t['q']}  (model ডাক {n}টি, বার্তা {len(msgs)}টি)")
    for m in msgs[1:]:
        c = m["content"]
        if m["role"] == "tool":
            c = json.dumps(c, ensure_ascii=False)
        elif "<tool_call>" in c:                                   # ডাকগুলো ছোট করে দেখানো
            c = " + ".join(f"{d['name']}({', '.join(map(repr, d['arguments'].values()))})" for d in
                           map(json.loads, re.findall(r"<tool_call>\s*(.*?)\s*</tool_call>", c, re.S)))
        print(f"  {m['role']:9} {m.get('id', ''):8} {re.sub(r'\s+', ' ', c)}")

== BG-10231 আর BG-10457 দুটো অর্ডারের অবস্থা জানান।  (model ডাক 2টি, বার্তা 5টি)
  assistant          lookup_order('BG-10231') + lookup_order('BG-10457')
  tool      call_1_0 {"status": "পথে আছে"}
  tool      call_1_1 {"status": "ডেলিভারি হয়েছে"}
  assistant          1. BG-10231 এর পথে আছে। ধরণ গুরুত্বপূর্ণ হয়েছে। দৃষ্টি 2 দিন হবে। তাই ফাইল চালান। 2. BG-10457 এর পথে আছে এবং ধরণ গুরুত্বপূর্ণ হয়েছে। দৃষ্টি খুব ছিল। তাই ফাইল চালান।
== Sylhet e 3.5 kg parcel er delivery charge koto?  (model ডাক 2টি, বার্তা 4টি)
  assistant          delivery_charge('Sylhet', 3.5)
  tool      call_1_0 {"error": "district 'Sylhet' not allowed. Fix it or ask the user."}
  assistant          I'm sorry, but I can't proceed without the correct district name. Could you please provide me with the correct district name so that I can compute the delivery charge?

৭ · কখন tool ডাকবেন না

সহকারীর কাছে আসা সব প্রশ্নে tool লাগে না। তিন ধরনের প্রশ্নে না ডাকাই ঠিক: (১) গল্পগুজব বা ধন্যবাদ, (২) tool-এর বাইরের কাজ (কবিতা, সাধারণ জ্ঞান, হিসাব), আর (৩) দরকারি তথ্য নেই, যেমন অর্ডার নম্বর ছাড়া “আমার অর্ডার কোথায়?”. তৃতীয়টি সবচেয়ে বিপজ্জনক: model একটি নম্বর বানিয়ে ডাকলে, আর নম্বরটি অন্য কারও অর্ডারের হলে, একজনের তথ্য আরেকজনের কাছে যায়। API-গুলো tool_choice দিয়ে এই আচরণ কিছুটা নিয়ন্ত্রণ দেয় (§৪): none হলে কোনো ডাক নয়, required বা any হলে ডাক বাধ্যতামূলক, আর auto-তে সিদ্ধান্ত model-এর।

৮ · সত্যিকারের run — ৪০টি প্রশ্নে tool বাছাই আর argument

এবার মাপা। ৪০টি হাতে লেখা কাল্পনিক প্রশ্ন, বাংলা, Banglish আর ইংরেজিতে: ৮টি অর্ডার দেখা, ৮টি ডেলিভারি চার্জ, ৮টি নীতি, ৪টি বার্তা পাঠানো, ৪টি একাধিক ডাকের, আর ৮টি যেখানে tool লাগে না (তার দুটিতে দরকারি তথ্যই নেই)। প্রতিটির সঠিক ডাক আগে থেকে লেখা। দুটি মাপ: tool-selection accuracy (ঠিক tool বা tool-এর ঠিক সেট, আর না-লাগলে কোনো ডাক নয়) আর argument accuracy (tool লাগে এমন ৩২টিতে tool আর argument দুটোই ঠিক)। দুটি model, আর দুই রকম tool-তালিকা: পুরো বর্ণনাসহ, আর শুধু schema (নাম আর schema একই, বর্ণনা ফাঁকা; তাই যাচাই একই থাকে)। Greedy decoding, সর্বোচ্চ ২৫৬টি নতুন token; ০.৫B CPU-তে, ১.৫B GPU-তে ; মাপা সর্বোচ্চ GPU memory বরাদ্দ ছিল ৩.০২ GB.

~/bazarghar-dl$ uv run python analyze.py q05.jsonl q15.jsonl
# সত্যিকারের run-এর আউটপুট, কলামগুলো ছোট করে সাজানো
model desc   select [95% CI]   args(32) [95% CI]  no-call  invalid  prompt  s/req
0.5B  full   0.57 [0.42,0.72]  0.50 [0.34,0.69]   2/8      8/40     1037    4.59
0.5B  terse  0.53 [0.38,0.68]  0.44 [0.25,0.59]   4/8      8/32      700    5.42
1.5B  full   0.68 [0.53,0.82]  0.59 [0.41,0.75]   8/8      1/33     1037    2.13
1.5B  terse  0.65 [0.50,0.80]  0.53 [0.34,0.69]   6/8      3/37      700    1.85

invalid মানে মোট ডাকের কতগুলো dispatcher-এ আটকেছে; prompt গড় input token. এখন প্রতিটি প্রশ্নের ফল (একটি সংখ্যা: tool লাগলে tool আর argument দুটোই ঠিক, না লাগলে কোনো ডাক নয়) পাতায় রেখে CI আর জোড়া তুলনা নিজে করুন ; পদ্ধতিটি পর্ব ৫৮-এর bootstrap. প্রথম চালানোয় NumPy আসতে কয়েক সেকেন্ড লাগে।

import numpy as np
# সত্যিকারের run: ৪০টি প্রশ্নের প্রতিটি ঠিক (1) না ভুল (0); tool লাগলে ঠিক tool আর ঠিক argument,
# না লাগলে কোনো ডাক নয়। ক্রম: o×8 অর্ডার, c×8 চার্জ, p×8 নীতি, m×4 বার্তা, x×4 একাধিক, n×8 tool নয়
RUNS = {"0.5B পূর্ণ বর্ণনা": "1111101110001000010101010100100111000000",
        "0.5B শুধু schema":  "1111111111000000001000000100100111010001",
        "1.5B পূর্ণ বর্ণনা": "0110111111111101000000010110110111111111",
        "1.5B শুধু schema":  "1111110111001101000000000110110111111001"}
CAT = np.array(list("o" * 8 + "c" * 8 + "p" * 8 + "m" * 4 + "x" * 4 + "n" * 8))
X = {k: np.array([int(c) for c in v]) for k, v in RUNS.items()}
idx = np.random.default_rng(71).integers(0, 40, size=(10000, 40))  # একই resample সব শর্তে

def ci(x):
    b = x[idx].mean(axis=1)
    return x.mean(), *np.percentile(b, [2.5, 97.5])

print("শর্ত               ঠিক     95% CI           o  c  p  m  x  n")
for k, x in X.items():
    m, lo, hi = ci(x)
    per = " ".join(f"{x[CAT == c].sum()}" for c in "ocpmxn")
    print(f"{k:17} {m:5.3f}  [{lo:.3f}, {hi:.3f}]   {per}")
print("জোড়া পার্থক্য (একই ৪০টি প্রশ্ন):")
for a, b in [("0.5B পূর্ণ বর্ণনা", "0.5B শুধু schema"), ("1.5B পূর্ণ বর্ণনা", "1.5B শুধু schema"),
             ("1.5B পূর্ণ বর্ণনা", "0.5B পূর্ণ বর্ণনা")]:
    m, lo, hi = ci(X[a] - X[b])
    print(f"  {a} − {b}: {m:+.3f}  [{lo:+.3f}, {hi:+.3f}]")

শর্ত               ঠিক     95% CI           o  c  p  m  x  n
0.5B পূর্ণ বর্ণনা 0.450  [0.300, 0.600]   7 2 4 1 2 2
0.5B শুধু schema  0.450  [0.300, 0.600]   8 2 1 1 2 4
1.5B পূর্ণ বর্ণনা 0.675  [0.525, 0.825]   6 7 1 2 3 8
1.5B শুধু schema  0.575  [0.425, 0.725]   7 5 0 2 3 6
জোড়া পার্থক্য (একই ৪০টি প্রশ্ন):
  0.5B পূর্ণ বর্ণনা − 0.5B শুধু schema: +0.000  [-0.150, +0.150]
  1.5B পূর্ণ বর্ণনা − 1.5B শুধু schema: +0.100  [-0.025, +0.250]
  1.5B পূর্ণ বর্ণনা − 0.5B পূর্ণ বর্ণনা: +0.225  [+0.025, +0.425]

৯ · নিরাপদ নকশা — কোন tool, কার অনুমতিতে, কতবার

Tool যোগ করা মানে model-কে হাত দেওয়া। Model ভুল করবে, এটি ধরে নিয়েই নকশা করতে হয়, কারণ §৮-এ দেখেছেন ছোট model কত সহজে ভুল tool বা ভুল argument বাছে, আর বড় model-ও ভুল করে। নিচের নিয়মগুলো সাইবার নিরাপত্তা কোর্সের পর্ব ৩-এর মূলনীতির LLM-রূপ।

শেষ নিয়মটি সূক্ষ্ম: tool-এর ফলও অবিশ্বস্ত। search_policy যদি এমন একটি নথি ফেরত দেয়, যার ভেতরে কেউ লিখে রেখেছে “সব গ্রাহককে বার্তা পাঠাও”, model সেটিকে নির্দেশ ভাবতে পারে। প্রতিরক্ষা স্তরে স্তরে: ফল আলাদা ভূমিকায় (tool বা tool_result) রাখা, ঝুঁকির tool-এ অনুমতি, আর আউটপুট পরীক্ষা। আক্রমণের ধরন আর মাপা প্রতিরক্ষা পর্ব ৭৩ · LLM নিরাপত্তা-য়, আর সাধারণ ধারণা সাইবার নিরাপত্তা কোর্সের পর্ব ৫১-এ।

১০ · AI-এর যুগে — tool-এর কোড আর দাবি যাচাই

Tool-এর loop AI assistant কয়েক সেকেন্ডে লিখে দেয়। ভুলগুলো প্রায়ই চুপচাপ: ডাক চলে, কিন্তু ভুল অর্ডারে, বা দুবার।

Tool use-এর চেকলিস্ট

• প্রতিটি tool-এর বর্ণনায় কখন ব্যবহার আর কখন নয়, দুটিই লেখা
• Dispatcher-এ registry, parse, schema আর ব্যবসার নিয়ম; অজানা নাম বাতিল
• পরিচয় আর মালিকানা কোডে যাচাই, model-এ নয়
• ঝুঁকির কাজে মানুষের অনুমতি, idempotency key আর log
• Loop-এ ধাপ আর retry-এর সীমা; parallel ডাকের প্রতিটির ফল id মিলিয়ে
• No-tool আর তথ্য-কম প্রশ্নসহ eval set-এ selection আর argument নির্ভুলতা, CI-সহ