Legal AI-তে benchmark জিতলেই যথেষ্ট নয়—নিজের মামলায় model বাছুন
আইনি কাজে বিশেষায়িত LLM নাকি general-purpose frontier model ভালো—এর সর্বজনীন উত্তর নেই। আপনার jurisdiction-এর আইন ও মামলার নথি থেকে যে model নির্ভুল উত্তর দেয়, যাচাইযোগ্য citation দেখায় এবং প্রমাণ না থাকলে থামে, নির্দিষ্ট কাজটির জন্য সেটিই উপযুক্ত; নামের পাশে “legal” লেখা বা benchmark-এ এগিয়ে থাকা যথেষ্ট নয়।
বাংলাদেশ ও ভারতের আইনজীবী, legal-tech buyer এবং engineering দলের তাই একই গোপন test set-এ candidate model তুলনা করা উচিত। সিদ্ধান্তের ভিত্তি হবে jurisdiction, supplied-document grounding, citation quality, task-specific accuracy, privacy এবং প্রতি গ্রহণযোগ্য কাজের মোট খরচ—vendor label নয়।
Benchmark কোথায় কাজে লাগে, কোথায় থামতে হয়
বিশেষায়নের সুবিধা বাস্তব হতে পারে। Thomson Reuters-এর প্রকাশিত মূল্যায়নে Thomson-কে ১০০টির বেশি legal-domain benchmark-এ পরীক্ষা করা হয়েছে এবং PrBench Legal Hard-এ model-টি ০.৩৫২ score নিয়ে পরীক্ষিত frontier model-গুলোর আগে ছিল। কিন্তু এটি vendor-প্রকাশিত ফল; বাংলা pleading, ভারতীয় statute interpretation বা বাংলাদেশের রায়ের citation-এ একই ফল হবে—ওই score তা প্রমাণ করে না।
একইভাবে, benchmark বদলালে model-গুলোর ব্যবধানও বদলায়। Stanford AI Index 2026-এর technical chapter অনুযায়ী, সাম্প্রতিক যুক্তরাষ্ট্র ও কানাডার সিদ্ধান্তভিত্তিক CaseLaw v2-তে GPT-5.1-এর accuracy ছিল ৭৩.৪ শতাংশ, GPT-4.1-এর ৬৯.৯ শতাংশ এবং অন্য শীর্ষ model-গুলোর অধিকাংশ ৬২–৬৬ শতাংশের মধ্যে; LegalBench-এর শীর্ষ ১৫ model আবার প্রায় চার percentage point-এর মধ্যে ছিল। একটি benchmark-এ স্পষ্ট ব্যবধান এবং অন্যটিতে ঘনিষ্ঠ ফল—দুটিই দেখায় যে aggregate leaderboard দিয়ে research, chronology extraction ও drafting-এর একক winner নির্ধারণ করা যায় না।
প্রকাশিত benchmark দিয়ে প্রথমে দুর্বল candidate বাদ দিন। তারপর benchmark-এর jurisdiction, supplied documents, prompt, model version, scoring rubric এবং test contamination-এর সম্ভাবনা আপনার workflow-এর সঙ্গে না মিললে সেই ফলকে procurement decision হিসেবে ব্যবহার করবেন না।
স্থানীয় নথি দিয়ে blind evaluation বানান
গত ছয় থেকে বারো মাসের কাজ থেকে ৬০–১০০টি প্রতিনিধিত্বশীল task নেওয়া একটি ব্যবহারযোগ্য সূচনা। Active matter-এর পরিচয় মুছে ফেলুন অথবা অনুমোদিত synthetic variant তৈরি করুন; প্রায় ২০ শতাংশ item prompt ও workflow ঠিক করার জন্য রেখে বাকিগুলো locked final test হিসেবে আলাদা করুন। Model operator যেন expected answer না দেখেন এবং reviewer যেন output-এর model-পরিচয় না জানেন।
বাংলাদেশি set-এ আপিল ও হাইকোর্ট বিভাগের রায়, প্রযোজ্য আইন, বাংলা নথি এবং প্রতিষ্ঠানের অনুমোদিত precedent bank রাখুন। বাংলাদেশ সুপ্রিম কোর্টের ওয়েবসাইটে Appellate Division ও High Court Division-এর judgment collection-এর পৃথক প্রবেশপথ রয়েছে; reference answer তৈরির সময় সংশ্লিষ্ট আদালতের প্রকাশিত নথিই ধরে রাখুন। ভারতীয় set-এ Supreme Court ও প্রাসঙ্গিক High Court, কেন্দ্রীয় বা রাজ্য আইন, amendment date এবং territorial rule আলাদা tag করুন।
Test set-এ আপনার বাস্তব কাজের অনুপাত বজায় রাখুন। একটি সম্ভাব্য বিন্যাস হলো:
- নথি থেকে fact ও timeline extraction—২০টি;
- প্রদত্ত রায় ও statute প্রয়োগ—২০টি;
- citation-সহ research memorandum—১৫টি;
- contract review বা pleading issue spotting—১৫টি;
- বাংলা–ইংরেজি mixed document ও OCR-ত্রুটি—১০টি;
- অসম্পূর্ণ বা ভুল premise-এ abstention—১০টি।
সব candidate-কে একই document bundle, system instruction, output format, tool access এবং retry budget দিন। একটি model-কে retrieval দিয়ে অন্যটিকে closed-book অবস্থায় চালালে model নয়, দুটি ভিন্ন system architecture-এর ফল তুলনা হবে।
Citation ও abstention আলাদা করে মাপুন
সাবলীল উত্তরকে সঠিক উত্তর ধরে score দেবেন না। প্রতিটি material legal proposition-এর জন্য authority, court, decision date, pinpoint paragraph বা page এবং supporting passage চাইুন। Reviewer যাচাই করবেন authority বাস্তব কি না, উদ্ধৃত অংশটি সেখানে আছে কি না, সেটি proposition-টিকে সত্যিই সমর্থন করে কি না এবং নির্ধারিত jurisdiction ও সময়সীমায় প্রযোজ্য কি না।
Journal of Legal Analysis-এর ২০২৪ সালের গবেষণায় ChatGPT 4, ChatGPT 3.5, PaLM 2 ও Llama 2-কে মার্কিন case-law প্রশ্নে পরীক্ষা করে অন্তত ৫৮ শতাংশ hallucination, ভুল premise মেনে নেওয়া এবং নিজের অনিশ্চয়তা ঠিকভাবে শনাক্ত করতে না পারার প্রমাণ পাওয়া যায়। ফলটি বর্তমান সব model বা বাংলাদেশ–ভারতের performance নির্দেশ করে না; এটি citation existence, proposition support ও false-premise resistance আলাদা metric রাখার যুক্তি দেয়।
ভারতে এর বিচারিক পরিণতির একটি নির্দিষ্ট নজিরও আছে। Supreme Court of India-এর Pooja Ramesh Singh মামলার সারসংক্ষেপে বলা হয়েছে, ছয়টি AI-সৃষ্ট citation-এর মধ্যে কিছু ছিল অস্তিত্বহীন এবং কিছু genuine citation-এর সঙ্গে অস্তিত্বহীন paragraph জুড়ে দিয়েছিল; আদালত NCLT ও NCLAT-এর সিদ্ধান্ত বাতিল করে বিষয়টি নতুনভাবে নিষ্পত্তির জন্য NCLT-তে ফেরত পাঠায়। তাই “মামলাটি পাওয়া গেছে” citation pass করার জন্য যথেষ্ট নয়—নির্দিষ্ট proposition ও paragraph-ও মিলতে হবে।
Abstention test-এ তিন ধরনের ফাঁদ রাখুন: bundle-এ অনুপস্থিত তথ্য, অন্য jurisdiction-এর একই নামের আইন এবং বাতিল বা সংশোধিত provision। ভালো output সীমা জানাবে, প্রয়োজনীয় নথি চাইবে এবং অনিশ্চিত citation বানাবে না। এই ফল accuracy-র সঙ্গে মেশাবেন না; justified refusal এবং confident fabrication-এর ঝুঁকি এক নয়।
Cross-jurisdiction error-এর জন্য আলাদা gate রাখুন
সাধারণ model ভাষাগতভাবে মসৃণ উত্তর দিয়েও বাংলাদেশ ও ভারতের court hierarchy, একই ধরনের common-law পরিভাষা বা সমনামের statute গুলিয়ে ফেলতে পারে। বিশেষায়িত model-ও নিরাপদ নয়, যদি তার corpus ও evaluation মূলত উত্তর আমেরিকাকেন্দ্রিক হয়। তাই প্রতিটি item-এ country, court, state বা division, law version, cut-off date এবং permitted sources বাধ্যতামূলক metadata করুন।
প্রতি উত্তরে ২, ১ বা ০ score ব্যবহার করা যায়: সম্পূর্ণ সঠিক, সংশোধনযোগ্য ঘাটতি অথবা ব্যবহার-অযোগ্য। তবে aggregate score-এর পাশাপাশি পাঁচটি মাত্রা আলাদা রাখুন:
- Jurisdiction: সঠিক দেশ, আদালত ও territorial rule;
- Grounding: প্রতিটি material claim প্রদত্ত নথিতে আছে কি না;
- Citation: authority, proposition ও pinpoint একসঙ্গে মেলে কি না;
- Completeness: outcome বদলাতে পারে এমন fact বা exception বাদ পড়েছে কি না;
- Abstention: evidence না থাকলে model থেমেছে কি না।
Critical error-এর weighted penalty বেশি রাখুন। ভুল formatting সংশোধনযোগ্য, কিন্তু অস্তিত্বহীন মামলা, ভুল jurisdiction বা adverse authority বাদ দেওয়া সরাসরি quality gate ব্যর্থ করবে। Average score কাছাকাছি হলে critical-error rate-ই বেশি অর্থবহ tie-breaker।
Privacy ও accepted-task cost দিয়ে চূড়ান্ত নির্বাচন
Confidential matter upload করার আগে “encrypted” বা “enterprise” label-এ থামবেন না। চুক্তি ও technical documentation থেকে যাচাই করুন prompt ও attachment কোথায় process ও সংরক্ষিত হয়, retention কত দিন, customer data training-এ ব্যবহৃত হয় কি না, subcontractor কারা, deletion কীভাবে নিশ্চিত হয় এবং incident notification-এর দায়িত্ব কার। একই vendor-এর consumer chat, enterprise product ও API-র শর্ত এক নাও হতে পারে।
Model price-কে শুধু token rate দিয়ে তুলনা করলে ব্যয় অসম্পূর্ণ থাকবে। Cost sheet-এ input ও output, embedding, retrieval, storage, OCR, reranking, tool call, retry, reviewer time, rework, private deployment, logging, monitoring এবং security review রাখুন।
Cost per accepted task হিসাব করতে model ও infrastructure charge, review labour এবং rework যোগ করে quality gate পেরোনো output-এর সংখ্যা দিয়ে ভাগ করুন। সস্তা model বেশি retry ও review চাইলে তার প্রকৃত খরচ frontier model-এর চেয়ে বেশি হতে পারে; সংকীর্ণ extraction task-এ ছোট বা specialised model যথেষ্ট হলে উল্টো ফলও সম্ভব।
একটি model-কে পুরো legal stack-এর winner না বানিয়ে task অনুযায়ী routing করাই যুক্তিসংগত। Document extraction-এ কম খরচের grounded model, কঠিন reasoning-এ শক্তিশালী frontier model এবং citation-sensitive research-এ অনুমোদিত legal database-সংযুক্ত system রাখা যেতে পারে। Fabricated citation, cross-jurisdiction error বা privacy condition নির্ধারিত সীমা ছাড়ালে cost কম হলেও candidate বাদ দিন; gate পেরোনোগুলোর মধ্যে accepted-task cost, latency ও operational fit দিয়ে নির্বাচন করুন।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।