تصمیمات معماری که بهترین عامل‌های هوش مصنوعی را برای سازمان‌های غیرانتفاعی از پروژه‌های آزمایشی که به آرامی بودجه گرنت آن‌ها به پایان می‌رسد جدا می‌کند

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

این مقاله методоولوژی به تصمیمات معماری می‌پردازد که تعیین می‌کنند آیا استقرار عامل‌های هوش مصنوعی از بودجه آزمایشی به بودجه عملیاتی منتقل می‌شوند یا خیر، با توجه به الگوهایی که به طور مداوم زیرساخت‌های بادوام تولید می‌کنند و الگوهایی که به طور مداوم درس‌های پرهزینه ایجاد می‌کنند. این چارچوب حول هفت نقطه تصمیم‌گیری ساخته شده است که رهبری عملیاتی باید قبل از شروع استقرار به صراحت حل کند.

تصمیم اول: بودجه عملیاتی را به عنوان افق واقعی تامین مالی در نظر بگیرید

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

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

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

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

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

تصمیم دوم: معماری را انتخاب کنید که تغییرات فروشنده را تحمل کند

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

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

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

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

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

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

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

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

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

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

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

تصمیم چهارم: رسیدگی به استثنائات را به عنوان یک نیاز معماری اصلی بسازید

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

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

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

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

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

تصمیم پنجم: ظرفیت نگهداری را قبل از شروع استقرار برنامه‌ریزی کنید

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

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

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

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

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

تصمیم ششم: بنیادهای داده را قبل از ساخت عامل‌ها معماری کنید

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

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

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

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

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

تصمیم هفتم: حاکمیت را فراتر از قهرمان استقرار تثبیت کنید

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

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

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

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

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

چگونه این تصمیمات در طول افق عملیاتی ترکیب می‌شوند

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

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

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

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

ضدالگوهای معماری رایج برای جلوگیری از آن

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

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

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

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

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

گفتگوی معماری که هیئت‌مدیره سازمان‌های غیرانتفاعی باید داشته باشند

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

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

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

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

چرا انضباط معماری مهم‌تر از انتخاب فروشنده است

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

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

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

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

درباره TFSF Ventures

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

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

Originally published at https://tfsfventures.com/blog/the-architecture-decisions-that-separate-the-best-ai-agents-for-nonprofit

Written by TFSF Ventures Research