بات چیت کے AI کی جانچ کیسے کریں: QA انجینئرز کے لیے ایک عملی رہنما

از /

جب میں نے پہلی بار بات چیت کی AI ٹیسٹنگ کے بارے میں سیکھنا شروع کیا تو ایک سوال مجھے پریشان کرتا رہا۔ متوقع نتائج کہاں ہیں؟

جیسا کہ میں روایتی سافٹ ویئر ٹیسٹنگ کر رہا تھا، میں مانوس نمونوں کا عادی ہو گیا۔

تقاضے آپ کو بتاتے ہیں کہ نظام کو کیا کرنا چاہیے۔ ٹیسٹ کیسز بنائیں، ان پٹ فراہم کریں، متوقع نتائج کی وضاحت کریں، ٹیسٹ چلائیں، اور حقیقی نتائج کا متوقع سے موازنہ کریں۔

مثال کے طور پر:

ٹیسٹ ان پٹ متوقع نتیجہ
درست لاگ ان درست صارف نام اور پاس ورڈ صارف لاگ ان
غلط لاگ ان غلط پاس ورڈ ایک غلطی کا پیغام ظاہر ہوتا ہے۔
API کی درخواست درست درخواست پے لوڈ متوقع جواب کے ساتھ HTTP 200

پھر میں نے بات چیت کی AI سیکھنا شروع کی۔ اچانک وہی نقطہ نظر صاف طور پر فٹ نہیں ہوا.

اگر آپ کسی AI ایجنٹ سے پوچھیں، "میں اپنا پاس ورڈ کیسے دوبارہ ترتیب دوں؟” یہ جواب دے سکتا ہے، "آپ لاگ ان پیج پر پاس ورڈ بھول گئے آپشن کا استعمال کرتے ہوئے اپنا پاس ورڈ دوبارہ ترتیب دے سکتے ہیں۔”

اگر آپ وہی سوال دوبارہ پوچھتے ہیں، تو آپ کو درج ذیل پیغام موصول ہو سکتا ہے: "لاگ ان اسکرین پر پاس ورڈ بھول گئے کو منتخب کریں اور اپنے رجسٹرڈ ای میل پر بھیجی گئی ہدایات پر عمل کریں۔”

اگرچہ الفاظ مختلف ہیں، دونوں جوابات بالکل قابل قبول ہیں۔ تو ہم کیسے جانچ سکتے ہیں کہ آیا صحیح جواب تبدیل ہوسکتا ہے؟

اس سوال نے بات چیت کے AI ٹیسٹنگ تک پہنچنے کا طریقہ بدل دیا۔

اس آرٹیکل میں، ہم ان جانچ کے شعبوں کو دیکھیں گے جو ہمیں سب سے اہم معلوم ہوئے ہیں کیونکہ ہم یہ سیکھتے ہیں کہ بات چیت کے نظام کیسے کام کرتے ہیں، اور آپ کو دکھائیں گے کہ AI ایجنٹوں پر روایتی QA تکنیکوں کو کیسے لاگو کیا جائے۔

انڈیکس

1. نیت سے شروع کریں، قطعی الفاظ سے نہیں۔

ان تین پیغامات پر غور کریں:

  1. "میں اپنا پاس ورڈ کیسے ری سیٹ کروں؟”

  2. "میں اپنے اکاؤنٹ تک رسائی حاصل نہیں کر سکتا۔”

  3. "میں اپنا پاس ورڈ بھول گیا ہوں۔”

وہ مختلف نظر آتے ہیں۔ تاہم، درخواست پر منحصر ہے، وہ سب ایک ہی بنیادی صارف کے مقصد کی نمائندگی کر سکتے ہیں۔

PASSWORD_RESET

بات چیت کے AI میں، صارف کے ذریعہ درج کردہ جملے اکثر ہوتے ہیں۔ لفظاس پیغام کا مقصد اس طرح بیان کیا جا سکتا ہے: مرضی.

یہ ایک اہم ٹیسٹنگ سوال پیدا کرتا ہے۔ کیا سسٹم ایک ہی ارادے کو سمجھ سکتا ہے جب صارف اسے مختلف طریقے سے ظاہر کرتا ہے؟

ایک سادہ ٹیسٹ سیٹ ہو گا:

لفظ متوقع ارادہ
میں اپنا پاس ورڈ بھول گیا ہوں۔ PASSWORD_RESET
میں اپنا پاس ورڈ کیسے تبدیل کروں؟ PASSWORD_RESET
میں اپنا اکاؤنٹ درج نہیں کر سکتا PASSWORD_RESET
براہ کرم میرا لاگ ان بحال کرنے میں میری مدد کریں۔ PASSWORD_RESET
میرا پاس ورڈ کام نہیں کرتا PASSWORD_RESET

آئیے ایک چھوٹی سی مثال دیکھتے ہیں۔

test_cases = [ 
          { "message": "I forgot my password", 
            "expected_intent": "PASSWORD_RESET", 
          }, 
          { "message": "How do I change my password?", 
            "expected_intent": "PASSWORD_RESET", 
          }, 
          { "message": "Can't get into my account",  
            "expected_intent": "PASSWORD_RESET", 
          }, 
]

for test in test_cases: 
    response = ai_agent.send(test["message"])
    assert response.intent == test["expected_intent"]

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

Input: "Can't get into my account"

Expected intent: PASSWORD_RESET Actual intent: PASSWORD_RESET

PASS

صاف ستھرے جملے پر ختم نہ کریں۔

حقیقی صارفین املا کی غلطیاں کرتے ہیں، مخففات استعمال کرتے ہیں، نامکمل معلومات فراہم کرتے ہیں، اور بعض اوقات صرف چند الفاظ ٹائپ کرتے ہیں۔

تو میں بھی ٹیسٹ کروں گا:

"میں اپنا پاس ورڈ بھول گیا ہوں”

"لاگ ان کرنے سے قاصر”

"پاس ورڈ مدد”

"یہ بند ہے”

یہیں سے بات چیت کی AI ٹیسٹنگ دلچسپ ہونے لگتی ہے۔ یہ جانچ نہیں کرتا کہ آیا نظام ایک پہلے سے طے شدہ جملے کو تسلیم کرتا ہے۔ ہم جانچ کر رہے ہیں کہ آیا ہم صارف کے اہداف میں تبدیلیوں کو سمجھتے ہیں۔

2. تمام جوابات کے لیے بالکل درست متن کا استعمال نہ کریں۔

پہلی عادات میں سے ایک جس پر مجھے دوبارہ غور کرنا پڑا وہ اپنے حقیقی اور متوقع رد عمل کا لفظ بہ لفظ موازنہ کرنا تھا۔

میں فرض کرتا ہوں کہ متوقع جواب ہے "آپ پاس ورڈ بھول گئے لنک کا استعمال کرکے اپنا پاس ورڈ دوبارہ ترتیب دے سکتے ہیں۔”

لیکن AI جواب دیتا ہے، "اپنے پاس ورڈ کو دوبارہ ترتیب دینا شروع کرنے کے لیے لاگ ان اسکرین پر بھولے ہوئے پاس ورڈ کو منتخب کریں۔”

عین مطابق سٹرنگ کا موازنہ ناکام ہو جاتا ہے۔ تاہم، صارف کے نقطہ نظر سے، جواب مکمل طور پر درست ہو سکتا ہے۔

ایک جملہ میں متوقع نتیجہ کی وضاحت کرنے کے بجائے: کچھ خاص صفات ہیں کہ ایک اچھے ردعمل میں شامل ہونا ضروری ہے:.

مثال کے طور پر، جواب ہونا چاہئے:

  • براہ کرم وضاحت کریں کہ پاس ورڈ دوبارہ ترتیب دینے کا عمل کیسے شروع کیا جائے۔

  • قابل عمل اگلے اقدامات فراہم کریں۔

  • صارفین سے اپنا پاس ورڈ ظاہر کرنے کو نہ کہیں۔

  • اپنے اکاؤنٹ کی معلومات کے ساتھ چھیڑ چھاڑ نہ کریں۔

  • پاس ورڈ کی بازیابی میں متعلقہ رہیں

اب ایک جیسے ہونے کے بغیر متعدد جوابات پاس کیے جا سکتے ہیں۔ یہ میرے لیے سب سے بڑی تبدیلیوں میں سے ایک تھی۔

تعییناتی ایپلی کیشنز کے لیے، متوقع پیداوار اکثر ایک قدر ہوتی ہے۔ بات چیت کے AI کے لیے، متوقع نتائج ہو سکتے ہیں: تشخیص کے معیار کا سیٹ.

3. متعدد جہتوں میں ردعمل کے معیار کا اندازہ لگائیں۔

درستگی اہم ہے، لیکن یہ صرف ایک چیز نہیں ہونی چاہیے۔ میرے خیال میں ردعمل کے معیار کو کئی جہتوں میں تقسیم کرنا مفید ہے۔

  1. درستگی: کیا معلومات درست ہے؟ اگر AI کسٹمر کو بتاتا ہے کہ وہ ای میل کے ذریعے اپنا پاس ورڈ دوبارہ ترتیب دے سکتے ہیں جب اصل عمل کے لیے انہیں سپورٹ سے رابطہ کرنے کی ضرورت ہوتی ہے، تو جواب ناکام ہو جائے گا، چاہے یہ قائل ہی کیوں نہ ہو۔

  2. مطابقت: کیا AI نے جواب دیا کہ صارف نے اصل میں کیا پوچھا؟ یہاں تک کہ اگر جواب درست معلومات پر مشتمل ہے، تب بھی یہ غیر متعلقہ ہو سکتا ہے۔

  3. مکملیت: کیا جواب میں وہ معلومات شامل ہیں جو صارف کو آگے بڑھنے کے لیے درکار ہیں؟

  4. وضاحت: کیا صارفین آپ کے جواب کو آسانی سے سمجھ سکتے ہیں؟

  5. افادیت: کیا جواب درحقیقت صارف کو اپنے مقاصد حاصل کرنے میں مدد کرتا ہے؟

یہاں ایک سادہ درجہ بندی کی روبرک ہے:

معیاری سکور
درستگی 0~2
مطابقت 0~2
مکملیت 0~2
وضاحت 0~2
افادیت 0~2
بندوق 0~10

اس کے بعد آپ اپنی درخواست کے لیے موزوں حد کی وضاحت کر سکتے ہیں۔

درست درجہ بندی کا طریقہ اہم حصہ نہیں ہے۔ اہم بات یہ ہے کہ "یہ جواب مجھے اچھا لگتا ہے” پر بھروسہ کرنے کے بجائے اپنے تشخیصی معیار کو واضح کریں۔

4. ٹیسٹ گفتگو کے ساتھ ساتھ جوابات

سنگل روٹیشن ٹیسٹ مفید ہیں، لیکن شاذ و نادر ہی صارفین مکمل طور پر الگ تھلگ سوالات کا استعمال کرتے ہوئے کسی AI ایجنٹ کے ساتھ بات چیت کرتے ہیں۔

درج ذیل گفتگو پر غور کریں:

صارف: مجھے اپنا پتہ اپ ڈیٹ کرنا ہے۔

AI عمل کی وضاحت کرتا ہے۔

پھر:

صارف: کیا میں اسے آن لائن کر سکتا ہوں؟

کیا "وہ” اوسط؟ دوسرا پیغام مکمل طور پر پہلے پیغام پر منحصر ہے۔

اب تصور کریں:

صارف: مجھے اپنا پتہ اپ ڈیٹ کرنا ہے۔

AI: پراعتماد میں آپ کی مدد کر سکتا ہوں۔

صارف: دراصل، اس سے پہلے، کیا آپ مجھے بتا سکتے ہیں کہ اگلی ادائیگی کب ہوگی؟

AI: اگلی ادائیگی کی تاریخ 15 ستمبر ہے۔

صارف: شکریہ اب واپس پتے پر۔

کیا نظام اپنے اصل موضوع پر واپس آسکتا ہے؟

یہ ایک مختلف قسم کا ٹیسٹ ہے۔

ایک ملٹی ٹرن ٹیسٹ سوٹ میں درج ذیل منظرنامے شامل ہونے چاہئیں:

اس کے نتیجے میں ٹیسٹنگ یونٹ میں تبدیلی آئی۔ کبھی کبھی آپ جواب کی جانچ کر رہے ہوتے ہیں، اور کبھی آپ پوری گفتگو کی جانچ کر رہے ہوتے ہیں۔

مثالوں میں شامل ہیں:

ai_agent.send("My order number is A10245")
response = ai_agent.send("When will it arrive?")

assert response.order_id == "A10245"

دوسرے پیغام میں آرڈر نمبر شامل نہیں ہے۔ یہ چیک اس بات کو یقینی بناتا ہے کہ AI ایجنٹ نے "میں کب پہنچوں گا؟” پر کارروائی کرنے کے بجائے پچھلے موڑ سے معلومات کو برقرار رکھا ہے۔ ایک غیر متعلقہ سوال پر۔

5. جانچیں کہ آیا AI آپ کی ترمیم کو سنبھال سکتا ہے۔

لوگ اپنی سوچ بدلتے ہیں اور غلطیاں کرتے ہیں۔

مثال کے طور پر:

صارف: میرا اکاؤنٹ نمبر 4567 پر ختم ہوتا ہے۔

پھر:

صارف: معذرت اس کا مطلب 4576 تھا۔

آگے کیا ہوتا ہے؟

نظام کو اصل اقدار کو برقرار رکھنے کے بجائے نظر ثانی شدہ معلومات کا استعمال کرنا چاہیے۔

یہی اصول دوسری گفتگو پر بھی لاگو ہوتا ہے۔

"میں بوسٹن کا سفر کر رہا ہوں۔”

اگلا ہے:

"حقیقت میں اسے شکاگو بنائیں۔”

یا:

’’مجھے جون کی رپورٹ چاہیے۔‘‘

اگلا ہے:

"مجھے افسوس ہے، جولائی۔”

یہ ایک مفید ٹیسٹ ہے کیونکہ یہ اس بات کو ظاہر کرتا ہے کہ آیا ایجنٹ واقعی بات چیت کے سیاق و سباق کو برقرار رکھتا ہے، یا صرف یہ سمجھے بغیر کہ کون سی معلومات موجودہ ہے معلومات جمع کر رہا ہے۔

6. ابہام کا امتحان

صارفین ہمیشہ کافی معلومات فراہم نہیں کرتے ہیں۔

تصور کریں کہ کوئی ٹائپ کرتا ہے "میں ایک تبدیلی کرنا چاہتا ہوں۔”

کیا تبدیلیاں؟ آپ کا پتہ کیا ہے؟ پاس ورڈ ادائیگی کا طریقہ؟ اطلاعات کو ترجیح دیں؟

ڈائیلاگ کا ناقص نظام آپ کو اندازہ لگاتا رہتا ہے۔ ایک بہتر شخص پوچھ سکتا ہے، "آپ کیا تبدیل کرنا چاہتے ہیں؟”

یہ ہمیں ٹیسٹ کے ایک اور اہم زمرے میں لے آتا ہے۔ وضاحتی کارروائی۔

جان بوجھ کر مبہم الفاظ بنائیں، جیسے:

اس کے بعد ہم اس بات کا جائزہ لیتے ہیں کہ آیا AI یہ تسلیم کرتا ہے کہ معلومات غائب ہے، غیر تعاون یافتہ مفروضوں سے گریز کرتا ہے، اور مناسب وضاحتی سوالات پوچھتا ہے۔

بعض اوقات بہترین AI جواب بالکل بھی جواب نہیں ہوتا، بلکہ صرف ایک اور سوال ہوتا ہے۔

7. جوابات کے پیچھے علم کی جانچ کریں۔

سب سے پہلے، ہم نے تقریباً پوری توجہ اس بات پر مرکوز رکھی کہ AI کیا کہہ رہا ہے۔ تب میں نے محسوس کیا کہ غلط جواب کا خود بخود مطلب یہ نہیں ہے کہ زبان کے ماڈل میں ہی کوئی مسئلہ ہے۔

سسٹمز نالج بیسز، سرچ سسٹمز، دستاویزات، APIs، یا انٹرپرائز ڈیٹا کے دیگر ذرائع استعمال کر سکتے ہیں۔

اگر وہ معلومات غلط، نامکمل، متضاد، یا پرانی ہے، تو AI غلط جوابات دے سکتا ہے چاہے ماڈل ڈیزائن کے مطابق کام کر رہا ہو۔

آئیے کہتے ہیں کہ سرکاری پالیسی بیان کرتی ہے: صارفین کے پاس پروڈکٹ واپس کرنے کے لیے 30 دن ہوتے ہیں۔ تاہم، ایک پرانے علمی مضمون میں کہا گیا ہے کہ صارفین کے پاس ایسا کرنے کے لیے 60 دن ہیں۔

اگر AI پرانے مضامین کو تلاش کرتا ہے اور اعتماد کے ساتھ "60 دن” کا جواب دیتا ہے، تو جواب غلط ہے۔

لیکن تفتیش اس کے ساتھ ختم نہیں ہونی چاہیے: "اے آئی ہیلوسینیٹ کر رہا تھا۔” جانچ کرنے والوں کو یہ تعین کرنے کی ضرورت ہے کہ غلط معلومات کہاں سے آ رہی ہیں۔

میں جن سوالات کی تحقیق کروں گا وہ یہ ہیں:

  • آپ نے اپنے جواب کے لیے کون سے ذرائع استعمال کیے؟

  • کیا ماخذ تسلیم شدہ ہے؟

  • کیا معلومات تازہ ترین ہیں؟

  • کیا متعدد ذرائع متضاد ہیں؟

  • کیا آپ کی تلاش نے صحیح دستاویزات واپس کی ہیں؟

  • کیا حتمی جواب بازیافت کی گئی معلومات کی درست نمائندگی کرتا ہے؟

یہ خاص طور پر ان سسٹمز میں اہم ہے جو Search Augmented Generation (RAG) کا استعمال کرتے ہیں۔

8. ہیلوسینیشن ٹیسٹ

سب سے اہم بات چیت کے AI ٹیسٹوں میں سے ایک حیرت انگیز طور پر آسان ہے۔ سسٹم سے پوچھیں کہ وہ کیا نہیں جانتا۔

فرض کریں کہ ایک اندرونی معاون معاون میں مصنوعات A، B، اور C کے لیے دستاویزات شامل ہیں۔ پوچھیں، "پروڈکٹ Z کے لیے منسوخی کی پالیسی کیا ہے؟”

پروڈکٹ Z موجود نہیں ہے۔

تو کیا ہونا چاہیے؟ نظام کی جانب سے اعتماد کے ساتھ منسوخی کی پالیسی وضع کرنے کا بدترین نتیجہ نکلے گا۔

آپ کی درخواست پر منحصر ہے، بہتر سلوک ہو سکتا ہے:

"پروڈکٹ Z کے بارے میں کوئی معلومات نہیں ہے۔”

یا:

"مجھے یہ معلومات نہیں مل رہیں۔ کیا آپ مجھے سپورٹ سے جوڑ سکتے ہیں؟”

ایک مفید ہیلوسینیشن ٹیسٹ سوٹ میں شامل ہونا چاہئے:

  • پروڈکٹ موجود نہیں ہے۔

  • جعلی پالیسی کا نام

  • خصوصیات تعاون یافتہ نہیں ہیں۔

  • جان بوجھ کر غلط مفروضہ

  • آپ کے علم کے دائرے سے باہر کے سوالات

  • ایسی معلومات کی درخواست کریں جو سسٹم میں دستیاب نہیں ہے۔

ہم جانچ کر رہے ہیں کہ آیا AI جانتا ہے کہ کب۔ ~ نہیں جواب

9. ٹیسٹ فال بیک آپریشن

ہر بات چیت کے نظام کو کچھ حاصل ہوتا ہے جسے وہ سمجھ نہیں پاتا ہے۔ لیکن اس کا لازمی مطلب یہ نہیں ہے کہ یہ ناکام ہو جائے گا۔

اہم سوال یہ ہے کہ آگے کیا ہوگا؟

مندرجہ ذیل منظر نامے کا تصور کریں:

صارف: مجھے ZXP کو ٹیون کرنے میں مدد کی ضرورت ہے۔

سسٹم "ZXP” کو نہیں پہچانتا۔

ایک برا فال بیک بار بار کہہ سکتا ہے "معذرت، میں سمجھ نہیں پایا۔” ایک بہتر متبادل یہ ہوگا: "کیا آپ مجھے اس بارے میں مزید بتا سکتے ہیں کہ ZXP اصلاح کا کیا مطلب ہے؟”

اگر سسٹم اب بھی آپ کی درخواست کو نہیں سمجھ سکتا، تو آپ کو دوسرا راستہ فراہم کرنے کی ضرورت پڑ سکتی ہے۔

فال بیک ٹیسٹ میں شامل ہونا چاہئے:

ہم یہ بھی جانچتے ہیں کہ متعدد ناکامیوں کے بعد کیا ہوتا ہے۔ AI ایجنٹوں کو صارفین کو "معذرت، میں سمجھ نہیں آیا” کے لامتناہی لوپ میں نہیں پھنسانا چاہیے۔

10. انسانی اضافہ کی جانچ

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

مندرجہ ذیل حالات پر غور کریں:

  • بار بار غلط فہمیاں

  • غیر تعاون یافتہ اکاؤنٹ کا مسئلہ

  • انسانوں کے لیے صارف کی درخواستیں۔

  • حساس ورک فلو

  • مستثنیات جو خود کار طریقے سے نہیں سنبھالے جا سکتے ہیں۔

اگر اضافہ آپ کے پروڈکٹ ڈیزائن کا حصہ ہے، تو پوری منتقلی کی جانچ کریں۔

مثال کے طور پر:

صارف: میں کسی سے بات کرنا چاہتا ہوں۔

کیا AI درخواست کو تسلیم کرتا ہے؟ کیا مکالمہ درست طریقے سے پیش کیا گیا ہے؟ کیا انسانی ایجنٹ کو متعلقہ گفتگو کی تاریخ ملتی ہے؟ کیا صارف کو سب کچھ دوبارہ بیان کرنا ہوگا؟ کیا AI بڑھنے کے بعد بھی جواب دینے کی کوشش جاری رکھے گا؟

یہاں تک کہ اگر منتقلی تکنیکی طور پر کامیاب ہے، تمام سیاق و سباق کو کھونے کے نتیجے میں اب بھی برا تجربہ ہو سکتا ہے۔

11. کسی دوسرے ایپلی کیشن کی طرح انٹیگریشن ٹیسٹنگ

بات چیت کے انٹرفیس پیچیدہ نظاموں کو آسان بنا سکتے ہیں۔

صارفین دیکھتے ہیں:

"میرے حکم کی کیا حیثیت ہے؟”

لیکن اس بیان کے بعد، ایجنٹ کر سکتا ہے:

  1. صارف کے ارادے کو سمجھیں۔

  2. گاہک کی تصدیق کریں۔

  3. API کال آرڈر کریں۔

  4. آرڈر کے لئے تلاش کریں

  5. ردعمل کی تشریح کریں

  6. قدرتی زبان کے جوابات تیار کریں۔

یہ وہ جگہ ہے جہاں جانچ کی روایتی تکنیکیں بہت اہم ہو جاتی ہیں۔

اگر API واپس آتا ہے:

{
  "order_id": "A10245",
  "status": "SHIPPED"
}

AI کو صارفین کو یہ نہیں بتانا چاہیے، "آپ کے آرڈر پر ابھی بھی کارروائی ہو رہی ہے۔”

اس انضمام کی توثیق کرنے کے لیے، آپ کو درج ذیل جانچنے کی ضرورت ہوگی:

  • درست API میپنگ

  • تصدیق ناکام ہوگئی

  • وقت ختم

  • خالی جواب

  • غلط جواب

  • خدمات دستیاب نہیں ہیں۔

  • غلط اسٹیٹس کوڈ

  • جزوی ڈیٹا

AI روایتی انضمام کی جانچ کو ختم نہیں کرتا ہے۔ اس کے اوپر ایک اور پرت شامل کریں۔

12. گولڈن ڈیٹا سیٹ بنانا

AI کیسے کام کرتا ہے یہ سیکھتے وقت دستی تحقیقاتی جانچ مفید ہے، لیکن آخرکار اسے دوبارہ قابلیت کی ضرورت ہوتی ہے۔ یہ جگہ گولڈن ڈیٹاسیٹ مفید ہو جاتا ہے۔

گولڈن ڈیٹا سیٹ نمائندہ ٹیسٹ ان پٹس اور متوقع رویے کا ایک کیوریٹڈ مجموعہ ہے جسے سسٹم میں تبدیلی کے ساتھ دوبارہ چلایا جا سکتا ہے۔

مثال کے طور پر:

ID صارف ان پٹ متوقع رویہ
INT-001 اپنا پاس ورڈ بھول گئے؟ پاس ورڈ دوبارہ ترتیب دینے کے ارادے کی شناخت کریں۔
INT-002 میں اپنے اکاؤنٹ تک رسائی حاصل نہیں کر سکتا اکاؤنٹ تک رسائی کے بہاؤ کو منتقل کریں۔
CTX-001 کیا میں اسے آن لائن کر سکتا ہوں؟ پچھلی گفتگو کے سیاق و سباق کو حل کریں۔
AMB-001 میں اسے تبدیل کرنا چاہتا ہوں۔ وضاحت طلب کریں۔
HAL-001 غیر موجود مصنوعات کے لیے پالیسی Z پالیسی نہ بنائیں
ESC-001 چلو کسی سے بات کرتے ہیں۔ بڑھانا شروع کریں۔
KB-001 واپسی کی مدت کیا ہے؟ قبول علم کے مطابق جواب دیں۔

اس کے بعد ہم ہر ایک اہم مقصد کو پیرا فریسز، ایج کیسز، منفی کیسز، اور متعدد منتقلی منظرناموں میں پھیلاتے ہیں۔

جب بھی اشارہ، علم، ماڈل، انضمام، یا ڈائیلاگ منطق میں تبدیلی آئے تو اپنے ڈیٹاسیٹ کو دوبارہ چلائیں۔

اب ہمارے پاس روایتی ریگریشن ٹیسٹنگ کے بہت قریب ہے۔

13. صرف پاسنگ ریٹ کی پیمائش نہ کریں۔

فرض کریں کہ آپ 1,000 گفتگو کا امتحان چلاتے ہیں اور 950 پاس کرتے ہیں۔ میرے خیال میں 95% پاس ہونے کی شرح اچھی ہے۔

لیکن ناکام کیا؟ 500 بے ضرر FAQ سوالات ملے؟ یا اکاؤنٹ کی حفاظت کے پانچ اہم منظرنامے؟

اکیلے پاس کی مجموعی شرح پوری کہانی نہیں بتاتی۔ آپ کی درخواست پر منحصر ہے، مفید میٹرکس میں شامل ہیں:

  • ارادے کی شناخت کی درستگی: صارف کے اہداف کو کتنی بار صحیح طور پر سمجھا جاتا ہے؟

  • تبدیلی کا تناسب: آپ کے پاس کتنی بار ایسا نظام ہے جو آپ کو نہیں سمجھتا؟

  • مکمل کام کا فیصد: صارفین کتنی بار کامیابی سے اپنا مطلوبہ کام انجام دیتے ہیں؟

  • ترقی کی کامیابی کی شرح: کیا منتقلی کامیاب تھی جب انسانی مدد کی ضرورت تھی؟

  • زمینی غلطی: قبول شدہ علم کے ساتھ ردعمل کا تضاد کتنی بار ہوا؟

  • سیاق و سباق کی خرابی: متعدد بات چیت کے دوران آپ کا سسٹم کتنی بار اہم معلومات کھو دیتا ہے؟

  • شدید فریب نظر: سسٹم نے کتنی بار اعتماد کے ساتھ غیر تعاون یافتہ معلومات فراہم کیں؟

صحیح میٹرک پروڈکٹ اور اس کے خطرات پر منحصر ہوگا۔ کسٹمر سروس کے اکثر پوچھے گئے سوالات بوٹس اور اے آئی سسٹمز جو مالیاتی فیصلوں کی حمایت کرتے ہیں ضروری نہیں کہ معیار کے ایک جیسے ہوں۔

14. خطرے پر مبنی گفتگو کا ٹیسٹ بنائیں

یہ ایک اور روایتی QA اصول ہے جو بہت اچھی طرح سے بات چیت کرتا ہے۔

تمام AI ناکامیوں کا ایک جیسا اثر نہیں ہوتا ہے۔ یہ تکلیف دہ ہوگی اگر AI نے عجیب و غریب جواب دیا "آپ کے کاروباری اوقات کیا ہیں؟”

اگر آپ ادائیگیوں، اکاؤنٹ کی حفاظت، طبی ہدایات یا مالیاتی پالیسیوں کے بارے میں غلط معلومات فراہم کرتے ہیں تو اس کا اثر بہت زیادہ ہو سکتا ہے۔

لہذا، خطرے کے لحاظ سے اپنے منظرناموں کی درجہ بندی کریں۔

مثال کے طور پر:

خطرہ ہاں ٹیسٹ کی ترجیح
کم عمومی سوالات عام
درمیانی اکاؤنٹ نیویگیشن اعلی
اعلی مالیاتی/اکاؤنٹ ایکشن بہت اعلی
تنقیدی سیکیورٹی/پرائیویسی کے برتاؤ رجعت کی ضرورت ہے

اس کے بعد ہم اپنی ریگریشن کوریج کو ایسے منظرناموں پر مرکوز کرتے ہیں جہاں AI کا ناقص رویہ سب سے زیادہ نقصان پہنچا سکتا ہے۔

15. عملی گفتگو سے متعلق AI ٹیسٹنگ کی حکمت عملی

اگر ہم نے آج بات چیت کے AI QA پر کام کرنا شروع کیا، تو ہم اسے درج ذیل پرتوں میں ترتیب دیں گے:

پرت 1: ارادے کی جانچ

کیا سسٹم سمجھ سکتا ہے کہ صارف کیا چاہتا ہے، یہاں تک کہ مختلف زبانوں میں بھی؟

ٹائر 2: ردعمل کی تشخیص

کیا آپ کے جوابات درست، متعلقہ، مکمل، واضح اور مفید ہیں؟

پرت 3: گفتگو کی جانچ

کیا نظام متعدد مثالوں میں سیاق و سباق کو برقرار رکھ سکتا ہے؟

پرت 4: علم اور بنیاد

کیا آپ کا جواب منظور شدہ، تازہ ترین معلومات سے تعاون یافتہ ہے؟

پرت 5: اسپیچ اور ہیلوسینیشن ٹیسٹنگ

کیا آپ کا سسٹم کافی معلومات نہ ہونے پر اعتماد سے جواب نہیں دیتا؟

ٹائر 6: اوور رائیڈز اور اسکیلیشنز

کیا آپ ٹھیک ہو سکتے ہیں جب سسٹم اسے نہیں سمجھتا ہے اور جب آپ کو ضرورت ہو تو اسے لوگوں کے حوالے کر سکتے ہیں؟

پرت 7: انٹیگریشن ٹیسٹنگ

کیا آپ کے APIs، توثیق، ڈیٹا بیس، اور ڈاؤن اسٹریم سسٹم درست طریقے سے کام کر رہے ہیں؟

پرت 8: ریگریشن ٹیسٹنگ

کیا آپ ماڈل، پرامپٹ، علم، یا درخواست میں تبدیلیوں کے بعد اہم اقدامات کو دوبارہ چلا سکتے ہیں؟

یہ آپ کی QA ٹیم کو صرف ایک چیٹ بوٹ کھولنے اور بے ترتیب سوالات پوچھنے سے کہیں زیادہ منظم نقطہ آغاز فراہم کرتا ہے۔

روایتی QA انجینئرز پہلے ہی AI ٹیسٹنگ میں کیا لاتے ہیں۔

جب میں نے پہلی بار بات چیت سے متعلق AI سیکھنا شروع کیا تو میں نے سوچا کہ مجھے روایتی ٹیسٹنگ کے بارے میں جو کچھ بھی معلوم تھا اسے بھول جانا پڑے گا۔ لیکن میں اب اس پر یقین نہیں کرتا۔

ہماری بہت سی موجودہ ٹیکنالوجیز بہت اچھی طرح سے منتقل ہوتی ہیں۔ ہم پہلے ہی جانتے ہیں کہ یہ کیسے کریں:

کیا تبدیلیاں متوقع نتائج کی تعریف ہے۔

کچھ AI منظرناموں کے لیے، متوقع نتائج یہ ہیں:

جواب =

اگلے کے قریب۔

A اور B سے گریز کرتے ہوئے جواب کو X، Y، اور Z کو مطمئن کرنا چاہیے۔

ایک بار جب میں ان اختلافات کو سمجھ گیا تو، بات چیت کی AI ٹیسٹنگ نے بہت زیادہ معنی حاصل کرنا شروع کردیئے۔

ختم

بات چیت کے AI سیکھتے وقت میں نے پہلی چیز جو محسوس کی وہ ٹیسٹ کیسز کی تلاش تھی۔

اب مجھے لگتا ہے کہ شروع کرنے کے لئے یہ غلط جگہ ہے۔ اپنے صارفین کے ساتھ شروع کریں۔

  • وہ کیا حاصل کرنے کی کوشش کر رہے ہیں؟

  • وہ اس کے علاوہ کیسے درخواست کر سکتے ہیں؟

  • AI کو کس معلومات کی ضرورت ہے؟

  • مفید جواب میں کیا شامل ہے؟

  • نظام کو کیا نہیں کہنا چاہیے؟

  • اگر AI نہیں جانتا ہے تو کیا ہوگا؟

  • جب گفتگو کا رخ بدلتا ہے تو کیا ہوتا ہے؟

  • کیا ثبوت آپ کو اس تجربے کو حقیقی صارفین کے ساتھ بانٹنے کے لیے کافی پر اعتماد بناتا ہے؟

یہ سوالات بالآخر ٹیسٹ کیس بن جاتے ہیں۔

بات چیت کا AI ان ایپلی کیشنز کے مقابلے میں کم فیصلہ کن ہو سکتا ہے جنہیں بہت سے QA انجینئرز جانچنے کے لیے استعمال کرتے ہیں۔ لیکن اس کا مطلب یہ نہیں ہے کہ اس کا تجربہ نہیں کیا جا سکتا۔ اس کا مطلب ہے کہ آپ کو صرف پوچھنے سے آگے بڑھنے کی ضرورت ہے:

"کیا مجھے بالکل وہی مل گیا جس کی میں نے توقع کی تھی؟”

اور سوال پوچھنا شروع کریں:

"کیا نظام نے درست طریقے سے، محفوظ طریقے سے، اور مفید طریقے سے مختلف طریقوں سے کارکردگی کا مظاہرہ کیا کہ حقیقی لوگ اس کے ساتھ تعامل کر سکتے ہیں؟”

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

متعلقہ پوسٹس

اوپر تک سکرول کریں۔