ایک قابل اعتماد AI سسٹم کیسے بنایا جائے۔

ہم سب وہاں جا چکے ہیں۔ چیٹ جی پی ٹی کھولیں اور پرامپٹ جاری کریں۔ "اس شیٹ سے تمام ای میلز نکالیں اور جذبات کے مطابق ترتیب دیں۔” یہ آپ کو کچھ قریب دیتا ہے۔ اگر ہم اسے ٹھیک کر دیتے ہیں تو ہم معذرت خواہ ہوں گے اور نیا ورژن فراہم کریں گے۔ آپ ایک مختلف فارمیٹ طلب کرتے ہیں اور اچانک آپ کا تمام سابقہ ​​سیاق و سباق ختم ہو جاتا ہے اور آپ دوبارہ شروع کر رہے ہیں۔

اس طرح کی خرابیاں چھوٹے کاموں کے لیے ٹھیک ہو سکتی ہیں، لیکن یہ پیداواری نظام کے لیے تباہ کن ہیں۔ "اس نے میری ChatGPT بات چیت میں کام کیا” اور "یہ پروڈکشن میں قابل اعتماد طریقے سے چلتا ہے” کے درمیان فرق بہت بڑا ہے۔ یہ کسی بہتر پیغام کے ساتھ بند نہیں ہوتا ہے۔ بند ہونے کے اوقات درج ذیل ہیں: انجینئرنگ

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

جو آپ سیکھیں گے۔

اس ٹیوٹوریل میں آپ سیکھیں گے کہ کیسے:

• سمجھیں کہ AI سسٹم روایتی سافٹ ویئر سے مختلف کیوں ناکام ہو جاتے ہیں۔

• پروڈکشن AI کے لیے تین اہم ناکامی کے طریقوں کی شناخت اور روکیں۔

• مسلسل آؤٹ پٹ کے لیے validator سینڈوچ پیٹرن کو لاگو کریں۔

• مناسب نگرانی اور انتباہ کے ساتھ قابل مشاہدہ پائپ لائنیں بنائیں

• شرح کو محدود کرنے اور سرکٹ بریکرز کے ذریعے بڑے پیمانے پر لاگت کا کنٹرول

• ایک مکمل، پروڈکشن کے لیے تیار AI فن تعمیر کو ڈیزائن کریں۔

شرطیں

اس ٹیوٹوریل سے زیادہ سے زیادہ فائدہ اٹھانے کے لیے، آپ کو ضرورت ہوگی:

• کسی بھی پروگرامنگ زبان کی بنیادی سمجھ

• REST API اور غیر مطابقت پذیر پروگرامنگ کا علم

• کم از کم ایک LLM API (OpenAI، Anthropic، یا اس سے ملتا جلتا) استعمال کرنے کا تجربہ کریں۔

• مقامی طور پر انسٹال کردہ Node.js (اختیاری، کوڈ کی مثالیں چلانے کے لیے)

آپ کو ان میں سے کسی میں ماہر ہونے کی ضرورت نہیں ہے۔ انٹرمیڈیٹ کا علم کافی ہے۔

انڈیکس

1. کیا AI سسٹم کو بنیادی طور پر مختلف بناتا ہے۔

2. ناکامی موڈ #1: غیر متضاد آؤٹ پٹ

3. ناکامی موڈ #2: خاموش ناکامی۔

4. ناکامی موڈ #3: لاگت قابو سے باہر ہے۔

5. ایک مکمل پروڈکشن آرکیٹیکچر کیسے بنایا جائے۔

6. نتیجہ

کیا AI سسٹم کو بنیادی طور پر مختلف بناتا ہے۔

روایتی سافٹ ویئر ہے۔ فیصلہ کن. تم لکھو if (urgency > 8) { return 'high' } یہ ہر بار بالکل ایسا ہی کرتا ہے۔ وہی ان پٹ، وہی آؤٹ پٹ۔ ہمیشہ کے لیے آپ یونٹ ٹیسٹ لکھ سکتے ہیں جو تمام راستوں کا احاطہ کرتے ہیں۔ تمام ناکامی کے طریقوں کی پیش گوئی کی جا سکتی ہے۔

دوسری طرف، اے آئی سسٹمز امکانی. جب آپ کسی بڑے لینگویج ماڈل (LLM) سے فوری طور پر درجہ بندی کرنے کے لیے کہتے ہیں، تو کبھی یہ کہتا ہے "ہائی”، کبھی یہ کہتا ہے "ارجنٹ”، کبھی یہ آپ کو 1 سے 10 کا اسکور دیتا ہے، اور کبھی یہ ایک پیراگراف لکھتا ہے جس کی وجہ بتائی جاتی ہے۔ ایک ہی ان پٹ، درجہ حرارت کی ترتیب، ماڈل ورژن، سیاق و سباق کی کھڑکی، اور عوامل پر منحصر مختلف آؤٹ پٹ آپ کے قابو سے باہر ہیں۔

حقیقت میں یہ ہے:

چیلنج	موجودہ نظام	اے آئی سسٹم
مستقل مزاجی	100% دوبارہ پیدا کرنے کے قابل	درخواست پر منحصر ہے۔
ڈیبگنگ	اسٹیک ٹریس، لاگ	"ماڈل نے ابھی اپنا طرز عمل بدلا ہے۔”
ٹیسٹ	یونٹ ٹیسٹ تمام راستوں کا احاطہ کرتے ہیں۔	تمام ممکنہ نتائج کی جانچ کرنا ممکن نہیں ہے۔
تعیناتی	ایک بار تعینات کریں اور یہ ہمیشہ کام کرے گا۔	وقت کے ساتھ کارکردگی میں کمی (ڈیٹا بڑھے)
ناکامی موڈ	متوقع، محدود	تخلیقی، لامحدود

انجینئرنگ چیلنجز میں شامل ہیں: آپ موروثی غیر متوقع صلاحیت کے اوپر اعتبار کیسے پیدا کرتے ہیں؟

جواب یہ نہیں ہے کہ "بہتر ماڈل استعمال کریں۔” ماڈل شاید 20% حل ہیں۔ باقی 80% اس کے ارد گرد بنایا گیا ایک نظام ہے۔

ناکامی موڈ #1: غیر متضاد آؤٹ پٹ

مسئلہ

AI سے سپورٹ ٹکٹس سے کسٹمر کی ای میلز نکالنے کو کہیں۔ کبھی کبھی آپ کو ایک ای میل واپس بھی مل سکتا ہے۔ کبھی کبھی آپ کو صرف نام معلوم ہوتا ہے۔ کچھ معاملات میں، آپ کو ایک فون نمبر مل سکتا ہے۔ فارمیٹ ہر بار بدلتا ہے۔ ایک ہی پرامپٹ، مختلف آؤٹ پٹ۔

Prompt: "Extract the customer email from this support ticket"

Output on Monday:    "john@example.com"
Output on Tuesday:   "Customer email: john@example.com (verified)"
Output on Wednesday:   "John Doe"
Output on Thursday: {
                       "customer_info": {
                         "email": "john@example.com"
                       }
                     }

تینوں آؤٹ پٹ صحیح معلومات پر مشتمل ہیں، لیکن پروگرام کے لحاظ سے تجزیہ نہیں کیا جا سکتا۔ جوابی اعداد و شمار میں مستقل مزاجی کی کمی کی وجہ سے ٹکٹوں کو روٹ کرنا، ورک فلو سسٹم کو متحرک کرنا، یا دوسرے کوڈ کے ساتھ ضم کرنا ناممکن ہو جاتا ہے۔

حل: تصدیق کنندہ سینڈوچ پیٹرن

توثیق کرنے والا سینڈوچ پیٹرن (جسے گارڈریل پیٹرن بھی کہا جاتا ہے) ڈیٹرمنسٹک کوڈ کی دو پرتوں کے درمیان AI کو سینڈویچ کرتا ہے، اس بات کو یقینی بناتا ہے کہ AI سسٹم غلط ڈیٹا تیار یا اس پر کارروائی نہیں کرتا ہے۔

بنیادی طور پر تین پرتیں ہیں:

1. بہترین روٹی: ان پٹ گارڈریل (تعیناتی)

2. گوشت: ایل ایل ایم (ممکنہ)

3. نیچے کی روٹی: آؤٹ پٹ گارڈریل (تعیناتی)

آئیے ہر پرت کو توڑتے ہیں۔

اوپر نمبر: ان پٹ گارڈریل

کسی بھی چیز کے AI کو چھونے سے پہلے اس کی تصدیق کریں۔ ردی کو فوری طور پر مسترد کریں اور تیزی سے اور سستے میں ناکام ہوجائیں۔ ذیل میں ڈیٹرمنسٹک کوڈ کے ساتھ ایک بنیادی مثال ہے جو موصول ہونے والے ڈیٹا کی تصدیق کرتی ہے۔

function validateTicketInput(raw): TicketInput {
  // Type checks
  if (!raw.email || typeof raw.email !== "string") {
    throw new ValidationError("Missing or invalid email");
  }

  // Format checks
  if (!isValidEmail(raw.email)) {
    throw new ValidationError(`Invalid email format: ${raw.email}`);
  }

  // Range checks
  if (!raw.body || raw.body.length < 10) {
    throw new ValidationError("Ticket body too short to classify");
  }

  if (raw.body.length > 10000) {
    throw new ValidationError("Ticket body exceeds max length");
  }

  // Return typed, validated input
  return {
    email: raw.email.toLowerCase().trim(),
    subject: raw.subject?.trim() || "No subject",
    body: raw.body.trim(),
    timestamp: new Date(raw.timestamp),
  };
}

یہ LLM بلانے سے پہلے چلتا ہے۔ یہ تیز، سستا اور فیصلہ کن ہے۔ آسان ناکامیوں کو فوری طور پر پکڑیں۔

گوشت: ایل ایل ایم کے سٹرکچرڈ نتائج

AI سے مفت متن نہ پوچھیں۔ ہم اسے اسکیما میں مجبور کرتے ہیں۔ زیادہ تر جدید APIs اس کی براہ راست حمایت کرتے ہیں۔

تو "مفت متن” کا کیا مطلب ہے؟ اگر آپ بغیر کسی رکاوٹ کے LLM کی درخواست کرتے ہیں تو غیر ساختہ قدرتی زبان واپس کر دی جائے گی۔ ماڈل فارمیٹ کا تعین کرتا ہے۔ کبھی کبھی یہ ایک جملہ ہوتا ہے، کبھی یہ پیراگراف ہوتا ہے، اور بعض اوقات یہ اضافی سیاق و سباق شامل کرتا ہے جس کی درخواست نہیں کی گئی تھی۔ اس سے پروگراماتی تجزیہ تقریباً ناممکن ہو جاتا ہے۔

دوسری طرف، اسکیما کو مجبور کرنے کا مطلب ہے ماڈل کو واضح طور پر بتانا، مثال کے طور پر، "صرف JSON کے ساتھ جواب دینا جو اس عین ساخت سے میل کھاتا ہے۔” اس کو نافذ کرنے کے لیے تازہ ترین LLM API میں بلٹ ان فعالیت ہے۔ آپ نہیں چاہتے کہ AI جواب کو صحیح طریقے سے فارمیٹ کرے، جس سے ساختی طور پر کسی اور چیز کو واپس کرنا ناممکن ہو جائے۔

اصل میں فرق یہ ہے:

کوئی اسکیما نفاذ نہیں (مفت متن):

const response = await openai.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [{
    role: "user",
    content: "Classify this support ticket as bug, billing, or feature request: " + ticketText
  }]
});

// Response could be:
// "This appears to be a billing issue"
// "billing"
// "Category: Billing (confidence: high)"
// { "type": "billing" }  <- if you're lucky

اسکیما کا اطلاق کریں:

const response = await openai.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [{
    role: "user",
    content: "Classify this support ticket: " + ticketText
  }],
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "ticket_classification",
      strict: true,
      schema: {
        type: "object",
        properties: {
          category: {
            type: "string",
            enum: ["bug", "billing", "feature", "other"]
          },
          confidence: {
            type: "number",
            minimum: 0,
            maximum: 1
          },
          priority: {
            type: "integer",
            minimum: 1,
            maximum: 5
          }
        },
        required: ["category", "confidence", "priority"],
        additionalProperties: false
      }
    }
  }
});

// Response is GUARANTEED to be:
// { "category": "billing", "confidence": 0.89, "priority": 2 }

کہ response_format پیرامیٹر ماڈل کو درست JSON آؤٹ پٹ کرنے پر مجبور کرتا ہے جو اسکیما سے میل کھاتا ہے۔ اگر یہ ایسا کرنے سے قاصر ہے تو، API اندرونی طور پر دوبارہ کوشش کرتا ہے جب تک کہ وہ ایسا نہ کرے۔ آپ کو ہر بار قابل قیاس، قابل تجزیہ ڈیٹا ملتا ہے۔

اہم فرق یہ ہے کہ ہم AI کو اس کے مطابق بنا رہے ہیں: آپ کا اس امید کے بغیر فارمیٹ کریں کہ یہ صحیح کام کرے گا۔

نیچے والا بن: آؤٹ پٹ گارڈریل

یہ سب سے اہم پرت ہے۔ LLM hallucinating ہو جائے گا. یہ پرت ڈیٹا بیس کو خراب کرنے یا صارف کو الجھانے سے پہلے ان فریب کو پکڑ لیتی ہے۔

گارڈریلز توثیق کے چیک ہیں جو LLM کے جواب کے بعد چلتے ہیں۔ اسے ہائی وے پر ایک حفاظتی رکاوٹ سمجھیں۔ ہو سکتا ہے کہ یہ گاڑی کو چلنے سے نہ روکے، لیکن یہ اسے سڑک پر جانے سے روک سکتا ہے۔

اے آئی سسٹمز میں، گارڈریلز اس بات کو یقینی بناتے ہیں کہ:

1. آؤٹ پٹ متوقع اسکیما سے میل کھاتا ہے۔

2. ڈیٹا کی قسم درست ہے۔

3. قدر قابل قبول حد کے اندر آتی ہے۔

4. کاروباری منطق سمجھ میں آتی ہے۔

بہت اچھا اب آپ کے پاس ایک منظم جواب ہے۔ اب اسے استعمال سے پہلے فعال طور پر توثیق کرنے کی ضرورت ہے۔

function validateClassification(raw): Classification {
  const required = ["category", "confidence", "priority", "reasoning"];
  for (const field of required) {
    if (raw[field] === undefined || raw[field] === null) {
      throw new ValidationError(`Missing required field: ${field}`);
    }
  }

  if (!["bug", "billing", "feature", "other"].includes(raw.category)) {
    throw new ValidationError(`Invalid category: ${raw.category}`);
  }

  if (typeof raw.confidence !== "number" || 
      raw.confidence < 0 || raw.confidence > 1) {
    throw new ValidationError(`Invalid confidence: ${raw.confidence}`);
  }

  if (!Number.isInteger(raw.priority) || 
      raw.priority < 1 || raw.priority > 5) {
    throw new ValidationError(`Invalid priority: ${raw.priority}`);
  }

  if (raw.category === "billing" && raw.priority > 3) {
    logger.warn("Suspicious: billing classified as low priority", raw);
  }

  return raw as Classification;
}

فعال طور پر توثیق کرنے کا مطلب ہے ہر چیز کی جانچ کرنا، نہ صرف اسکیما کی تعمیل۔ ہم چیک کر رہے ہیں:

• اسکیما کی تعمیل: کیا آپ کے JSON میں صحیح فیلڈز ہیں؟

• محفوظ ٹائپ کریں: کیا "ٹرسٹ" درحقیقت ایک عدد ہے نہ کہ تار؟

• رینج کی درستگی: کیا اعتبار 0 اور 1 کے درمیان ہے، -5 یا 999 کے درمیان نہیں؟

• کاروباری منطق: کیا فیلڈز کا یہ مجموعہ آپ کے ڈومین کے لیے موزوں ہے؟

• اعتماد کی حد: کیا AI واقعی اس جواب میں پراعتماد ہے؟

اگر توثیق ناکام ہوجاتی ہے، غلط ڈیٹا خود بخود قبول نہیں ہوتا ہے۔ تین اختیارات ہیں:

1. براہ کرم ایک واضح پیغام کے ساتھ دوبارہ کوشش کریں۔: ماڈل سے سخت ہدایات کے ساتھ دوبارہ کوشش کرنے کو کہیں۔

2. انسانی جائزے کی طرف بڑھیں۔: ناکامی کو لاگ کریں اور اسے جائزہ کی قطار میں لے جائیں۔

3. متبادل استعمال: ایک محفوظ ڈیفالٹ لوٹاتا ہے جس پر انسانی توجہ کی ضرورت ہے۔

تعییناتی اصول

یہاں مذہبی طور پر عمل کرنے کے اصول ہیں:

اگر آپ اسے if بیان سے حل کر سکتے ہیں، تو AI استعمال نہ کریں۔

ای میل فارمیٹ کی توثیق؟ ریگولر ایکسپریشنز کا استعمال کریں۔ تاریخ کا تجزیہ؟ تاریخ کی لائبریری کا استعمال کریں۔ کیا آپ چیک کر رہے ہیں کہ آیا سٹرنگ میں کلیدی لفظ ہے؟ سٹرنگ کا طریقہ استعمال کریں۔ ریاضی اصلی ریاضی کا استعمال کریں۔

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

ناکامی موڈ #2: خاموش ناکامی۔

مسئلہ

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

درستگی بڑھنے پر غور کریں۔ ماڈل کو 2024 سے ڈیٹا پر تربیت دی گئی تھی۔ اب یہ 2026 کے وسط میں ہے۔ فراہم کنندہ نے انوائس کی شکل تبدیل کر دی ہے۔ درجہ بندی کی درستگی 95% سے گر کر 71% رہ گئی۔ آپ کو اس وقت تک پتہ نہیں چلے گا جب تک آپ اپنا سہ ماہی آڈٹ نہیں کر لیتے۔ اور تب تک، ہزاروں ریکارڈ غلط طریقے سے ہینڈل ہو چکے تھے۔

اصول سادہ ہے۔ آپ اسے ٹھیک نہیں کر سکتے جو آپ نہیں دیکھ سکتے۔

حل: قابل مشاہدہ پائپ لائن

ہر پروڈکشن اے آئی سسٹم میں پہلے دن سے ہی مشاہداتی ہونا ضروری ہے۔ پیداواری نظام میں یہ کیسے ہوتا ہے:

اوپر دیے گئے خاکے میں:

1. ان پٹ کی آمد: صارف کی درخواستیں (سپورٹ ٹکٹ، دستاویزات، سوالات) آتی ہیں۔ درخواست کی شناخت، ٹائم اسٹیمپ، یوزر آئی ڈی، اور ان پٹ ہیش (ڈپلیکیٹس کو ہٹانے کے لیے) ریکارڈ کریں۔

2. ایل ایل ایم پروسیسنگ: درخواست AI ماڈل کو جاتی ہے۔ یہ کال کردہ ماڈل کو ریکارڈ کرتا ہے، اس میں کتنا وقت لگا (دیر)، استعمال شدہ ٹوکنز کی تعداد، لاگت، اور اہم ٹرسٹ سکور۔

3. اعتماد کا دروازہ: یہاں روٹنگ کا تعین کریں۔

   • اعلی وشوسنییتا (>0.8): خود بخود عمل کرتا ہے اور اعمال کو انجام دیتا ہے۔

   • درمیانی اعتبار (0.6-0.8):انسانی جائزہ کی قطار میں بھیجیں۔

   • کم وشوسنییتا (<0.6): فوری اضافہ + اطلاع

4. نگرانی ڈیش بورڈ: یہ تمام ڈیٹا ایک مشاہداتی ٹول میں جاتا ہے جو وقت کے ساتھ رجحانات کو ٹریک کرتا ہے۔

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

کیا پیمائش کریں اور کیوں:

میٹرک نظام	یہ کیوں ضروری ہے؟
ردعمل کا وقت	API کی حیثیت، ماڈل کے مسائل
ایمان	ماڈل کی تنزلی
انسانی اوور رائڈ کی شرح	آؤٹ پٹ کوالٹی کے مسائل
غلطی کی شرح	نظام کی خرابی
لاگت فی درخواست	بجٹ کنٹرول
ٹوکن کے استعمال کے رجحانات	تیز رفتار کارکردگی

مقصد انسانوں کو لوپ سے ہٹانا نہیں ہے۔ انسانوں کو صرف اس وقت شامل کریں جب نظام واقعی غیر یقینی ہو۔

ناکامی موڈ #3: لاگت قابو سے باہر ہے۔

مسئلہ

10 ٹکٹوں کے ساتھ اپنے ورک فلو کی جانچ کریں۔ یہ بہت اچھا کام کرتا ہے اور اس کی قیمت 50 سینٹ ہے۔ پیداوار میں تعینات کریں۔ API تک 1,000 درخواستیں پہنچ گئیں۔ بل: $500 فی دن۔

یا آپ نے اپنا دوبارہ کوشش کرنے کا لوپ غلط لکھا ہے۔ لامحدود API کالز تیار کرتا ہے۔ بل: $5,000 فی دن۔

یا، آپ ہر کام کے لیے سب سے مہنگا ماڈل استعمال کر رہے ہیں، یہاں تک کہ آسان کام جو ایک سستا ماڈل ہینڈل کر سکتا ہے۔

حقیقت: "10 درخواستوں کے لیے کام کرتا ہے۔" ≠ "10,000 درخواستوں کے لیے کام کرتا ہے۔" پیمانہ سب کچھ بدل دیتا ہے۔

حل: سرکٹ بریکر کے ساتھ گیٹڈ پائپ لائن

کمزور پروٹو ٹائپس سے مضبوط پروڈکشن سسٹمز کی طرف جانے کے لیے صارف کے ان پٹ کو براہ راست LLM API سے باندھنے کے سادہ انداز کو ترک کرنے کی ضرورت ہے۔ اس کے بجائے گیٹ پائپ لائن.

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

اوپر کی تصویر میں، یہ دروازے ہیں:

1. رفتار محدود کرنے والا

2. کیشے چیک کریں۔

3. درخواست کی قطار

4. سرکٹ بریکر

آئیے ہر ایک پر ایک نظر ڈالیں۔

گیٹ 1: شرح کی حد

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

گیٹ 2: کیشے چیک کریں۔

سب سے سستی LLM API کالز وہ ہیں جن پر آپ کو کال کرنے کی بالکل بھی ضرورت نہیں ہے۔ بہت سی AI درخواستیں دہرائی جانے والی یا بہت ملتی جلتی ہیں۔ جارحانہ طریقے سے کیش کریں۔

گیٹ 3: قطار کی درخواست کریں۔

LLM API معیاری REST API سے مختلف ہے۔ درخواستوں کو مکمل ہونے میں اکثر 10 سے 30 سیکنڈ لگتے ہیں۔ اگر 500 صارفین ایک ہی وقت میں "جمع کروائیں" کو دباتے ہیں، تو آپ سرور کو کریش کیے بغیر یا فراہم کنندہ کی ہم آہنگی کی حدود کو مارے بغیر 500 کنکرنٹ کنکشن نہیں کھول سکیں گے۔ درخواست کی قطاریں درخواستوں کو بیچ کر اور کنٹرول شدہ شرح پر ان پر کارروائی کرکے اس مسئلے کو حل کرتی ہیں۔

گیٹ 4: سرکٹ بریکر

عارضی نیٹ ورک کے مسائل کے لیے دوبارہ کوشش کی منطق ضروری ہے، لیکن اصل بندش کے دوران تباہ کن ہے۔ اگر آپ کا LLM فراہم کنندہ ڈاون ٹائم کا سامنا کر رہا ہے اور 500 خرابیاں واپس کر رہا ہے، تو پھر سے کوشش کرنے والے سادہ لوپس آپ کے API کو پاگلوں کی طرح خراب کر دیں گے، ناکام درخواستوں پر پیسہ ضائع کر دیں گے۔

گیٹ پائپ لائن کو کیسے لاگو کریں۔

ذیل میں ایک مثال پر عمل درآمد ہے جس میں دکھایا گیا ہے کہ چاروں دروازے ایک ساتھ کام کر رہے ہیں۔

مرحلہ 1: ریٹ محدود کرنے والا (ریڈیس کا استعمال کرتے ہوئے)

import { RateLimiterRedis } from "rate-limiter-flexible";
import Redis from "ioredis";

const redis = new Redis({
  host: process.env.REDIS_HOST,
  port: 6379
});

// Rate limiting per user
const userLimiter = new RateLimiterRedis({
  storeClient: redis,
  keyPrefix: "rl:user",
  points: 100,        
  duration: 3600,     
  blockDuration: 60   
});

// Rate limiting globally 
const globalLimiter = new RateLimiterRedis({
  storeClient: redis,
  keyPrefix: "rl:global",
  points: 1000,       
  duration: 3600      
});

مرحلہ 2: کیشے ٹیر

import { createHash } from "crypto";

class AICache {
  private redis: Redis;
  private ttl: number = 3600; 

  hashInput(input: string): string {
    return createHash("sha256").update(input).digest("hex");
  }

  async get(input: string): Promise {
    const key = `ai:cache:${this.hashInput(input)}`;
    const cached = await this.redis.get(key);
    
    if (cached) {
      // Cache hit - free!
      await metrics.increment("ai.cache.hits");
      return JSON.parse(cached);
    }
    
    await metrics.increment("ai.cache.misses");
    return null;
  }

  async set(input: string, result: T): Promise {
    const key = `ai:cache:${this.hashInput(input)}`;
    await this.redis.setex(key, this.ttl, JSON.stringify(result));
  }
}

مرحلہ 3: قطار کی درخواست کریں۔

import Queue from "bull";

const aiQueue = new Queue("ai-requests", {
  redis: {
    host: process.env.REDIS_HOST,
    port: 6379
  }
});

aiQueue.process(5, async (job) => {
  // Only 5 simultaneous LLM calls max
  const { ticket } = job.data;
  return await callLLM(ticket);
});

async function enqueueRequest(ticket: Ticket) {
  const job = await aiQueue.add(
    { ticket },
    {
      attempts: 3,
      backoff: {
        type: "exponential",
        delay: 2000
      }
    }
  );
  
  return job.finished(); 
}

مرحلہ 4: سرکٹ بریکر

enum CircuitState {
  CLOSED,   
  OPEN,     
  HALF_OPEN 
}

class CircuitBreaker {
  private state = CircuitState.CLOSED;
  private failures = 0;
  private lastFailureTime?: Date;
  private successesInHalfOpen = 0;

  private readonly failureThreshold = 3;
  private readonly openDurationMs = 5 * 60 * 1000; 
  private readonly halfOpenSuccesses = 2;

  async execute(
    fn: () => Promise,
    fallback?: () => T
  ): Promise {
    if (this.state === CircuitState.OPEN) {
      const elapsed = Date.now() - (this.lastFailureTime?.getTime() || 0);
      
      if (elapsed < this.openDurationMs) {
        // Still in open state - use fallback or throw
        if (fallback) {
          logger.warn("Circuit OPEN - using fallback");
          return fallback();
        }
        throw new Error("Circuit breaker OPEN - service unavailable");
      }
      
      // Transition to half-open
      this.state = CircuitState.HALF_OPEN;
      logger.info("Circuit transitioning to HALF_OPEN");
    }

    try {
      const result = await fn();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }

  private onSuccess() {
    if (this.state === CircuitState.HALF_OPEN) {
      this.successesInHalfOpen++;
      
      if (this.successesInHalfOpen >= this.halfOpenSuccesses) {
        // Service recovered - close circuit
        this.state = CircuitState.CLOSED;
        this.failures = 0;
        this.successesInHalfOpen = 0;
        logger.info("Circuit CLOSED - service recovered");
      }
    } else {
      this.failures = 0;
    }
  }

  private onFailure() {
    this.failures++;
    this.lastFailureTime = new Date();

    if (this.state === CircuitState.HALF_OPEN) {
      // Failed during test - back to open
      this.state = CircuitState.OPEN;
      this.successesInHalfOpen = 0;
      logger.error("Circuit reopened during HALF_OPEN test");
    } else if (this.failures >= this.failureThreshold) {
      // Too many failures - open circuit
      this.state = CircuitState.OPEN;
      logger.error(`Circuit OPEN after ${this.failures} failures`);
    }
  }
}

مرحلہ 5: یہ سب ایک ساتھ ڈالنا

const cache = new AICache();
const circuitBreaker = new CircuitBreaker();

async function processWithGatedPipeline(ticket: Ticket) {
  try {
    await userLimiter.consume(ticket.userId);
    await globalLimiter.consume("global");
  } catch (error) {
    throw new Error("Rate limit exceeded. Please try again later.");
  }

  const cacheKey = ticket.body;
  const cached = await cache.get(cacheKey);
  if (cached) {
    logger.info("Cache hit - returning cached result");
    return cached;
  }

  const queuedResult = await enqueueRequest(ticket);

  const result = await circuitBreaker.execute(
    async () => {
      const classification = await callLLM(ticket);
      await cache.set(cacheKey, classification);
      return classification;
    },
    () => ({
      category: "other",
      confidence: 0,
      requiresHumanReview: true,
      reason: "service_unavailable"
    })
  );

  return result;
}

اس سے کیا حاصل ہوتا ہے:

• شرح کی حد: غلط استعمال اور لاگت سے بھاگنے کو روکیں۔

• کیشنگ: تکراری استفسار کے اخراجات کو 30-40% تک کم کریں

• قطار: ٹریفک بڑھنے پر سرور اوورلوڈ کو روکیں۔

• سرکٹ بریکر: دوبارہ کوششوں پر رقم ضائع کرنے کی بجائے بندش پر جلدی ناکام ہوجائیں۔

ہر گیٹ کی آپریٹنگ لاگت کم ہے۔ یہ دو خصوصیات آپ کے سسٹم کو سب سے عام پروڈکشن کی غلطیوں سے بچاتی ہیں۔

ایک مکمل پروڈکشن آرکیٹیکچر کیسے بنایا جائے۔

ناکامی کے موڈ کے تینوں حلوں کو یکجا کرنے سے - مستقل آؤٹ پٹ، مشاہدہ، اور لاگت پر کنٹرول - کا نتیجہ ایک مکمل پروڈکشن فن تعمیر میں ہوتا ہے۔

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

ورک فلو کا مکمل نفاذ

یہاں یہ ہے کہ ہم نے جن تمام ٹکڑوں کا احاطہ کیا ہے وہ ایک ہی ورک فلو میں کیسے اکٹھے ہوتے ہیں۔ یہ ناکامی موڈ #1 کی تصدیقی فعالیت، ناکامی موڈ #2 کی مشاہداتی صلاحیت، اور ناکامی موڈ #3 کی گیٹ پائپ لائن کو یکجا کرتا ہے۔

class TicketWorkflow {
  async processTicket(rawInput: unknown): Promise {
    const requestId = generateId();
    const startTime = Date.now();

    try {
      // LAYER 1: Input validation + rate limiting + cache
      const ticket = validateTicketInput(rawInput);
      await rateLimiter.consume(ticket.userId);
      
      const cached = await cache.get(ticket.body);
      if (cached) return { ...cached, source: "cache" };

      // LAYER 2: AI processing with circuit breaker protection
      const classification = await circuitBreaker.execute(() => 
        classifyTicket(ticket)
      );

      // LAYER 3: Output validation + confidence routing
      const validated = validateClassification(classification);
      
      let action: string;
      if (validated.confidence >= 0.8) {
        await sendToAgent(ticket, validated);
        action = "auto_assigned";
      } else {
        await sendToReviewQueue(ticket, validated);
        action = "needs_review";
      }

      // LAYER 4: Log everything for observability
      await logger.log({
        requestId,
        userId: ticket.userId,
        confidence: validated.confidence,
        action,
        latencyMs: Date.now() - startTime,
        cost: calculateCost(classification.tokensUsed)
      });

      await cache.set(ticket.body, validated);
      return { classification: validated, action };

    } catch (error) {
      await logger.logError(requestId, error);
      throw error;
    }
  }
}

ہر پرت کا کردار مندرجہ ذیل ہے:

پرت 1 (ان پٹ) آپ کے سسٹم کو غلط ڈیٹا اور غلط استعمال سے بچاتا ہے۔

• یقینی بنائیں کہ آپ کے ٹکٹ میں مطلوبہ فیلڈز (ای میل، مضمون، باڈی) ہیں۔

• شرح کی حدوں کو چیک کریں (ایک صارف کو سسٹم پر غالب آنے سے روکنے کے لیے)۔

• اگر یہ ٹکٹ پہلے دیکھا گیا ہے، تو یہ کیش شدہ نتائج لوٹاتا ہے۔

پرت 2 (آرکیسٹریشن) یہ وہ جگہ ہے جہاں AI کھیل میں آتا ہے:

• ہم LLM کو ساختی پیداوار کی ضروریات کے ساتھ کہتے ہیں۔

• سرکٹ بریکر میں لپٹا ہوا (اگر API نیچے جاتا ہے تو جلدی ناکام ہو جائے گا)

• سب سے سستا ماڈل استعمال کریں جو کام کرتا ہے (درجہ بندی کے لیے ہائیکو)۔

پرت 3 (تصدیق) یقینی بنائیں کہ آپ کا آؤٹ پٹ استعمال کرنے کے لیے محفوظ ہے۔

• تصدیق کریں کہ جواب اسکیما سے میل کھاتا ہے۔

• اعتماد پر مبنی راستہ (اعلی اعتماد → خودکار تفویض، کم اعتماد → انسانی جائزہ)

• AI آؤٹ پٹ پر آنکھیں بند کرکے بھروسہ نہ کریں۔

ٹائر 4 (مشاہدہ) ہر چیز کو ٹریک کریں:

• ہر درخواست کو تاخیر، لاگت اور قابل اعتماد سکور کے ساتھ لاگ ان کیا جاتا ہے۔

• اپنے مانیٹرنگ ڈیش بورڈ پر میٹرکس بھیجیں۔

• اسامانیتاوں کی وارننگ (اعتماد میں کمی، لاگت میں اضافہ)

یہ فن تعمیر "میرے چیٹ جی پی ٹی ڈیمو میں کام کیا" سے لے کر "روزانہ 10,000 ٹکٹوں کے ساتھ قابل اعتماد طریقے سے چلتا ہے۔" کوڈ ایک سادہ API کال سے زیادہ پیچیدہ ہے، لیکن یہ پیچیدگی جان بوجھ کر ہے۔ یہ وہی ہے جو آپ کے سسٹم کو پروڈکشن کے لیے تیار کرتا ہے۔

نتیجہ: انجینئرنگ کے بہت سارے اشارے

AI کے ساتھ جیتنے والی ٹیمیں اب نہیں جیتتی ہیں کیونکہ ان کے پاس ایک بہتر ماڈل ہے۔ ان کی جیت کی وجہ یہ ہے کہ انہوں نے بہتر بنایا۔ نظام نامکمل ماڈلز کے ارد گرد۔

کوئی بھی کمپنی OpenAI API کو کال کر سکتی ہے۔ وہ لوگ جو آگے بڑھتے ہیں وہ ہیں جو اپنی API کالوں کو توثیق، مشاہداتی، لاگت پر قابو پانے، اور سوچے سمجھے فن تعمیر کے ساتھ پیک کرتے ہیں۔ یہ وہ شخص ہے جو گفتگو میں تخلیقی ساتھی کے بجائے AI کو اسمبلی لائن کے جزو کے طور پر پیش کرتا ہے۔

ہر پروڈکشن اے آئی سسٹم کو تین چیزوں کی ضرورت ہے:

1. ساخت: توثیق کرنے والے، اسکیما، اور تعییناتی پرتیں جو مستقل مزاجی کو نافذ کرتی ہیں اور کنارے پر غیر متوقع پن کو دور کرتی ہیں۔

2. گھڑی: لاگنگ، مانیٹرنگ، اور الرٹ آپ کو گھنٹوں میں مسائل کی نشاندہی کرنے میں مدد کرتا ہے، مہینوں میں نہیں۔ ایک قابل مشاہدہ پائپ لائن جو آپ کو یہ دیکھنے دیتی ہے کہ سسٹم کیا کر رہا ہے اور کیوں۔

3. کنٹرول: شرح کی حد بندی، کیشنگ، سرکٹ بریکرز، اور لاگت کے دروازے اس بات کو یقینی بناتے ہیں کہ پیمانہ آپ کے تجربات کو بجٹ کی ایمرجنسی میں تبدیل نہیں کرتا ہے۔

ایک قابل اعتماد AI ورک فلو صرف آپ کو بہتر اشارے نہیں دیتا ہے۔ یہ ناقابل اعتماد اجزاء کے لیے بہتر فن تعمیر کے بارے میں ہے۔

اگر آپ کو یہ مددگار معلوم ہوا تو آپ مجھ سے LinkedIn پر رابطہ کر سکتے ہیں یا میرے نیوز لیٹر کو سبسکرائب کر سکتے ہیں۔ آپ میری ویب سائٹ بھی وزٹ کر سکتے ہیں۔