AI Detection میں Token Probability اور Log-Likelihood

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

یہ ایک token probability ہے، اور ہر token probability ai detection اسی پر مبنی ہوتی ہے، ابتدا سے۔ کوئی بھی number of metrics جس کی report detector دے گا, including the two we cover elsewhere on this site, صرف ان numbers کی series پر کی گئی arithmetic ہے۔ وہ layer جس کے نیچے زیادہ تر 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 ہر possible next token کو, اس سے پہلے آنے والی چیز کی بنیاد پر, ایک probability assign کرتا ہے۔ ان per-token probabilities کو logarithms میں تبدیل کیا جاتا ہے اور passage بھر میں جمع کیا جاتا ہے, جس سے raw multiplication کے تقریباً فوراً پیش آنے والے numerical problem سے بچا جاتا ہے۔ حاصل شدہ sum, جسے average کر کے rescale کیا جاتا ہے, آخرکار perplexity figure کے طور پر سامنے آتا ہے یا classifier کے decision کو feed کرتا ہے۔ ہر stage arithmetic کا ایک مخصوص, قابلِ جانچ حصہ ہے, کوئی black box نہیں۔

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

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

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

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

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

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

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

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

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

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

عبارت کی لمبائی, مثالی طور پر	خام احتمال, جاری حاصل ضرب	log-probabilities کا مجموعہ
12 token، ہر ایک مثالی 0.1 کے ساتھ	1 x 10 to the power of -12, ابھی بھی قابلِ نمائندگی	تقریباً -27.6
350 token، ہر ایک مثالی 0.1 کے ساتھ	1 x 10 to the power of -350, بالکل 0 پر underflow ہو جاتا ہے	تقریباً -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 اعداد، جو ایک document میں variation کے لحاظ سے tracked ہوتے ہیں بجائے اس کے کہ انہیں ایک average میں ہموار کر دیا جائے، what burstiness is built from ہیں، جو perplexity سے متعلق مگر الگ signal ہے۔ دونوں اوپر بیان کردہ یکساں per-token اعداد سے شروع ہوتے ہیں۔ وہ صرف ان پر مختلف arithmetic کرتے ہیں۔

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

کسی classifier کو train کرنے یا watermark استعمال کرنے کے بجائے، یہ طریقہ ایک passage میں perturbation پیدا کرتا ہے، اس کے reworded ہونے کے انداز میں چھوٹی چھوٹی تبدیلیاں پیدا کرتا ہے، اور پھر ہر 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 reader کو نظر نہیں آتا اور بعد میں text کے ایک مختصر span پر 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 اسی per-token scoring کا ایک simplified version آپ کے اپنے draft پر چلاتا ہے، جو یہ دیکھنے کا زیادہ direct طریقہ ہے کہ کوئی passage کہاں کھڑا ہے، بجائے اس کے کہ verdict کو دوسرے ہاتھ سے پڑھا جائے۔

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

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