No. 003تعینیت9 منٹ مطالعہ

اعتماد کے ساتھ غلط ریونیو نمبر: LLMs جمع کیوں نہیں کر سکتے

ماڈل آپ کو ریونیو کا ایک عدد کامل اعتماد کے ساتھ تھماتا ہے — اور اس کے پیچھے کوئی حساب نہیں ہوتا۔ تحقیق کہتی ہے یہ ناکامی ساختی ہے — اور اس کا حل بھی۔

اکتوبر 2025 میں Deloitte نے آسٹریلوی حکومت کو رقم واپس کی۔ فرم نے محکمۂ روزگار و کاری تعلقات کو AU$440,000 کا ایک جائزہ فراہم کیا تھا؛ شائع شدہ رپورٹ میں ایک وفاقی عدالتی فیصلے سے گھڑا ہوا اقتباس اور ایسے علمی مقالات کے حوالے شامل تھے جن کا وجود ہی نہیں (The Guardian, 2025)۔ نظرثانی شدہ نسخے میں انکشاف ہوا کہ مسودہ سازی میں GPT-4o استعمال ہوا تھا۔ بعد کی رپورٹنگ کے مطابق واپسی تقریباً AU$97,000 تھی — معاہدے کی آخری قسط۔

ایک تفصیل رقم سے زیادہ اہم ہے۔ یہ من گھڑت باتیں نہ فرم کے جائزے میں پکڑی گئیں، نہ کلائنٹ کے۔ انہیں ایک بیرونی ماہرِ تعلیم نے پکڑا جس نے حوالے جانچے۔ یہ دستاویز ہر اس جانچ پڑتال کی تہہ سے گزر گئی جس کے لیے اسے بنایا گیا تھا، کیونکہ اس میں کچھ بھی غلط نظر نہیں آتا تھا۔

یہی وہ زمرہ ہے: وہ ماڈل نہیں جو ناکام ہو، بلکہ وہ جو جواب لوٹائے۔ کسی لینگویج ماڈل سے دو سو قطاروں کا ریونیو جمع کرنے کو کہیں تو آپ کو ایک جواب ملتا ہے — درست پیمانے کے ساتھ، درست کرنسی علامت کے ساتھ، اور ایک پراعتماد جملے میں لپٹا ہوا۔ جو چیز قابلِ اعتماد طریقے سے نہیں ملتی وہ ہے مجموع۔ غائب جواب پکڑا جاتا ہے۔ اچھے انداز میں پیش کیا گیا غلط جواب بورڈ کو بھیج دیا جاتا ہے۔

اور یہ انداز کبھی نہیں ٹوٹتا، کیونکہ اعتماد بھی تخلیق شدہ متن ہے۔ ماڈل کو معلوم نہیں کہ وہ غلط ہے؛ دبانے کے لیے کوئی اندرونی الارم نہیں۔ عدد کا دعویٰ کرنے والا جملہ اور خود عدد ایک ہی جگہ سے آتے ہیں — اگلا ممکنہ ٹوکن۔

قابلِ یقین، حسابی نہیں

فطری رجحان یہ ہے کہ غلط اعداد کو ماڈل کی ناپختگی میں شمار کریں: یقیناً اگلا ورژن درست جمع کرے گا۔ تحقیق کہتی ہے یہ ناکامی ساختی ہے، اور اس کی وجہ پر غیرمعمولی اتفاق ہے۔

GPT-4 سے دو تین ہندسوں کے اعداد ضرب کرنے کو کہا گیا تو zero-shot میں 59% درست؛ ChatGPT نے 55% (arXiv, 2023)۔ چار ہندسوں پر GPT-4 گر کر 3% پر آ گیا۔ پانچ پر 0%۔ Faith and Fate کے مصنفین نے طریقہ کار کا سراغ لگایا: ٹرانسفارمر مرکب مسائل کو دیکھے ہوئے لکیری ٹکڑوں کی مطابقت سے حل کرتے ہیں — نمونہ تلاش، طریقہ کار نہیں۔ چٹان بالکل وہیں ہے جہاں نمونے ختم ہوتے ہیں۔

جمع بھی محفوظ نہیں۔ 2025 کے ایک تجزیے نے پایا کہ LLMs ایک الگورتھم کی بجائے ایک ہندسے کے lookahead heuristic سے جمع کرتے ہیں: درستگی بالکل وہیں گرتی ہے جہاں carries ایک ہندسے سے آگے پھیلتی ہیں، prompting یا tokenization سے قطع نظر، اور ناکامیاں صرف carry ڈھانچے سے قابلِ پیش گوئی ہیں (arXiv, 2025)۔ منظم، بے ترتیب نہیں۔ ماڈل تقریباً حساب نہیں کر رہا۔ وہ کچھ اور کر رہا ہے جو اکثر حساب سے متفق ہوتا ہے۔

Apple کے GSM-Symbolic نے آخری راستہ بند کیا — کہ شاید یہ صرف مشکل حساب کو متاثر کرتا ہے (Apple, 2024)۔ پرائمری سطح کے لفظی مسائل لیں اور صرف اعداد بدلیں: آزمائے گئے ہر جدید ماڈل کی کارکردگی گری۔ ایک قابلِ یقین مگر غیرمتعلق شق شامل کریں: درستگی 65% تک گر گئی۔ اور ایک ہی سوال کے سانچے کی تازہ مثالوں میں درستگی نمایاں طور پر مختلف رہی — وہی مسئلہ، دوبارہ الفاظ میں، جوابات کی مختلف تقسیم دیتا ہے۔ یہ آخری نتیجہ ڈیمو کا مسئلہ بیان کرتا ہے۔ ڈیمو تقسیم سے ایک نمونہ ہے۔ آڈٹ وہ تقسیم ہے۔

مصنفین کا فیصلہ — "موجودہ LLMs حقیقی منطقی استدلال کے قابل نہیں" — ایک تحقیقی مقالے کے لیے غیرمعمولی طور پر صریح ہے۔ کسی نے اسے رد نہیں کیا۔

100 50 0 accuracy, % zero-shot scratchpad 59 92 3×3-digit 4 4×4-digit 0 5×5-digit
n-ہندسہ × n-ہندسہ ضرب پر GPT-4 کی درستگی، zero-shot بمقابلہ مرحلہ وار scratchpad۔ Faith and Fate, NeurIPS 2023۔

واضح حل، پیمائش کے ساتھ

ہر ٹیم جو اس ناکامی سے ٹکراتی ہے وہی چار حل تلاش کرتی ہے۔ ہر ایک کی پیمائش ہو چکی ہے۔

بازیابی۔ FinanceBench نے GPT-4-Turbo سے عوامی مالیاتی دستاویزات کے بارے میں 150 سوالات پوچھے، بازیابی نظام دستاویزات فراہم کرتا رہا۔ اس نے 81% کے غلط جواب دیے یا انکار کیا (Patronus AI, 2023)۔ سولہ ترتیبات — GPT-4-Turbo، Llama 2، Claude 2، vector stores، طویل context — نے 2,400 دستی جائزہ شدہ جوابات میں کمزوریاں ظاہر کیں، اور جب ثبوت کے صفحات بالکل درست فراہم نہ ہوئے تو ماڈلز نے اعداد گھڑ لیے۔ بازیابی دستاویز لاتی ہے۔ ماڈل پھر بھی عدد بگاڑ دیتا ہے۔

گراؤنڈنگ۔ BBC نے ChatGPT، Copilot، Gemini اور Perplexity کو اپنے مضامین تک براہِ راست رسائی دی اور خبروں کے بارے میں سوالات پوچھے۔ 51% جوابات میں سنگین مسائل تھے؛ 91% میں کچھ نہ کچھ۔ BBC مواد کا حوالہ دینے والے 19% جوابات میں حقائق کی غلطیاں تھیں — غلط بیانات، غلط اعداد، غلط تاریخیں — اور BBC مضامین سے منسوب 13% اقتباسات بدلے ہوئے یا کبھی موجود ہی نہ تھے (BBC, 2025)۔ ماخذ ہاتھ میں تھا۔ اعداد پھر بھی مڑ گئے۔

ذہین تر ماڈل۔ OpenAI کا اپنا system card رپورٹ کرتا ہے کہ o3 نے PersonQA prompts پر 33% اور o4-mini نے 48% hallucination کی — پرانے o1 کے 16% کے مقابلے میں (OpenAI, 2025)۔ وینڈر کی اپنی پیمائش کے مطابق، نئے reasoning ماڈلز اپنے پیشرو سے دو سے تین گنا زیادہ hallucinate کرتے ہیں۔ o3 محض زیادہ دعوے کرتا ہے — زیادہ درست اور زیادہ گھڑے ہوئے، یکساں یقین کے ساتھ۔

بہتر prompting۔ مرحلہ وار scratchpad prompting GPT-4 کی تین ہندسوں کی ضرب 59% سے 92% تک لے جاتی ہے (arXiv, 2023)۔ بہتر — اور پھر بھی بارہ میں سے ایک غلط۔ GPT-3 کو چار ہندسوں کی ضرب پر مکمل fine-tuning سے بھی نادیدہ چار ہندسوں کے مسائل پر تقریباً 40% اور پانچ ہندسوں پر 0% ملا۔ حد طریقہ کار میں ہے، prompt میں نہیں۔

ہر حل امکانات بہتر کرتا ہے۔ کوئی بھی یہ نہیں بدلتا کہ حساب کون کرتا ہے۔ جواب اب بھی قابلِ یقین اعداد کی تقسیم سے نمونہ لیا جاتا ہے، اور اس تقسیم کا صرف ایک رکن مجموع ہے۔

0 50 100 % RETRIEVAL · FINANCEBENCH 2023 wrong or refused 81% GROUNDING · BBC 2025 significant issues 51% factual errors introduced 19% REASONING · PERSONQA, OPENAI 2025 o1 (predecessor) 16% o3 33% o4-mini 48%
حل کے بعد ناکامی کی شرح۔ FinanceBench 2023 · BBC 2025 · OpenAI o3 / o4-mini system card 2025۔

حساب کون کرے

ساختی جواب ایک ایسی تقسیمِ کار ہے جو بالکل اہلیت کی لکیر پر کھینچی گئی ہو۔ لینگویج ماڈل زبان میں بے مثال اور بہی کھاتوں میں ناقابلِ اعتماد ہیں، لہٰذا ماڈل کو کبھی حساب کرنے والی چیز نہیں ہونی چاہیے۔

SQAI اسی تقسیم پر بنا ہے۔ ماڈل ایک typed intent تصنیف کرتا ہے — sum amount where region = "east" — اور ایک تعینیاتی انجن اسے مرتب شدہ کوڈ کے طور پر چلاتا ہے: hash-pinned معاہدے کے خلاف تصدیق شدہ، پالیسی کے خلاف جانچا گیا، ایک تھریڈ پر float64 میں حسابی، provenance کے ساتھ واپس کیا گیا۔

{
  "status": "ok",
  "value": 2130.5,
  "rows_matched": 5
}

یہ 2130.5 کوئی ممکنہ ٹوکن نہیں۔ یہ مجموع ہے، 445 ماڈیولز میں 4,574 read-only صلاحیتوں کی سطح سے ایک تعینیاتی kernel کے ذریعے تیار کیا گیا — جن میں سے 4,564 مکمل طور پر تعینیاتی ہیں — 0.83–0.93 ms warm میں جواب دیتا ہے۔

تعینیاتی کا مطلب قابلِ جانچ ہے۔ finance.npv(0.1, [-1000, 300, 420, 560, 680]) computation hash b74f67d0… کے تحت 505.020148896933 لوٹاتا ہے — چاہے کال TypeScript سے کی جائے یا Python سے، وہی قدر اور وہی hash، کیونکہ نتائج ایک canonical JSON شکل پر hash کیے جاتے ہیں۔ دعویٰ ایمانداری سے محدود ہے: اعلان کردہ execution scope کے اندر تعینیاتی، ایک envelope کے ساتھ جو runtime ورژن، platform، precision mode اور thread count ریکارڈ کرتا ہے بجائے بڑھا چڑھا کر دعویٰ کرنے کے۔ ایک ماڈل کا اسی prompt کا جواب اگلی بار خود سے مطابقت کا وعدہ نہیں کر سکتا۔ یہ مہینوں بعد، کسی بھی زبان میں، byte-identical طریقے سے دہرایا جاتا ہے۔

ایک دوسرا رساؤ ہے، اور زیادہ تر stacks اسے کھلا چھوڑ دیتے ہیں۔ ایک compute engine جوڑیں، پھر خام query rows کو "خلاصے کے لیے" context میں ڈالیں — اور ماڈل خاموشی سے rows سے اعداد دوبارہ اخذ کرتا اور گھڑتا ہے۔ SQAI context کو ایک governed boundary کے طور پر برتتا ہے: زیادہ سے زیادہ 25 rows، 250 cells اور 32,000 bytes ماڈل تک پہنچتے ہیں، 100 rows کی پہلے سے طے شدہ حد اور 1,000 کی سخت execution ceiling کے پیچھے۔ کٹاؤ ہمیشہ ظاہر کیا جاتا ہے، تاکہ ماڈل ایمانداری سے یہ دعویٰ نہ کر سکے کہ اس نے جو دیکھا اسے جمع کیا۔ جزوی rows کبھی نہیں دکھائی جاتیں، تاکہ کوئی ادھا ریکارڈ اسے تخیل سے مکمل کرنے پر نہ اکسائے۔ Aggregates حد سے پہلے حسابی ہوتے ہیں۔ ماڈل کو جواب ملتا ہے، ہوم ورک نہیں۔

اور پالیسی کوئی prompt نہیں ہے۔ اجازت یافتہ sources، fields اور functions createSQAI() کے وقت کوڈ میں طے ہوتے ہیں اور execution سے پہلے in-process جانچے جاتے ہیں؛ ماڈل کے tool input میں کوئی policy fields نہیں ہوتے، لہٰذا اسے وسیع کرنے کے لیے کچھ نہیں۔ پالیسی سے باہر کسی صلاحیت کی درخواست کوئی تخلیقی حل نہیں دیتی — وہ policy_denied_function دیتی ہے۔ دلیل وہی ہے جو agents کو SQL لکھنے نہ دینے کے پیچھے ہے: تخلیق شدہ متن کو بہترین کوشش کی ہدایات سے نہ چلائیں؛ execution کو allow-lists سے چلائیں جنہیں متن چھو نہیں سکتا۔

GOVERNED BOUNDARY MODEL language in, language out sum(amount) · region = "east" typed intent — never a SQL string ENGINE contract → policy → execute float64 · 1 thread · sub-ms warm value 2130.5 · rows 5 plan_hash f87610d8afeb… byte-identical replay · TS ≡ PY answer, not rows ≤ 25 rows · ≤ 250 cells · ≤ 32,000 B truncation always declared
تقسیمِ کار: ماڈل typed intent تصنیف کرتا ہے؛ float64 kernel حساب کرتا ہے؛ row caps خام ڈیٹا کو context سے باہر رکھتی ہیں۔

حساب کس نے کیا؟

اگلی بار جب کوئی AI نظام آپ کو ریونیو کا عدد دے، ایک سوال بازار کے ہر architecture کو چھانٹ دیتا ہے: حساب کس نے کیا؟

اگر جواب ہے "ماڈل نے،" تو آپ کے ہاتھ میں ایک عدد ہے جس کا انداز بے عیب اور provenance نامعلوم ہے، اور تصدیق کا واحد راستہ یہ ہے کہ انسان کام دوبارہ کرے — وہی چیز جسے آپ خودکار کرنا چاہتے تھے۔ Deloitte کی من گھڑت باتیں اس لیے پکڑی گئیں کیونکہ عمل سے باہر ایک ماہرِ تعلیم نے جانچنے کا فیصلہ کیا۔ یہ کوئی ضابطہ نہیں۔ یہ قسمت ہے۔

اگر جواب ہے "ایک تعینیاتی انجن نے، اور یہ رہا hash،" تو تصدیق ایک replay ہے: وہی intent، وہی انجن، وہی bytes۔ ناکامی اس وقت زیادہ باریک — اور خاموش — ہو جاتی ہے جب غلط عدد غلط جمع کی بجائے پھیلے ہوئے join سے آئے، جو اپنی الگ کہانی ہے۔ لیکن اصول ایک جملے میں سما جاتا ہے: ماڈل سوال لکھتا ہے، جواب کبھی نہیں۔

غلط ریونیو نمبر خود کو ظاہر نہیں کرتا۔ وہ مرتب، حوالہ شدہ اور پراعتماد آتا ہے — اور پانچ ہندسوں کی ضرب میں کبھی درست نہیں۔ pipeline اس طرح بنائیں کہ وہ داخل ہی نہ ہو سکے۔