آپ نے ایک ایسا اندرونی ٹول بنایا ہے جو ایک ٹیم کو LLM پر مبنی فیچر کے لیے 28 یونٹ ٹیسٹ چلانے کی اجازت دیتا ہے، وہ بھی ماڈل کی API کو کال کیے بغیر۔ آپ نے اسے ماڈل کو ایک فیک ایبل انٹرفیس (fakeable interface) میں لپیٹ کر اور تین تہوں (deterministic، heuristic اور LLM-based evaluation) کے ذریعے حاصل کیا۔

روایتی اسسرشنز (assertions) اس وقت ٹوٹ جاتی ہیں جب LLM نثر (prose) تیار کرتا ہے۔ ایک ہی پرامپٹ ہر بار مختلف جملہ دے سکتا ہے، اس لیے assertEqual(output, expected) ناکامی کا نشان لگا دیتا ہے چاہے ماڈل نے درست طریقے سے کام کیا ہو۔ زیادہ تر انجینئرنگ گروپس یا تو بغیر کسی تصدیق کے فیچر لانچ کر دیتے ہیں یا خود ماڈل کو ٹیسٹ کرنے کی کوشش کرتے ہیں، جیسے کہ کسی مسلسل بدلتے ہوئے ہدف کو کوئی ساکن لائبریری سمجھا جا رہا ہو۔

یہ مسئلہ کیوں اہم ہے

LLMs اب کسٹمر کے سامنے والے ورک فلو کا حصہ ہیں—ای میل رابطہ، سپورٹ کے جوابات، مواد کی تخلیق۔ ایک بھی فرضی حقیقت (hallucinated fact) یا ڈیٹا کا اخراج برانڈ کی ساکھ کو نقصان پہنچا سکتا ہے، نجی ڈیٹا کو ظاہر کر سکتا ہے، یا تعمیل (compliance) کی خلاف ورزیوں کا سبب بن سکتا ہے۔ ایک قابل اعتماد ٹیسٹ حکمت عملی کے بغیر، ٹیمیں غیر مستحکم ناکامیوں (flaky failures) کے پیچھے وقت ضائع کرتی ہیں یا ایسے بگ لانچ کرتی ہیں جو صرف پروڈکشن میں سامنے آتے ہیں۔

طریقہ کار: ماڈل کی ذمہ داری کو کم کرنا

پہلا قدم یہ تھا کہ LLM کے اصل کام کو محدود کیا جائے۔ مصنف کے سسٹم میں ماڈل صرف آؤٹ ریچ پیغامات کا ڈرافٹ تیار کرتا ہے۔ تمام روٹنگ لاجک، اسٹیٹ مینجمنٹ اور سیفٹی چیک عام کوڈ میں رہتے ہیں۔ ماڈل کو ایک واحد، واضح آؤٹ پٹ تک محدود کر کے، ارد گرد کا سسٹم یقینی (deterministic) اور ٹیسٹ کے قابل رہتا ہے۔

اسے ممکن بنانے کے لیے، LLM ایک پرووائیڈر انٹرفیس کے پیچھے کام کرتا ہے، جس سے ٹیسٹ میں ایک فیک ورژن استعمال کرنا ممکن ہو جاتا ہے۔ پروڈکشن میں، امپلیمنٹیشن بیرونی API کو کال کرتی ہے؛ ٹیسٹ سویٹ میں، ایک ہلکا پھلکا فیک (fake) پہلے سے تیار شدہ جواب (canned response) واپس کرتا ہے۔ چونکہ باقی کوڈ صرف انٹرفیس کے ساتھ بات چیت کرتا ہے، اس لیے پورے ورک فلو کو یونٹ ٹیسٹ کے ذریعے آزمایا جا سکتا ہے جو کبھی نیٹ ورک کو چھوتے بھی نہیں۔ اس کا نتیجہ ایک قابلِ پیش گوئی کور (core) ہے جسے 28 ٹیسٹ تصدیق کرتے ہیں۔

ایک ایماندارانہ ایویلیوایشن ہارنس

اسکوپ کو محدود کرنے کے باوجود، ماڈل کا آؤٹ پٹ غیر یقینی (nondeterministic) رہتا ہے۔ اس لیے مصنف نے تین تہوں والا ایویلیوایشن ہارنس (evaluation harness) بنایا، جس میں سے ہر تہہ خطرے کی ایک مختلف قسم کو سنبھالتی ہے۔

  • تہہ 1 – Deterministic چیکس سادہ ریگولر ایکسپریشن رولز ٹھوس غلطیوں کو پکڑ لیتے ہیں جیسے کہ غلط بلڈنگ آئی ڈی یا ممنوعہ ٹوکنز۔ یہ چیک تیز ہوتے ہیں اور بائنری پاس/فیل (pass/fail) فراہم کرتے ہیں۔

  • تہہ 2 – Heuristic چیکس اسکرپٹس فرضی نمبروں یا تاریخوں کو تلاش کرتے ہیں، اور واضح طور پر حقیقت سے ہٹ کر معلومات کو نشان زد کرتے ہیں۔ وہ ایسے جھوٹے دعووں کو نہیں پکڑ پاتے جن میں عددی اشارے نہ ہوں، اور مصنف نے اس حد کا کھل کر اعتراف کیا ہے۔

  • تہہ 3 – LLM جج ایک ثانوی ماڈل لہجے اور پیشہ ورانہ مہارت کی درجہ بندی کرتا ہے۔ چونکہ یہ مرحلہ ایک اور امکانی (probabilistic) سسٹم پر انحصار کرتا ہے، اس لیے اسے صرف موضوعی (subjective) پہلوؤں کے لیے استعمال کیا جاتا ہے جہاں یقینی قواعد ناممکن ہوں۔

ہارنس کی کلید وہ ڈیٹا سیٹ ہے جو ایویلیوایشن کے لیے استعمال ہوتا ہے۔ مصنف نے ناکامی کے معلوم پیٹرنز—مخصوص جال اور ڈومین نالج—کو انکوڈ کیا ہے تاکہ ہارنس بالکل ان غلطیوں کا ٹیسٹ کرے جو عملی طور پر سامنے آئی ہیں۔ یہ کوئی جادوئی "سب کچھ پکڑ لینے والا" نظام نہیں ہے بلکہ ایک ہدف شدہ حفاظتی جال (safety net) ہے۔

ٹیموں کے لیے اس کے معنی

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

ایک دوسرا پہلو: آپ اب بھی ماڈل کو خود یونٹ ٹیسٹ نہیں کر سکتے

مصنف تسلیم کرتا ہے کہ ماڈل ایک بدلتا ہوا ہدف ہے۔ یہاں تک کہ LLM جج کی تہہ بھی اسی غیر یقینی پن (nondeterminism) کا شکار ہے جس کا وہ جائزہ لینے کی کوشش کرتی ہے۔ نتیجے کے طور پر، سسٹم کبھی یہ ضمانت نہیں دے سکتا کہ ہر ہیلو سینیشن یا پالیسی کی خلاف ورزی ریلیز سے پہلے پکڑی جائے گی۔ یہ طریقہ کار خطرے کو کم کرتا ہے، ختم نہیں کرتا، اور یہ ٹیم کی اس صلاحیت پر انحصار کرتا ہے کہ نئے ناکامی کے طریقوں کے سامنے ایویلیوایشن ڈیٹا کو اپ ٹو ڈیٹ رکھا جائے۔

خلاصہ

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