AI দায়বদ্ধতার চেকলিস্ট: টিমনিট গেব্রু থেকে শেখা

চালানোর আগে কেন AI দায়বদ্ধতা গুরুত্বপূর্ণ

একসময় একটি AI ফিচার তৈরি করা ছিল মূলত কারিগরি প্রশ্ন: কি আমরা মডেলটিকে কাজ করাতে পারি? এখন কঠিন প্রশ্নটা হলো আপনি কি এটি ডেপ্লয় করা উচিত, এবং কী সীমা লাগবে।

যখন বাস্তবে ব্যবহারকারীরা AI আউটপুটের ওপর নির্ভর করবে, ছোটখাট সমস্যা বড় ব্যয় হয়ে যায়: ভুল সিদ্ধান্ত, বিভ্রান্ত গ্রাহক, প্রাইভেসি লিক, বা অন্যায় আচরণ।

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

এটি সর্বাধিক গুরুত্বপূর্ণ লঞ্চের ঠিক আগে, যখন ডকুমেন্টেশনকে ঐচ্ছিক মনে করা প্রলোভন সৃষ্টি করে। ডকুমেন্টেশন ছাড়াই শিপ করলে পরে ব্যয়বহুল বিস্ময় হয়: উত্তরহীন সাপোর্ট টিকিট, রাগানো ব্যবহারকারী, প্রোডাক্ট রোলব্যাক, এবং অভ্যন্তরীণ আঙ্গুল তোলা।

একটি সহজ দায়বদ্ধতা চেকলিস্ট কনক্রিট উত্তর জোর করে:

• ফিচারকে কোন ডেটা খাওয়ানো হয়েছে, এবং জানা ফাঁকগুলো কী?
• উদ্দেশ্য কী, এবং কি স্পষ্টভাবে আউট অফ স্কোপ?
• কোন ভুলগুলো সম্ভব এবং কে ক্ষতিগ্রস্ত হতে পারে?
• কোন গার্ডরেল আছে (মানব রিভিউ, ফ্যালব্যাক, মনিটরিং)?

লক্ষ্য তত্ত্ব নয়—বেসিক (ডেটা, সীমা, ঝুঁকি) ডকুমেন্ট করা, তারপর এমন সিদ্ধান্ত নেয়া যা আপনি পরে রক্ষা করতে পারেন, এমনকি দ্রুতগতিতে কাজ করলেও।

টিমনিট গেব্রু এক পাতায়: তার কাজ কি বদলালো

টিমনিট গেব্রু AI দায়বদ্ধতার অন্যতম সবচেয়ে উদ্ধৃত কণ্ঠস্বর, কারণ তিনি একটি সহজ ধারণাকে জোর দিয়েছিলেন যে বহু টিম এড়িয়ে চলত: কেবল "আমরা কি সেটি তৈরি করতে পারি?" জিজ্ঞাসা করা যথেষ্ট নয়। আপনাকে জিজ্ঞাসা করতে হবে "আমরা কি এটাকে ডেপ্লয় করা উচিত, কে ক্ষতিগ্রস্ত হতে পারে, এবং আমরা কীভাবে জানতে পারব?"

এই পরিবর্তনের বড় অংশ হলো AI সিস্টেমকে অন্যদের জন্য পাঠযোগ্য করা—শুধু তাদের ইঞ্জিনিয়ারদের জন্য নয় যারা মডেল ট্রেন করেছে, বরং রিভিউয়ার, প্রোডাক্ট ম্যানেজার, সাপোর্ট টীম এবং ব্যবহারকারীরাও বুঝতে পারে। উদ্দেশ্য হলো লিখে রাখা কি সিস্টেম করতে চায়, কোন ডেটা সেট করেছে, কোথায় ব্যর্থ হয়, এবং বাস্তব জীবনে ঝুঁকি কেমন দেখায়।

দুইটি ব্যবহারিক আলপত্রিক ডিজাইন জনপ্রিয় হয়ে উঠল কারণ সেগুলো এই পাঠযোগ্যতাকে কংক্রিট করে তোলে:

• ডেটাসেট নোট (প্রায়ই datasheets for datasets বলা হয়): ডেটা কি, কোথা থেকে এসেছে, কে প্রদর্শিত বা অনুপস্থিত, এবং কী জন্য ব্যবহার করা উচিৎ নয়।
• মডেল নোট (প্রায়ই model cards বলা হয়): মডেলটির উদ্দেশ্য, কিভাবে টেস্ট করা হয়েছে, জানা সীমাবদ্ধতা, এবং কোন ধরনের ভুল আশা করা যায়।

প্রোডাক্ট টিমদের জন্য, এটা কেবল কাগজপত্র নয়। ডকুমেন্টেশন হলো প্রমাণ। কেউ জিজ্ঞাসা করলে, "কেন আমরা এই ফিচারটি শিপ করলাম?" বা "আপনি কেন এই ব্যর্থতা ধরতে পারেননি?" আপনার কাছে এমন কিছু থাকতে হবে যা আপনি ইশারা করে দেখাতে পারেন: আপনি যা পরিমাপ করেছেন, আপনি কী সমর্থন না করার সিদ্ধান্ত নিয়েছেন, এবং আপনি কি নিরাপত্তা যোগ করেছেন।

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

কোনটা AI ফিচার এবং কি ভুল হতে পারে

AI ফিচার হল এমন কোনও প্রোডাক্ট অংশ যেখানে মডেলের আউটপুট মানুষকে দেখা, করার বা তাদের সঙ্গে আচরণ পরিবর্তন করতে পারে। আউটপুট যদি কোনো সিদ্ধান্তকে প্রভাবিত করে—even যদি সামান্য—তাহলে এটিকে প্রকৃত ফিচার হিসেবে বিবেচনা করুন যার বাস্তব ফল আছে।

সাধারণ ধরনের মধ্যে রয়েছে সারাংশ, র‍্যাংকিং, রিকমেন্ডেশন, মনিটরিং/মডারেশন, এবং স্কোরিং (ঝুঁকি, ফ্রড, মান, যোগ্যতা, অগ্রাধিকার)।

যখন কিছু ভুল হয়, প্রভাব ক্লিক করা ব্যক্তির পারাপরেও পৌঁছায়। ক্ষতিগ্রস্ত হতে পারে শেষ ব্যবহারকারী, অন-ব্যবহারকারী (যারা উল্লেখ বা প্রোফাইল করা হয়েছে), সাপোর্ট স্টাফ ও মডারেটর, কন্ট্রাক্টর ও রিভিউয়ার, এবং সেই ডেটার সাবজেক্ট যাদের ডেটা ট্রেন বা ইভালুয়েশনে ব্যবহার হয়েছে।

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

ক্ষতিগুলো প্রায়শই গ্রুপ এবং প্রসঙ্গে অসমভাবে পড়ে। একটি মডারেশন মডেল বেশিরভাগ ব্যবহারকারীদের জন্য ঠিকঠাক কাজ করলেও এক কমিউনিটির স্ল্যাং বা ডায়ালেক্ট বারবার ভুল বিশ্লেষণ করে বেশি কনটেন্ট রিমুভ করতে পারে। একটি র‍্যাংকিং মডেল ছোট বিক্রেতাদের চাপা দিতে পারে যদি তারা বড় ব্র্যান্ডের সাধারণ প্যাটার্ন মেলে না।

যদি আপনি Koder.ai-এর মতো চ্যাট-চালিত বিল্ডারে AI ফিচার বানান, গতিশীলতা বাস্তব, কিন্তু দায়বদ্ধতার কাজ একই থাকে। আপনাকে এখনও স্পষ্ট হতে হবে মডেল কোথায় ব্যর্থ হতে পারে এবং ব্যর্থ হলে কে মূল্য চুকাবে।

লঞ্চের আগে ন্যূনতম ডকুমেন্টেশন কী থাকা উচিত

লঞ্চের আগে আপনার কাছে এমন কয়েকটি ডকুমেন্ট থাকা প্রয়োজন যা একটি প্রশ্নের উত্তর দেয়: আমরা কি তৈরি করেছি, এটা কার জন্য, এবং কী ভুল হতে পারে? সংক্ষিপ্ত রাখুন, কিন্তু প্রতিটি দাবিকে পরীক্ষা যোগ্য রাখুন।

লিখিতভাবে থাকার ন্যূনতম সেট:

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

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

একজন নির্দিষ্ট মালিক রাখুন ডকস আপ টু ডেট রাখার জন্য (সাধারণত ফিচারের প্রোডাক্ট মালিক, লিগ্যাল নয়)। কডেন্স নির্দিষ্ট করুন (প্রতি রিলিজ বা প্রতি মাসে), এবং কোনো ঘটনায় তাৎক্ষণিক আপডেট করার নিয়ম।

সুরাহাটি খাঁটি ও বাস্তব রাখুন। "উচ্চ নির্ভুলতা"র মত কথা বলা থেকে বিরত থাকুন যদি আপনি টেস্ট সেট, মেট্রিক ও যে ব্যর্থতা ঠিক করা হয়নি তা না বলে।

ডেটা ডকুমেন্টেশন: কী রেকর্ড করবেন এবং কতটা বিস্তারিত

ভাল ডেটা নোট দুই কাজ করে: ব্যবহারকারীরা খুঁজে পাওয়ার আগেই ব্যর্থতা পূর্বাভাস করতে সাহায্য করে, এবং ভবিষ্যৎ সহকর্মীদের একটি পরিষ্কার কারণ দেয় সিস্টেমকে বিশ্বাস (বা বিশ্বাস না) করার।

প্রয়োজনীয় বিস্তারিত স্তর হওয়া উচিত—"কঠিন প্রশ্নগুলো ১০ মিনিটে উত্তর দিতে পর্যাপ্ত।" আপনি থিসিস লিখছেন না; আপনি সেই তথ্য লিখছেন যা কেউ বাগ রিপোর্ট, প্রাইভেসি পর্যালোচনা, বা কাস্টমার অভিযোগের সময়ে দরকার হবে।

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

প্রতিনিধিত্বযোগ্যতা (representativeness) একটি আলাদা লাইন দাবি করে। কি অনুপস্থিত তা নাম দিন: অঞ্চল, ভাষা, ডিভাইস, অ্যাক্সেসিবিলিটি চাহিদা, ব্যবহারকারীর ধরন, বা এজ কেস। সরলভাবে লিখুন: "প্রধানত US English মোবাইল ব্যবহারকারী" বা "ছোট ব্যবসা থেকে উদাহরণ কম"।

যদি আপনি মানব লেবেল ব্যবহার করেন, লেবেলার প্রেক্ষাপট ডকুমেন্ট করুন (প্রবীণ বিশেষজ্ঞ বনাম ক্রাউড), তাদের নির্দেশনাগুলো কী ছিল, এবং কোথায় মতবিরোধ হয়েছিল। মতবিরোধ লুকানোর জন্য নয়—এটা রWarn সংকেত যে ডিজাইনকে সেই অনুযায়ী করতে হবে।

সীমাবদ্ধতা ডকুমেন্টেশন: প্রান্তগুলো দৃশ্যমান করুন

সীমাবদ্ধতার ডকসগুলো হল যেখানে আপনি "ডেমোতে কাজ করেছে" থেকে এগোবেন到 "এই ফিচার নিরাপদে কি সামলাতে পারে"। যদি আপনি কেবল সুখী পথ লিখেন, ব্যবহারকারীরা আপনাদের পরিবর্তে এজগুলো খুঁজে বের করবে।

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

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

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

তারপর একটি একক সতর্কবার্তা তৈরি করুন যা আপনি প্রোডাক্টে পুনরায় ব্যবহার করতে পারেন:

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

মডেল, প্রম্পট বা নীতি বদলালে এই নোট আপডেট করুন।

ব্যবহারকারী ক্ষতি মূল্যায়ন: উদ্বেগকে লিখিত ঝুঁকি মানচিত্রে পরিণত করুন

একটি ক্ষতি মূল্যায়ন কোনো বিমূর্ত নীতিবাদের আলাপ নয়। এটি একটি সংক্ষিপ্ত ডকুমেন্ট যা বলে: যদি এই ফিচার ভুল করে, কে ক্ষতিগ্রস্ত হতে পারে, কিভাবে, এবং আমরা লঞ্চের আগে ও পরে কী করব।

শুরুতে বিস্তৃত শ্রেণি নিয়ে শুরু করুন যাতে আপনি স্পষ্ট বিষয় মিস না করেন: সুরক্ষা, বৈষম্য, গোপনীয়তা, প্রতারণা, ও নির্ভরযোগ্যতা।

প্রতিটি ক্ষতিকে বাস্তব পরিস্থিতিতে রূপ দিন। প্রতিটি শ্রেণির জন্য এক বা দুটি কনক্রিট গল্প লিখুন: ব্যবহারকারী কে, তারা কী চায়, মডেল কী আউটপুট দিতে পারে, এবং ব্যবহারকারী কী করবে। মূল কথা হচ্ছে কার্যপ্রবাহ। একটি ভুল উত্তর বিরক্তিকর; একটি ভুল উত্তর যে চিকিৎসাগত সিদ্ধান্ত বা অর্থ লেনদেনকে ট্রিগার করে তা অনেক বড়।

প্রাধান্য নির্ধারণের জন্য সহজ স্কেল ব্যবহার করুন। প্রতিটি দৃশ্যের জন্য তীব্রতা (কম, মধ্য, উচ্চ) এবং সম্ভাব্যতা (কম, মধ্য, উচ্চ) চিহ্নিত করুন। আপনার নরমির সঠিক সংখ্যার দরকার নেই—একটি শেয়ার করা দৃষ্টিভঙ্গি দরকার যে কোন কাজগুলো এখনই গুরুত্ব পায়।

শেষে, মালিক নির্ধারণ করুন। নামহীন mitigation আসলে mitigation নয়। প্রতিটি দৃশ্যের জন্য লঞ্চের আগে mitigation (গার্ড্রেল, UX সতর্কতা, ব্লক করা টপিক, লগিং), লঞ্চের পরে mitigation (সাপোর্ট প্লেবুক, মনিটরিং, রোলব্যাক ট্রিগার), এবং কে জবাবদিহি করবে তা লিখে রাখুন।

ধাপে ধাপে: প্রোটোটাইপ থেকে রিলিজ পর্যন্ত কিভাবে ফিচার গেট করবেন

গেটিং হলো কিভাবে আপনি "আমরা এটা তৈরি করতে পারি" থেকে "আমরা এটা শিপ করা উচিত" এ যান। এটিকে এক সেট এক্সিট হিসেবে ধরুন: পরের এক্সিট পার হচ্ছেন না যতক্ষণ না বেসিকগুলো লেখা, রিভিউ করা, এবং টেস্ট করা হয়।

1. উদ্দেশ্য ও সিদ্ধান্ত যা এটি প্রভাবিত করে লিখুন। কার জন্য, তারা কি সিদ্ধান্ত নেবে, এবং আউটপুট ভুল হলে কী হবে—স্পষ্ট করুন।

2. ডেটা ও সীমাবদ্ধতার নোট আগেভাগে খসড়া করুন। UI পালিশের আগে করুন, যখন ফিচারটি reshape করা সহজ।

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

4. ইউজার মেসেজিং, ফ্যালব্যাক, ও এসক্যালেশন যোগ করুন। মডেল যখন রিফিউজ করে, অনিশ্চিত হয়, বা খারাপ করে তখন ব্যবহারকারী কী দেখবে তা ঠিক করুন। একটি নিরাপদ ডিফল্ট দিন (যেমন "মানুষকে জিজ্ঞাসা করুন") এবং খারাপ উত্তর রিপোর্ট করা সহজ করুন।

5. মনিটরিং, ইনসিডেন্ট, ও রোলব্যাক সংজ্ঞায়িত করুন। আপনি কোন সিগনাল দেখবেন (অভিযোগ, রিভার্সাল রেট, পতাকা দেওয়া আউটপুট), কে এলার্ট পাবে, এবং "ফিচার বন্ধ" দেখতে কেমন হবে নির্দিষ্ট করুন।

যদি কোনো ধাপ কঠিন লাগে, সেই ঘর্ষণ প্রায়ই বলে দিচ্ছে ঝুঁকি কোথায়।

দলগুলো যে সাধারণ ভুলগুলো করে

বিশ্বাস ভঙ্গ করার সবচেয়ে দ্রুত উপায় হলো ল্যাবে ভাল স্কোর পেয়ে নিজেকে নিরাপদ মনে করা। বেঞ্চমার্ক সাহায্য করে, কিন্তু তা দেখায় না মানুষ কিভাবে ফিচারকে ঠেলে দিবে, ভুলবোঝাবে, বা নির্ভর করবে দৈনন্দিন কাজে।

আরেকটি সাধারণ ব্যর্থতা হলো অনিশ্চয়তা লুকানো। যদি আপনার সিস্টেম সবসময় একই আত্মবিশ্বাস নিয়ে কথা বলে, ব্যবহারকারীরা ধরে নেবে এটা সবসময় সঠিক। এমনকি একটি সাধারণ "নিশ্চিত নয়" পথ বা উত্তর কিসের ওপর ভিত্তি করে তা জানালে মানুষ অস্থির আউটপুটকে fact ধরে নেওয়া থেকে বিরত থাকবে।

টিমগুলো প্রায়শই নিজেদের অভ্যাস দিয়ে টেস্ট করে। অভ্যন্তরীণ প্রম্পটগুলো ভদ্র ও প্রত্যাশিত হয়; বাস্তব ব্যবহারকারী ক্লান্ত, তাড়াহুড়ো, এবং সৃজনশীল। তারা গন্দা টেক্সট পেস্ট করে, ফলো-আপ করে, বা মডেলকে ভাঙার চেষ্টা করে।

পাঁচটি ভুল বারবার দেখা যায়:

• বেঞ্চমার্ক বা অফলাইন ইভ্যালকে লঞ্চ সিদ্ধান্ত হিসেবে দেখা
• একবারে নিশ্চিত উত্তর চাপানো; "আমি জানি না" বা "রিভিউ দরকার" না রাখা
• শুধু টিম-লিখিত প্রম্পট দিয়ে টেস্ট করা এবং বাস্তব মেসি ইনপুট ফেলে দেওয়া
• লঞ্চের পরে ডকুমেন্ট লেখা এবং কখনো আপডেট না করা
• রোলব্যাক পথ ছাড়া শিপ করা

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

একটি কংক্রিট উদাহরণ: যদি আপনি একটি অ্যাপ বিল্ডারের ভিতরে AI অ্যাসিস্ট্যান্ট ডেপ্লয় করেন, অস্পষ্ট অনুরোধে ("Airbnb-এর মতো করুন"), দ্বন্দ্বপূর্ণ চাহিদায়, ও সংবেদনশীল কনটেন্টে টেস্ট করুন। তারপর একটি স্পষ্ট রোলব্যাক প্ল্যান রাখুন (স্ন্যাপশট, ভার্জনিং, দ্রুত ডিসেবল সুইচ) যাতে ব্যবহারকারীরা ক্ষতি রিপোর্ট করলে আপনি দ্রুত ব্যবস্থা নিতে পারেন।

দ্রুত চেকলিস্ট যা আপনি আপনার স্পেসে কপি করে ব্যবহার করতে পারেন

নীচেরটিকে আপনার প্রোডাক্ট স্পেসে পেস্ট করুন এবং শিপ করার আগে পূরণ করুন। সংক্ষিপ্ত রাখুন, কিন্তু প্রতিটি উত্তর স্পষ্ট করে দিন। নাম উল্লেখ করুন প্রতিটি ঝুঁকির জন্য একটি মালিক।

### 1) Purpose and affected people
- Feature name:
- What decision or action does the AI support (one sentence):
- Who uses it:
- Who is affected even if they never use it (customers, employees, bystanders):
- What a “good” outcome looks like:

### 2) Data used (training, tuning, retrieval, logs)
- Data sources (where it came from and why it’s allowed):
- What you excluded (and why):
- Sensitive data involved (PII, health, finance, kids):
- Data retention period and deletion plan:
- Security and access controls:

### 3) Limits and “do not use” zones
- Known failure modes (give 3-5 concrete examples):
- Languages supported and not supported:
- Inputs it should refuse (or route to a human):
- Cases where it must not be used (legal, medical, hiring, etc.):

### 4) User harm assessment
- Top 5 harms (ranked):
- Mitigation for each harm:
- Who owns each mitigation (name + team):
- What you will tell users (warnings, confidence cues, citations):

### 5) Operations after launch
- Monitoring signals (quality, complaints, bias flags, cost spikes):
- Human review path (when and how escalation happens):
- Rollback trigger (exact threshold or condition):
- Snapshot/version you can revert to: