عامل هوش مصنوعی شما در صورت از دست رفتن پاسخ، مبلغ را دو بار کسر میکند
اگر عامل هوش مصنوعی شما ابزاری را برای کسر وجه از کارت فراخوانی کند و شبکه پاسخ را از دست بدهد، عامل شما به شکلی نامناسب عمل میکند. بدون اینکه متوجه شود، مبلغ را دو بار از مشتری کسر میکند.
پول قبلاً جابهجا شده است. عامل هرگز پاسخ "ok" را نشنیده است. او همان کاری را انجام میدهد که هر حلقه تلاش مجدد (retry loop) انجام میدهد: دوباره تلاش میکند. او از همان پرامپت و همان آرگومانها استفاده میکند. این امر باعث شارژ مجدد میشود.
یک تلاش مجدد (retry)، یک رویداد شبکه نیست؛ بلکه تصمیمی است در مورد یک اثر جانبی (side effect) که ممکن است قبلاً اتفاق افتاده باشد.
ابزارهای استاندارد تلاش مجدد مانند backoff و jitter، تلاشها را «مؤدبانه» میکنند، اما هیچ کاری برای جلوگیری از کسر مبلغ دوگانه انجام نمیدهند.
شما به یک دفتر کل همارزی (idempotency ledger) نیاز دارید. این دفتر از یک کلید منحصربهفرد استفاده میکند تا اطمینان حاصل شود که یک عمل حداکثر یک بار انجام میشود.
فراخوانی یک ابزار به دو روش شکست میخورد:
- درخواست از دست رفته است. عمل هرگز انجام نشده است. تلاش مجدد ایمن است.
- پاسخ از دست رفته است. عمل قبلاً انجام شده است. تلاش مجدد باعث ایجاد مورد تکراری میشود.
برای یک عامل، این دو حالت یکسان به نظر میرسند. هر دو شبیه به اتمام زمان (timeout) یا قطع اتصال هستند.
اگر ابزاری دارای اثر جانبی مانند پرداخت، ارسال ایمیل یا بازپرداخت (refund) باشد، نمیتوانید به تلاشهای مجدد ساده تکیه کنید. شما باید از یک کلید همارزی (idempotency key) استفاده کنید.
چگونه این مشکل را حل کنیم:
- ابزارهای خود را برچسبگذاری کنید. مشخص کنید کدام ابزارها دارای اثرات جانبی برگشتناپذیر هستند.
- از کلیدهای قطعی (deterministic keys) استفاده کنید. یک کلید پایدار بر اساس شناسه گردش کار (workflow ID)، مرحله و آرگومانها ایجاد کنید. این کار را قبل از اینکه LLM بتواند آرگومانها را تغییر دهد، انجام دهید.
- از کلیدهای ارائهدهنده استفاده کنید. اگر از Stripe استفاده میکنید، کلید همارزی آنها را ارسال کنید. ارائهدهنده باید تکرار را تشخیص دهد تا از شارژ مجدد جلوگیری کند.
- برای ابزارهای خودتان یک دفتر کل بسازید. برای اثرات جانبی که تحت کنترل خودتان است، از یک جدول پایگاه داده با محدودیت منحصربهفرد (unique constraint) استفاده کنید. این کار تضمین میکند که سیستم شما قبل از تلاش مجدد، نتیجه را ثبت کند.
«حداقل یک بار» (at-least-once) را با «دقیقاً یک بار» (exactly-once) اشتباه نگیرید. در سیستمهای توزیعشده، شما با ترکیب تحویل «حداکثر یک بار» (at-most-once) با تلاشهای مجدد «حداقل یک بار» و یک دفتر کل حذف تکرار (deduplication ledger)، به حالت «دقیقاً یک بار» دست مییابید.
عملیات نوشتن (write) را مانند عملیات خواندن (read) مدیریت نکنید. تلاش مجدد برای یک خواندن هزینهای ندارد، اما تلاش مجدد برای یک نوشتن هزینه دارد.
Source: https://dev.to/0012303/your-ai-agent-will-double-charge-on-a-lost-response-5eed
Optional learning community: https://t.me/GyaanSetuAi