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

মূল শিক্ষা: শুধু অতীতের ইতিহাস টেনে আনা মানে এই নয় যে কী আসলে এখনও সঠিক তা জানা। একটি মৌলিক সার্চ সেটআপ একটি কোডিং এজেন্টের প্রয়োজনীয় প্রয়োজনীয়তাগুলির মধ্যে মাত্র 57% ধরতে পেরেছে। একটি যাচাইকরণ স্তর যোগ করলে তা 100%-এ পৌঁছেছে।

8টি কাজের মধ্যে, বেসলাইন শূন্যটি সঠিক করেছে, মৌলিক সার্চ 4টি সঠিক করেছে, এবং ইনটেন্ট-সচেতন সার্চ 8টি-ই সঠিক করেছে। আমি এই সব করেছি শূন্য এমবেডিং, শূন্য ভেক্টর ডেটাবেস, এবং পাইপলাইনে একেবারেই কোনো LLM কল ছাড়াই।

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

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

এটি কোনো বানানো পরিস্থিতি নয়। এটি এই নিবন্ধের জন্য আমি যে প্রকৃত পরীক্ষার কেসটি ব্যবহার করেছি। নীচে, আমি আপনাকে দেখাব কীভাবে তিনটি ভিন্ন পদ্ধতি এই সঠিক সমস্যাটি পরিচালনা করে।