কিভাবে অ্যাপ লজিকে মডেল ব্যবহার করে এআই-প্রথম পণ্য তৈরি করবেন

এআই-প্রথম পণ্য মানে কি

এটি কেবল “একটি চ্যাটবট যোগ করা” নয়। এআই-প্রথম পণ্য বলতে আমরা এমন একটি ডিজাইন বুঝি যেখানে মডেলটি আপনার অ্যাপলিকেশন লজিকের সক্রিয়, কার্যকরী অংশ—ঠিক যেভাবে একটি রুল ইঞ্জিন, সার্চ ইনডেক্স, বা রিকমেন্ডেশন অ্যালগরিদম কাজ করে।

আপনার অ্যাপ কেবল এআই ব্যবহার করছে না; বরং এটি এমনভাবে ডিজাইন করা যে মডেল ইনপুট ব্যাখ্যা করবে, কার্য সিদ্ধান্ত নিবে, এবং সিস্টেমের বাকি অংশ নির্ভর করতে পারে এমন স্ট্রাকচার্ড আউটপুট তৈরি করবে।

প্র্যাকটিক্যালভাবে: প্রতিটি সিদ্ধান্ত পথ হার্ড-কোড করার পরিবর্তে ("যদি X হলে Y কর"), আপনি মডেলকে ফাজি অংশ—ভাষা, উদ্দেশ্য, অস্পষ্টতা, অগ্রাধিকার নির্ধারণ—সম্পর্কে সিদ্ধান্ত নিতে দেবেন, আর আপনার কোড থাকবে যা অবশ্যই নিখুঁত হওয়া দরকার: পারমিশন, পেমেন্ট, ডাটাবেস রাইট, এবং পলিসি এনফোর্সমেন্ট।

কখন এআই-প্রথম উপযুক্ত (এবং কখন নয়)

এআই-প্রথম সবচেয়ে ভাল কাজ করে যখন সমস্যাটিতে থাকে:

• বহু বৈধ ইনপুট (ফ্রি টেক্সট, মেশানো ডকুমেন্ট, বিভিন্ন ইউজার লক্ষ্য)
• এত অনেক এজ-কেস যে হাতে রুল মেইনটেইন করা কঠিন
• বিচার, সারাংশ বা সংশ্লেষণের মধ্যে মূল্য থাকে—না যে নিখুঁত নির্ধারিত আউটপুট প্রয়োজন

রুল-ভিত্তিক অটোমেশন সাধারণত ভাল যখন প্রয়োজনীয়তা স্থির এবং এক্স‍্যাক্ট—ট্যাক্স হিসাব, ইনভেন্টরি লজিক, অযোগ্যতা চেক, অথবা এমন কমপ্লায়েন্স ওয়ার্কফ্লো যেখানে প্রতিবার আউটপুট একই থাকতে হবে।

সাধারণ পণ্য লক্ষ্য যা এআই-প্রথম সমর্থন করে

টিমগুলি সাধারণত মডেল-চালিত লজিক গ্রহণ করে তোলে যাতে তারা:

• গতিশীলতা বাড়ায়: ড্রাফট উত্তর, ফিল্ড এক্সট্র্যাকশন, রিকোয়েস্ট রাউটিং দ্রুত করা
• পার্সোনালাইজেশন: ব্যাখ্যা, পরিকল্পনা বা সুপারিশ ব্যক্তিগতকরণ করা
• সিদ্ধান্তে সহায়তা: ট্রেডঅফ হাইলাইট করা, অপশন জেনারেট করা, প্রমাণ সংক্ষেপ করা

যে ট্রেডঅফগুলি আপনাকে গ্রহণ করতে হবে (এবং ডিজাইন করতে হবে)

মডেলগুলো হতে পারে অপ্রেডিক্টেবল, কখনও কখনও আত্মবিশ্বাসীভাবে ভুল, এবং তাদের আচরণ পরিবর্তিত হতে পারে প্রম্পট, প্রোভাইডার বা রিট্রিভড কনটেক্সট বদলানোর সাথে। এগুলো প্রতি রিকোয়েস্টে খরচ বাড়ায়, ল্যাটেন্সি বাড়ায়, এবং সেফটি ও ট্রাস্ট সংক্রান্ত উদ্বেগ (গোপনীয়তা, ক্ষতিকর আউটপুট, পলিসি লঙ্ঘন) বাড়ায়।

শুদ্ধ মানসিকতা: মডেলকে একটি কম্পোনেন্ট হিসেবে দেখুন, কোনও জাদুকরী বাক্স নয়। এটাকে একটি ডিপেনডেন্সি হিসেবে বিবেচনা করুন—স্পেসিফিকেশন, ফেলিওর মোড, টেস্ট এবং মনিটরিং দিন—তাহলে আপনি নমনীয়তা পাবেন বশতই জিনিসগুলোতে অতিরিক্ত প্রত্যাশা না রেখে।

সঠিক ইউজ কেস বেছে নিন এবং সাফল্য সংজ্ঞায়িত করুন

প্রতি ফিচারেই মডেল ড্রাইভার করার দরকার নেই। সেরা এআই-প্রথম ইউজ কেসগুলো স্পষ্ট জব-টু-বি-ডান দিয়ে শুরু করে এবং একটি পরিমেয় আউটকাম দিয়ে শেষ হয় যা আপনি সপ্তাহে-সপ্তাহে ট্র্যাক করতে পারেন।

মডেলের বদলে জব দিয়ে শুরু করুন

এক বাক্যের জব স্টোরি লিখুন: “যখন ___, আমি চাই ___, যাতে আমি ___।” তারপর আউটকাম পরিমেয় করুন।

উদাহরণ: “যখন আমি একটি দীর্ঘ কাস্টমার ইমেল পাই, আমি চাই একটি প্রস্তাবিত উত্তর যা আমাদের নীতিগুলোর সাথে মেলে, যাতে আমি ২ মিনিটের মধ্যে উত্তর দিতে পারি।” এটা “ইমেলে একটি LLM যোগ করুন” বলার চেয়ে অনেক বেশি কার্যকর।

সিদ্ধান্তের পয়েন্টগুলো মানচিত্র করুন

মডেল কোথায় সিদ্ধান্ত নেবে সেই মুহূর্তগুলো নির্ধারণ করুন। এই সিদ্ধান্ত-পয়েন্টগুলো স্পষ্ট হওয়া উচিত যাতে আপনি সেগুলো টেস্ট করতে পারেন।

সাধারণ সিদ্ধান্ত-পয়েন্ট:

• ইন্টেন্ট ক্লাসিফাই করে সঠিক ওয়ার্কফ্লোতে রুট করা
• ক্লারিিফাইং প্রশ্ন করা দরকার কিনা সিদ্ধান্ত নেওয়া
• কোন টুলগুলো সিলেক্ট করা (সার্চ, CRM লুকআপ, ড্রাফটিং, টিকিট তৈরি)
• কখন একটি মানুষের কাছে এস্কেলেট করা হবে সিদ্ধান্ত নেওয়া

যদি আপনি সিদ্ধান্তগুলো নামাতে না পারেন, আপনি মডেল-চালিত লজিক শিপ করার জন্য প্রস্তুত নন।

আচরণের গ্রহণযোগ্যতা মানদণ্ড লিখুন

মডেল আচরণকে যেকোনো প্রোডাক্ট রিকোয়ারমেন্টের মতো আচরণ করুন। কি “ভালো” এবং “খারাপ” তা সাধারণ ভাষায় নির্ধারণ করুন।

উদাহরণ:

• ভাল: সর্বশেষ নীতি ব্যবহার করে, সঠিক অর্ডার আইডি উদ্ধৃত করে, যদি তথ্য অনুপস্থিত থাকে একটি স্পষ্ট এক প্রশ্ন করে
• খারাপ: ডিসকাউন্ট বানায়, সমর্থনহীন লোকেল উল্লেখ করে, বা প্রয়োজনীয় ডাটা চেক না করে উত্তর দেয়

এই মানদণ্ডগুলো পরে আপনার মূল্যায়ন সেটের ভিত্তি হবে।

শীঘ্রই সীমাবদ্ধতা নির্ধারণ করুন

যেসব সীমাবদ্ধতা আপনার ডিজাইন পছন্দগুলোকে গঠন করে সেগুলো তালিকাভুক্ত করুন:

• সময় (রেসপন্স ল্যাটেন্সি টার্গেট)
• বাজেট (প্রতি টাস্ক খরচ)
• কমপ্লায়েন্স (PII হ্যান্ডলিং, অডিট চাহিদা)
• সমর্থিত লোকেল/ভাষা (বোলার, টোন, সাংস্কৃতিক প্রত্যাশা)

মনিটর করার জন্য সাফল্য মেট্রিক নির্দিষ্ট করুন

জবের সাথে জড়িত কয়েকটি ছোট মেট্রিক বাছাই করুন:

• টাস্ক সম্পন্নতার হার
• প্রতিনিধিত্বমূলক কেসে অ্যাকুরেসি বা নীতি অনুগততা
• CSAT বা গুণগত ইউজার রেটিং
• প্রতি টাস্ক সময় বাঁচানো (বা টাইম-টু-রেজলিউশন)

আপনি যদি সাফল্য পরিমাপ না করতে পারেন, তাহলে উন্নতির বদলে অনুভূতির উপর রাজি হবেন।

এআই-চালিত ইউজার ফ্লো এবং সিস্টেম-বাউন্ডারি ডিজাইন করুন

এআই-প্রথম ফ্লো মানে isn’t “একটি স্ক্রিন যা LLM কল করে।” এটা একটি end-to-end যাত্রা যেখানে মডেল কিছু সিদ্ধান্ত নেয়, প্রোডাক্ট নিরাপদে সেগুলো কার্যকর করে, এবং ইউজার অভিমুখী থাকে।

end-to-end লুপ মানচিত্র করুন

পাইপলাইনকে একটি সরল চেইন হিসেবে আঁকুন: ইনপুট → মডেল → অ্যাকশন → আউটপুট।

• ইনপুট: ব্যবহারকারীর দেয়া (টেক্সট, ফাইল, সিলেকশন) এবং অ্যাপ কনটেক্সট (অ্যাকাউন্ট টিয়ার, ওয়ার্কস্পেস, সাম্প্রতিক কার্যক্রম)
• মডেল স্টেপ: মডেল কোন কাজটি নির্ধারণ করবে (ক্লাসিফাই, ড্রাফট, সারমাইজ, পরবর্তী অ্যাকশন সিলেক্ট)
• অ্যাকশন: আপনার সিস্টেম কি করতে পারে (সার্চ, টাস্ক তৈরি, রেকর্ড আপডেট, ইমেল পাঠানো)
• আউটপুট: ব্যবহারকারীর দেখানো (একটি ড্রাফট, ব্যাখ্যা, কনফার্মেশন স্ক্রিন, ত্রুটি ও পরবর্তী ধাপ)

এই মানচিত্র অস্পষ্টতা কোথায় গ্রহণযোগ্য (ড্রাফটিং) এবং কোথায় নয় (বিলিং পরিবর্তন) তা স্পষ্ট করে দেয়।

সিস্টেম বাউন্ডারি নির্ধারণ: মডেল বনাম ডিটারমিনিস্টিক কোড

ডিটারমিনিস্টিক পথগুলো (পারমিশন চেক, বিজনেস রুল, ক্যালকুলেশন, ডাটাবেস রাইট) আলাদা করে রাখুন মডেল-চালিত সিদ্ধান্ত (ইন্টারপ্রিটেশন, অগ্রাধিকার, ন্যাচারাল-ল্যাঙ্গুয়েজ জেনারেশন) থেকে।

একটি দরকারী নিয়ম: মডেল প্রস্তাব করতে পারে, কিন্তু কোডকে যাচাই করতে হবে কোনো অনতিরোধ্য কাজ করার আগে।

মডেল কোথায় রান করবে তা নির্ধারণ করুন

রানটাইম বেছে নিন সীমাবদ্ধতা অনুযায়ী:

• সার্ভার: ব্যক্তিগত ডেটার জন্য, কনসিস্টেন্ট টুলিং ও অডিট লগসের জন্য ভাল
• ক্লায়েন্ট: হালকা সহায়তার এবং লোকাল প্রসেসিংয়ের মাধ্যমে গোপনীয়তার জন্য সুবিধাজনক, তবে নিয়ন্ত্রণ কঠিন
• এজ: দ্রুত গ্লোবাল ল্যাটেন্সি, কিন্তু সীমিত ডিপেনডেন্সি
• হাইব্রিড: এজে দ্রুত ইন্টেন্ট ডিটেকশন ও সার্ভারে ভারী কাজ

ল্যাটেন্সি, খরচ এবং ডেটা পারমিশন বাজেট করুন

প্রতি রিকোয়েস্টের জন্য একটি ল্যাটেন্সি এবং খরচ বাজেট (রিট্রাই ও টুল কল সহ) সেট করুন, এবং UX তাতে মানানসই করুন (স্ট্রিমিং, প্রগ্রেসিভ ফলাফল, “পিছনে চালিয়ে নিন”)।

প্রতি স্টেপে কোন ডেটা সোর্স কি পড়তে পারে, কি লিখতে পারে, এবং কি explicit ইউজার কনফার্মেশন দরকার—এসব ডকুমেন্ট করুন। এটা ইঞ্জিনিয়ারিং এবং ট্রাস্ট উভয়ের জন্য একটি কনট্র্যাক্ট হয়ে যাবে।

আর্কিটেকচার প্যাটার্ন: অর্কেস্ট্রেশন, স্টেট, এবং ট্রেস

যখন মডেল আপনার অ্যাপ লজিকের একটি অংশ, তখন আর্কিটেকচার মানে শুধু সার্ভার ও API নয়—এটা কিভাবে আপনি ধারাবাহিকভাবে মডেল সিদ্ধান্তের চেইন চালাবেন তা।

অর্কেস্ট্রেশন: মডেলের কাজ পরিচালনা

অর্কেস্ট্রেশন হলো সেই লেয়ার যা এআই টাস্ককে end-to-end ম্যানেজ করে: প্রম্পট ও টেমপ্লেট, টুল কল, মেমরি/কনটেক্সট, রিট্রাই, টাইমআউট, এবং ফলব্যাক।

ভাল অর্কেস্ট্রেটর মডেলকে পাইপলাইনের একটি কম্পোনেন্ট হিসেবে দেখে। তারা ঠিক করে কোন প্রম্পট ব্যবহার করতে হবে, কখন টুল কল করতে হবে (সার্চ, ডাটাবেস, ইমেল, পেমেন্ট), কনটেক্সট কীভাবে কম্প্রেস বা ফেচ করতে হবে, এবং মডেল অস্বীকৃত কিছু রিটার্ন করলে কি করা হবে।

যদি আপনি আইডিয়া থেকে ওয়ার্কিং অর্কেস্ট্রেশন দ্রুত নিতে চান, একটি ভাইব-কোডিং ওয়ার্কফ্লো প্রোটোটাইপ করার ক্ষেত্রে সাহায্য করে। উদাহরণস্বরূপ, Koder.ai দলগুলোকে চ্যাটের মাধ্যমে ওয়েব অ্যাপ (React), ব্যাকএন্ড (Go + PostgreSQL), এবং মোবাইল (Flutter) তৈরি করতে দেয়—তারপর “ইনপুট → মডেল → টুল কল → ভ্যালিডেশন → UI” মত ফ্লো নিয়ে পুনরাবৃত্তি এবং স্ন্যাপশট, রোলব্যাক, সোর্স-কোড এক্সপোর্ট ইত্যাদি সুবিধা দেয়।

মাল্টি-স্টেপ টাস্কের জন্য স্টেট মেশিন

ট্রায়াজ → তথ্য সংগ্রহ → কনফার্ম → এক্সিকিউট → সারমাইজের মতো মাল্টি-স্টেপ এক্সপেরিয়েন্সগুলো যখন ওয়ার্কফ্লো বা স্টেট মেশিন হিসেবে মডেল করা হয় তখন ভাল কাজ করে।

সাধারণ প্যাটার্ন: প্রতিটি ধাপের (1) অনুমতিপ্রাপ্ত ইনপুট, (2) প্রত্যাশিত আউটপুট, এবং (3) ট্রানজিশন থাকে। এটা টকিং কথাবার্তা এড়ায় এবং এজ-কেসগুলোকে স্পষ্ট করে—যেমন ইউজার মানসিকতা বদলে দিলে কি হবে বা আংশিক তথ্য দিলে কিভাবে আচরণ হবে।

সিঙ্গেল-শট বনাম মাল্টি-টার্ন রিজনিং

সিঙ্গেল-শট ভাল যখন টাস্ক সীমাবদ্ধ: একটি মেসেজ ক্লাসিফাই করা, ছোট একটি রিপ্লাই ড্রাফট করা, ডকুমেন্ট থেকে ফিল্ড এক্সট্র্যাক্ট করা। এটা সস্তা, দ্রুত এবং ভ্যালিডেট করা সহজ।

মাল্টি-টার্ন ভাল যখন মডেলকে ক্লারিিফাইং প্রশ্ন করতে হবে বা টুলগুলোকে ইটারেটিভভাবে ব্যবহার করতে হবে (উদাহরণ: প্ল্যান → সার্চ → রিফাইন → কনফার্ম)। সচেতনভাবে ব্যবহার করুন এবং লুপে টাইম/স্টেপ লিমিট দিন।

আইডেম্পোটেন্সি: পুনরাবৃত্তি করা সাইড-ইফেক্ট এড়ান

মডেল রিট্রাই করে। নেটওয়ার্ক ফেল করে। ইউজার ডাবল-ক্লিক করে। যদি কোনো এআই স্টেপ সাইড-ইফেক্ট ট্রিগার করতে পারে—ইমেইল পাঠানো, বুকিং, চার্জিং—তাহলে এটিকে আইডেম্পোটেন্ট করুন।

কমন ট্যাকটিক: প্রতিটি এক্সিকিউট অ্যাকশনের সাথে একটি আইডেম্পোটেন্সি কী লাগান, অ্যাকশন ফলাফল সংরক্ষণ করুন, এবং নিশ্চিত করুন রিট্রাই একই আউটকাম দেয় পরিবর্তে সেটিকে পুনরায় চালানো না করে।

ট্রেস: প্রতিটি ধাপ ডিবাগেবল করুন

ট্রেসিং যোগ করুন যাতে আপনি উত্তর দিতে পারেন: মডেল কী দেখেছিল? সে কী সিদ্ধান্ত নিয়েছিল? কোন টুলগুলো রান হয়েছিল?

প্রতিটি রানের জন্য স্ট্রাকচার্ড ট্রেস লগ করুন: প্রম্পট ভার্সন, ইনপুট, রিট্রিভড কনটেক্সট আইডি, টুল রিকোয়েস্ট/রেসপন্স, ভ্যালিডেশন এরর, রিট্রাই, এবং চূড়ান্ত আউটপুট। এটা “এআই অদ্ভুত কিছু করেছে”কে একটি অডিটেবল, ফিক্সেবল টাইমলাইনে পরিণত করে।

প্রম্পটকে প্রোডাক্ট লজিক হিসেবে দেখুন: স্পষ্ট কন্ট্র্যাক্ট ও ফরম্যাট

যখন মডেল আপনার অ্যাপ লজিকের অংশ হয়, তখন প্রম্পট কেবল “কপিরাইট” নয় বরং এক্সিকিউটেবল স্পেসিফিকেশন। সেগুলোকে প্রোডাক্ট রিকোয়ারের মত আচরণ করুন: স্পষ্ট স্কোপ, ভবিষ্যদ্বাণীমূলক আউটপুট, এবং পরিবর্তন নিয়ন্ত্রণ।

সিস্টেম প্রম্পট দিয়ে কন্ট্র্যাক্ট শুরু করুন

আপনার সিস্টেম প্রম্পটটি মডেলের ভূমিকা, কি করা যাবে না, এবং যে সেফটি নিয়মগুলো গুরুত্বপূর্ণ সেগুলো নির্ধারণ করবে। এটি স্থিতিশীল ও পুনঃব্যবহারযোগ্য রাখুন।

অন্তর্ভুক্ত করুন:

• ভূমিকা ও লক্ষ্য: কে এটি (উদাহরণ: “সাপোর্ট ট্রায়াজ অ্যাসিস্ট্যান্ট”) এবং সফলতা কেমন দেখায়
• স্কোপ সীমা: কোন অনুরোধগুলোকে প্রত্যাখ্যান বা এস্কেলেট করতে হবে
• সেফটি নিয়ম: PII হ্যান্ডলিং, মেডিক্যাল/লিগ্যাল ডিসক্লেইমার, অনুমান না করা
• টুল পলিসি: কখন টুল কল করতে হবে বনাম সরাসরি উত্তর দিতে হবে

ইনপুট/আউটপুট স্পষ্টভাবে কাঠামোবদ্ধ করুন

প্রম্পটগুলোকে API ডেফিনিশনের মতো লিখুন: আপনি যে নির্দিষ্ট ইনপুট দেবেন (ব্যবহারকারী টেক্সট, অ্যাকাউন্ট টিয়ার, লোকেল, পলিসি স্নিপেট) এবং আপনি যে নির্দিষ্ট আউটপুট আশা করেন তা তালিকাভুক্ত করুন। 1–3টি বাস্তব উদাহরণ যোগ করুন, যাতে জটিল কেসগুলোও ঢুকছে।

একটি দরকারী প্যাটার্ন: কনটেক্সট → টাস্ক → সীমাবদ্ধতা → আউটপুট ফরম্যাট → উদাহরণ।

মেশিন-রিডেবল ফলাফলের জন্য সীমাবদ্ধ ফরম্যাট ব্যবহার করুন

যদি কোড আউটপুট নিয়ে কাজ করবে, প্রোজোনালি প্রোজোনালি প্রো না করে। JSON চাইুন যা একটি স্কিমা মেনে চলে এবং অন্য কিছু ফিরিয়ে দিলে তা প্রত্যাখ্যান করুন।

{
  "type": "object",
  "properties": {
    "intent": {"type": "string"},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "actions": {
      "type": "array",
      "items": {"type": "string"}
    },
    "user_message": {"type": "string"}
  },
  "required": ["intent", "confidence", "actions", "user_message"],
  "additionalProperties": false
}

প্রম্পটের ভার্সন কন্ট্রোল এবং নিরাপদ রোলআউট

প্রম্পটগুলো ভার্সন কন্ট্রোলে রাখুন, রিলিজ ট্যাগ করুন, এবং ফিচারের মতো রোল আউট করুন: স্টেজড ডিপ্লয়মেন্ট, A/B যেখানে প্রযোজ্য, এবং দ্রুত রোলব্যাক। প্রতিটি রেসপন্সের সাথে প্রম্পট ভার্সন লগ করুন ডিবাগের জন্য।

একটি প্রম্পট টেস্ট স্যুট তৈরি করুন

একটি ছোট কিন্তু প্রতিনিধিত্বশীল কেস সেট (হ্যাপি পাথ, অস্পষ্ট অনুরোধ, পলিসি লঙ্ঘন, দীর্ঘ ইনপুট, বিভিন্ন লোকেল) তৈরি করুন। প্রতিটি প্রম্পট পরিবর্তনের সময় সেগুলো অটোমেটিক চালান এবং আউটপুট কন্ট্রাক্ট ভাঙলে বিল্ড ফেল করুন।

টুল কলিং: মডেল সিদ্ধান্ত নিক, কোড এক্সিকিউট করুক

টুল কলিং সবচেয়ে পরিষ্কার উপায় যাতে দায়বদ্ধতা ভাগ করা যায়: মডেল নির্ধারণ করে কি করা দরকার এবং কোন ক্ষমতা ব্যবহার করতে, আর আপনার অ্যাপ কোড এক্সিকিউট করে কাজটি এবং ভেরিফাইড রেজাল্ট ফেরত দেয়।

এতে ফ্যাক্ট, ক্যালকুলেশন এবং সাইড-ইফেক্ট (টিকিট তৈরি, রেকর্ড আপডেট, ইমেল পাঠানো) ডিটারমিনিস্টিক, অডিটযোগ্য কোডে থাকে—ফ্রি-ফর্ম টেক্সটের উপর নির্ভর না করে।

একটি ছোট, লক্ষ্যভিত্তিক টুলসেট ডিজাইন করুন

শুরুতে কয়েকটি টুল নিন যা ৮০% রিকোয়েস্ট কভার করে এবং সিকিউর করা সহজ:

• সার্চ (ডকুমেন্ট/হেল্প সেন্টার) প্রোডাক্ট প্রশ্নের জন্য
• DB লুকআপ (প্রথমে রিড-অনলি) ইউজার/অ্যাকাউন্ট/অর্ডার স্ট্যাটাসের জন্য
• ক্যালকুলেটর প্রাইসিং, টোটাল, কনভার্শন এবং রুল-ভিত্তিক ম্যাথের জন্য
• টিকেটিং মানব ফলোআপের জন্য সাপোর্ট রিকোয়েস্ট ওপেন করা

প্রতিটি টুলের উদ্দেশ্য সংকীর্ণ রাখুন। “সবকিছু করে” এমন টুল টেস্ট করা কঠিন করে এবং ভুলভাবে ব্যবহৃত হওয়ার সুযোগ বাড়ায়।

ইনপুট ভ্যালিডেট করুন, আউটপুট_SANITIZE করুন

মডেলকে অন-ট্রাস্টেড কলে দেখুন।

• টুল ইনপুট ভ্যালিডেশন কঠোর স্কিম দিয়ে (টাইপ, রেঞ্জ, এনাম)। অনুপযুক্ত আর্গুমেন্ট প্রত্যাখ্যান বা মেরামত করুন (উদাহরণ: অনুপস্থিত আইডি, অত্যাধিক বিস্তৃত কুয়েরি)।
• টুল আউটপুট_SANITIZE করে মডেলে ফেরত দিন: সিক্রেটস ধুয়ে ফেলুন, ফরম্যাট নর্মালাইজ করুন, এবং কেবল মডেলকে যে ফিল্ডগুলো দরকার সেগুলো দিন।

এতে রিট্রিভড টেক্সটের মাধ্যমে প্রম্পট-ইনজেকশন ঝুঁকি কমে এবং অনিচ্ছাকৃত ডেটা লিকেজ সীমাবদ্ধ হয়।

প্রতিটি টুলে পারমিশন ও রেট লিমিট যোগ করুন

প্রতিটি টুল এফোর্স করবে:

• পারমিশন চেক (কে কোন রেকর্ড/অ্যাকশন অ্যাক্সেস করতে পারে)
• রেট লিমিট (প্রতি ইউজার/সেশন/টুল) যাতে ত্রুটি ও যথেচ্ছতা কমে

যদি একটি টুল স্টেট পরিবর্তন করতে পারে (টিকেটিং, রিফান্ড), শক্তিশালী অথোরাইজেশন এবং অডিট লগ প্রয়োজন।

সবসময় একটি “কোনো টুল নয়” পথ রাখুন

কখনো কখনো সেরা কার্যক্রম হল কোনো কার্যক্রম না করা: বিদ্যমান কনটেক্সট থেকে উত্তর দিন, একটি ক্লারিিফাইং প্রশ্ন করুন, বা সীমাবদ্ধতা ব্যাখ্যা করুন।

“কোনো টুল নয়” কে একটি ফার্স্ট-ক্লাস আউটকাম বানান যাতে মডেল টুল কল করে শুধু ব্যস্ত দেখানোর জন্য না।

ডেটা এবং RAG: মডেলকে আপনার রিয়ালিটিতে গ্রাউন্ড করুন

আপনার পণ্যের উত্তর যদি নীতিমালা, ইনভেন্টরি, চুক্তি বা অভ্যন্তরীণ জ্ঞানের সাথে মেলাতে হয়, তবে মডেলকে কেবল সাধারণ প্রশিক্ষণের উপর নির্ভর না করে আপনার ডেটায় গ্রাউন্ড করা দরকার।

RAG বনাম ফাইন-টিউনিং বনাম সহজ কনটেক্সট

• সরল কনটেক্সট (প্রম্পটে কয়েক প্যারাগ্রাফ পেস্ট করা) কাজ করে যখন জ্ঞান ছোট, স্থিতিশীল, এবং প্রতিবার পাঠাতে পারি (উদাহরণ: সংক্ষিপ্ত প্রাইসিং টেবিল)।
• RAG (Retrieval-Augmented Generation) ভালো যখন তথ্য বড়, ঘনঘন পরিবর্তনশীল, বা উত্সের উদ্ধৃতি দরকার (উদাহরণ: হেল্প-সেন্টার আর্টিকেল, প্রোডাক্ট ডক্স, অ্যাকাউন্ট-স্পেসিফিক ডেটা)।
• ফাইন-টিউনিং ভালো যখন আপনি ধারাবাহিক স্টাইল/ফরম্যাট চান বা ডোমেইন-স্পেসিফিক প্যাটার্ন—কিন্তু এটাকে সত্যি ‘ফ্যাক্ট স্টোর’ হিসেবে ব্যবহার করবেন না। এটি লেখার দক্ষতা বাড়াতে ব্যবহার করুন এবং আপ-টু-ডেট ট্রুথের জন্য RAG এর সাথে জোড়া দিন।

ইনজেশন বেসিক: চাংকিং, মেটাডেটা, ফ্রেশনেস

RAG মান অধিকাংশই ইনজেশন সমস্যার উপর নির্ভরশীল।

ডকুমেন্টগুলোকে আপনার মডেলের জন্য উপযুক্ত সাইজে (সাধারণত কয়েকশ টোকেন) চাংক করুন, স্বাভাবিক সীমার (হেডিং, FAQ এন্ট্রি) অনুযায়ী। মেটাডেটা সংরক্ষণ করুন যেমন: ডকুমেন্ট টাইটেল, সেকশন হেডিং, প্রোডাক্ট/ভার্সন, অডিয়েন্স, লোকেল, এবং পারমিশন।

ফ্রেশনেস পরিকল্পনা করুন: পুনরায়-ইনডেক্সিং শিডিউল, "শেষ আপডেট" ট্র্যাক করুন, এবং পুরনো চাংক এক্সপায়ার করুন। একটি স্টেলে থাকা চাংক যদি উচ্চ র‍্যাঙ্ক পায় তা ধীরে ধীরে পুরো ফিচারকে ক্ষতিগ্রস্ত করে।

উদ্ধৃতি এবং ক্যালিব্রেটেড উত্তর

মডেলকে উৎস উদ্ধৃত করে উত্তর দিতে বলুন: (1) উত্তর, (2) স্নিপেট আইডি/URL তালিকা, এবং (3) আত্মবিশ্বাস বিবৃতি।

যদি রিট্রিভাল দুর্বল হয়, মডেলকে বলুন সে কি নিশ্চিত করতে পারে না এবং পরবর্তী ধাপ প্রস্তাব করুক ("আমি সেই নীতি খুঁজে পাইনি; এখানে কাকে যোগাযোগ করা যায়"), অনুমান করতে দেবেন না।

প্রাইভেট ডেটা: অ্যাক্সেস কন্ট্রোল ও রেড্যাকশন

রিট্রাইভালের আগে অ্যাক্সেস এনফোর্স করুন (ইউজার/অর্গ পারমিশন দ্বারা ফিল্টার) এবং জেনারেশনের আগে আবার রেড্যাক্ট করুন (সেন্সিটিভ ফিল্ড মুছে দিন)।

এম্বেডিং ও ইনডেক্সগুলোকে সংবেদনশীল ডেটা স্টোর হিসাবে বিবেচনা করুন এবং অডিট লগ রাখুন।

যখন রিট্রিভাল ফেল করে: গ্রেসফুল ফলব্যাক

যদি টপ রেজাল্ট অনর্থক বা খালি হয়, ফলব্যাক হিসেবে নিন: একটি ক্লারিিফাইং প্রশ্ন জিজ্ঞেস করা, মানব সাপোর্টে রাউট করা, অথবা একটি নন-RAG মোডে স্যুইচ করে সীমাবদ্ধতা ব্যাখ্যা করা—অন্তত অনুমান না করে।

নির্ভরযোগ্যতা: গার্ডরেইল, ভ্যালিডেশন, এবং ক্যাশিং

যখন মডেল আপনার অ্যাপ লজিকের ভিতরে থাকে, “সাধারণভাবে ঠিক থাকে” যথেষ্ট নয়। নির্ভরযোগ্যতা মানে: ইউজার নিয়মিত আচরণ পায়, সিস্টেম নিরাপদে আউটপুট গ্রহণ করতে পারে, এবং ফেলিওরগুলি ধাপে ধাপে গ্রেসফুললি ডিগ্রেড করে।

নির্ভরযোগ্যতার লক্ষ্য নির্ধারণ করুন (ফিক্স যোগ করার আগে)

লিখে রাখুন ফিচারের জন্য “নির্ভরযোগ্য” মানে কি:

• কনসিস্টেন্ট আউটপুট: অনুরূপ ইনপুট তুলনীয় উত্তর দেয় (টোন, ডিটেইল লেভেল, সীমাবদ্ধতা)
• স্টেবল ফরম্যাট: আউটপুট প্রত্যেকবার পার্সেবল হতে হবে (JSON, বুলেট লিস্ট, নির্দিষ্ট ফিল্ড)
• বাউন্ডেড আচরণ: মডেল কি করবে তার স্পষ্ট সীমা (অনুমান না করা, উৎস উদ্ধৃত করা, অনিশ্চয় হলে প্রশ্ন করা)

এই লক্ষ্যগুলো প্রম্পট এবং কোড উভয়ের জন্য গ্রহণযোগ্যতা মানদণ্ড হয়ে যায়।

গার্ডরেইল: ভ্যালিডেট, ফিল্টার, এবং পলিসি এফোর্স

মডেল আউটপুটকে আনট্রাস্টেড ইনপুট হিসেবে বিবেচনা করুন।

• স্কিমা ভ্যালিডেশন: কঠোর ফরম্যাট (উদাহরণ: JSON নির্দিষ্ট কি সহ) বাধ্য করুন এবং পািস না হলে প্রত্যাখ্যান করুন
• কন্টেন্ট ফিল্টার: প্রবৃতি চেক, PII ডিটেক্টর, অথবা পলিসি ভ্যালিডেটর চালান ব্যবহারকারীর ইনপুট ও মডেল আউটপুট উভয়ের ওপর
• বিজনেস রুল: কোডে সীমাবদ্ধতা এনফোর্স করুন (প্রাইস রেঞ্জ, যোগ্যতার নিয়ম, অনুমোদিত অ্যাকশন), এমনকি প্রম্পটে সেগুলো উল্লেখ থাকলেও

যদি ভ্যালিডেশন ফেল করে, নিরাপদ ফলব্যাক দিন (ক্লারিিফাই, সরল টেমপ্লেটে স্যুইচ, বা মানবের কাছে রাউট)।

রিট্রাই যা সহায়ক

অন্ধভাবে পুনরাবৃত্তি এড়ান। ভিন্ন প্রম্পট দিয়ে রিট্রাই করুন যা ফেলিওর মোড ঠিক করে:

• "শুধু বৈধ JSON ফিরিয়ে দেন। কোনো মার্কডাউন নয়।"
• "অনিশ্চয় হলে confidence কম সেট করুন এবং একটি প্রশ্ন করুন।"

রিট্রাই সীমা দিন এবং প্রতিটি ফেলিওরের কারণ লগ করুন।

ডিটারমিনিস্টিক পোস্ট-প্রসেসিং

কোড ব্যবহার করে মডেল আউটপুট স্বাভাবিকীকরণ করুন:

• ইউনিট, তারিখ এবং নাম canonicalize করা
• আইটেমগুলো ডুপ্লিকেটি রিমুভ করা
• র্যাঙ্কিং রুল বা থ্রেশহোল্ড প্রয়োগ করা

এতে পরিবর্তনশীলতা কমে এবং আউটপুট টেস্ট করা সহজ হয়।

প্রাইভেসি সংক্রান্ত সমস্যা ছাড়া ক্যাশিং

রিপ্লেকটেবল ফলাফল (একই কুয়েরি, শেয়ারড এমবেডিং, টুল রেসপন্স) ক্যাশ করুন খরচ ও ল্যাটেন্সি কমানোর জন্য।

পছন্দ করুন:

• ইউজার-স্পেসিফিক ডেটার জন্য ছোট TTL
• ক্যাশ কীতে রড PII বাদ দিন (বা হ্যাশ সাবধানে)
• সেন্সিটিভ ফ্লো জন্য “ক্যাশ না করা” ফ্ল্যাগ

ভালভাবে করলে, ক্যাশিং কনসিস্টেন্সি বাড়ায় এবং ইউজার ট্রাস্ট বজায় রাখে।

সেফটি ও ট্রাস্ট: UX নষ্ট না করে ঝুঁকি কমান

সেফটি আলাদা কোনো কমপ্লায়েন্স লেয়ার নয় যা পরে বোল্ট অন করবেন। এআই-প্রথম পণ্যগুলোতে মডেল অ্যাকশন, ভাষা, এবং সিদ্ধান্তকে প্রভাবিত করে—তাই সেফটি আপনার পণ্য কন্ট্র্যাক্টের অংশ হতে হবে: সহকারী কি করতে পারে, কি প্রত্যাখ্যান করবে, এবং কখন সহায়তা চাইবে।

ডিজাইন করার জন্য প্রধান সেফটি উদ্বেগ

আপনার অ্যাপ বাস্তবে যে ঝুঁকিগুলো মুখোমুখি হবে সেগুলো নামকরণ করুন, তারপর প্রতিটির জন্য নিয়ন্ত্রণ মানচিত্র করুন:

• সংবেদনশীল ডেটা: ব্যক্তিগত পরিচয়, ক্রেডেনশিয়াল, ব্যক্তিগত ডকুমেন্ট ও নিয়ন্ত্রিত কিছু
• ক্ষতিকর নির্দেশনা: আত্মহত্যা, সহিংসতা, অবৈধ কৃত্য, বা নিরাপদ নয় এমন মেডিক্যাল/ফাইন্যান্সিয়াল নির্দেশ
• বায়াস ও অনন্যায়ফল: বিভিন্ন গ্রুপে অসামঞ্জস্যপূর্ণ সেবা বা সুপারিশ

অনুমোদিত/ব্লক করা বিষয় এবং এস্কেলেশন পথ

একটি স্পষ্ট পলিসি লিখুন যা আপনার প্রোডাক্ট এনফোর্স করতে পারে। তা কনক্রিট রাখুন: ক্যাটাগরি, উদাহরণ, এবং প্রত্যাশিত রেসপন্স।

তিনটি স্তর ব্যবহার করুন:

1. অনুমোদিত: সাধারণভাবে উত্তর দিন
2. সীমাবদ্ধ: শর্তযুক্তভাবে উত্তর (উদাহরণ: সাধারণ তথ্য দিন, ধাপে ধাপে নয়)
3. ব্লক করা: প্রত্যাখ্যান করুন এবং এস্কেলেশন পথ দেখান (সাপোর্ট, রিসোর্স, বা একটি মানব এজেন্ট)

এস্কেলেশন একটি প্রোডাক্ট ফ্লো হওয়া উচিত, শুধুই প্রত্যাখ্যান মেসেজ নয়। “মনুষের সাথে কথা বলুন” অপশন দিন, এবং হ্যান্ডঅফের সময় ইউজারের শেয়ার করা কনটেক্সট অন্তর্ভুক্ত করুন (অনুমোদন নিয়ে)।

উচ্চ-প্রভাব অ্যাকশনের জন্য মানব রিভিউ

যদি মডেল বাস্তব পরিণতি ট্রিগার করতে পারে—পেমেন্ট, রিফান্ড, অ্যাকাউন্ট পরিবর্তন, বাতিল, ডেটা ডিলিশন—তাহলে একটি চেকপয়েন্ট যোগ করুন।

ভাল প্যাটার্ন: কনফার্মেশন স্ক্রিন, “ড্রাফট তারপর অনুমোদন”, সীমা (পরিমাণ ক্যাপ), এবং এজ-কেসের জন্য মানব রিভিউ কিউ।

প্রকাশ, সম্মতি, এবং টেস্টেবল পলিসি

ইউজারকে বলুন যখন তারা এআই-এর সাথে ইন্টার‍্যাক্ট করছে, কুন ডেটা ব্যবহার হচ্ছে, এবং কি সংরক্ষণ করা হবে। কনসেন্ট নিন যেখানে প্রয়োজন, বিশেষ করে কথোপকথন সংরক্ষণ বা সিস্টেম উন্নতির জন্য ডেটা ব্যবহার।

অভ্যন্তরীণ সেফটি পলিসিকে কোডের মতো ট্রিট করুন: ভার্সনিং, যুক্তি ডকুমেন্ট করুন, এবং টেস্ট (উদাহরণ প্রম্পট ও প্রত্যাশিত আউটকাম) যোগ করুন যাতে প্