تکرار اور تشخیص: درستگی، latency، خرچ، اطمینان

تین طریقے

1. 1

   چار میٹرکس زیادہ تر LLM نظاموں کا احاطہ کرتے ہیں۔ درستگی: آؤٹ پُٹ متوقع جواب سے ملتا ہے؟ FBR خلاصے کے لیے ماہر یہ پرکھے کہ ہر خلاصہ flagged irregularities صحیح پہچانتا ہے۔ Latency: درخواست سے جواب کا وقت؟ Interactive ٹولز کے لیے 95ویں فیصد کے تحت تین سیکنڈ ہدف۔ Batch ٹولز کے لیے کاروباری دن کی حد۔ خرچ: فی کال PKR، روزانہ ٹریک، drift پر الرٹ۔ اطمینان: ہر آؤٹ پُٹ کے بعد صارف کا ایک ٹیپ سکور۔ ہر میٹرک ضروری؛ کوئی اکیلا کافی نہیں۔ تیز سستا کم درست ٹول بے کار۔ مکمل ٹول جو دس لاکھ روزانہ لے، ناقابلِ برداشت۔

2. 2

   Eval set بنانا۔ 50 سے 100 اصل ان پُٹ سے شروع کریں جو آپ کے نظام کی ضرورت کے تنوع کا احاطہ کریں۔ FBR کیس کے لیے: دس happy paths، دس edge cases (نامکمل ڈیٹا، مبہم رقمیں)، دس دشمنانہ (مخلوط زبان، خراب PDFs)، دس high-impact (زیادہ revenue والے filers جہاں غلط جواب مہنگا)، دس اردو غالب۔ ہر ان پُٹ کے لیے متوقع رویہ یا تو ماہر کا gold-standard reference output، یا must-have حقائق کی checklist۔ یہ سیٹ زندہ دستاویز ہے؛ ہر بار جب اصل صارف ناکامی پکڑے، یہ بڑھتا ہے۔

3. 3

   تین تشخیصی طریقے۔ Domain ماہر کا دستی جائزہ سونے کا معیار مگر مہنگا اور سست۔ Pairwise ماڈل جج: ایک دوسرا LLM آؤٹ پُٹ کا reference سے موازنہ کر کے اسکور دے۔ سستا، تیز، مگر تعصبات رکھتا ہے جنہیں ماپا جائے۔ تیسرا production میٹرکس: thumbs-up/down کا تناسب، وقت کی بچت، نیچے کی غلطی۔ تینوں ملا کر استعمال ہوں۔ ایک چھوٹا ڈیش بورڈ بنائیں جو eval set اور production پر چاروں میٹرکس ہر prompt یا ماڈل کی تبدیلی پر دکھائے۔ یہی ماہانہ governance میٹنگ کی دستاویز۔

کیوں؟

Claude کے ساتھ آزمائیں

Claude یا ChatGPT کے ساتھ آزمانے کے لیے پرامپٹ: 'Python میں ایسا evaluation harness بنائیں جو میرا 50 ان پُٹ والا CSV Claude Sonnet سے چلائے، چاروں میٹرکس (LLM judge سے درستگی، ms میں latency، PKR میں خرچ، صارف کا thumb) پکڑے، اور موجودہ run کا پچھلے سے موازنہ کر کے ایک Markdown رپورٹ لکھے۔ کوڈ اور Markdown ٹیمپلیٹ دونوں دیں۔ تبصرے اردو میں۔' چلائیں، آڈٹ کریں، بہتر کریں۔