جب آپ مصنوعی ذہانت (AI) کے ساتھ کام شروع کرتے ہیں، تو سب سے زیادہ آوازیں ایک ہی چیز کی طرف اشارہ کرتی ہیں: ماڈل۔ وہ کہتے ہیں کہ صحیح ماڈل کا انتخاب کریں، اور باقی سب خود بخود ٹھیک ہو جائے گا۔ اپنے تجربات کے چند ہفتوں کے بعد، میں آپ کو بتا سکتا ہوں کہ یہ بات بالکل درست نہیں ہے۔ دستیاب لارج لینگویج ماڈلز (LLMs) میں سے انتخاب کرنا اہم ہے، لیکن یہ شاید کام کا صرف بیس فیصد حصہ ہے۔ باقی سب سسٹم کا کام ہے۔ یہ پائپنگ (plumbing)، مہارت اور مسلسل ٹیسٹنگ کا کام ہے۔ یہ احساس مجھے جلد ہو گیا، اور اس کے بعد سے میرے ہر پروجیکٹ کے کام کرنے کے انداز کو اس نے بدل کر رکھ دیا ہے۔
ماڈل تو محض ایک آغاز ہے
یہ سمجھنا آسان ہے کہ مبتدی (beginners) ماڈلز کے پیچھے کیوں پاگل ہوتے ہیں۔ ریلیز نوٹس بہتر استدلال (reasoning)، بڑے کانٹیکسٹ ونڈوز (context windows) اور صاف ستھرے آؤٹ پٹ کا وعدہ کرتے ہیں۔ یہ بہتری حقیقی ہے، لیکن یہ عمومی مقصد (general-purpose) کے لیے ہے۔ ایک جدید ترین ماڈل خود بخود آپ کی کمپنی کی ریفنڈ پالیسی نہیں جان سکے گا۔ جب تک آپ اسے نہ بتائیں، یہ آپ کی موبائل ایپ کے لیے جوابات کو قابل اعتماد طریقے سے فارمیٹ نہیں کرے گا۔ یہ ہوا میں سے لائیو انوینٹری ڈیٹا نہیں نکال سکتا۔
میں نے یہ مشکل تجربے سے سیکھا۔ میرا پہلا پروٹو ٹائپ ایک قابل ماڈل استعمال کرتا تھا اور خوبصورت، پراعتماد پیراگراف تیار کرتا تھا جو کبھی کبھی مکمل طور پر غلط ہوتے تھے۔ متن پیشہ ورانہ لگتا تھا کیونکہ ماڈل نے لہجہ (tone) سیکھ لیا تھا، لیکن اس کی تازہ معلومات تک رسائی نہیں تھی۔ میں نے ماڈل کے بینچ مارکس (benchmarks) کا موازنہ کرنے میں کئی دن گزار دیے جبکہ مجھے ڈیٹا پائپ لائنز اور کانٹیکسٹ انجیکشن (context injection) کے بارے میں سوچنا چاہیے تھا۔ ماڈل خراب نہیں تھا۔ اس کے گرد بنا ہوا سسٹم نامکمل تھا۔ جب آپ ڈیمو سے ایسے سافٹ ویئر کی طرف بڑھتے ہیں جس پر لوگ حقیقت میں بھروسہ کرتے ہیں، تو یہ فرق ہی سب کچھ ہوتا ہے۔
پرامپٹس کوڈ ہیں، محض مشورے نہیں
اعلیٰ معیار کے پرامپٹس (prompts) کسی بھی قابل اعتماد AI ایپلی کیشن کی بنیاد ہوتے ہیں۔ شروع میں، میں پرامپٹس کو سرچ کوئریز (search queries) کی طرح سمجھتا تھا—مختصر، غیر رسمی اور پرامید۔ میں ماڈل سے "اس کا خلاصہ کریں" یا "مددگار بنیں" کہتا اور بہترین نتائج کی امید کرتا۔ نتائج مفید اور غیر متعلقہ کے درمیان تیزی سے بدلتے رہتے تھے، اور مجھے اندازہ نہیں تھا کہ ایسا کیوں ہو رہا ہے۔
اب میں پرامپٹس کو ہلکے پھلکے پروگراموں کی طرح لیتا ہوں۔ ایک اچھا پرامپٹ کردار (role) کا تعین کرتا ہے، آؤٹ پٹ کا فارمیٹ بتاتا ہے، ضرورت پڑنے پر مثالیں شامل کرتا ہے، اور حدود مقرر کرتا ہے۔ اگر مجھے JSON چاہیے، تو میں JSON مانگتا ہوں اور اس کا اسکیما (schema) دکھاتا ہوں۔ اگر مجھے مختصر جواب چاہیے، تو میں واضح طور پر لمبائی کی حد مقرر کرتا ہوں اور تمہید (preamble) پر پابندی لگا دیتا ہوں۔ بار بار دہرانا (iteration) اہم ہے۔ میں پرامپٹس اور ان کے آؤٹ پٹ کا ایک لاگ (log) رکھتا ہوں، اور ایک وقت میں صرف ایک متغیر (variable) تبدیل کرتا ہوں۔ پرامپٹ میں ایک مبہم صفت (adjective) پورے ورک فلو (workflow) کے رویے کو بدل سکتی ہے۔ یہ حساسیت سختی اور درستگی کا تقاضا کرتی ہے، اندازوں کا نہیں۔
غلط ڈیٹا، غلط نتیجہ (Garbage In, Garbage Out)
قابل اعتماد ڈیٹا کی واپسی (data retrieval) وہ جگہ ہے جہاں بہت سے AI پروجیکٹس خاموشی سے ناکام ہو جاتے ہیں۔ Retrieval-Augmented Generation، یا RAG، ماڈلز کو نجی یا موجودہ ڈیٹا تک رسائی دینے کا معیاری طریقہ بن گیا ہے۔ خیال سادہ ہے: متعلقہ دستاویزات حاصل کریں، انہیں ماڈل کے کانٹیکسٹ ونڈو میں ڈالیں، اور ماڈل کو حقائق پر غور کرنے دیں۔ لیکن عملی طور پر یہ کام زیادہ پیچیدہ ہے۔
میں نے ایک سادہ نالج بیس (knowledge base) کی غلطیاں درست کرنے میں وقت گزارا جو مسلسل غیر متعلقہ نتائج دے رہا تھا۔ ماڈل ٹھیک تھا۔ ریٹریول لیئر (retrieval layer) ناکام ہو رہی تھی۔ میرے چنکس (chunks) بہت چھوٹے تھے اور ان میں کانٹیکسٹ نہیں تھا۔ میرے ایمبیڈنگز (embeddings) ڈپلیکیٹ ہیڈرز کو صاف کیے بغیر تیار کیے گئے تھے۔ سم러لٹی سرچ (similarity search) نے تکنیکی طور پر قریب ترین متن تلاش کیا جس نے غلط سوال کا جواب دیا۔ اسے ٹھیک کرنے کا مطلب چنکنگ اسٹریٹیجی پر دوبارہ غور کرنا، میٹا ڈیٹا فلٹرز شامل کرنا، اور ری-رینکنگ (re-ranking) کا مرحلہ متعارف کروانا تھا۔ جب ریٹریول مستحکم ہو گیا، تو ماڈل کے جوابات فوری طور پر بہتر ہو گئے۔ سبق واضح تھا: آپ ایک بہتر ماڈل کے ذریعے خراب ڈیٹا ریٹریول کو ٹھیک نہیں کر سکتے۔ آپ کو پائپ لائن کو صحیح طریقے سے بنانا ہوگا۔
آپ اسے بہتر نہیں بنا سکتے جسے آپ ناپتے نہیں
مسلسل جانچ پڑتال (evaluation) وہ عادت ہے جو تجربات کو مصنوعات سے الگ کرتی ہے۔ جب میں نے شروع کیا، تو میں صرف مجموعی تاثر (vibe) کی بنیاد پر جانچ کرتا تھا۔ میں پانچ آؤٹ پٹ پڑھتا، سر ہلاتا اور آگے بڑھ جاتا۔ یہ تب تک کام کرتا ہے جب تک کوئی صارف چھٹا سوال نہ پوچھے اور اسے کچھ عجیب و غریب جواب نہ ملے۔
اب میں ہر فیچر کے لیے چھوٹے ایویلیوایشن سیٹس (evaluation sets) بناتا ہوں۔ میں صارفین کے حقیقی سوالات جمع کرتا ہوں، متوقع رویے کی نشاندہی کرتا ہوں، اور ان کے خلاف خودکار چیک (automated checks) چلاتا ہوں۔ میں 'ڈرفٹ' (drift) پر نظر رکھتا ہوں: ایک پرامپٹ جو پچھلے مہینے کام کر رہا تھا، ماڈل کی اپ ڈیٹ یا بنیادی ڈیٹا میں تبدیلی کے بعد خراب ہو سکتا ہے۔ میں اسٹائل کی جانچ کو حقائق کی درستگی سے الگ رکھتا ہوں۔ پیشہ ورانہ نظر آنا اچھا ہے؛ لیکن درست ہونا لازمی ہے۔ اس لوپ (loop) کے بغیر، آپ صرف امید کے سہارے کام کر رہے ہیں، اور امید کوئی ٹیسٹنگ اسٹریٹیجی نہیں ہے۔
مشین کی حدود کو جانیں
ماڈل کی حدود کو سمجھنے نے مجھے حد سے زیادہ وعدے کرنے اور توقعات پر پورا نہ اترنے سے بچایا ہے۔ ان سسٹمز کی حقیقی حدود ہوتی ہیں۔ کانٹیکسٹ ونڈوز (Context windows) پہلے کے مقابلے میں بڑی ہو گئی ہیں، لیکن ان کی بھی ایک حد ہے، اور انہیں مکمل طور پر بھر دینے سے کارکردگی متاثر ہوتی ہے۔ ماڈلز غلط معلومات (hallucinate) دیتے ہیں، خاص طور پر ان مخصوص موضوعات پر جہاں ٹریننگ ڈیٹا کم ہو۔ انہیں درست حساب کتاب اور بعض اقسام کے کثیر مرحلہ وار منطق (multi-step logic) میں دشواری ہوتی ہے۔ وہ الفاظ کے چناؤ کے حوالے سے حساس ہوتے ہیں۔
لاگت اور رفتار بھی حدود ہیں۔ ایک ایسا ماڈل جو دس سیکنڈ میں بہترین نثر تیار کرتا ہے، وہ ریئل ٹائم چیٹ انٹرفیس میں ناقابل استعمال ہو سکتا ہے۔ اب میں فیچرز کو شروع میں ہی لیٹنسی بجٹ (latency budgets) کے مطابق ترتیب دیتا ہوں۔ اگر کسی کام کے لیے ایک سیکنڈ سے بھی کم وقت میں جواب چاہیے، تو میں جوابات کو پہلے سے تیار (precompute) کر سکتا ہوں، کیشنگ (cache) کا بھرپور استعمال کر سکتا ہوں، یا پہلے ڈرافٹ کے لیے ایک چھوٹا ماڈل اور صرف بہتری کے لیے ایک بڑا ماڈل استعمال کر سکتا ہوں۔ حدود کے اندر رہ کر کام کرنا ایک معیاری انجینئرنگ ہے۔ AI بھی اس سے مختلف نہیں ہے۔
حقیقی لوگوں کے لیے تعمیر کرنا
میں اس وقت ایک سادہ مقصد کے ساتھ LLM ایپلی کیشنز اور سافٹ ویئر انجینئرنگ کا مطالعہ کر رہا ہوں: ایسے ٹولز بنانا جو لوگ روزانہ استعمال کریں۔ یہ بات بظاہر سادہ لگتی ہے، لیکن ایک بہترین پروٹو ٹائپ اور روزانہ استعمال ہونے والے ٹول کے درمیان فرق بہت زیادہ ہے۔ ایک ڈیمو میں چالیس سیکنڈ کا وقفہ اور طویل جواب برداشت کیا جا سکتا ہے۔ لیکن ایک ایسا شخص جو میٹنگ سے پہلے اپنا کام ختم کرنے کی کوشش کر رہا ہو، وہ ایسا نہیں کر سکتا۔
روزانہ استعمال ہونے والے ٹولز کو ایرر ہینڈلنگ (error handling)، فال بیکس (fallbacks)، اور ماڈل کے غیر یقینی ہونے کی صورت میں واضح UI کی ضرورت ہوتی ہے۔ انہیں نئے ورک فلو (workflows) مسلط کرنے کے بجائے موجودہ ورک فلو کے ساتھ ضم ہونے کی ضرورت ہوتی ہے۔ اب میں ایج کیسز (edge cases) کے بارے میں سوچتا ہوں: جب ماڈل جواب دینے سے انکار کر دے، جب کانٹیکسٹ اوور فلو ہو جائے، یا جب API ٹائم آؤٹ ہو جائے تو کیا ہوگا؟ AI سافٹ ویئر لانچ کرنے کا مطلب صرف پرامید ہونا نہیں بلکہ ان سوالات کے جواب کوڈ کے ذریعے دینا ہے۔
آئیے جو ہم سیکھتے ہیں اسے شیئر کریں
میں دوسرے ڈویلپرز کے ساتھ جڑنا چاہتا ہوں جو اسی راستے پر چل رہے ہیں۔ یہ شعبہ تیزی سے آگے بڑھ رہا ہے، اور بہترین طریقے (best practices) ابھی لکھے جا رہے ہیں۔ کسی کے پاس بھی تمام جوابات نہیں ہیں۔ چاہے آپ پرامپٹ ڈیزائن (prompt design) کے ساتھ جدوجہد کر رہے ہوں، ریٹریول پائپ لائنز (retrieval pipelines) سے لڑ رہے ہوں، یا بڑے پیمانے پر آؤٹ پٹس کا جائزہ لینے کا طریقہ ڈھونڈ رہے ہوں، ان مسائل کو مل کر بہتر طریقے سے حل کیا جا سکتا ہے۔
آئیے جو ہم سیکھتے ہیں اسے شیئر کریں۔ کانفرنسوں کی چمک دمک والی گفتگو نہیں، بلکہ وہ الجھا ہوا درمیانی مرحلہ۔ وہ ٹوٹے ہوئے پائپ لائنز، وہ پرامپٹ کی تبدیلیاں جنہوں نے آخر کار کام کیا، وہ ایویلیوایشن ٹیسٹ جنہوں نے لانچ سے پہلے بگ (bug) پکڑ لیا۔ یہی باریک بینی اور ایماندارانہ تبادلہ خیال ہے جو انفرادی تجربات کو علم کے ایک مشترکہ ذخیرے میں بدل دیتا ہے۔
اصل حاصلِ کلام
اگر آپ AI ڈویلپمنٹ کا آغاز کر رہے ہیں، تو اس کی تلاش میں کم وقت صرف کریں