AI অ্যাপের জন্য নির্দিষ্ট কাঠামোর আউটপুট কেন প্রয়োজন?
AI অ্যাপে কাঠামোবদ্ধ আউটপুট দরকার, কারণ সফটওয়্যার কথোপকথনের ঢঙে লেখা একটি অনুচ্ছেদ নির্ভরযোগ্যভাবে বুঝতে পারে না; প্রতিবার একই নাম ও একই ধরনের ফিল্ড তার প্রয়োজন। একটি বাড়তি বাক্য বা অনুপস্থিত ফিল্ডও আপনার অ্যাপের পরের ধাপটি অচল করে দিতে পারে।
পার্সেলওয়াইজ নামে 12 জনের একটি কাল্পনিক লজিস্টিকস স্টার্টআপের কথা ভাবুন। এর ডেভেলপার সানা এমন একটি টুল তৈরি করছেন, যা গ্রাহকের ইমেইল পড়ে ডেলিভারি পরিবর্তনের ফর্ম পূরণ করে: অর্ডারের রেফারেন্স, চাওয়া তারিখ, নতুন ঠিকানা এবং গ্রাহক টাকা ফেরত চাইছেন কি না। একটি সাধারণ ইমেইল এমন: 'হ্যালো, অর্ডার PW-88213, বৃহস্পতিবার বাড়িতে থাকব না, তার বদলে শনিবার দিতে পারবেন? অথবা 14 নম্বরে রেখে যাবেন। না পারলে বাতিল করে টাকা ফেরত দিন।' তাঁর প্রথম সংস্করণে মডেলকে বলা হয়, 'JSON-এ উত্তর দাও'। বেশির ভাগ উত্তর পার্স করা যায়, কিন্তু কিছু উত্তর শুরু হয় 'অবশ্যই, এই নিন JSON' দিয়ে, কিছুতে ফিল্ডের নাম 'requested_date' না দিয়ে 'date' দেওয়া হয়, আর একটিতে তারিখ হিসেবে 'শনিবার' ফেরত আসে।
JSON স্কিমা কী এবং এটি কেন কাজে লাগে?
JSON স্কিমা হলো আপনি যে তথ্য আশা করছেন তার একটি আনুষ্ঠানিক বিবরণ: কোন কোন ফিল্ড থাকবে, কোনগুলো আবশ্যক, প্রতিটির ধরন কী এবং কোন মানগুলো গ্রহণযোগ্য। মডেলকে একটি স্কিমা দিলে 'অনুগ্রহ করে JSON-এ উত্তর দিন' কথাটি এমন একটি চুক্তিতে পরিণত হয়, যা আপনার কোড যাচাই করতে পারে।
সানার ক্ষেত্রে স্কিমা বলছে: order_reference একটি আবশ্যিক স্ট্রিং; requested_date তারিখের বিন্যাসে একটি আবশ্যিক স্ট্রিং, অথবা তারিখ দেওয়া না থাকলে null; new_address একটি স্ট্রিং অথবা null; refund_requested একটি আবশ্যিক বুলিয়ান; এবং অন্য কোনো তথ্যক্ষেত্র অনুমোদিত নয়। শেষ নিয়মটি মডেলকে মন্তব্যের জন্য বাড়তি তথ্যক্ষেত্র যোগ করা থেকে আটকায়।
মডেলের API-গুলো কীভাবে নির্দিষ্ট কাঠামোয় ফলাফল দেওয়ার সুবিধা দেয়?
প্রধান মডেলগুলোর API-তে অনুরোধের সঙ্গে একটি JSON স্কিমা পাঠানো যায় এবং মডেলের আউটপুট সেই কাঠামো মেনে চলতে বাধ্য থাকে।
OpenAI
কঠোর মোড চালু থাকলে OpenAI-এর কাঠামোবদ্ধ আউটপুট সুবিধা উত্তরকে সরবরাহ করা JSON স্কিমার মধ্যে সীমাবদ্ধ রাখে। এর নথিতে পুরোনো JSON মোডের সঙ্গে এই পার্থক্যটি তুলে ধরা হয়েছে: পুরোনো মোড শুধু বৈধ JSON নিশ্চিত করে, আপনার স্কিমা মেনে চলা নিশ্চিত করে না। তাই যেখানে পাওয়া যায়, সেখানে কাঠামোবদ্ধ আউটপুট ব্যবহারের পরামর্শ দেওয়া হয়েছে।
Anthropic
Claude-এর API আপনার দেওয়া স্কিমার সঙ্গে মেলে এমন JSON ফলাফল দেয়। পাশাপাশি টুলের সংজ্ঞায় একটি কঠোর বিকল্প রয়েছে, যাতে টুলের ইনপুট তার স্কিমার সঙ্গে মিলিয়ে যাচাই করা হয়। এর নথিপত্রে স্কিমার কোন বৈশিষ্ট্যগুলো সমর্থিত এবং কোনগুলো ব্যবহার করলে ত্রুটি ফেরত আসে, তা তালিকাভুক্ত আছে।
Gemini API উত্তরের জন্য JSON স্কিমা গ্রহণ করে এবং স্কিমার কীওয়ার্ডগুলোর একটি নির্দিষ্ট অংশ সমর্থন করে। এর নথিতে বলা হয়েছে, আউটপুটের JSON গঠনগতভাবে সঠিক হলেও আপনার অ্যাপ্লিকেশনে মানগুলো যাচাই করা উচিত।
তার পরও যাচাই করা ও আবার চেষ্টা করা কেন প্রয়োজন?
আপনাকে তারপরও যাচাই করতে হবে, কারণ স্কিমা তথ্যের গঠন নিয়ন্ত্রণ করে, মানগুলো সঠিক কি না তা নয়। নিখুঁত গঠনের উত্তরেও ভুল তারিখ, বানানো অর্ডার রেফারেন্স বা গ্রাহক কখনো চাননি এমন টাকা ফেরতের নির্দেশক থাকতে পারে।
দুই স্তরে যাচাই করুন। প্রথমে একটি স্কিমা লাইব্রেরি দিয়ে কাঠামো পরীক্ষা করুন, যেমন Python-এ Pydantic বা JavaScript-এ Zod। OpenAI, Anthropic ও Google-এর নথিতে এগুলোর উদাহরণ আছে। দ্বিতীয়ত, ব্যবসায়িক নিয়ম পরীক্ষা করুন: অর্ডারের শনাক্তকারী কি নির্ধারিত ধরন মেনে চলে এবং সিস্টেমে আছে, তারিখটি কি ভবিষ্যতের এবং সরবরাহের নির্ধারিত দিন, আর ঠিকানাটি কি সরবরাহ এলাকার মধ্যে? সেবাদাতাদের নথিতে উল্লেখ করা পরিস্থিতিগুলোও সামলান: উত্তর দিতে অস্বীকৃতি, যা আপনার স্কিমা নাও মানতে পারে, এবং সর্বোচ্চ টোকেন সীমার কারণে কেটে যাওয়া উত্তর, যাতে JSON অসম্পূর্ণ থেকে যায়।
সতর্কভাবে আবার চেষ্টা করুন। কোনো যাচাই ব্যর্থ হলে, নির্দিষ্ট ত্রুটিটি উল্লেখ করে একবার পুনরায় চেষ্টা করতে বলুন, যেমন 'requested_date অবশ্যই একটি তারিখ হতে হবে; ইমেলে শনিবার বলা আছে, আর অর্ডারের তারিখ 14 October'। পুনরায় চেষ্টার সংখ্যা এক বা দুইয়ের মধ্যে সীমিত রাখুন, তারপর ইমেলটি একজন মানুষের কাছে পাঠান।
দুর্বল ও নির্ভরযোগ্য কাঠামোবদ্ধ আউটপুট কেমন হয়?
দুর্বল সংস্করণ: প্রম্পটে বলা আছে 'তথ্যগুলো বের করে JSON-এ উত্তর দাও।' যা ফেরত আসে, অ্যাপ সেটাই পড়ে। উপরের ইমেলের ক্ষেত্রে এটি order ও date নামের ফিল্ড পায়, তারিখের মান পায় 'শনিবার', আর টাকা ফেরতের মান পায় true, কারণ মডেল 'না হলে শুধু বাতিল করে দিন' কথাটিকে নিশ্চিত অনুরোধ হিসেবে ধরেছে। ফর্মে ভুল তথ্য বসে যায় এবং গ্রাহক না চাইলেও টাকা ফেরত পান।
নির্ভরযোগ্য সংস্করণ: অনুরোধে সানার নির্ধারিত তথ্যকাঠামো ও কঠোর মোড অন্তর্ভুক্ত আছে। প্রম্পটে প্রতিটি ক্ষেত্রের ব্যাখ্যা দেওয়া আছে, যার মধ্যে রয়েছে 'গ্রাহক কোনো শর্ত ছাড়াই টাকা ফেরত চাইলে তবেই refund_requested সত্য হবে'। মডেল order_reference হিসেবে PW-88213, requested_date হিসেবে পরবর্তী শনিবারের তারিখ, new_address হিসেবে null এবং refund_requested হিসেবে false ফেরত দেয়। ঠিক এই পরিস্থিতির জন্য সানা তথ্যকাঠামোয় conditional_request নামে যে ক্ষেত্রটি যোগ করেছেন, সেটির মান হয় 'শনিবার বা প্রতিবেশীর কাছে ডেলিভারি সম্ভব না হলে টাকা ফেরত'। যাচাই করে নিশ্চিত হওয়া যায় যে অর্ডারটি আছে এবং শনিবার ডেলিভারি দেওয়া হয়। ইমেলে শর্তসাপেক্ষ অনুরোধ থাকায় নিয়ম অনুযায়ী চূড়ান্ত সিদ্ধান্তের জন্য সেটি একজন মানুষের কাছে পাঠানো হয়।
নির্দিষ্ট কাঠামোয় আউটপুট পাওয়ার ক্ষেত্রে সাধারণ ভুলগুলো কী?
সবচেয়ে সাধারণ ভুল হলো বৈধ JSON-কে সঠিক ডেটা বলে বিশ্বাস করা। অন্য ভুলগুলো হলো: API-তে স্কিমা বাধ্যতামূলক করার সুবিধা থাকা সত্ত্বেও শুধু প্রম্পটের নির্দেশের ওপর নির্ভর করা, বিবরণ ছাড়া অস্পষ্ট ফিল্ডের নাম ব্যবহার করা, সৎ উত্তর null হলেও জোর করে কোনো মান বসানো, উত্তর দিতে অস্বীকৃতি ও অসম্পূর্ণ উত্তর উপেক্ষা করা এবং কী ভুল হয়েছে তা মডেলকে না জানিয়ে আবার চেষ্টা করা।
Tosheo.ai-এর পাঠ্যতালিকায় নির্দিষ্ট কাঠামোয় আউটপুট পাওয়ার বিষয়টি কোথায় রয়েছে?
কাঠামোবদ্ধ আউটপুট হলো AI অ্যাপ তৈরি বিভাগের AI অ্যাপ তৈরির কোর্সের একটি কোড পাঠ। হাতে-কলমে শেখার সম্পূর্ণ সংস্করণটি সাইন-আপের পর কোড ধারায় পাওয়া যাবে। সেখানে আপনি কোড দিয়ে ডেটার কাঠামো নির্ধারণ করবেন, API কল করবেন, উত্তর যাচাই করবেন এবং আবার চেষ্টা করার ব্যবস্থা যোগ করবেন। প্রতিটি ধাপে নির্দিষ্ট মূল্যায়ন-মানদণ্ড অনুযায়ী মতামত পাবেন।