Structured Outputs স্কিমা মানায়—ভুল তথ্য তবু পেরিয়ে যেতে পারে

OpenAI ও Gemini API থেকে নির্ভরযোগ্য কাঠামোবদ্ধ জেসন নিতে তিনটি পরীক্ষা আলাদা করুন: উত্তরটি বৈধ জেসন কি না, নির্ধারিত স্কিমা মানে কি না এবং তার মানগুলো উৎসতথ্যের সঙ্গে মেলে কি না। OpenAI-এর Structured Outputs নির্দেশিকা অনুযায়ী JSON mode বৈধ জেসন দেওয়ার জন্য, Structured Outputs নির্দিষ্ট স্কিমা মানানোর জন্য; স্কিমা-সঠিক উত্তরেও ভুল থাকতে পারে।

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

তিনটি পরীক্ষা আলাদা ফল দেয়

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

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

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

স্কিমা লিখুন, কিন্তু তার সীমাও জানুন

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

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

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

একটি শর্তাধীন উদাহরণে চার ধরনের ভুল

ধরা যাক, একটি বিক্রির ইনপুটে তারিখ ২৮ ফেব্রুয়ারি ২০২৬, দুটি পণ্যের দাম ৭০০ ও ৩০০ টাকা এবং অনুমোদিত গ্রাহক পরিচিতি ‘সি-১৭’। আউটপুটে তারিখ ‘২০২৬-০২-৩০’, মোট ১১০০ টাকা ও পরিচিতি ‘সি-৯৯’ এসেছে। স্কিমায় তারিখ ও পরিচিতি শুধু স্ট্রিং এবং মোট শুধু সংখ্যা হিসেবে নির্ধারিত থাকলে প্রয়োজনীয় সব ক্ষেত্র উপস্থিত থাকা সত্ত্বেও এই মানগুলো কাঠামোগত পরীক্ষায় পাস করতে পারে।

এখানে ৩০ ফেব্রুয়ারি বাস্তব দিন নয়; দেওয়া দামগুলোর যোগফল ১০০০ টাকা, ১১০০ নয়; আর ‘সি-৯৯’ অনুমোদিত পরিচিতি নয়। পরিচিতির গঠন ঠিক থাকলেই সেটি সঠিক গ্রাহকের হয় না। একই উদাহরণে অবস্থা ‘পরিশোধিত’ এলেও লেনদেনের তথ্য না থাকলে ক্ষেত্র দুটির সম্পর্ক যাচাই করে ফল আটকাতে হবে। পরীক্ষাগুলো এভাবে ভাগ করলে কোন ভুলটি স্কিমায় ধরা সম্ভব এবং কোনটির জন্য উৎস বা রেকর্ড প্রয়োজন, তা পরিষ্কার থাকে।

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

ব্যর্থ উত্তর সামলানোর ছোট কর্মপ্রবাহ

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

1. উত্তর অসম্পূর্ণ বা জেসনের বিন্যাস ভাঙা হলে ব্যর্থতার কারণসহ সীমিতবার নতুন উত্তর চান। স্কিমা ভাঙলে কোন ক্ষেত্র অনুপস্থিত বা ভুল ধরনের, সেটি জানান। প্রতিবার পাওয়া নতুন উত্তরকে শুরু থেকে সব পরীক্ষার মধ্য দিয়ে চালান।
2. স্কিমা মেনেও মান ভুল হলে প্রাসঙ্গিক উৎসতথ্য ও নির্দিষ্ট অসংগতি জানান। এই উদাহরণে দুটি উৎসদাম ও পাওয়া মোট উল্লেখ করা যায়। সংশোধিত উত্তরকে নতুন প্রার্থী হিসেবে যাচাই করুন; মডেলের ‘সংশোধন করেছি’ বক্তব্যকে যাচাইয়ের বিকল্প করবেন না।
3. উৎসে প্রয়োজনীয় মানই না থাকলে, পরিচিতি অনুমোদিত না হলে বা সীমিত পুনরায় অনুরোধেও ভুল থাকলে ফল প্রত্যাখ্যান করুন। কাজের ঝুঁকি অনুযায়ী সেটিকে মানব পর্যালোচনায় পাঠান অথবা পরবর্তী কাজ বন্ধ রাখুন। অনুমান করা মান দিয়ে রেকর্ড স্থায়ী করবেন না।

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

আরও পড়ুন:

• YouTube Studio 24.31.6-এর সমর্থন শেষ—আপডেট না করলে কাজ আটকে যেতে পারে
• Google passkey চালু করুন—shared device-এ এক ভুলেই account খুলে যেতে পারে
• Composition GST সস্তা দেখায়—ITC হারালেই Regular জিতে যেতে পারে