AWS نے اپنی Bedrock سروس میں query-aware compression کا اضافہ کیا ہے، جس سے ڈویلپرز لینگویج ماڈل تک پہنچنے سے پہلے غیر متعلقہ دستاویز کے ٹکڑوں (chunks) کو کم کر سکتے ہیں۔ ماڈل تک بھیجے جانے والے ٹوکنز کی تعداد کم کر کے، یہ فیچر Retrieval-Augmented Generation (RAG) پائپ لائنز کے لیے کمپیوٹ بل کو کم کر سکتا ہے۔

RAG پائپ لائنز پر اخراجات کیوں بڑھ جاتے ہیں

RAG سسٹم پہلے نالج بیس سے متن کے اقتباسات (passages) نکالتے ہیں، پھر صارف کے سوال کا جواب دینے کے لیے ان اقتباسات کو ایک جنریٹیو ماڈل کو فراہم کرتے ہیں۔ زیادہ تر implementations میں حاصل کردہ ہر ٹکڑے کو براہ راست ماڈل کو بھیج دیا جاتا ہے، چاہے متن کا بڑا حصہ سوال سے بالکل بھی متعلق نہ ہو۔ ہر اضافی لفظ ایک ٹوکن بن جاتا ہے، اور ماڈل جو بھی ٹوکن پروسیس کرتا ہے وہ بنیادی API کے چارجز میں اضافہ کرتا ہے۔ ان چھوٹی اور درمیانی درجے کی کمپنیوں کے لیے جو سپورٹ بوٹس یا اندرونی سرچ ٹولز چلاتی ہیں، ٹوکن کا خرچ خود ماڈل کالز کی لاگت پر تیزی سے غالب آ سکتا ہے۔

Query-aware compression کیا کرتی ہے

Bedrock کی یہ نئی صلاحیت ریٹریول (retrieval) اور جنریشن (generation) کے درمیان ایک فلٹرنگ مرحلہ شامل کرتی ہے:

  • سسٹم اب بھی کسی بھی کوئری کے لیے دستاویزات کا وہی سیٹ نکالتا ہے۔
  • ماڈل کے کسی بھی متن کو دیکھنے سے پہلے، ایک ہلکا پھلکا پروسیسر (lightweight processor) ہر اقتباس کا مخصوص سوال کے ساتھ جائزہ لیتا ہے۔
  • صرف وہی حصے رکھے جاتے ہیں جنہیں متعلقہ قرار دیا جاتا ہے؛ باقی سب کو غیر ضروری معلومات (noise) سمجھ کر نکال دیا جاتا ہے۔

آپ کو کسی نئے انڈیکس (index)، ایمبیڈنگ ماڈل (embedding model)، یا فائن ٹیونڈ لینگویج ماڈل کی ضرورت نہیں ہے۔ یہ تبدیلی محض پائپ لائن کو اس طرح دوبارہ ترتیب دینا ہے کہ کمپریشن لیئر کو استعمال کیا جا سکے۔

کاروباری اثرات

چونکہ ماڈل کو بھیجے جانے والے متن کی مقدار کے ساتھ ٹوکن فیس بڑھتی ہے، اس لیے غیر متعلقہ ٹکڑوں کو ہٹانے سے بل میں لائن بہ لائن کمی آ سکتی ہے۔ وہ کمپنیاں جن کے RAG اخراجات استعمال بڑھنے کے ساتھ ساتھ تیزی سے بڑھ رہے ہیں، انہیں اس کا سب سے زیادہ فائدہ ہوگا۔

آگے کیا دیکھنا ہے

  • اپنے ڈیٹا پر فیچر کا پائلٹ ٹیسٹ کریں: ایک معیاری RAG فلو اور query-aware compression والے فلو کا آمنے سامنے ٹیسٹ کریں۔ ٹوکن کی تعداد، لیٹنسی (latency)، اور جواب کی مطابقت کو ناپیں۔
  • وینڈر کی شفافیت: تھرڈ پارٹی RAG پلیٹ فارمز کا جائزہ لیتے وقت، یہ پوچھیں کہ آیا وہ اپنی ریٹریول پائپ لائنز میں کمپریشن یا فلٹرنگ کا استعمال کرتے ہیں۔ ایسا وینڈر جو خام ٹکڑے (raw chunks) بھیجتا ہے، اس کے ماہانہ انوائس زیادہ ہونے کا امکان ہے۔

خلاصہ

پائپ لائن میں ایک معمولی تبدیلی—ماڈل تک پہنچنے سے پہلے غیر متعلقہ متن کو فلٹر کرنا—ایک چھپے ہوئے خرچے کو ایک قابلِ کنٹرول اخراجات میں بدل سکتی ہے۔ وہ تنظیمیں جو پہلے سے Bedrock پر مبنی RAG کے لیے ادائیگی کر رہی ہیں، ان کے لیے query-aware compression کو فعال کرنا ایک کم محنت والا تجربہ ہے، لیکن کسی بھی قسم کی بچت آپ کے مخصوص ڈیٹا پر منحصر ہوگی۔