একজন সাপোর্ট এজেন্ট টু-ফ্যাক্টর অথেন্টিকেশন (two-factor authentication) রিসেট করার একটি ব্যবহারকারীর অনুরোধের এমন কিছু ধাপ দিয়ে উত্তর দিয়েছিলেন যা আসলে অস্তিত্বহীন। উত্তরটি আত্মবিশ্বাসী মনে হচ্ছিল, HTTP রিকোয়েস্ট 200 OK রিটার্ন করেছিল, ল্যাটেন্সি (latency) স্বাভাবিক ছিল এবং প্রতিটি মনিটরিং চার্ট সবুজ (green) দেখাচ্ছিল।

একটি AI-চালিত সাপোর্ট এজেন্ট hallucination বা কাল্পনিক উত্তর দিয়েছিল কারণ যে অভ্যন্তরীণ পরীক্ষাগুলো (internal checks) এই ত্রুটিটি ধরতে পারত, সেগুলো কখনোই চলেনি। ইঞ্জিনিয়াররা যে ড্যাশবোর্ডগুলোর ওপর নির্ভর করেন সেগুলো একটি নিখুঁত কার্যক্রম রিপোর্ট করছিল, অথচ এজেন্টটি নিঃশব্দে একটি কাল্পনিক সমাধান তৈরি করছিল।

কেন প্রথাগত ড্যাশবোর্ডগুলো AI hallucination ধরতে পারে না

বেশিরভাগ অবজারভেবিলিটি স্ট্যাক (observability stacks) একটি AI এজেন্টকে অন্য যেকোনো মাইক্রোসার্ভিসের মতোই বিবেচনা করে: একটি মাত্র ইনবাউন্ড রিকোয়েস্ট এবং একটি মাত্র আউটবাউন্ড রেসপন্স। তারা HTTP স্ট্যাটাস, রেসপন্স টাইম এবং এরর কাউন্ট লগ করে। কিন্তু তারা রিকোয়েস্টের ভেতরে থাকা লুকানো ধাপগুলো লগ করে না – যেমন এক্সটার্নাল ডকুমেন্ট রিট্রিভাল (retrieval), লার্জ ল্যাঙ্গুয়েজ মডেলের (LLM) কল, অক্সিলিয়ারি টুলের ব্যবহার এবং আউটপুট যাচাই করার জন্য ব্যবহৃত কোনো গার্ড-রেইল (guard-rail) লজিক।

যখন একটি রিট্রিভাল ধাপ খালি ফলাফল প্রদান করে, মডেলটি প্রায়ই সেই শূন্যস্থানটি বিশ্বাসযোগ্য মনে হয় এমন টেক্সট দিয়ে "পূরণ" করে ফেলে। মনিটরিং সিস্টেমের দৃষ্টিতে কলটি সফল হয়েছে, কারণ কিছুই ক্র্যাশ করেনি এবং স্ট্যাটাস কোড ২০০ ছিল। ফলে এই hallucination বা কাল্পনিক উত্তরটি অদৃশ্য থেকে যায়, এবং একমাত্র লক্ষণ হিসেবে ব্যবহারকারীর কাছে একটি ভুল উত্তর পৌঁছে যায়।

একটি ব্ল্যাক বক্সকে একটি পাঠযোগ্য ট্রিতে (tree) রূপান্তর করা

নির্ভরযোগ্য ডিবাগিংয়ের প্রথম ধাপ হলো এজেন্টকে একটি মোনোলিথিক কল (monolithic call) হিসেবে দেখা বন্ধ করা এবং প্রতিটি অভ্যন্তরীণ অপারেশনকে একটি ট্রেস টেবিলের (trace table) নিজস্ব রো (row) হিসেবে কল্পনা করা। একটি সাধারণ কার্যক্রম নিচের ধাপগুলোতে বিভক্ত হতে পারে:

  • এজেন্ট ইনভোকেশন (agent invocation)
  • রিট্রিভাল ধাপ যা প্রাসঙ্গিক ডকুমেন্টেশন সংগ্রহ করে
  • প্রতিটি ল্যাঙ্গুয়েজ-মডেল ইনফারেন্স (inference) যা রিট্রিভ করা ডেটা প্রসেস করে
  • প্রতিটি টুল কল (যেমন: ডাটাবেস লুকআপ, API রিকোয়েস্ট)
  • গার্ড-রেইল চেক যা তথ্যের সত্যতা বা পলিসি কমপ্লায়েন্স নিশ্চিত করে

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

যে বাগটি এড়িয়ে গিয়েছিল

ত্রুটিপূর্ণ সাপোর্ট ইন্টারঅ্যাকশনটিতে ট্রেসটি দেখতে এমন ছিল:

  1. Retrieval চলল কিন্তু কোনো ডকুমেন্ট রিটার্ন করল না।
  2. পরবর্তী ধাপটি তা সত্ত্বেও এগিয়ে গেল, মডেলের কাছে একটি খালি কনটেক্সট পাঠিয়ে দিল।
  3. মডেলটি এমন একটি উত্তর তৈরি করল যা অনুপস্থিত তথ্যগুলোকে কাল্পনিক ধাপ দিয়ে পূরণ করেছে।
  4. সিস্টেম 200 রিটার্ন করল কারণ পাইপলাইনে কোনো এক্সেপশন (exception) দেখা দেয়নি।

এই hallucination ল্যাঙ্গুয়েজ মডেলের নিজস্ব কোনো ত্রুটি ছিল না; এটি ছিল রিট্রিভাল এবং জেনারেশন ধাপের মধ্যে একটি অনুপস্থিত গার্ড-রেইল। এজেন্টটি উত্তর দিয়েছিল এমনকি যখন তার কাছে উত্তরের ভিত্তি হিসেবে কোনো তথ্যই ছিল না।

সহজ গার্ড-রেইল যা hallucination বন্ধ করে

দুটি সুনির্দিষ্ট পরিবর্তন এই সমস্যাটি দূর করেছে:

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

দ্রুত ডিবাগিংয়ের জন্য একটি ব্যবহারিক ওয়ার্কফ্লো

  1. প্রতিটি অভ্যন্তরীণ কল ট্রেস করুন – এজেন্টকে এমনভাবে ইনস্ট্রুমেন্ট (instrument) করুন যাতে প্রতিটি রিট্রিভাল, মডেল ইনফারেন্স এবং টুল ব্যবহার একটি পারসিস্টেন্ট লগে (persistent log) একটি রো হিসেবে লেখা হয়।
  2. ব্যর্থ কার্যক্রমগুলো সংরক্ষণ করুন – ব্যবহারকারী যে ইন্টারঅ্যাকশনটিকে ভুল হিসেবে রিপোর্ট করেছেন তার সম্পূর্ণ ট্রেস সংরক্ষণ করুন। স্টোরেজ বাঁচাতে এগুলো মুছে ফেলা মানে রিগ্রেশন (regression) খুঁজে বের করার জন্য প্রয়োজনীয় ডেটা লুকিয়ে ফেলা।
  3. ভার্সন তথ্য দিয়ে রানগুলোকে ট্যাগ করুন – প্রতিটি ট্রেস রো-তে রিলিজ আইডেন্টিফায়ার এবং যেকোনো ফিচার-ফ্ল্যাগ স্টেট অন্তর্ভুক্ত করুন। এটি আপনাকে সাম্প্রতিক কোড পরিবর্তনের সাথে একটি নতুন বাগের সম্পর্ক স্থাপন করতে সাহায্য করবে।
  4. শুধুমাত্র গতি নয়, গুণমান পরিমাপ করুন – এমন মেট্রিক্স যোগ করুন যা পরিমাপ করে যে উত্তরটি নির্দেশাবলী কতটা অনুসরণ করে এবং রিট্রিভ করা কন্টেন্টের ওপর কতটা ভিত্তি করে তৈরি। উত্তর ভুল হলে উচ্চ থ্রুপুট (throughput) খুব একটা কাজে আসে না।
  5. প্রতিদিন ব্যর্থতাগুলো পর্যালোচনা করুন – স্টোর করা ব্যর্থতাগুলোর একটি সংক্ষিপ্ত ও নিয়মিত পর্যালোচনা অনেক সময় প্যাটার্ন প্রকাশ করে (যেমন: একটি নির্দিষ্ট ধরণের কুয়েরি ক্রমাগত খালি রিট্রিভাল প্রদান করছে), যা অনেক ব্যবহারকারীকে প্রভাবিত করার আগেই ধরা পড়ে।

"গ্রিন" (green) অবস্থাকে "ভেরিফাইড" (verified)-এ রূপান্তর করার মাধ্যমে টিমগুলো দ্রুত hallucination ধরতে পারে এবং ব্যবহারকারীর অভিজ্ঞতাকে নির্ভরযোগ্য রাখতে পারে।

অভ্যন্তরীণ ব্যর্থতা উপেক্ষা করার মূল্য

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

পরবর্তীতে যা খেয়াল রাখতে হবে

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

মূল কথা: একটি সবুজ ড্যাশবোর্ড আপনাকে জানায় যে সিস্টেমের অভ্যন্তরীণ কাজগুলো ঠিকঠাক চলছে; কিন্তু এটি উত্তরটি সঠিক হওয়ার নিশ্চয়তা দেয় না। প্রতিটি রিট্রিভাল, মডেল কল এবং গার্ড-রেল চেক ট্র্যাক করার মাধ্যমে, আপনি লুকানো হ্যালুসিনেশনগুলোকে দৃশ্যমান ব্যর্থতায় রূপান্তর করেন, যা ব্যবহারকারীর কাছে পৌঁছানোর আগেই সংশোধন করা সম্ভব।