عامل هوش مصنوعی شما نیازی ندارد باهوش‌تر شود؛ بلکه باید «ایدمپوتنت» (Idempotent) باشد

بیشتر عامل‌های هوش مصنوعی در محیط عملیاتی (production) به دلیل استدلال ضعیف شکست نمی‌خورند، بلکه به دلیل خطاهای شبکه با مشکل مواجه می‌شوند.

مدل ابزار درست را انتخاب می‌کند. جزئیات درست را وارد می‌کند. و سپس، هزینه را دو بار از مشتری کسر می‌کند.

این اتفاق به این دلیل می‌افتد که عامل‌های دارای قابلیت نوشتن (write-capable)، در شبکه‌های غیرقابل اعتماد فعالیت می‌کنند.

  • درخواست‌ها با تایم‌اوت (timeout) مواجه می‌شوند.
  • اتصالات قطع می‌شوند.
  • فریم‌ورک‌ها مراحلی را که قبلاً تمام شده‌اند، دوباره امتحان (retry) می‌کنند.

در یک عامل «فقط خواندنی» (read-only)، تلاش مجدد (retry) هزینه‌ای ندارد. اما در یک عامل «دارای قابلیت نوشتن»، تلاش مجدد به معنای انجام دومین اقدام غیرقابل بازگشت است.

راه حل، «ایدمپوتنت بودن» (idempotency) است.

به این شکست رایج نگاه کنید:

  1. عامل تابعی را برای ارسال فاکتور فراخوانی می‌کند.
  2. سرویس، فاکتور را ایجاد می‌کند.
  3. قبل از اینکه پاسخ به عامل برسد، اتصال قطع می‌شود.
  4. عامل با تایم‌اوت مواجه شده و دوباره تلاش می‌کند.
  5. حالا شما دو فاکتور دارید.

یک مدل باهوش‌تر این مشکل را حل نخواهد کرد. در واقع، یک مدل باهوش‌تر ممکن است با تلاش‌های مجددِ تهاجمی‌تر، اوضاع را بدتر هم کند.

می‌توانید از سیستم‌های پرداخت مانند Stripe الگو بگیرید. آن‌ها از یک Idempotency-Key استفاده می‌کنند. سرور نتیجه اولین درخواست را ذخیره می‌کند. اگر کلاینت دوباره همان کلید را ارسال کند، سرور به جای اجرای مجدد عملیات، همان نتیجه ذخیره‌شده را بازمی‌گرداند.

برای یک عامل هوش مصنوعی، شما باید این کلید را از «قصد» (intent) استخراج کنید.

از شناسه‌های (ID) تصادفی استفاده نکنید. از هشِ (hash) نام ابزار و پارامترهای ثابت آن استفاده کنید.

مثال:

  • ابزار: charge_customer
  • پارامترها: {customer_id: 42, amount: 500}
  • کلید: hash(tool + params)

اگر عامل دقیقاً همان عملیات شارژ را دوباره امتحان کند، کلید ثابت می‌ماند. سیستم آن را شناسایی کرده و از شارژ تکراری جلوگیری می‌کند.

یک نکته احتیاطی: کیفیت کلید شما به میزان دقت تعریف شما از یک «عمل واحد» بستگی دارد.

  • اگر یک برچسب زمانی (timestamp) را در هش خود بگنجانید، هر تلاش مجدد کلید جدیدی دریافت می‌کند و محافظت شما از کار می‌افتد.
  • اگر بدنه پیامی را که توسط یک LLM نوشته شده در هش بگنجانید، ممکن است مدل حتی یک کلمه را تغییر دهد. این کار باعث ایجاد یک کلید جدید و یک عملیات تکراری می‌شود.

همیشه بر اساس داده‌های ثابت مانند شناسه‌های مشتری یا شناسه‌های فاکتور کلیدسازی کنید. از گنجاندن هر چیزی که ممکن است مدل تغییر دهد، خودداری کنید.

از تلاش برای رفع مشکل قابلیت اطمینان عامل با پرامپت‌های بهتر دست بردارید.

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

Source: https://dev.to/gs_sanjana_3e822112e14f8/your-ai-agent-doesnt-need-to-be-smarter-it-needs-to-be-idempotent-2736

Optional learning community: https://t.me/GyaanSetuAi