بیشتر دستیارهای هوش مصنوعی تا وقتی چیزی از آن‌ها نپرسید، بیکار می‌مانند. پرسشی تایپ می‌کنید، پاسخ می‌دهند و سپس منتظر می‌مانند. در انطباق تجاری، این الگو مشکلی بنیادی دارد: ریسک‌ها منتظر نمی‌مانند کسی درباره‌شان سؤال کند.
در Atlas Verified، سامانه‌ای از عامل‌های ابری خودمختار ساختیم که به‌طور پیوسته زنجیره‌های تأمین را پایش می‌کنند، پایگاه‌های داده دولتی را بررسی می‌کنند و طبق برنامه، ریسک‌های انطباق را آشکار می‌کنند، بدون اینکه کسی دستوری تایپ کند. آن‌ها در پس‌زمینه، برای همه سازمان‌های پلتفرم ما اجرا می‌شوند و اطلاعات ساختاریافته را مستقیماً به داشبورد تحویل می‌دهند.
این مطلب مهندسی عامل‌های همیشه‌فعال هوش مصنوعی را پوشش می‌دهد: تفاوتشان با هوش مصنوعی مکالمه‌ای، اهمیت خروجی ساختاریافته و چالش‌های هماهنگ‌سازی اجرای عامل‌های خودمختار در مقیاس بزرگ.
از واکنشی به پیش‌دستانه
هوش مصنوعی مکالمه‌ای ذاتاً واکنشی است. کاربر پرسشی می‌پرسد، مدل درباره آن استدلال می‌کند، چند ابزار را فراخوانی می‌کند و پاسخ می‌دهد. این روش برای پژوهش موردی و تحلیل اسناد خوب کار می‌کند. اما پایش انطباق، اطلاعات پیش‌دستانه می‌طلبد.
این سناریو را در نظر بگیرید: گواهی ارگانیک تأمین‌کننده‌ای در طول شب از سوی USDA تعلیق می‌شود. محموله‌ای از آن تأمین‌کننده هم‌اکنون در مسیر است. تصمیم جدید OFAC، یک فورواردر را به فهرست تحریم‌ها اضافه می‌کند. هشدار وارداتی FDA برای کالایی صادر می‌شود که شما در حال وارد کردن آن هستید.
هیچ‌یک از این رویدادها منتظر نمی‌ماند مسئول انطباق وارد سامانه شود و پرسش درست را بپرسد. تا وقتی کسی به فکر بررسی بیفتد، ممکن است فرصت اقدام پیش‌دستانه از دست رفته باشد. کالا در بندر است. مدارک ثبت شده‌اند. خطر واقعی است.
عامل‌های ابری با معکوس کردن این رابطه مشکل را حل می‌کنند. به‌جای اینکه کاربر هوش مصنوعی را هدایت کند، هوش مصنوعی طبق برنامه خودش را به کار می‌اندازد، همه موارد مهم را بررسی می‌کند و یافته‌ها را به کاربر می‌رساند.
معماری یک عامل برای هر بخش چهارگانه
وقتی نخستین نمونه‌های عامل‌های ابری را ساختیم، یک عامل واحد را امتحان کردیم که همه‌چیز را پوشش می‌داد: تغییرات مقررات، وضعیت تأمین‌کننده، ردیابی محموله و پردازش اسناد. خروجی آن نامتمرکز و پراکنده‌گو بود. عامل یک مسیر جالب را دنبال می‌کرد و دسته‌های کامل اطلاعات را نادیده می‌گرفت.
راه‌حل، تقسیم فضای مسئله به حوزه‌های متمرکزی بود که آن‌ها را بخش‌های چهارگانه می‌نامیم:
اطلاعات. هشدارهای نظارتی، روندهای بازار و ریسک‌های بین‌حوزه‌ای. این عامل پایگاه‌های داده دولتی را برای تغییراتی پایش می‌کند که بر سازمان اثر می‌گذارند: هشدارهای وارداتی جدید FDA، به‌روزرسانی‌های فهرست OFAC، تغییرات تعرفه و تغییر وضعیت گواهی ارگانیک.
تأمین‌کنندگان. سلامت شبکه تأمین‌کنندگان. این عامل وضعیت راستی‌آزمایی تأمین‌کنندگان، شکاف‌های انطباق، انقضای گواهی‌ها و ریسک‌های تمرکز شبکه را بررسی می‌کند. اگر 80% از تأمین ارگانیک شما به یک نهاد گواهی‌دهنده وابسته باشد، این عامل آن را علامت‌گذاری می‌کند.
محموله‌ها. پایش محموله‌های فعال. این عامل موقعیت کشتی‌ها را ردیابی می‌کند، انحراف از مسیر را پایش می‌کند، تأخیرها را بررسی می‌کند و کامل بودن مستندات محموله را اعتبارسنجی می‌کند. مسائلی مانند ماندن کانتینرها در بندر بیش از زمان مورد انتظار یا انحراف کشتی‌ها از مسیرهای اظهارشده را آشکار می‌کند.
فضای کاری. سلامت عملیاتی. این عامل وضعیت پردازش اسناد، راستی‌آزمایی‌های در انتظار، فعالیت تیم و الگوهای استفاده از پلتفرم را بررسی می‌کند. مواردی مانند اسنادی که پردازششان شکست خورده و نیاز به توجه دارند، یا راستی‌آزمایی‌هایی که بیش از حد طولانی در انتظار مانده‌اند را آشکار می‌کند.
هر عامل با دستور سیستمی متمرکز و مجموعه محدودی از ابزارهای مرتبط با حوزه خود اجرا می‌شود. این روش خروجی بسیار بهتری نسبت به یک عامل همه‌دان تولید می‌کند، به همان دلیلی که تیم متخصصان از یک فرد عمومی بهتر عمل می‌کند: عمق تمرکز.
اشتراک لایه ابزار با عامل گفت‌وگو
یکی از مهم‌ترین تصمیم‌های معماری این بود که عامل‌های ابری دقیقاً از همان لایه ابزار عامل گفت‌وگوی مکالمه‌ای ما استفاده کنند. همان ابزارهای غربالگری OFAC، جست‌وجوی USDA، ردیابی کشتی، پرس‌وجوی داده تجاری و تحلیل اسناد، هر دو سامانه را پشتیبانی می‌کنند.
این کار مزایای مهندسی چشمگیری دارد:
بدون تکرار ابزارها. وقتی منبع داده جدیدی اضافه می‌کنیم یا مبدل موجودی را بهبود می‌دهیم، هم عامل گفت‌وگو و هم عامل‌های ابری فوراً بهره‌مند می‌شوند. یک پیاده‌سازی، یک مجموعه آزمون و یک بخش برای نگهداری وجود دارد.
نتایج سازگار. بررسی تحریم‌ها توسط عامل ابری و بررسی تحریم‌ها توسط کاربر در گفت‌وگو، همان تابع را با همان منطق فراخوانی می‌کنند. نتایج مستقیماً قابل مقایسه و تطبیق متقابل‌اند.
چالش این است که ابزارهای طراحی‌شده برای استفاده تعاملی، همیشه در زمینه پردازش دسته‌ای به همان شکل کار نمی‌کنند. عامل گفت‌وگو وقتی پرس‌وجویی مبهم باشد می‌تواند از کاربر توضیح بخواهد. عامل ابری نمی‌تواند. این موضوع را با دادن دستورهای مشخص‌تر و حدود بازگشت بالاتر به عامل‌های ابری مدیریت می‌کنیم؛ آن‌ها زمان بیشتری برای اصلاح خود دارند، چون کسی در لحظه منتظر پاسخ نیست.
خروجی ساختاریافته: از متن آزاد تا کارت‌های داشبورد
اینجا تفاوت عامل‌های ابری و عامل‌های گفت‌وگو از همه روشن‌تر است. عامل گفت‌وگو متن روایی تولید می‌کند که گاهی کارت‌های ساختاریافته در آن گنجانده شده‌اند. عامل ابری باید منحصراً خروجی ساختاریافته‌ای تولید کند که مستقیماً در داشبورد نمایش داده شود.
هر اجرای عامل، آرایه‌ای از کارت‌های اطلاعاتی تولید می‌کند. هر کارت نوع و طرحواره تعریف‌شده‌ای دارد:
شمارنده‌ها شاخص‌های کلیدی را همراه با نشانگر روند نمایش می‌دهند: مجموع محموله‌های فعال، تأمین‌کنندگان با گواهی‌های در آستانه انقضا و راستی‌آزمایی‌های در انتظار.
نشانگرهای ریسک نگرانی‌های مشخص انطباق را که به توجه نیاز دارند برجسته می‌کنند: تأمین‌کننده‌ای با گواهی تعلیق‌شده، انطباق با تحریم‌ها یا هشدار وارداتی FDA.
هشدارها اطلاعات حساس به زمان را منتقل می‌کنند: تغییرات مقررات، موارد جدید تعیین‌شده از سوی OFAC و به‌روزرسانی‌های تعرفه‌ای که بر محموله‌های فعال اثر می‌گذارند.
نمودارها و جدول‌ها داده‌های تحلیلی را ارائه می‌کنند: روند حجم محموله‌ها، توزیع مسیرهای تجاری و نرخ تکمیل راستی‌آزمایی.
نقشه‌ها اطلاعات جغرافیایی را نمایش می‌دهند: موقعیت کشتی‌ها، فعالیت بنادر و پراکندگی تأمین‌کنندگان.
چالش مهندسی، محدود کردن مدل زبانی بزرگ به تولید مداوم خروجی ساختاریافته معتبر است. مدل‌های زبانی می‌خواهند روایت کنند. می‌خواهند توضیح دهند و قید و شرط بیاورند. واداشتن آن‌ها به تولید آرایه JSON تمیزی از کارت‌ها با نوع‌ها، فیلدها و داده‌های درست، به مهندسی دقیق دستور و اعتبارسنجی خروجی نیاز دارد.
وقتی خروجی عامل با طرحواره کارت مورد انتظار مطابقت ندارد، آنچه را می‌توانیم تجزیه می‌کنیم و کارت‌های بدساخت را کنار می‌گذاریم، به‌جای اینکه کل اجرا را شکست‌خورده بدانیم. اطلاعات ناقص بهتر از نبود اطلاعات است.
عامل‌های سفارشی: پایشگرهای خودمختار تعریف‌شده توسط کاربر
فراتر از چهار عامل سیستمی، کاربران می‌توانند عامل‌های ابری خود را بسازند. عامل سفارشی دارای نام، دستور سیستمی نوشته‌شده توسط کاربر و برنامه زمان‌بندی است. از همان لایه ابزار استفاده می‌کند و همان انواع کارت را تولید می‌کند، اما تمرکزش کاملاً توسط کاربر تعریف می‌شود.
کاربر ممکن است عاملی بسازد که یک مسیر تجاری مشخص را برای اختلال‌ها پایش کند. یا عاملی که هر روز مجموعه مشخصی از تأمین‌کنندگان را در برابر فهرست‌های تحریم بررسی کند. یا عاملی که با استفاده از منابع داده تجاری، تغییرات قیمت یک کالای مشخص را ردیابی کند. امکانات فقط به آنچه لایه ابزار می‌تواند به آن دسترسی داشته باشد محدودند.
ایمن و مفید کردن این کار به چند تصمیم مهندسی نیاز داشت:
محدودسازی به سازمان. هر عامل سفارشی به یک سازمان تعلق دارد و فقط می‌تواند به داده‌های همان سازمان دسترسی داشته باشد. عامل نمی‌تواند از مرزهای سازمانی عبور کند، حتی اگر دستور کاربر بخواهد آن را به این کار وادار کند.
فیلتر کردن قابلیت ابزارها. عامل‌های سفارشی به همان ابزارهای راستی‌آزمایی و پژوهش عامل‌های سیستمی دسترسی دارند، اما مرزهای مجوز سازمان را به ارث می‌برند. عامل سفارشی نمی‌تواند به ابزارها یا داده‌هایی دسترسی داشته باشد که خود کاربر از طریق رابط گفت‌وگو به آن‌ها دسترسی ندارد.
مدیریت برنامه زمان‌بندی. عامل‌های سفارشی طبق برنامه‌های تعریف‌شده توسط کاربر، اما در محدوده محدودیت‌های پلتفرم اجرا می‌شوند. این کار مانع می‌شود یک سازمان با زمان‌بندی ده‌ها عامل برای اجرا در هر ساعت، منابع محاسباتی نامتناسبی مصرف کند.
هماهنگ‌سازی در مقیاس بزرگ
اجرای روزانه عامل‌های خودمختار برای سازمان‌های متعدد، چالش‌های هماهنگ‌سازی‌ای ایجاد می‌کند که در سامانه مبتنی بر گفت‌وگو وجود ندارند.
حذف موارد تکراری. اگر زمان‌بند فعال شود و عامل سازمان A قبلاً در بازه حذف موارد تکراری اجرا شده باشد، از اجرای آن صرف‌نظر می‌شود. این کار از اجرای دوباره بر اثر تلاش مجدد، هم‌پوشانی برنامه‌ها یا اختلال زمان‌بند جلوگیری می‌کند. هر جفت عامل و سازمان به‌عنوان یک واحد زمان‌بندی یکتا در نظر گرفته می‌شود.
جداسازی شکست‌ها. اگر عامل یک سازمان شکست بخورد، چون ابزار خطا برگرداند، مدل زبانی بزرگ خروجی غیرقابل تجزیه تولید کند یا خدمت وابسته از دسترس خارج باشد، نباید بر اجرای عامل‌های سازمان‌های دیگر اثر بگذارد. هر اجرا کاری مستقل است. خطاها ثبت می‌شوند، اجرا شکست‌خورده علامت‌گذاری می‌شود و زمان‌بند به کار بعدی می‌رود.
چرخه عمر کارت. کارت‌های اطلاعاتی زمان اعتبار دارند. کارت‌های قدیمی منقضی می‌شوند و هنگام اجرای دوباره عامل جایگزین می‌شوند. این تضمین می‌کند داشبورد همیشه اطلاعات جاری را نشان دهد و یافته‌های قدیمی روی هم جمع نشوند. وقتی عامل کارت‌های جدید تولید می‌کند، کارت‌های قبلی آن بخش چهارگانه به‌صورت اتمی جایگزین می‌شوند.
بودجه‌بندی منابع. اجرای عامل‌ها، توکن‌های مدل زبانی بزرگ، فراخوانی‌های API خارجی و اتصال‌های پایگاه داده مصرف می‌کند. مصرف توکن را برای هر اجرا و هر سازمان پیگیری می‌کنیم تا هزینه‌ها را مدیریت و عامل‌های مصرف‌کننده منابع نامتناسب را شناسایی کنیم. عاملی که از کنترل خارج شده و 50 فراخوانی ابزار انجام می‌دهد درحالی‌که 10 فراخوانی کافی است، علامت‌گذاری می‌شود.
پیوند عامل‌های ابری و گفت‌وگو
عامل‌های ابری و عامل گفت‌وگو سامانه‌هایی جداافتاده نیستند. آن‌ها یک حلقه بازخورد تشکیل می‌دهند.
عامل گفت‌وگو می‌تواند خروجی عامل‌های ابری را جست‌وجو کند. وقتی کاربر می‌پرسد «عامل‌های من چه چیزی پیدا کردند؟» یا «آیا ریسک انطباقی هست که باید از آن خبر داشته باشم؟»، عامل گفت‌وگو تازه‌ترین کارت‌های اطلاعاتی را بازیابی می‌کند و به‌شکل مکالمه‌ای ارائه می‌دهد. می‌تواند نشانگر ریسک را توضیح دهد، زمینه بیشتری ارائه کند یا به کاربر برای اقدام بر اساس یک یافته کمک کند.
این یک گردش کار طبیعی ایجاد می‌کند: عامل‌های ابری در طول شب مسائل را آشکار می‌کنند، کاربر صبح داشبورد را بررسی می‌کند و وقتی می‌خواهد یافته‌ای را عمیق‌تر بررسی کند، گفت‌وگویی باز می‌کند. عامل گفت‌وگو از قبل می‌داند عامل‌های ابری چه یافته‌اند و می‌تواند کار را از همان نقطه ادامه دهد.
مسیر معکوس نیز کار می‌کند: الگوهایی که از تعامل‌های گفت‌وگویی کاربران پدید می‌آیند، به تنظیم دستورهای عامل‌های ابری کمک می‌کنند. اگر کاربران مرتب درباره نوع مشخصی از ریسک سؤال کنند که عامل‌های ابری آشکار نمی‌کنند، این نشانه‌ای برای تنظیم تمرکز عامل است.
آنچه آموخته‌ایم
ساخت عامل‌های خودمختار هوش مصنوعی درس‌هایی به ما داده که از ساخت عامل‌های مکالمه‌ای آشکار نمی‌شوند:
خروجی ساختاریافته دشوارتر از متن آزاد است. واداشتن مدل زبانی بزرگ به تولید مداوم JSON معتبر و مطابق طرحواره، چالشی به‌طور معنادار متفاوت از نوشتن یک بند خوب است. مدل‌ها می‌خواهند توضیح دهند و باید آن انرژی تحلیلی را به فیلدهای ساختاریافته هدایت کنید.
دامنه همه‌چیز است. عامل متمرکز با حوزه روشن، اطلاعات بهتری از عامل گسترده با دسترسی به همه‌چیز تولید می‌کند. معماری یک عامل برای هر بخش چهارگانه، بزرگ‌ترین بهبود منفرد کیفیتی بود که انجام دادیم.
نتایج جزئی بهتر از اجرای شکست‌خورده‌اند. در سامانه دسته‌ای، وقتی چیزی اشتباه پیش می‌رود نمی‌توانید از کاربر بپرسید چه کنید. کاهش کنترل‌شده قابلیت‌ها، یعنی تولید کارت‌هایی که می‌توانید و ذکر شکاف‌ها، ضروری است.
کاربران کنترل می‌خواهند. عامل‌های سفارشی یکی از پرتقاضاترین قابلیت‌ها از آب درآمدند. متخصصان انطباق، ریسک‌های خاص خود را بهتر از هر سامانه عمومی می‌شناسند. فراهم کردن امکان برنامه‌ریزی پایشگرهای خودمختار به زبان طبیعی، ارزش چشمگیری ایجاد کرد.
حلقه بازخورد اهمیت دارد. عامل‌های ابری و عامل‌های گفت‌وگو در کنار هم ارزشمندتر از هرکدام به‌تنهایی هستند. اطلاعات پیش‌دستانه دستور کار را تعیین می‌کند؛ هوش مصنوعی مکالمه‌ای عمق را فراهم می‌کند. طراحی برای این جریان دوسویه از ابتدا، هر دو سامانه را بهتر شکل داد.
نگاه به آینده
عامل‌های ابری تغییری بنیادی در نگاه ما به هوش مصنوعی در انطباق ایجاد می‌کنند. پرسش این نیست که «هوش مصنوعی وقتی از آن سؤال شود چه پاسخی می‌تواند بدهد؟»، بلکه این است که «هوش مصنوعی بدون اینکه از آن سؤال شود باید چه چیزهایی را بررسی کند؟»
با گسترش لایه ابزار از طریق منابع داده بیشتر و پیچیده‌تر شدن عرصه مقررات، ارزش پایش خودمختار افزایش می‌یابد. روز کاری متخصص انطباق نباید با بررسی دستی شش پایگاه داده دولتی و سه خدمت ردیابی آغاز شود. باید با داشبوردی شروع شود که دقیقاً بگوید در طول شب چه چیزی تغییر کرده و چه چیزی به توجه او نیاز دارد.
این همان چیزی است که عامل‌های ابری ارائه می‌کنند. و چالش مهندسیِ قابل اتکا، مقیاس‌پذیر و مفید کردن آن، یکی از رضایت‌بخش‌ترین مسائلی است که فرصت کار روی آن را داریم.
عامل‌های ابری Atlas Verified به‌طور خودمختار زنجیره‌های تأمین را پایش می‌کنند، پایگاه‌های داده دولتی را بررسی می‌کنند و ریسک‌های انطباق را آشکار می‌کنند تا متخصصان انطباق بر تصمیم‌ها تمرکز کنند، نه گردآوری داده.