«جلوگیری از توهمات عملیاتی»؛ هدف از پیاده‌سازی اعتبارسنجی سخت‌گیرانه در LLM

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

بر اساس مستندات فنی یک بازارچه گیمینگ که در ۱۶ اوت ۲۰۲۶ این سیستم را پیاده کرده است، هزینهٔ یک تصمیم اشتباهِ خودکار، به‌مراتب بیشتر از هزینهٔ استخدام یک بازبین انسانی است. این اتفاق اغلب به این دلیل رخ می‌دهد که یک مدل زبانی بزرگ (LLM) ممکن است یک شیء JSON معتبر برگرداند که حاوی منطق متناقض است؛ مثلاً فاکتوری را به عنوان «مجاز» علامت‌گذاری کند اما یک کد دلیل «مسدود شده» را ذکر نماید. برای بازارچه‌ای که فاکتورهای تأمین‌کنندگان را به عنوان آپلود کاربر می‌پذیرد، صحت خروجی ساختاریافته تنها معیار تعیین‌کننده است: یک برچسب ارزان‌قیمت هیچ ارزشی ندارد اگر شناسهٔ فاکتور، نام تأمین‌کننده، ارز یا دلیل نظارتی در فیلد اشتباهی قرار گرفته باشد.

بسیاری از توسعه‌دهندگان نظارت بر محتوا را یک انتخاب دوتایی می‌بینند: یا اتوماسیون کامل یا بررسی انسانی کامل. این رویکرد در مقیاس بالا شکست می‌خورد چون «منطقه خاکستریِ» خطاهای ساختاری را نادیده می‌گیرد. وقتی یک مدل نمی‌تواند از یک طرح‌واره (Schema) پیروی کند، این فقط یک نقص فنی نیست، بلکه ریسکی برای یکپارچگی داده‌هاست که اگر اجازه عبور یابد، می‌تواند سیستم‌های حسابداری پایین‌دستی را فاسد کند. برای حل این مشکل، یک معماری دو مرحله‌ای، لایهٔ پذیرش را از لایهٔ طبقه‌بندی جدا می‌کند. مرحله اول از قوانین قطعی (Deterministic Rules) برای رد کردن داده‌های تکراری دقیق یا پاکت‌های دادهٔ ناقص (Malformed Envelopes) استفاده می‌کند، پیش از آنکه این داده‌ها هرگز به یک مدل گران‌قیمت برسند. این استراتژی که در واقع نوعی پیاده‌سازی از گیت‌های کیفی قطعی برای توقف پس‌روندهای فنی است، تضمین می‌کند که هزینه توکن‌ها فقط برای محتوایی هزینه شود که واقعاً به تحلیل معنایی نیاز دارد.

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

گردش‌کار مبتنی بر گیتِ طرح‌واره

پس از عبور فایل از فیلتر اولیه، وارد خط لولهٔ طبقه‌بندی دسته‌ای (Batch Classification) می‌شود. به‌جای انتظار برای یک پاسخ آنی (Real-time)، سیستم یک مرجع منبع و یک هش (Hash) ذخیره می‌کند و درخواست پذیرش فوراً بازگردانده می‌شود. سپس کارکنان (Workers) دسته‌هایی را بر اساس محدودیت‌های سنی (زمان ورود) و اندازه تشکیل می‌دهند و هویت هر آیتم را حفظ می‌کنند، حتی اگر درخواست مدل چندین آیتم را با هم گروه‌بندی کند. این جداسازی (Decoupling) مانع از آن می‌شود که تأخیر کاربر به عملکرد مدل گره بخورد و به سیستم اجازه می‌دهد به‌جای کمترین قیمت توکن تبلیغ‌شده، روی تصمیمات معتبر و قابل ردیابی بهینه شود.

دسته‌بندی (Batching) یک انتخاب زمان‌بندی است، نه مکانیزم صحت. قوانین اعتبارسنجی و ارجاع به انسان باید برای هر آیتم، صرف‌نظر از نحوه دسته‌بندی، یکسان اعمال شوند. برای تضمین ردیابی، سیستم چهار اصل سخت‌گیرانه (Invariants) را اعمال می‌کند:

• همسویی با طرح‌واره: هر نتیجهٔ پذیرفته‌شده باید دقیقاً با یک نسخهٔ پین‌شده از طرح‌واره و مجموعه‌ای بسته از برچسب‌ها مطابقت داشته باشد.
• تبار تغییرناپذیر: هر مسدودسازی یا تأیید خودکار باید به هش منبع تغییرناپذیر، نسخهٔ پرامپت، نسخهٔ طبقه‌بندی‌کننده و شناسهٔ تصمیم اشاره کند.
• تکرارناپذیری (Idempotency): یک تلاش مجدد (Retry) نباید منجر به ایجاد دومین اقدام نظارتی یا دومین تیکت بررسی شود. با پیروی از روح استاندارد RFC 9110، سیستم کار را از طریق یک هش محتوای پایدار شناسایی کرده و تصمیمات را تحت یک کلید تکرارناپذیری ثبت می‌کند تا انتقال به وضعیت نهایی مشروط باشد.
• پرهیز از حدس‌زنی: فیلدهای خالی، برچسب‌های ناشناخته، دلایل متناقض و استخراج‌های نامطمئن از فاکتور باید مستقیماً به صف بررسی انسانی هدایت شوند؛ این موارد هرگز به مقادیر حدسی تبدیل نمی‌شوند.

مدیریت صف بررسی انسانی

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

• ابهام در سیاست‌ها: نیاز به یک متخصص تطبیق (Compliance Specialist) برای تفسیر مرز قوانین.
• خروجی ساختاریافتهٔ نامعتبر: یک شکست قراردادی که در آن مدل LLM نتوانسته از گیت طرح‌واره عبور کند.
• تضاد در استخراج: یک بازبین عملیات داده تضادهای فیلدهای فاکتور را حل می‌کند (مثلاً ارز USD است اما مبلغ کل فاکتور وجود ندارد).
• نمونه‌برداری دستی: ممیزی‌های روتین برای اطمینان از دقت اتوماسیون.

برای جلوگیری از «طوفان‌های تلاش مجدد» (Retry Storms)، سیستم کلاس‌های خطا را به دسته‌های مجزا تقسیم می‌کند. خطاهای انتقال (Transport Failures) باعث تلاش مجدد با یک سقف مشخص و تأخیر متغیر (Jitter) می‌شوند. خطاهای طرح‌واره، پاسخ را قرنطینه کرده و یک مورد بررسی ایجاد می‌کنند. ابهام در سیاست‌ها باعث ایجاد یک بررسی عادی می‌شود و اتمام ظرفیت، فشار معکوس (Backpressure) را در مرحله پذیرش اعمال می‌کند. ترکیب این حالت‌ها در یک دسته‌بندی کلی «شکست»، پیش‌بینی هزینه‌ها را غیرممکن می‌کند.

برای محافظت بیشتر از سیستم، توضیحات آزاد (Free-form) مدل به عنوان رکورد اصلی بازبین نمایش داده نمی‌شود. در عوض، سیستم یک کد دلیل محدود شده و در صورت اجازه سیاست‌ها، یک گزیده کوتاه از شواهد متصل به آفست‌های منبع را ذخیره می‌کند. این کار مانع از آن می‌شود که یک یادداشت تأمین‌کننده حاوی دستورات، در رابط کاربری بررسی به عنوان یک فرمان عملیاتی تفسیر شود.

مدل‌سازی هزینه و شمارش توکن‌ها

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

model_cost = input_tokens * input_rate + output_tokens * output_rate
review_cost = reviewed_items * average_review_minutes * loaded_reviewer_rate_per_minute
total_cost = model_cost + review_cost + queue_infrastructure_cost

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

در نمونه‌ای با ۱۰,۰۰۰ آپلود، توصیه می‌شود داده‌ها بر اساس زبان، نوع فایل، قالب تأمین‌کننده و برچسب سیاست تقسیم‌بندی شوند. این کار «شاخه گران‌قیمت» را آشکار می‌کند؛ واقعیتی که نشان می‌دهد تغییر کوچکی در نرخ نتایج مبهم یا نامعتبر می‌تواند بودجهٔ بررسی انسانی را به‌صورت نمایی افزایش دهد. ظرفیت بازبین باید بر اساس معادله زیر مدیریت شود:
required_reviewer_minutes = arrival_count * review_rate * average_review_minutes
تخفیف‌های دسته‌بندی نمی‌توانند صفی را نجات دهند که در آن نرخ ورود داده‌ها از ظرفیت سرویس‌دهی بیشتر باشد.

پیاده‌سازی در پایتون

در یک پیاده‌سازی عملی با پایتون، رابط Classifier برای حفظ انعطاف‌پذیری در برابر APIهای تجاری مختلف طراحی می‌شود. منطق برنامه از یک dataclass برای اجبار به رعایت نوع داده‌ها استفاده می‌کند تا تضمین شود برای مبالغ از Decimal و برای تصمیمات از Literal استفاده می‌شود.

from dataclasses import dataclass
from decimal import Decimal
from hashlib import sha256
from typing import Any, Literal, Protocol

Decision = Literal["allow", "block", "review"]
REASONS = {"safe", "prohibited_content", "ambiguous", "invalid_invoice"}

@dataclass(frozen=True)
class ModerationResult:
    decision: Decision
    reason: str
    invoice_id: str | None
    supplier: str | None
    currency: str | None
    total: Decimal | None

class Classifier(Protocol):
    def classify(self, payload: bytes, schema_version: str) -> dict[str, Any]: ...

def parse_result(raw: dict[str, Any]) -> ModerationResult:
    required = {"decision", "reason", "invoice_id", "supplier", "currency", "total"}
    if set(raw) != required:
        raise ValueError("result keys do not match the pinned schema")
    if raw["decision"] not in {"allow", "block", "review"}:
        raise ValueError("unknown decision")
    if raw["reason"] not in REASONS:
        raise ValueError("unknown reason")
    
    total = Decimal(str(raw["total"])) if raw["total"] is not None else None
    result = ModerationResult(
        decision=raw["decision"], reason=raw["reason"], 
        invoice_id=raw["invoice_id"], supplier=raw["supplier"], 
        currency=raw["currency"], total=total,
    )
    
    if result.decision == "allow" and (not result.invoice_id or not result.currency or total is None):
        raise ValueError("an allowed invoice requires complete accounting fields")
    if result.decision == "allow" and result.reason != "safe":
        raise ValueError("allow requires the safe reason")
    return result

def classify_for_queue(
    content: bytes, policy_version: str, schema_version: str, classifier: Classifier
) -> tuple[str, ModerationResult | None, str]:
    item_key = sha256(policy_version.encode() + b":" + content).hexdigest()
    try:
        result = parse_result(classifier.classify(content, schema_version))
    except (ValueError, ArithmeticError):
        return item_key, None, "invalid_output_review"
    
    if result.decision == "review":
        return item_key, result, "policy_review"
    return item_key, result, "automated_decision"

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

تحلیل: تغییر رویکرد از قیمت به صحت

این معماری معیار اصلی عملیات هوش مصنوعی را از «هزینه هر توکن» به «هزینه هر تصمیم درست» تغییر می‌دهد. با تبدیل LLM به یک «موتور پیشنهاددهنده» به‌جای یک «مرجع نهایی»، سیستم ریسک «شکست‌های خاموش» را حذف می‌کند؛ جایی که مدل با اعتماد به نفس کامل، پاسخی غلط را در یک پاکت JSON کاملاً فرمت‌شده ارائه می‌دهد. این رویکرد با اولویت‌بندی پایداری در استقرار مدل‌ها همسو است تا ریسک مدل‌های معیوب در محیط عملیاتی کاهش یابد.

برای تعیین بهترین گزینه عملیاتی، توازن‌های (Trade-offs) زیر اعمال می‌شوند:

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

برای این مورد فاکتورهای گیمینگ، انتخاب بهینه «قوانین پیش از LLM» و سپس «اعتبارسنجی سخت‌گیرانه طرح‌واره» است. این رویکرد میان‌برِ استفاده از یک تجزیه‌کننده JSON سهل‌گیر را به عنوان تست صحت رد می‌کند، زیرا خروجی قابل تجزیه فقط نحو (Syntax) را ثابت می‌کند، نه معنا (Meaning) را. یک مدل با دقت بالا که نرخ بررسی انسانی را ۵٪ کاهش دهد، می‌تواند به‌مراتب ارزان‌تر از یک مدل کم‌هزینه باشد که صف بررسی را با نتایج مبهم پر می‌کند.

در گام بعدی، توسعه‌دهندگان باید خط لوله‌های نظارتی فعلی خود را با یک نمونه ممیزی‌شده (Labeled Audit Sample) ارزیابی کنند تا شناسایی کنند چه تعداد از تصمیمات «خودکار»، در واقع خطاهایی هستند که از صف عبور کرده‌اند. اتوماسیون باید دامنه خود را تکه‌تکه و برای هر بخش از سیاست‌ها، با استفاده از مجموعه‌های ارزیابی برچسب‌دار برای تعیین آستانه‌ها در دسته‌ها، زبان‌ها و قالب‌های خاص گسترش دهد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما دربارهٔ تراشه‌های Blackwell مراجعه کنید.