Naia ADK-তে ডকুমেন্ট-চালিত মাল্টি-AI ডেভেলপমেন্ট প্রসেস: Jev দিয়ে দক্ষতা পরীক্ষা

হ্যালো। আমি লিউক (Luke), Naia-র নির্মাতা।

Naia সাধারণ ব্যবহারকারীদের কাছে ক্যারেক্টার এজেন্টের একটি পণ্যের মতো মনে হতে পারে, তবে আমার দৈনন্দিন কাজের একটি বড় অংশ সফটওয়্যার ডেভেলপমেন্ট। তাই এর জন্য ডেভেলপমেন্ট অবকাঠামো তৈরি করা এবং Naia-র ডেভেলপমেন্ট অবকাঠামো ব্যবহার করে কর্পোরেট ক্লায়েন্টদের সফটওয়্যার ডেভেলপমেন্ট পরিচালনা করা আমার কাজের অংশ। পূর্বে আমি "হার্নেস ইঞ্জিনিয়ারিং: Re:Zero থেকে শুরু হওয়া এআই সফটওয়্যার ইঞ্জিনিয়ারিং" (কোরিয়ান সংস্করণ, ইংরেজি সংস্করণ) শিরোনামে একটি বই প্রকাশ করেছিলাম। এরপর থেকেও এআই এজেন্ট-ভিত্তিক ডেভেলপমেন্ট প্রসেস আরও উন্নত করার জন্য আমরা নিরবচ্ছিন্ন প্রচেষ্টা চালিয়ে যাচ্ছি।

আজ আমি Naia ডেভেলপমেন্টের জন্য তৈরি করা সফটওয়্যার ডেভেলপমেন্ট প্রসেস ও আউটপুট উন্মুক্ত করছি এবং সাম্প্রতিক জনপ্রিয় সিদ্ধান্ত মডেল Jev কীভাবে এই ডেভেলপমেন্ট প্রসেসে যুক্ত করার চেষ্টা করছি তা শেয়ার করছি।

এই ডেভেলপমেন্ট প্রসেসে আমার অর্জনের প্রধান লক্ষ্য ছিল ৩টি: দৃশ্যমানতা (Visibility), সমান্তরালকরণ (Parallelization), এবং ব্যয় অপ্টিমাইজেশন (Cost Optimization)।

• দৃশ্যমানতা : ডেভেলপমেন্ট সঠিকভাবে এগোচ্ছে কি না এবং মডেল ড্রিফট ঘটলে ঠিক কোন ধাপে সমস্যা হয়েছে তা শনাক্ত করা।
• সমান্তরালকরণ : মাল্টি-এজেন্টকে সমান্তরালে কাজ ভাগ করে দিয়ে ডেভেলপমেন্টের গতি বাড়ানো।
• ব্যয় অপ্টিমাইজেশন : ব্যয়-অপ্টিমাইজড মডেল ব্যবহার করা। Jev এক্ষেত্রে একটি চমৎকার বিকল্প।

কাজের নিয়ম ব্যবস্থা (Harness)-র মূল কাঠামো নিচে ওপেন সোর্স হিসেবে উন্মুক্ত রয়েছে:

• ব্যক্তিগত ওয়ার্কস্পেসের মূল কাঠামো ও কাজের নিয়ম ব্যবস্থা (Harness): nextain/naia-adk
• দল ও প্রকল্পের সহযোগিতার মূল কাঠামো: nextain/naia-pj-adk
• কমিউনিটি অংশগ্রহণের নির্দেশিকা: nextain/naia-comm-public
• Jev হলো TypeSafe AI কর্তৃক প্রকাশিত একটি সিদ্ধান্ত মডেল।

এই নিবন্ধে বর্ণিত টাস্ক কিউ (Task Queue), বোর্ড, রানার এবং পরিকল্পনা সংক্রান্ত ডকুমেন্টগুলো এখনও অভ্যন্তরীণভাবে উন্নয়নশীল পর্যায়ে রয়েছে এবং ব্যক্তিগত রাখা হয়েছে। বর্তমানে এই প্রসেসটিও একটি যাচাইকরণ পর্যায়ে রয়েছে এবং Naia-র ওয়েব প্ল্যাটফর্মে উন্মোচিত হতে যাওয়া নতুন ফিচার: লিপ-সিঙ্ক ও গান গাইতে সক্ষম ভিডিও অবতার, Naia Visual Agent Studio-র উন্নয়নে পরীক্ষামূলকভাবে ব্যবহৃত হচ্ছে। এগুলো এখনই জনসমক্ষে প্রকাশ না করার কারণ হলো, এগুলো দলগত প্রকল্পে যৌথভাবে ব্যবহারের জন্য এখনও সম্পূর্ণ প্রস্তুত নয়; গুছিয়ে নেওয়ার সাথে সাথে আমরা অতিরিক্ত অংশগুলো প্রকাশ করব।

এই নিবন্ধে ও আমাদের ডেভেলপমেন্ট ডকুমেন্টে ব্যবহৃত সংক্ষিপ্ত রূপ

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

1. প্রবর্তনের পটভূমি ও সমস্যা চিহ্নিতকরণ

এআই এজেন্টদের ওপর ডেভেলপমেন্টের দায়িত্ব ব্যাপকভাবে ছেড়ে দিলে তারা ব্যাকএন্ড ছাড়াই ব্যবহারকারী ইন্টারফেস (UI, User Interface) তৈরি শুরু করে, অথবা মক অবজেক্ট দিয়ে চালানো পরীক্ষাকে পাস হিসেবে রিপোর্ট করে। তাই আমরা পরিকল্পনা উপর থেকে নিচে (Top-down) এবং ডেভেলপমেন্ট নিচ থেকে উপরে (Bottom-up) পরিচালনা করি। পরিকল্পনা সামগ্রিক ব্যবহারকারীর অভিজ্ঞতা থেকে নেমে আসে, আর ডেভেলপমেন্ট কার্যকর ন্যূনতম ইউনিট থেকে গড়ে তোলা হয়, তবে ব্যাকএন্ড বাস্তবিকভাবে ভেদ করার পরেই কেবল ইন্টারফেস সংযুক্ত করা হয়। স্ক্রিন থেকে শুরু করলে ইন্টিগ্রেশনের সময় বড় ধরনের রদবদলের ঝুঁকি খুব বেশি থাকে।

2. ডকুমেন্ট-চালিত কাজের ধারা ও ডেভেলপমেন্ট প্রসেস

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

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

ডকুমেন্ট ভিউয়ারে ডেভেলপমেন্ট প্রক্রিয়ার পৃষ্ঠা।

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

পরিকল্পনা ডকুমেন্টের প্রতিটি অংশের জন্য ইস্যু, বাস্তবায়নের অবস্থান এবং যাচাইয়ের অবস্থা এক স্থানে দেখার Studio সমন্বিত সূচি।

3. পরীক্ষার তিন স্তরের কাঠামো এবং ক্রমের নিয়মাবলী

পরীক্ষা শিল্প-মানক নাম অনুসারে তিনটি স্তরে বিভক্ত।

• ইউনিট টেস্ট (UT): কার্যকরী ইউনিট (FE) স্পেসিফিকেশন অনুযায়ী কাজ করছে কি না তা দেখে।
• ইন্টিগ্রেশন টেস্ট (IT): স্ক্রিন ছাড়া বাস্তব ব্যাকএন্ড উপাদানগুলোকে শেষ পর্যন্ত ভেদ করে। কেবল মক অবজেক্টের মধ্য দিয়ে যাওয়া পরীক্ষা গ্রহণ করা হয় না।
• ব্যবহারকারীর সম্পূর্ণ যাত্রার পরীক্ষা (E2E): বাস্তব ব্রাউজার স্ক্রিন থেকে বাস্তব ব্যাকএন্ড পর্যন্ত ব্যবহারকারীর একটি একক যাত্রা ভেদ করে। SP-তে স্ক্রিন না থাকা ইউনিটগুলোই কেবল E2E ছাড়া ইন্টিগ্রেশন টেস্টের মাধ্যমে বন্ধ করা হয়; স্ক্রিন থাকলে বর্তমান পরিবর্তন শুধু ব্যাকএন্ডে হলেও E2E বাধ্যতামূলক। মানদণ্ড হলো SP, বাস্তবায়নকারীর পরিবর্তন (Diff) নয়।

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

স্বাধীন যাচাইকরণ (QC) বাস্তবায়নকারীর পরীক্ষা থেকে আলাদাভাবে পরিচালিত হয়। UC এবং FE না দেখে, কেবল PC এবং SP-র ওপর ভিত্তি করে অনাকাঙ্ক্ষিত ইনপুট ও ব্যতিক্রমী পরিস্থিতিতে পণ্যের প্রতিশ্রুতি বজায় রয়েছে কি না তা আক্রমণাত্মকভাবে যাচাই করে। কারণ UC এবং FE দেখলে কেবল সেই সংকীর্ণ সীমার মধ্যে যাচাই করার প্রবণতা দেখা দিতে পারে। ডেভেলপমেন্টের শেষ দিকের ধাপ হওয়ায় এখনো এটি সম্পূর্ণ বাস্তবিকভাবে যাচাই করা সম্ভব হয়নি।

4. Git-ভিত্তিক টাস্ক কিউ এবং কাজের বোর্ড

কে, কখন, কী কাজ করেছে তা বিশ্বস্ততার সাথে নিশ্চিত করার জন্য কাজগুলোকে একটি Git রিপোজিটরি (naia-comm)-র টাস্ক কিউ দিয়ে পরিচালনা করা হয়। এখনো কোনো শেয়ার্ড সার্ভার নেই; লক্ষ্য হলো যাচাইকরণের পর একটি ডেভেলপমেন্ট সার্ভার তৈরি করা এবং একাধিক ডিভাইস ও ডেভেলপারের মধ্যে সহযোগিতাকে সক্ষম করা।

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

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

এটি কাজের বোর্ডের স্ক্রিন (অভ্যন্তরীণ ঠিকানা আড়াল করা হয়েছে)। উপরের মেট্রিকগুলো naia-comm-এর main শাখার কিউ রেকর্ডগুলোকে একত্রিত করে: ক্যাপচারের সময়ে ২২৮টি টাস্ক আইটেমের মধ্যে ১০টি উপলব্ধ ছিল, ১টি চলমান ছিল এবং ৬৫টি বর্তমানে সফল ফলাফল ছিল, যেখানে অনিবন্ধিত রানার নামের ৪টি সফল রেকর্ডে সতর্কতা যুক্ত ছিল।

5. কাজের নিয়ম ব্যবস্থা ও মাল্টি-এজেন্ট সহযোগিতার কাঠামো

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

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

※ মডেল বিন্যাস পরীক্ষা পর্যায়ে রয়েছে এবং পরিবর্তিত হতে পারে।

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

উদাহরণস্বরূপ, "ঘোষিত রিপোজিটরি চেকআউটের মিল" এর মতো অবস্থান সংক্রান্ত পরীক্ষা কেবল রানারের মাধ্যমে চলার সময়েই কার্যকর হয় এবং সরাসরি কাজের নির্দেশনার মাধ্যমে চালু করা কার্যক্রমে প্রযোজ্য হয় না।

6. স্বাধীন তদন্তের ওপর ভিত্তি করে প্রতিপক্ষ পর্যালোচনা

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

7. পরিলক্ষিত ফলাফল ও সীমাবদ্ধতা

পরিলক্ষিত ফলাফল

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

পরিলক্ষিত সীমাবদ্ধতা ও দুর্বলতা

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

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

8. Jev-এর মাধ্যমে যাচাইকরণ দক্ষতা ও ভবিষ্যৎ করণীয়

পর্যালোচনার চাপ কমাতে আমরা যাচাইকরণকে তিনটি স্তরে ভাগ করার চেষ্টা করেছি। এর মধ্যে দ্বিতীয় স্তরে, সাম্প্রতিক কম খরচ ও দ্রুত গতির সুবিধা সম্পন্ন Jev যুক্ত করার সম্ভাব্যতা নিয়ে প্রযুক্তিগত যাচাই চলছে।

• প্রথম স্তর, যান্ত্রিক পরীক্ষা (স্ক্রিপ্ট): যে বিষয়গুলোতে কেবল সাধারণ মিল দেখতে হয়: পরীক্ষার রসিদ পাস/ব্যর্থ (০টি ব্যর্থতা, এক্সিট কোড ০), URL প্রতিক্রিয়া, ফাইলের উপস্থিতি।
• দ্বিতীয় স্তর, ধরন নির্ধারণ (Jev): যখন ইন্টিগ্রেশন টেস্ট (IT) এবং E2E রসিদ "পাস" বলে, তখন পরীক্ষাটি সত্যিই বাস্তব ব্যাকএন্ড ভেদ করেছে নাকি কেবল মক অতিক্রম করে পাস হয়েছে তা নির্ধারণ করা। ইউনিট টেস্ট (UT) মূলত মক ব্যবহার করতে পারে, তাই সেগুলো এর আওতাভুক্ত নয়।
• তৃতীয় স্তর, দিকনির্দেশনামূলক বিচার (উচ্চস্তরের মডেল ও মানুষ): কাজের পরিধি ও উদ্দেশ্য সংগতিপূর্ণ কি না।

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

যাচাইকরণের ফলাফল

আত্মবিশ্বাস ০.৮৫ বা তার বেশি হলে এবং ভিন্নভাবে প্রশ্ন করলেও একই উত্তর পাওয়া গেলেই কেবল Jev-এর সিদ্ধান্ত গ্রহণ করে বাকিগুলো বড় ভাষার মডেল (LLM)-এর কাছে হস্তান্তর করার কৌশলের মাধ্যমে, ৮৭১টি টেস্ট ফাইলে (চূড়ান্ত মূল্যায়নে ২৫৭টি) আমরা পরিমাপ ও অনুমান করেছি যে সময় প্রায় ৬৬% এবং খরচ প্রায় ৬০~৭০% কমানো সম্ভব (সময় Gemini 3.8 Flash-এর সাপেক্ষে পরিমাপ করা এবং খরচ Opus ও Luna-র মতো মডেলের ইউনিট মূল্যের ভিত্তিতে হিসাব করা হয়েছে)।

Jev-এর ৯৭১টি কলের খরচ ছিল ০.২২ ডলার, এবং একটি সিদ্ধান্তে Jev-এর সময় লেগেছে প্রায় ০.৭ সেকেন্ড যেখানে LLM-এর লেগেছে প্রায় ১২ সেকেন্ড।

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

ভবিষ্যৎ করণীয়

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

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