تفاوت بین پلتفرمهای عامل هوش مصنوعی با اشتراک ماهانه و پیادهسازیهایی که مالکیت کامل آنها را دارید
مقایسهای واضح از پلتفرمهای عامل هوش مصنوعی مبتنی بر اشتراک و پیادهسازیهای با مالکیت کامل، از نظر هزینه، کنترل داده و ریسک وابستگی بلندمدت.
سریعترین رشد در صنعت نرمافزار سازمانی، به عوامل خودمختار اختصاص دارد و سریعترین مدل قیمتگذاری متصل به این دسته، اشتراک ماهانه است. این دو روند با هم ظهور کردند و برای اکثر خریداران جدایی ناپذیر به نظر میرسند. اما اینطور نیست. تفاوت معنادار و فزایندهای بین پلتفرمهای عامل هوش مصنوعی با اشتراک ماهانه و پیادهسازیهای عامل هوش مصنوعی با مالکیت کامل وجود دارد و این تفاوت در ترازنامه، کتابچه راهنمای عملیاتی و ریسک حقوقی هر شرکتی که یکی از این دو را انتخاب میکند، مشهود است. وظیفه خریدار این است که این تفاوت را درک کرده و آگاهانه انتخاب کند، نه بر اساس پیشفرض.
پلتفرم اشتراکی واقعاً چیست؟
یک پلتفرم عامل هوش مصنوعی اشتراکی، سرویسی است که مشتری آن را اجاره میکند. فروشنده کد، منطق هماهنگی، دسترسی به مدل، داشبوردها، یکپارچهسازیها و زمان اجرای عملیاتی را میزبانی میکند. مشتری وارد سیستم میشود، گردش کارهای خود را از بین بلوکهای موجود پیکربندی میکند، پلتفرم را به دادههای خود متصل میکند و هزینهای دورهای بر اساس تعداد عاملها، اقدامات، کاربران یا ترکیبی از هر سه پرداخت میکند.
این مدل مزایای واقعی دارد. مشتری نیازی به تیم مهندسی برای نگهداری پلتفرم ندارد. فروشنده مسئولیت زمان کارکرد، پچهای امنیتی، ارتقاء مدل و انتشار ویژگیهای جدید را بر عهده میگیرد. برای شرکتی که میخواهد عاملها به سرعت راهاندازی شوند و با پرداخت نامحدود برای این راحتی مشکلی ندارد، یک پلتفرم اشتراکی در عرض چند روز پس از امضای قرارداد، ارزش را ارائه میدهد.
نقطه ضعف آن ساختاری است. مشتری هرگز مالک عاملها نمیشود. مشتری مالک پیکربندی عاملها است، و حتی همین مالکیت نیز توسط آنچه پلتفرم اجازه میدهد محدود میشود. عاملها در زمان اجرای فروشنده، در برابر لایه هماهنگی فروشنده، با گزارشهایی که در زیرساخت فروشنده ذخیره میشوند، اجرا میشوند. اگر مشتری بخواهد عاملهای خود را به جای دیگری منتقل کند، هیچ چیز فیزیکی برای انتقال وجود ندارد. پیکربندی در تئوری قابل حمل است و در عمل به دام افتاده است زیرا زمان اجرایی که آن را تفسیر میکند در نزد فروشنده قرار دارد.
این مدلی است که صنعت آن را «وابستگی به پلتفرم» مینامد. گردش کارهای عملیاتی مشتری در محصول فروشنده جاسازی میشود. هزینه ترک کردن، فقط هزینه اشتراک بعدی نیست. این هزینه بازسازی تمام چیزهایی است که در طول سالها استفاده مشتری از پلتفرم پیکربندی شده بود.
پیادهسازی با مالکیت کامل واقعاً چیست؟
یک پیادهسازی با مالکیت کامل، شیء فیزیکی متفاوتی است. مشتری یک ساخت سفارش میدهد. این ساخت، یک پایگاه کد را ارائه میدهد که عاملها را اجرا میکند، یک پیکربندی زیرساخت که آنها را میزبانی میکند و مجموعهای از دفترچههای عملیاتی که نحوه کارکرد آنها را توصیف میکند. مشتری کد منبع را در اختیار دارد. مشتری زیرساخت را میزبانی میکند. مشتری میتواند هر بخش از سیستم را بدون اجازه هیچ کس بخواند، تغییر دهد، گسترش دهد، جایگزین کند یا خاموش کند.
کار برای رسیدن به این نقطه سنگینتر از امضای یک اشتراک است. یک فرآیند پیادهسازی وجود دارد. یک تیم ساخت وجود دارد. یک فاز یکپارچهسازی وجود دارد. مشتری باید قبل از امضای قرارداد به مالکیت مهندسی فکر کند، زیرا کسی باید سیستم را پس از تحویل عملیاتی کند، و این فرد یا یک تیم داخلی، یک شرکت قراردادی یا یک توافق با سازنده اولیه است.
آنچه مشتری در پایان ساخت دریافت میکند، پایدار است. عاملها بر روی زیرساختی اجرا میشوند که مشتری مستقیماً هزینه آن را پرداخت میکند، معمولاً با هزینه اولیه ارائهدهندگان ابری و مدل هوش مصنوعی بدون هیچ گونه افزایش قیمتی. ساختار هزینه قابل پیشبینی میشود. هزینه دیگر با تصمیمات قیمتگذاری فروشنده افزایش نمییابد. با میزان استفاده افزایش مییابد، و میزان استفاده با کسب و کار مشتری به روشهایی که مشتری میتواند مدلسازی کند، افزایش مییابد.
این همان چیزی است که نتایج عوامل هوش مصنوعی تولیدی بدون وابستگی به فروشنده، به طور ملموس به معنای آن است. عاملها خروجی تولید میکنند. خروجیها به عملیات مشتری سرازیر میشوند. هزینه تولید این خروجیها، هزینه محاسبات، هزینه فراخوانی مدل و هزینه ذخیرهسازی است. هیچ هزینه پلتفرمی وجود ندارد. هیچ مجوز به ازای هر عامل وجود ندارد. هیچ مذاکرهای در زمان تمدید وجود ندارد زیرا هیچ تمدیدی در کار نیست.
جایی که هزینهها در طول زمان واگرا میشوند
مقایسه هزینه سال اول بین یک پلتفرم اشتراکی و یک پیادهسازی با مالکیت کامل به ندرت به نفع مالکیت است. یک اشتراک برای چهار عامل با قیمتگذاری معمول سازمانی ممکن است بسته به حجم، سالانه بیست تا پنجاه هزار دلار هزینه داشته باشد. یک پیادهسازی با مالکیت کامل برای همان چهار عامل به سرمایهگذاری اولیه در حدود چند ده هزار دلار به علاوه هزینههای جاری زیرساخت نیاز دارد. در سال اول، این دو عدد مشابه به نظر میرسند.
در سال دوم، مقایسه شروع به واگرایی میکند. اشتراک تمدید میشود، اغلب با افزایش قیمت مرتبط با رشد استفاده، تصمیمات قیمتگذاری فروشنده یا هر دو. پیادهسازی با مالکیت کامل با همان هزینه زیرساختی که در سال اول داشت، به کار خود ادامه میدهد. هزینه زیرساخت ممکن است با استفاده افزایش یابد، اما به صورت خطی با آنچه کسبوکار واقعاً مصرف میکند، افزایش مییابد، نه با آنچه فروشنده تصمیم به شارژ آن میگیرد.
در سال سوم، این شکاف بیشتر میشود. شرکتی که از چهار عامل به دوازده عامل مقیاسبندی کرده است، یا سه برابر تعداد اشتراکها را پرداخت کرده یا پیادهسازی با مالکیت کامل خود را برای مدیریت عاملهای اضافی گسترش داده است. هزینه گسترش یکبار است. هزینه اشتراک برای همیشه است. تا پایان سال سوم، هزینهکرد تجمعی بر روی یک پلتفرم اشتراکی معمولاً دو تا چهار برابر هزینهکرد تجمعی بر روی یک پیادهسازی با مالکیت کامل با دامنه مشابه است.
اقتصاد زمانی اهمیت بیشتری پیدا میکند که میزان استفاده مقیاسپذیر باشد. شرکتی که ده هزار تراکنش در ماه را از طریق یک پلتفرم اشتراکی پردازش میکند، قیمتی متفاوت از شرکتی که یک میلیون تراکنش را پردازش میکند، پرداخت میکند. شرکتی که یک میلیون تراکنش را از طریق یک پیادهسازی با مالکیت کامل پردازش میکند، فقط هزینه محاسبات اضافی و فراخوانی مدل را پرداخت میکند. هیچ هزینه اضافی به ازای هر تراکنش وجود ندارد. هزینه نهایی میلیونمین تراکنش، هزینه نهایی فراخوانی مدلی است که آن را تامین کرده است.
چه اتفاقی میافتد وقتی یک فروشنده اشتراکی قیمتگذاری خود را تغییر میدهد؟
مهمترین ریسک نادیده گرفته شده در پلتفرمهای عامل مبتنی بر اشتراک، عدم تقارن در مذاکرات تمدید است. فروشنده دقیقاً میداند که پلتفرم او چقدر در عملیات مشتری جاسازی شده است. مشتری اغلب این را نمیداند. وقتی تمدید با افزایش قیمت سی درصدی میرسد، گزینههای مشتری عبارتند از پذیرش، مذاکره از موضع ضعف، یا تغییر.
تغییر در اسلایدها ساده به نظر میرسد و در عمل به ندرت ساده است. عاملهایی که مشتری در طول دو سال ساخته است، قابل انتقال به پلتفرم دیگری نیستند، زیرا زبان گردش کار، الگوهای یکپارچهسازی و منطق محرک، مختص فروشنده هستند. مهاجرت عملاً یک بازسازی است، در یک بازه زمانی فشرده، با فشار فروشنده برای رعایت زمان. اکثر مشتریان افزایش را میپذیرند. این الگو تکرار میشود.
یک پیادهسازی با مالکیت کامل، عدم تقارن را به طور کامل از بین میبرد. هیچ تمدیدی وجود ندارد. هیچ مذاکرهای وجود ندارد. ارائهدهندگان زیرساخت که مشتری از آنها استفاده میکند، چه فروشندگان ابری و چه مدل، دینامیکهای قیمتگذاری خاص خود را دارند، اما این هزینهها قابل مشاهده، با قیمت بازار و قابل جایگزینی هستند. اگر یک ارائهدهنده مدل قیمتها را افزایش دهد، مشتری میتواند مدلها را بدون اخلال در منطق عامل تغییر دهد. اگر یک ارائهدهنده ابری قیمتها را افزایش دهد، مشتری میتواند زیرساخت را بدون بازسازی عاملها جابجا کند.
این قابلیت انتخاب، همان چیزی است که عاملهای هوش مصنوعی بدون وابستگی به پلتفرم فراهم میکنند. مشتری به فناوری زیربنایی وابسته است که جایگزینهای رقابتی دارد، نه به زمان اجرای یک فروشنده خاص که اینگونه نیست.
چرا مالکیت کد مهمترین بند است
در هر قرارداد بین مشتری و یک شرکت پیادهسازی عامل، بند حیاتی، بندی است که به مالکیت کد اشاره دارد. زبان مهم است زیرا تفاوتهای ظریفی دارد و پیامدهای جدی. برخی قراردادها به مشتری مجوز دائمی استفاده از عاملها را اعطا میکنند در حالی که فروشنده مالکیت را حفظ میکند. برخی دیگر دسترسی به یک نمونه پیکربندی شده را اعطا میکنند در حالی که کد زیربنایی اختصاصی باقی میماند. برخی نیز مالکیت کامل codebase را به مشتری منتقل میکنند بدون هیچ هزینه مجوز مستمر و بدون وابستگی عملیاتی به شرکت پیادهسازی.
تنها آخرین مورد از اینها استقلال واقعی را به ارمغان میآورد. مجوز دائمی هنوز یک مجوز است. همراه با محدودیتها، شرایط استفاده، و طرف مقابلی که میتواند رابطه را در صورت تغییر اوضاع کسبوکار تغییر دهد. انتقال مالکیت متفاوت است. مشتری کد منبع، اسکریپتهای استقرار، مستندات و حق اصلاح یا گسترش را بدون نیاز به اجازه بیشتر دریافت میکند.
سوال مهمی که هر خریدار باید قبل از امضا بپرسد این است که آیا قرارداد مالکیت را ارائه میدهد یا دسترسی. پاسخ تقریباً همیشه در قرارداد موجود است، اما به ندرت برجسته میشود. یک آزمایش ساده این است که از فروشنده بپرسید چه اتفاقی میافتد اگر مشتری رابطه را در روز سی و یکم پس از استقرار فسخ کند. اگر عاملها از کار بیفتند، مشتری مالک آنها نیست. اگر عاملها به کار خود ادامه دهند و مشتری به عملیات آنها ادامه دهد، مشتری مالک آنها است.
TFSF Ventures هر استقرار را حول پاسخ دوم ساختار میدهد. codebase در پایان استقرار سی روزه به مخزن مشتری منتقل میشود. زیرساخت در حساب ابری مشتری اجرا میشود. دسترسی به مدل از طریق کلیدهای API مشتری انجام میشود. پس از روز سی، مشارکت TFSF هر چیزی است که مشتری به صورت پروژهای انتخاب کند. عاملها بدون توجه به این مسائل به کار خود ادامه میدهند.
هزینههای پنهان داخلی در پلتفرمهای ماهانه
صفحات قیمتگذاری اشتراک، هزینه اصلی را لیست میکنند. هزینه واقعی راهاندازی یک استقرار عامل مبتنی بر پلتفرم به روشهایی که به راحتی نادیده گرفته میشوند، بالاتر است. معمولاً به ازای هر یکپارچهسازی هزینهای وجود دارد. اغلب به ازای هر اقدامی که از یک آستانه فراتر رود، هزینهای اعمال میشود. گاهی اوقات برای ارائهدهنده مدل، زمانی که پلتفرم API زیربنایی را نشانهگذاری میکند، هزینهای وجود دارد. اغلب برای پشتیبانی premium هزینهای وجود دارد که در صورت تولید درخواستهای مسدودکننده تولید توسط tier رایگان پلتفرم، ضروری میشود.
هر یک از این هزینهها به خودی خود منطقی هستند و به معنای فریبکاری پنهان نیستند. آنها صرفاً هزینههای اضافی هستند. خریداری که فقط به هزینه اصلی نگاه کرده و سه سال هزینه را با آن نرخ پیشبینی کرده باشد، هزینه واقعی را در اکثر استقرارها در مقیاس، سی تا پنجاه درصد کمتر برآورد خواهد کرد.
پیادهسازیهای با مالکیت اختصاصی هزینههای خود را دارند و یک فروشنده جدی آنها را قبل از امضای قرارداد به طور شفاف توضیح میدهد. هزینه اولیه ساخت وجود دارد. هزینههای جاری زیرساخت، که همان هزینه واقعی محاسبات و فراخوانی مدل بدون افزایش قیمت است، وجود دارد. اگر مشتری تصمیم بگیرد سیستم را به صورت داخلی مدیریت نکند، یک توافقنامه نگهداری نیز وجود دارد. این سه مورد کل ساختار هزینه را تشکیل میدهند. هیچ هزینهای به ازای هر یکپارچهسازی، هیچ هزینه اضافی به ازای هر اقدام، و هیچ سطح پشتیبانی premium وجود ندارد زیرا هیچ صاحب پلتفرمی برای شارژ آنها وجود ندارد.
پیادهسازیهای TFSF Ventures با این روش شفاف قیمتگذاری میشوند. TFSF Ventures FZ-LLC (RAKEZ License 47013955) هزینه ساخت، هزینه جاری زیرساخت حدود چهارصد تا پانصد دلار در ماه به صورت هزینهای و هر توافقنامه نگهداری اختیاری را در پیشنهاد خود منتشر میکند. مشتری قبل از امضای قرارداد کل هزینه را میبیند. برای خریدارانی که میپرسند آیا تیم زیرساخت عامل معتبر است، ثبت RAKEZ با RAKEZ License 47013955 و انتقال مالکیت کد قراردادی، حقایق قابل تأییدی هستند که یک پیادهسازی واقعی را از یک رابطه فروشنده که به عنوان یک پیادهسازی ظاهر میشود، متمایز میکنند.
چه اتفاقی برای دادههایی که عاملها تولید میکنند، میافتد؟
یک پلتفرم اشتراکی، گزارشها، تاریخچههای گفتگو، تعاملات مشتری و خروجیهای عملیاتی را روی زیرساختی که فروشنده کنترل میکند، ذخیره میکند. دادههای مشتری نزد فروشنده قرار میگیرد. دسترسی توسط شرایط و ضوابط فروشنده کنترل میشود. نگهداری توسط سیاست فروشنده تعیین میشود. صادرات امکانپذیر است اما به ندرت بدون مشکل انجام میشود.
این مشکل در سه سناریو به یک مشکل ملموس تبدیل میشود. اول، زمانی که مشتری میخواهد از دادههای عملیاتی برای آموزش یک مدل یا سیستم تحلیلی استفاده کند، دادهها باید از پلتفرم استخراج شوند، که گاهی محدود است. دوم، زمانی که مشتری مشمول درخواست نظارتی یا حسابرسی است، زمان پاسخ به سرعت عمل فروشنده بستگی دارد، نه مشتری. سوم، زمانی که رابطه با فروشنده به پایان میرسد، دادهها یا با مشتری همراه میشوند یا نمیشوند، بسته به قرارداد.
یک پیادهسازی با مالکیت کامل، دادهها را در فضای ذخیرهسازی که مشتری کنترل میکند، مینویسد. گزارشها در پایگاه داده مشتری قرار میگیرند. تعاملات در انبار داده مشتری قرار میگیرند. مشتری میتواند این دادهها را بدون دخالت هیچ کس دیگری تجزیه و تحلیل، نگهداری، حذف یا صادر کند. این آزادی ساختاری است. به سیاستهای فروشنده وابسته نیست زیرا هیچ فروشنده پلتفرمی که ذخیرهسازی را کنترل کند وجود ندارد.
برای شرکتهای فعال در صنایع تحت نظارت، از جمله خدمات مالی، مراقبتهای بهداشتی، حقوقی و هر کسب و کاری که با دادههای شخصی تحت رژیمهای حریم خصوصی مدرن سروکار دارد، این تفاوت یک تعیینکننده عملی برای انطباق است. یک پلتفرم اشتراکی از مشتری میخواهد به کنترلهای فروشنده اعتماد کند. یک پیادهسازی با مالکیت کامل، کنترلها را در محدوده حسابرسی خود مشتری قرار میدهد.
چرا برخی استقرارها شبیه پلتفرم هستند اما در واقع مالکیت آنها با مشتری است؟
یک الگوی ظریف که خریداران باید آن را تشخیص دهند، شرکت پیادهسازی است که از ابزارهای پلتفرمی استفاده میکند اما نتیجهای با مالکیت کامل ارائه میدهد. شرکت عاملها را با استفاده از فریمورکهای داخلی خود میسازد، آنها را برای گردش کارهای مشتری پیکربندی میکند و در پایان ساخت، کل پشته شامل کد فریمورک را به مشتری منتقل میکند. مشتری با چیزی روبرو میشود که شبیه یک پلتفرم است اما در واقع یک codebase است که مشتری مالک آن است.
این الگو به طور فزایندهای رایج است زیرا سرعت توسعه به سبک پلتفرم را با مالکیت ساختهای سفارشی ترکیب میکند. شرکت از استفاده مجدد داخلی در طول توسعه بهره میبرد. مشتری از زمان تحویل سریعتر بهره میبرد. قرارداد از انتقال مالکیت واضح در پایان ساخت بهره میبرد.
این الگو تنها زمانی کار میکند که کد فریمورک واقعاً قابل انتقال باشد و مشتری ظرفیت مهندسی یا رابطه قراردادی برای نگهداری آن را داشته باشد. یک فریمورک که برای عملکرد به ابزارهای شرکت اصلی نیاز دارد، پلتفرمی مبدل است. یک فریمورک که مستند شده، دارای کنترل نسخه و توسط هر تیم مهندسی باصلاحیت قابل اجرا است، یک محصول قابل تحویل واقعی است.
شریک پیادهسازی در TFSF Ventures به طور ذاتی از این الگو استفاده میکند. عاملها با استفاده از الگوهای استقرار داخلی ارائهدهنده زیرساخت ساخته میشوند، اما محصول قابل تحویل در پایان ساخت سی روزه یک codebase کامل شامل کد فریمورک، منطق عامل، آداپتورهای یکپارچهسازی و runbookهای عملیاتی است. مشتری میتواند شرکت پیادهسازی را برای گسترشها درگیر کند، یک تیم داخلی برای نگهداری سیستم استخدام کند یا یک شرکت دیگر را برای به عهده گرفتن عملیات قرارداد کند. فریمورک مشتری را به هیچ یک از این انتخابها محدود نمیکند.
چارچوب تصمیمگیری برای خریداران
انتخاب بین یک پلتفرم اشتراکی و پیادهسازی با مالکیت کامل یک سوال اخلاقی نیست. هر دو مدل موارد استفاده مشروعی دارند. تصمیم باید آگاهانه و بر اساس سه عامل گرفته شود: طول عمر مورد انتظار پیادهسازی، ظرفیت مهندسی موجود برای عملیات آن، و اهمیت استراتژیک عملیاتی که عاملها اجرا خواهند کرد.
اگر پیادهسازی آزمایشی است، انتظار میرود کمتر از یک سال کار کند و مشتری ظرفیت مهندسی برای عملیات آن ندارد، یک پلتفرم اشتراکی پاسخ صحیح است. مصالحه در وابستگی و هزینههای جاری قابل قبول است زیرا افق زمانی کوتاه است و وابستگی عملیاتی کم است.
اگر پیادهسازی هسته اصلی عملیات است، انتظار میرود به طور نامحدود کار کند، و مشتری یا مهندسی داخلی دارد یا یک رابطه قراردادی، یک پیادهسازی با مالکیت کامل تقریباً همیشه پاسخ صحیح است. هزینه اولیه در طی هجده تا بیست و چهار ماه اول عملیات بازیابی میشود. عدم مواجهه با تمدید در طول عمر سیستم بیشتر میشود. آزادی برای اصلاح، گسترش و جایگزینی اجزا، گزینههای استراتژیکی را تولید میکند که پلتفرمهای اشتراکی به طور ساختاری نمیتوانند ارائه دهند.
مورد میانی، جایی که مشتری در مورد طول عمر یا ظرفیت نامطمئن است، جایی است که تصمیمگیری نیاز به بیشترین تحلیل دارد. خریداری در این موقعیت باید هزینههای مورد انتظار سه ساله و پنج ساله هر دو گزینه را ترسیم کند، احتمال اینکه عملیات در طول زمان حیاتیتر شود را در نظر بگیرد، و ارزش گزینه مالکیت کد را در مقابل راحتی عملیات فروشنده بسنجد. در بیشتر موارد، تحلیل زودتر از آنچه که شهود اولیه خریدار نشان میدهد، به سمت مالکیت اشاره میکند.
این محاسباتی است که پیادهسازی هوش مصنوعی را به عنوان یک انتخاب آگاهانه و نه پیشفرض، به کنترل کامل شما در میآورد. پیشفرض در بازار فعلی اشتراک است، زیرا اشتراک چیزی است که اکثر فروشندگان میفروشند. انتخاب آگاهانه، به طور فزایندهای، مالکیت است، زیرا محاسبات برای هر عملیاتی که شرکت قصد دارد بیش از دو سال اجرا کند، کارایی دارد.
مهاجرت از اشتراک به مالکیت چگونه به نظر میرسد؟
شرکتهایی که دو یا سه سال با پلتفرمهای اشتراکی کار کردهاند و تصمیم به مهاجرت به یک پیادهسازی با مالکیت کامل میگیرند، با مجموعهای از سوالات خاص مواجه میشوند. اولین سوال این است که چه چیزی را حفظ کنند. برخی از گردش کارها به اندازهای خوب پیکربندی شدهاند که باید تکرار شوند و نه دوباره طراحی گردند. سوال دوم این است که چه چیزی را کنار بگذارند. برخی از گردش کارها در طول زمان انباشته شدهاند زیرا پلتفرم افزودن آنها را آسان کرده بود، نه به این دلیل که ضروری بودند.
یک مهاجرت خوب، این مرحله را فرصتی برای حسابرسی میداند. عاملهایی که کارهای مهمی انجام میدادند، به طور تمیز در کد پایه جدید بازسازی میشوند. عاملهایی که فقط اجرا میشدند چون کسی آنها را غیرفعال نکرده بود، کنار گذاشته میشوند. یکپارچهسازیهای مهم به زیرساخت جدید متصل میشوند. یکپارچهسازیهای آزمایشی قبل از بازسازی، از نظر مشارکت واقعیشان ارزیابی میشوند.
زمانبندی مهاجرت برای یک پیادهسازی متوسط در بازار، شش تا دوازده هفته است. هفتههای اول حسابرسی و طراحی است. هفتههای میانی ساخت و عملیات موازی است. هفتههای پایانی جابجایی و از کار انداختن اشتراک قبلی است. هزینه مهاجرت معمولاً در هشت تا چهارده ماه اول پس از جابجایی از طریق حذف هزینه اشتراک بازیابی میشود.
نحوه مطالعه قراردادهای فروشنده توسط خریداران قبل از امضا
تفاوتهای بین اشتراک و مالکیت به ندرت در صفحه بازاریابی ظاهر میشوند. آنها در قرارداد نمایان میشوند. خریدارانی که قرارداد را قبل از امضا به دقت مطالعه میکنند، مدل را به درستی شناسایی میکنند. خریدارانی که به صحبتهای فروشنده متکی هستند، اغلب مدل را تنها در اولین تمدید کشف میکنند.
بندهایی که باید مطالعه شوند شامل بند مالکیت، بند فسخ، بند نگهداری دادهها و بند اصلاح است. بند مالکیت مشخص میکند که چه کسی حقوق کد و پیکربندی عامل را در اختیار دارد. بند فسخ مشخص میکند که در صورت پایان یافتن رابطه چه اتفاقی میافتد، از جمله اینکه آیا عاملها به کار خود ادامه میدهند یا خیر. بند نگهداری دادهها مشخص میکند که دادههای عملیاتی کجا قرار دارند و چه کسی میتواند به آنها دسترسی داشته باشد. بند اصلاح مشخص میکند که آیا مشتری میتواند سیستم را به طور مستقل گسترش دهد یا خیر.
قرارداد یک پلتفرم اشتراکی، مالکیت کد را منتقل نمیکند، عملیات عامل را در صورت فسخ پایان میدهد، دادهها را در زیرساخت فروشنده نگهداری میکند و اصلاحات را به آنچه پلتفرم پشتیبانی میکند محدود میکند. قرارداد یک پیادهسازی با مالکیت کامل، مالکیت را منتقل میکند، بر عملکرد عامل در صورت فسخ تأثیری نمیگذارد، دادهها را در زیرساخت مشتری نگهداری میکند و امکان اصلاحات نامحدود را فراهم میآورد. زبان قرارداد زمانی که خریدار بداند به دنبال چه چیزی باشد، unambiguous است.
درباره 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-difference-between-ai-agent-platforms-that-charge-monthly-and-deployments-you-own
Written by TFSF Ventures Research