به یک LLM بپرسید «این گزارش آزمایش نگران‌کننده است؟» یا «این بند قرارداد به نفع من است؟» و جوابی روان، منظم و کاملاً غیرقابل‌حسابرسی می‌گیرید. در پرسش‌های عادی این فقط آزاردهنده است؛ در بالین بیمار یا اتاق دادگاه، مسئله‌ی حقوقی و ایمنی است. تصمیم‌های این دامنه‌ها دو ویژگی دارند: باید تکرارپذیر باشند — دو کارشناس با داده‌ی یکسان باید به یک نتیجه برسند — و باید قابل‌توضیح باشند — مشخص باشد کدام قاعده به کدام شاهد تکیه کرده. LLM تنها، هیچ‌کدام را تضمین نمی‌کند. اما ترکیبش با فناوری قدیمی‌تر — سیستم‌های مبتنی بر قاعده — دقیقاً همین دو چیز را می‌دهد.
چرا LLM تنها کافی نیست؟
سه شکاف مشخص: عدم ثبات — همان سند را دوباره بدهید، ممکن است نتیجه‌ی کمی متفاوت بگیرید؛ تصمیم بالینی که جابه‌جا شود بی‌اعتبار است. توهم‌زایی — مدل ممکن است معیاری را نقل کند که وجود ندارد یا شرطی را از جایی دیگر بیاورد. و عدم شفافیت — توضیحِ مدل درباره‌ی استدلالش، بازسازیِ روانِ متن است نه گزارش مکانیزم واقعی؛ حسابرسی‌پذیر نیست. نکته‌ی منصفانه: LLM در چیزی که واقعاً انجام می‌دهد فوق‌العاده است — فهم زبان نامنظم، خواندن سند شلوغ، تبدیل پرونده‌ی پیچیده به داده‌ی مرتب. مشکل جایی است که از او «حکم» بخواهیم.
تقسیم کار: مدل ترجمه می‌کند، قاعده تصمیم می‌گیرد
معماری درست مرز روشنی دارد. سمت LLM — استخراج: سند را می‌خواند و حقایق را به شکل ساخت‌یافته بیرون می‌کشد: سن، فشار خون، دوز دارو، تاریخ امضا، مبلغ خسارت. خروجی با قالب JSON تعریف‌شده گرفته می‌شود و هر فیلد به محل دقیقش در سند ارجاع دارد. سمت موتور قواعد — تصمیم: قواعد مدون سازمان — پروتکل‌های بالینی، مقررات، شرط‌های قراردادی — به شکل صریح و قابل‌بازبینی نوشته شده‌اند: «اگر A و B آنگاه C با اولویت X». موتور قواعد روی حقایقِ استخراج‌شده اجرا می‌شود و نتیجه را با شماره‌ی قاعده‌های فعال‌شده می‌دهد. تصمیم دیگر از «احساس» مدل نیامده؛ از منطقی آمده که می‌شود خواندش، تستش کرد و می‌شود نسخه‌بندیش کرد.
این مرز یک مزیت پنهان هم دارد: قواعد کسب‌وکار باقی می‌مانند، مدل عوض می‌شود. وقتی مدل زبانی جدیدتری آمد، فقط لایه‌ی استخراج را ارتقا می‌دهید و بقیه‌ی سیستم دست‌نخورده است — چون قرارداد بین دو طرف، فقط JSON استخراجی است.
ثبت زنجیره‌ی دلیل
هر تصمیم خروجی باید سه چیز همراهش داشته باشد: شواهد — هر فیلد استخراج‌شده با نقل‌قول و محلش در سند؛ اگر مدل گفته «فشار خون بالا»، دقیقاً کدام جمله‌ی سند این را گفته؟ قواعد فعال — کدام قاعده‌ها شعله ور شدند و با چه مقادیری؛ و مسیر جایگزین — کدام قاعده‌ها مرزی بودند و نزدیک بود فعال شوند. این بسته‌ی دلیل همان چیزی است که کارشناس انسانی برای بازبینی لازم دارد و همان چیزی است که در ممیزی و اختلاف، سیستم شما را نجات می‌دهد. بدون این بسته، فقط یک جعبه‌ی سیاه دیگر دارید — سریع‌تر، اما همان.
قاعده تصمیم می‌گیرد، مدل ترجمه می‌کند، انسان امضا می‌زند — هر کدام همان‌جا که تخصص دارند.
انسان در حلقه و مرز مسئولیت
در این دامنه‌ها، سیستم پشتیبان تصمیم است، نه تصمیم‌گیر: خروجی، پیشنهاد اولویت‌بندی با دلیل کامل است و امضای نهایی با کارشناس است. دو پیامد طراحی دارد. اول، رابط کاربری باید دورِ دلیل ساخته شود — کارشناس باید بتواند هر فیلد استخراج‌شده را با یک کلیک به سند برگرداند و تأیید یا اصلاح کند؛ اصلاحاتش هم داده‌ی ارزیابی نسخه‌های بعدی می‌شود. دوم، امنیت سند: متن اسناد بیرونی — گزارش‌های سایر مراکز، اسناد طرف مقابل — می‌تواند حاوی دستور مخرب برای مدل باشد؛ این حفره را در تزریق پرامپت بررسی کرده‌ایم و در این معماری یعنی: استخراج از متن دشمن باید ایزوله و سخت‌گیرانه‌تر انجام شود، چون خروجی خرابِ استخراج، مستقیم به موتور قواعد می‌رسد.
جمع‌بندی
فرمول پشتیبان تصمیم قابل‌تفسیر: LLM برای فهم زبان و استخراج ساخت‌یافته‌ی حقایق با ارجاع به سند، موتور قواعد برای تصمیم و اولویت‌بندی با قواعد مدون، بسته‌ی دلیل کامل برای هر خروجی، و کارشناس انسانی که امضا می‌کند و اصلاحاتش به ارزیابی برمی‌گردد. شروع عملی: یکی از گردش‌کارهای قاعده‌مند موجودتان را بردارید، ده قاعده‌ی پرترددش را صریح بنویسید و لایه‌ی استخراج را با ۵۰ سند واقعی تست کنید — قبل از هر چیز، کیفیت استخراج را بسنجید، چون همه‌چیز روی آن سوار است. قراردادهای زمینه‌ی مدل را در مهندسی زمینه ببینید و برای تست روی اسناد واقعی خودتان، یک حساب بسازید.