অ্যানথ্রোপিক সম্প্রতি Claude মডেলের একাধিক প্রযুক্তিগত চ্যালেঞ্জের মুখোমুখি হয়েছে। ওয়াটারমার্ক এমবেডিং সীমাবদ্ধতার কারণে কোড জেনারেশনের স্বাধীনতা কমেছে; Sonnet 5-এর অ্যাডাপটিভ থিংকিং মেকানিজম একই মডেলকে বিভিন্ন কম্পিউটেশনাল ইনপুট সমন্বয় করতে সক্ষম করেছে, যা পণ্য লাইনের ক্ষমতার সীমানা অস্পষ্ট করেছে; 1M কনটেক্সট যদিও পর্যাপ্ত মনে হয়, কিন্তু দীর্ঘ Agent সংলাপে মডেলটি বাস্তবে শুধুমাত্র 20%-30% পর্যন্তই কার্যকরভাবে ব্যবহার করতে পারে, তারপর এটি অবস্থা বিশৃঙ্খলা এবং উপেক্ষা শুরু করে; কনটেক্সট সংকুচিতকরণের সময় কোন তথ্যগুলি এখনও কার্যকর, তা চিহ্নিত করা কঠিন, অস্থায়ী ধারণাগুলি ভুলভাবে সত্যে পরিণত হতে পারে; Agent সক্রিয়ভাবে পরিবেশটি পরিবর্তন করার পর, মডেলটি মূল সমস্যা নয়, বরং নিজেই তৈরি করা নতুন ত্রুটির বিশ্লেষণের দিকে ঝুঁকছে। নিবন্ধটি উল্লেখ করেছে যে, long Agent-এর reliability-এর উপর নির্ভরশীলতা越来越 depends on state clarity, action verifiability, and error rollback capability, rather than mere single-step model performance.লেখক এবং উৎস: লেইফেঙ্গো
মডেলের স্কোর কমে যাওয়ার চেয়ে আরও সমস্যার বিষয় হলো, মডেলটি এখনও আপগ্রেড হচ্ছে, কিন্তু ব্যবহারকারীরা এটিকে ক্রমাগত ব্যবহারযোগ্য বলে মনে করছেন না।
অ্যানথ্রোপিক সম্প্রতি এই ধরনের একটি অনুভূতি দিয়েছে।
এই কয়দিনে X-এ একটি পোস্টে ক্লডের এই সময়ের কয়েকটি সাধারণ অসন্তুষ্টি একত্রিত করা হয়েছে: টেক্সট এবং কোডে মেশিন-পঠনযোগ্য মার্কার যোগ করা হচ্ছে, Sonnet 5-এর বাস্তব অভিজ্ঞতা মডেল আপগ্রেডের ঘোষণার সাথে মানানসই নয়, Fable 5 বেশি দামে বিক্রি হচ্ছে, কিন্তু এটি Opus 5-এর চেয়ে কোথায় বেশি ভালো তা বোঝা যাচ্ছে না; একটি আরও চোখে পড়া প্রতিক্রিয়া হলো, Fable 5-এর কনটেক্সট শুধুমাত্র ২০%–৩০% পর্যন্ত ব্যবহার হচ্ছে, তারপরের ক্ষমতা কমতে শুরু করছে।

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

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

পেপার: https://arxiv.org/pdf/2301.10226
প্রাকৃতিক ভাষায় প্রায়শই একাধিক অর্থগতভাবে কাছাকাছি প্রতিদান থাকে। একই অর্থকে শব্দ পরিবর্তন বা বাক্যের ক্রম পরিবর্তন করে প্রকাশ করা যায়, এবং মডেলটি অনেক স্থানে কিছুটা জেনারেশন রিডানডেন্সি রাখে। টেক্সট ওয়াটারমার্কিংয়ের একটি সাধারণ পদ্ধতি হলো এই রিডানডেন্সির ব্যবহার, যেখানে একাধিক গ্রহণযোগ্য টোকেনের মধ্যে স্বল্প পরিমাণে নমুনা সম্ভাবনা পরিবর্তন করে, যথেষ্ট দীর্ঘ সময়ের জন্য পরিসংখ্যানগত প্যাটার্ন তৈরি করা।
কোডে অসংখ্য নিম্ন এনট্রপি অবস্থান রয়েছে। ভেরিয়েবল ঘোষণার পরে, পরবর্তী রেফারেন্সগুলি প্রায় সর্বদা একই নাম ব্যবহার করে; JSON ফিল্ড, উদ্ধৃতি এবং প্যারেনথিসিস কঠোর কাঠামোর দ্বারা নিয়ন্ত্রিত; ফাংশন প্যারামিটারগুলি ইন্টারফেসের সাথে মিলতে হবে; পাথ, রেগুলার এক্সপ্রেশন, SQL, Shell কমান্ডে, একটি টোকেনের পরিবর্তনই সরাসরি আচরণ পরিবর্তন করতে পারে।
সম্ভাব্যতা বণ্টন দেখে, এই অবস্থানগুলি প্রায়শই খুব তীক্ষ্ণ হয়। সঠিক টোকেনটি উচ্চ সম্ভাব্যতা দখল করে, অন্যান্য প্রতিদ্বন্দ্বী অন্য কোনো প্রকাশ নয়, বরং সম্ভবত ভুল। তাই, কোড ওয়াটারমার্কের মূল সীমাবদ্ধতা হল এনকোডিং ক্ষমতা।
যদি একটি অবস্থানে শুধুমাত্র একটি যুক্তিসঙ্গত আউটপুট থাকে, তবে এটির অতিরিক্ত সংকেত বহনের জন্য প্রায় কোনও স্থান থাকে না; যদি সিস্টেমটি শুধুমাত্র উচ্চ এনট্রপি অবস্থানগুলিতে ট্যাগ এমবেড করে, তবে কোডের দৈর্ঘ্য ছোট, স্ট্রাকচারড টোকেনের অনুপাত বেশি এবং ব্যবহারযোগ্য অবস্থানের অভাব দেখা দেয়।
অতএব, সনাক্তকরণ শক্তি, উত্পাদন গুণমান এবং পরিবর্তনের প্রতিরোধ ক্ষমতার মধ্যে একটি সরাসরি বিনিময় থাকে: সংকেত খুব দুর্বল হলে সনাক্ত করা কঠিন হয়, সীমাবদ্ধতা খুব শক্তিশালী হলে সঠিক উত্পাদনকে প্রভাবিত করতে পারে, এবং ফরম্যাটিং বা আংশিক পুনর্লিখনের পরেও সনাক্তকরণ ক্ষমতা বজায় রাখতে বেশি সংকেত পুনরাবৃত্তির প্রয়োজন হয়।

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

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

রেফারেন্স লিঙ্ক: https://platform.claude.com/docs/en/build-with-claude/effort
এই পরিবর্তনটি কোডিং এজেন্টে বিশেষভাবে স্পষ্ট। একটি বাগের সম্মুখীন হলে, Claude কেবল পরিবর্তনের প্রস্তাব তৈরি করার পাশাপাশি কোন ফাইলগুলি পড়তে হবে, কোন কল চেইনটি অনুসরণ করতে হবে, কতগুলি প্রত্যাশিত অনুমান রাখতে হবে, টেস্ট চালানো উচিত কি না, ডিপেন্ডেন্সি চেক করা চালিয়ে যাওয়া উচিত কি না, এবং কখন প্রমাণটি যথেষ্ট বলে মনে করতে হবে—সেগুলিরও সিদ্ধান্ত নিতে হবে।
এই কাজগুলিকে একটি অনুসন্ধান গাছ হিসাবে দেখা যেতে পারে। কম গণনা ব্যয় অর্থ শাখাগুলি আগেই কেটে ফেলা এবং দ্রুত সিদ্ধান্ত গ্রহণ; বেশি ব্যয় মডেলকে অনুসন্ধান এবং যাচাই করতে দেয়, যা প্রমাণের অভাবে সরাসরি কাজ করার সম্ভাবনা কমিয়ে দেয়।

রেফারেন্স লিঙ্ক: https://platform.claude.com/docs/en/build-with-claude/effort
অতএব effort শুধুমাত্র thinking দৈর্ঘ্য নয়, বরং একটি Agent টাস্ক কতটা বিস্তৃত অনুসন্ধানের অনুমতি দেয় তা নিয়ন্ত্রণ করে। এটি Anthropic-এর মডেল হাইয়ারার্কি পরিবর্তন করবে।
যদি একটি সাধারণ coding টাস্ক Opus-এর জন্য ইতিমধ্যেই কঠিন না হয়, তাহলে effort বাড়ানোর পর, Opus দ্রুত পারফরম্যান্স প্ল্যাটফর্ম এলাকায় প্রবেশ করতে পারে। Fable যদিও শক্তিশালী বেস মডেল নিয়েছে, তবুও এটির জন্য পরিষ্কারভাবে অভিজ্ঞতার পার্থক্যে রূপান্তরিত হওয়ার জন্য বেশি কঠিনতা বাকি নেই।
ব্যবহারকারী অনুরোধ শুরু থেকেই মডেলগুলির মধ্যে মূল্যের পার্থক্য প্রদান করে। তাই Fable-এর মূল্য প্রকাশ করা সহজ হবে সাধারণ কোড ব্যাখ্যা, ছোট পুনর্গঠন বা সাধারণ debugging-এর পরিবর্তে অপরিচিত কোডবেস, বহু-পর্যায়ের পরিকল্পনা, বিভিন্ন টুলের মধ্যে কাজ, দীর্ঘসময়ের স্বাধীন বাস্তবায়ন, এবং ত্রুটি ঘটার পরও পুনরুদ্ধারের প্রয়োজনীয়তা সহ কাজগুলিতে।

রেফারেন্স লিঙ্ক: https://www.anthropic.com/news/claude-opus-5
এর অর্থ হচ্ছে উচ্চতর মডেলগুলি যা বিক্রি করছে, তা পরিবর্তন হচ্ছে। এগুলি এখন শুধুমাত্র “এই রাউন্ডের উত্তরগুলি বেশি শক্তিশালী” বিক্রি করছে না, বরং আরও জটিল ট্রাজেক্টরিতে অতিরিক্ত বিশ্বস্ততা।
সমস্যা হলো, এই সুবিধাটি পর্যাপ্ত দীর্ঘ কাজের ক্ষেত্রেই প্রকাশ পায়, আর কাজ যত দীর্ঘ হয়, মডেলের ক্ষমতা ততই একমাত্র নির্ধারক না হয়ে প্রসঙ্গের অবস্থা কেন্দ্রীয় ভূমিকা পায়।

03
তৃতীয় পাপ: অসংখ্য ইতিহাস ধারণ করতে পারে, কিন্তু বর্তমান অবস্থা বুঝতে পারে না
1M কনটেক্সট দেখে এটিকে একটি বিশাল কাজের মেমোরি হিসেবে বুঝা যায়, তাই যখন Claude শুধুমাত্র 200K বা 300K টোকেন ব্যবহার করেই তথ্য হারায়, পুনরাবৃত্তি করে বা স্টেট বিভ্রান্তির সম্মুখীন হয়, তখন এটি খুবই অপ্রত্যাশিত মনে হয়।
কিন্তু কনটেক্সট উইন্ডো ক্ষমতা পরিমাপ করে, অবস্থা সামঞ্জস্যতা নয়। দীর্ঘ এজেন্ট সেশন একটি স্থির দলিল নয়, বরং একটি অবিরাম যোগ হচ্ছে এমন এক্সিকিউশন হিস্ট্রি।

রেফারেন্স লিঙ্ক: https://platform.claude.com/docs/en/build-with-claude/context-windows
একটি ফাইল একাধিকবার সংশোধন করা হতে পারে; একটি বাগ প্রথমে ক্যাশে সমস্যা হিসাবে চিহ্নিত করা হয়েছিল, পরে এটি সমান্তরালতা থেকে আসছে বলে আবিষ্কৃত হয়েছিল; একটি পরীক্ষা প্রথমে ব্যর্থ হতে পারে, তারপর সফল হয়, এবং নতুন সংশোধনের কারণে আবারও ব্যর্থ হতে পারে। পুরনো কনটেন্ট অবস্থা পরিবর্তনের সাথে স্বয়ংক্রিয়ভাবে মুছে ফেলা হয় না, নতুন কনটেন্ট শুধুমাত্র পিছনে যোগ করা হয়।
এখানে সমস্যাটি শুধু রিট্রিভাল নয়। মডেলটিকে কেবল বর্তমান কাজের সাথে সম্পর্কিত তথ্য খুঁজে বার করতে হবে, এটিও বিচার করতে হবে যে এই তথ্যগুলি এখনও বৈধ কিনা।
পুরানো ফাংশন এবং নতুন ফাংশন অত্যন্ত সদৃশ, পুরানো টেস্ট লগ এবং নতুন টেস্ট লগে অনেক একই টোকেন রয়েছে, এবং পূর্বে প্রত্যাখ্যাত বিশ্লেষণও বর্তমান সমস্যার সাথে অর্থগতভাবে অত্যন্ত সম্পর্কিত। অ্যাটেনশন এই কনটেন্টগুলি খুঁজে পাওয়া কঠিন নয়, কঠিন হলো তাদের মধ্যে কভারেজ সম্পর্ক নির্ধারণ করা।
ডাটাবেস ভার্সন নম্বর, আপডেট সময়, ট্রানজেকশন এবং স্পষ্ট ক্ষেত্রের মাধ্যমে বর্তমান অবস্থা বজায় রাখতে পারে, যখন প্রাকৃতিক ভাষার প্রসঙ্গে সাধারণত এই ধরনের কাঠামো থাকে না। এটি আরও কাছাকাছি অ্যাপেন-অনলি লগের, যেখানে মডেলটিকে ঘটনাগুলির ক্রম থেকে বর্তমান বিশ্বটি কী তা নিজেই পুনরুদ্ধার করতে হয়।

রেফারেন্স লিঙ্ক: https://platform.claude.com/docs/en/build-with-claude/context-windows
সুতরাং, দীর্ঘ কনটেক্সটের জটিলতা টোকেন ব্যবহারের অনুপাতের সাথে সরলভাবে মিলে যায় না। 250K টোকেনের স্ট্যাটিক ডকুমেন্টটি 250K টোকেনের এজেন্ট ইতিহাসের চেয়ে অনেক বেশি সহজে প্রসেস করা যায়, কারণ পরবর্তীটিতে ব্যাপকভাবে পরিবর্তিত অবজেক্ট, পর্যায়ক্রমিক বিচার, টুলের ফলাফল এবং এখন অকার্যকর স্ট্যাটাস রয়েছে।
Thinking history আরও জটিলতা বাড়াবে। সেশনে শুধু “কী ঘটেছিল” নয়, বরং “তখন কেন এই সিদ্ধান্ত নেওয়া হয়েছিল” তাও সংরক্ষিত থাকতে পারে। যদি প্রাথমিক reasoning একটি পরবর্তীতে প্রত্যাখ্যাত ধারণার উপর ভিত্তি করে গঠিত হয়, তবুও সেই reasoning যদি বর্তমান সমস্যার সাথে অত্যন্ত সম্পর্কিত হয়, তবে এটি পরবর্তী সিদ্ধান্তগুলিতে অংশগ্রহণ করতে থাকতে পারে।
সুতরাং 1M কনটেক্সটের প্রকৃত সীমাবদ্ধতা শুধু কতটা তথ্য রাখা যায় তার ব্যাপার নয়, বরং একই অবজেক্টের ক্রমবর্ধমান ইতিহাসের ভার্সনগুলির পরেও মডেলটি বর্তমান ভার্সনটি স্থিতিশীলভাবে পুনরুদ্ধার করতে পারে কিনা।

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

রেফারেন্স লিঙ্ক: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
কমপ্যাকশনকে যা সমাধান করতে হবে তা হলো “কোন কনটেন্ট গুরুত্বপূর্ণ” নয়, বরং “কোন কনটেন্ট এখনও বৈধ”। একটি ইতিহাসে একসাথে থাকতে পারে সম্পন্ন টাস্ক, পরে বাতিল করা সিদ্ধান্ত, বর্তমানে প্রযোজ্য ইন্টারফেস কনস্ট্রেইন্ট, মেয়াদোত্তীর্ণ টেস্ট রেজাল্ট এবং অস্থায়ী ওয়ার্কঅ্যারাউন্ড। কমপ্যাকশনটি এই টাইম-স্টেটগুলিকে পুনর্সংগঠিত করবে যাতে পরবর্তী রাউন্ডের জন্য একটি কার্যকরী প্রতিনিধিত্ব তৈরি হয়।
যদি "বর্তমানে সমস্যাটি ক্যাশে থেকে আসছে বলে সন্দেহ করা হচ্ছে" কে "সমস্যাটি ক্যাশে থেকে আসছে" এভাবে সংক্ষিপ্ত করা হয়, তবে অস্থায়ী ধারণাটি বাস্তবতায় পরিণত হয়; যদি একটি পুরনো ও বাতিলকৃত পদ্ধতি এখনও সারাংশে প্রবেশ করে, তবে পরবর্তী Agent সম্ভবত পুরনো পথেই চলতে থাকবে; যদি কোনো গুরুত্বপূর্ণ সীমাবদ্ধতা সারাংশে প্রবেশ না করে, তবে মডেলটি পরবর্তীতে এটিকে আরও দেখবেই না।
সুতরাং কমপ্যাকশনের মূল মাপকাঠি হল কম্প্রেশন রেট নয়, বরং স্টেট ফিডেলিটি। এটিই হল যে কারণে জিট, টেস্ট, টাস্ক ফাইল, মেমোরি এবং স্ট্রাকচার্ড হ্যান্ডঅফ দীর্ঘসময়ের এজেন্টে বাড়তে থাকছে।
এগুলো শুধুমাত্র মডেলের দেখার জন্য তথ্য বাড়ানো নয়, বরং দীর্ঘস্থায়ীভাবে বৈধ অবস্থাগুলোকে প্রাকৃতিক ভাষার ইতিহাস থেকে বাহ্যিক সিস্টেমে স্থানান্তরিত করছে। Git বর্তমান কোড ভার্সনটি স্পষ্টভাবে চিহ্নিত করে, টেস্টগুলো যাচাইযোগ্য ফলাফল দেয়, টাস্ক ফাইলগুলো সম্পন্নতা রেকর্ড করে, এবং স্ট্রাকচারড স্টেট বর্তমান উপসংহার এবং ইতিহাসের চেষ্টাগুলোকে পৃথক করে।
প্রেক্ষাপটটি সমৃদ্ধ ইতিহাস ধারণ করতে পারে, কিন্তু দীর্ঘমেয়াদে সমস্ত স্টেট ম্যানেজমেন্টের দায়িত্ব বহন করতে পারে না।

রেফারেন্স লিঙ্ক: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

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

রেফারেন্স লিঙ্ক: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
যদি এটি চিনতে পারে যে “এই নতুন ত্রুটিগুলি গত পরিবর্তনের পরে দেখা দিয়েছে,” তবে এটি পূর্ববর্তী অনুমানগুলি পুনরায় পরীক্ষা করার জন্য রোলব্যাক করতে পারে; যদি এই কার্যকারণ সম্পর্কটি স্থাপন না করা হয়, তবে নতুন ত্রুটিগুলিকে একটি একটি করে স্বতন্ত্র সমস্যা হিসাবে বিবেচনা করা হতে পারে।
এখন প্রতিটি স্থানীয় পদক্ষেপের জন্য সম্ভবত কিছু ভিত্তি থাকতে পারে, কিন্তু সম্পূর্ণ কার্যক্রমটি মূল সমস্যা থেকে বিচ্যুত হয়ে গেছে। তাই দীর্ঘ এজেন্টের বিশ্বস্ততা শুধুমাত্র একটি পদক্ষেপের সঠিকতা দ্বারা নির্ধারিত হওয়া উচিত নয়। আরও গুরুত্বপূর্ণ হলো, ভুলটি পরিবেশে প্রবেশ করার পরে, সিস্টেমটি কি এটি শনাক্ত, কারণ নির্ণয় এবং পুনরুদ্ধার করতে পারে।
Git diff মডেলকে বলতে পারে যে কোন পরিবর্তনগুলি সাম্প্রতিকভাবে ঘটেছে, টেস্ট দিয়ে পরীক্ষা করা যায় যে কোন আচরণ ভেঙে গেছে কিনা, checkpoint এবং rollback দিয়ে ভুলের প্রসারণ সীমাবদ্ধ করা যায়, এবং স্বতন্ত্র evaluator মডেলের নিজস্ব ব্যাখ্যার বাইরে অতিরিক্ত যাচাই প্রদান করে।
এই উপাদানগুলির মূল কাজ হল এজেন্টকে বন্দর সংশোধন ক্ষমতা প্রদান করা।

রেফারেন্স লিঙ্ক: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

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