এআই দিয়ে অ্যাপ তৈরি করার সময়ে সাধারণ ভুলগুলো — অস্পষ্ট লক্ষ্য, দুর্বল প্রম্পট, মূল্যায়নের অভাব, এবং UX ফাঁক — এবং এগুলো কীভাবে এড়ানো যায় তা নিয়ে একটি বাস্তবধর্মী গাইড।
কেন এআই অ্যাপ প্রজেক্টগুলো শুরুর দিকে ব্যর্থ হয় (ভালো আইডিয়াও থাকলে)\n\nশুরুতে এআই অ্যাপগুলো সহজ মনে হয়: আপনি একটি API সংযুক্ত করেন, কয়েকটা প্রম্পট লেখেন, ডেমো দেখায় চমৎকার। তারপর রিয়েল ইউজার আসে অগোছালো ইনপুট, অস্পষ্ট লক্ষ্য ও এজ কেস নিয়ে—এবং হঠাৎ অ্যাপটি অসঙ্গতিপূর্ণ, ধীর, বা আত্মবিশ্বাসী কিন্তু ভুল হয়ে পড়ে।\n\nএকটি “নবীন ভুল” দক্ষতার অভাব নয়। এটা এমন একটি নতুন ধরনের উপাদান নিয়ে কাজ করার সমস্যা: একটি মডেল যা প্রোবাবিলিস্টিক, প্রাসঙ্গিকতায় সংবেদনশীল, এবং মাঝে মাঝে বিশ্বাসযোগ্য জবাব উদ্ভাবন করে। বহু প্রথম ব্যর্থতা হয় কারণ দলেরা ঐ উপাদানটিকে সাধারণ লাইব্রেরির কলের মতো আচরণ করে—নির্ধারিত, সম্পূর্ণ নিয়ন্ত্রণযোগ্য, এবং ব্যবসার সাথে আগেই সঙ্গত।\n\n### কীভাবে এই গাইডটি ব্যবহার করবেন\n\nগাইডটি ঝুঁকি দ্রুত কমাতে স্ট্রাকচার করা হয়েছে। সর্বোচ্চ প্রভাব ফেলতে পারে এমন সমস্যা প্রথমে ঠিক করুন (প্রব্লেম নির্বাচন, বেসলাইন, মূল্যায়ন, ট্রাস্টের জন্য UX), তারপর অপ্টিমাইজেশনে যান (খরচ, লেটেন্সি, মনিটরিং)। যদি আপনার কাছে কেবল কয়েকটা পরিবর্তনের সময় থাকে, সেগুলো অপ্রকাশিত ব্যর্থতা রোধ করবে এমনগুলোকে অগ্রাধিকার দিন।\n\n### একটি দ্রুত মানসিক মডেল\n\nআপনার এআই অ্যাপকে একটি চেইন হিসেবে ভাবুন:\n\n- ইনপুট: ব্যবহারকারীর বার্তা, ফাইল, ডাটাবেস রেকর্ড, উদ্ধার করা ডকুমেন্ট\n- মডেল: প্রম্পট, টুল/ফাংশন, সীমাবদ্ধতা, কনটেক্সট উইন্ডো\n- আউটপুট: মডেলের প্রতিক্রিয়া, সূত্র(সিস্টেশন), নেয়া অ্যাকশন\n- ব্যবহারকারীর প্রভাব: সিদ্ধান্ত, সময় সাশ্রয় (বা ক্ষতি), আস্থা অর্জন (বা নষ্ট)\n\nপ্রজেক্টগুলো যখন শুরুর দিকে ব্যর্থ হয়, ভাঙ্গন সাধারণত “মডেল খারাপ” নয়। এটা যে চেইনের কোনো লিংক অজ্ঞাত, অটেস্ট করা হয়নি, বা বাস্তব ব্যবহারের সাথে অসঙ্গত—এটাই মূল কারণ। নিম্নের সেকশনগুলো সবচেয়ে সাধারণ দুর্বল লিংকগুলো দেখায়—এবং প্র্যাকটিক্যাল ফিক্স যেগুলো আপনি খুব বেশি কিছু পুনর্নির্মাণ না করেই প্রয়োগ করতে পারবেন।\n\nএকটি বাস্তব টিপ: যদি আপনি দ্রুত এগোচ্ছেন, এমন পরিবেশ ব্যবহার করুন যেখানে আপনি নিরাপদে ইটারেট করতে পারেন এবং তৎক্ষণাৎ রোলব্যাক করতে পারবেন। Koder.ai-এর মতো প্ল্যাটফর্ম (চ্যাটের মাধ্যমে ওয়েব, ব্যাকএন্ড ও মোবাইল অ্যাপ বানানোর জন্য একটি ভাইব-কোডিং প্ল্যাটফর্ম) এখানে সাহায্য করতে পারে কারণ আপনি ফ্লো দ্রুত প্রোটোটাইপ করতে পারবেন, ছোট পরিবর্তন রাখবেন, এবং স্ন্যাপশট/রোলব্যাক-এ নির্ভর করতে পারবেন যখন কোনো পরীক্ষা মান কমায়।\n\n## ভুল #1: এআই দিয়ে ভুল সমস্যা সমাধান করা\n\nএকটি সাধারণ ব্যর্থতা হলো প্রথমে বলা: “চল এআই যুক্ত করি” এবং তারপর ব্যবহার করার জায়গা খোঁজা। ফলাফল হচ্ছে এমন একটি ফিচার যা ডেমোতে কার্যকর মনে হলেও বাস্তবে প্রাসঙ্গিক নয় (বা বিরক্তিকর)।\n\n### কাজটি (job-to-be-done) দিয়ে শুরু করুন\n\nমডেল বাছাই বা প্রম্পট ডিজাইন করার আগে, প্লেইন ভাষায় ব্যবহারকারীর কাজটি লিখুন: তারা কী অর্জন করতে চায়, কোন প্রসঙ্গে, আর আজ সেটা কেন কঠিন?\n\nতারপর মাপযোগ্য সাফল্যের ক্রাইটেরিয়া নির্ধারণ করুন। উদাহরণ: “রিপ্লাই ড্রাফট করতে সময় 12 মিনিট থেকে 4 মিনিটে নামানো”, “প্রথম-রেসপন্স ত্রুটি 2% এর নিচে আনা”, বা “ফর্ম সম্পন্নতার হার 10% বাড়ানো।” যদি আপনি মাপতে না পারেন, আপনি বলতে পারবেন না যে এআই সাহায্য করেছে।\n\n### একটুকু সরু v1 কেস বেছে নিন (এবং কী বাদ দেবেন তা ঠিক করুন)\n\nনবীনরা প্রায়ই সব-কিছু জানে এমন অ্যাসিস্ট্যান্ট বানানোর চেষ্টা করে। v1-এ, একটি মাত্র ওয়ার্কফ্লো ধাপ বেছে নিন যেখানে এআই স্পষ্ট মূল্য যোগ করতে পারে।\n\nভালো v1 গুলো সাধারণত:\n\n- বিদ্যমান প্রক্রিয়ার মধ্যে ফিট করে (হঠাৎ পুরোপুরি বদলে দেয় না)\n- স্পষ্ট ইনপুট ও প্রত্যাশিত আউটপুট থাকে\n- কিছুই অনিবার্য হওয়ার আগে একটি মানুষ পর্যালোচনা করতে পারে\n\nততটুকু গুরুত্বপূর্ণ: স্পষ্টভাবে তালিকা করুন v1-এ কী ইনক্লুডেড হবে না (অতিরিক্ত টুল, বহু ডেটা সোর্স, এজ-কেস অটোমেশন)। এতে স্কোপ বাস্তববাদী থাকে এবং শেখা দ্রুত হয়।\n\n### কী অবশ্যই সঠিক হতে হবে বনাম কী “সাহায্যকারী” হতে পারে তা নির্ধারণ করুন\n\nপ্রতিটি আউটপুটের জন্য একই সঠিকতার প্রয়োজন নেই।\n\n- অবশ্যই সঠিক হতে হবে: সংখ্যা, নীতি বিবৃতি, আইনি/চিকিৎসা দাবি, ইমেইল/পেমেন্ট ট্রিগার করে এমন অ্যাকশন\n- সাহায্যকারী হতে পারে: ব্রেইনস্টর্মিং, টোন রিরাইট, সারসংক্ষেপ, সুপারিশকৃত পরবর্তী ধাপ\n\nএ লাইন আগে টানুন। এটা নির্ধারণ করবে আপনাকে কঠোর গার্ডরেইল, সূত্র, মানব অনুমোদন লাগবে কি না, অথবা একটি “ড্রাফট সহায়ক” যথেষ্ট হবে কি না।\n\n## ভুল #2: তুলনা করার জন্য বেসলাইন নেই\n\nঅনেক এআই প্রজেক্ট শুরু হয় “চল এলএলএম যোগ করি” বলেই এবং কখনও উত্তর করে না: তুলনায় কি?\n\nআপনি যদি বর্তমান কাজপ্রবাহ নথিভুক্ত না করেন (বা একটি নন-এআই ভার্সন তৈরি না করেন), আপনি বলতে পারবেন না মডেল সাহায্য করছে, ক্ষতি করছে, না শুধু কাজকে এক জায়গা থেকে অন্য জায়গায় সরাচ্ছে। দলগুলো মতামত নিয়ে ঝগড়া করে, ফলাফল মাপেও না।\n\n### মডেল স্পর্শ করার আগে একটি বেসলাইন তৈরি করুন\n\nসবচেয়ে সহজ যা কাজ করতে পারে সেটা দিয়ে শুরু করুন:\n\n- রুলস-ভিত্তিক ফ্লো (if/then চেক, কীওয়ার্ড রাউটিং, অনিবার্য ফিল্ড)
রিটেনশন লিমিট সেট করুন, কারা কনভারসেশন দেখতে পারে সেটা সীমাবদ্ধ করুন, এবং আলাদা রাখুন ডেভ বনাম প্রোড। উচ্চ-ঝুঁকির অ্যাপগুলোর জন্য অডিট ট্রেইল ও রিভিউ ওয়ার্কফ্লো যোগ করুন যাতে আপনি প্রমাণ করতে পারেন কে কী দেখেছে এবং কেন।\n\nনিরাপত্তা, গোপনীয়তা, ও কমপ্লায়েন্স কাগজপত্র নয়—এগুলো প্রোডাক্ট রিকোয়ারমেন্ট।\n\n## ভুল #10: প্রথম দিন থেকেই খরচ ও লেটেন্সি না ম্যানেজ করা\n\nএকটি সাধারণ নবীন অবাক হওয়া: ডেমো তৎক্ষণাৎ এবং সস্তা মনে হয়, তারপর বাস্তব ব্যবহার ধীর ও দামী করে তোলে। এটা সাধারণত হয় কারণ টোকেন ব্যবহার, রিট্রাই, এবং “বড় মডেলে স্যুইচ করে দিন” সিদ্ধান্তগুলো নিয়ন্ত্রণহীন রাখলে।\n\n### খরচ ও লেটেন্সি আসলে কোথা থেকে আসে\n\nবড় ড্রাইভারগুলো প্রায়ই পূর্বানুমানযোগ্য:\n\n- প্রতিটি অনুরোধে বড় চ্যাট ইতিহাস বা পুরো ডক পাঠানো\n- (সার্চ, ডাটাবেস লুকআপ, ওয়েব ব্রাউজিং): প্রতিটি টুল কল রাউন্ড ট্রিপ বাড়ায়\n- “প্ল্যান → রিসার্চ → ড্রাফট → রিভাইজ” টোকেন ও সময় গুণ করে\n- টাইমআউটের সাইলেন্ট রিট্রাই, বড় মডেলে অটোমেটিক স্যুইচিং\n\n### প্রোডাক্টে গার্ডরেইল রাখুন, লোকের মাথায় না\n\nপ্রোটোটাইপের জন্যও স্পষ্ট বাজেট নির্ধারণ করুন:\n\n- প্রতিটি অনুরোধ ও সেশনের জন্য \n- মাল্টি-এজেন্ট ফ্লোতে \n- টাইমআউট ওGraceful partial response পরিকল্পনা\n- পুনরাবৃত্ত প্রশ্ন, এমবেডিং, টুল রেজাল্টের জন্য ক্যাশিং\n\nপ্রম্পট ও রিট্রিভাল ডিজাইনও এমন করে করুন যাতে আপনি অপ্রয়োজনীয় টেক্সট পাঠান না—উদাহরণ: পুরানো কনভারসেশন টার্নগুলোর সারাংশ পাঠান, এবং পুরো ফাইল না পাঠিয়ে শীর্ষ প্রাসঙ্গিক স্নিপেটAttach করুন।\n\n### যে মেট্রিকটি গুরুত্বপূর্ণ সেটি ট্র্যাক করুন\n\n"প্রতি অনুরোধ খরচ" অপ্টিমাইজ করবেন না—অপ্টিমাইজ করুন (উদাহরণ: “ইস্যু রেজলভড”, “ড্রাফট গ্রহণ”), কারণ ব্যর্থ রিট্রাই করে দুইবার চেষ্টা করা বাস্তবে বেশি খরচ বার করে।\n\nআপনি যদি প্রাইসিং টিয়ার পরিকল্পনা করেন, শুরুর দিকে সীমা আঁকুন (দেখুন /pricing) যাতে পারফরম্যান্স ও ইউনিট ইকোনমিক্স পরে সমস্যায় না ফেলে।\n\n## ভুল #11: মনিটরিং ও ধারাবাহিক উন্নতি বাদ দেয়া\n\nঅনেক নবীন "দায়িত্বশীল" হয়ে লগ সংগ্রহ করে—তারপর সেগুলো কখনও না দেখে রাখে। অ্যাপ ধীরে ধীরে дег্রেড করে, ব্যবহারকারীরা ওয়ার্কঅ্যারাউন্ড বানায়, এবং দল আন্দাজ করে কী ভুল হচ্ছে।\n\n### শুধু লগ না—শেখার জন্য লাগান\n\nমনিটরিংয়ের কাজ হওয়া উচিত: কয়েকটি হাই-সিগন্যাল ইভেন্ট ট্র্যাক করুন:\n\n- (নির্বাচিত টাস্ক, পেইজ, বা ফ্লো), কেবল কাঁচা টেক্সট নয়\n- (হ্যালুসিনেশন, ভুল টুল কল, রিট্রিভাল মিস, ফরম্যাটিং ত্রুটি)\n- (ব্যবহারকারী এডিট, রিট্রাই, "regenerate", ম্যানুয়াল ওভাররাইড)\n\nএই সিগন্যালগুলো "টোকেন ব্যবহার" ছাড়া বেশি actionable।\n\n### একটি সরল ফিডব্যাক লুপ তৈরি করুন\n\nখারাপ উত্তর চিহ্নিত করার সহজ উপায় দিন (থাম্বস ডাউন + ঐচ্ছিক কারণ)। তারপর এটাকে অপারেশনাল বানান:\n\n1. নতুন নেগেটিভস দৈনিক/সাপ্তাহিক পর্যালোচনা করুন\n2. দিন কী ভুল হয়েছে (একটি ধারাবাহিক ট্যাক্সোনমি)\n3. প্রতিনিধিত্বমূলক কেসগুলিকে একটি -এ রূপান্তর করুন\n4. প্রতিটি রিলিজের আগে ঐ ইভ্যাল সেট পুনরায় চালান যাতে রিগ্রেশন না হয়\n\nসময়কালে, আপনার ইভ্যাল সেট প্রোডাক্টের "ইমিউন সিস্টেম" হয়ে উঠবে।\n\n### পুনরাবৃত্ত সমস্যা ট্রায়াজ করুন\n\nনম্র ট্রায়াজ প্রসেস রাখুন যাতে প্যাটার্নগুলো হারিয়ে না যায়:\n\n- প্রধান পুনরাবৃত্ত সমস্যাগুলোর জন্য একজন মালিক\n- স্পষ্ট সিদ্ধান্ত: প্রম্পট পরিবর্তন, রিট্রিভাল ঠিক করা, UX পরিবর্তন, বা গার্ডরেইল
সাধারণ প্রশ্ন
How do I know whether I’m solving the right problem with AI?
প্রথমে plain ভাষায় job-to-be-done লিখুন এবং মাপজোক যোগ করুন (উদাহরণ: সময় বাঁচানো, ত্রুটির হার কমানো, সম্পন্নতা বৃদ্ধির হার)। তারপর একটি সঙ্কুচিত v1 ধাপ বেছে নিন যা বিদ্যমান কার্যপ্রবাহে বসে এবং স্পষ্টভাবে কী না করা হবে তা তালিকাভুক্ত করুন।
যদি আপনি "ভাল হয়েছে" মাপতে না পারেন, আপনি ডেমো অপটিমাইজ করে ফেলবেন ফলাফল নয়।
What’s a good baseline for an AI feature, and why does it matter?
বেসলাইন হলো আপনার নন-এআই (বা ন্যূনতম-এআই) কন্ট্রোল যাতে আপনি সঠিকতা, গতি এবং ব্যবহারকারীর সন্তুষ্টি তুলনা করতে পারেন।
প্রায়োগিক বেসলাইনগুলোর মধ্যে আছে:
রুলস-ভিত্তিক রাউটিং/ভ্যালিডেশন
টেমপ্লেট ও ম্যাক্রো
FAQ-এ সার্চ
শুধুই মানুষ-in-the-loop (পরিষ্কার কিউ + SOP)
এ ছাড়া, এর সীমা জানলে আপনি ROI প্রমাণ করতে পারবেন—ইতরথে না জানলে বলতে পারবেন না যে এআই কার্যপ্রণালী উন্নত করেছে কিনা।
How can I make prompts more reliable than “prompt until it works”?
প্রম্পটকে "প্রম্পট যতক্ষণ না কাজ করে ততক্ষণ কষো" মানসিকতার বাইরে নিয়ে যান—প্রম্পট লিখুন যেমনটা প্রোডাক্ট রিকোয়ারমেন্ট লেখা হয়:
ভূমিকা (role) নির্ধারণ করুন
কাজ (task) এবং এক্সেপ্টেন্স ক্রাইটেরিয়া স্পষ্ট করুন
তারপর দুই-একটি ভালো উদাহরণ এবং অন্তত একটি কাউন্টার-উদাহরণ যোগ করুন—"এটা করা যাবে না"—যাতে ভুল আত্মবিশ্বাসী উত্তর কমে।
Why does my AI confidently answer incorrectly about company-specific details?
মডেলকে আপনার বর্তমান নীতিমালা, মূল্য, রোডম্যাপ বা কাস্টমার ইতিহাস জানা ধরে না নিন।
যদি উত্তর আপনার অভ্যন্তরীণ সত্যের সাথে মিলতে হবে, আপনাকে সেই সত্য সরবরাহ করতে হবে—অনুমোদিত ডক, ডাটাবেস রেজাল্ট বা উদ্ধার করা উদ্ধৃতি হিসেবে—এবং মডেলকে সেগুলো উদ্ধৃত/কোট করতে বলুন। না হলে নিরাপদ ফালব্যাক দিন: "প্রদত্ত সোর্স অনুযায়ী আমি নিশ্চিত না—যেভাবে যাচাই করবেন তা এখানে।"
What are the most common RAG mistakes, and how do I fix them quickly?
রিট্রিভাল মানেই সঠিকতা নিশ্চিত করে না। সাধারণ ব্যর্থতা: খারাপ চাংকিং (মাঝেই কেটে দেওয়া), কীওয়ার্ড মিলানো যা অর্থ মিলায় না, পুরানো ডকুমেন্ট, এবং অনেক নিম্নমানের কাংক পাস করা।
বিস্বাসযোগ্যতা বাড়াতে:
প্রাসঙ্গিকতার থ্রেশহোল্ড ও "কোনো উত্তর নেই" আচরণ
near-duplicate চাংক ডিডুপ্লিকেট করা
কম কিন্তু উচ্চমানের সোর্স পছন্দ করা
ডক টাইটেল + এক্সরাপ্ট + আপডেট ডেট দেখানো সাইটেশনের জন্য
যদি কোট করা না যায়,_fact হিসেবে দেখাবেন না।
What’s the minimum evaluation setup I need before shipping?
ছোট, প্রতিনিধিত্বমূলক ইভ্যালুয়েশন সেট (30–100 কেস) দিয়ে শুরু করুন যার মধ্যে আছে:
সাধারণ "মানি" ফ্লো
বিভ্রান্তিকর ইনপুট (মিসিং কনটেক্সট, টাইপো)
ঝুঁকিপূর্ণ অনুরোধ (নীতিসম্মত, আইনি/চিকিৎসা, PII)
কয়েকটি ধারাবাহিক চেক ট্র্যাক করুন:
সঠিকতা (কার্যকরী পর্যায়ে ঠিক আছে কি?)
রিজেকশন/ক্ল্যারিফিকেশন গুণ
ফরম্যাট ভ্যালিডিটি (JSON/ফিল্ড)
How do I test beyond happy paths so production doesn’t fall apart?
পরিকল্পনা করুন কী হবে ব্যর্থতার প্রতিটি ক্ষেত্রে (রিট্রাই, পাটিশনাল ফলাফল, ক্লিয়ার মেসেজ) যাতে সিস্টেম নীরব না থেকে ব্যর্থতার কথা ব্যবহারকারী বুঝতে পারে।
What UX changes increase trust in an AI app?
যথাযথ যাচাই ডিফল্ট করুন:
তাত্ক্ষণিকভাবে সোর্স/সিটেশন দেখানো
যেখানে সোর্স নেই, সেখানে এডিটেবল ড্রাফট দেখান ("অধিকৃত উত্তর" নয়)
ইনপুট অসম্পূর্ণ হলে ১–২টি ক্ল্যারিফাইং প্রশ্ন জিজ্ঞেস করুন
লক্ষ্য: নিরাপদ আচরণটাই ব্যবহারকারীর জন্য দ্রুততম পথ হবে।
What are the key safety and privacy practices for beginner AI apps?
সহজ কথায় একটি "রিজেক্ট বা এসক্যালেট" নীতি লিখুন—কি প্রশ্ন প্রত্যাখ্যান করা হবে (আত্মহত্যা নির্দেশিকা, অবৈধ কাজ, চিকিৎসা/আইনি পরামর্শ, হেনস্থা) এবং কী ঘটনা মানব পর্যালোচনার দরকার (অ্যাকাউন্ট পরিবর্তন, উচ্চ-ঝুঁকির সুপারিশ, মাইনরের ব্যাপারে)। এই নীতিটি প্রোডাক্টে বাধ্যতামূলক করুন।
PII-কে ঝুঁকিপূর্ণ মনে করুন: সংরক্ষণ কম রাখুন, লগ করার আগে রিডাক্ট/টোকেনাইজ করুন, সংরহনের জন্য স্পষ্ট সম্মতি নিন। লগ অ্যাক্সেস সীমাবদ্ধ করুন এবং ডেভ/প্রোড আলাদা রাখুন।
How can I control cost and latency from day one?
প্রধান চালকরা সচরাচর: কন্টেক্সট দৈর্ঘ্য, টুল রাউন্ডট্রিপ, মাল্টি-স্টেপ চেইন, রিট্রাই/ফলব্যাক।
কোডে কঠোর সীমা লাগান:
প্রতি অনুরোধ/সেশন max tokens
max টুল কল/স্টেপ
টাইমআউট + আংশিক/ফলব্যাক UX
ক্যাশিং (প্রতিবারের প্রশ্ন, এমবেডিং, টুল রেজাল্ট)
"প্রতি অনুরোধ খরচ" নয়—"প্রতি সফল টাস্ক খরচ" অপ্টিমাইজ করুন। ব্যর্থ রিট্রাই ও ডাবল-চেষ্টা বদলে বেশি খরচ বাড়ায়।
নবীনদের সাধারণ এআই অ্যাপ বানানোর ভুল এবং সমাধান | Koder.ai
শুধুমাত্র মানুষ-in-the-loop (পরিষ্কার কিউ + ম্যাক্রো) আপনার “কন্ট্রোল” হিসেবে\n\nএই বেসলাইন হবে আপনার মানদণ্ড—সঠিকতা, গতি এবং ব্যবহারকারীর সন্তুষ্টির জন্য। এটি দেখায় কাজটির কোন অংশই আসলে “ভাষাগতভাবে কঠিন” এবং কোন অংশ শুধু স্ট্রাকচারের অভাব।\n\n### সাধারণ মেট্রিক দিয়ে ROI অনুমান করুন\n\nকয়েকটি মাপযোগ্য ফলাফল বেছে নিন এবং বেসলাইন ও এআই উভয়ের জন্য ট্র্যাক করুন:\n\n- প্রতি টাস্কে সময় সাশ্রয় (প্রতি টিকিট/প্রতি ড্রাফট/প্রতি বিশ্লেষণে মিনিট)\n- ত্রুটি হ্রাস (কম এসকালেশন, কম রিওয়ার্ক)\n- কনভার্শন লিফট (বেশি সাইন-আপ, কম ড্রপ-অফ)\n\n### কখন এআই ভুল টুল, তা জানুন\n\nযদি কাজটি নির্ধারিত (ডিটারমিনিস্টিক) হয় — ফরম্যাটিং, ভ্যালিডেশন, রাউটিং, ক্যালকুলেশন — তাহলে এআইকে পুরো কাজ দেওয়ার দরকার নাও থাকতে পারে; শুধু টোন রিরাইটিংয়ের মতো ছোট অংশ এআইয়ে রাখা যেতে পারে এবং বাকি রুলস দিয়ে করা উচিৎ। একটি শক্তিশালী বেসলাইন এটা স্পষ্ট করে এবং আপনার “এআই ফিচার”-কে দামী ওভারওয়ার্ক হওয়ার থেকে রক্ষা করে।\n\n## ভুল #3: প্রম্পটকে জাদুর মন্ত্র হিসেবে দেখা\n\nনবীনদের একটি সাধারণ প্যাটার্ন হলো “প্রম্পট যতক্ষণ না কাজ করে ততক্ষণ টুইক করা”: একটি বাক্য ছোটখাটো বদলে একবার ভালো উত্তর পেয়ে নেওয়া—এবং ধরে নেওয়া যে সমস্যা মিটল। সমস্যা হল: অগঠিত প্রম্পটগুলো ব্যবহারকারীদের ভিন্ন ইনপুট, এজ-কেস ও মডেল আপডেটে অন্যভাবে আচরণ করে। যা জেতার মতো দেখাচ্ছিল, তা বাস্তব ডেটা এসে অনিশ্চিত আউটপুটে পরিণত হতে পারে।\n\n### প্রম্পট লিখুন প্রোডাক্ট রিকোয়ারমেন্ট-এর মতো\n\nমডেলের উপর আশা রাখার বদলে কাজটি স্পষ্টভাবে বর্ণনা করুন:\n\n- রোল: মডেলকে কী রূপে আচরণ করতে হবে (উদাহরণ: “বিলিং প্রশ্নের জন্য কাস্টমার সাপোর্ট এজেন্ট”)\n- টাস্ক: কী তৈরি করতে হবে (উদাহরণ: “ইমেইল রিপ্লাই ড্রাফট”)\n- সীমাবদ্ধতা: কি করা যাবে না (উদাহরণ: “নীতি উদ্ভাবন করবেন না; যদি তথ্য fehlt হয় তবে স্পষ্ট প্রশ্ন করুন”)\n- আউটপুট ফরম্যাট: একটি স্কিমা বা টেমপ্লেট (উদাহরণ: JSON কী, বুলেট সেকশন)\n\nএতে অনিশ্চিত অনুরোধকে এমন কিছুতে পরিণত করা হয় যা আপনি টেস্ট ও পুনরুৎপাদনযোগ্য করতে পারেন।\n\n### উদাহরণ এবং কাউন্টার-উদাহরণ ব্যবহার করুন\n\nকঠিন কেসে কয়েকটি ভালো উদাহরণ (“যখন ব্যবহারকারী X জিজ্ঞেস করে, Yর মতো রিপ্লাই দিন”) এবং অন্তত একটি কাউন্টার-উদাহরণ (“Z করবেন না”) যোগ করুন। কাউন্টার-উদাহরণগুলো বিশেষত সহায়ক যখন মডেল আত্মবিশ্বাসী কিন্তু ভুল উত্তর তৈরি করে—যেমন সংখ্যা রচিত করা বা অবাস্তব ডকুমেন্ট উদ্ধৃত করা।\n\n### প্রম্পটকে কোডের মতো ভার্সন করুন\n\nপ্রম্পটকে সম্পদ হিসেবে বিবেচনা করুন: ভার্সন কন্ট্রোলে রাখুন, নাম দিন, ছোট চেঞ্জলগ রাখুন (কি বদলেছে, কেন, প্রত্যাশিত প্রভাব)। যখন মান কমে, আপনি দ্রুত রোলব্যাক করতে পারবেন—এবং “গত সপ্তাহে যে প্রম্পটটা ছিল” নিয়ে স্মৃতিচারণ থেকে বিরত থাকবেন।\n\n## ভুল #4: মডেলকে আপনার ব্যবসা জানা ধরে নেওয়া\n\nনবীনরা প্রায়ই এলএলএমকে কোম্পানি-নির্দিষ্ট তথ্য জিজ্ঞাসা করে যা তার কাছে নেই: বর্তমান প্রাইসিং রুল, অভ্যন্তরীণ নীতি, সর্বশেষ প্রোডাক্ট রোডম্যাপ, বা কিভাবে আপনার সাপোর্ট টিম এজ-কেস হ্যান্ডল করে। মডেল তারপরও আত্মবিশ্বাসী উত্তর দিতে পারে—এবং এভাবেই ভুল পরামর্শ রিলিজ হয়।\n\n### মডেল “জানে” এমন জিনিসগুলো আলাদা করুন এবং আপনি যা জানেন তা আলাদা করুন\n\nএকটি এলএলএমকে সাধারণ ভাষা প্যাটার্ন, সারসংক্ষেপ, রিরাইট এবং প্রদত্ত কনটেক্সটের উপর যুক্তি করার ব্যাপারে চমৎকার ভাবুন। এটা আপনার সংগঠনের লাইভ ডাটাবেস নয়। যদিও প্রশিক্ষণে এটি অনুরূপ ব্যবসা দেখেছে, এটি আপনার বর্তমান বাস্তবতা জানবে না।\n\nএকটি ব্যবহারযোগ্য মানসিক মডেল:\n\n- মডেল জ্ঞান: সাধারণ লেখনী, কমন কনসেপ্ট, জেনেরিক বেস্ট প্র্যাকটিস\n- আপনার ব্যবসার ডেটা: নীতি, SKU, চুক্তি, প্রোডাক্ট ডক, কাস্টমার ইতিহাস, সংখ্যা\n\nযদি জবাব আপনার অভ্যন্তরীণ সত্যের সাথে মিলে যাবে, আপনাকে সেই সত্য দিতে হবে।\n\n### রিট্রিভাল ব্যবহার করুন কিন্তু কেবল তখনই যদি আপনি সোর্স দিতে পারেন\n\nRAG (retrieval-augmented generation) যোগ করলে এটাকে “শোকাইওয়ার্ক” সিস্টেম হিসেবে বিবেচনা করুন। অনুমোদিত সোর্স থেকে স্পষ্ট প্যাসেজ উদ্ধার করুন এবং সহকারীকে সেগুলো উদ্ধৃত করতে বলুন। যদি আপনি কোট করতে না পারেন,_fact হিসেবে দেখাবেন না।\n\nএতে আপনার প্রম্পটও বদলে যাবে: “আমাদের রিফান্ড পলিসি কী?” না বলে বলুন “সংযুক্ত পলিসি এক্সার্প্ট ব্যবহার করে রিফান্ড পলিসি ব্যাখ্যা করুন এবং প্রাসঙ্গিক লাইনগুলো কোট করুন।”\n\n### “আমি জানি না” এবং নিরাপদ ফালব্যাক যোগ করুন\n\nঅস্পষ্টতার জন্য স্পষ্ট আচরণ তৈরি করুন: “যদি প্রদত্ত সোর্সে উত্তর না পাই, বলুন আপনি জানেন না এবং পরবর্তী ধাপ প্রস্তাব করুন।” ভালো ফালব্য্যাক: মানব হ্যান্ডঅফ লিংক, সার্চ পেজ, বা একটি ছোট ক্ল্যারিফিকেশন প্রশ্ন। এটি ব্যবহারকারীকে রক্ষা করে—এবং আপনার টিমকে পরবর্তীতে ভুল মেটাতে বাধ্য করে না।\n\n## ভুল #5: রিলেভান্স চেক ও উৎসসংশ্লেষ ছাড়া RAG করা\n\nRAG দ্রুতভাবে একটি এআই অ্যাপকে স্মার্ট মনে করাতে পারে: আপনার ডক যোগ করুন, কয়েকটা প্রাসঙ্গিক চাংক উদ্ধার করুন, এবং মডেলকে উত্তর করতে দিন। নবীনদের ফাঁদ হল ধরে নেয়া যে রিট্রিভাল অটোম্যাটিকভাবে সঠিকতা দেয়।\n\n### সাধারণত কী ভুল হয়\n\nঅধিকাংশ RAG ব্যর্থতা মডেল ‘হ্যালুসিনেট করছে’ বলে নয়—বরং সিস্টেম মডেলটিকে ভুল কনটেক্সট পাঠাচ্ছে।\n\nসাধারণ সমস্যা: খারাপ চাংকিং (আইডিয়া মাঝেই কাটাচ্ছে), অনরিলেভান্ট রিট্রিভাল (টপ রেজাল্ট কীওয়ার্ড মিলে গেলো কিন্তু অর্থ মিলেনা), এবং স্টেইল ডক (সিস্টেম গত কোয়ার্টারের পলিসিই উদ্ধৃত করছে)। যখন উদ্ধারকৃত কনটেক্সট দুর্বল, মডেল তখনও আত্মবিশ্বাসী উত্তর তৈরি করে—শুধু যে শব্দগুলোর উপর ভিত্তি করে সেটা شور।\n\n### কেবল রিট্রিভাল নয়—রিলেভান্স চেক যোগ করুন\n\nরিট্রিভালকে সার্চের মতো বিবেচনা করুন: এটাকে কোয়ালিটি কন্ট্রোল দরকার। কিছু ব্যবহারিক প্যাটার্ন:\n\n- স্কোর কম হলে মিনিমাম রিলেভান্স থ্রেশহোল্ড বা "কোনো উত্তর নেই" আচরণ সেট করুন\n- প্রায়-একই চাংকগুলোর ডুপ্লিকেশন সরান যাতে একবারের মতো এক প্যারাগ্রাফ দোমিনেট না করে\n- অনেক চাংক টেনে আনার চেয়ে কম কিন্তু উচ্চমানের সোর্স পছন্দ করুন\n\n### সাইটেশন বাধ্যতামূলক করুন এবং সোর্স দেখান\n\nআপনার অ্যাপ সিদ্ধান্তের জন্য ব্যবহৃত হলে, ব্যবহারকারীরা যাচাই করতে চায়। প্রতিটি ফ্যাকচুয়াল দাবি সোর্স এক্সরাপ্ট, ডক শিরোনাম, এবং শেষ-আপডেট তারিখ দেখাবে—এগুলো UI-তে দেখান এবং রেফারেন্স করা অংশ খোলা সহজ রাখুন।\n\n### ভাঙা অবস্থায় পরীক্ষা করুন\n\nদুইটি দ্রুত টেস্ট অনেক কিছু ধরবে:\n\n- Needle in a haystack: একটি দীর্ঘ ডকেও এক গুরুত্বপূর্ণ বাক্য লুকিয়ে রাখুন এবং দেখুন এটা উদ্ধার হয় কিনা।\n- Near-duplicate queries: একই প্রশ্ন একটু ভিন্নভাবে করে দেখুন এবং রিট্রিভাল ও সাইটেশন তুলনা করুন।\n\nযদি সিস্টেম নির্ভরযোগ্যভাবে উদ্ধার ও কোট করতে না পারে, RAG শুধু জটিলতা বাড়াচ্ছে—ভরসা নয়।\n\n## ভুল #6: মূল্যায়ন ও রিগ্রেশন টেস্ট ছাড়া শিপ করা\n\nঅনেক নবীণ দল কয়েকটা “দেখে ভালো লাগছে” ডেমোর পর এআই ফিচার শিপ করে। ফলাফল টিপিক্যাল: প্রথম বাস্তব ব্যবহারকারীরা এজ-কেস, ফরম্যাটিং ভাঙ্গন, বা মডেল আত্মবিশ্বাসী কিন্তু ভুল উত্তর দেখায়—আর আপনার কাছে মাপানোর কোনো উপায় থাকে না যে কত খারাপ বা উন্নত হচ্ছে।\n\n### মূল সমস্যা: বেসলাইন নেই, গেট নেই\n\nআপনি যদি একটি ছোট টেস্ট সেট ও কয়েকটি মেট্রিক সংজ্ঞায়িত না করেন, প্রতিটি প্রম্পট টুইক বা মডেল আপগ্রেড একটি বাজি। আপনি একটি সিচুয়েশন ঠিক করতে পারেন এবং অজান্তে পাঁচটা অন্যকেস ভাঙে রাখতে পারেন।\n\n### শুরুর দিকে একটি ছোট, প্রতিনিধিত্বমূলক ইভ্যালুয়েশন সেট নিন\n\nআপনাকে হাজারেরও দরকার নেই। 30–100 বাস্তবসদৃশ কেস থেকে শুরু করুন যার মধ্যে আছে:\n\n- সাধারণ অনুরোধ ("মানি" ফ্লো)\n- বিভ্রান্তিকর ইনপুট (টাইপো, মিসিং কনটেক্সট)\n- ঝুঁকিপূর্ণ অনুরোধ (নীতি, আইনি, ব্যক্তিগত ডেটা)\n\nসংরক্ষণ করে রাখুন প্রত্যাশিত “ভ্যালিড” আচরণ (উত্তর + প্রয়োজনীয় ফরম্যাট + অনিশ্চয়ের সময় কী করা উচিত)।\n\n### সহজ মেট্রিক ব্যবহার করুন যেগুলো ধারাবাহিকভাবে প্রয়োগ করা যায়\n\nশুরুতে তিনটি চেক ব্যাবহার করুন যা ইউএক্স-এ মানে রাখে:\n\n- সঠিকতা: উত্তর কর্মক্ষমতার জন্য পর্যাপ্ত সঠিক কি?\n- রিজেকশন কোয়ালিটি: যখন সম্মত না হওয়া উচিত বা প্রশ্ন করা উচিত, সেসম্পর্কে কি স্পষ্ট ও সহায়ক?\n- ফরম্যাট ভ্যালিডিটি: আপনার প্রয়োজনীয় JSON/ফিল্ড/টোন কি সব সময় মেনে চলছে?\n\n### শিপ করার আগে রিগ্রেশন চেক স্বয়ংক্রিয় করুন\n\nএকটি বেসিক রিলিজ গেট যোগ করুন: কোনো প্রম্পট/মডেল/কনফিগ পরিবর্তন লাইভ যাবে না যদি না একই ইভ্যালুয়েশন সেট পাস করে। এমনকি CI-তে একটি হালকা স্ক্রিপ্ট চালালেই “ঠিক করেছি… এবং ভেঙে ফেলেছি” লুপ আটকানো যাবে।\n\nশুরু করার জন্য একটি চেকলিস্ট তৈরি করুন এবং সেটা আপনার ডেপ্লয়মেন্ট প্রসেসের পাশে রাখুন (দেখুন /blog/llm-evaluation-basics)।\n\n## ভুল #7: কেবল হ্যাপি পাথ টেস্ট করা\n\nঅনেক নবীন এআই অ্যাপ ডেভেলপমেন্ট ডেমোতে জমে: একটিবারে পরিষ্কার প্রম্পট, একটা পারফেক্ট উদাহরণ, এক আদর্শ আউটপুট। সমস্যা হলো ব্যবহারকারীরা ডেমো স্ক্রিপ্টের মতো আচরণ করে না। আপনি যদি কেবল “হ্যাপি পাথ” টেস্ট করেন, বাস্তবে ইনপুট মেললেই আপনার সিস্টেম ভেঙে পড়বে।\n\n### ডেমোর মতো টেস্ট করা বন্ধ করুন\n\nপ্রোডাকশন-সদৃশ পরিস্থিতি অন্তর্ভুক্ত করে: অগোছালো ডেটা, ব্যাঘাত, অননুমিত সময়। আপনার টেস্ট সেটটি হওয়া উচিত বাস্তবে অ্যাপটি কিভাবে ব্যবহৃত হয় তার প্রতিফলন: বাস্তব ব্যবহারকারী প্রশ্ন, বাস্তব ডকুমেন্ট, এবং বাস্তব সীমাবদ্ধতা (টোকেন লিমিট, কনটেক্সট উইন্ডো, নেটওয়ার্ক সমস্যা)।\n\n### যে ইনপুটগুলো চমক তৈরি করে সেগুলো টেস্ট করুন\n\nএজ-কেসগুলোই হল যেখানে হ্যালুসিনেশন ও নির্ভরযোগ্যতার সমস্যা প্রথম প্রর্দশিত হয়। নিশ্চিত করুন আপনি টেস্ট করেছেন:\n\n- অস্পষ্ট ইনপুট ("এটা সারসংক্ষেপ করুন" কিন্তু কোন বস্তু নেই, অস্পষ্ট প্রদানের সর্বনাম)\n- দীর্ঘ টেক্সট যা ট্রাঙ্কেশন বা চাংকিংকে বাধ্য করে\n- গোলমেলে OCR (ভুল পড়া অক্ষর, ভাঙা প্যারাগ্রাফ, অনুপস্থিত পেজ)\n- স্ল্যাং, টাইপো, মিশ্র ভাষা, ও dziন ধরনের ফরম্যাটিং (টেবিল, বুলেট ডাম্প)\n\n### লেটেন্সি ও থ্রুপুট স্ট্রেস টেস্ট করুন\n\nএকটি অনুরোধ কাজ করলেই হবে না। উচ্চ কনকারেন্টি, রিট্রাই, এবং ধীর মডেল রিপ্লাই চেষ্টা করুন। p95 লেটেন্সি মাপুন, এবং নিশ্চিত করুন UX এখনও গ্রহণযোগ্য যখন রেসপন্স বেশি সময় নেয়।\n\n### আংশিক ব্যর্থতার পরিকল্পনা করুন (কারণ সেটা ঘটবে)\n\nমডেল টাইমআউট হতে পারে, রিট্রিভাল কিছুই না দিতে পারে, এবং API-তে রেট লিমিট হতে পারে। প্রতিটি ক্ষেত্রে আপনি কী করবেন তা ঠিক করুন: “উত্তর দেয়া যাচ্ছে না” স্টেট দেখানো, সরল পদ্ধতিতে ফলাফল ফিরিয়ে দেওয়া, ক্ল্যারিফাইং প্রশ্ন করা, অথবা কাজ কিউতে রাখা। যদি ব্যর্থতার স্টেট ডিজাইন না করা থাকে, ব্যবহারকারী নীরবতাকে “এআই ভুল” হিসেবে ধরে নেবে না—বরং “সিস্টেমে সমস্যা” হিসেবেই নেবে।\n\n## ভুল #8: ট্রাস্ট ও যাচাইয়ের জন্য UX উপেক্ষা করা\n\nঅনেক নবীন এআই অ্যাপ ব্যর্থ হয় না কারণ মডেল খারাপ, বরং কারণ ইন্টারফেস আউটপুটকে সবসময় সঠিক ভাবেই উপস্থাপন করে। যখন UI অনিশ্চয়তা ও সীমাবদ্ধতাগুলো লুকায়, ব্যবহারকারী হয় অতিরিক্ত আস্থা ধরে (এবং ক্ষুব্ধ হয়), অথবা পুরোপুরি আস্থা হারায়।\n\n### যাচাই ডিফল্ট করুন\n\nঅভিজ্ঞতা এমনভাবে ডিজাইন করুন যাতে যাচাই করা সহজ ও দ্রুত হয়। কার্যকর প্যাটার্নগুলির মধ্যে আছে:\n\n- সংক্ষিপ্ত, এডিটেবল সারসংক্ষেপ এবং পরে সহায়ক বিবরণ\n- স্পষ্ট সোর্স (লিংক, ডক টাইটেল, টাইমস্ট্যাম্প, বা উদ্ধৃত অংশ) যখন আপনি জ্ঞান উল্লেখ করছেন\n- “চেক” অ্যাকশন যাতে ব্যবহারকারী মূল দাবি যাচাই করতে পারেন (উৎস খুলুন, উদ্ধৃত অংশ দেখুন, বিকল্প তুলনা করুন)\n\nআপনার অ্যাপ যদি সোর্স দিতে না পারে, সেটা পরিষ্কারভাবে বলুন এবং UX-টিকে নিরাপদ আউটপুটের দিকে সরান (ড্রাফট, সাজেশন, বিকল্প) — কর্তৃত্বপূর্ণ বিবৃতির মতো নয়।\n\n### অনুমান করার পরিবর্তে প্রশ্ন করুন\n\nযখন ইনপুট অসম্পূর্ণ, আত্মবিশ্বাসী উত্তর ফোর্স করবেন না। ১–২টি ক্ল্যারিফাইং প্রশ্ন যোগ করুন (“কোনটি অঞ্চল?”, “কোন টাইমফ্রেম?”, “কোন টোন?”)। এটি হ্যালুসিনেশন কমায় এবং ব্যবহারকারীকে মনে করায় সিস্টেম তাদের সঙ্গে কাজ করছে, টর-ট্রিক নয়।\n\n### দৃশ্যমান গার্ডরেইল যোগ করুন\n\nযখন ব্যবহারকারী কী ঘটবে তা পূর্বানুমান করতে পারে এবং ভুল থেকে ফিরে আসতে পারে, আস্থা বাড়ে:\n\n- উচ্চ-প্রভাব অ্যাকশনের জন্য কনফার্মেশন (send, publish, delete)\n- পরিবর্তন প্রয়োগের আগে প্রিভিউ (এডিট ডিফ)\n- অনিও এবং ভার্সন হিস্ট্রি যেকোনো অনিষ্পন্ন কাজের জন্য\n\nলক্ষ্য হচ্ছে—সঠিকতা হবে দ্রুততম পথ, ব্যবহারকারীর জন্য ধীরতা নয়।\n\n## ভুল #9: নিরাপত্তা, গোপনীয়তা, ও কমপ্লায়েন্স নিয়ে ভাবা বাদ দেওয়া\n\nঅনেক নবীন এআই অ্যাপ ব্যর্থ হয় না কারণ মডেল খারাপ—বরং কারণ কেউ ঠিক করেনি কি হবেই না। যদি আপনার অ্যাপ ক্ষতিকর নির্দেশ, ব্যক্তিগত ডেটা প্রকাশ, বা সংবেদনশীল দাবির তৈরির সুযোগ রাখে, তাহলে এটি শুধু কোয়ালিটি সমস্যা নয়—এটি আস্থা ও আইনি ঝুঁকি।\n\n### প্রত্যাখ্যান ও মানব হ্যান্ডঅফ নির্ধারণ করুন\n\nশুরুতেই একটি সহজ "প্রত্যাখ্যান বা এসক্যালেট" পলিসি প্লেইন ভাষায় লিখুন। কি উত্তর প্রদান করা উচিত নয় (স্ব-হত্যা নির্দেশ, অবৈধ কাজ, চিকিৎসা/আইনি নির্দেশ), আর কী ঘটলে মানুষ পর্যালোচনার প্রয়োজন (অ্যাকাউন্ট পরিবর্তন, উচ্চ-ঝুঁকির সুপারিশ, মাইনরের বিষয়) তা স্পষ্ট করুন। এই নীতি প্রোডাক্টে প্রয়োগ করুন—আশায় রাখবেন না।\n\n### PII-কে হ্যান্ডেল করুন ঝুঁকিপূর্ণ বস্তু হিসেবেই\n\nনির্দিষ্টভাবে ধরে নিন ব্যবহারকারী ব্যক্তিগত ডেটা পেস্ট করবে—নাম, ইমেইল, ইনভয়েস, স্বাস্থ্য-বিবরণ।\n\nসংগ্রহ কম রাখুন, এবং কাঁচা ইনপুট স্টোর করা থেকে বিরত থাকুন যদি না তা সত্যিই দরকার। লগ করার আগে সংবেদনশীল ফিল্ডগুলো রিডাক্ট বা টোকেনাইজ করুন। ডেটা স্টোর করা, ট্রেনিং-এ ব্যবহার করা, বা তৃতীয় পক্ষের সাথে শেয়ার করার আগে স্পষ্ট সম্মতি নিন।\n\n### লগিং ও অ্যাক্সেস কন্ট্রোলও "এআই সেফটি"র অংশ\n\nডিবাগ করার জন্য লগ দরকার, কিন্তু লগই লিক হয়ে যেতে পারে।
কনটেক্সট দৈর্ঘ্য:
টুল ব্যবহার
মাল্টি-স্টেপ চেইন:
রিট্রাই ও ফলব্যাক:
max tokens
max steps/tool calls
প্রতি সফল টাস্ক খরচ
ব্যবহারকারীরা কী করতে চেয়েছিল, কোথায় ব্যর্থ হলো, তারা কীভাবে ঠিক করেছে?
ব্যবহারকারীর উদ্দেশ্য
ব্যর্থতার ধরন
করেকশন পয়েন্ট
লেবেল
ইভ্যালুয়েশন সেট
একটি ডেডলাইন এবং "মেরামত হলো যখন..."-এর পরিমাপযোগ্য মানদণ্ড\n\nমনিটরিং অতিরিক্ত কাজ নয়—এটাই হচ্ছে কীভাবে আপনি একই বাগ বারবার শিপ করা থামাবেন।\n\n## প্রয়োগযোগ্য চেকলিস্ট এই ভুলগুলো এড়াতে\n\nআপনি যদি প্রথম এআই ফিচার বানাচ্ছেন, মডেলকে "আউটস্মার্ট" করতে চেষ্টা করবেন না। প্রোডাক্ট ও ইঞ্জিনিয়ারিং সিদ্ধান্তগুলো স্পষ্ট, টেস্টযোগ্য, ও পুনরাবৃত্তিমূলক করুন।\n\n### 1) এক পৃষ্ঠার স্পেস লিখুন (প্রম্পট লেখার আগে)\n\nচারটি জিনিস অন্তর্ভুক্ত করুন:\n\n- ব্যবহারকারী ও প্রসঙ্গ: কে এটি ব্যবহার করছে, কোথায়, এবং কী জড়িত আছে\n- টাস্ক: করা ঠিক কি (ইনপুট, আউটপুট, সীমাবদ্ধতা)\n- ঝুঁকি: কী ভুল হতে পারে (গোপনীয়তা, খারাপ পরামর্শ, ভুল ক্রিয়াকলাপ)\n- সাফল্য মেট্রিক: কীভাবে আপনি “ভাল” পরিমাপ করবেন (সময় সাশ্রয়, সঠিকতা, ডিফ্লেকশন রেট, CSAT)\n\n### 2) সীমাবদ্ধতা ও নিরাপদ ডিফল্ট সহ একটি মিনিমাল v1 তৈরি করুন\n\nসঠিক হতে পারে এমন সবচেয়ে ছোট ওয়ার্কফ্লো দিয়ে শুরু করুন।\n\nঅনুমোদিত অ্যাকশন নির্ধারণ করুন, সম্ভব হলে স্ট্রাকচার্ড আউটপুট বাধ্যতামূলক করুন, এবং "আমি জানি না / আরো তথ্য চাই"-কে একটি বৈধ ফলাফল হিসেবে রাখুন। যদি আপনি RAG ব্যবহার করেন, সিস্টেমকে সরু রাখুন: কম সোর্স, কড়া ফিল্টারিং, এবং স্পষ্ট সাইটেশন।\n\nআপনি যদি Koder.ai-তে তৈরি করছেন, একটি ব্যবহারিক প্যাটার্ন হলো Planning Mode-এ শুরু করা (যাতে আপনার ওয়ার্কফ্লো, ডেটা সোর্স, এবং প্রত্যাখ্যান নীতিগুলো স্পষ্ট থাকে), তারপর ছোট পরিবর্তন করে ইটারেট করা এবং যখন প্রম্পট বা রিট্রিভাল টুইক রিগ্রেশন আনে তখন snapshots + rollback-এ নির্ভর করা।\n\n### 3) প্রতিবার রিলিজ করার আগে একটি চেকলিস্ট ব্যবহার করুন\n\nশিপ করার আগে যাচাই করুন:\n\n- ইভ্যালুয়েশন পাস করেছে: আপনার টেস্ট সেট লক্ষ্যমানমানে পৌঁছেছে\n- বাজেট ও লেটেন্সি: আপনার প্রতি-অনুরোধ খরচ সীমা ও টাইমআউট প্ল্যান আছে\n- UX ট্রাস্ট চেক: ব্যবহারকারীরা উত্তর যাচাই করতে পারে (সোর্স, সতর্কতা, সহজ রিট্রাই/এডিট)\n\n### 4) সহজ উন্নতির রোডম্যাপ অনুসরণ করুন\n\nযখন মান কম থাকে, এই অর্ডারে ঠিক করুন:\n\n1. ডেটা/রিট্রিভাল: ভালো ডক, চাংকিং, র্যাঙ্কিং, সততা\n2. প্রম্পট ও টুল নিয়ম: স্পষ্ট নির্দেশনা, টাইট ফরম্যাট, কম স্বাধীনতা\n3. মডেল পছন্দ: শুধু তখনই আপগ্রেড করুন যখন আপনি প্রমাণ করেছেন প্রব্লেম ইনপুট বা রিট্রিভালে নেই\n\nএতে অগ্রগতি মাপযোগ্য থাকে—এবং “অলিখিত প্রম্পট টুইক” আপনার কৌশল না হয়ে উঠে।\n\nআপনি দ্রুত শিপ করতে চান কিন্তু স্ট্যাক বারবার পুনর্নির্মাণ করতে চান না, এমন টুলিং বেছে নিন যা দ্রুত ইটারেশন ও পরিষ্কার হ্যান্ডঅফ সমর্থন করে। উদাহরণস্বরূপ, Koder.ai চ্যাট থেকে React ফ্রন্টএন্ড, Go ব্যাকএন্ড, এবং PostgreSQL স্কিমা জেনারেট করতে পারে—তারপরও সোর্স কোড এক্সপোর্ট ও কাস্টম ডোমেইনে ডেপ্লয় করতে দেয়—উপযোগী যখন আপনার এআই ফিচার প্রোটোটাইপ থেকে নির্ভরশীল প্রোডাক্টে যাবে।
প্রতিটি প্রম্পট/মডেল/কনফিগ পরিবর্তনের আগে চালান—এতে সাইলেন্ট রিগ্রেশন আটকানো যায়।