چگونه عوامل هوش مصنوعی تولیدی، استثنائات را ساعت سه صبح بدون بیدار کردن کسی مدیریت می‌کنند؟

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

اینکه چگونه عوامل هوش مصنوعی تولیدی استثنائات را ساعت سه صبح بدون بیدار کردن کسی مدیریت می‌کنند، بخشی از زیرساخت‌های مامورانه است که در دموهای محصول نشان داده نمی‌شود، اما تفاوت بین یک استقرار که ربع اول را پشت سر می‌گذارد و یکی که بی‌سروصدا قطع می‌شود، در همین است. مدیریت استثنائات یک قابلیت اضافی نیست. این آن معماری است که تعیین می‌کند آیا عوامل واقعاً می‌توانند بدون نظارت مستمر انسانی کار کنند یا خیر، که هدف اصلی از قرار دادن آنها در مرحله تولید است.

آناتومی یک استثنای تولیدی

یک استثنا هر چیزی است که از مسیر اجرای مطمئن عامل منحرف می‌شود. نتایج استقرار عامل هوش مصنوعی تولیدی به این بستگی دارد که سیستم چقدر خوب این لحظات را مدیریت می‌کند، زیرا اجرای مطمئن نیمی از کار آسان است. نیمه دشوار آن چیزی است که وقتی سندی می‌رسد که با هیچ الگوی شناخته شده‌ای مطابقت ندارد، وقتی یک API پاسخ نادرست می‌دهد، وقتی یک تکه داده در لبه یک آستانه تصمیم‌گیری قرار می‌گیرد، وقتی یک سیستم شخص ثالث به طور موقت در دسترس نیست، یا وقتی یک قانون نظارتی به شکلی تغییر کرده که عامل برای آن آموزش ندیده است، اتفاق می‌افتد.

هر عامل تولیدی باید پاسخ چهار سوال را به صورت بی‌درنگ بداند. چه اتفاقی افتاد. آیا موقعیت قابل بازیابی در محدوده اختیارات تصمیم‌گیری خود عامل است یا خیر. آیا موقعیت به انسان نیاز دارد یا خیر، و اگر بله، کدام انسان، با چه زمینه‌ای، و در چه بازه زمانی. آیا موقعیت مستلزم این است که عامل کل گردش کاری که بخشی از آن است را متوقف کند، یا می‌تواند عملیات پایین‌دستی را ادامه دهد در حالی که استثنا در یک صف قرار دارد؟

عواملی که در ساعت 3 صبح به خوبی کار می‌کنند، آنهایی هستند که این چهار سوال قبل از استقرار پاسخ داده شده‌اند، نه در حین آن. این معماری مدیریت استثنائات است و بخشی از زیرساخت مامور است که به بیشترین نظم مهندسی نیاز دارد زیرا بیشتر کار تا زمانی که چیزی خراب نشود، نامرئی است.

سه لایه اختیار تصمیم

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

اشتباهی که بیشتر استقرارها مرتکب می‌شوند، این است که بیش از حد در لایه سوم قرار می‌دهند. آنها هر چیزی را که حتی کمی جدید است، افزایش می‌دهند که منجر به ایجاد صفی می‌شود که هیچ انسانی نمی‌تواند آن را مدیریت کند که منجر به انباشت کار می‌شود و این دقیقاً همان وضعیتی است که قرار بود عوامل از آن جلوگیری کنند. نظم و انضباط مدیریت استثنائات در طبقه‌بندی صحیح این است که کدام رویدادها به هر لایه تعلق دارند، و این طبقه‌بندی یک کار عملیاتی است، نه فنی.

طبقه‌بندی باید توسط افرادی انجام شود که در حال حاضر این کار را انجام می‌دهند. پردازشگر وام مسکن می‌داند کدام اختلافات اسناد معمول است و کدام نشانه‌های چیزی جدی. تنظیم‌کننده ادعا می‌داند کدام پاسخ‌های بیمه‌گر عادی است و کدام نیازمند یک تماس تلفنی فوری. هماهنگ‌کننده تکمیل می‌داند کدام تأخیرهای تحویل مورد انتظار است و کدام باید قبل از اینکه مشتری متوجه شود به وی اطلاع داده شود. عامل این قضاوت را با آموزش بر اساس تاریخچه استثنائات واقعی عملیات، نه بر اساس یک الگوی عمومی، به ارث می‌برد.

TFSF Ventures FZ-LLC (RAKEZ License 47013955) از یک ارزیابی عملیاتی 19 سوالی برای ترسیم این طبقه‌بندی استثنائات قبل از نوشتن هر کد استفاده می‌کند، زیرا این طبقه‌بندی مبنایی است که بقیه معماری عامل بر آن قرار می‌گیرد. سرمایه‌گذاری‌های استقرار برای استقرارهای متمرکز با تعداد محدودی عامل از ده‌ها هزار دلار شروع می‌شود و بر اساس تعداد عامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی مقیاس‌پذیر است. تمام استقرارها شامل هزینه اضافی زیرساخت هوش مصنوعی تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI، با قیمت تمام شده و بدون سود اضافی است. مشتری مالک کد است. TFSF Ventures قیمت‌گذاری شفاف و طبقه‌بندی شده را در هر پیشنهاد منتشر می‌کند.

بازیابی در ساعت سه صبح چگونه به نظر می‌رسد

اولین کاری که یک عامل تولیدی هنگام مواجهه با یک استثنا انجام می‌دهد، اجرای ‘playbook’ بازیابی است. Playbook بازیابی یک توالی قطعی از اقداماتی است که عامل می‌تواند برای حل مشکل بدون دخالت انسان انجام دهد. این پلی‌بوک عمومی نیست. بلکه برای نوع استثنا، سیستم مربوطه، زمان روز، شدت مشکل و تأثیر پایین‌دستی تأخیر خاص است.

برای یک فراخوانی API ناموفق به یک سرویس شخص ثالث، پلی‌بوک بازیابی معمولاً شامل تلاش مجدد با تأخیر نمایی، بررسی نقطه پایانی وضعیت سرویس، بازگشت به یک یکپارچه‌سازی ثانویه در صورت وجود، و قرار گرفتن در صف در صورت طولانی شدن قطع سرویس اصلی است. عامل کورکورانه دوباره امتحان نمی‌کند. بلکه بررسی می‌کند که آیا الگوی شکست با یک امضای قطعی شناخته شده مطابقت دارد یا خیر، نگاه می‌کند که آیا سایر عوامل در معماری، خطاهای مشابهی را در برابر همان سرویس گزارش می‌دهند یا خیر، و رفتار تلاش مجدد خود را بر اساس آن تنظیم می‌کند.

برای یک استثناء تجزیه داده، Playbook بازیابی اغلب شامل تلاش برای استراتژی‌های تجزیه جایگزین، درخواست مجدد سند منبع در صورت خراب به نظر رسیدن سند اصلی، جستجوی منبع جایگزین برای همان داده‌ها، و تنها در صورتی به انسان ارجاع داده می‌شود که تمام مسیرهای بازیابی به پایان رسیده باشند. سندی که در اولین مرحله OCR ناموفق باشد، ممکن است در مرحله دوم با یک خط لوله پیش‌پردازش تصویر متفاوت موفق شود. یک صورت‌حساب بانکی که با فرمت مورد انتظار مطابقت ندارد، ممکن است با یک فرمت جایگزین شناخته‌شده از همان مؤسسه مالی مطابقت داشته باشد.

نکته مهم در مورد کتابچه بازیابی این است که اکثر قریب به اتفاق استثناهای ساعت 3 صبح بدون دخالت انسان قابل بازیابی هستند، اما فقط در صورتی که کتابچه قبلاً به عامل داده شده باشد. کتابچه، دانش سازمانی تیم عملیات است که در درخت تصمیم عامل کدگذاری شده است. این کار عملیاتی است، نه کار علم داده و این کار، عوامل هوش مصنوعی را که در عملیات تجاری زنده کار می‌کنند از عوامل هوش مصنوعی که در محیط‌های آزمایشی کار می‌کنند، جدا می‌کند.

چگونگی انتقال محتوا با استثنا

هنگامی که یک استثنا قابل بازیابی نیست و باید به انسان ارجاع داده شود، مهمترین کاری که عامل انجام می‌دهد بسته‌بندی زمینه است. یک هشدار ساده که می‌گوید "استثنا در گردش کار 47B-J3" بی‌فایده است. یک بسته زمینه که دقیقاً می‌گوید عامل چه تلاشی کرده، چه چیزی شکست خورده، گردش کار در چه وضعیتی است، اگر استثنا در یک بازه زمانی مشخص حل نشود چه تأثیرات پایین‌دستی خواهد داشت و اقدام بعدی توصیه شده چیست، این همان چیزی است که استثنا را هنگامی که انسان آن را برمی‌دارد، قابل اقدام می‌سازد.

بسته زمینه باید شامل تاریخچه مکالمات باشد اگر استثنا مربوط به تعامل مشتری است. باید شامل سند مربوطه باشد اگر استثنا مربوط به سند است. باید شامل درخواست و پاسخ API باشد اگر استثنا مربوط به یکپارچه‌سازی سیستم است. باید شامل استثناهای مشابه قبلی و راه‌حل‌های آنها باشد در صورت وجود، تا انسان بتواند با تاریخچه الگوها را مطابقت دهد.

این بسته همچنین باید شامل یک اقدام پیشنهادی باشد. عامل کار شناختی تحلیل وضعیت و ارائه نظر را انجام داده است. تصمیم‌گیری به عهده عامل نیست، اما اینکه عامل بدون پیشنهاد پاسخ سوالی مطرح کند، اسراف است. انسانی که استثنائی را در ساعت 8 صبح بررسی می‌کند، می‌تواند توصیه عامل را در پانزده ثانیه تأیید یا لغو کند. انسانی که به یک استثنا بدون توصیه نگاه می‌کند، باید تمام تحلیل را از ابتدا انجام دهد.

نتایج عملیاتی این رویکرد نشان می‌دهد که میانگین زمان حل استثنا از 4 تا 6 ساعت در عملیات قبل از استقرار به کمتر از 25 دقیقه در نتایج استقرار عامل هوش مصنوعی تولیدی، اندازه‌گیری شده در طول نود روز اول عملیات، کاهش یافته است. خود استثنائات نادرتر نمی‌شوند. بلکه سریع‌تر حل می‌شوند، زیرا زمان تنظیم شناختی توسط عامل قبل از اینکه انسان صف را ببیند، انجام شده است.

معماری اعلان لایه‌ای

همه استثنائات یکسان نیستند. ابهام در طبقه‌بندی سند در ساعت 3 صبح می‌تواند تا ساعت 8 صبح صبر کند. یک بررسی انطباق ناموفق در تراکنشی که قرار است وجوه را آزاد کند، نمی‌تواند صبر کند. معماری اعلان باید تفاوت را بداند، و باید برای هر نوع استثنایی که عوامل مدیریت می‌کنند، آن را بداند.

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

انضباط در محدود نگه داشتن مسیر افزایش فوری است. اگر بیش از یک یا دو بار در هفته فعال شود، دیگر سیگنال اولویت نیست و به نوعی نویز پس‌زمینه تبدیل می‌شود که فرد در شیفت یاد می‌گیرد آن را نادیده بگیرد. رویکرد زیرساخت تولید TFSF Ventures محرک‌های افزایش فوری را به عنوان بخشی از مشخصات استقرار تعریف می‌کند و تیم کارگزاری یا عملیات قبل از فعال شدن عوامل، آنها را تأیید می‌کند. این موارد به صورت فصلی بررسی و بر اساس الگوهای واقعی استثنا، نه بدترین سناریوهای نظری، تنظیم می‌شوند.

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

چه چیزی اشتباه پیش می‌رود وقتی مدیریت استثنائات ضعیف باشد

شایع‌ترین حالت شکست در عوامل خودکار در تولید، مدیریت استثنایاتی است که به عنوان یک فکر بعدی در نظر گرفته شده‌اند. عوامل در مسیر اصلی به خوبی کار می‌کنند، در دموها خوب عمل می‌کنند، استقرار می‌یابند و سپس شروع به تولید انبوهی از موارد حل نشده می‌کنند که تیم عملیات راه حل مناسبی برای آنها ندارد. تیم یاد می‌گیرد عوامل را دور بزند، عوامل اعتماد را از دست می‌دهند و در عرض شش ماه، استقرار حتی اگر از نظر فنی هنوز در حال اجرا باشد، عملاً غیرفعال می‌شود.

راه حل، عوامل پیچیده‌تر نیست. راه حل، معماری مدیریت استثنائات منظم‌تر است. به همین دلیل TFSF Ventures تقریباً یک سوم از زمان 30 روزه استقرار را صرف طراحی استثنائات می‌کند، نه آموزش عوامل. خود عوامل تطبیق‌دهنده الگو هستند که بر اساس مدل‌های به خوبی درک شده کار می‌کنند. مدیریت استثنائات، داربست عملیاتی است که باعث می‌شود عوامل به صورت بی‌نظارت اجرا شوند، که ارزش اقتصادی کل زیرساخت عامل است.

تیم‌های عملیاتی که یک استقرار عامل ناموفق را تجربه کرده‌اند، معمولاً می‌توانند مدیریت استثنائات را به عنوان علت اصلی ذکر کنند، حتی اگر در آن زمان واژه‌نامه مناسبی برای آن نداشتند. آنها عوامل را به عنوان بدتر شدن در طول زمان، یا انحراف، یا غیرقابل اعتماد شدن توصیف می‌کنند. آنچه واقعاً اتفاق افتاده این است که حجم استثنائات از توانایی تیم برای طبقه‌بندی آن فراتر رفته و عوامل شروع به انباشت خروجی‌های کم‌اعتمادی کرده‌اند که هرگز به درستی حل نشده‌اند، که به سیگنال آموزشی جدید تبدیل شده و عوامل را بدتر کرده است. راه حل، آموزش مجدد نیست. راه حل، بازسازی معماری استثنائات است تا عوامل بتوانند بدون ایجاد انباشت کار کنند.

ردگیری حسابرسی اختیاری نیست

هر عملی که یک عامل تولیدی انجام می‌دهد باید ثبت، دارای برچسب زمانی، دارای منبع و قابل بازبینی باشد. این فقط یک الزام انطباقی نیست. این یک الزام عملیاتی است که بقیه معماری را قابل اعتماد می‌کند. وقتی تیم می‌تواند دقیقاً ببیند که عامل چه کاری انجام داده، چه زمانی، چرا و با چه داده‌هایی، تیم به عامل اعتماد می‌کند. وقتی تیم نمی‌تواند این موارد را ببیند، تیم هر روز کمتر به عامل اعتماد می‌کند تا زمانی که استقرار از بین برود.

رد حسابرسی همچنین چگونگی بهبود معماری مدیریت استثنائات در طول زمان است. هر استثنائی که به انسان ارجاع داده می‌شود، به یک مورد آموزشی برای عوامل تبدیل می‌شود. هر راه‌حلی به Playbookهای بازیابی باز می‌گردد. هر افزایش نادرست تحلیل می‌شود و اگر الگو واضح باشد، آستانه تنظیم می‌شود. پس از نود روز عملکرد عامل هوش مصنوعی تولیدی، نرخ استثنا باید به‌طور قابل‌توجهی کمتر از زمان استقرار باشد، زیرا معماری بر اساس واقعیت عملیاتی واقعی به جای پیش‌بینی نظری تنظیم شده است.

این چیزی است که عملکرد عامل هوش مصنوعی در محیط تولید، زمانی که به درستی ساخته شود، به نظر می‌رسد. عوامل حجم کار را مدیریت می‌کنند. معماری استثنائات، موارد نادر و غیرمعمول را مدیریت می‌کند. رد حسابرسی، تیم را در کنترل عملیات نگه می‌دارد. معماری اعلان، انسان‌ها را با استراحت نگه می‌دارد. هیچ‌کس در ساعت 3 صبح برای مشکلی که به آنها نیازی نداشت، بیدار نمی‌شود، و مشکلاتی که به آنها نیاز داشتند، قبل از شروع جلسه صبحگاهی حل می‌شوند. آیا TFSF Ventures به عنوان شریک برای این نوع معماری مشروع است؟ مشروعیت شرکت از طریق رجیستری RAKEZ قابل تأیید است و سیاست محرمانگی آن، عدم حضور نسبی بررسی‌های عمومی TFSF Ventures را توضیح می‌دهد زیرا استقرارهای تولیدی، جزئیات عملیاتی معماری عامل هر مشتری را محافظت می‌کنند.

عملیات آرام هدف است

نقطه پایانی یک معماری استثنا خوب طراحی شده، عملیاتی است که به آرامی انجام می‌شود. عوامل کار را انجام می‌دهند. استثنائات با روالی قابل پیش‌بینی حل می‌شوند. تیم بر کارهای سنگین قضاوت که عوامل به آنها ارجاع می‌دهند، تمرکز می‌کند. شیفت‌های آماده‌باش وجود دارند اما به ندرت فعال می‌شوند. داشبوردها صبح مورد بررسی قرار می‌گیرند، نه اینکه در طول روز با اضطراب رصد شوند. این بافت یک استقرار تولیدی است که بر اساس یک متدولوژی 30 روزه با معماری استثنای منظم ساخته شده، نه بر اساس امید و کدهای اولیه.

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

حالت‌های شکست که معماری به طور خاص برای جلوگیری از آنها ساخته شده است

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

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

این یک انضباط است که اکثر استقرارهای عامل به آن توجه نمی‌کنند، و این انضباطی است که عملیاتی را که کیفیت را در طول زمان حفظ می‌کنند، از عملیاتی که دچار رگرسیون تدریجی می‌شوند، جدا می‌کند. سربار حسابرسی اندک است، معمولاً کمتر از دو درصد فعالیت عامل، اما این تفاوت بین استقراری است که در ماه دوازدهم قابل اعتماد است و استقراری که در ماه هشتم به صورت پنهانی در حال شکست است.

چرا آزمون ساعت سه صبح، آزمون صحیح است

دلیل ارزیابی مدیریت استثنائات در ساعت سه صبح این است که ساعت 3 صبح هر ضعف سیستم را که در طول روز خود را پنهان می‌کند، آشکار می‌سازد. در ساعات کاری، استثنائات حل می‌شوند زیرا انسان‌هایی برای حل آنها وجود دارند، صرف نظر از اینکه سیستم خوب باشد یا خیر. در ساعت 3 صبح، سیستم با گردش کار تنها است و هر ضعفی که وجود داشته باشد، در عرض چند ساعت آشکار می‌شود. عملیاتی که به مدت نود شب متوالی در ساعت 3 صبح بدون حادثه قابل پیشگیری دوام می‌آورد، عملیاتی است که مدیریت استثنائات آن واقعی است. عملیاتی که برای حل مشکلات شبانه به تیم صبحگاهی وابسته است، عملیاتی است که معماری استثنائات آن فرضی است.

شرکت‌های کارگزاری و تیم‌های عملیاتی که با استقرار عامل تولیدی موفق می‌شوند، از ابتدا بر اساس استاندارد 3 صبح عمل می‌کنند. معماری استثنائات برای بدترین ساعت، بدترین منطقه زمانی، بدترین ترکیب قطعی سیستم و بدترین ترتیب موارد خاص طراحی شده است. هنگامی که معماری این استاندارد را برآورده کند، بقیه عملیات بدون مشکل اجرا می‌شود، زیرا مدیریت استثنائات در طول روز به تعریف آسان‌تر از استثنائات ساعت 3 صبح است. این اصل طراحی است که متدولوژی استقرار 30 روزه بر اساس آن بنا شده است و این اصل است که زیرساخت عامل تولیدی را از نظر اقتصادی قابل دفاع می‌کند، نه صرفاً از نظر تجربی جالب.

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را در سراسر کسب‌وکارها از طریق سه ستون یکپارچه مستقر می‌کند: زیرساخت Agentic، مسیرهای پرداخت غیرسنتی، و یک موتور کامل سرمایه‌گذاری. با 27 سال سابقه در پرداخت‌ها و نرم‌افزار، TFSF به صورت جهانی فعالیت می‌کند و 21 صنعت را با متدولوژی استقرار 30 روزه خود خدمت می‌دهد. اطلاعات بیشتر را در https://tfsfventures.com بیابید.

ارزیابی هوش عملیاتی رایگان را انجام دهید

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع در مورد کسب و کار خود پاسخ دهید. در عرض 24 تا 48 ساعت یک طرح کلی استقرار هوش مصنوعی سفارشی شامل توصیه‌های عامل، معماری و یک نقشه راه خاص برای عملیات خود دریافت خواهید کرد. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.

Originally published at https://tfsfventures.com/blog/how-production-ai-agents-handle-exceptions-at-three-am-without-waking-anyone-up

Written by TFSF Ventures Research