SafeQL ৮৭.৪% SQL error সারিয়েছে—বাস্তব database এখনো বড় পরীক্ষা
KAIST ৪ সেপ্টেম্বর ২০২৬-এ SafeQL-এর ফল ঘোষণা করেছে। KAIST-এর আনুষ্ঠানিক ঘোষণায় বলা হয়েছে, Min-Soo Kim-এর নেতৃত্বাধীন School of Computing দলটির পদ্ধতি BIRD benchmark-এর একটি পরীক্ষায় AI-তৈরি প্রাথমিক SQL-এর execution error সর্বোচ্চ ৮৭.৪% সমাধান করেছে।
এই ৪ সেপ্টেম্বরের ঘোষণার কেন্দ্রে থাকা SafeQL ব্যর্থ SQL পুরোটা আবার তৈরি না করে DBMS-এর feedback কাজে লাগিয়ে ত্রুটিযুক্ত অংশটি ধাপে ধাপে বদলায়। তবে ৮৭.৪% হলো নির্দিষ্ট BIRD configuration-এ প্রাথমিক execution error কমার সর্বোচ্চ হার—সব প্রশ্নের সঠিক উত্তর পাওয়ার হার বা বাস্তব enterprise database-এ নিশ্চিত সাফল্যের হার নয়।
SafeQL পুরো query না লিখে যে অংশটি বদলায়
প্রচলিত regeneration পদ্ধতিতে একটি SQL ব্যর্থ হলে query, error message ও schema context আবার LLM-এ পাঠানো হয়। মডেল সম্পূর্ণ নতুন SQL তৈরি করায় আগে সঠিক থাকা clause-ও বদলে যেতে পারে; প্রতিটি নতুন generation-এর সঙ্গে token ব্যবহার ও model latency-ও যোগ হয়।
Geonho Lee ও Min-Soo Kim-এর SafeQL গবেষণাপত্রে পদ্ধতিটিকে DBMS-guided search হিসেবে সংজ্ঞায়িত করা হয়েছে। SafeQL unknown relation, unknown attribute, unsupported function বা operator এবং empty result-এর মতো অবস্থার জন্য সম্ভাব্য সংশোধন তৈরি করে; তারপর database-এ candidate চালিয়ে executable query-র দিকে এগোয়।
এই অনুসন্ধানের ক্ষেত্রটির নাম Safe Query Space। মূল query-র গঠন ও অর্থের কাছাকাছি candidate আগে পরীক্ষা করা হয়, type mismatch থাকা বিকল্প type-based pruning-এ বাদ পড়ে এবং embedding similarity অনুসারে top-K candidate রাখা হয়। বাস্তবায়নটি PostgreSQL-এর RawStmt কাঠামোর ওপর তৈরি extension, ফলে SQL-কে সাধারণ text হিসেবে নয়, abstract syntax tree ধরে সংশোধন করা যায়।
Search দিয়ে সমাধান না হলে hybrid mode LLM-কে নতুন SQL তৈরির জন্য আবার ডাকে এবং সেখান থেকে refinement চালায়। অর্থাৎ SafeQL full regeneration বাদ দেয়নি; শনাক্তযোগ্য error-এ local repair আগে ব্যবহার করে regeneration-কে fallback হিসেবে রেখেছে।
Selective repair ও regeneration-এর ফল এক মাপকাঠি নয়
প্রকাশিত সংখ্যাগুলো বোঝার জন্য error resolution, execution accuracy, token এবং সময়কে আলাদা রাখতে হবে। BIRD full development set-এ SafeQL hybrid ও OpenSearch-SQL configuration-এর execution accuracy ছিল ৬৯.৪%; refinement না থাকা একই agent-based baseline-এর accuracy ছিল ৬৪.২%, অর্থাৎ বৃদ্ধি ৫.২ percentage point। ওই configuration-এই প্রাথমিক execution error ৮৭.৪% কমেছে।
- সংশোধনের পরিসর: regeneration পুরো SQL প্রতিস্থাপন করে; SafeQL search প্রথমে ব্যর্থ relation, attribute, join, function বা value-সংশ্লিষ্ট অংশ বদলায়।
- Token ব্যবহার: BIRD-এ SafeQL hybrid পরীক্ষিত regeneration পদ্ধতিগুলোর তুলনায় ১.৮ থেকে ১৫.১ গুণ কম token নিয়েছে। Search-only mode নতুন SQL generation না করায় অতিরিক্ত LLM token ব্যবহার করেনি।
- Correction time: একই তুলনায় refinement latency ১.৯ থেকে ২৯.৬ গুণ কম ছিল। এগুলো configuration-ভিত্তিক পরিসর, প্রতিটি query-র জন্য নিশ্চিত গতি নয়।
- Execution accuracy: BIRD-এ prompt-based DAIL-SQL configuration-এ SafeQL hybrid ৬৩.৩% accuracy পেয়েছে, যা refinement-বিহীন baseline-এর চেয়ে ৫.৮ percentage point বেশি। এই মাপকাঠি ৮৭.৪% error-resolution rate থেকে আলাদা।
- Fallback: search-only repair যথেষ্ট না হলে hybrid mode আবার LLM regeneration ব্যবহার করে; তাই fallback হওয়া query-র token ও latency সুবিধা আলাদা হতে পারে।
Aju Press-এর ৪ সেপ্টেম্বরের প্রতিবেদনে Spider পরীক্ষায় SafeQL hybrid-এর ৯১.৭% execution accuracy, regeneration পদ্ধতির তুলনায় সর্বোচ্চ ৯৬.৫ গুণ কম token এবং সর্বোচ্চ ৩৪.৫ গুণ কম repair time-এর তথ্যও রয়েছে। BIRD ও Spider-এর সংখ্যা ভিন্ন benchmark, baseline এবং configuration-এর ফল; সেগুলোকে একটি অভিন্ন production performance দাবি হিসেবে মেলানো যাবে না।
৮৭.৪% error resolution সঠিক উত্তরের হার নয়
Error-resolution rate শুধু প্রথমে execution error হওয়া query-র কত অংশ refinement-এর পরে আর সেই অবস্থায় নেই, তা মাপে। Execution accuracy দেখে final SQL প্রত্যাশিত result ফিরিয়েছে কি না। কোনো query সফলভাবে চলেও ভুল table, join বা filter বেছে নিয়ে অর্থগতভাবে ভুল উত্তর দিতে পারে।
গবেষণাটি empty result-কেও refinement-এর আওতায় রেখেছে, তবে লেখকেরা স্পষ্ট করেছেন যে বাস্তবে শূন্য ফল সব সময় ভুল query বোঝায় না। কোনো সময়সীমায় লেনদেন না থাকলে empty result-ই সঠিক business answer হতে পারে; এমন অবস্থায় predicate বদলে non-empty result তৈরি করা বরং অর্থগত ভুল ঘটাতে পারে। SafeQL-এ error type অনুযায়ী refinement নিয়ন্ত্রণের ব্যবস্থা আছে, কিন্তু production policy-তে কোন empty result সংশোধনযোগ্য তা সংশ্লিষ্ট domain-এর নিয়মেই স্থির করতে হবে।
BIRD-এর পরীক্ষায় ১,৫৩৪টি query-র full development set এবং ৫০০টি query-র mini development set PostgreSQL-এ স্থানান্তর করে ব্যবহার করা হয়েছে; Spider-ও PostgreSQL-এ migrate করা হয়। এই নকশা একই নিয়মে পদ্ধতিগুলো তুলতে সাহায্য করে, কিন্তু কোনো প্রতিষ্ঠানের নিজস্ব schema, SQL dialect, permission model বা business vocabulary-তে একই ফল প্রমাণ করে না।
Enterprise pilot-এ চার স্তরের যাচাই দরকার
Production সিদ্ধান্তের আগে benchmark score পুনরাবৃত্তি করাই যথেষ্ট নয়। Pilot-এ SafeQL যে database ও access boundary-তে চলবে, সেখানকার failure condition ধরে অন্তত চার স্তরের acceptance test আলাদা রাখা দরকার:
- Schema drift: table বা column rename, নতুন relation এবং migration-এর পরে candidate search বর্তমান schema ব্যবহার করছে কি না; পুরোনো metadata থেকে executable কিন্তু ভুল query হচ্ছে কি না।
- Access control: candidate তৈরি, validation execution এবং LLM fallback—তিন পর্যায়েই ব্যবহারকারীর database role ও row-level restriction অক্ষুণ্ণ আছে কি না। Search space-এ কোনো object পাওয়া যাওয়া সেটিতে ব্যবহারকারীর প্রবেশাধিকার থাকার সমান নয়।
- Sensitive data boundary: schema name, database value, error text বা query fragment কোনো বাহ্যিক model endpoint-এ যাচ্ছে কি না; গেলে masking, retention ও outbound-data policy কীভাবে কার্যকর হচ্ছে।
- Audit ও semantic validation: initial SQL, DBMS error, candidate পরিবর্তন, final query, result এবং fallback invocation পুনর্গঠনযোগ্যভাবে log হচ্ছে কি না। শুধু execution success নয়, পরিচিত প্রশ্নের result set, aggregate, join cardinality ও authorization outcome-ও মিলতে হবে।
Fallback-এর সীমাও pilot-এর অংশ: search কত ধাপ পরে থামবে, কখন regeneration চালু হবে এবং repeated failure-এ system query বন্ধ করবে নাকি অসম্পূর্ণ ফল ফেরাবে—এসব আচরণ আগে নির্দিষ্ট না করলে গড় token বা latency প্রকৃত ঝুঁকি দেখাবে না। রিপোর্টে execution accuracy, unresolved failure, end-to-end latency এবং LLM token আলাদা metric হিসেবে রাখা উচিত।
এখন প্রমাণিত সীমা benchmark পর্যন্ত
SafeQL বর্তমানে প্রকাশিত ও VLDB 2026-এ অন্তর্ভুক্ত একটি PostgreSQL extension-ভিত্তিক গবেষণা prototype। BIRD ও Spider-এ selective repair, hybrid fallback এবং full regeneration-এর তুলনামূলক ফল রয়েছে; কিন্তু বহু প্রতিষ্ঠানের live database, দীর্ঘমেয়াদি schema change, বাস্তব permission hierarchy বা sensitive-data boundary-তে সমমানের ফলের প্রমাণ প্রকাশিত হয়নি।
তাই শিরোনামের ৮৭.৪% একটি শক্তিশালী benchmark ফল হলেও পরবর্তী বড় পরীক্ষা production environment। সেখানে মূল প্রশ্ন হবে শুধু SQL চলেছে কি না নয়—উত্তরটি সঠিক, অনুমোদিত ও audit করা সম্ভব কি না, আর repair ব্যর্থ হলে system নিরাপদভাবে থামে কি না।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।