AI-translated from English; not yet reviewed by a fluent editor.

# Jev-এর বড় বাজি: আমরা যে সফটওয়্যার ব্যবহার করি, তার ভেতরে AI-নির্ভর সিদ্ধান্ত

> TypeSafe-এর CEO Diogo Almeida সফটওয়্যারের ভেতরে ছোট ছোট সিদ্ধান্ত নেওয়ার জন্য তৈরি AI-এর পক্ষে যুক্তি দেন। আমরা Jev-এর চালু, সীমা এবং অর্থবহ পরিবর্তনের প্রমাণ কী হতে পারে তা খতিয়ে দেখি।

By BIG CHANGE Editorial

Published: 2026-09-22T00:45:03.943Z
Updated: 2026-09-22T00:45:03.943Z
Canonical: https://bigchange.ai/blog/jev-typesafe-ai-decisions-software-diogo-almeida

![Pencil sketch of document cards passing through a small decision switch, constrained by a checklist, into two output trays.](https://bigchange.ai/api/media/file/jev-interview-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. A decision switch inside a larger workflow; not a depiction of Jev’s internal architecture.

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

TypeSafe AI ২০২৬ সালের ১৫ সেপ্টেম্বর প্রাথমিক প্রবেশাধিকারসহ Jev-এর পরিচয় করায়; এটি সেই সিদ্ধান্তগুলোকে লক্ষ্য করে। সফটওয়্যারের জন্য এটি সীমাবদ্ধ ও কাঠামোবদ্ধ উত্তর তৈরি করে। সাধারণ উদ্দেশ্যের মডেলের সঙ্গে দীর্ঘ কথোপকথনের ওপর অ্যাপ্লিকেশনের কতটা নির্ভর করা উচিত, তা নতুন করে ভাবার আহ্বান এই চালু। [TypeSafe-এর চালুর ঘোষণা](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

Latent Space-এর ২১ সেপ্টেম্বরের সাক্ষাৎকারে TypeSafe-এর সহপ্রতিষ্ঠাতা ও CEO Diogo Almeida এ যুক্তির সবচেয়ে পূর্ণাঙ্গ ব্যাখ্যা দেন; উপস্থাপক ছিলেন swyx। দুই ঘণ্টা ২২ মিনিটের কথোপকথনের সম্পূর্ণ ইংরেজি ক্যাপশন আমরা পর্যালোচনা করেছি এবং পণ্যের নথিপত্র যাচাই করেছি। এটি ওই সাক্ষাৎকার ও প্রকাশ্য প্রমাণের বিশ্লেষণ; আমরা স্বাধীনভাবে Jev-এর benchmark পরীক্ষা করিনি। [মূল সাক্ষাৎকারটি দেখুন](https://www.youtube.com/watch?v=cFx9Z3ZXca0)

আমাদের পাঠে, Jev-এর সবচেয়ে গুরুত্বপূর্ণ প্রস্তাবটি স্বয়ংক্রিয়তার একক নিয়ে। পুরো প্রক্রিয়ার দায়িত্ব নিরাপদে দেওয়ার আগে কোনো কোম্পানি বিদ্যমান কর্মপ্রবাহের ভেতরে সীমিত পরিসরের একটি বিচার স্বয়ংক্রিয় করতে পারে। সেই বিচার বারবার করার খরচ যথেষ্ট কম এবং পরিমাপ যথেষ্ট স্পষ্ট হলে, প্রতিটি আলাপকে chat session না বানিয়েও পরিচিত ব্যবসায়িক সফটওয়্যার কার্যকর সক্ষমতা পেতে পারে।

এতে কর্মপ্রবাহ নকশাকারী এবং ব্যবহারকারী—দুই পক্ষই প্রভাবিত হবেন। কোন কাজ অনুমোদিত, কোনটি ভুল বলে গণ্য হবে এবং ব্যতিক্রম কে সামলাবেন—এসব কাউকে ঠিক করতেই হবে। সেই সিদ্ধান্তগুলোর মান নির্ধারণ করবে, এই পদ্ধতি নির্ভরযোগ্য সেবা তৈরি করবে, না শুধু ভুল দ্রুত ঘটাবে।

## TypeSafe আসলে কী চালু করেছে

Jev-এর নথিবদ্ধ interface-এ একটি state এবং নির্দিষ্ট type-সহ কিছু প্রশ্ন দেওয়া হয়। এর তিনটি মৌলিক উপাদান হলো Choice—নির্দিষ্ট বিকল্পগুলোর মধ্যে বেছে নেয়; Score—একটি rubric অনুযায়ী মূল্যায়ন করে; এবং Noul—শূন্য থেকে একের স্কেলে কোনো বক্তব্যের সম্ভাবনা জানায়। Choice ও Score বণ্টন এবং confidence field ফেরত দেয়। Noul-এর আলাদা confidence field নেই। দেওয়া একই state ব্যবহার করেও প্রশ্নগুলো স্বাধীনভাবে মূল্যায়ন করা যায়। [TypeSafe-এর interface-সংক্রান্ত নথি](https://docs.typesafe.ai/introduction)

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

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

TypeSafe দ্রুত, স্বজ্ঞাত চিন্তার ভাষা ধার করে এই model category-কে System One বলে। নামটিকে নির্দিষ্ট কাজের ধরন বোঝানোর বিবরণ হিসেবে নিন। এটি মানবসদৃশ চিন্তার সনদ নয়, সহজ ও কঠিন কাজের মধ্যে স্পষ্ট সীমানাও প্রতিষ্ঠা করে না। ছোট প্রশ্নেও জটিল বিচার লুকিয়ে থাকতে পারে—বিশেষ করে প্রয়োজনীয় তথ্য না থাকলে।

## প্রকৌশলগত পরিবর্তন: ছোট, পরিদর্শনযোগ্য সিদ্ধান্ত

Almeida কাজকে ভাগ করার পক্ষে: সীমিত পরিসরের প্রশ্ন করুন, তারপর code-এ উত্তরগুলো একত্র করুন। [সাক্ষাৎকার, ১:০৩:০২ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=3782s)

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

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

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

TypeSafe-এর নথিভুক্ত pattern-এ একসঙ্গে একাধিক প্রশ্ন করা, score একত্র করা এবং অনিশ্চিত ঘটনা বাড়তি ব্যবস্থাপনার জন্য পাঠানো রয়েছে। এগুলো স্থাপত্যগত বিকল্পের বর্ণনা, কোনো নির্দিষ্ট ক্রেতা-প্রক্রিয়া তদারকিহীনভাবে চালানোর উপযোগী—তার প্রমাণ নয়। [TypeSafe-এর pattern](https://docs.typesafe.ai/patterns)

কার্যকর পরীক্ষা হলো, কাজ ভাগ করলে রোগনির্ণয় ও ফল—দুটিই উন্নত হয় কি না। কোন ধাপে ব্যর্থতা ঘটেছে তা ব্যাখ্যা করতে পারা মূল্যবান। ওই ব্যর্থতার হার ও পরিণতি কমানোই ব্যবসায়িক যুক্তি।

![Pencil diagram: an input document branches into three parallel questions, whose answers enter a rules box before action or review.](/api/media/file/jev-interview-inline-v1.png)

## উত্তর বৈধ হলেও ভুল হতে পারে

Jev “ভুল তথ্য বানাতে পারে না”—চালুর এই দাবিটি সীমিত অর্থে পড়তে হবে। TypeSafe-এর নিশ্চয়তা অনুমোদিত output schema-র সঙ্গে মেলার ক্ষেত্রে প্রযোজ্য। নির্বাচিত উত্তর সত্য কি না, তা এতে প্রতিষ্ঠিত হয় না। তাদের নিজস্ব ঘোষণাতেও schema-র নিশ্চয়তা আর পরীক্ষালব্ধ মূল্যায়ন আলাদা করে দেখানো হয়েছে। [TypeSafe-এর type safety ব্যাখ্যা](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

ধরা যাক, কোনো অ্যাপ্লিকেশনে মান হিসেবে আছে `damaged`, `late` এবং `other`। ফেরত দেওয়া `damaged` মানটি সম্পূর্ণ বৈধ, যদিও প্যাকেটটি শুধু দেরিতে এসেছে। চতুর্থ category বানাতে না পারা মডেলও ভুলটি বেছে নিতে পারে। তালিকায় সত্যিই দরকারি কোনো category বাদ থাকলে schema-টিই সমস্যার অংশ হয়ে ওঠে।

কাঠামোবদ্ধ output প্রকৌশলের বিদ্যমান পদ্ধতিও বটে। OpenAI ২০২৪ সালের আগস্টে schema-নিয়ন্ত্রিত Structured Outputs চালু করে এবং স্পষ্টভাবে জানায়, ফেরত আসা মানের ভেতরেও মডেল ভুল করতে পারে। তাই সব ধরনের কাঠামোবদ্ধ AI output উদ্ভাবনের কৃতিত্ব না দিয়ে Jev-কে তার সিদ্ধান্তের মান, অনিশ্চয়তা জানানোর পদ্ধতি, latency ও খরচের নির্দিষ্ট সমন্বয়ে বিচার করা দরকার। [OpenAI-এর মূল ঘোষণা ও সীমাবদ্ধতা](https://openai.com/index/introducing-structured-outputs-in-the-api/)

ক্রেতাদের জন্য এ পার্থক্য মূল্যায়ন-পরিকল্পনা বদলে দেয়। schema পরীক্ষা করে সফটওয়্যার উত্তরটি ব্যবহার করতে পারে কি না। তথ্যগত পরীক্ষা দেখে উত্তরটি প্রমাণের সঙ্গে মেলে কি না। নীতিগত পরীক্ষা দেখে ফলস্বরূপ কাজ অনুমোদিত কি না। এক পরীক্ষায় পাশ করা অন্যগুলোর বিকল্প নয়।

## সাক্ষাৎকারের সবচেয়ে গুরুত্বপূর্ণ চ্যালেঞ্জ: calibration

১:০৯ মিনিটে Almeida নিখুঁত calibration-এর ধারণা নাকচ করেন এবং মডেলের ভুল স্বীকার করেন। [সাক্ষাৎকার, ১:০৮:৫০ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4130s)

Calibration হলো বিভিন্ন পূর্বাভাস-গোষ্ঠীতে অনুমিত সম্ভাবনা ও পর্যবেক্ষিত ফলের তুলনা। প্রতিটি উচ্চ-সম্ভাবনার ঘটনায় সঠিক না হয়েও মডেল অনিশ্চয়তার সংকেত দিতে কাজে লাগতে পারে। TypeSafe-এর প্রাথমিক নির্দেশিকায় এই পার্থক্য স্পষ্ট রাখা হয়েছে। [TypeSafe-এর calibration ব্যাখ্যা](https://docs.typesafe.ai/introduction/machine-learning-primer)

API-র confidence field-এর ক্ষেত্রেও আরেকটি পার্থক্য জরুরি। TypeSafe একে উত্তরের বণ্টন থেকে হিসাব করা পরিসংখ্যান হিসেবে বর্ণনা করে। নির্বাচিত উত্তরটি সঠিক হওয়ার স্বাধীনভাবে মাপা সম্ভাবনার সঙ্গে এটি বিনিমেয় নয়। তাদের নথি কাজ ও তার পরিণতি অনুযায়ী threshold বেছে নিতে বলে। [TypeSafe-এর confidence নথি](https://docs.typesafe.ai/confidence)

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

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

Calibration নিয়ে গবেষণা Jev-এর বহু আগের। Chuan Guo ও সহলেখকদের ২০১৭ সালের বহুল উদ্ধৃত গবেষণায় আধুনিক neural network-এর দুর্বল calibration এবং তা উন্নত করার পদ্ধতি পরীক্ষা করা হয়েছিল। এটি সমস্যাটির প্রেক্ষাপট দেয়; TypeSafe-এর মডেল যাচাই করে না। [আধুনিক neural network-এর calibration নিয়ে গবেষণা](https://arxiv.org/abs/1706.04599)

## নির্ভরযোগ্যতার মধ্যে সেবা বদলালে কী ঘটে, সেটিও পড়ে

কথোপকথনে robustness-কে determinism থেকে আলাদা করা হয়েছে এবং দীর্ঘমেয়াদি সহায়তার কোনো সাধারণ প্রতিশ্রুতি ছাড়া সংস্করণ স্থিতিশীলতার কথা এসেছে। [সাক্ষাৎকার, ৪১:২৪ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=2484s) এবং [৪৯:৪০ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=2980s)

এগুলো কেনার আলাদা প্রশ্ন। একই input-এ একই output আসে কি না—তা determinism-এর প্রশ্ন। রেকর্ডের অপ্রাসঙ্গিক পরিচয়সংখ্যার মতো পরিবর্তনে আচরণ অযৌক্তিকভাবে বদলায় কি না—তা robustness-এর প্রশ্ন। মডেল একই ভুল উত্তর বারবার দিয়েও deterministic হতে পারে। আশপাশের কর্মপ্রবাহ নির্ভরযোগ্য থেকেও মডেলের output সামান্য ওঠানামা করতে পারে।

এই দুটির কোনোটিই সেবা-জীবনচক্রের ঝুঁকি মেটায় না। কোন model revision সিদ্ধান্তটি তৈরি করেছে, সেটি পাওয়া যাবে কি না এবং বিকল্প মডেল কীভাবে মূল্যায়িত হবে—ব্যবসার তা জানা দরকার। সরবরাহকারীর পরীক্ষায় উন্নতি হলেও ক্রেতার যত্নে সমন্বয় করা কর্মপ্রবাহের আচরণ বদলে যেতে পারে।

যুক্তিযুক্ত পদক্ষেপ হলো প্রতিনিধিত্বশীল উদাহরণ সংরক্ষণ, সংস্করণ নথিবদ্ধ করা এবং গুরুত্বপূর্ণ কাজ সরানোর আগে বিকল্প তুলনা করা। fallback-ও জরুরি: অন্যথায় নির্ভুল সিদ্ধান্ত-সেবাও অনুপলভ্য হতে পারে। অ্যাপ্লিকেশনের কাজ থামানো বা অন্যত্র পাঠানোর নিরাপদ উপায় না থাকলে বাস্তবে uptime-ও সিদ্ধান্তের মানের অংশ হয়ে যায়।

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

## গতি ও দামের সংখ্যার প্রেক্ষাপট কেন জরুরি

TypeSafe-এর প্রচারিত কর্মপ্রবাহ-ফলে গতিতে ১৯৩.৬ গুণ এবং খরচে ৪৪৪.৬ গুণ উন্নতি রয়েছে। ঘোষণায় বলা হয়েছে, কোম্পানির তৈরি কর্মপ্রবাহ থেকে পাওয়া এগুলো সর্বোচ্চ পর্যায়ের ফল। reference উত্তর নেওয়া হয়েছিল অন্য মডেলের সম্ভাব্যতার অনুমান থেকে; স্বাধীনভাবে যাচাই করা সঠিক শ্রেণিবিভাগ থেকে নয়। কোম্পানি আরও সতর্ক করে যে সংক্ষিপ্ত demo-তে Jev সুবিধা পায় এবং দীর্ঘমেয়াদে টেকসই মূল্য নির্ধারণ এখনও প্রতিষ্ঠিত হয়নি। [TypeSafe-এর মূল্যায়ন-সংক্রান্ত সীমা](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

সংখ্যার সঙ্গে এই সীমাগুলোও উল্লেখ করা উচিত। reference মডেলের সঙ্গে মিল তথ্যবহুল হতে পারে, কিন্তু মীমাংসিত ক্রেতা-ঘটনার বিপরীতে সঠিকতা মাপার সমান নয়। বিক্রেতা-নকশা করা কর্মপ্রবাহ ক্রেতার কাজে লাগতে পারে, কিন্তু সেই ক্রেতার অনুরোধের বণ্টনকে প্রতিনিধিত্ব নাও করতে পারে।

সঠিক তুলনায় পুরো কাজটি ধরতে হবে: প্রেক্ষাপট সংগ্রহ, সিদ্ধান্ত নেওয়া, নিয়ম প্রয়োগ, ব্যতিক্রম সামলানো এবং ব্যর্থতা থেকে সেরে ওঠা। মডেল call সস্তা হলেও review-তে অতিরিক্ত কাজ পাঠালে মোট খরচ বেশি হতে পারে। ধীর call-ও সাশ্রয়ী হতে পারে যদি তা ব্যয়বহুল পুনঃকাজ এড়ায়।

অ্যাপ্লিকেশন যে বাস্তব অঞ্চলে চলে সেখান থেকেও latency মাপা দরকার। সেবার অবকাঠামোর কাছে করা demo অন্যত্র থাকা ব্যবহারকারীর অভিজ্ঞতার প্রতিশ্রুতি নয়। ইন্টার‌্যাকটিভ ব্যবস্থায় গড়ের পাশাপাশি ধীর অনুরোধও পরীক্ষা করা উচিত; পটভূমির কাজের ক্ষেত্রে মোট throughput ও খরচ বেশি গুরুত্বপূর্ণ হতে পারে।

Jev-এর নামটি দক্ষতা বাড়লে ব্যবহারও বাড়তে পারে—এই ধারণা মনে করায়। পৃথক ব্যবসার জন্য তাতে বাজেটের প্রশ্ন ওঠে: কোন নতুন সিদ্ধান্ত মূল্যায়নের যোগ্য হবে, আর কোনগুলো শুধু সস্তা হয়েছে বলেই অপ্রয়োজনীয়ভাবে মূল্যায়িত হবে? আরও model call নিজে কোনো ফল নয়।

## ভিন্ন গবেষণা-লক্ষ্য, প্রমাণ এখনও অসম্পূর্ণ

Almeida-র গবেষণার যুক্তিতে data, কাজ বাছাই এবং RLCD যুক্ত হয়েছে preference optimization নিয়ে তাঁর সমালোচনার সঙ্গে। [সাক্ষাৎকার, ৭:২৩ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=443s) এবং [২২:১২ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=1332s)

RLCD-এর পূর্ণরূপ Reinforcement Learning for Calibrated Decisions। TypeSafe একে ব্যবহারযোগ্য সিদ্ধান্ত ও সম্ভাবনা শেখানোর পদ্ধতি হিসেবে তুলে ধরে এবং মানব-পছন্দ বা যাচাইযোগ্য পুরস্কারভিত্তিক পদ্ধতির সঙ্গে তুলনা করে। এটি কোম্পানির গবেষণা-লক্ষ্য সম্পর্কে নিজস্ব বিবরণ। একে সম্পূর্ণ প্রশিক্ষণ-পদ্ধতির স্বাধীন যাচাই ভাবা উচিত নয়। [TypeSafe-এর AI primer](https://docs.typesafe.ai/introduction/machine-learning-primer)

পদ্ধতিটি মূল্যায়নের মধ্যেও বৃহত্তর প্রশ্নটি অনুসন্ধানের যোগ্য: প্রশিক্ষণের লক্ষ্য কোন আচরণকে পুরস্কৃত করে? প্রভাবশালী ব্যাখ্যা তৈরিতে অনুকূলিত মডেল ব্যবহার করতে স্বচ্ছন্দ হলেও এমনভাবে অনিশ্চয়তা প্রকাশ নাও করতে পারে, যা code কাজে লাগাতে পারে। সিদ্ধান্তভিত্তিক interface অনিশ্চয়তা সামলানো সহজ করতে পারে, তবে output-এর বাস্তবতার সঙ্গে মিল বাইরেরভাবে যাচাই করতেই হবে।

TypeSafe এ উদ্বেগকে mode dropping-এর সঙ্গে যুক্ত করে: preference optimization মানুষের পুরস্কৃত উত্তরের দিকে সম্ভাব্য output-এর পরিসর সংকুচিত করতে পারে। এটি ব্যর্থতার ধরন নিয়ে TypeSafe-এর ব্যাখ্যা; preference-trained প্রতিটি মডেল সিদ্ধান্তের কাজে অযোগ্য—এমন অনুসন্ধান নয়। [preference optimization নিয়ে TypeSafe-এর আলোচনা](https://docs.typesafe.ai/introduction/machine-learning-primer)

Almeida-র পটভূমির কারণে এই যুক্তি বিশেষ আগ্রহের। InstructGPT প্রবন্ধে তিনি সহলেখক ছিলেন; সেখানে মানব প্রতিক্রিয়া ব্যবহার করে ভাষা-মডেলকে নির্দেশ মানতে প্রশিক্ষণের গবেষণা করা হয়। ওই লেখকত্ব যাচাইযোগ্য; প্রতিটি গবেষণাগার কী ভুল করে—এমন ব্যাপক দাবি আলাদা বিষয়। [InstructGPT প্রবন্ধ](https://arxiv.org/abs/2203.02155)

pretraining-এ ব্যয় এবং লক্ষ্যহীন নতুন গবেষণাগার নিয়ে তাঁর আপত্তিও কার্যকর কাজ বেছে নেওয়ার একই যুক্তির অংশ। [সাক্ষাৎকার, ১:৪৯:৩২ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6572s) এবং [২:০৩:১০ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7390s)

ক্রেতার জন্য প্রাসঙ্গিক শিক্ষা হলো, সংজ্ঞায়িত প্রক্রিয়ায় পণ্যটি কী করতে পারে তা জিজ্ঞেস করা। গবেষণার ঐতিহ্য, compute-এ ব্যয় ও স্বতন্ত্র মডেল স্থাপত্য ব্যাখ্যা করতে পারে কোম্পানি কীভাবে পণ্যটি তৈরি করেছে। অন্যের ব্যবসায় সেটি মোতায়েনের অর্থনীতি তারা প্রতিষ্ঠা করতে পারে না।

সাক্ষাৎকারে Almeida-র OpenAI ছাড়া, শুরুর কঠিন গ্রহণ এবং developer-নির্ভর প্রবৃদ্ধিও আলোচিত হয়েছে। [সাক্ষাৎকার, ১:৩১:২৭ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5487s) এবং [১:৫৬:৪৮ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7008s)

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

## নতুন chat window-এর চেয়ে বিদ্যমান সফটওয়্যার বেশি লাভবান হতে পারে

Almeida আরও শক্তিশালী SaaS পণ্য এবং AI-কে পটভূমিতে মিলিয়ে যাওয়ার সম্ভাবনা দেখেন। [সাক্ষাৎকার, ১:১৯:৫৭ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4797s)

এটি অনুসন্ধানের বিশ্বাসযোগ্য দিক, কারণ সফটওয়্যারে আগে থেকেই এমন জায়গা আছে, যেখানে কার্যকর বিচার পরের ধাপ বদলাতে পারে। সময়সূচি অ্যাপ booking-এর আগে অস্পষ্ট অনুরোধ ধরতে পারে। media archive গবেষকের জন্য উপকরণ গুছিয়ে দিতে পারে। service desk সাধারণ হালনাগাদ আর মনোযোগ দরকার এমন অভিযোগ আলাদা করতে পারে। এগুলো সম্ভাব্য নকশা, Jev ব্যবহারের প্রকাশিত ফল নয়।

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

বিদ্যমান সফটওয়্যার ব্যবসার সামনে তবু প্রতিযোগিতা থাকবে। একই বিচার অনেক developer পেতে পারলে একা model call-এ বিশেষত্ব থাকবে কম। আশপাশের পণ্যকে কার্যকর তথ্য-প্রবেশাধিকার, সুচিন্তিত interaction design এবং নির্ভরযোগ্যভাবে কাজ শেষ করার উপায় দিতে হবে।

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

BIG CHANGE-এর শিল্প-পর্যালোচনায় পরিমাপযোগ্য ঘটনাটি হলো সিদ্ধান্ত স্বয়ংক্রিয় করার আরেকটি পদ্ধতি পাওয়া যাচ্ছে। ব্যাপক গ্রহণ, উৎপাদনশীলতার লাভ এবং শ্রমবাজারের প্রভাব—ভিন্ন প্রমাণ দরকার এমন পরবর্তী প্রশ্ন।

## অব্যবহৃত data, বাস্তব-সময়ের সফটওয়্যার ও demo-র সীমা

সাক্ষাৎকারে সংরক্ষিত data, ইন্টার‌্যাকটিভ অ্যাপ্লিকেশন, যাচাই এবং computer-use demo নিয়ে আলোচনা হয়েছে। [সাক্ষাৎকার, ১:৩৪:৫০ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5690s)

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

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

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

এসব পার্থক্য category error ঠেকায়: একটি কার্যকর উপাদানকে তার নিজের ভূমিকার কৃতিত্ব দিতে হবে, চারপাশের বৃহত্তর অ্যাপ্লিকেশনের সব সক্ষমতার কৃতিত্ব নয়।

সাক্ষাৎকারে fine-tuning, vision এবং অতিরিক্ত model shape-ও সম্ভাবনা হিসেবে এসেছে। [সাক্ষাৎকার, ১:১০:২৭ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4227s) এবং [১:২৬:২৩ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5183s)

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

## coding agent-রা কাজ ভাগ করতে পারে ভিন্নভাবে

Almeida একক মডেলের loop-এর বাইরে coding agent-এর জন্য কম খরচে state ব্যবস্থাপনা ও অভিন্ন context প্রস্তাব করেন। [সাক্ষাৎকার, ১:৪০:১৭ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6017s) এবং [২:০৯:২৯ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7769s)

এক সম্ভাব্য স্থাপত্যে সক্ষম coding model পরিবর্তন তৈরি করবে, ছোট সিদ্ধান্ত-সংক্রান্ত call প্রাসঙ্গিক file শ্রেণিবদ্ধ করবে এবং সাধারণ software পরের কাজগুলো সামলাবে। আলাদা reviewer চূড়ান্ত patch পরীক্ষা করতে পারে। এটি নকশা-প্রস্তাব; benchmark-এ যাচাই করা সুপারিশ বা Jev ইতিমধ্যে কোনো বিদ্যমান coding agent-এর বিকল্প—তার প্রমাণ নয়।

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

বিপদ হলো সমন্বয়ের প্রস্তাবকে একসঙ্গে কাজ করার নিশ্চয়তা ভেবে নেওয়া। দুটি agent-ই ভাবতে পারে, তাদের একই file লিখতে হবে। পরস্পরবিরোধী write ঠেকানোর software mechanism-এর জায়গায় সম্ভাবনাভিত্তিক মডেল বসানো উচিত নয়। অনুমতি, version check ও lock-কেই ফল নিশ্চিত করতে হবে।

একইভাবে, আগের কাজ সস্তায় খুঁজে পাওয়া memory ব্যবস্থাপনা উন্নত করতে পারে, কিন্তু continuous learning নামে পরিচিত প্রতিটি সমস্যার সমাধান করে না। আগের চেষ্টা মনে রাখা, কেন ব্যর্থ হয়েছিল বোঝা এবং নতুন পরিস্থিতিতে নির্ভরযোগ্যভাবে মানিয়ে নেওয়া—আলাদা সক্ষমতা। বিশ্বাসযোগ্য মূল্যায়নে agent বা call গোনার বদলে সম্পন্ন কাজ, regression, সংঘাত এবং মানুষের হস্তক্ষেপ পরীক্ষা করা উচিত।

## নিরাপত্তা পুরো ব্যবস্থায় কাজ করে; অদৃশ্য হয় না

Almeida মডেলের refusal-এর বদলে application-স্তরের নিরাপত্তা-নিয়ন্ত্রণের পক্ষে বলেন; swyx তার পরিণতি নিয়ে প্রশ্ন তোলেন। [সাক্ষাৎকার, ১৩:১১ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=791s) এবং [১:৪২:২৯ মিনিটে](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6149s)

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

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

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

## কী প্রমাণ করবে বড় পরিবর্তন

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

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

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

Jev-এর চালু ও Almeida-র সাক্ষাৎকার AI কীভাবে অর্থনীতিতে প্রবেশ করে, তার উচ্চাভিলাষী একটি অনুমান সামনে আনে: বারবার করা সীমাবদ্ধ সিদ্ধান্তে মানুষ যে সফটওয়্যারের ওপর আগে থেকেই নির্ভর করে, তা আরও সক্ষম হতে পারে। পরের প্রমাণ আসা উচিত—ভুল ও ব্যতিক্রমের হিসাবসহ—সময়ের সঙ্গে এই কাজ করা ব্যবস্থা থেকে। তখনই আকর্ষণীয় model architecture এমন পরিবর্তনে রূপ নেবে, যা পাঠকেরা সত্যিই দেখতে পাবেন।

## Sources

- [Latent Space-এর মূল সাক্ষাৎকার](https://www.youtube.com/watch?v=cFx9Z3ZXca0) — Diogo Almeida-র Latent Space-সাক্ষাৎকার, প্রকাশিত ২১ সেপ্টেম্বর, ২০২৬। এই বিশ্লেষণে সময়চিহ্নসহ লিংক রয়েছে।
- [System One Models ও Jev-এর পরিচিতি](https://typesafe.ai/blog/introducing-system-one-models-and-jev) — ১৫ সেপ্টেম্বর, ২০২৬। TypeSafe-এর Jev প্রাথমিক প্রবেশাধিকারের ঘোষণা; performance দাবি ও মূল্যায়নের সীমাসহ।
- [ভূমিকা](https://docs.typesafe.ai/introduction) — মডেলের input state এবং Choice, Score ও Noul প্রশ্ন ব্যাখ্যা করা TypeSafe-এর নথি।
- [Confidence](https://docs.typesafe.ai/confidence) — confidence ও probability-র পার্থক্য এবং অ্যাপ্লিকেশন threshold কীভাবে ব্যবহার করতে পারে—সে বিষয়ে TypeSafe-এর নথি।
- [AI primer](https://docs.typesafe.ai/introduction/machine-learning-primer) — প্রশিক্ষণ-লক্ষ্য এবং পূর্বাভাসের বিভিন্ন গোষ্ঠীতে calibration-এর অর্থ সম্পর্কে TypeSafe-এর ব্যাখ্যা।
- [Patterns](https://docs.typesafe.ai/patterns) — মডেলের সিদ্ধান্তকে application logic-এর সঙ্গে মিলিয়ে নেওয়ার TypeSafe-এর উদাহরণ।
- [API-তে Structured Outputs পরিচিতি](https://openai.com/index/introducing-structured-outputs-in-the-api/) — ৬ আগস্ট, ২০২৪। schema-নিয়ন্ত্রিত output ও তার সীমা নিয়ে OpenAI-এর ঘোষণা।
- [আধুনিক neural network-এর calibration নিয়ে গবেষণা](https://arxiv.org/abs/1706.04599) — neural network-এর calibration নিয়ে Chuan Guo ও সহলেখকদের ২০১৭ সালের গবেষণা। এই প্রবন্ধে Jev মূল্যায়িত হয়নি।
- [মানব প্রতিক্রিয়া দিয়ে ভাষা-মডেলকে নির্দেশ মানতে প্রশিক্ষণ](https://arxiv.org/abs/2203.02155) — মানব প্রতিক্রিয়া ব্যবহার করে নির্দেশ মানার বিষয়ে Diogo Almeida-সহলেখিত ২০২২ সালের InstructGPT গবেষণা।