آپ کا RAG پائپ لائن ایک معیاری لوڈ ٹیسٹ کو بڑی کامیابی سے پاس کر لیتا ہے۔ p95 لیٹنسی (latency) صحت مند نظر آتی ہے۔ ایرر ریٹس (error rates) تقریباً صفر کے قریب ہیں۔ پھر بھی صارفین ایسے جوابات کی اطلاع دیتے ہیں جو سوال سے کتراتے ہیں، ایسے دستاویزات کا حوالہ دیتے ہیں جو موجود ہی نہیں ہیں، یا چھ ماہ پہلے اپ لوڈ کیے گئے وائٹ پیپر سے غیر متعلقہ پیراگراف نکال لاتے ہیں۔ ڈیش بورڈ کہتا ہے کہ سب کچھ ٹھیک ہے، لیکن تجربہ بتاتا ہے کہ یہ خراب ہے۔

یہ فرق اس لیے ہے کیونکہ روایتی پرفارمنس ٹیسٹنگ ریکویسٹ-رسپانس (request-response) سسٹمز کے لیے بنائی گئی تھی، ان سسٹمز کے لیے نہیں جو سوچتے ہیں۔ جب آپ ایک REST اینڈ پوائنٹ پر ایک ہزار متوازی (parallel) ریکویسٹس بھیجتے ہیں، تو آپ کو یہ معلوم ہوتا ہے کہ آیا آپ کے سرورز قائم رہتے ہیں یا نہیں۔ آپ کو اس بارے میں کچھ معلوم نہیں ہوتا کہ آیا آپ کی ریٹریول لیئر (retrieval layer) صحیح ٹکڑے (chunks) نکال رہی ہے، آیا آپ کا پرامپٹ ٹیمپلیٹ (prompt template) سیاق و سباق کو برقرار رکھتا ہے، یا آیا ویکٹر اسٹور خالی ہونے پر ماڈل خود سے ذرائع ایجاد کر لیتا ہے۔ معیاری لوڈ ٹیسٹنگ رفتار کی پیمائش کرتی ہے۔ RAG ایپلی کیشنز یہ تقاضا کرتی ہیں کہ آپ سمجھ بوجھ (understanding) کی پیمائش کریں۔

اسٹیٹس کوڈ 200 سے آگے

ایک عام API لوڈ ٹیسٹ تین چیزیں چیک کرتا ہے: دستیابی (availability)، لیٹنسی (latency)، اور تھرو پٹ (throughput)۔ یہ پوچھتا ہے کہ آیا سرور نے جواب دیا، اس میں کتنا وقت لگا، اور یہ کتنے بیک وقت استعمال کرنے والے صارفین (concurrent users) کا مقابلہ کر سکا۔ ایک RAG ایپلی کیشن کے لیے، یہ نمبر بنیادی ضرورت ہیں، نتیجہ نہیں۔ ایک تیز غلط جواب اب بھی ایک غلط جواب ہی ہے، اور بڑے پیمانے پر غلط جوابات، سست جوابات کے مقابلے میں زیادہ مہنگے پڑتے ہیں۔

RAG ہر ریکویسٹ میں دو الگ مرحلے شامل کرتا ہے۔ پہلا، سسٹم صارف کے سوال کو ایک ایمبیڈنگ (embedding) میں تبدیل کرتا ہے، ایک ویکٹر اسٹور کو کوئری کرتا ہے، اور سیاق و سباق کے ٹکڑوں (context chunks) کا ایک سیٹ واپس لاتا ہے۔ دوسرا، یہ ان ٹکڑوں کو ایک پرامپٹ میں بھرتا ہے، سب کچھ ایک لینگویج ماڈل کو بھیجتا ہے، اور جواب (completion) کو اسٹریم کرتا ہے۔ روایتی ٹیسٹ اکثر ان سب کو ایک واحد "رسپانس ٹائم" میٹرک میں سمو دیتے ہیں۔ وہ ریٹریول انجن اور جنریٹر کو ایک ہی بلیک باکس (black box) کے طور پر دیکھتے ہیں۔

آپ کو اس باکس کو کھولنا ہوگا۔ اگر آپ کا ویکٹر ڈیٹا بیس لوڈ کے تحت سست ہو جاتا ہے، تو ریٹریول لیٹنسی بڑھ جاتی ہے۔ LLM اب بھی تیزی سے جواب دے سکتا ہے، لیکن وہ جلدی میں حاصل کردہ ناقص سیاق و سباق کی بنیاد پر جواب دے رہا ہوتا ہے۔ متبادل کے طور پر، ویکٹر سرچ تیز رہتی ہے جبکہ LLM کی قطار (queue) پیچھے رہ جاتی ہے، جس سے 'ٹائم ٹو فرسٹ ٹوکن' (time-to-first-token) بڑھ جاتا ہے یہاں تک کہ صارفین چمکتے ہوئے کرسر کو گھورنے لگتے ہیں۔ ایک واحد اینڈ ٹو اینڈ ٹائمر دونوں ناکامیوں کو چھپا دیتا ہے۔

صرف ڈیٹا بیس نہیں، بلکہ ریٹریول (Retrieval) کا ٹیسٹ کریں

زیادہ تر ٹیمیں ایک تیز ویکٹر سرچ بینچ مارک چلاتی ہیں اور ریٹریول لیئر کا ٹیسٹ مکمل قرار دے دیتی ہیں۔ وہ بینچ مارک عام طور پر یہ ماپتا ہے کہ ڈیٹا بیس ایک منتخب کردہ کوئری کے لیے کتنی تیزی سے قریبی پڑوسیوں (nearest neighbors) کو واپس کرتا ہے۔ یہ شاذ و نادر ہی یہ ماپتا ہے کہ آیا وہ پڑوسی واقعی جواب پر مشتمل ہیں۔

لوڈ کے ساتھ ریٹریول کا معیار باریک انداز میں بدل جاتا ہے۔ متوازی دباؤ (concurrent pressure) کے تحت، approximate nearest neighbor انڈیکس، تنہائی میں کام کرنے کے مقابلے میں مختلف انداز میں برتاؤ کر سکتے ہیں۔ چنکنگ حکمت عملی (chunking strategies) جو نوٹ بک میں مکمل نظر آتی تھیں، جب دس ہزار دستاویزات ایک ہی ایمبیڈنگ اسپیس کے لیے مقابلہ کرتی ہیں تو وہ حدود کے پار سیاق و سباق کو ضائع کرنے لگتی ہیں۔ ایک کوئری جو پرسکون ماحول میں مثالی پیراگراف واپس کرتی ہے، وہ اس وقت ایک گمراہ کن مارکیٹنگ سلائیڈ سامنے لا سکتی ہے جب انڈیکس دوبارہ بن رہا ہو یا جب ریکویسٹ کے دباؤ میں میٹا ڈیٹا فلٹرنگ ختم ہو رہی ہو۔

اسے صحیح طریقے سے ٹیسٹ کرنے کے لیے، آپ کو ایک گراؤنڈ ٹروتھ (ground-truth) ڈیٹا سیٹ کی ضرورت ہے۔ ایسے سوالات تیار کریں جہاں آپ پہلے سے جانتے ہوں کہ کون سی معلوماتی دستاویزات ظاہر ہونی چاہئیں۔ ان سوالات کو مختلف کنکرنسی (concurrency) لیولز پر چلائیں اور چیک کریں کہ آیا متوقع ٹکڑے (chunks) ٹاپ-k نتائج میں شامل ہیں۔ صرف کوئری کے دورانیے کو نہیں، بلکہ ہٹ ریٹ (hit rate) کو ٹریک کریں۔ اگر آپ کے ٹاپ پانچ ٹکڑے اہم ذریعے کو مکمل طور پر چھوڑ دیتے ہیں، تو آپ کا ریٹریول پائپ لائن LLM کے جاگنے سے پہلے ہی ناکام ہو چکا ہے۔

آپ کو کناروں (edges) کا بھی اسٹریس ٹیسٹ کرنا چاہیے۔ ایسی کوئریز جمع کروائیں جن کا کارپس (corpus) میں کوئی جواب نہ ہو۔ ایسے مبہم سوالات جمع کروائیں جو متعدد ڈومینز سے تعلق رکھ سکتے ہوں۔ ایسے طویل سوالات جمع کروائیں جو آپ کے ایمبیڈنگ ماڈل کی ٹوکن لمٹ سے تجاوز کریں اور خاموشی سے کٹ (truncate) جائیں۔ دیکھیں کہ ریٹریول لیئر کیا واپس کرتی ہے۔ ہر صورت میں، گزرے ہوئے ملی سیکنڈز سے زیادہ ناکامی کا طریقہ کار (failure mode) اہمیت رکھتا ہے۔

جب ماڈل خاموشی سے گھٹتا ہے

ایک بار جب ٹکڑے LLM تک پہنچ جاتے ہیں، تو معیاری لوڈ ٹیسٹنگ جھوٹ بولنا جاری رکھتی ہے