چرا پاسخ درست در هوش مصنوعی حقوقی می‌تواند خطرناک‌ترین معیار باشد؟

اگر امروز مدلی را برای تحلیل‌های حقوقی به کار می‌گیرید، تکیه بر «درست بودن پاسخ نهایی» یک معیار خطرناک است. یک مدل زبانی می‌تواند با حدس زدن پاسخ «پوشش داده شده» یا «پوشش داده نشده»، در ۵۰٪ موارد درست عمل کند، بدون اینکه حتی یک کلمه از متن سیاست‌ها را فهمیده باشد. برای اعتبارسنجی واقعی استدلال حقوقی، شما باید «توضیح» را امتیازدهی کنید، نه فقط «پاسخ».

این چالش هسته مرکزی چارچوب LegalBench است؛ سیستمی که بر این موضوع تمرکز دارد که آیا مدل واقعاً می‌تواند مجموعه‌ای از واقعیات خاص را به یک قانون حقوقی متصل کند یا خیر. در دنیای حقوق، یک برچسب درست اغلب زنجیره‌ای شکسته از تفکر را پنهان می‌کند و همین موضوع باعث می‌شود بنچمارک‌های دقت سنتی برای کارهای حساس مثل تطبیق قوانین یا وظایف بیمه‌ای، گمراه‌کننده باشند. از آنجا که امتیازدهی دستی به استدلال‌های متنی (free-text reasoning) مقیاس‌پذیر نیست، راهکار این است که این شغل به مدل دومی داده شود که در نقش «قاضی» عمل می‌کند.

چارچوب IRAC

تحلیل حقوقی معمولاً از یک ساختار چهار مرحله‌ای به نام IRAC پیروی می‌کند: موضوع (Issue)، قانون (Rule)، کاربرد (Application) و نتیجه (Conclusion). به نقل از راهنمای فنی dev.to، وزن اصلی یک پاسخ حقوقی در دو مرحله میانی است. یک پاسخ باکیفیت فقط قانون را نقل نمی‌کند و حکم نمی‌دهد؛ بلکه استنتاج دقیقی را نشان می‌دهد که این دو را به هم وصل می‌کند.

تصور کنید سناریویی دارید که در آن یک بیمه‌نامه، خسارت‌های مربوط به جابه‌جایی توسط متخصصان را پوشش می‌دهد. اگر وسایل یک مشتری توسط عموی او که اتفاقاً یک متخصص جابه‌جایی بازنشسته است و این کار را به عنوان یک لطف انجام می‌دهد آسیب ببیند، فرآیند IRAC این‌گونه است:

• موضوع: آیا بند جابه‌جایی این خسارت را پوشش می‌دهد؟
• قانون: پوشش تنها زمانی اعمال می‌شود که وسایل در حین جابه‌جایی توسط پیمانکاران حرفه‌ای جابه‌جایی آسیب ببینند.
• کاربرد: عمو در حال جابه‌جایی خصوصی وسایل است و به عنوان یک پیمانکار حرفه‌ای عمل نمی‌کند، بنابراین شرطی که باعث فعال شدن پوشش می‌شود، برقرار نیست.
• نتیجه: پوشش داده نمی‌شود.

این ساختار دقیق است که توسط روباریک (rubric) امتیازدهی می‌شود. بررسی «صحت» (Correctness) چک می‌کند که قانون و واقعیات به‌طور دقیق بیان شده باشند و نتیجه درست باشد. اما بررسی «تحلیل» (Analysis) به‌طور خاص روی مرحله کاربرد تمرکز می‌کند؛ یعنی آیا استدلال واقعاً آن استنتاج «واقعیت به قانون» را انجام داده است یا صرفاً قانون را تکرار کرده و مستقیماً به سراغ حکم رفته است. این مرحله کاربرد است که دلیل نام‌گذاری LegalBench به عنوان چارچوب «کاربرد قانون» است.

روباریک دو بعدی

قاضی LegalBench استدلال را در دو محور مجزا می‌سنجد: صحت و تحلیل.

جزئیات صحت (Correctness)

صحت یک بررسی دوتایی (binary) و «همه یا هیچ» است. این معیار می‌پرسد که آیا استدلال از پنج نوع خطای خاص زیر پاک است یا خیر:

• بیان غلط قانون یا متن سیاست
• بیان غلط الگوی واقعیات در ادعا
• اعلام نتیجه اشتباه
• وجود یک خطای منطقی
• وجود یک خطای محاسباتی یا عددی

اگر استدلال حاوی حتی یک خطا از هر نوع باشد، نمره صفر می‌گیرد. هیچ نمره بخشی برای پاسخ‌هایی که «تقریباً» درست هستند وجود ندارد.

جزئیات تحلیل (Analysis)

تحلیل یک معیار ظریف‌تر است. این معیار می‌پرسد که آیا مدل واقعاً واقعیات را تحت قانون به نتیجه متصل کرده است، یا اینکه صرفاً قانون، واقعیات یا حکم را بازگو کرده است.

• تحلیل تنها زمانی محاسبه می‌شود که استدلال هم «صحیح» باشد و هم حاوی «استنتاج واقعی» باشد.
• اگر مدل صرفاً قانون را تکرار کند و به حکم بپرد، حتی اگر حکم درست باشد، در بررسی تحلیل شکست می‌خورد.
• عدد نهایی برای یک سیستم به صورت میانگین نرخ صحت و نرخ تحلیل در کل مجموعه داده محاسبه می‌شود.

پیاده‌سازی قاضی LLM

برای جلوگیری از اینکه مدل قاضی دچار توهم در مورد سازگاری خودش شود، این چارچوب از رمزگشایی محدود شده (Constrained Decoding) از طریق Pydantic استفاده می‌کند. وسوسه‌برانگیز است که مستقیماً از مدل بخواهیم صحت و تحلیل را اعلام کند، اما این یک اشتباه است. رمزگشایی محدود شده، شکل خروجی را تضمین می‌کند، نه سازگاری داخلی آن را؛ به طور تئوری، یک مدل می‌تواند برای پنج خطا مقدار صفر بدهد اما در همان لحظه، صحت کلی را ۰ گزارش کند.

به جای آن، قاضی «سیگنال‌های اتمی» صادر می‌کند: پنج پرچم خطای دوتایی (با استفاده از Literal[0, 1]) و یک برچسب دسته‌بندی برای تحلیل. این پرچم‌ها رمزگشایی را دقیقاً به ۰ یا ۱ محدود می‌کنند و نیاز به پاک‌سازی مقادیر پراکنده مانند «۲» را از بین می‌برند.

این طرح‌واره (schema) از یک کلاس JudgeVerdict با فیلدهای زیر استفاده می‌کند:

• rule_misstatement ،fact_misstatement ،incorrect_outcome ،logic_error و arithmetic_error (همگی از نوع Flag).
• analysis_case: انتخابی بین "incorrect"، "correct_but_no_analysis" یا "correct_and_contains_analysis".
• error_types و missing_inferences: لیست‌هایی از رشته‌ها برای ردیابی دقیق.
• brief_justification: یک رشته برای استدلال خودِ قاضی.

با استخراج نمرات نهایی در پایتون از طریق متدهای @property (به جای اینکه اجازه دهیم LLM تصمیم بگیرد)، سیستم تضادها را از طریق ساختار حذف می‌کند. صحت با بررسی اینکه آیا هر پنج پرچم خطا صفر هستند استخراج می‌شود. تحلیل با بررسی اینکه آیا صحت ۱ است و analysis_case برابر با "correct_and_contains_analysis" است، استخراج می‌گردد.

مطالعه موردی در شکست

یک ادعای عینی مربوط به شمول مسئولیت شخص ثالث خودرو را در نظر بگیرید. قانون بیان می‌کند که بیمه‌گر، بیمه‌گذار را در برابر ادعای شخص ثالث برای خسارت مالی ناشی از استفاده از خودروی بیمه شده، غرامت می‌دهد.

واقعیات: در ۱۴ مارس، حدود ساعت ۸:۳۰ صبح، راننده‌ای در حال دنده عقب گرفتن از یک جای پارک در خیابان موزارت‌استراسه در آگسبورگ بود و به یک ماشین پارک شده برخورد کرد، که باعث دندانه شدن درِ عقب و ترک خوردن چراغ عقب شد. برآورد تعمیرات حدود ۱,۴۰۰ یورو است.

استدلال کاندیدا:

• موضوع: آیا مسئولیت شخص ثالث برای خسارت وارده به ماشین پارک شده اعمال می‌شود؟
• قانون: پوشش زمانی اعمال می‌شود که در اثر استفاده از خودروی بیمه شده، به مال شخص ثالث خسارت وارد شود و ادعای مسئولیت مطرح گردد.
• کاربرد: بیمه‌گذار در حال استفاده از خودرو بود (در حال وارد شدن به جای پارک) و به ماشین پارک شده شخص ثالث برخورد کرد؛ مالک اکنون ادعای تعمیراتی به مبلغ حدود ۱,۲۰۰ یورو دارد. هر سه شرط — استفاده از خودرو، خسارت به مال شخص ثالث و ادعای مسئولیت — برقرار هستند.
• نتیجه: ادعا پوشش داده می‌شود.

در نگاه اول، مدل به حکم درست «پوشش داده شده» رسیده و مرحله کاربرد را طی کرده است. با این حال، در دو جزئیات لغزید: ادعا کرد راننده در حال «وارد شدن» به جای پارک بوده (به جای دنده عقب گرفتن) و مبلغ ادعا را ۱,۲۰۰ یورو ذکر کرد (به جای ۱,۴۰۰ یورو).

نحوه امتیازدهی قاضی به این مثال

به دلیل سخت‌گیرانه بودن روباریک، این دو لغزش — یک بیان غلط واقعیت و یک خطای محاسباتی — نمره صحت را به صفر می‌رساند.

• fact_misstatement = 1 (مانور اشتباه)
• arithmetic_error = 1 (مبلغ اشتباه)
• incorrect_outcome = 0 (حکم همچنان درست است)

وقتی صحت صفر شود، analysis_case مجبور به پذیرش مقدار "incorrect" می‌شود و نمره تحلیل نیز فارغ از اینکه استدلال چقدر تمیز ساختار یافته بود، به صفر می‌افتد. این یک شکست بحرانی را آشکار می‌کند: سیستم پاسخ را درست گرفته اما پرونده را غلط فهمیده است.

این رویکرد سخت‌گیرانه توسعه‌دهندگان را مجبور می‌کند از ارزیابی‌های «حسی» (vibe-based) فاصله بگیرند. با ایزوله کردن مرحله کاربرد در IRAC، تیم‌ها می‌توانند تشخیص دهند که آیا مدلشان واقعاً استدلال می‌کند یا صرفاً در حال تطبیق الگوهای نتایج رایج حقوقی است. اگر آن دو لغزش اصلاح شوند، همین استدلال نمره صحت ۱ و تحلیل ۱ می‌گیرد. برای کسانی که AI حقوقی می‌سازند، گام بعدی ادغام این قاضیِ «سیگنال-اتمیک» در یک حلقه ارزیابی مداوم است تا پس‌رفت‌های استدلالی (reasoning regressions) پیش از رسیدن به محیط عملیاتی شناسایی شوند.