‏دیتای تازه، شرط بقای ایجنت‌های هوش مصنوعی

نویسنده‌ی این مقاله که یکی از معماران AWS ـه، می‌گه یه فرض پنهون تو خیلی از معماری‌های AI هست: این‌که دیتایی که ایجنت می‌خونه همون وضعیت لحظه‌ایه. اما تو سیستم‌های توزیع‌شده و replication بین ریجن‌ها این فرض همیشه درست نیست و می‌تونه کل زنجیره‌ی استدلال ایجنت رو خراب کنه.

نویسنده یه مثال می‌زنه: یه ایجنت مدیریت انبار، موجودی رو تو us-east-1 به ۵۰۰ واحد آپدیت می‌کنه، ولی به خاطر ۲ ثانیه تأخیر تو replication، یه ایجنت دیگه تو Mumbai هنوز مقدار قدیمی (صفر) رو می‌بینه و اشتباهی اعلام می‌کنه که موجودی تموم شده. بهش می‌گه «بدهی توهم» (hallucination debt)؛ یعنی وقتی یه تصمیم غلط دوباره تو دیتابیس نوشته می‌شه و خودش تبدیل به یه واقعیت غلط برای خوندن‌های بعدی می‌شه.

برای دیتای حساس مثل مجوزهای کاربر یا رکوردهای مالی، پیشنهاد اینه از سازگاری قوی استفاده بشه: Amazon Aurora Global Database با فعال کردن Global Write Forwarding و سطح GLOBAL یا SESSION، یا Aurora DSQL که سازگاری قوی و همزمان بین چند ریجن رو به‌صورت بومی می‌ده.

برای حافظه‌ی مکالمه و state سشن کاربر که نیاز به مقیاس بالا و تأخیر کم داره، DynamoDB Global Tables با تکنیک Conditional Writes پیشنهاد می‌شه؛ اگه دیتا از زمان خوندن عوض شده باشه، دیتابیس خطای ConditionalCheckFailedException می‌ده تا ایجنت مجبور بشه دوباره بخونه، نه این‌که کار ایجنت دیگه رو بی‌سروصدا رونویسی کنه.

برای جریان‌های داده‌ی پرسرعت مثل تله‌متری IoT یا آنالیز لاگ، Amazon Keyspaces (سازگار با Cassandra) با تنظیم سطح خوندن روی LOCAL_QUORUM به‌جای LOCAL_ONE پیشنهاد می‌شه تا ایجنت هیچ اسپایک مهمی رو از دست نده، بدون این‌که سرعت ingestion افت کنه.

نکات کلیدی:

• Amazon Aurora DSQL سازگاری قوی و همزمان بین چند ریجن رو به‌صورت بومی پشتیبانی می‌کنه.
• DynamoDB Global Tables با Conditional Writes از رونویسی ناخواسته‌ی تصمیم‌های موازی جلوگیری می‌کنه.
• Amazon Keyspaces با سطح خوندن LOCAL_QUORUM جریان‌های پرسرعت تله‌متری رو بدون از دست دادن اسپایک پردازش می‌کنه.
• انتخاب الگوی درست باید بر اساس حساسیت دیتا (مالی/امنیتی در برابر session/تله‌متری) انجام بشه، نه یه راه‌حل واحد برای همه.