درک معماری عامل هوش مصنوعی در پشت ابتکارات حمل و نقل خودمختار و عملیات ناوگان خصوصی
راهنمای متدولوژی هفت لایهای برای معماری عامل هوش مصنوعی در پشت حمل و نقل خودران و خودکارسازی ناوگان خصوصی در امارات، با ترتیب استقرار و الگوهای
ابتکارات حمل و نقل خودران در امارات متحده عربی، از جمله استراتژی خودروهای خودران دبی که ۲۵ درصد از سفرها را تا سال ۲۰۳۰ هدف قرار داده است، برنامههای حمل و نقل هوشمند ابوظبی، و کارهای خودکارسازی ناوگان خصوصی که در اپراتورهای لجستیک، تاکسی آنلاین و حمل و نقل شرکتی در حال انجام است، همگی به جای یک مدل واحد یکپارچه، بر یک معماری عامل هوش مصنوعی لایهبندی شده متکی هستند. این معماری اهمیت دارد زیرا تفاوت عملیاتی بین یک نمایش تحقیقاتی و یک استقرار تولیدی، ساختار عوامل است، نه قابلیت هیچ مدل واحدی. این راهنمای متدولوژی، معماری پشت استقرارهای هوش مصنوعی حمل و نقل خودران دبی و عملیات ناوگان خصوصی را توصیف میکند، با لایههای توصیف شده بر اساس اصطلاحات استقرار به جای اصطلاحات تحقیقاتی.
چرا معماری نتایج عملیاتی را تعیین میکند
بحث حمل و نقل خودران اغلب بر قابلیت در سطح خودرو متمرکز است: سیستمهای ادراک، سیستمهای تصمیمگیری، سیستمهای کنترل و پرونده ایمنی برای حذف راننده. قابلیت در سطح خودرو ضروری است اما برای استقرار عملیاتی کافی نیست. خودرویی که میتواند خود را در شرایط کنترل شده براند، یک سرویس حمل و نقل کارآمد تولید نمیکند. سرویس کارآمد نیاز به هماهنگی ناوگان، پیشبینی تقاضا، تعامل با مشتری، صورتحساب، برنامهریزی تعمیر و نگهداری، گزارشدهی نظارتی و مدیریت استثنائات برای مواردی دارد که خارج از پوشش خودران خودرو قرار میگیرند.
معماری که خودروهای خودران را به یک سرویس کارآمد تبدیل میکند، همان معماری عاملی است که ناوگانهای غیرخودران را اجرا میکند، با لایههای اضافی برای نظارت بر خودرو و مدیریت پرونده ایمنی. این همپوشانی ساختاری دلیل این است که اپراتورهایی که اتوماسیون ناوگان غیرخودران بالغی دارند، نسبت به اپراتورهایی که از یک پایه دستی شروع میکنند، راحتتر میتوانند خودروهای خودران را در عملیات خود جذب کنند. معماری عامل، سیستم عامل ناوگان است و خودروهای خودران یک کلاس ورودی اضافی هستند تا یک مدل عملیاتی جداگانه.
برای اپراتورهای امارات که هم استقرار کامل خودران را در افق چند ساله و هم اتوماسیون ناوگان خصوصی کوتاهمدت بدون خودروهای خودران را برنامهریزی میکنند، سؤال معماری یکسان است. متدولوژی توصیف شده در اینجا برای هر دو مورد اعمال میشود، با اجزای خاص خودروهای خودران که در جایی که با الگوی ناوگان معمولی متفاوت هستند، مشخص میشوند.
لایه اول: لایه ادراک و رابط خودرو
پایینترین لایه معماری، رابط بین پشته عامل و خودروهای فیزیکی در ناوگان را مدیریت میکند. برای خودروهای غیرخودران، رابط شامل فید تلماتیک، برنامه راننده و سیستم مدیریت ناوگان است که وضعیت خودرو را تجمیع میکند. برای خودروهای خودران، رابط، سیستمهای ادراک، سیستمهای تصمیمگیری و کانالهای نظارت ایمنی خودرو را اضافه میکند.
لایه رابط، ورودیها را از منابع ناهمگن خودرو به یک نمایش وضعیت عملیاتی ثابت نرمالسازی میکند. یک ناوگان مختلط معمولاً شامل خودروهایی از تولیدکنندگان مختلف، با پروتکلهای تلماتیک متفاوت، نسخههای مختلف برنامه راننده و پیکربندیهای حسگر متفاوت در زیرمجموعه خودران است. لایه رابط این ناهمگنی را از لایههای بالاتر معماری پنهان میکند و یک مدل وضعیت خودرو یکنواخت را به عوامل تصمیمگیرنده عملیاتی ارائه میدهد.
لایه رابط همچنین مرز امنیتی بین ناوگان و سیستمهای پشتیبان است. دادههای خودرو که از این مرز عبور میکنند، قبل از ثبت در مدل وضعیت عملیاتی، احراز هویت، رمزگذاری و در برابر محدودههای مورد انتظار اعتبارسنجی میشوند. وضعیت امنیتی بسیار مهم است زیرا خودروهای خودران به ویژه یک سطح حمله را ارائه میدهند که میتواند بر ایمنی فیزیکی تأثیر بگذارد، و معماری رابط خودرو را به عنوان یک مرز با اعتماد بالا در نظر میگیرد که نیاز به کنترلهای امنیتی صریح دارد.
لایه دوم: لایه وضعیت عملیاتی و تلهمتری
لایه دوم، وضعیت خودرو، وضعیت مشتری، وضعیت تقاضا و وضعیت خارجی را در یک مدل عملیاتی بلادرنگ تجمیع میکند که لایههای بالاتر برای تصمیمگیری آن را پرسوجو میکنند. مدل وضعیت عملیاتی شامل موقعیت خودرو، وضعیت خودرو، در دسترس بودن راننده، درخواستهای مشتری، شرایط ترافیکی، آب و هوا، مرزهای نظارتی و تقویم رویدادها است. مدل به طور مداوم با ورود ورودیها بهروز میشود و تنها منبع حقیقت برای لایههای عملیاتی بالاتر است.
نظم طراحی در این لایه، تازگی دادهها در مقابل عملکرد پرسوجو است. تصمیمات عملیاتی نیاز به دادههای اخیر دارند، اما حجم تلهمتری از یک ناوگان بزرگ میتواند یک موتور پرسوجو را در صورتی که هر تصمیمی باعث اسکن کامل دادهها شود، تحت فشار قرار دهد. معماری این موضوع را از طریق یک مدل داده طبقهبندی شده مدیریت میکند: یک لایه گرم با تازگی زیر ثانیه برای خودروها و درخواستها در حالتهای فعال، یک لایه میانی با تازگی در حد دقیقه برای دادههای خلاصه در سطح ناوگان، و یک لایه سرد برای تحلیلهای تاریخی. عوامل تصمیمگیری لایه گرم را پرسوجو میکنند؛ عوامل برنامهریزی لایه میانی را پرسوجو میکنند؛ عوامل گزارشدهی و تحلیل، لایه سرد را پرسوجو میکنند.
لایه وضعیت عملیاتی همچنین اعلانهای رویداد محور را به لایههای بالاتر مدیریت میکند. هنگامی که وضعیت خودرو به گونهای تغییر میکند که نیاز به تصمیمگیری یک عامل دارد، لایه وضعیت عملیاتی یک رویداد را منتشر میکند که عامل مربوطه در آن مشترک است. الگوی رویداد محور، سربار نظرسنجی را که در غیر این صورت بر بودجه محاسباتی سیستم غالب میشد، کاهش میدهد و به عوامل اجازه میدهد در ثانیه به جای دقیقه به تغییرات عملیاتی واکنش نشان دهند.
لایه سوم: لایه عامل تصمیمگیرنده
لایه عامل تصمیمگیرنده جایی است که سیاست عملیاتی ناوگان به عنوان مجموعهای از عوامل تخصصی کدگذاری میشود، که هر یک مسئول یک حوزه عملیاتی تعریف شده هستند. عوامل معمول در یک استقرار حمل و نقل شامل عامل اعزام، عامل مسیریابی، عامل خدمات مشتری، عامل صورتحساب، عامل نگهداری، عامل برنامهریزی راننده، عامل هماهنگی پارکینگ، و برای ناوگانهای خودران، عامل نظارت بر خودروی خودران است.
هر عامل دارای یک محدوده تعریف شده، یک قرارداد ورودی تعریف شده از لایه وضعیت عملیاتی، یک قرارداد خروجی تعریف شده به لایه اقدام، و یک پوشش استثنا تعریف شده است که مشخص میکند کدام موارد توسط عامل مدیریت میشوند و کدام موارد به لایه بالاتر ارجاع داده میشوند. نظم محدوده مهم است زیرا عواملی که سعی میکنند حوزههای زیادی را مدیریت کنند شکننده و دشوار میشوند. متدولوژی استقرار به نفع عوامل باریک متعدد نسبت به عوامل گسترده اندک است، با هماهنگی صریح بین عوامل برای مواردی که چندین حوزه را در بر میگیرند.
هماهنگی بین عوامل توسط یک عامل هماهنگکننده مدیریت میشود که رویدادهای ورودی را به عوامل تصمیمگیرنده مربوطه هدایت میکند و خروجیها را هنگامی که چندین عامل نیاز به هماهنگی دارند، ترکیب میکند. به عنوان مثال، درخواست مشتری برای یک سفر چند مرحلهای با یک قانون صورتحساب حساب شرکتی، نیاز دارد که عامل خدمات مشتری درخواست را تجزیه کند، عامل اعزام یک خودرو را اختصاص دهد، عامل مسیریابی دنباله چند مرحلهای را برنامهریزی کند، و عامل صورتحساب قیمتگذاری شرکتی را اعمال کند. هماهنگکننده ترتیب و جریان دادهها را بین عوامل مدیریت میکند.
لایه عامل تصمیمگیرنده جایی است که سیاست عملیاتی ناوگان در آن زندگی میکند. تغییرات در سیاست عملیاتی به عنوان تغییرات در پیکربندی عامل پیادهسازی میشوند تا تغییرات کد، که به تیم عملیات اپراتور اجازه میدهد بدون دخالت مهندسی، سیاست را تنظیم کند. مدل پیکربندی شامل قوانین قیمتگذاری، سیاستهای اختصاص، تعهدات سطح خدمات، آستانههای ارجاع، و پارامترهای انطباق نظارتی است.
لایه چهارم: لایه اقدام و یکپارچهسازی
لایه اقدام تصمیمات لایه عامل را به اقدامات در سیستمها و کانالهای پاییندستی اپراتور ترجمه میکند. لایه اقدام با برنامه راننده، برنامه مشتری، پردازنده پرداخت، سیستم مدیریت ناوگان، سیستم حسابداری، رابط گزارشدهی نظارتی و هر سرویس شخص ثالثی که ناوگان به آن وابسته است، ارتباط برقرار میکند. لایه اقدام جایی است که تصمیمات عامل به نتایج دنیای واقعی تبدیل میشوند.
انضباط معماری در این لایه، idempotency و قابلیت اطمینان است. یک تصمیم عامل باید دقیقاً یک اقدام پاییندستی تولید کند، حتی اگر لایه اقدام با خرابیهای موقت یا مشکلات شبکه مواجه شود. معماری این را از طریق الگوی صندوق خروجی تراکنشی به دست میآورد: تصمیم عامل به یک گزارش دائمی تعهد میشود، و لایه اقدام از گزارش میخواند و اقدام پاییندستی را با تضمینهای idempotency اجرا میکند. اگر یک اقدام پاییندستی با شکست مواجه شود، مجدداً امتحان میشود تا زمانی که موفق شود یا تا زمانی که یک اپراتور انسانی مداخله کند.
لایه اقدام همچنین جایی است که مسیر حسابرسی تصمیمات عملیاتی ثبت میشود. هر اقدامی که توسط لایه منتشر میشود، با عاملی که آن را تولید کرده است، وضعیت ورودی که تصمیم را اطلاعرسانی کرده است، نسخه سیاست اعمال شده، و سیستم پاییندستی که اقدام را اجرا کرده است، ثبت میشود. مسیر حسابرسی الزامات نظارتی سازمانهای حمل و نقل امارات را برآورده میکند و یک رکورد پزشکی قانونی از هر تصمیم عملیاتی ناوگان را به اپراتور ارائه میدهد.
لایه پنجم: لایه رسیدگی به استثنا و ارجاع
لایه رسیدگی به استثنا جزئی از معماری است که تعیین میکند آیا استقرار عامل در مواجهه با پیچیدگی عملیاتی واقعی جان سالم به در میبرد یا خیر. این لایه یک مدل استثنا سه لایه را پیادهسازی میکند: حل خودکار برای مواردی که در محدوده اطمینان و سیاست عامل قرار میگیرند، حل با کمک که در آن عامل توصیهای را آماده میکند و یک اپراتور انسانی آن را تأیید میکند، و ارجاع کامل به یک اپراتور انسانی برای مواردی که نیاز به قضاوت خارج از محدوده عامل دارند.
تعیین لایه برای هر مورد توسط امتیاز اطمینان عامل، حوزه سیاست تصمیم، و خطر عملیاتی یک تصمیم نادرست تعیین میشود. موارد با اطمینان بالا و خطر کم به طور خودکار حل میشوند. موارد با اطمینان پایینتر یا خطر بالاتر به حل با کمک هدایت میشوند، جایی که استدلال و اقدام توصیه شده عامل برای تأیید به یک اپراتور انسانی ارائه میشود. مواردی که به طور کلی خارج از کتابخانه سیاست عامل قرار میگیرند، به یک اپراتور انسانی ارجاع داده میشوند که تصمیم را بدون دخالت عامل مدیریت میکند.
لایه رسیدگی به استثنا مکانیزم عملیاتی است که به استقرار اجازه میدهد پیچیدگی دنیای واقعی را بدون نیاز به پیشبینی هر مورد مرزی در زمان طراحی مدیریت کند. موارد مرزی جدیدی که کتابخانه سیاست پوشش نمیدهد، در ابتدا به اپراتورهای انسانی هدایت میشوند، با الگوی تصمیمگیری اپراتور که ثبت شده و برای گسترش کتابخانه سیاست در طول زمان استفاده میشود. سیستم از ارجاعات خود یاد میگیرد و نرخ ارجاع با بلوغ کتابخانه سیاست کاهش مییابد.
معماری رسیدگی به استثنا یک الگوی استقرار خاص است که شرکتهای زیرساخت تولیدی در سراسر عمودیها اعمال میکنند. مدل سه لایه مورد استفاده در استقرارهای حمل و نقل امارات همان مدلی است که در خدمات مالی، مراقبتهای بهداشتی، حقوقی و سایر استقرارهای عمودی استفاده میشود، با کتابخانه سیاست و آستانههای اطمینان تنظیم شده با حوزه عملیاتی. سازگاری ساختاری در سراسر عمودیها چیزی است که به یک شرکت استقرار اجازه میدهد تا همان متدولوژی را در ۲۱ عمودی با سفارشیسازی جزئیات عملیاتی اعمال کند.
لایه ششم: لایه نظارت و ایمنی برای خودروهای خودران
برای ناوگانهای خودران، یک لایه اضافی بالای لایه وضعیت عملیاتی قرار میگیرد تا نظارت بر خودرو و مدیریت پرونده ایمنی را انجام دهد. لایه نظارت، تصمیمگیری خودروی خودران را در زمان واقعی نظارت میکند، تأیید میکند که اقدامات برنامهریزی شده خودرو در محدوده خودران قرار دارند، و زمانی که خودرو با موقعیتهایی مواجه میشود که از قابلیت خودران آن فراتر میرود، دخالت ناظر انسانی را فعال میکند.
لایه نظارت ضروری است زیرا خودروهای خودران در وضعیت فعلی فناوری در یک حوزه طراحی عملیاتی کار میکنند که شرایط خاصی را exclude میکند: آب و هوای نامساعد، مناطق ساختمانی پیچیده، انواع خاصی از تقاطعها و سایر موارد استثنائی تعریف شده. هنگامی که خودرو به یک شرایط خارج از حوزه طراحی عملیاتی خود نزدیک میشود، لایه نظارت یا خودرو را به یک وضعیت ایمن هدایت میکند و درخواست تحویل انسانی میدهد یا کنترل را به یک ناظر از راه دور واگذار میکند که سفر را از طریق تلهعملیات تکمیل میکند.
لایه نظارت با عوامل اعزام و مسیریابی یکپارچه میشود تا اطمینان حاصل شود که خودروهای خودران به سفرهایی اختصاص داده نمیشوند که نیاز به عملکرد خارج از حوزه طراحی عملیاتی خود داشته باشند. این یکپارچگی یک محدودیت بر منطق اختصاص عامل اعزام است: یک خودروی خودران تنها در صورتی برای یک درخواست واجد شرایط است که مسیر به طور کامل در حوزه طراحی عملیاتی آن قرار گیرد و پیشبینی شود شرایط برای مدت سفر در محدوده باقی بماند.
برای استقرارهای امارات، لایه نظارت همچنین گزارشدهی نظارتی مورد نیاز سازمان راهها و حمل و نقل دبی و سازمانهای معادل را نیز مدیریت میکند. عملیات خودروهای خودران مشمول الزامات گزارشدهی هستند که از گزارشدهی ناوگان معمولی فراتر میرود، و لایه نظارت دادهها را جمعآوری کرده و گزارشها را به عنوان یک خروجی عملیاتی مداوم به جای یک پروژه انطباق دورهای تولید میکند.
لایه هفتم: لایه نظارت و مشاهدهپذیری
لایه مشاهدهپذیری یک لایه عرضی است که سلامت و عملکرد سایر لایهها را نظارت میکند. این لایه معیارهای تأخیر، نرخ خطا، معیارهای کیفیت تصمیم، نرخ ارجاع استثناها و نرخ موفقیت اقدامات پاییندستی را ضبط میکند. معیارها در داشبوردهای عملیاتی تجمیع میشوند که تیم عملیات اپراتور از آنها برای نظارت بر عملکرد ناوگان در زمان واقعی استفاده میکند.
لایه مشاهدهپذیری همچنین نظارت بر عملکرد مدل را برای اجزای مدل زبان و مدل تصمیم پشته عامل مدیریت میکند. عملکرد مدل میتواند با گذشت زمان با تغییر الگوهای ورودی تغییر کند، و لایه نظارت تغییر را تشخیص داده و بازآموزی یا تنظیم آستانه را فعال میکند. تشخیص تغییر خودکار است، با هشدارهایی که برای بررسی به تیم عملیات یادگیری ماشین اپراتور هدایت میشوند.
برای زیرساخت عامل در سطح استقرار، لایه مشاهدهپذیری مکانیزم مسئولیت عملیاتی است که به اپراتور اجازه میدهد تا از عملکرد سیستم طبق مشخصات اطمینان حاصل کند. خروجی این لایه دادههایی است که از بررسیهای عملیاتی، حسابرسیهای نظارتی و چرخههای بهبود مستمر پشتیبانی میکند. بدون لایه مشاهدهپذیری، اپراتور نمیتواند نشان دهد که زیرساخت عامل تعهدات عملیاتی خود را برآورده میکند.
نحوه استقرار معماری در یک متدولوژی ۳۰ روزه
معماری هفت لایه در یک متدولوژی با دامنه ثابت استقرار مییابد که اپراتور را از یک ارزیابی عملیاتی تا یک پشته عامل در حال اجرا در یک بازه زمانی ۳۰ روزه هدایت میکند. این متدولوژی با ارزیابی هوش عملیاتی ۱۹ سوالی آغاز میشود که کاندیداهای خودکارسازی با ارزش بالا را شناسایی میکند، سپس از طریق طراحی معماری که سیستمهای موجود اپراتور را به هفت لایه نگاشت میکند، شامل کار یکپارچهسازی که پشته عامل را به محیط اپراتور متصل میکند، پوشش رسیدگی به استثناها را بر اساس تحمل ریسک اپراتور پیکربندی میکند و با انتقال عملیاتی و انتقال مالکیت کد به پایان میرسد.
جدول زمانی ۳۰ روزه یک تعهد استقرار است، نه یک جدول زمانی تحقیقاتی. این متدولوژی فرض میکند که سیستمهای موجود اپراتور پایدار و مستند هستند، سیاست عملیاتی میتواند در یک کتابخانه سیاست محدود مشخص شود، و دامنه استقرار در فاز اولیه بر تعداد کمی از عوامل متمرکز است. برای استقرارهایی با دامنه گستردهتر یا با سیستمهای اپراتور که قبل از یکپارچهسازی نیاز به اصلاح دارند، جدول زمانی به یک استقرار فازبندی شده با همان الگوی معماری که در سراسر فازها اعمال میشود، گسترش مییابد.
سرمایهگذاریهای استقرار برای استقرارهای متمرکز با چند عامل از دهها هزار دلار شروع میشود و بر اساس تعداد عامل، پیچیدگی یکپارچهسازی و دامنه عملیاتی مقیاسپذیر است. تمام استقرارها شامل یک هزینه انتقال زیرساخت هوش مصنوعی جداگانه در حدود چهارصد تا پانصد دلار در ماه از Pulse AI است که با قیمت تمام شده و بدون سود و زیان صورتحساب میشود. TFSF قیمتگذاری شفاف و طبقهبندی شده را در هر پیشنهاد منتشر میکند، و قیمتگذاری TFSF Ventures FZ-LLC منعکسکننده دامنه استقرار است تا تعهدنامههای نگهداری آزاد. برای اپراتورهایی که میپرسند آیا TFSF Ventures قانونی است، ساختار شرکت از طریق ثبت RAKEZ قابل تأیید است؛ بررسیهای TFSF Ventures به طور عمومی در دسترس نیستند زیرا شرکت یک سیاست محرمانگی مستند مشتری را حفظ میکند.
معماری در ۲۱ عمودی که TFSF Ventures در سراسر جهان ارائه میدهد، ثابت است، با جزئیات عملیاتی که برای هر عمودی سفارشیسازی شده است. عمودی حمل و نقل لایه نظارت را برای استقرارهای خودران اضافه میکند و لایه عامل تصمیم را برای عملیات ناوگان سفارشیسازی میکند، اما الگوی هفت لایه زیربنایی همانند خدمات مالی، مراقبتهای بهداشتی و سایر عمودیها است. سازگاری ساختاری چیزی است که به تعهد استقرار ۳۰ روزه امکان میدهد در سراسر زمینههای عمودی برقرار باشد.
معنی این معماری برای اپراتورهای امارات
اپراتورهای امارات که هم استقرار خودران و هم اتوماسیون ناوگان خصوصی را برنامهریزی میکنند، باید فروشندگان را بر اساس عمق معماری عامل به جای قابلیت هر مدل فردی ارزیابی کنند. لایه مدل در بین ارائهدهندگان به طور فزایندهای کالایی شده است، و تفاوت عملیاتی بین استقرارها از معماری بالای مدل و اطراف آن ناشی میشود. یک معماری عمیق با رسیدگی به استثناء صریح، مشاهدهپذیری قوی، و یکپارچگی منظم با سیستمهای اپراتور، استقراری را تولید میکند که مقیاسپذیر است. یک معماری کمعمق با یک مدل قدرتمند اما زیرساخت ضعیف اطراف آن، نمونهای اولیه را تولید میکند که برای رسیدن به تولید با مشکل مواجه است.
متدولوژی توصیف شده در اینجا یک مثال از یک معماری در سطح استقرار است که در الگوی استقرار ۳۰ روزه TFSF Ventures برای استقرار هوش مصنوعی حمل و نقل در خاورمیانه استفاده میشود. این متدولوژی در سراسر عمودیهایی که شرکت خدمات میدهد، یکسان است، با جزئیات عملیاتی که برای هر تعامل سفارشیسازی میشود. برای اپراتورهای امارات که در حال بررسی استقرار هستند، مکالمه معماری مفیدتر از مکالمه مدل است زیرا معماری تعیین میکند که آیا استقرار نتایج عملیاتی تولید میکند یا یک نمایش تحقیقاتی باقی میماند.
نحوه ترتیببندی استقرارهای اپراتورهای باتجربه
اپراتورهای حمل و نقل امارات که زیرساخت عامل را در چندین حوزه عملیاتی مستقر کردهاند، معمولاً استقرارهای خود را به گونهای ترتیببندی میکنند که اولویت با تأثیر عملیاتی باشد و تغییرات را در واحدهای قابل مدیریت جذب کنند. این الگو با اتوماسیون رو به مشتری آغاز میشود زیرا حجم کار خدمات مشتری بالا است و ریسک عملیاتی تصمیمات عامل توسط پوشش ارجاع محدود میشود. این الگو با اتوماسیون اعزام ادامه مییابد زیرا پیچیدگی عملیاتی بالا است و لایه عامل بهبود قابل اندازهگیری در بهرهبرداری ناوگان تولید میکند. این الگو در فازهای بعدی اتوماسیون صورتحساب و اتوماسیون عملیات ناوگان را اضافه میکند.
ترتیببندی اهمیت دارد زیرا هر فاز دادههای عملیاتی تولید میکند که پیکربندی فاز بعدی را اطلاعرسانی میکند. گزارشهای تعامل عامل خدمات مشتری، کتابخانه سیاست عامل اعزام را در مورد ترجیحات مشتری اطلاعرسانی میکند. الگوهای اختصاص عامل اعزام، منطق برنامهریزی راننده عامل عملیات ناوگان را اطلاعرسانی میکند. نتایج تطبیق عامل صورتحساب، پاسخ عامل خدمات مشتری را به اختلافات صورتحساب اطلاعرسانی میکند. استقرار فازبندی شده، یادگیری عملیاتی را که عوامل را به هم متصل میکند، جذب میکند.
برای اپراتورهایی که از یک پایه بدون زیرساخت عامل شروع میکنند، فاز اول توصیه شده ترکیب خدمات مشتری و اعزام است که در ۳۰ روز اول افزایش قابل اندازهگیری در چگالی عملیاتی تولید میکند و پایهای برای فازهای بعدی ایجاد میکند. برای اپراتورهایی که اتوماسیون خدمات مشتری بالغی دارند اما اتوماسیون سمت ناوگان ندارند، فاز بعدی توصیه شده اعزام است که حلقه بین تعامل با مشتری و اجرای عملیاتی را کامل میکند.
نحوه پشتیبانی معماری از بهبود مستمر
لایه مشاهدهپذیری معماری، دادههای عملیاتی را تولید میکند که از بهبود مستمر پشته عامل در طول زمان پشتیبانی میکند. این دادهها شامل معیارهای کیفیت تصمیم عامل، الگوهای ارجاع استثنا، سیگنالهای رضایت مشتری و معیارهای کارایی عملیاتی است. فرآیند بهبود از دادهها برای گسترش کتابخانه سیاست، بازآموزی اجزای مدل، تنظیم پوشش استثنا و بهبود یکپارچگی با سیستمهای پاییندستی استفاده میکند.
فرآیند بهبود مستمر پس از واگذاری توسط اپراتور مالکیت میشود، با شرکت استقرار که برای تعاملات اضافی در اهداف بهبود خاص در دسترس است. مدل مالکیت کد به این معنی است که اپراتور میتواند سیستم را با تیمهای داخلی، مهندسان شخص ثالث یا شرکت استقرار اصلی بسته به ترجیح اپراتور و دامنه بهبود گسترش دهد. این انعطافپذیری یک مزیت ساختاری مدل مالکیت کد بر مدل خدمات مدیریت شده است که در آن اپراتور برای هر تغییری به فروشنده وابسته است.
برای اپراتورهای امارات که گزینههای استقرار زیرساخت عامل را ارزیابی میکنند، سوال بهبود مستمر باید بخشی از معیارهای ارزیابی باشد. استقراری که برای هر تنظیم سیاست نیاز به دخالت فروشنده دارد، هزینههای کل مالکیت بالاتر و بهبود عملیاتی کندتری نسبت به استقراری با مالکیت کد و یک متدولوژی بهبود مستمر ساختاریافته تولید میکند.
معنی این برای بخش حمل و نقل امارات چیست؟
بخش حمل و نقل امارات به سمت یک الگوی ساختاری حرکت میکند که در آن ستون فقرات عامل، سیستم عامل ناوگان و وسایل نقلیه، ورودیهای سیستم هستند. این الگو برای عملیات مستقل، برای اتوماسیون ناوگان خصوصی، برای حمل و نقل بر اساس تقاضا، برای لجستیک و برای حمل و نقل شرکتی اعمال میشود. فروشندگانی که ستون فقرات عامل را مستقر میکنند، به طور فزایندهای از تولیدکنندگان وسایل نقلیه، پلتفرمهای فناوری و شرکتهای مشاوره متمایز میشوند، زیرا ستون فقرات، زیرساخت عملیاتی است و نه فناوری وسیله نقلیه یا توصیه استراتژیک.
برای اپراتورهایی که فاز بعدی نقشه راه هوش مصنوعی ناوگان خود در امارات را برنامهریزی میکنند، تصمیم معماری مهمترین تصمیم در ترتیب استقرار است. معماری انتخاب شده برای اولین استقرار، الگوی عملیاتی را برای سالها شکل میدهد و بر توانایی اپراتور برای جذب وسایل نقلیه خودمختار، گسترش به حوزههای عملیاتی جدید و انطباق با تغییرات نظارتی تأثیر میگذارد. معماری مناسب، معماری است که از الگوی عملیاتی خاص اپراتور پشتیبانی میکند، نه آنی که در یک نمایش فروشنده برنده میشود.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایهگذاری است که زیرساختهای عامل هوشمند را از طریق سه ستون مستقر میکند: زیرساختهای عاملی، مسیرهای پرداخت غیرسنتی و موتورهای سرمایهگذاری. TFSF با ۲۷ سال سابقه در پرداخت و نرمافزار، با متدولوژی استقرار ۳۰ روزه خود به ۲۱ بخش در سراسر جهان خدمات ارائه میدهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.
ارزیابی رایگان هوش عملیاتی را انجام دهید
به چند سوال کوتاه پاسخ دهید. یک طرح هوش مصنوعی سفارشی در عرض ۲۴ تا ۴۸ ساعت دریافت کنید که شامل توصیههای عامل، معماری و نقشه راه است. بدون تماس فروش. بدون تعهد. فقط داده. در https://tfsfventures.com/assessment شروع کنید.
Originally published at https://tfsfventures.com/blog/understanding-ai-agent-architecture-autonomous-transportation-private-fleet-operations
نوشته شده توسط واحد تحقیقات TFSF Ventures