شمار پرونده‌های توهم هوش مصنوعی در دادگاه‌ها از ۲٬۰۰۰ گذشت؛ چه باید ساخت؟

شمار رأی‌های دادگاه‌ها درباره محتوای حاصل از توهم هوش مصنوعی از ۲٬۰۰۰ گذشته است. چرا RAG به‌تنهایی مشکل را حل نکرد و کدام الگوها خطای هوش مصنوعی را در حوزه قرارداد بررسی‌پذیر می‌کنند؟

توهم هوش مصنوعی یعنی پاسخی نادرست یا بی‌پشتوانه که مدل زبانی با اطمینان می‌دهد. تا ۲۳ شهریور ۱۴۰۵، دامین شارلوتن در پایگاه AI Hallucination Cases، ۲٬۰۴۱ رأی از دادگاه‌ها و مراجع رسیدگی را درباره محتوای حاصل از توهم هوش مصنوعی فهرست کرده است. RAG به‌تنهایی راه‌حل نیست: در پژوهش پیش‌ثبت‌شده استنفورد، سه ابزار مطرح پژوهش حقوقی در آزمون‌های ۲۰۲۴ هر کدام در ۱۷ تا ۳۳ درصد موارد دچار توهم شدند. آنچه باید ساخت سه چیز است: ساختاری که خروجی را با متن سند تطبیق‌پذیر کند، روندی که تصمیم را به انسان بسپارد و مجموعه ارزیابی‌ای که از ابتدا آماده باشد.

من مهندس هوش مصنوعی در پروژه کارتز کانترکت بودم. در این نوشته می‌گویم اگر امروز دوباره روی چنین سامانه‌ای کار می‌کردم، از آن تجربه چه چیزهایی را نگه می‌داشتم و چه کاری را پیش از هر کار دیگری انجام می‌دادم.

پایگاه پرونده‌های توهم هوش مصنوعی به توسعه‌دهندگان چه می‌گوید و چه نمی‌گوید؟

شمار رأی‌های پایگاه شارلوتن از ۲٬۰۰۰ گذشته است. پیش از آنکه این عدد در یک ارائه تجاری یا گزارش ریسک نقل شود، سه نکته را باید درباره آن دانست.

رأی را می‌شمارد، نه خطا را. این پایگاه رأی‌هایی را ثبت می‌کند که در آن‌ها دادگاه یا مرجع رسیدگی به‌صراحت یا به‌طور ضمنی احراز کرده است که یکی از طرفین به محتوای حاصل از توهم تکیه کرده است. به‌طور استثنایی، شماری از رأی‌ها را هم در بر می‌گیرد که در آن‌ها استفاده از هوش مصنوعی ادعا شده اما تأیید نشده است؛ به گفته خود شارلوتن، گنجاندن این دسته به تشخیص شخصی اوست. به تصریح پایگاه، «مجموعه (ناگزیر گسترده‌تر) همه ارجاع‌های جعلی یا استفاده از هوش مصنوعی در لوایح دادگاه» را دنبال نمی‌کند. پس این فهرست کارنامه خطاهایی است که به قاضی رسیده‌اند، نه نرخ توهم.

ابزارها را مقصر نمی‌داند. یادداشت خود پایگاه می‌گوید آمدن نام یک ابزار «لزوماً به این معنا نیست که آن ابزار مسئول توهم‌های مورد بحث بوده است». از همین رو هیچ رأیی از این پایگاه را به ابزاری نسبت نمی‌دهم؛ ابزارهایی که در ادامه نام برده می‌شوند از پژوهش استنفورد آمده‌اند، نه از این پایگاه.

دسته‌ها از عدد کل مهم‌ترند. در پایگاه شارلوتن، ۱٬۶۹۰ رأی برچسب «ساختگی» (Fabricated)، ۸۵۴ رأی برچسب «تحریف‌شده» (Misrepresented) و ۵۴۸ رأی برچسب «نقل‌قول نادرست» (False Quotes) دارند و یک رأی می‌تواند چند برچسب بگیرد. بررسی اینکه منبع مورد استناد اصلاً وجود دارد یا نه، می‌تواند بیشتر خطاهای دسته نخست را آشکار کند، یعنی منابع استنادی‌ای که از اساس ساختگی‌اند. اما هر جا منبع واقعی باشد و فقط نقل‌قول ساختگی یا برداشت از آن نادرست باشد، این بررسی دو دسته دیگر را تشخیص نمی‌دهد. ابزار هوش مصنوعی در حوزه قرارداد هم می‌تواند هر دو خطا را مرتکب شود، آن هم در حالی که به بندی اشاره می‌کند که واقعاً در قرارداد هست.

به گزارش پایگاه شارلوتن، در ۱٬۱۷۴ رأی، کسی که از هوش مصنوعی استفاده کرده خودِ طرف دعوا بوده که بدون وکیل در دادرسی حاضر شده است، و در ۸۱۱ رأی، یک وکیل. پس طراحی ابزار هوش مصنوعی حقوقی نمی‌تواند بر این فرض تکیه کند که وکیلی در کار است، یا اینکه اگر وکیلی در کار باشد، خطاهای ابزار را تشخیص خواهد داد. در همین پایگاه، قرارداد (Contract) با ۴۴۹ رأی پرشمارترین حوزه حقوقی است. این‌ها دعاوی قراردادی‌اند که محتوای حاصل از توهم هوش مصنوعی در آن‌ها محل بحث بوده است، نه قراردادهایی که هوش مصنوعی تنظیم کرده باشد.

آیا RAG جلوی توهم هوش مصنوعی حقوقی را می‌گیرد؟

نه. در معماری RAG، یا تولید مبتنی بر بازیابی (retrieval-augmented generation)، سامانه پیش از پاسخ‌دادن بخش‌های مرتبط اسناد را پیدا می‌کند و همراه پرسش به مدل زبانی می‌دهد. پژوهش استنفورد که در ادامه می‌آید نتیجه می‌گیرد که RAG حقوقی «می‌تواند توهم را در مقایسه با سامانه‌های هوش مصنوعی همه‌منظوره (در اینجا GPT-4) کاهش دهد، اما توهم همچنان چشمگیر، گسترده و بالقوه موذیانه است». «موذیانه» واژه دقیقی است: پاسخی که استناد نادرست دارد، به منبعی واقعی هم ارجاع می‌دهد. اینکه RAG چیست و لایه‌های محافظ در برابر توهم آن چگونه طراحی می‌شوند، در نوشته جلوگیری از توهم هوش مصنوعی در RAG آمده است.

پژوهش پیش‌ثبت‌شده استنفورد: توهم در ۱۷ تا ۳۳ درصد موارد

در مقاله‌ای که نسخه arXiv آن در ۱۰ خرداد ۱۴۰۳ (۳۰ مه ۲۰۲۴) منتشر شد، پژوهشگرانی از دانشگاه‌های استنفورد و ییل «نخستین ارزیابی تجربی پیش‌ثبت‌شده از ابزارهای پژوهش حقوقی مبتنی بر هوش مصنوعی» را گزارش کردند. پیش‌ثبت‌شده یعنی طرح پژوهش و مجموعه‌ای شامل بیش از ۲۰۰ پرسش حقوقی پیش از اجرای ارزیابی ثبت شده بودند تا پرسش‌ها متناسب با نتایج گزینش نشوند. برخی شرکت‌های ارائه‌دهنده، بازیابی را راه «حذف» توهم یا «جلوگیری» از آن معرفی کرده بودند. این پژوهش نشان داد که ابزارهای Lexis+ AI و Westlaw AI-Assisted Research و Ask Practical Law AI هر کدام در ۱۷ تا ۳۳ درصد موارد دچار توهم شدند و «ادعاهای ارائه‌دهندگان اغراق‌آمیز است».

تعریف توهم در این پژوهش از خود این بازه مهم‌تر است. پاسخی توهم به شمار می‌آید که «یا نادرست باشد یا استناد نادرست (misgrounded) داشته باشد». استناد نادرست یعنی برای گزاره‌های کلیدی منبع ذکر شده است، اما این گزاره‌ها «منبع را نادرست تفسیر می‌کنند یا به منبعی ارجاع می‌دهند که در آن مورد کاربرد ندارد». این ابزارها در سال ۲۰۲۴ و برای پژوهش حقوقی آزموده شدند، نه برای قرارداد؛ پس این بازه را نباید نرخ امروزِ توهم در هوش مصنوعی حقوقی دانست. اما همین دسته خطا در قرارداد هم رخ می‌دهد: پاسخی که استناد نادرست دارد درست به نظر می‌رسد، ولی به بند اشتباه اشاره می‌کند.

پژوهش گوگل درباره زمینه کافی: زمینه بیشتر، امتناع کمتر

مقاله «زمینه کافی» (Sufficient Context) دو نوع خطا را از هم جدا می‌کند: خطایی که در آن مدل از زمینه‌ای مناسب استفاده نادرست می‌کند، و خطایی که در آن زمینه از ابتدا برای پاسخ کافی نبوده است. به گزارش این مقاله، مدل‌های بزرگ‌تری از گوگل، OpenAI و Anthropic که در این پژوهش آزموده شدند، وقتی زمینه (context) کافی نیست «اغلب به‌جای امتناع، پاسخ نادرست می‌دهند».

در یادداشتی که Google Research در ۲۴ اردیبهشت ۱۴۰۴ (۱۴ مه ۲۰۲۵) درباره این پژوهش منتشر کرد، آمده است که RAG «به‌طور کلی عملکرد را بهبود می‌بخشد». اما برخلاف انتظار، «توانایی مدل را برای امتناع از پاسخ، در جایی که امتناع به‌جاست، کاهش می‌دهد». در مثالی که Google Research آورده است، مدل Gemma بدون هیچ زمینه‌ای به ۱۰٫۲ درصد پرسش‌ها پاسخ نادرست داد و با زمینه ناکافی به ۶۶٫۱ درصد آن‌ها.

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

بررسی قرارداد با هوش مصنوعی: کدام خطاها اهمیت دارند؟

بند ساختگی برای کسی که قرارداد را امضا می‌کند مسئولیت حقوقی می‌آورد؛ پس مدلی که از خود بندی بسازد از نبودن مدل بدتر است. اگر امروز چنین ابزاری می‌ساختم، طراحی را پیش از هر چیز بر مهار همین خطاها متمرکز می‌کردم. هیچ‌یک از الگوهای جدول زیر درستی پاسخ را ثابت نمی‌کند؛ بیشترشان کمک می‌کنند پاسخ نادرست آشکار شود.

الگوهای طراحی هوش مصنوعی در حوزه قرارداد: تجربه کارتز کانترکت

از آذر ۱۴۰۴ تا تیر ۱۴۰۵ مهندس هوش مصنوعی در پروژه کارتز کانترکت بودم. کارتز کانترکت فضای کاری سه‌زبانه‌ای برای تنظیم، بررسی و ویرایش قرارداد با هوش مصنوعی بود، با پشتیبانی کامل از فارسی و راست‌به‌چپ، و سه بخش داشت: دستیار گام‌به‌گام تنظیم قرارداد، مسیر بررسی قرارداد و استودیوی قرارداد. موتور هوش مصنوعی این سه روند را با شروع از زنجیره‌های اولیه هوش مصنوعی کارفرما بازسازی کردم و گسترش دادم. دستیار ویرایش (copilot) را هم ساختم؛ دستیاری که نوع هر درخواست را تشخیص می‌داد، بندهای مرتبط را پیدا می‌کرد و ویرایش را در کل قرارداد برنامه‌ریزی می‌کرد.

دشوارترین مسائل، بازیابی و پایبندی مدل به متن بود و این پایبندی با ساختار تأمین شد، نه با اعتماد. هیچ‌یک از شش الگوی زیر تضمینی سنجیده‌شده نیست؛ چهار الگوی نخست همان قیدهای طراحی‌اند که پایبندی مدل به متن را تأمین می‌کردند.

پاسخ فقط از بندهایی که دستیار ویرایش انتخاب کرده است

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

بند همان واحدی است که حقوق‌دان با آن کار می‌کند، مثلاً «تبصره ۲ ماده ۷»؛ پس ارزیاب می‌تواند مجموعه‌ای از بندهای بازیابی‌شده را برچسب بزند و بررسی کند. آن دستور راهی جز حدس‌زدن پیش پای مدل می‌گذارد، اما سازوکاری الزام‌آور نیست؛ بنابراین مجموعه ارزیابی باید پرسش‌هایی داشته باشد که بندهای انتخاب‌شده پاسخی برایشان ندارند. بازیابی متن فارسی دام‌های خودش را دارد؛ این دام‌ها برای سامانه‌ای دیگر در نوشته جستجوی ترکیبی در RAG فارسی بررسی شده‌اند.

اصلاحی که متن قرارداد را عیناً نقل می‌کند

هر اصلاح پیشنهادی باید متن فعلی قرارداد را کلمه‌به‌کلمه نقل می‌کرد تا بتوان آن را در سند یافت و جایگزین کرد، و متن جایگزینِ آماده‌ای هم همراه خود داشت. همین الزام، اعتبارسنجی نقل‌قول دقیق (exact-quote validation) را ممکن می‌کند: برنامه می‌تواند پیش از اعمال اصلاح بررسی کند که متن نقل‌شده واقعاً در سند وجود دارد.

اینکه یک بازنویسی سنجیده و به صلاح هست یا نه، داوری حقوقی است؛ اینکه جمله‌ای که قرار است جایگزین شود اصلاً در سند هست یا نه، با تطبیق رشته‌ای معلوم می‌شود. راهنمای OWASP درباره اطلاعات نادرست در LLM‌ها همین استدلال را در سطح کلی مطرح می‌کند و توصیه می‌کند «خروجی‌های کلیدی، به‌ویژه خروجی محیط‌های پرمخاطره، به‌طور خودکار اعتبارسنجی شوند». اگر دوباره چنین سامانه‌ای می‌ساختم، هر اصلاحی را که نقل‌قولش در سند پیدا نشود کنار می‌گذاشتم، هرگز آن را به‌صورت تقریبی اعمال نمی‌کردم و شمار این موارد را هشداری زودهنگام به حساب می‌آوردم. به نظر من، در متن فارسی پیش از این تطبیق باید هر دو متن را یکسان‌سازی (normalise) کرد: ی و ک عربی به فارسی تبدیل شوند و نیم‌فاصله‌ها و ارقام هم یکسان شوند. وگرنه ممکن است نقل‌قولی که درست است هم پیدا نشود.

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

قالب خروجی ثابت، بدون نمایش خام

هر تحلیل ساختاری ثابت (schema) بازمی‌گرداند تا خط زمانی، فهرست ریسک‌ها و اصلاحات هر بار به یک شکل چیده شوند. پاسخی که ساختار نادرست داشت، از چند مرحله پیاپی تجزیه و ترمیم می‌گذشت که ترمیم پاسخ‌های نیمه‌تمام را هم در بر می‌گرفت، و در صورت نیاز با فضای بیشتر برای پاسخ، دوباره درخواست می‌شد. چنین پاسخی هرگز به‌صورت خام به کاربر نشان داده نمی‌شد.

این طراحی خطایی پنهان را هدف می‌گیرد: فهرست ریسکی که وسط کار قطع شده، برای خواننده کامل به نظر می‌رسد. ترمیم به‌تنهایی این مشکل را حل نمی‌کند، چون فهرست نیمه‌تمامی که ساختارش در ترمیم بسته شده باشد، همچنان بی‌خطا تجزیه (parse) می‌شود. اگر دوباره چنین سامانه‌ای می‌ساختم، پاسخ نیمه‌تمامی را که ترمیم شده دوباره درخواست یا علامت‌گذاری می‌کردم، نه اینکه آن را به‌عنوان پاسخ کامل نمایش دهم. قالب ثابت به بررسی‌های دیگر هم نشان می‌دهد هر مقدار را کجا باید پیدا کنند.

میزان پایین تصادفی‌بودن هنگام نگارش پیش‌نویس

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

روند هدایت‌شده برای هر کار، نه یک پنجره گفت‌وگو برای همه کارها

تنظیم، بررسی و ویرایش قرارداد سه کار متفاوت‌اند و هر کدام به روند هدایت‌شده (guided workflow) خود نیاز دارد، نه به یک پنجره گفت‌وگوی عمومی. برای نمونه، بررسی قرارداد از جایگاه کاربر در معامله نوشته می‌شود؛ از همین رو در گام نخست، کاربر نقش خود را در معامله مشخص می‌کند.

شرکت Anthropic در مقاله «Building effective agents»، روند را به معنای هماهنگ‌سازی اجزای سامانه به کار می‌برد. در این معنا، روندها سامانه‌هایی‌اند که «LLM‌ها و ابزارها در آن‌ها از طریق مسیرهایی که از پیش در کد تعیین شده‌اند، هماهنگ می‌شوند». به گفته همین مقاله، روندها «برای کارهایی که تعریف روشنی دارند، پیش‌بینی‌پذیری و ثبات فراهم می‌کنند». هر گامِ ثابت ورودی و خروجی‌ای با شکل معلوم دارد که می‌توان آن را بررسی کرد. پنجره خالی گفت‌وگو هر چیزی را می‌پذیرد و هر چیزی برمی‌گرداند.

ویرایش‌های برجسته‌شده‌ای که کاربر می‌پذیرد یا رد می‌کند

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

به این ترتیب کاربر به‌جای بازخوانی کل سند، تغییرات علامت‌خورده را داوری می‌کند. تغییر نامی که در چند بخش اعمال شده، در همه آن بخش‌ها برجسته است، نه اینکه بعدها به شکل ناهماهنگی در متن به چشم بیاید.

سامانه‌ای دیگر: گیت‌های قطعی دستیار هوشمند همین سایت

هیچ‌یک از آنچه در این بخش شرح می‌دهم جزو کارتز کانترکت نبود. دستیار هوشمند این سایت را خودم ساخته‌ام و نگهداری می‌کنم. این دستیار فقط از محتوای خود سایت پاسخ می‌دهد و چند گیت قطعی (deterministic gate) مسیر پرسش و پاسخ آن را کنترل می‌کنند.

برخی پرسش‌ها پیش از هر بازیابی، با تطبیق الگو رد می‌شوند: پرسش درباره هزینه و در دسترس بودن برای همکاری، جزئیات خصوصی، درخواست گمانه‌زنی، تلاش برای بیرون‌کشیدن یا تغییر پرامپت سیستمی (system prompt) و درخواست انجام کار، مانند نوشتن کد یا ترجمه متن. اگر پرسش درباره من نباشد و هیچ نتیجه بازیابی‌شده‌ای به آستانه امتیاز بازیابی نرسد، دستیار سایت از پاسخ امتناع می‌کند و مدل اصلاً فراخوانی نمی‌شود. پرسش‌های مربوط به من نیز با تطبیق الگو شناسایی می‌شوند، از روی نشانه‌هایی مانند نام من یا ضمیر سوم‌شخص («او»)، و صرفاً به این دلیل که هیچ قطعه‌متنی به آستانه نرسیده است رد نمی‌شوند. در این حالت، داده‌های ثبت‌شده خود سایت، یعنی مدخل‌هایی از رزومه، مطالعه‌های موردی، نوشته‌ها و صفحه مشاوره، به مدل داده می‌شود و از مدل خواسته می‌شود که اگر این داده‌ها پاسخ پرسش را در بر ندارند، فقط یک توکن ثابت برگرداند؛ آن‌گاه خواننده همان پاسخ امتناع را می‌بیند. هنگام استریم پاسخ، گیت جمله‌ای (sentence gate) هر جمله کامل را پیش از نمایش بررسی می‌کند:

• محدوده استناد. هر نشانگر استناد باید به یکی از منابعی اشاره کند که به مدل داده شده است.

• استناد اجباری. هر جمله محتوایی باید نشانگر استناد داشته باشد.

• پشتوانه مقادیر. هر عدد، URL و نشانی ایمیل باید در منبعی وجود داشته باشد که همان جمله به آن استناد می‌کند.

• بدون اول شخص. جمله نباید ضمیر اول شخص (مانند «من» و «ما») یا فعل‌های پرکاربرد اول شخص داشته باشد.

اگر یک جمله رد شود، پاسخ همان‌جا متوقف می‌شود و آن جمله هرگز نمایش داده نمی‌شود. نشانگرهای استناد بررسی و سپس حذف می‌شوند، پس خواننده هرگز آن‌ها را نمی‌بیند.

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

ارزیابی هوش مصنوعی حقوقی: چرا مجموعه ارزیابی را باید اول ساخت؟

ترتیب رایج این است: اول ساختن، بعد سنجیدن. برای هوش مصنوعی حقوقی، پیشنهاد من این است که این ترتیب برعکس شود و مجموعه ارزیابی (evaluation set) پیش از خود سامانه ساخته شود.

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

• هر تغییر به آزمون رگرسیون نیاز دارد. بدون مجموعه‌ای ثابت، هر تغییر در مدل، پرامپت یا بازیابی با حس و گمان داوری می‌شود.

• مجموعه ارزیابی از خود پروژه بیشتر عمر می‌کند. مجموعه‌ای برچسب‌خورده همراه با نتایج آخرین اجرای آن مدرکی است که دیگران هم می‌توانند به کار بگیرند؛ فهرستی از اصول طراحی چنین نیست.

آنچه در کارتز کانترکت رخ داد

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

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

مجموعه ارزیابی هفته اول برای هوش مصنوعی در حوزه قرارداد

آنچه در ادامه می‌آید توصیه است، نه توصیف چیزی که کارتز کانترکت داشت. هر مورد فقط دو نتیجه دارد: قبول یا مردود.

• پرسش‌های پاسخ‌پذیر، با برچسب بند. پاسخ باید درست باشد و از همان بند گرفته شود.

• پرسش‌هایی که قرارداد پاسخشان را ندارد. انتظار می‌رود سامانه بگوید «به ماده دیگری از قرارداد نیاز دارم» یا «قرارداد در این باره چیزی نمی‌گوید»، نه اینکه پاسخی بسازد.

• درخواست‌های ویرایش. هر نقل‌قول در اصلاح پیشنهادی باید با تطبیق رشته‌ای در متن اصلی سند پیدا شود.

• ویرایش‌های سراسری. تغییر نام یکی از طرفین باید همه جاهایی را که آن نام آمده است تغییر دهد و به هیچ چیز دیگری دست نزند.

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

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

• ساختار فارسی. شماره‌گذاری ماده، بند و تبصره؛ سطرهای دوجهته‌ای که فارسی و لاتین را کنار هم دارند؛ و ارقام فارسی.

• هر دو طرف معامله. همان قرارداد باید از جایگاه هر یک از طرفین بررسی شود.

مهلت‌های قانون هوش مصنوعی اتحادیه اروپا پس از Digital Omnibus، از نگاه مهندسی

• پارلمان اروپا متن نهایی را در ۲۶ خرداد ۱۴۰۵ (۱۶ ژوئن ۲۰۲۶) و شورای اتحادیه اروپا در ۸ تیر ۱۴۰۵ (۲۹ ژوئن ۲۰۲۶) تصویب کردند.

• مهلت نشانه‌گذاری محتوای تولیدشده با هوش مصنوعی، برای سامانه‌هایی که پیش از ۱۱ مرداد ۱۴۰۵ (۲ اوت ۲۰۲۶) به بازار عرضه شده‌اند، ۱۱ آذر ۱۴۰۵ (۲ دسامبر ۲۰۲۶) است.

• سایر تعهدات شفافیت ماده ۵۰، مانند آگاه‌کردن کاربران از اینکه با یک سامانه هوش مصنوعی سروکار دارند، از ۱۱ مرداد ۱۴۰۵ (۲ اوت ۲۰۲۶) اعمال می‌شوند.

• تعهدات مربوط به سامانه‌های پرخطر مستقلِ فهرست‌شده در پیوست سوم (Annex III) به ۱۱ آذر ۱۴۰۶ (۲ دسامبر ۲۰۲۷) موکول شده است. برای هوش مصنوعی تعبیه‌شده در محصولاتی که مشمول قوانین ایمنی محصول‌اند و این قوانین در پیوست یکم (Annex I) فهرست شده‌اند، این تاریخ ۱۲ مرداد ۱۴۰۷ (۲ اوت ۲۰۲۸) است.

اینکه یک ابزار حقوقی مشمول این مقررات هست یا نه، پرسشی برای مشاور حقوقی است. هیچ‌یک از الگوهای بالا اقدامی برای انطباق با مقررات نیست.

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

چه خودتان ابزاری بسازید و چه بخواهید یک ابزار هوش مصنوعی حقوقیِ ایرانی یا خارجی را برای تنظیم یا بررسی قرارداد انتخاب کنید، پرسش‌ها یکسان‌اند.

• هر پاسخ به چه چیزی متکی است؟ به یک ماده، بند یا بخش مشخص، نه به «سند» به‌طور کلی.

• آیا جای هر ویرایش در سند پیدا می‌شود؟ هر تغییر باید متنی را که جایگزین می‌کند نقل کند و این نقل با خود سند تطبیق داده شود.

• آیا می‌تواند بگوید پاسخ در سند نیست؟ از توسعه‌دهنده یا فروشنده بخواهید این را عملاً نشان دهد.

• آیا خروجی پیش از نمایش اعتبارسنجی می‌شود؟ پاسخ‌های خراب باید ترمیم یا کنار گذاشته شوند.

• آیا چیزی بدون تأیید کاربر تغییر می‌کند؟ نباید تغییر کند.

• آیا برای هر کار روندی جدا وجود دارد؟ تنظیم، بررسی و ویرایش قرارداد نباید در یک پنجره گفت‌وگو با هم ترکیب شوند.

• آیا مقادیر کلمه‌به‌کلمه بررسی می‌شوند؟ مبالغ، تاریخ‌ها و نام طرفین، در مقایسه با متن اصلی قرارداد.

• آیا می‌توانم مجموعه ارزیابی را ببینم؟ چه چیزی در آن است، کدام موارد امتناع را می‌آزمایند و آخرین بار چه زمانی اجرا شده است.

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

پرسش‌های متداول

توهم هوش مصنوعی چیست و تاکنون در چند رأی دادگاه مطرح شده است؟

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

آیا RAG توهم هوش مصنوعی را از بین می‌برد؟

نه، اما آن را کاهش می‌دهد. در پژوهشی پیش‌ثبت‌شده از پژوهشگران استنفورد و ییل، توهم در سه ابزار پژوهش حقوقی مبتنی بر بازیابی کمتر از GPT-4 بود. با این حال، هر کدام از این ابزارها در آزمون‌های سال ۲۰۲۴ همچنان در ۱۷ تا ۳۳ درصد موارد دچار توهم شدند. پژوهش «زمینه کافی» گوگل هم نشان داد مدل‌های بزرگ‌تر، وقتی زمینه بازیابی‌شده کافی نیست، اغلب به‌جای امتناع پاسخ نادرست می‌دهند.

آیا بررسی قرارداد با هوش مصنوعی قابل اتکاست؟

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

اعتبارسنجی نقل‌قول دقیق چیست؟

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

چرا هیچ عددی برای دقت کارتز کانترکت وجود ندارد؟

کارفرما همکاری را یک ماه مانده به اتمام، به دلیل مشکلات مالی ناشی از جنگ، متوقف کرد؛ پیش از آنکه مجموعه ارزیابی رسمی ساخته شود. این سایت عددی را که اندازه‌گیری نکرده است تخمین نمی‌زند. همین خلأ دلیل آن است که این نوشته ساختن مجموعه ارزیابی را پیش از هر چیز توصیه می‌کند.

منابع

• دامین شارلوتن (Damien Charlotin)، AI Hallucination Cases Database، آخرین به‌روزرسانی ۲۳ شهریور ۱۴۰۵ (۱۴ سپتامبر ۲۰۲۶)، تاریخ بازدید ۲۶ شهریور ۱۴۰۵ (۱۷ سپتامبر ۲۰۲۶)، با مجوز CC BY 4.0.

• مقاله Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools، نوشته Varun Magesh و Faiz Surani و Matthew Dahl و Mirac Suzgun و Christopher D. Manning و Daniel E. Ho، منتشرشده در ۲۰۲۴.

• مقاله Sufficient Context: A New Lens on Retrieval Augmented Generation Systems، نوشته Hailey Joren و Jianyi Zhang و Chun-Sung Ferng و Da-Cheng Juan و Ankur Taly و Cyrus Rashtchian، منتشرشده در ۲۰۲۴.

• وبلاگ Google Research، نوشته Deeper insights into retrieval augmented generation: The role of sufficient context، منتشرشده در ۲۴ اردیبهشت ۱۴۰۴ (۱۴ مه ۲۰۲۵).

• مدخل LLM09:2025 Misinformation در OWASP GenAI Security Project.

• شرکت Anthropic، مقاله Building effective agents، منتشرشده در ۲۹ آذر ۱۴۰۳ (۱۹ دسامبر ۲۰۲۴).

• مؤسسه حقوقی Freshfields، تحلیل EU AI Act unpacked #34: The final Digital Omnibus on AI، منتشرشده در ۱۹ تیر ۱۴۰۵ (۱۰ ژوئیه ۲۰۲۶).

• مطالعه موردی کارتز کانترکت، در همین سایت.