دادن دسترسی مستقیم یک مدل زبانی به درگاه پرداخت، دستورالعمل دقیقی برای یک فاجعه مالی است. تصور کنید یک برنامهنویس بخواهد سیستمی بسازد که پرداختهای ناموفق را بازیابی کند، اما مدل به دلیل یک توهم ساده، مبلغ را دو بار از حساب مشتری کسر کند. این ریسکها یادآور اشتباهات هزینهبر در بازپرداختهاست که نشان میدهد حتی خطاهای کوچک در مهندسی پرامپت میتواند پیامدهای مالی جدی داشته باشد.
برای حل این چالش، یک توسعهدهنده در جریان رقابت Razorpay AI Buildathon 2026، عاملی به نام REVA (عامل بازیابی درآمد ریزرپِی) را طراحی کرد. هدف این ابزار بازیابی پرداختهای شکستخورده بدون ریسک ایجاد تراکنشهای تکراری است. همانطور که در تحلیل قبلی ما دربارهی چرخش رباتهای معاملاتی به سمت ارکستراسیون مدلهای زبانی اشاره کردیم، اکنون صنعت با تنشی میان «خودمختاری هوش مصنوعی» و «ایمنی مالی» روبروست.
در سامانههای پرداخت، شکست یک تراکنش همیشه به معنای ضرر نیست؛ گاهی یک اختلال موقت بانکی یا انقضای کارت دلیل این اتفاق است. اما تلاش کورکورانه برای تکرار این پرداختها معمولاً به خطاهای بحرانی منجر میشود. به نقل از گزارش وبسایت dev.to در تاریخ ۵ سپتامبر ۲۰۲۶، توسعهدهنده REVA دو رویکرد رایج صنعت را رد کرد:
- تلاشهای کورکورانه (Blind Retries): زمانبندیهای ثابتی که دلیل شکست را نادیده میگیرند و ریسک شارژ تکراری را افزایش میدهند.
- قوانین ایستا (Static Rules): زنجیرههای طولانی از دستورات if/else که برای مدیریت زمینههای پیچیده بیش از حد سختگیرانه هستند.
سامانه REVA از یک معماری ترکیبی استفاده میکند. در اینجا مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — به عنوان موتور استدلال عمل میکند تا بفهمد چرا پرداخت شکست خورده است. مدل تشخیص میدهد که آیا مشکل یک خطای موقت بانکی است یا انقضای کارت، اما هرگز نمیتواند دستور پرداخت را صادر کند. در عوض، استدلال هوش مصنوعی به یک سیستم قطعی (Deterministic) منتقل میشود که پیش از هر اقدامی، سیاستهای سختگیرانه مالی را اجرا میکند.
این تغییر رویکرد به این معناست که توسعهدهندگان باید دست از نگاه به مدلهای زبانی به عنوان «مجریان خودمختار» بردارند و آنها را به عنوان «طبقهبندیکنندههای پیشرفته» ببینند. با جداسازی مرحله تصمیم از مرحله اجرا، شرکتها میتوانند از درک زمینهای هوش مصنوعی بهره ببرند، بدون اینکه پیشبینیپذیری مورد نیاز برای حسابرسی و انطباق قانونی را فدا کنند. این رویکرد بهینه در مدیریت منابع ضروری است، چرا که بخش کوچکی از اجرای نادرست عاملهای هوش مصنوعی میتواند بخش بزرگی از هزینههای عملیاتی را به خود اختصاص دهد.
گام بعدی شما
- اگر در حال ساخت عاملهای مالی هستید، برای خروجیهای مدل خود «پوششهای قطعی» (Deterministic Wrappers) طراحی کنید.
- نقاط انتقال کنترل از هوش مصنوعی به اپراتور انسانی را برای تراکنشهای با ارزش بالا تعریف کنید.
- مدلهای زبانی را صرفاً برای تحلیل علت خطا (Root Cause Analysis) به کار ببرید، نه برای اجرای دستورات مالی.
اما چالش بعدی، تعیین دقیق لحظهای است که یک تراکنش شکستخورده باید حتماً توسط انسان بررسی شود؛ موضوعی که در گزارشهای آینده درباره مدیریت استثنائات در عاملهای هوش مصنوعی بررسی خواهیم کرد.
گفتگو