Jev বনাম একটি ভাষা মডেল

একই সিদ্ধান্ত, দুই ভাবে লেখা

একটি সহায়তার টিকিটকে চারটি সারির একটিতে পাঠান। কোডে প্রতিটি পক্ষ আসলে আপনার কত খরচ করায়, তা এখানে।

const res = await llm.chat({
  messages: [{ role: "user", content:
    `Route this ticket. Reply with JSON: {"queue": "Billing"|"Technical"|"Account"|"Sales"}
     Ticket: ${ticket}` }],
  response_format: { type: "json_object" }
});

let queue;
try {
  queue = JSON.parse(res.content).queue;        // may not be JSON
} catch {
  return retry();                               // ...so there is a retry
}
if (!QUEUES.includes(queue)) return retry();    // may be a queue you never had
// and no idea how close the call was

const { answers } = await jev.systemOne({
  state: ticket,
  model: "jev-latest",
  questions: { queue: { type: "choice", instructions:
    "Which team should own this ticket?", criteria: QUEUES } }
});

const { choice, probabilities, confidence } = answers.queue;
// choice is one of QUEUES. It cannot be anything else.
if (confidence < 0.7) return humanReview(ticket, probabilities);
route(choice);

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

দ্বিতীয় সংস্করণটি কী দেখতে পায়

সেই টিকিটটিই, সত্যিকারভাবে Jev দিয়ে চালানো। বিজয়ী অবাক করে না; দ্বিতীয় স্থানেরটিই সেই অংশ যা শুকনো লেবেল ফেলে দিত।

কারিগরি ৮৭%-এ জিতছে, কিন্তু অ্যাকাউন্ট ১৩% ধরে রেখেছে — আর এটাই সঠিক মতভেদ, কারণ SSO-র বিকল দুটোর সীমানাতেই বসে। শুকনো একটি লেবেল এটি লুকিয়ে ফেলত। আপনার রাউটিং ভুল হলে যদি খরচ থাকে, তবে ১৩%-ই সেই সংখ্যা যার উপর সীমা বসাতে হবে।

পাশাপাশি

আপনি কী পাঠান

Jev

একটি অবস্থা আর টাইপযুক্ত প্রশ্নের একটি মানচিত্র।

ভাষা মডেল

একটি প্রম্পট, যা সাধারণত স্কিমা আর নিয়মগুলো গদ্য হিসেবে বয়ে নেয়।

কী ফিরে আসে

Jev

প্রতিটি প্রশ্নের জন্য একটি টাইপযুক্ত উত্তর, প্রতিটি বিকল্পের সম্ভাব্যতাসহ।

ভাষা মডেল

লেখা। JSON, যদি ভদ্রভাবে চেয়ে থাকেন আর সেই মোড সমর্থিত হয়।

আপনার কোডের পরের লাইন

Jev

এমন একটি মানের উপর শাখা, যা কেবল আপনারই মানগুলোর একটি হতে পারে।

ভাষা মডেল

প্রথমে বিশ্লেষণ, তারপর যাচাই, তারপর একটি শাখা যখন এদের কোনোটি ব্যর্থ হয়।

এটি কীভাবে ব্যর্থ হয়

Jev

এটি আপনার লেখা নিয়ে ভুল করতে পারে। আপনি যে আকার ঠিক করেননি তা ফেরত দিতে পারে না।

ভাষা মডেল

এটি আকার নিয়েও ভুল করতে পারে — একটি ঘর অনুপস্থিত, এমন লেবেল যা আপনি কখনো তালিকায় রাখেননি, JSON-এর চারপাশে জড়ানো গদ্য।

দশটি জিনিস জিজ্ঞেস করা

Jev

একটি অনুরোধে দশটি প্রশ্ন, অবস্থার বিপরীতে সমান্তরালে যাচাই করা।

ভাষা মডেল

একটি ঠাসা প্রম্পট, নয়তো দশটি কল।

অনিশ্চয়তা

Jev

প্রতিটি Choice আর Score-এ একটি বণ্টন আর একটি আস্থার মান।

ভাষা মডেল

লেখাটি নিজের নিশ্চয়তা নিয়ে যা-ই দাবি করুক।

সংখ্যাগুলো

এগুলো TypeSafe প্রকাশ করে; এগুলো নির্মাতার নিজের হিসাব, আমাদের মাপা নয়।

আমরা যা মাপতে পারি: এই সাইট দিয়ে করা ১৪টি রানে যাওয়া-আসার মধ্যমা সময় ৩২৯ ms — আর সেসব অনুরোধের বেশির ভাগই একটি নয়, নয়টি প্রশ্ন বয়ে নিয়েছিল।

কখন ভাষা মডেলই সঠিক হাতিয়ার

বেশির ভাগ সময়েই, যদি আপনার দরকার হয় ভাষা। Jev-এর এমন কোনো মত নেই যা সে ব্যাখ্যা করতে পারে, আর বলারও কিছু নেই।

• আপনার গদ্য দরকার — একটি উত্তর, একটি সারসংক্ষেপ, একটি কমিট বার্তা, সিদ্ধান্তের বদলে সিদ্ধান্তের ব্যাখ্যা।
• আপনার কোড লেখানো দরকার, বা একটি পরিকল্পনা, বা এমন যেকোনো উন্মুক্ত কিছু যেখানে উত্তরের সেট কল করার আগে জানা নেই।
• সম্ভাব্য উত্তরের সেট সত্যিই সীমাহীন। কোনো যথেচ্ছ নাম বের করা ২৫৫টি বিকল্পের উপর Choice নয়।
• আপনার এমন যুক্তির শৃঙ্খল দরকার যা আপনি খতিয়ে দেখতে পারেন। Jev একটি রায় ফেরত দেয়, তার পেছনের ধাপগুলো নয়।
• পরিমাণ কম আর আকার আলগা। দিনে দুবার চালানো পুনঃচেষ্টার লুপ নকশা করে সরানোর মতো যথেষ্ট নয়।

এই দুটি প্রতিদ্বন্দ্বিতার চেয়ে মিলেমিশে ভালো কাজ করে। TypeSafe-এর নিজের কাঠামোই হলো দ্রুত সুসংগঠিত বিচারের জন্য System One আর তার পেছনে System Two হিসেবে একটি সাধারণ মডেল — ইনপুট ছাঁকুন Noul দিয়ে, রাউট করুন Choice দিয়ে, আর যা টিকে যায় তা তুলে দিন সেই মডেলের হাতে যে সত্যিই লিখতে পারে।

পড়তে থাকুন