GitHub Actions merge queue کے اندر آٹھ ماہ گزارنے سے آپ کو وہ کچھ سیکھنے کو ملتا ہے جو فیچر موازنہ میٹرکس (feature comparison matrices) کبھی نہیں سکھا سکتے۔ ایک فریم ورک پچاس میٹرکس، شاندار ڈیش بورڈز، اور معتبر ریسرچ لیبز کے حوالے فراہم کر سکتا ہے۔ لیکن اگر یہ آپ کی ڈیپلائمنٹ کو اس لیے روک دے کیونکہ ایک "vibe check" اسکور ایک ہی کوڈ کے مقابلے میں 0.72 سے گر کر 0.68 ہو گیا ہے، تو یہ بیکار ہونے سے بھی بدتر ہے۔ یہ آپ کی شپنگ ویلوسٹی (shipping velocity) کے لیے ایک فعال خطرہ بن جاتا ہے۔
یہی وہ فلٹر ہے جسے زیادہ تر LLM ایویلیوایشن خلاصے (roundups) نظر انداز کر دیتے ہیں۔ وہ صلاحیتوں (capabilities) کو گنتے ہیں۔ وہ شاذ و نادر ہی وہ واحد سوال پوچھتے ہیں جو مرج کیو (merge queue) میں اہمیت رکھتا ہے: کیا یہ چیک ہر بار چلنے پر بالکل ایک ہی طرح سے پاس اور فیل ہوتا ہے؟
میں نے یہ مشکل کام کر کے سیکھا۔ میں نے چھ اوپن سورس LLM ایویلیوایشن فریم ورکس کو ایک حقیقی CI پائپ لائن میں جوڑا۔ وہ آٹھ ماہ تک لائیو پروڈکشن پل ریکویسٹس (pull requests) پر چلے۔ دو نے گیٹ کیپر (gatekeepers) کے طور پر رہنے کا حق حاصل کیا۔ باقیوں کو مشاورتی ڈیش بورڈز تک محدود کر دیا گیا، نائٹلی جابز (nightly jobs) میں منتقل کر دیا گیا، یا مکمل طور پر ہٹا دیا گیا۔ سبق تلخ اور مہنگا تھا: جب آپ مین برانچ کی حفاظت کر رہے ہوں، تو یقینی ساخت (deterministic structure) امکاناتی معیار (probabilistic quality) کو مات دے دیتی ہے۔
مرج گیٹ کا اصل کام
ایک CI گیٹ ریسرچ کا ماحول نہیں ہے۔ یہ ایک باؤنسر ہے۔ اس کا پورا مقصد ایک مخصوص تبدیلی کو دیکھنا اور 'ہاں' یا 'ناں' میں جواب دینا ہے۔ ہاں، یہ PR مین برانچ میں شامل ہو سکتا ہے۔ ناں، یہ نہیں ہو سکتا۔ اس جواب کو سیکنڈوں میں پہنچنا چاہیے، اس کی لاگت معمولی ہونی چاہیے، اور اسے کبھی بھی ماضی کے فیصلوں کو تبدیل نہیں کرنا چاہیے۔ اگر آپ کسی پرسکون منگل اور کسی افراتفری والے جمعہ کو اسی کمٹ (commit) پر وہی پائپ لائن دوبارہ چلائیں، تو نتیجہ بالکل ایک جیسا ہونا چاہیے۔
یہیں پر زیادہ تر LLM ایویلیوایشن فریم ورکس لڑکھڑا جاتے ہیں۔ انہیں ڈیٹا سائنسدانوں نے ڈیٹا سائنسدانوں کے لیے بنایا ہے۔ وہ بصیرت (insight)، تحقیق، اور باریک بینی سے اسکورنگ کے لیے کام کرتے ہیں۔ جبکہ ایک مرج کیو بائنری فیصلوں، رفتار، اور صفر غیر مستقل مزاجی (zero flakiness) کے لیے کام کرتا ہے۔ یہ دونوں مقاصد صرف جزوی طور پر ایک دوسرے سے ملتے ہیں۔
LLM-as-Judge کی وجہ سے کیو (Queue) کیوں متاثر ہوتی ہے
میرے ٹیسٹ میں ناکام ہونے والے ٹولز میں ایک ہی ڈیزائن کی غلطی مشترک تھی: وہ بنیادی گیٹ میکانزم کے طور پر LLM-as-judge کالز پر بہت زیادہ انحصار کرتے تھے۔
ایک LLM-as-judge پرامپٹ ماڈل سے کسی آؤٹ پٹ کو ایک سے دس کے پیمانے پر اسکور کرنے، یا دو جوابات میں سے بہتر کا انتخاب کرنے، یا حقائق کی درستگی کی درجہ بندی کرنے کا کہتا ہے۔ یہ طریقہ کار معیار کے رجحانات کو سمجھنے کے لیے طاقتور ہے۔ لیکن ایک بلاکنگ CI چیک کے لیے یہ زہر ہے۔ وہی ان پٹ مختلف دنوں میں مختلف اسکورز پیدا کر سکتا ہے کیونکہ ٹیمپریچر (temperature)، ماڈل ورژننگ، اور پرامپٹ فارمیٹنگ سب شور (noise) پیدا کرتے ہیں۔ جب وہ اسکور ایک سخت حد (hard threshold) اور ایک سخت ایگزٹ کوڈ (hard exit code) سے جڑا ہو، تو آپ کی کیو فرضی مسائل کی وجہ سے بلاک ہو جاتی ہے۔
ناکامیوں کا سلسلہ تیزی سے بڑھتا ہے۔ ایک غیر یقینی (nondeterministic) چیک کیو میں بیک لاگ پیدا کرتا ہے۔ انجینئرز اس تک دوبارہ کوشش (retry) کرنے کے عادی ہو جاتے ہیں جب تک کہ نمبر سازگار نہ آ جائے، جو ٹیم کو ریڈ بلڈز (red builds) کو نظر انداز کرنے کی تربیت دیتا ہے۔ ٹوکن کے اخراجات بڑھ جاتے ہیں کیونکہ ہر ری ٹرائی مزید API کریڈٹس جلاتی ہے۔ سب سے بدترین بات یہ ہے کہ سگنل بے معنی ہو جاتا ہے۔ ایک ریڈ بلڈ کا مطلب ہونا چاہیے "آپ نے بگ متعارف کرایا ہے"۔ اگر اس کا مطلب یہ ہو کہ "جج ماڈل آج زیادہ نخرے دکھا رہا ہے،" تو اعتماد ختم ہو جاتا ہے۔
بچ جانے والے فریم ورکس کیا مختلف کرتے ہیں
Promptfoo اور DeepEval اس لیے بچ گئے کیونکہ وہ یقینی چیکس (deterministic checks) کو بنیادی اہمیت دیتے ہیں اور LLM جج اسکورز کو ثانوی، غیر بلاکنگ سگنلز کے طور پر استعمال کرتے ہیں۔ وہ سمجھتے ہیں کہ ایک گیٹ کو ایگزٹ کوڈ کی ضرورت ہوتی ہے، نہ کہ کسی رائے رکھنے والے فلوٹنگ پوائنٹ نمبر کی ضرورت۔
Promptfoo، جو MIT لائسنس کے تحت جاری کیا گیا ہے، کمانڈ لائن کے لیے بنایا گیا ہے۔ یہ regex matches، JSON schema validation، contains checks، اور exact string comparisons جیسے اسسرشنز (assertions) چلاتا ہے۔ یہ کوئی بہت زیادہ پیچیدہ چیزیں نہیں ہیں۔ یہ دراصل بہتر شدہ grep اور jq کمانڈز ہیں۔ یہی وجہ ہے کہ یہ CI میں کام کرتے ہیں۔ ایک regex یا تو میچ کرتا ہے یا نہیں کرتا۔ ایک JSON schema یا تو ویلیڈیٹ کرتا ہے یا ایرر دیتا ہے۔ Promptfoo معیاری Unix exit codes واپس کرتا ہے، اس لیے GitHub Actions قدرتی طور پر سمجھ جاتا ہے کہ مرج کب روکنا ہے۔ یہ language-agnostic ہے کیونکہ یہ ایک CLI ٹول کے طور پر کام کرتا ہے۔ آپ کو صرف آؤٹ پٹس کو ویلیڈیٹ کرنے کے لیے Node.js سروس ریپو کے اندر Python ecosystem انسٹال کرنے کی ضرورت نہیں ہے۔
DeepEval، جو Apache 2.0 کے تحت لائسنس یافتہ ہے، Python ٹیموں کے لیے بہترین انتخاب ہے۔ یہ pytest کی طرح انٹیگریٹ ہوتا ہے۔ آپ جانی پہچانی سنٹیکس میں ٹیسٹ لکھتے ہیں، اور ناکامی قدرتی طور پر سوٹ کو بلاک کر دیتی ہے۔ DeepEval میٹرکس کا ایک بہت بڑا کیٹلاگ پیش کرتا ہے، لیکن اہم تفصیل یہ ہے کہ آپ کو انہیں احتیاط سے استعمال کرنا ہوگا۔ گیٹس کے لیے یقینی (deterministic) یا ہیورسٹک (heuristic) میٹرکس پر بھروسہ کریں۔ اگر آپ G-Eval یا دیگر جج پر مبنی اسکوررز استعمال کر رہے ہیں، تو انہیں سخت اسسرٹس (hard asserts) کے بجائے غیر بلاکنگ رپورٹ جنریٹرز میں لپیٹ کر رکھیں۔ اس طرح استعمال کرنے پر، DeepEval آپ کو ریسرچ نوٹ بک کی غیر مستقل مزاجی کے بغیر ایک ٹیسٹنگ فریم ورک کی سہولت فراہم کرتا ہے۔
باقی چار فریم ورکس کہاں فٹ بیٹھتے ہیں
وہ چار فریم ورکس جو گیٹس کے طور پر زندہ نہیں رہ سکے، ان کی اہمیت اب بھی برقرار ہے۔ وہ بس آپ کے ٹول چین (toolchain) میں کہیں اور فٹ بیٹھتے ہیں۔
Future AGI (Apache 2.0) پچاس سے زیادہ میٹرکس فراہم کرتا ہے اور ان ٹیموں کو نشانہ بناتا ہے جو کسٹم SDKs بنا رہی ہیں۔ یہ میٹرکس مکمل ہیں۔ مسئلہ یہ ہے کہ یہ ٹول آپ سے توقع کرتا ہے کہ آپ اسے CI کیو (queue) میں چلانے کے لیے اپنا خود کا ہارس (harness) لکھیں۔ تحقیقی تناظر میں، یہ ایک مناسب سودا ہے۔ لیکن مرج کیو (merge queue) میں، کسٹم وائرنگ کی ہر تہہ عدم استحکام کا ایک نیا ذریعہ بنتی ہے۔ یہ ایک قابلِ عمل ایویلیوایشن انجن ہے، لیکن تیار گیٹ کیپر (gatekeeper) نہیں ہے۔
RAGAS (Apache 2.0) ریٹریول آگمینٹڈ جنریشن (retrieval-augmented generation) کے معیار کی پیمائش کرنے میں مہارت رکھتا ہے۔ اس کے faithfulness اور answer relevance میٹرکس یہ سمجھنے کے لیے واقعی مفید ہیں کہ ایک نالج بیس وقت کے ساتھ کیسی کارکردگی دکھاتی ہے۔ بدقسمتی سے، یہ میٹرکس LLM ججز پر بہت زیادہ انحصار کرتے ہیں۔ یہ رات کے وقت ہونے والے کوالٹی ٹاسک کے لیے بہترین ہیں جو Slack پر رجحانات (trends) پوسٹ کرتا ہے۔ لیکن یہ پل ریکویسٹ (pull request) کے لیے اچھے باؤنسر نہیں ہیں۔ RAGAS کو اپنے شیڈول شدہ تجزیاتی پائپ لائن (analysis pipeline) میں رکھیں، نہ کہ اپنے مرج بلاکرز (merge blockers) میں۔
Arize Phoenix ایلاسٹک لائسنس 2.0 (Elastic License 2.0) کے تحت ہے اور یہ بالکل ایک مختلف مقام پر ہے۔ یہ ڈسٹریبیوٹڈ ٹریسنگ (distributed tracing) کو ایویلیوایشن کے ساتھ جوڑتا ہے، جس سے آپ کو یہ سمجھنے میں مدد ملتی ہے کہ ایک ماڈل نے ایک خاص طریقے سے کیوں برتاؤ کیا۔ آپ کو اس کی ضرورت تب ہوتی ہے جب آپ پروڈکشن کے کسی واقعے کی ڈی بگنگ (debugging) کر رہے ہوں یا کسی ہالوسینیشن (hallucination) کی وجہ کسی غلط ریٹریول چنک (retrieval chunk) تک تلاش کر رہے ہوں۔ آپ یہ نہیں چاہتے کہ کوئی ٹریسنگ ٹول یہ فیصلہ کرے کہ ایک جونیئر ڈویلپر کی فیچر برانچ شپ (ship) ہو سکتی ہے یا نہیں۔ اس کا آرکیٹیکچر بصیرت (insight) کے لیے بنایا گیا ہے، بائنری گیٹس (binary gates) کے لیے نہیں۔
MLflow Evaluate (Apache 2.0) اپنی روایت تجرباتی ٹریکنگ (experiment tracking) سے لیتا ہے۔ یہ بھاری ہے۔ اسے ایک ہلکی (lean) CI امیج میں شامل کرنے سے اسٹارٹ اپ وقت اور ایسی وابستگیوں (dependencies) کا اضافہ ہوتا ہے جو ہر کام کو سست کر دیتی ہیں۔ اگر آپ کو اسے کسی پائپ لائن کے اندر استعمال کرنا ہی ہے، تو اس کے ہیورسٹک میٹرکس (heuristic metrics) کو صرف اسٹرکچرل چیکس کے لیے استعمال کریں۔ اس کے باوجود، آپ فریم ورک کے بنیادی ڈیزائن کے خلاف لڑ رہے ہوں گے۔ MLflow رنز کو لاگ کرنے اور ہفتوں تک تجربات کا موازنہ کرنے کے لیے بنا ہے۔ جبکہ ایک مرج کیو (merge queue) کو ایک منٹ سے بھی کم وقت میں فیصلہ چاہیے۔
عملی اصول (Practical Rules for Gating)
اگر آپ اس تجربے سے کچھ اور نہ بھی سیکھیں، تو یہ تین اصول ضرور یاد رکھیں۔
پہلا، وائب (vibe) کے بجائے اسٹرکچر (structure) کو گیٹ کریں۔ آپ اس بات کو یقینی بنا سکتے ہیں کہ آؤٹ پٹ ایک درست JSON ہے۔ آپ اس بات کو یقینی بنا سکتے ہیں کہ اس میں مطلوبہ کیز (keys) موجود ہیں۔ آپ اس بات کو یقینی بنا سکتے ہیں کہ کلاسیفیکیشن لیبل ایک منظور شدہ enum سے تعلق رکھتا ہے۔ یہ چیکس تیز، سستے اور یقینی (deterministic) ہوتے ہیں۔ آپ یہ یقینی طور پر نہیں کہہ سکتے کہ کوئی خلاصہ "دوستانہ" ہے یا کوئی دوبارہ لکھا گیا متن "تخلیقی" ہے۔ یہ خوبیاں انسانی جائزے یا وقتاً فوقتاً ہونے والے بیچ ایویلیوایشن (batch evaluation) کے لیے ہیں، خودکار گیٹس کے لیے نہیں۔
دوسرا، اگر تبدیل نہ ہونے والے ان پٹ پر اسکور بدل جائے، تو اسے فوری طور پر نیچا دکھائیں۔ اپنے ایویلیوایشن سویٹ (evaluation suite) کو بالکل اسی آرٹفیکٹ (artifact) کے خلاف دو بار چلائیں۔ اگر کوئی میٹرک پاس سے فیل ہو جاتا ہے، تو اس نے مرج کو روکنے کا حق کھو دیا ہے۔ اسے ایک مشاورتی ڈیش بورڈ (advisory dashboard) پر منتقل کر دیں جہاں تغیر (variance) متوقع اور قابلِ قبول ہو۔
تیسرا، ایگزٹ کوڈ (exit code) کا احترام کریں۔ سرخ بینر والی ایک خوبصورت HTML رپورٹ مرج کو نہیں روکتی۔ ایک نان زیرو (nonzero) ایگزٹ کوڈ روکتا ہے۔ آپ کے ایویلیوایشن ٹول کو آپ کے CI پلیٹ فارم کی مقامی زبان بولنی چاہیے۔ اسٹینڈرڈ آؤٹ (Standard out) انسانوں کے لیے ہے۔ ایگزٹ کوڈز مشینوں کے لیے ہیں۔
خلاصہ (The Takeaway)
ہم ابھی LLM سے چلنے والی ایپلی کیشنز کے ٹیسٹنگ کے طریقے سمجھنے کے ابتدائی مراحل میں ہیں۔ ترغیب یہ ہوتی ہے کہ ایویلیوایشن کو انسانی گریڈنگ کے معیار کی طرح سمجھا جائے: باریک بین، سیاق و سباق کے مطابق، اور تھوڑا سا موضوعی (subjective)۔ یہ ایک تحقیقی مقالے میں تو کام کرتا ہے، لیکن مرج کیو (merge queue) میں ناکام ہو جاتا ہے۔
آٹھ ماہ کے پروڈکشن ٹریفک کے بعد، میری پائپ لائن اب مختلف سروسز میں اسٹرکچرل اور اسکیمہ اسرشنز (structural and schema assertions) کے لیے Promptfoo چلاتی ہے، اور پائتھن سائیڈ کے بیہیویئرل چیکس (behavioral checks) کے لیے DeepEval استعمال کرتی ہے جو آسانی سے پاس-فیل کی شرائط پر پورا اترتے ہیں۔ باقی سب کچھ رات کے ڈیش بورڈز پر رپورٹ ہوتا ہے۔ کیو مستحکم ہے۔ سگنل صاف ہے۔ ٹیم اب دوبارہ ریڈ بلڈ (red build) پر بھروسہ کرتی ہے۔
آپ کو اپنے گیٹ پر مزید میٹرکس کی ضرورت نہیں ہے۔ آپ کو کم میٹرکس کی ضرورت ہے جو ہر بار سچ بتائیں۔
اس تحریر کی بنیاد Dev.to پر شیئر کیے گئے اصل ٹیسٹنگ اور تحریر پر ہے۔ قابلِ اعتماد AI سسٹمز بنانے کے بارے میں مزید بات چیت کے لیے، Telegram پر GyaanSetu کمیونٹی میں شامل ہوں۔