تله معمار: وقتی محصول AIات روی زمین اجارهای ساخته میشه
هوش مصنوعیخلاصهٔ کاملتر
Kanupriya Yakhmi، معمار سابق سیستمهای Waymo، دانشجوی دکترای AI/ML و مدیر محصول با MBA اجرایی، توی یه جلسه Agile از یه بحران خاموش صحبت کرد: شرکتهایی که همه چیزشون رو روی یه provider هوش مصنوعی بنا کردن و فکر نکردن اگه «موجر» شرایط رو عوض کنه، چی میشه.
اون سه سوال رو بهعنوان حداقل due diligence قبل از راهاندازی هر محصول AI مطرح کرد. اول: آیا منطق اصلی کسبوکارت میتونه روی یه مدل دیگه بدون بازنویسی کامل اجرا بشه؟ اگه نه، مهاجرت یعنی rebuild کامل، نه refactor. دوم: آیا دادههای آموزشی، embeddingها و مجموعههای ارزیابی میتونن منتقل بشن؟ Kanupriya گفت گپهای ارزیابی «گرانترین نوع بدهی فنیاند.» سوم: آیا deploymentات بدون تغییر بنیادی در معماری میتونه به provider دیگهای بره؟ اگه نه، یه managed service داری با اسم خودت روش، نه یه محصول واقعی.
اون یه مدل چهار مرحلهای از درجه وابستگی ارائه داد. در مرحله ۱، همه فراخوانیهای AI مستقیم به SDK یه provider میرن — سریع برای ساخت، فاجعهبار برای خارج شدن. مرحله ۲ یه لایه انتزاعی داخلی اضافه میکنه تا جابهجایی مدل یه تغییر config بشه نه rebuild. مرحله ۳ یعنی جایگزینهای open-weight ارزیابی شدن، data pipelineها تحت کنترل خودتن، و فقط evaluation harness رو موقع مهاجرت باید عوض کنید. مرحله ۴ هم portability کامل زیرساخته؛ مدل، داده و compute مستقل از هم قابل جابهجاییاند.
یه نکته ظریفتر هم مطرح شد: وابستگی به vendor همیشه اشتباه نیست. سرعت ورود به بازار برای شرکتهای کوچیک حیاتیه و بعضیها عمداً اول روی سرویسهای خارجی ساختن، بازار رو گرفتن، و بعد به زیرساخت داخلی مهاجرت کردن. مشکل وقتیه که یه تصمیم prototype بهصورت دائمی باقی میمونه. اون با مفهوم SOM (serviceable obtainable market) توضیح داد که وابستگیهای AI میتونن بازار واقعی قابل دسترس شما رو کوچیکتر از چیزی کنن که فکر میکردید.
جالبترین بخش صحبتش «Agile 2.0» بود — پیشنهادی برای ادغام ریسکهای vendor خارجی توی سرمونیهای Agile. چیزایی مثل: «چی توی upstream عوض شده که ممکنه چیزی رو خراب کنه؟» باید صریحاً توی standup مطرح بشن، deprecation timeline مدلها باید توی sprint planning دیده بشه، و retrospectiveها باید بپرسن آیا رفتار vendor داره بدهی فنی ناخواسته درست میکنه. بهعلاوه، تیمهای مختلف با dependency surface فرقدار باید Agile process مخصوص به خودشون داشته باشن، نه یه قالب یکسان برای همه.
نکات کلیدی:
- اگه مدل AI رو نمیشه بدون rebuild عوض کرد، در واقع یه managed service با لوگوی خودت داری، نه محصول AI
- evaluation harness (ابزار بررسی عملکرد AI) اولین چیزیه که تیمها skip میکنن و گرانترین بدهی فنیه
- وابستگی به vendor در مرحله prototype میتونه آگاهانه و درست باشه، به شرطی که بعداً بازبینی بشه
- Agile باید ریسکهای خارج از سازمان (تغییر مدل، deprecation، تغییر قیمت) رو هم track کنه
- تیمها اغلب تصمیمات معماری قبل از پیوستنشون رو به ارث میبرن — بدون اینکه بدونن چرا اون انتخابها گرفته شدن
