একটি চমৎকার AI ডেমো এবং রাত ২টায় কোনো সমস্যা ছাড়াই সচল থাকা একটি প্রোডাকশন সিস্টেমের মধ্যে বিশাল ব্যবধান রয়েছে। যারা ডেমো তৈরি করেন তাদের বেশিরভাগই এটি জানেন। কিন্তু যখন তারা আপনাকে ব্লুপ্রিন্ট বিক্রি করেন, তখন তারা সবসময় এটি নিয়ে সৎ থাকেন না। প্রোডাকশনে আপনার পাইপলাইন ভুল ফাউন্ডেশন মডেল নির্বাচনের কারণে ব্যর্থ হয় না। এটি ব্যর্থ হয় কারণ আপনার সিস্টেম ডিজাইন একটি প্রোটোটাইপকে একটি প্রোডাক্ট হিসেবে বিবেচনা করে।

বর্তমানে সবাই সবকিছুকেই 'এজেন্ট' (agent) বলছে। একটি স্ক্রিপ্ট যা কোনো শর্ত পূরণ না হওয়া পর্যন্ত লুপ করে চলে, সেটি হঠাৎ করেই একটি এজেন্ট হয়ে যাচ্ছে। একটি চ্যাটবট যা মেমরিতে শেষ তিনটি মেসেজ জমা রাখে, সেটিও একটি এজেন্ট। এই অগোছালো শব্দচয়ন প্রকৃত ইঞ্জিনিয়ারিংয়ের ক্ষতি করছে। টিমগুলো এমন একটি পাঁচ-ধাপের ওয়ার্কফ্লো অটোমেট করার জন্য ভারী এজেন্ট ফ্রেমওয়ার্ক ব্যবহার করতে চায় যা একটি সাধারণ cron job দিয়েও সামলানো সম্ভব। একই সাথে, তারা প্রকৃত জটিলতার পেছনে যথেষ্ট বিনিয়োগ করে না কারণ এই লেবেলটি শুনলে মনে হয় যেন Large Language Model জাদুকরীভাবে সব এজ কেস (edge cases) সমাধান করে দেবে। কিন্তু তা হবে না।

একটি এজেন্ট আসলে কী

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

আপনি যা তৈরি করছেন তা বিচার করার জন্য এই তিনটি নিয়ম ব্যবহার করুন:

  • যদি একজন মানুষকে প্রতিটি ধাপ বলে দিতে হয়, তবে এটি একটি চ্যাট ইন্টারফেস। আপনি গাড়ি চালাচ্ছেন। সিস্টেমটি কেবল একটি অত্যন্ত ভদ্র স্টিয়ারিং হুইল মাত্র।
  • যদি এটি একটি ব্যর্থ টুল কল থেকে পুনরুদ্ধার করতে পারে, তবে আপনি সঠিক পথে আছেন। একটি search API টাইম-আউট হওয়া বা 500 error প্রদান করা মানেই কাজ শেষ হয়ে যাওয়া নয়। সিস্টেমটির উচিত পুনরায় চেষ্টা করা (retry), কিছুটা বিরতি নেওয়া (back off), বিকল্প কোনো সোর্সে (fallback source) চলে যাওয়া অথবা সাহায্য চাওয়া।
  • যদি এটি একটি লক্ষ্যকে উপ-কাজে (subtasks) বিভক্ত করে এবং সেগুলো অর্পণ করে, তবে এটি একটি প্রকৃত এজেন্ট। একে “prepare the Q3 compliance report” এর মতো একটি কমান্ড দিন, এবং এটি ডেটা সোর্সগুলো শনাক্ত করবে, ডেটা এক্সট্রাকশন শিডিউল করবে, কাঁচা সংখ্যাগুলো (raw numbers) একটি ক্যালকুলেশন মডিউলে পাঠাবে, বর্ণনামূলক ড্রাফটটি পর্যালোচনার জন্য পাঠাবে এবং কখন থামতে হবে তাও জানবে।

যদি আপনার সিস্টেম এই কাজগুলো না করে, তবে আপনার সমস্যাটি এজেন্টের নয়। আপনার সমস্যাটি স্ক্রিপ্টিং বা ওয়ার্কফ্লো সংক্রান্ত। এটি দ্রুত স্বীকার করে নিলে আপনি ফ্রেমওয়ার্কের অপ্রয়োজনীয় জটিলতা (framework bloat) থেকে কয়েক সপ্তাহ বেঁচে যেতে পারেন।

সফল টিমগুলো আসলে কোন বিষয়গুলোকে অগ্রাধিকার দেয়

যে টিমগুলো নির্ভরযোগ্য সিস্টেম তৈরি করে, তারা বেঞ্চমার্কে কয়েক পয়েন্ট বাড়ানোর জন্য সারাদিন সর্বশেষ মডেল রিলিজ পরিবর্তন করে কাটায় না। তারা তিনটি বিরক্তিকর কিন্তু অত্যন্ত কার্যকর (high-leverage) বিষয়ে মনোযোগ দেয়।

টুল ডিজাইন (Tool design)। আপনার এজেন্ট ততটাই ভালো যতটা ভালো টুল আপনি তাকে দিচ্ছেন। যদি একটি সার্চ ফাংশন অসামঞ্জস্যপূর্ণ ফিল্ড নামসহ র (raw), নেস্টেড JSON প্রদান করে, তবে মডেলটি কন্টেন্ট নিয়ে চিন্তা করার পরিবর্তে স্ট্রাকচার পার্সিং করতে গিয়ে মূল্যবান কনটেক্সট উইন্ডো নষ্ট করে ফেলে। যদি টুলের বর্ণনা অস্পষ্ট হয়, তবে মডেল ভুল আর্গুমেন্ট নিয়ে হ্যালুসিনেশন (hallucinate) করতে পারে। টুল ইন্টারফেসগুলোকে এমন একজন অত্যন্ত আক্ষরিক (literal) জুনিয়র ডেভেলপারের জন্য API হিসেবে বিবেচনা করুন, যার পরিষ্কার ইনপুট, অনুমানযোগ্য আউটপুট এবং সুনির্দিষ্ট এরর স্টেট (error states) প্রয়োজন।

ফেইলর হ্যান্ডলিং (Failure handling)। যখন একটি রিট্রিভাল (retrieval) ধাপ কিছুই খুঁজে পায় না তখন কী ঘটে? অনেক পাইপলাইন নিঃশব্দে প্রম্পটে খালি কনটেক্সট ঢুকিয়ে দেয় এবং মডেলকে তার ট্রেনিং ডেটা থেকে একটি উত্তর হ্যালুসিনেশন করতে বাধ্য করে। এটি কোনো ফিচার নয়; এটি একটি প্রোডাকশন ইনসিডেন্ট যা ঘটার অপেক্ষায় আছে। একটি সঠিক সিস্টেম শূন্যতা শনাক্ত করতে পারে। এটি একটি বিস্তৃত কুয়েরি দিয়ে পুনরায় চেষ্টা করে। এটি কোনো মানুষের কাছে বিষয়টি পাঠায় (escalate), অথবা একটি স্পষ্ট ব্যাখ্যা দিয়ে থেমে যায়। কিছু না পাওয়া সত্ত্বেও এটি কিছু খুঁজে পেয়েছে বলে ভান করে না।

অবজারভেবিলিটি (Observability)। এজেন্ট কেন একটি নির্দিষ্ট সিদ্ধান্ত নিল তা আপনার দেখা প্রয়োজন। কেবল চূড়ান্ত আউটপুট নয়—বরং চেইন অফ থট (chain of thought), টুল নির্বাচন, রিট্রিভ করা চাঙ্কস (retrieved chunks) এবং হ্যান্ডঅফ লগগুলোও দেখা প্রয়োজন। এই ট্রেস ছাড়া ডিবাগিং করা মানে কেবল অনুমান করা। আগামী সপ্তাহে যখন কোনো ব্যবহারকারী ভুল উত্তরের জন্য অভিযোগ করবেন, তখন আপনার কাছে এটি পুনরায় দেখার ক্ষমতা থাকতে হবে যে ঠিক কোন রিট্রিভাল ধাপটি ভুল তথ্য দিয়েছিল এবং কেন।

আর্কিটেকচার প্যাটার্ন যা ফ্রেমওয়ার্কের চেয়েও দীর্ঘস্থায়ী

LangChain, CrewAI এবং আগামী ছয় মাস পর আসা পরবর্তী জনপ্রিয় ফ্রেমওয়ার্কগুলো হলো কেবল স্ক্যাফোল্ডিং (scaffolding)। আর্কিটেকচার হলো মূল ভবন। আপনার ডিজাইন যদি ভঙ্গুর হয়, তবে কোনো ফ্রেমওয়ার্কই আপনাকে বাঁচাতে পারবে না। সেই প্যাটার্নগুলো অনুসরণ করুন যেগুলোর স্থায়িত্ব প্রমাণিত:

  • প্রথমে পরিকল্পনা করুন, তারপর কার্যকর করুন। মডেলকে একই সাথে চিন্তা (reason) এবং কাজ (act) করতে দেবেন না। প্রথমে একটি পরিকল্পনা তৈরি করুন। তারপর ধাপগুলো সম্পন্ন করুন। যখন কিছু ভুল হবে, আপনি এক্সিকিউশন বা কার্যকর করার প্রক্রিয়া থেকে আলাদাভাবে পরিকল্পনাটি পরীক্ষা করতে পারবেন। এতে ইন্টারলিভড টুল কল এবং স্ট্রীম-অফ-কনশাসনেস রিজনিংয়ের জটিলতা সমাধান করতে আপনার অনেক কম সময় ব্যয় হবে।
  • রিট্রিভাল (retrieval) এবং রিজনিং (reasoning)-কে আলাদা রাখুন। কনটেক্সট বা প্রেক্ষাপট সংগ্রহ করা একটি I/O কাজ। আর সেই কনটেক্সট ব্যবহার করা হলো একটি রিজনিং বা চিন্তাভাবনার কাজ। এই দুটিকে মিশিয়ে ফেললে আপনার রিট্রিভার মডেলের টোকেন লিমিটের দ্বারা সীমাবদ্ধ হয়ে পড়বে এবং আপনার মডেলটি অপ্রাসঙ্গিক বা নয়েজযুক্ত তথ্যে দূষিত হয়ে যাবে। রিট্রিভাল লেয়ারকে আক্রমণাত্মকভাবে তথ্য সংগ্রহ করতে দিন। আর রিজনিং লেয়ারকে প্রাপ্ত তথ্যটি সতর্কতার সাথে মূল্যায়ন করতে দিন।
  • স্পষ্ট হ্যান্ডঅফ (handoff) ব্যবহার করুন। যদি একাধিক এজেন্ট একটি কাজ সম্পন্ন করে, তবে কাজের হস্তান্তর প্রক্রিয়াটি সুসংগঠিত করুন। স্পষ্ট আউটপুট স্কিমা, মালিকানার সীমানা এবং হ্যান্ডঅফ লগ নির্ধারণ করুন। এজেন্টদের মধ্যে অস্পষ্ট বা অনানুষ্ঠানিক কথাবার্তা কাজের অবহেলা, চক্রাকার লুপ (circular loops) বা কাজের পুনরাবৃত্তির দিকে নিয়ে যেতে পারে। এজেন্ট-টু-এজেন্ট যোগাযোগকে একটি গ্রুপ চ্যাটের মতো নয়, বরং একটি সুসংজ্ঞায়িত API কন্ট্রাক্টের মতো বিবেচনা করুন।

আপনার RAG কেন অপ্রাসঙ্গিক তথ্য প্রদান করে তার আসল কারণ

যদি আপনার রিট্রিভাল-অগমেন্টেড জেনারেশন (RAG) পাইপলাইন ক্রমাগত অপ্রাসঙ্গিক ফলাফল প্রদান করে, তবে এমবেডিং মডেল টিউন করা বন্ধ করে আপনার চাঙ্কিং (chunking) কৌশলের দিকে নজর দিন। RAG সিস্টেমের ক্ষেত্রে এটিই হলো সবচেয়ে অবহেলিত ব্যর্থতার কারণ।

যখন আপনি ডকুমেন্টগুলোকে কঠোরভাবে নির্দিষ্ট আকারের চাঙ্কে (chunks) বিভক্ত করেন, তখন আপনি প্রায়শই কোনো ধারণা বা আইডিয়াকে বিচ্ছিন্ন করে ফেলেন। একটি অনুচ্ছেদ যা “যাইহোক, এই পদ্ধতিটি রেগুলেটরি পরিবর্তনগুলো বিবেচনা করতে ব্যর্থ হয়েছে” দিয়ে শুরু হয়, সেটি যদি আগের অনুচ্ছেদটি ছাড়া থাকে যেখানে পদ্ধতির নাম উল্লেখ ছিল, তবে তার কোনো অর্থ থাকে না। সেই বিচ্ছিন্ন অংশটি যদি আপনি মডেলে ইনপুট হিসেবে দেন, তবে মডেলটি তার প্রয়োজন অনুযায়ী যেকোনো কাল্পনিক প্রেক্ষাপট তৈরি করে নেবে। এটি রিট্রিভাল নয়; এটি একটি হ্যালুসিনেশন ফ্যাক্টরি (hallucination factory)।

এই সমাধানগুলো চেষ্টা করে দেখুন:

  • ওভারল্যাপিং উইন্ডোজ (Overlapping windows)। পাশাপাশি থাকা চাঙ্কগুলোর সীমানায় এক বা দুটি বাক্য শেয়ার করতে দিন যাতে কোনো ধারণা বা বিষয় মাঝপথে বিচ্ছিন্ন না হয়ে যায়।
  • সিম্যান্টিক চাঙ্কিং (Semantic chunking)। ক্যারেক্টার কাউন্টের পরিবর্তে প্রাকৃতিক সীমানা—যেমন অনুচ্ছেদের সমাপ্তি, সেকশন হেডার বা বিষয়ের পরিবর্তন অনুযায়ী ভাগ করুন।
  • প্যারেন্ট-ডকুমেন্ট রিট্রিভাল (Parent-document retrieval)। সিম্যান্টিক ম্যাচিংয়ের জন্য ছোট এবং সুনির্দিষ্ট চাঙ্ক রিট্রিভ করুন, কিন্তু ল্যাঙ্গুয়েজ মডেলকে সম্পূর্ণ প্যারেন্ট সেকশন বা ডকুমেন্টটি প্রদান করুন যাতে জেনারেশনের সময় তার কাছে প্রয়োজনীয় প্রেক্ষাপট থাকে।
  • র (raw) টেক্সটের পরিবর্তে স্ট্রাকচার্ড ডেটা সংরক্ষণ করুন। টেবুলার ডেটা, কী-ভ্যালু পেয়ার এবং সম্পর্কগুলো গদ্য আকারে (prose) এমবেড করা প্রায়ই কঠিন হয়ে পড়ে। যদি আপনার সোর্স ম্যাটেরিয়াল স্ট্রাকচার্ড হয়, তবে সেটিকে গ্রাফ ডেটাবেস বা রিলেশনাল স্টোরে স্ট্রাকচার্ড অবস্থায় রাখুন এবং এজেন্টকে এমবেড করা টেক্সট ফ্র্যাগমেন্ট থেকে অনুমান করার পরিবর্তে সরাসরি কুয়েরি করতে দিন।

এমন সিস্টেম তৈরি করুন যা আপনি বিশ্বাস করতে পারেন

বেঞ্চমার্কের পেছনে ছোটা বন্ধ করুন। লিডারবোর্ড স্কোর হলো ল্যাব কন্ডিশন বা পরীক্ষাগারের অবস্থা। কিন্তু প্রোডাকশন পরিবেশ হলো বিশৃঙ্খল, প্রতিকূল এবং অ্যাসিনক্রোনাস (async)। আসল বিষয় হলো, আপনি যখন ঘুমাচ্ছেন, আপস্ট্রিম API যখন অস্থিতিশীল, এবং ব্যবহারকারী যখন এমন কিছু জিজ্ঞাসা করছেন যা ট্রেনিং ডেটাতে ছিল না—তখন আপনার সিস্টেম সঠিকভাবে কাজ করছে কি না।

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

উৎস: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

লার্নিং কমিউনিটিতে যোগ দিন: GyaanSetu AI on Telegram