AI شناخت میں ٹوکن احتمال اور لاگ-لائیکلی ہڈ

اگر آپ کسی detector سے پوچھیں کہ اس نے وہ score کیسے نکالا، تو اس کے زیادہ تر user interfaces آپ کو ایک ہی جواب دیں گے: ایک ایسا پیراگراف جس میں کچھ الفاظ دوسروں کے مقابلے میں زیادہ گہرے سایے میں دکھائے گئے ہوں۔ یہ shading کوئی اندازہ نہیں ہے۔ یہ passage میں موجود ہر token کے ساتھ منسلک ایک عدد سے آتا ہے، جو detector کے perplexity، burstiness، یا final percentage کو چھونے سے بہت پہلے حساب کیا جاتا ہے۔

یہ token probability ہے، اور ہر token probability ai detection اسی پر، ابتدا سے، مبنی ہے۔ کسی detector کے رپورٹ کیے گئے metrics کی کوئی بھی تعداد, including the two we cover elsewhere on this site, صرف ان اعداد کی ایک سلسلے پر کی گئی arithmetic ہے۔ وہ تہہ جس کے نیچے کی تہہ پر زیادہ تر explanations رک جاتی ہیں، وہیں آپ کو یہ سوچنا پڑتا ہے کہ token اصل میں کیا ہے، model کی اس کے بارے میں distribution کا کیا مطلب ہے، اور arithmetic raw probability کے بجائے log space میں کیوں چلتی ہے۔ زیادہ تر explanations یہیں رک جاتی ہیں۔

ان میں سے کسی چیز کو opaque رہنے کی ضرورت نہیں۔ ایک token، ایک probability distribution اور ایک logarithm عام tools ہیں، کوئی proprietary secrets نہیں، اور یہی تین ideas how AI detectors actually work کی وضاحت کرتے ہیں, raw text سے لے کر report پر ایک single number تک۔

Token Probability AI Detection: Distribution سے Score تک

Token probability ai detection تین stages میں کام کرتا ہے۔ ایک language model اپنے سے پہلے آنے والی چیز کی بنیاد پر ہر ممکن next token کو ایک probability دیتا ہے۔ ان per-token probabilities کو logarithms میں بدلا جاتا ہے اور passage بھر میں جمع کیا جاتا ہے، جس سے ایک numerical problem سے بچا جاتا ہے جس سے raw multiplication تقریباً فوراً دوچار ہو جاتی ہے۔ حاصل شدہ sum، جب average کیا جائے اور rescale کیا جائے، تو آخرکار perplexity figure کے طور پر سامنے آتا ہے یا classifier کے decision کو feed کرتا ہے۔ ہر stage arithmetic کا ایک مخصوص، قابلِ جانچ حصہ ہے، کوئی black box نہیں۔

Token اصل میں کیا ہے

ایک ٹوکن ایک لفظ نہیں ہوتا۔ جدید زبان کے ماڈل متن کو byte-pair encoding جیسے الگورتھم کے ذریعے subword حصوں میں تقسیم کرتے ہیں، اس لیے 'the' جیسے عام لفظ کے لیے عموماً ایک ٹوکن ہوتا ہے، 'perplexity' جیسے کم عام لفظ کے لیے دو یا تین حصے بنتے ہیں، اور کوئی غیر مانوس نام انفرادی حروف تک بکھر سکتا ہے۔ عام انگریزی کا ایک اقتباس قابلِ اعتماد طور پر اپنے الفاظ کی تعداد سے زیادہ حصوں میں ٹوکنائز ہوتا ہے، اور کسی بھی word count پر اعتماد کرنے سے پہلے جو کوئی tool آپ کو واپس بتاتا ہے، یہ جاننا اہم ہے۔

ماڈل کبھی الفاظ کو اس طرح نہیں دیکھتا جس طرح ایک قاری دیکھتا ہے۔ وہ اعداد کی ایک ترتیب دیکھتا ہے، جن میں سے ہر ایک ایک fixed vocabulary میں ایک index ہوتا ہے جس پر ماڈل کو train کیا گیا تھا۔ token probability ai detection اس مقام کے بعد جو کچھ بھی کرتا ہے، وہ اسی عددی ترتیب پر عمل کرتا ہے، اصل حروفی string پر نہیں، اور یہی ایک وجہ ہے کہ detector کے اندرونی طریقۂ کار کسی شخص کے جملہ واقعی پڑھنے کے انداز سے الگ محسوس ہو سکتے ہیں۔

اگلے ٹوکن پر ماڈل کی تقسیم

کسی ترتیب میں ہر مقام پر، ایک autoregressive language model ایک prediction نہیں دیتا۔ وہ اپنی پوری vocabulary پر ایک مکمل probability distribution دیتا ہے، یعنی دسیوں ہزار اعداد جو مل کر 1 بنتے ہیں، اور ہر ممکن اگلے ٹوکن کو، اس سے پہلے آنے والی ہر چیز کی بنیاد پر، سب سے زیادہ سے کم امکان تک درجہ بند کرتا ہے۔ ماڈل کو 'the results of the' فقرہ دیں، تو وہ اس probability mass کا زیادہ تر حصہ چند موزوں اسموں، 'study,' 'experiment,' 'analysis,' کے درمیان تقسیم کرتا ہے، جبکہ 'marmalade.' جیسے لفظ کو نہایت معمولی حصہ دیتا ہے۔

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

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

خام احتمال کی جگہ Log-Likelihood کیوں آتا ہے

احتمالات کو آپس میں ضرب دینا ریاضیاتی طور پر درست ہے، مگر چند درجن ٹوکن کے بعد عملی طور پر بے کار ہو جاتا ہے۔ ہر انفرادی احتمال ایک کسر ہوتا ہے جو 1 سے کم ہوتی ہے، اس لیے جب ہر نئے ٹوکن کو ضرب میں شامل کیا جاتا ہے تو جاری حاصل ضرب ہر بار سکڑتی ہے، اور بہت تیزی سے سکڑتی ہے۔ چند سو ٹوکن کے بعد خام حاصل ضرب اتنا نیچے گر سکتا ہے کہ کمپیوٹر جس سب سے چھوٹے عدد کی نمائندگی کر سکتا ہے، اس سے بھی کم ہو جائے، اور پھر وہ بالکل صفر پر گول ہو جاتا ہے، جس ناکامی کو underflow کہا جاتا ہے۔

ایک بار ایسا ہو جائے تو اس عدد میں کوئی معلومات باقی نہیں رہتی۔ ایک دستاویز جو صرف غیر متوقع تھی اور ایک دستاویز جو انتہائی، بے ترتیب طور پر غیر متوقع تھی، دونوں ایک ہی صفر میں سمٹ جاتی ہیں، اور بعد میں ان میں فرق کرنے کا کوئی طریقہ نہیں رہتا۔ Logarithms اس مسئلے کو حل کرتے ہیں کیونکہ کسی حاصل ضرب کا logarithm، logarithms کے مجموعے کے برابر ہوتا ہے، جو بنیادی الجبرا کی ایک مساوات ہے۔ عام منفی اعداد کی ایک قطار کو جمع کرنا، چھوٹی کسرات کی ایک قطار کو ضرب دینے کی طرح underflow نہیں کرتا، اور اس کے علاوہ اس کا حساب بھی کم خرچ ہے۔

اقتباس کی لمبائی (مثالی)	خام احتمال، جاری حاصل ضرب	log-probabilities کا مجموعہ
12 ٹوکن، ہر ایک کے لیے مثالی 0.1	1 x 10 to the power of -12، ابھی بھی قابلِ نمائندگی	تقریباً -27.6
350 ٹوکن، ہر ایک کے لیے مثالی 0.1	1 x 10 to the power of -350، بالکل 0 پر underflows	تقریباً -805.9

یہ ایک سادہ کردہ مثال ہے۔ حقیقی per-token probabilities بہت زیادہ بدلتی رہتی ہیں، 0.1 کی ہموار سطح پر نہیں رہتیں، لیکن مسئلے کی سمت بالکل درست ہے۔ جیسے ہی کوئی خام حاصل ضرب underflow ہو کر صفر بن جاتا ہے، وہ موازنہ جس کی detector کو واقعی ضرورت ہوتی ہے, یعنی آیا یہ document اس document کے مقابلے میں زیادہ یا کم متوقع تھا, ناممکن ہو جاتا ہے۔ log-probabilities کا مجموعہ اس طرح کبھی ناکام نہیں ہوتا۔ یہ ایک دقیق، معمولی، قابلِ موازنہ عدد کی صورت میں برقرار رہتا ہے، چاہے passage کتنا ہی طویل کیوں نہ ہو، اور detectability کو raw probability space کے بجائے log space میں ناپنے کی اصل وجہ یہی ہے۔

Per-Token Scores سے Detection Score تک

کسی passage میں log-probabilities کو جمع کرنے سے reference model کے تحت document کی total log-likelihood حاصل ہوتی ہے۔ tokens کی تعداد سے تقسیم کرنے سے length کا اثر ختم ہو جاتا ہے اور average log-likelihood per token باقی رہتی ہے، ایک ایسا عدد جو بالآخر پانچ سو لفظی essay اور پانچ ہزار لفظی thesis chapter کے درمیان قابلِ موازنہ ہو جاتا ہے۔ اس average کو منفی کریں اور exponentiate کریں، تو جو نتیجہ نکلتا ہے وہ perplexity score ہے، ایک ایسا metric جس کی اس cluster میں مکمل وضاحت ایک الگ نظر میں what perplexity actually measures کے تحت کی گئی ہے۔

وہی per-sentence figures، جنہیں ایک average میں سمیٹنے کے بجائے document بھر میں variation کے لحاظ سے track کیا جاتا ہے، what burstiness is built from ہیں، جو perplexity سے متعلق مگر الگ signal ہے۔ دونوں کا آغاز اوپر بیان کردہ یکساں per-token numbers سے ہوتا ہے۔ فرق صرف یہ ہے کہ ان پر اوپر سے مختلف arithmetic کی جاتی ہے۔

سادہ average اس خام مواد کو استعمال کرنے کا واحد طریقہ نہیں ہے، اور research اس سے کافی آگے بڑھ چکی ہے۔ DetectGPT, جو ICML 2023 میں Mitchell, Lee, Khazatsky, Manning and Finn نے شائع کیا، اسی probability function کی ایک مختلف خاصیت سے کام کرتا ہے: language model سے sampled text عموماً اس خطے میں ہوتا ہے جہاں معمولی rewordings log-probability کو بڑھانے کے بجائے گھٹا دیتی ہیں، اور paper اس pattern کو negative curvature کہتی ہے۔

کسی classifier کو train کرنے یا watermark استعمال کرنے کے بجائے، یہ طریقہ ایک passage میں perturbation پیدا کرتا ہے، اس کی rewording میں چھوٹی چھوٹی variations بناتا ہے، اور پھر ہر variation کو اسی model کے ساتھ دوبارہ score کرتا ہے۔ paper اس کا موازنہ بہترین zero-shot baseline سے کرتا ہے اور پاتا ہے کہ 20-billion-parameter model سے generated text پر یہ طریقہ 0.95 AUROC حاصل کرتا ہے، جبکہ بہترین zero-shot baseline 0.81 AUROC حاصل کرتا ہے۔

وہی Distribution، Detect کرنے کے بجائے Watermark کرنے کے لیے استعمال کی گئی

اب تک ہر چیز میں probability distribution کو ایسی چیز سمجھا گیا ہے جسے بعد میں پڑھا جاتا ہے۔ اسے generation کے لمحے پر بھی استعمال کیا جا سکتا ہے، اور اس طرح مسئلہ بالکل الٹ جاتا ہے۔ Kirchenbauer, Geiping, Wen, Katz, Miers and Goldstein کا 2023 method ہر لفظ پیدا ہونے سے پہلے allowed tokens کی ایک randomized shortlist منتخب کرتا ہے، جو اس سے پہلے آنے والی چیز کے hash پر مبنی ہوتی ہے، اور sampling کو نرمی سے اس shortlist کی طرف steer کرتا ہے۔ یہ bias قاری کو نظر نہیں آتا اور بعد میں text کے ایک مختصر حصے پر statistical test کے ذریعے recover کیا جا سکتا ہے، original model تک رسائی کے بغیر۔

Google DeepMind کا SynthID اس خیال کا ایک version production میں لاتا ہے: یہ generation time پر next-token probability scores کو adjust کرتا ہے اور آج Gemini app اور web experience میں live ہے۔ OpenAI نے ایک comparable system بنایا اور اسے ship نہیں کیا۔ reporting اس فیصلے کو جزوی طور پر ایک survey سے منسوب کرتی ہے جس میں تقریباً 30 percent ChatGPT users نے کہا کہ watermarking سے وہ product کم استعمال کریں گے، اور اس کے ساتھ اس تشویش کو بھی کہ watermark paraphrasing کے دوران کتنی اچھی طرح survive کرے گا۔

ایک detector کی report ایک shaded word یا ایک single percentage دکھاتی ہے اور وہیں رک جاتی ہے، کبھی یہ نہیں دکھاتی کہ وہ distribution کیا تھی جس سے یہ سب آیا۔ TextPulse کا free perplexity checker آپ کے اپنے draft پر اسی per-token scoring کا ایک simplified version چلاتا ہے، جو یہ دیکھنے کا زیادہ براہ راست طریقہ ہے کہ کوئی passage کہاں کھڑا ہے، بجائے اس کے کہ verdict کو بالواسطہ پڑھا جائے۔

دو پڑوسی صفحات اس کو اٹھاتے ہیں۔ کیا detectors اب بھی burstiness پر انحصار کرتے ہیں 2023 کے بعد بدل چکا ہے، اور GPTZero ان ہی probabilities کو score میں کیسے بدلتا ہے اپنی الگ صفحے پر بیان کیا گیا ہے۔

یہ TextPulse کے باقی free tools کے ساتھ موجود ہے، اس لیے ایک ہی مسودہ کو rhythm اور structure کے ساتھ ساتھ word-level predictability کے لیے بھی جانچا جا سکتا ہے، بغیر اس کے کہ ایسا کرنے کے لیے ایک درجن الگ tabs کھولنے پڑیں۔