Needle Cactus Compute: ایک چھوٹا AI Function Calling ماڈل

LinkedIn پر ایک 26-million-parameter اوپن سورس ماڈل کے بارے میں ایک پوسٹ گردش کر رہی ہے: Needle، Cactus Compute کی طرف سے، جو Gemini سے distill کیا گیا ہے تاکہ فونز اور wearables پر function calling کی جا سکے۔ یہ واقعی ایک دلچسپ پروجیکٹ ہے — لیکن repository پہلے ہی اس ورژن سے آگے بڑھ چکی ہے۔ Cactus نے گزشتہ چند دنوں میں Needle 2 جاری کر دیا: 45 million parameters، ایک واحد 14MB binary میں compressed، ایک نئی architecture recipe پر بنایا گیا جسے وہ Simple Attention Network کہتے ہیں۔ بنیادی خیال برقرار ہے اور مزید واضح ہو جاتا ہے: یہ کوئی چھوٹا chatbot نہیں، بلکہ ایک بنیادی طور پر مختلف قسم کا ماڈل ہے، ایسا جو ساختی طور پر آزاد انداز کی لمبی text جواب پیدا ہی نہیں کر سکتا، چاہے آپ چاہیں بھی۔

اس قسم کے ماڈل کی کوریج میں عام غلطی یہ ہے کہ اسے “GPT مگر چھوٹا” سمجھ لیا جاتا ہے۔ یہ ایسا نہیں ہے، اور یہی فرق اصل میں دلچسپ engineering فیصلے ہیں: ماڈل جو بھی token خارج کرتا ہے وہ آپ کے اپنے function schemas سے compile کی گئی grammar کے ذریعے constrained ہوتا ہے، ہر response کے ساتھ ایک calibrated confidence score ہوتا ہے جس پر آپ programmatically عمل کر سکتے ہیں، اور کوئی غیر متعلق سوال فرضی جواب نہیں لیتا — اسے ایک واضح، structured refusal ملتی ہے۔ یہ پوسٹ بتاتی ہے کہ یہ سب کیسے بنایا جاتا ہے، اور اس کے اوپر حقیقت میں build کرنا کیسا دکھتا ہے۔

آپ یہ سیکھیں گے:

• کیوں tool calling ایک بنیادی طور پر open-ended generation سے مختلف مسئلہ ہے، اور کیوں اسی وجہ سے ماڈل اتنا چھوٹا ہو سکتا ہے
• Needle 2 کی Simple Attention Network architecture ایک standard transformer سے کیسے مختلف ہے
• byte-level grammar-constrained decoding کس طرح valid structured output کی ضمانت دیتی ہے، صرف امید نہیں باندھتی
• confidence gating اور tool retrieval کیسے کام کرتے ہیں، اور production reliability کے لیے یہ کیوں اہم ہیں
• LoRA کے ساتھ Needle کو اپنے tools پر کیسے fine-tune کریں، اور نتیجے کو اسی lightweight engine پر کیسے deploy کریں
• اس قدر specialized ماڈل کی حقیقی حدود کیا ہیں، اور ایک general-purpose LLM کے مقابلے میں یہ کہاں fit ہوتا ہے

فہرستِ مضامین

1. بنیادیات
2. مکمل Architecture
3. بنیادی Layers کی وضاحت
4. ابتدا سے انتہا تک Walkthrough
5. خاص صورتیں
6. Scaling اور Production چیلنجز
7. Code مثالیں
8. عام غلطیاں
9. Production کی بہترین عملی ترکیبیں

بنیادیات

Needle دراصل کیا کور کرتا ہے

Needle صرف ایک مسئلہ حل کرتا ہے: ایک query اور declared tools کے ایک مجموعے کو دیکھتے ہوئے یہ طے کرنا کہ کون سا tool call کرنا ہے اور اس میں کون سے arguments بھرنے ہیں — یا اگر کچھ بھی لاگو نہ ہو تو واضح طور پر انکار کرنا ہے۔ کسی action کو انجام دینا اور text سے structured data نکالنا اندرونی سطح پر ایک ہی عمل نکلتے ہیں؛ فرق صرف اتنا ہے کہ آپ “tool” کے طور پر کیا declare کرتے ہیں۔ یہ جان بوجھ کر ایک محدود دائرہ ہے، اور یہی محدودیت پوری بات کا مرکز ہے۔ Tool calling بنیادی طور پر retrieval-and-assembly کام ہے — query کو tool name سے match کریں، input سے argument values نکالیں، valid JSON emit کریں — نہ کہ open-ended reasoning۔ خاص طور پر اسی کام کے لیے بنایا گیا ماڈل chatbot جیسی وسیع عمومی معلوماتی صلاحیت نہیں مانگتا، اور یہی وجہ ہے کہ 45 million parameters، جو 14MB binary میں compressed ہیں، اسی مخصوص کام میں اپنے سے کئی گنا بڑے ماڈلز کے مقابلے میں مؤثر ثابت ہو سکتے ہیں۔

یہ مسئلہ اچھی طرح حل کرنا کیوں بہت قیمتی ہے

• On-device AI کے سامنے ایسی حقیقی پابندیاں ہوتی ہیں جنہیں cloud model کو کبھی پورا نہیں کرنا پڑتا۔ RAM جو صرف چند درجن megabytes میں ناپی جاتی ہے، network connection کی کوئی ضمانت نہیں، اور battery budgets جو watch یا glasses پر 1B+ parameter ماڈل کو عملی طور پر ناممکن بنا دیتی ہیں۔
• Latency-sensitive features کو سرے سے cloud LLM تک جانا ہی نہیں چاہیے۔ “turn off the lights” کے لیے hosted model تک round trip نہ صرف سست ہے بلکہ کم private بھی، اس کے مقابلے میں وہ ماڈل بہتر ہے جو پہلے ہی client پر موجود ہو اور فوراً جواب دے۔
• اس کام میں ساختی guarantees خام capability سے زیادہ اہم ہیں۔ ایک tool-calling system جو کبھی کبھار malformed JSON دے دے یا کوئی parameter hallucinate کر دے، وہ صرف inconvenient نہیں — وہ ایک broken integration ہے۔ Needle کا پورا design اسی قسم کی failure کو صرف statistically rare بنانے کے بجائے ساختی طور پر ناممکن بنانے کے گرد بنایا گیا ہے۔

مکمل Architecture

Tool schemas ──▶ Grammar compiler (byte-level)
                         │
Query + schemas ──▶ Simple Attention Network ──▶ constrained decode ──▶ structured call
                                                                              │
                                                                       execute locally
                                                                              │
                                                                    result fed back in
                                                                              │
                                                                        next turn / final answer

رہنما اصول یہ ہے: ماڈل کے پاس آزادی کے صرف وہی درجات ہیں جن کی grammar اجازت دیتی ہے۔ درستی کو تعمیر کے ذریعے نافذ کیا جاتا ہے — آپ کے declared schemas سے compile کی گئی byte-level grammar decoding کے دوران ہر token کو constrain کرتی ہے — نہ کہ اس امید پر کہ کہیں بہت بڑا اور بہت سست ماڈل مناسب برتاؤ کر لے۔

بنیادی Layers کی وضاحت

1. Simple Attention Network Architecture

یہ کیا ہے: Needle 2 کی dense small-model recipe، جیسا کہ Cactus کے اپنے paper (arXiv:2607.18363) میں بیان کیا گیا ہے۔ ایک standard feed-forward block کے بجائے، یہ Hadamard-transform-based MLP، grouped-query attention، hashed n-gram tables سے بنی ہوئی “engram” key-value memory، اور کئی residual streams کو جوڑنے والی multi-lane hyper-connections استعمال کرتا ہے۔ اجزاء کے درمیان routing کو سادہ softmax کے بجائے Sinkhorn iteration کے ذریعے normalize کیا جاتا ہے۔

یہ کیوں اہم ہے: ان تمام انتخابوں میں سے ہر ایک standard transformer کی اس “general capability” کا کچھ حصہ efficiency کے بدلے قربان کرتا ہے جس پر عام طور پر parameters خرچ ہوتے ہیں، مگر یہاں یہ efficiency خاص طور پر اسی task کے لیے ہے۔ اصل 26M Needle تو اس سے بھی آگے گیا تھا، pure attention اور gating استعمال کرتے ہوئے، بغیر کسی feed-forward layers کے — یہ شرط لگاتے ہوئے کہ tool calling کو اُس قسم کے associative “knowledge storage” کی ضرورت نہیں جو ایک FFN عموماً فراہم کرتا ہے۔ Needle 2 ایک lightweight MLP دوبارہ شامل کرتا ہے، مگر جان بوجھ کر ایک سستا variant جو dense matrix کے بجائے fixed، weight-free Hadamard transform پر مبنی ہے۔

Production tip: یہ توقع نہ رکھیں کہ یہ architecture open-ended chat quality پر generalize کرے گی — اسے خاص طور پر tool calling کی retrieval-and-assembly ساخت کے لیے optimize کیا گیا ہے، اور یہی specialization اسے اتنا چھوٹا بناتی ہے کہ یہ 28MB RAM میں چل سکے۔

2. Byte-Level Grammar-Constrained Decoding

یہ کیا ہے: آپ جو بھی tool schema declare کرتے ہیں، وہ ایک ایسی grammar میں compile ہو جاتا ہے جو ہر decoding step پر یہ constrain کرتی ہے کہ ماڈل کو کون سے tokens emit کرنے کی اجازت ہے۔ ماڈل malformed JSON، کسی unrecognized tool name، یا ایسی value پیدا ہی نہیں کر سکتا جو declared constraint کی خلاف ورزی کرے — اس لیے نہیں کہ اسے ایسا نہ کرنے کی training دی گئی ہے، بلکہ اس لیے کہ invalid tokens decoding کے دوران دستیاب ہی نہیں ہوتے۔

یہ کیوں اہم ہے: اس سے “ماڈل کو valid JSON واپس کرنا چاہیے” ایک احتمالی امید سے بدل کر ایک ضمانت بن جاتی ہے۔ Value ranges، regex patterns، string lengths، اور enums جیسی constraints — یعنی schema میں بیان کی جا سکنے والی ہر چیز — براہ راست grammar میں compile ہو جاتی ہیں، لہٰذا آپ کی declared حدود سے باہر کوئی argument لفظی طور پر generate ہی نہیں ہو سکتا۔

Production tip: جہاں ممکن ہو validation کو application code میں بعد ازاں check کرنے کے بجائے schema کے اندر لے آئیں۔ ایک Literal["heat", "cool", "auto"] یا پہلے سے declare کی گئی numeric range کا مطلب یہ ہے کہ ماڈل ابتدا ہی سے invalid value emit نہیں کر سکتا — بعد میں پکڑنے کے لیے کچھ بچتا ہی نہیں۔

3. Confidence Gating

یہ کیا ہے: ہر response کے ساتھ ایک confidence score آتا ہے جو دو آزاد signals میں سے کم از کم پر مبنی ہوتا ہے: ایک calibrated head جو full prompt کے ساتھ produced call کو score کرتا ہے، اور call tokens کی raw decoding probability۔ اعلیٰ score کے لیے دونوں کا متفق ہونا ضروری ہے۔

یہ کیوں اہم ہے: یہ آپ کو ایک واحد، اصولی عدد فراہم کرتا ہے جس کے گرد آپ ایک حقیقی escalation policy بنا سکتے ہیں: اپنی منتخب threshold سے اوپر locally عمل کریں، اور اس سے نیچے دوبارہ پوچھیں یا کسی بڑے cloud model کی طرف route کر دیں۔ اس design کا مطلوبہ failure mode خاموش غلط execution نہیں بلکہ escalation ہے۔

Production tip: Threshold کو global طور پر نہیں بلکہ ہر use case کے مطابق tune کریں — ایک smart-home toggle کم معیار برداشت کر سکتا ہے، جبکہ payment یا message send جیسی چیز میں خاموشی سے execute ہونے والی غلط low-confidence call دوبارہ پوچھنے کے مقابلے میں کہیں زیادہ خراب نتیجہ ہے۔

4. بڑے Catalogs کے لیے Tool Retrieval

یہ کیا ہے: اگر declared tools پانچ یا اس سے کم ہوں تو سب کچھ براہ راست context میں render ہو جاتا ہے۔ اس کے بعد، ایک built-in retrieval head ہر tool schema کو ایک بار embed کرتا ہے، ہر turn پر query کو embed کرتا ہے، اور دائرہ کار کو سب سے زیادہ score لینے والے پانچ tools تک محدود کر دیتا ہے — جبکہ decoding grammar صرف اسی subset پر دوبارہ بنائی جاتی ہے۔

یہ کیوں اہم ہے: کوئی non-selected tool صرف unlikely نہیں رہتا کہ call ہو — وہ اس turn کے لیے حقیقتاً ناقابلِ رسائی ہو جاتا ہے، کیونکہ grammar خود صرف retrieved subset کی اجازت دیتی ہے۔ یہی وہ چیز ہے جو کسی device کو ایک بڑا tool catalogue declare کرنے دیتی ہے بغیر context budget تباہ کیے یا ہر turn پر سب کچھ سوچنے کی کوشش میں decoding سست کیے۔

Production tip: Tool embeddings کو ہر session میں دوبارہ compute کرنے کے بجائے disk پر persist کریں۔ یہ schema set اور model کے fingerprint سے keyed ہوتے ہیں، اس لیے کوئی unchanged catalogue فوراً load ہو جاتا ہے اور صرف حقیقی schema تبدیلی ہی re-embedding مجبور کرتی ہے۔

5. Conversation Length سے بےنیاز محدود Memory

یہ کیا ہے: ایک 256-token sliding window جاری conversation کو handle کرتی ہے، جبکہ declared tools کو fixed key-value “sinks” کے طور پر اپنی جگہ pinned رکھا جاتا ہے تاکہ وہ context سے slide out نہ ہوں۔

یہ کیوں اہم ہے: Total memory use تقریباً 28MB کے قریب رہتی ہے چاہے conversation کتنی ہی لمبی کیوں نہ ہو — یہ کسی بھی wearable یا embedded device پر حقیقت میں deploy ہونے والی چیز کے لیے ایک سخت ضرورت ہے، جہاں usage کے ساتھ بےقابو بڑھتی ہوئی memory عملی نہیں رہتی۔

6. System Instructions نہیں، System Facts

یہ کیا ہے: ایک optional system turn environment state لے کر آتا ہے — date، locale، device type، battery level، اور اسی طرح کی recognized keys — مگر سختی سے facts کے طور پر جن سے ماڈل reasoning کر سکتا ہے، نہ کہ ایسی instructions کے طور پر جو اس کے behavior کو steer کریں۔

یہ کیوں اہم ہے: یہ ایک دانستہ security-adjacent design choice ہے۔ چونکہ ماڈل کو train کیا گیا ہے کہ اس field کو commands نہیں بلکہ data سمجھے، اس لیے وہاں رکھا گیا text ماڈل کے اصل behavior کو override یا redirect کرنے کا موقع نہیں پاتا — یوں prompt-injection طرز کی manipulation کی ایک پوری قسم بند ہو جاتی ہے، جسے زیادہ permissive “system prompt” design کھلا چھوڑ دیتی۔

Production tip: Relative time references (“tomorrow at 7”) صرف تب resolve ہوتی ہیں جب واقعی date: fact فراہم کی گئی ہو — اس کے بغیر ماڈل absolute time کا اندازہ لگانے کے بجائے اس فقرے کو جوں کا توں آگے بڑھا دیتا ہے، جو time-sensitive چیزوں کے لیے زیادہ محفوظ failure mode ہے۔

7. Weights-Agnostic Engine پر LoRA Fine-Tuning

یہ کیا ہے: Needle، frozen base model کے خلاف LoRA کے ساتھ fine-tune کرتا ہے، پھر adapter کو merge کر کے نتیجے کو ایک واحد .cact file میں quantize کرتا ہے — ایک self-contained artifact جو base model کے بالکل اسی inference engine پر چلتا ہے، کسی الگ build step کے بغیر۔

یہ کیوں اہم ہے: اس سے ماڈل کو اپنے tool catalogue کے مطابق specialized بنانا واقعی سستا ہو جاتا ہے، اور output deploy کرنے میں اصل جتنا ہی آسان رہتا ہے: ایک file، ایک engine، کوئی recompilation نہیں۔

Production tip: اگر ابھی آپ کے پاس labeled examples نہیں ہیں، تو toolchain OpenRouter-backed generation step کے ذریعے آپ کے tool schemas سے براہ راست training data synthesize کر سکتی ہے — یہ پہلا fine-tune شروع کرنے کا ایک مناسب طریقہ ہے، اس سے پہلے کہ آپ کے پاس سیکھنے کے لیے حقیقی usage logs موجود ہوں۔

ابتدا سے انتہا تک Walkthrough

ایک request کو query سے executed action تک trace کریں:

1. Tools declare کیے جاتے ہیں، یا تو decorated Python functions کے طور پر یا raw JSON schemas کے طور پر — مثال کے طور پر set_lights tool کی وضاحت کرتے ہوئے جس میں room، on، اور brightness parameters ہوں۔
2. Grammar compiler ان schemas سے constrained decoding grammar بناتا ہے جیسے ہی tools register ہوتے ہیں۔
3. ایک query آتی ہے: “dim the living room to 30.”
4. ماڈل query کو declared tools کے خلاف process کرتا ہے اور ایک call پیدا کرتا ہے، جہاں ہر token compiled grammar کے ذریعے constrained ہوتا ہے — اس کے لیے یہ ساختی طور پر ناممکن ہے کہ کسی undeclared tool کو call کرے یا malformed argument emit کرے۔
5. Response میں خود call، ایک مختصر natural-language reasoning trace، اور ایک confidence score شامل ہوتا ہے — جیسے set_lights(room="living room", on=true, brightness=30) اعلیٰ confidence کے ساتھ۔
6. Confidence configured threshold سے اوپر آ جاتی ہے، اس لیے call بغیر escalation کے locally execute ہو جاتی ہے۔
7. کسی multi-step task کے لیے — مثلاً، “message Alex that I’m running late” — ماڈل پہلے search_for_contact tool کو call کرتا ہے، نتیجہ (ایک contact ID) اگلے turn میں واپس feed کیا جاتا ہے، اور پھر ماڈل returned ID استعمال کرتے ہوئے send_instant_message کو call کرتا ہے، یوں calls کو chain کرتا ہے جیسا کہ ایک لمبا workflow چاہتا ہے۔
8. ایک آخری turn plain text میں جواب دے سکتی ہے جب تمام ضروری calls مکمل ہو جائیں، اور یہ ایک جداگانہ “respond” type کے طور پر واپس آتی ہے جس کے ساتھ مزید function calls منسلک نہیں ہوتیں۔

خاص صورتیں

Extraction، ایک tool کے ساتھ tool calling ہی ہے۔ ایک واحد schema declare کریں — جیسے invoice یا receipt کی record shape — اور query کی جگہ text پاس کریں تو parsed fields اسی schema کے arguments کے طور پر واپس آ جاتے ہیں۔ چونکہ صرف ایک tool declare کیا گیا ہے، grammar اسی نام کی صرف ایک call کی اجازت دیتی ہے، اس لیے schema conformance صرف ممکنہ نہیں بلکہ guaranteed ہوتی ہے۔

غیر متعلق queries کو structured refusal ملتی ہے، free-text جواب نہیں۔ اگر کوئی declared tool کسی request کو serve نہیں کر سکتا، تو ماڈل ایک empty call واپس کرتا ہے۔ Conversational text کی طرف کوئی fallback نہیں ہوتا — یہی declared scope سے باہر کسی بھی چیز کو handle کرنے کا پورا contract ہے، اور یہی embedded integration میں ماڈل کے behavior کو predictable رکھتا ہے۔

Optional arguments کو چھوڑ دیا جاتا ہے، اندازے سے نہیں بھرا جاتا۔ اگر input کسی optional field کے لیے ثبوت فراہم نہیں کرتا، تو اسے plausible-sounding guess سے بھرنے کے بجائے call سے مکمل طور پر خارج رکھا جاتا ہے — arguments پر بھی وہی نظم و ضبط لاگو ہوتا ہے جو پورے off-topic queries پر ہوتا ہے۔

Scaling اور Production چیلنجز

Fleet scale پر fine-tuning کو پھر بھی اسی tiny footprint میں fit ہونا ہوتا ہے۔ ایک LoRA adapter واپس ایک واحد quantized .cact file میں merge ہو جاتا ہے، جس کا مطلب ہے کہ ہر customer، ہر device class، یا ہر tool catalogue کے مطابق ماڈل کو specialize کرنا آپ کی deployment complexity کو کئی گنا نہیں بڑھاتا — ہر variant پھر بھی اسی identical lightweight engine پر چلتا ہے۔

Confidence threshold tuning ایک جاری operational فیصلہ ہے، ایک بار کی setting نہیں۔ جیسے جیسے آپ کا tool catalogue بڑھتا ہے یا usage patterns بدلتے ہیں، کسی خاص action کے لیے مناسب escalation threshold بھی بدل سکتی ہے — اسے monitor کرنے والی metric سمجھیں، نہ کہ ایک مستقل قدر جسے ایک بار set کر کے بھول جائیں۔

جیسے جیسے آپ کا tool catalogue بڑھتا ہے، retrieval quality زیادہ اہم ہو جاتی ہے۔ پانچ tools کے بعد، درستی اس بات پر منحصر ہوتی ہے کہ retrieval head ہر turn میں واقعی صحیح پانچ candidates سامنے لائے — ایسا catalogue جس میں بہت سے near-duplicate یا ناقص طور پر بیان کیے گئے tools ہوں، model کی raw capacity ختم ہونے سے بہت پہلے retrieval accuracy خراب کر دے گا۔

یہ ایک محدود specialist ہے، اور اسے general model کی طرح benchmark کرنا اصل نکتے کو کھو دینا ہے۔ Needle single-shot tool-call accuracy میں اپنے سے کئی گنا بڑے function-calling-focused models کے ساتھ جیت ہار کا تبادلہ کرتا ہے — مگر یہ موازنہ خاص طور پر tool calling کے بارے میں ہے، general reasoning یا conversation کے بارے میں نہیں، اور مضبوط function-calling benchmarks کو وسیع تر capability کے ثبوت کے طور پر لینا غلطی ہوگی۔

Code مثالیں

Decorator کے ساتھ ایک tool declare کرنا — سادہ cases میں صرف signature اور docstring ہی کافی ہیں:

import needle

@needle.tool
def get_weather(city: str):
    "Get the current weather for a city."
    return {"city": city, "temp_c": 27, "sky": "clear"}

agent = needle.Needle(tools=[get_weather])
print(agent.run("what's it like in Lagos right now?"))

حقیقی constraints شامل کرنا — ranges اور patterns جو براہ راست decode grammar میں compile ہوتے ہیں:

from typing import Annotated

@needle.tool
def send_money(
    amount: Annotated[float, needle.Field(gt=0, le=10000)],
    to: Annotated[str, needle.Field(pattern=r"^@[a-z0-9_]+$")],
):
    "Send money to a handle."
    return {"sent": amount, "to": to}

Typed result کے ساتھ structured extraction:

from pydantic import BaseModel

class Invoice(BaseModel):
    vendor: str
    total: float
    due_date: str

invoice = needle.extract("Invoice from Acme Corp, $1,200.00, due 2026-09-01", Invoice)

اپنے tools پر ابتدا سے انتہا تک fine-tuning:

needle generate-data --tools my_tools.json --num-samples 500 --output data.jsonl
needle finetune data.jsonl --epochs 3
needle build checkpoints/needle2.pkl --lora checkpoints/needle_lora.pkl --out my_needle.cact

عام غلطیاں

غلطی: Needle کو ایک چھوٹا chatbot سمجھنا۔ Design کے مطابق اس میں free-text fallback نہیں — tool calling یا extraction سے باہر کوئی بھی conversational use case اس کے لیے غلط انتخاب ہے۔ حل: open-ended conversation کو ایک general-purpose model کی طرف route کریں اور Needle کو structured actions تک محدود رکھیں۔

غلطی: retrieval کو ملحوظ رکھے بغیر ایک بڑا tool catalogue declare کرنا۔ پانچ tools کے بعد، ہر turn میں صرف top five retrieved candidates ہی قابلِ رسائی ہوتے ہیں۔ حل: واضح اور منفرد tool descriptions لکھیں تاکہ retrieval head واقعی ان کے درمیان فرق کر سکے۔

غلطی: confidence field کو نظر انداز کرنا۔ واپس آنے والی ہر call کو confidence check کیے بغیر قبول کر لینا، ماڈل کے اپنے اس اشارے کو ضائع کرنا ہے کہ وہ خود کتنا پُریقین ہے۔ حل: ہر action کے لیے ایک حقیقی threshold مقرر کریں اور اس سے نیچے کسی بھی چیز کے لیے escalation path بنائیں۔

غلطی: system facts field میں behavioral instructions رکھنا۔ ماڈل کو train کیا گیا ہے کہ اس field کو commands نہیں بلکہ data سمجھے، اس لیے وہاں رکھی گئی instructions اسے steer نہیں کریں گی۔ حل: behavior guidance کو tool descriptions اور schemas میں رکھیں، جہاں ماڈل واقعی اسے directive کے طور پر پڑھتا ہے۔

غلطی: ایک نہایت خاص tool ontology کے لیے fine-tuning چھوڑ دینا۔ Base model tool calling کے اندر general-purpose ہے؛ ایک محدود یا غیر معمولی catalogue باکس سے باہر اس کی سب سے مضبوط fit نہیں ہو سکتی۔ حل: اپنے schemas پر LoRA fine-tuning اتنی سستی ہے کہ accuracy کو capped مان لینے سے پہلے اسے کرنا فائدہ مند ہے۔

Production کی بہترین عملی ترکیبیں

• Constraints کو schema میں لے جائیں، بعد ازاں validation میں نہیں۔ Ranges، patterns، اور enums جو پہلے سے declare ہوں، generation کے دوران نافذ ہوتے ہیں، بعد میں پکڑے نہیں جاتے۔
• Confidence score کے گرد ایک حقیقی escalation path بنائیں۔ ہر action کے لیے طے کریں کہ “threshold سے نیچے” کا کیا مطلب ہوگا — retry، clarifying question، یا کسی بڑے model کو hand off۔
• Tool descriptions کو منفرد اور مخصوص رکھیں، خاص طور پر جب آپ بڑے catalogue کے لیے retrieval head پر انحصار کر رہے ہوں۔
• System facts field کو صرف data سمجھیں۔ Behavior steer کرنے کے لیے اس پر بھروسا نہ کریں — اسے اسی کے لیے train نہیں کیا گیا۔
• اگر آپ کا tool catalogue غیر معمولی ہے تو جلد fine-tune کریں۔ اپنے schemas پر ایک سستا LoRA pass، اس خطرے کے مقابلے میں چھوٹی قیمت ہے کہ آپ ایسی base-model accuracy کے ساتھ ship کریں جو آپ کے domain کے مطابق tuned نہ ہو۔

اختتامیہ

اصل کہانی یہ نہیں کہ “ایک 26M model function calling کر سکتا ہے” — یہ framing دراصل اس چیز کو کم کر کے دکھاتی ہے جو پہلے ہی ship ہو چکی ہے، کیونکہ Needle 2 ایک purpose-built architecture، grammar-guaranteed structured output، اور production escalation کے لیے بنے confidence contract کے ساتھ اس سے آگے بڑھ چکا ہے۔ بنیادی خیال وہ ہے جسے محفوظ رکھنا چاہیے: ہر AI task کو billion-parameter model کی ضرورت نہیں ہوتی، اور جب آپ کو بالکل معلوم ہو کہ ماڈل کو کیا کرنا ہے، تو اس کا پورا parameter budget ایک ہی کام کو بہترین انداز میں کرنے پر خرچ کرنا، اس budget کا زیادہ حصہ ایسی general capability پر خرچ کرنے سے بہتر ہے جسے آپ کبھی استعمال ہی نہیں کریں گے۔

کیا آپ دیکھ رہے ہیں کہ مزید teams اپنے agent stack کے محدود، structured حصوں کے لیے ایسے specialized tiny models کی طرف جا رہی ہیں، یا عملی طور پر اب بھی ایک بڑے general-purpose model کی کشش غالب ہے؟