در تیم هوش مصنوعی چه تصمیم هایی به راهبری معماری نیاز دارند؟

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

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

هوش مصنوعی تعداد این انتخاب ها را بالا برده است. یک قابلیت ممکن است همزمان به کد، داده اختصاصی، مدل، بازیابی، ابزار، هویت، ارزیابی و تایید انسانی وابسته باشد. راهنمای معماری بار های کاری هوش مصنوعی مایکروسافت این اجزا را لایه های سامانه می بیند که هر کدام با سرعت و ریسک متفاوتی تغییر می کنند. دستور مدل شاید هر روز عوض شود؛ اما قرارداد API یا مرز دسترسی به داده ممکن است چندین محصول را درگیر کند.

پرسش اصلی این نیست که آیا شرکت باید عنوان شغلی «معمار» داشته باشد. باید معلوم باشد چه کسی مسئول تصمیم هایی است که از یک تیم فراتر می روند، بیش از یک اسپرینت دوام می آورند و گزینه های بعدی را محدود می کنند.

اول مرز تصمیم را پیدا کنید

تیم های تحویل باید برای انتخاب های محلی اختیار داشته باشند. تایید مرکزی برای هر جزء رابط یا کتابخانه صف می سازد. از آن طرف، اختیار بی مرز هم به هویت های ناسازگار، داده تکراری، سکو های هم پوشان و اتصال های شکننده می انجامد.

جدول زیر کمک می کند تفاوت را ببینیم. این جدول حکم ثابت نیست؛ نشانه هایی است برای اینکه بدانیم تصمیم چه زمانی از دامنه یک تیم خارج می شود.

راهبری معماری مسئول کیفیت همه جزئیات پیاده سازی نیست؛ مسئول دیدن پیامد های مشترک است. اگر چند تیم برای یک مدل یا داده به شکل های ناسازگار متصل شوند، هزینه بعدا و معمولا در بدترین زمان ظاهر می شود.

تصمیم خوب باید قابل بازبینی باشد

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

این ثبت در سامانه های هوش مصنوعی اهمیت ویژه دارد، چون اجزا جداگانه عوض می شوند. شاید مدل تغییر کند، اما قرارداد برنامه ثابت بماند؛ شاید ابزار تازه ای به عامل اضافه شود و در نتیجه مرز تایید انسانی تغییر کند. اگر فقط نام فناوری را ثبت کرده باشیم، نمی فهمیم تغییر جزء چه اثری بر خطر کل سامانه گذاشته است.

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

معماری هوش مصنوعی، گردش کار را هم در بر می گیرد

درگاه مدل به تنهایی معماری نیست. سامانه به داده ای وابسته است که پاسخ را پشتیبانی می کند، دستور ها و هماهنگ سازی، ابزار های در دسترس عامل، آدم هایی که خروجی را تایید می کنند و گزارش هایی که خرابی را نشان می دهند.

از این رو معماری باید چند موضوع را از ابتدا در بر بگیرد:

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

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

خریدن، مسئولیت طراحی را حذف نمی کند

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

این پرسش ها را پیش از انتخاب فروشنده بپرسید، نه پس از امضای قرارداد. مقاله «انتخاب نرم افزار سازمانی متناسب با کار» به ارزیابی و ثبت تصمیم بیشتر می پردازد. ساختن و خریدن هم انتخاب یک باره نیست: سازمان ممکن است مدل را بخرد، هماهنگ سازی را خودش بسازد و ارزیابی را با ابزار دیگری انجام دهد. باید روشن باشد در رخداد هر بخش مسئولش کیست.

استاندارد را برای کم کردن کار تکراری به کار ببرید

استاندارد بد فقط کاغذبازی اضافه می کند. استاندارد خوب تصمیمی را می گیرد که تیم ها لازم نیست هر بار از نو بگیرند؛ برای نمونه روش مشترک هویت سرویس، نگهداری راز ها یا ثبت فعالیت ابزار.

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

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

بازبینی را به تغییر واقعیت وصل کنید

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

اگر چند تیم بار ها با تصمیم های ناسازگار روبه رو می شوند، مالک سامانه معلوم نیست یا پایلوت هوش مصنوعی بدون ارزیابی و پایش به محیط عملیاتی می رسد، شاید در راهبری معماری شکاف دارید. لازم نیست بلافاصله سازمان را بازچینی کنید. یک پروژه مهم را انتخاب کنید و بنویسید چه تصمیمی محلی است، چه چیزی مشترک، مسئول هر کدام کیست و چه زمانی باید دوباره بررسی شود.

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

مقاله های تبدیل راهبرد کسب و کار به جهت گیری قابل استفاده برای تیم های فنی و راهبرد ابر: انتخاب محل مناسب برای هر بار کاری به دو سوی همین کار می پردازند: ترجمه هدف کسب و کار به تصمیم فنی و انتخاب محل کار با توجه به محدودیت هایش.

مهدی لطفی نژاد متخصص داده و هوش مصنوعی، مشاور و مدرس رسمی با نزدیک به ۲۰ سال تجربه صنعتی است. او به صدها متخصص در خاورمیانه و جنوب شرق آسیا آموزش داده و در DATATWEETS می نویسد تا این تجربه عملی را رایگان و خودآموز در اختیار همه بگذارد.