Text-to-SQL-এ "রেকর্ড"-এর বিপদ
প্রতি মাসে নতুন দাবি আসে যে очередная LLM প্রায় মানুষের সমান হয়ে গেছে SQL-বেঞ্চমার্কে। কিন্তু ভালো করে দেখলে, এই সংখ্যাগুলোর পেছনে খুব আলাদা শর্ত লুকিয়ে থাকে: কেউ ডেটাবেসে অ্যাক্সেস ছাড়া সহজ প্রম্পট ব্যবহার করে, কেউ মডেলকে পুনরাবৃত্তি করে কোয়েরি চালানোর অনুমতি দেয়, আর কেউ যুক্তি সরাসরি মডেলের ওজনের মধ্যে বানিয়ে ফেলেছে। এমন ফলাফল সরাসরি তুলনা করা — যেন একজন মেকানিকসহ গাড়িকে আর একটি ড্রোনের সাথে পাশাপাশি রাখা, যা চলার সময় নিজেই নিজেকে মেরামত করে।
arXiv-এ (2608.15389) প্রকাশিত সাম্প্রতিক প্রিপ্রিন্টের লেখকরা ঠিক এই সমস্যার দিকেই নজর দিয়েছেন। তারা প্রস্তাব করেন যে, আর লিডারবোর্ডের বিমূর্ত উচ্চতায় "অগ্রগতি" মাপা যাবে না, বরং প্রথমে সৎভাবে নির্ধারণ করতে হবে যে SQL তৈরির সময় সিস্টেমটির কতটা স্বায়ত্তশাসন ছিল। এই শর্ত ছাড়া, বিভিন্ন কাজের মধ্যে যেকোনো তুলনাই অস্থির হয়ে পড়ে: বেঞ্চমার্ক, বেস মডেল বা এমনকি ইনফারেন্স প্রোটোকলের সামান্য পরিবর্তনও সিদ্ধান্ত বদলে দিতে পারে।
স্বায়ত্তশাসনের অক্ষ: প্রম্পট থেকে স্বয়ংসম্পূর্ণ এজেন্ট পর্যন্ত
গবেষকরা সব সংখ্যা এক টেবিলে জড়ো করার বদলে Text-to-SQL ক্ষেত্রটিকেই "লিডারবোর্ড অ্যাগ্রিগেশন" হিসেবে নতুন করে সংজ্ঞায়িত করেন। তারা সিস্টেম লেখকদের নিজেদের রিপোর্ট করা মেট্রিকগুলো সংগ্রহ করেন এবং সেগুলোকে ইনফারেন্সের স্বায়ত্তশাসনের অক্ষ বরাবর সাজান। ফলাফল পাঁচটি স্তর:
- Constrained generation — মডেল শুধুমাত্র কঠোরভাবে সীমাবদ্ধ অনুমোদিত কোয়েরির জায়গা থেকে উত্তর বেছে নেয়, প্রায়ই বাহ্যিক সিনট্যাক্স যাচাইসহ।
- In-context generation — SQL উদাহরণ এবং স্কিমা বর্ণনাসহ কনটেক্সটের উপর এক পাসে তৈরি হয়।
- Iterative generation — সিস্টেম একাধিক চেষ্টা করতে পারে, এক্সিকিউশনের ফলাফল বা ডেটাবেসের উত্তর অনুযায়ী কোয়েরি সংশোধন করে।
- Agentic generation — মডেল এজেন্টের মতো কাজ করে: নিজে ডেটাবেস স্কিমা অন্বেষণ করে, কোয়েরি চালায়, ত্রুটিতে সাড়া দেয় এবং পরবর্তী পদক্ষেপ পরিকল্পনা করে।
- Reasoning-internalized generation — "যুক্তি" আগে থেকেই মডেলে তৈরি থাকে, তাই ইনফারেন্সে এটি সরাসরি কোয়েরি দেয়, বাহ্যিক অর্কেস্ট্রেশন বা মধ্যবর্তী ধাপ ছাড়াই।
এই ধরনের স্কেল বলে না যে একটি স্তর অন্যটির চেয়ে "ভালো"। এটি শুধু সৎ তুলনার শর্ত নির্ধারণ করে: অভ্যন্তরীণ reasoning-সহ সিস্টেমকে খালি single-shot আউটপুটের সাথে সমানভাবে তুলনা করা যায় না, যেমন এজেন্টিক কনট্যুর যাকে কোয়েরি চালানোর অধিকার দেওয়া হয়েছে, তাকে সেই মডেলের সাথে তুলনা করা উচিত নয় যাকে এই অধিকার দেওয়া হয়নি।
গুরুত্বপূর্ণ বিষয় হল, এই ধরনের লিডারবোর্ডের প্রতিটি ঘরের জন্য মেট্রিকের উৎস খুঁজে পাওয়া যায়। এর অর্থ হল, পাঠক সবসময় বুঝতে পারেন কোন কনফিগারেশন ফলাফল দিয়েছে, পরীক্ষামূলক অংশের টুকরো থেকে অনুমান করার চেষ্টা না করে।
Spider এবং এর বাইরে পরীক্ষায় কী দেখা গেল
মেট্রিক অ্যাগ্রিগেশনকে বাস্তবতার সাথে যুক্ত করতে, লেখকরা Spider বেঞ্চমার্কে একটি লক্ষ্যবস্তু গবেষণা চালান। তারা ওপেন 8B-মডেল — CoT-সুপারভিশনসহ এবং ছাড়া — DeepSeek V3 এবং GLM-4-এর উপর ভিত্তি করে few-shot বেসলাইনগুলির সাথে তুলনা করেন। মজার বিষয় হল, সম্পূর্ণ ফাইন-টিউনড সংস্করণ নয়, বরং few-shot প্রোটোকল ব্যবহার করা হয়েছিল, তাই তুলনাটি বেশ পরিষ্কার ছিল।
পরীক্ষা থেকে অনুশীলনকারীদের জন্য গুরুত্বপূর্ণ চারটি প্যাটার্ন উঠে আসে।
প্রথমত, Spider-এ পাওয়া উন্নতিগুলো BIRD এবং Spider 2.0-এ অসমভাবে স্থানান্তরিত হয়। একটি মডেল এক সেট কোয়েরিতে সুন্দর বৃদ্ধি দেখাতে পারে এবং অন্যটিতে প্রায় নড়াচড়া নাও করতে পারে। এটি আবারও নিশ্চিত করে: একটি জনপ্রিয় বেঞ্চমার্কে একক স্কোরের অন্ধ তাড়া সাধারণ অগ্রগতির বিভ্রম তৈরি করে।
দ্বিতীয়ত, স্বায়ত্তশাসন স্থিতিশীলতা যোগ করে, কিন্তু অ-তুচ্ছ মূল্যে। এজেন্টিক কনট্যুর действительно বহু-পদক্ষেপ এবং অস্পষ্ট কাজে ভালো করে, তবে টোকেন এবং এক্সিকিউশন সময়ের খরচ উল্লেখযোগ্যভাবে বেড়ে যায়। ইন্টারঅ্যাকটিভ অ্যানালিস্টের জন্য এই মূল্য যুক্তিযুক্ত হলেও, ব্যাচ প্রসেসিংয়ের জন্য এটি বিরল ত্রুটির পুরো লাভ গ্রাস করতে পারে।
তৃতীয়ত, reasoning internalized মোড অপ্রত্যাশিতভাবে মাঝামাঝি অবস্থান নেয়। এটি যুক্তি ছাড়া "নির্বোধ" উত্তর ডিকোডিং এবং বাহ্যিকভাবে অর্কেস্ট্রেটেড এজেন্টদের মধ্যে থাকে। অনেক কাজের জন্য এই মোড প্রায় এজেন্ট-মানের ফল দেয়, কিন্তু জটিল টুলসহ কনট্যুর তৈরির প্রয়োজন ছাড়াই। যদিও সার্বজনীন "ফ্রি লাঞ্চ" পাওয়া যায় না: অন্তর্নির্মিত যুক্তিরও নিজস্ব সীমাবদ্ধতা রয়েছে।
চতুর্থত, CoT-সুপারভিশনের লাভ Hard এবং Extra-Hard স্তরের কোয়েরিতে কেন্দ্রীভূত হয়। সহজ প্রশ্নে পার্থক্য প্রায় অদৃশ্য বা এমনকি নেতিবাচক — উত্তর যখন সরাসরি দেখা যায় তখন মডেলের জোরে যুক্তি করার দরকার কী? কিন্তু জটিল বহু-পদক্ষেপ কাজে ধাপগুলো জোরে বলার ক্ষমতা উল্লেখযোগ্য সুবিধা দেয়। যারা SQL-অ্যাসিস্ট্যান্ট তৈরি করেন তাদের জন্য এটি গুরুত্বপূর্ণ সংকেত: অতিরিক্ত কম্পিউটেশনাল শক্তি উচ্চ জটিলতার কোয়েরিতে ফোকাস করা উচিত, সাধারণ সহজ ক্ষেত্রে নষ্ট না করা।
এই স্কেলটি অনুশীলনে কীভাবে ব্যবহার করবেন
কাজের সবচেয়ে দরকারী ফলাফল — এমনকি ট্যাক্সোনমি নয়, বরং পাবলিক Python-হার্নেস, যা লেখকরা প্রিপ্রিন্টের সাথে প্রকাশ করেছেন। হার্নেস স্বায়ত্তশাসনের অক্ষ পুনরুত্পাদন করে এবং পুরো পরিবেশ পুনর্লিখন ছাড়াই লিডারবোর্ডে নতুন পদ্ধতি যোগ করতে দেয়। আপনি যদি আরেকটি Text-to-SQL পদ্ধতি তৈরি করেন, তাহলে শুধু বলুন এটি স্বায়ত্তশাসনের কোন স্তরে কাজ করে — এবং সম্প্রদায় আপনাকে আগের সিস্টেমের সাথে সমানভাবে তুলনা করতে পারবে।
এটা স্পষ্ট যে, নিজেরা রিপোর্ট করা মেট্রিকের উপর ভিত্তি করে অ্যাগ্রিগেশন এখনও সতর্কতার সাথে বিশ্বাস করা উচিত। সবার কাছে অন্যের পরীক্ষা পুনরাবৃত্তি করার বাজেট নেই, কিন্তু একটি অভিন্ন অ্যানোটেশন ইতিমধ্যেই বড় অগ্রগতি। আপাতত очередной "state-of-the-art" পড়ার সময় মনে রাখুন একটি সহজ প্রশ্ন: কোয়েরি তৈরির সময় মডেলটি আসলে কী করতে পারত? যদি এই প্রশ্নের উত্তর না থাকে, তাহলে নিবন্ধের সংখ্যাটিও কেবল একটি সুন্দর অঙ্ক, দৃঢ় ভিত্তি ছাড়া।
