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

وقتی قرارداد خوانده می‌شود اما اطلاعاتش قابل استفاده نیست

یک قرارداد خدمات ۴۰ صفحه‌ای را در نظر بگیرید که سه الحاقیه دارد؛ مبلغ در متن اصلی، دامنه خدمات در پیوست فنی و شرط تمدید خودکار در بند ۱۲ آمده است. مدیر مالی می‌پرسد «جریمه تأخیر در پرداخت برای فاکتور دوم چقدر است؟» و تیم حقوقی می‌پرسد «مهلت اعلام عدم تمدید چه زمانی تمام می‌شود؟» اگر پاسخ AI فقط یک پاراگراف خلاصه باشد، هیچ‌کدام از این دو نفر نمی‌توانند تصمیم بگیرند. مشکل اینجا «هوش» مدل نیست؛ نبود فیلدهای روشن، منبع قابل ارجاع و قاعده اعتبارسنجی است.

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

اول فیلد را تعریف کنید، بعد مدل را انتخاب کنید

برای هر نوع قرارداد باید یک شِمای فیلد ثابت تعریف کنید. مثلاً برای قرارداد خدمات: طرفین، تاریخ امضا، تاریخ شروع، تاریخ پایان، مبلغ قرارداد، ارز، دوره پرداخت، شرایط تمدید خودکار، مهلت اعلام عدم تمدید، جریمه تأخیر، سطح خدمت، قانون حاکم و شرط محرمانگی. هر فیلد باید نوع داده، واحد، مقدار مجاز و منبع مورد انتظار داشته باشد. «مبلغ» بدون ارز و بدون مشخص‌کردن اینکه ناخالص است یا خالص، برای واحد مالی تقریباً بی‌فایده است.

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

• فیلد خوب حداقل چهار جزء دارد: نام، نوع داده و واحد، منبع مورد انتظار، و قاعده اعتبارسنجی.
• برای فیلدهای شرطی، محرک را جدا ذخیره کنید؛ مثلاً «پس از دریافت فاکتور معتبر» یا «با اخطار کتبی ۶۰ روزه».
• مبلغ را همراه با ارز، مالیات و نوع ناخالص یا خالص ثبت کنید تا در سیستم مالی قابل تطبیق باشد.
• برای هر فیلد مشخص کنید که پاسخ با اطمینان پایین باید به کدام نقش برای بازبینی برود.

RAG و OCR کافی نیستند؛ لایه اعتبارسنجی لازم است

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

معماری قابل اتکا معمولاً چهار مرحله دارد: تجزیه سند، قطعه‌بندی بر اساس بند، استخراج فیلدهای نامزد، و اعتبارسنجی. اعتبارسنجی یعنی مقایسه با قواعد (مثلاً تاریخ پایان نباید قبل از شروع باشد)، تطبیق با سیستم‌های زنده (مثلاً شماره قرارداد در ERP) و ثبت منبع (صفحه، بند، نسخه). در پیلاردین، ترکیب RAG با اتصال به سیستم‌های زنده و ماژول‌های Matrix برای همین لایه طراحی شده است؛ مسیر /matrix نقطه شروع مناسبی برای دیدن دامنه است.

• تاریخ‌ها را با هم مقایسه کنید: شروع، پایان، امضا و الحاقیه‌ها نباید تناقض غیرتوضیح‌داده داشته باشند.
• واحد و ارز را کنترل کنید؛ پاسخ «۳۰» بدون روز یا ماه برای تیم مالی خطرناک است.
• هر فیلد را به صفحه، بند و نسخه قرارداد وصل کنید تا پاسخ قابل حسابرسی باشد.
• موارد کم‌اطمینان یا پرریسک را قبل از ثبت نهایی به بازبینی انسانی بفرستید.

نمونه عملی: قرارداد خدمات و مسیر تأیید انسانی

فرض کنید سازمانی ۲۰۰ قرارداد خدمات دارد و می‌خواهد فقط سه چیز را خودکار کند: تاریخ پایان، شرایط تمدید خودکار و جریمه تأخیر. تیم حقوقی یک شِمای کوچک تعریف می‌کند و ۳۰ تا ۵۰ قرارداد را به‌عنوان نمونه طلایی برچسب می‌زند. سپس سیستم روی همه قراردادها اجرا می‌شود، اما هر فیلد با سطح اطمینان پایین یا مبلغ بالا به بازبینی انسانی می‌رود. این کار از «اتوماسیون همه‌چیز» واقع‌بینانه‌تر است و سریع‌تر نتیجه می‌دهد.

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

• یک دسته قرارداد پرتکرار و کم‌ریسک را انتخاب کنید.
• شِمای فیلد را با واحد مالی و حقوقی مشترکاً تأیید کنید.
• ۳۰ تا ۵۰ نمونه طلایی برای سنجش دقت بسازید.
• آستانه اطمینان و قاعده ارجاع به انسان را از روز اول تعیین کنید.
• هر پاسخ را به صفحه، بند و نسخه قرارداد وصل کنید.

سنجش دقت و کیفیت خروجی

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

• برای هر فیلد معیار precision، recall و نرخ ارجاع به انسان را جدا ثبت کنید.
• خطاها را بر اساس نوع بند، نوع سند و کیفیت OCR دسته‌بندی کنید تا بهبود هدفمند شود.
• هر تغییر در شِمای فیلد یا قاعده اعتبارسنجی را نسخه‌بندی کنید.
• یک جلسه بازبینی دوره‌ای بین حقوقی، مالی و فنی برای بررسی نمونه خطاها برگزار کنید.

امنیت، حریم خصوصی و حاکمیت داده

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

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

نتیجه‌گیری

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

FAQ

آیا برای استخراج قراردادها کافی است متن را به یک مدل زبانی بدهیم؟

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

حداقل شِمای فیلد برای شروع چه چیزهایی باید داشته باشد؟

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

چگونه از خطاهای پرهزینه جلوگیری کنیم؟

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

ردپای حسابرسی چه اطلاعاتی باید داشته باشد؟

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