اگر امروز برای پردازش اسناد حقوقی حجیم به مدل‌های ابری پول می‌دهید، احتمالاً بخش بزرگی از بودجه شما صرف توکن‌های بیهوده می‌شود. یک خط لوله خصوصی تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — می‌تواند هزینه‌های توکن در GPT-4o را تا ۸۵.۹٪ کاهش دهد، به شرطی که تمرکز مهندسی از مدل به مرحله پیش‌پردازش منتقل شود.
به نقل از یک راهنمای فنی منتشر شده در ۱۴ اکتبر ۲۰۲۶، بحرانی‌ترین شکست‌ها در هوش مصنوعی حقوقی نه در تنظیمات ذخیره‌ساز برداری، بلکه در نحوه مدیریت اسناد پیش از رسیدن به مدل بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و همسایگی کلمات را مشخص می‌کند — رخ می‌دهد. کار سخت و غیرجذاب در واقع روی اسناد انجام می‌شود، پیش از آنکه هرگز به یک مدل برداری برسند؛ اگر این مرحله به‌درستی مدیریت نشود، هیچ مقدار تنظیماتی در پایگاه‌داده برداری نمی‌تواند سیستم را نجات دهد. این چالش‌ها اغلب با نقص در زیرساخت‌های انتقال داده مرتبط هستند، همان‌طور که در تحلیل معماری‌های رویدادمحور برای رفع خطاهای انتقال در مدل‌های RAG بررسی شد.
در دنیای حقوق، محرمانگی یک الزام حرفه‌ای است، نه یک ویژگی اختیاری یا یک چک‌باکس در لیست امکانات. به همین دلیل، مجموعه داده‌ها (Corpus) نباید شبکه داخلی را ترک کنند. این محدودیت باعث می‌شود الگوی رایج ارسال اسناد به APIهای ابری، جایی که داده‌ها پردازش و تجاری‌سازی می‌شوند، به‌دلیل تعهدات اخلاقی و قانونی محرمانگی حرفه‌ای غیرممکن باشد.
بنابراین، کل خط لوله شامل تکه‌بندی، برداری‌سازی، بازیابی و تولید باید روی زیرساخت‌های تحت کنترل اجرا شود. این محیط‌ها می‌توانند از یک ماشین ساده برای دفاتر کوچک تا خوشه‌های داخلی برای سازمان‌های بزرگ متغیر باشند. به‌طور فزاینده‌ای، این امر شامل محیط‌های نرم‌افزاری بومی (xin chuang) است که روی سیستم‌عامل‌های Kylin یا UnionTech اجرا می‌شوند. مرز استقرار باید به عنوان یک ورودی طراحی در نظر گرفته شود، نه یک تصمیم ثانویه یا اتفاقی. برای سازمان‌هایی که حتی در مراحل تست نیز به محیط‌های کاملاً ایزوله نیاز دارند، انتقال تولید داده‌های آزمایشی به محیط‌های محلی راهکاری کلیدی برای حفظ امنیت داده‌هاست.
چالش داده‌ها در قالب اعداد
مقیاس این چالش عظیم است. طبق پیش‌بینی‌های IDC، داده‌های بدون ساختار در چین طی پنج سال آینده با نرخ رشد سالانه مرکب (CAGR) ۳۰ تا ۴۰ درصد، از ۵۱ زتابایت به ۱۲۹ زتابایت می‌رسد. در همین حال، بررسی‌های جداگانه‌ی IDC نشان می‌دهد کارکنان دانشی حدود ۲.۵ ساعت از روز خود — یعنی تقریباً ۳۰ درصد زمان کاری — را صرف شکار اطلاعات می‌کنند. برای وکلا، این یعنی زمان آن‌ها به‌جای دفاع در دادگاه و litigating، صرف گشتن در پوشه‌ها و جست‌وجوی دستی می‌شود.
علاوه بر این، ریسک شکست با داده‌های نشت اطلاعات quantified شده است. گزارش سال ۲۰۲۵ شرکت IBM درباره هزینه نشت داده‌ها نشان داد که اطلاعات سرقت‌شده شامل داده‌های شناسایی شخصی (PII) مشتریان (۵۳٪)، داده‌های شناسایی شخصی کارکنان (۳۷٪) و مالکیت معنوی یا IP (۳۳٪) بوده است. اسناد حقوقی دقیقاً سرشار از همین دسته‌بندی‌ها هستند و هر خط لوله‌ای که ساخته شود، در واقع یک پایگاه‌داده قابل پرس‌وجو از این مواد حساس است.
مرحله اول: فشرده‌سازی محلی
پرونده‌های قضایی اغلب با PDFها، اسناد اسکن‌شده، فایل‌های OFD و رکوردهای صوتی یا تصویری پر شده‌اند که فضای ذخیره‌سازی را اشغال کرده و هزینه‌های توکن را بالا می‌برند. این راهنما استدلال می‌کند که نادیده گرفتن فشرده‌سازی یک اشتباه هزینه‌بر است؛ زیرا محتوای تصویری که توسط یک توکن‌ساز چندوجهی (Multimodal) — مدلی که هم‌زمان متن، عکس و صدا را می‌فهمد — محاسبه می‌شود، در هر فراخوانی گران است. خط لوله‌های بازیابی که صفحات اسکن‌شده را مستقیماً به مدل می‌فرستند، این صورت‌حساب گران‌قیمت را برای همیشه به ارث می‌برند.
برای حل این مشکل، یک موتور فشرده‌سازی محلی باید هشت فرمت مختلف از جمله PDF، تصاویر، ویدیو، صوت، Office، OFD و اسکن‌ها را پشتیبانی کند تا داده‌های زائد را حذف کرده و در عین حال چیدمان، مهرها، جداول و ترتیب خواندن را حفظ کند. در یک اندازه‌گیری مرجع، یک سند ۴۴۳ صفحه‌ای از نوع OFD در حدود ۱۲۴ ثانیه به‌طور کامل پردازش شد.
این رویکرد منجر به بردی مضاعف در توکن‌ها می‌شود. با فشرده‌سازی محلی محتوای تصویری، هزینه تکرارشونده برای هر پرس‌وجو در طول عمر کتابخانه به‌شدت کاهش می‌یابد. در مقایسه با GPT-4o، این روش هزینه‌های توکن را ۸۵.۹٪ کم کرد. نکته کلیدی در «محلی بودن» است؛ هر API که نیاز به آپلود فایل داشته باشد، هدف امنیتی خط لوله خصوصی را از بین می‌برد.
مرحله دوم: سانسور پیش از ایندکس‌گذاری
بسیاری از خط لوله‌های RAG از نظر ساختاری اشتباه هستند، زیرا مجوزهای سطح سند در مرحله تکه‌بندی (Chunking) — یعنی برش‌های کوچکی از متن شبیه تکه‌های کیک که مدل می‌خورد — از بین می‌روند. ذخیره‌ساز برداری عبارت «فقط تیم مالی می‌تواند این را باز کند» را به «هر کسی که پرس‌وجوی مشابهی دارد، این بخش را دریافت می‌کند» تبدیل می‌کند. اگر یک شناسه مشتری یا شماره حساب بانکی در یک تکه (Chunk) باشد، یک سؤال به‌درستی طراحی‌شده می‌تواند آن را بازیابی کند.
راهکار این است که فیلدهای حساس پیش از برداری‌سازی و ایندکس‌گذاری شناسایی و ماسک شوند، به‌جای استفاده از فیلترهای پسینی (post-hoc) که یک مرحله عقب‌تر از پرس‌وجو اجرا می‌شوند. این شناسایی نیز باید محلی باشد تا نشت داده در مسیر سرویس سانسور رخ ندهد.
- شناسایی مبتنی بر قانون: سیستم باید ساختارهای رایج مانند شماره‌های شناسایی، کارت‌های بانکی و شماره تلفن‌ها را با استفاده از مجموعه‌ای از قوانین قابل تنظیم هدف قرار دهد، زیرا ترکیب اسناد در هر سازمان متفاوت است.
- تنظیمات تخصصی صنعت: یک سیستم بالغ باید حداقل ۱۳ دسته از اطلاعات حساس، از جمله شناسه‌های مشتری، حساب‌های بانکی و جزئیات افشا نشده پرونده‌ها را شناسایی کند.
- حفظ معنا: سانسور باید فیلدهای خاص را هدف قرار دهد، نه معنای متن را. برای مثال، جمله‌ای که می‌گوید «فروشنده باید مبلغ را به حساب ۶۲۲۵ ۸۸۰۱ ۲۳۴۵ ۶۷۸۹ واریز کند» به «فروشنده باید مبلغ را به حساب [سانسور شده] واریز کند» تبدیل می‌شود.
در این مثال، تعهد پرداخت، طرف قرارداد و مهلت — یعنی هر آنچه سیستم بازیابی برای پاسخ به «مهلت پرداخت چه زمانی است» نیاز دارد — حفظ شده است. فقط بخشی که افشایش می‌تواند هفته‌ی کسی را خراب کند، حذف شده است.
توالی مهندسی
توالی سخت‌گیرانه خط لوله برای داده‌های حقوقی به این ترتیب است: دریافت سند $ \rightarrow $ تشخیص فرمت (PDF / OFD / Office / اسکن / تصویر) $ \rightarrow $ بازیابی چیدمان (تیترها، ترتیب خواندن، جداول) $ \rightarrow $ نویسه‌خوانی نوری (OCR) برای اسکن‌ها (بهبود $ \rightarrow $ تحلیل $ \rightarrow $ استخراج $ \rightarrow $ سطح اطمینان) $ \rightarrow $ پاک‌سازی (حذف سربرگ‌ها/پاورقی‌ها، اصلاح خطاهای رایج OCR) $ \rightarrow $ سانسور (شناسایی ۱۳ دسته حساس، ماسک کردن پیش از برداری‌سازی) $ \rightarrow $ فشرده‌سازی (کاهش حجم محلی با حفظ دقت چیدمان) $ \rightarrow $ تکه‌بندی معنایی $ \rightarrow $ برداری‌سازی و ایندکس‌گذاری.
تکه‌بندی باید بر اساس مرزهای معنایی باشد، نه تعداد کاراکترهای ثابت. بندهای حقوقی ساختار دارند و تکه‌ای که یک بند را از وسط می‌برد، بازیابی ضعیفی خواهد داشت. هر تکه باید به متادیتای منبع، نسخه و برچسب زمانی متصل باشد تا سیستم بازیابی بتواند نسخه معتبر (Authoritative copy) را ترجیح دهد و انسان‌ها بتوانند پاسخ‌ها را تا منبع اصلی ردیابی و حسابرسی کنند.
اثرات اقتصادی
برای یک کتابخانه ۲ ترابایتی با اسکن‌های زیاد، فشرده‌سازی با حفظ کیفیت (۶۰ تا ۸۰ درصد) حجم را به ۴۰۰ تا ۸۰۰ گیگابایت کاهش می‌دهد، پیش از آنکه کاهش حجم ذخیره‌ساز برداری و اندازه‌های کوچک‌تر دسته‌های برداری (Embedding batch sizes) محاسبه شود. اگرچه صرفه‌جویی در فضای ذخیره‌سازی قابل توجه است، اما کاهش هزینه توکن محرک اصلی است. هنگام اجرای هزاران فراخوانی هفتگی بازیابی‌افزا، کاهش هزینه‌های GPT-4o بسیار بیشتر از مزیت یک‌باره ذخیره‌سازی است.
این ادغام نیازمند بازسازی کامل نیست. مراحل فشرده‌سازی و سانسور، اسناد تمیزتر و کوچک‌تری تولید می‌کنند که به مدل‌های برداری و ذخیره‌سازهای موجود متصل می‌شوند. برای کسانی که نیاز به یکپارچگی عمیق‌تر دارند، استفاده از یک SDK فشرده‌سازی یا سرویس پروتکل زمینه مدل (MCP) روی stdio یا HTTP پیشنهاد می‌شود تا دستیاران هوش مصنوعی بتوانند فشرده‌سازی را با یک جمله فعال کنند.
اندازه‌گیری موفقیت
مهندسان پیش از تعویض مدل‌ها باید سه معیار خاص را روی نمونه‌ای از فایل‌های واقعی خود بسنجند:
- نسبت اسکن: چه بخشی از فایل‌های منبع اسکن یا PDFهای تصویری هستند؟ این عدد حجم کاری OCR و فشرده‌سازی را پیش‌بینی می‌کند.
- کیفیت تکه‌ها: چه تعداد از تکه‌های بازیابی‌شده تکراری یا نسخه‌های قدیمی هستند؟ این معیار پیش‌بینی می‌کند که آیا جست‌وجو کاربردی خواهد بود یا خیر.
- ریسک انطباق: کدام فیلدها در ایندکس باعث نگرانی افسر انطباق می‌شود؟ با جست‌وجوی الگوهای شناسایی شخصی (PII) در ایندکس، فرض کنید که مواردی را خواهید یافت.
اگر این اعداد روی یک نمونه ۱۰۰ فایلی ضعیف باشند، روی ۱۰۰ هزار فایل بدتر خواهند شد و هیچ تنظیماتی در مدل، سیستم را نجات نمی‌دهد. این رویکرد مهندسی «خسته‌کننده» و منضبط است که یک دموی جذاب را از یک سیستم تولیدی که یک دهه دوام می‌آورد، جدا می‌کند. مدل‌ها توجه‌ها را جلب می‌کنند، اما خط لوله است که پاسخ‌ها را فراهم می‌کند.
گام بعدی شما
- نسبت اسکن‌های موجود در پایگاه داده خود را محاسبه کنید تا حجم نیاز به OCR را تخمین بزنید.
- یک لیست از ۱۳ دسته داده حساس در حوزه کاری خود تهیه کرده و قوانین سانسور محلی را بر اساس آن تنظیم کنید.
- تکه‌بندی‌های فعلی خود را بررسی کنید تا مطمئن شوید بندهای حقوقی در مرزهای معنایی قطع نمی‌شوند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو