برای هوش مصنوعی، زیرساخت بزرگ بخریم یا از چیزی که داریم بهتر استفاده کنیم؟

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

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

سه تصمیم که بهتر است جدا بگیریم

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

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

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

هزینه واقعی فقط قیمت هر درخواست نیست

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

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

فناوری قابل تعویض، تصمیم قابل دفاع

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

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

معماری را از سفر یک درخواست بشناسید

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

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

ابر، زیرساخت داخلی یا ترکیبی؟

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

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

متن باز و بسته، دو نوع معامله اند

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

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

هزینه کل مالکیت را ببینید

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

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

از آزمایش مستقل به استاندارد سازمانی برسید

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

معماری را با چند سناریوی شکست امتحان کنید

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

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

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

زیرساخت خوب همیشه بزرگ ترین و تازه ترین نیست. زیرساختی است که نیاز امروز را پاسخ دهد و فردا سازمان را اسیر انتخاب امروز نکند.