نيهان فراتك
نيهان فراتكdecision intelligence
[TRACE_ID: NFT-XR1nb]
۱۴۰۳/۰۱/۲۰

فراتر از جستجو: معماری RAG در خدمت حقوق

مسئله اصلی: توهم‌زایی در حوزه‌ای که خطا قابل تحمل نیست

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

RAG چگونه این مشکل را حل می‌کند

معماری RAG (Retrieval-Augmented Generation) پاسخ‌دهی را به دو مرحله تقسیم می‌کند:

مرحله اول — بازیابی: پرسش کاربر به یک بردار معنایی تبدیل می‌شود و مرتبط‌ترین بخش‌های اسناد از پایگاه دانش استخراج می‌شوند.

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

چالش‌های فنی که ساده نیستند

چانک‌بندی اسناد حقوقی

متون حقوقی ساختار ویژه‌ای دارند: ماده، تبصره، بند، ارجاعات متقابل. تقسیم ساده بر اساس تعداد کلمات باعث از دست رفتن زمینه می‌شود. ما از چانک‌بندی معناـمحور استفاده می‌کنیم که مرزهای منطقی سند را رعایت می‌کند.

جستجوی ترکیبی

جستجوی معنایی به‌تنهایی کافی نیست. وقتی کاربر شماره ماده‌ای را ذکر می‌کند، جستجوی کلیدواژه‌ای دقیق‌تر است. ما ترکیب وزن‌دار جستجوی برداری و جستجوی واژگانی (BM25) را به‌کار می‌بریم.

ارجاع‌دهی دقیق

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

دفتریارچه: پیاده‌سازی عملی این معماری

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

درس اصلی

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