سکوی داخلی هوش مصنوعی

مسئله، «داشتن یک مدل» نبود.

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

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

تمرکز من روی ساختن یک «لایه» بود، نه نصب یک ابزار.

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

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

مصرف‌کننده‌ها از مدل‌ها جدا شدند.

یک Gateway مشترک میان تجربه کاربر و مقصد مدل قرار گرفت؛ جایی که مسیریابی، سیاست مصرف و مشاهده‌پذیری بتوانند مستقل از رابط کاربری یا ارائه‌دهنده مدیریت شوند.

چند تصمیم معماری، پلتفرم را از یک اتصال ساده جدا کردند.

معماری خوب، حذف مصالحه نیست؛ آشکار کردن آن‌هاست.

خروجی اصلی، یک نقطه کنترل مشترک بود.

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

بخش سخت AI سازمانی، اغلب خود مدل نیست.

ارزش معماری زمانی روشن می‌شود که مدل‌ها، قیمت‌ها و کیفیت‌ها تغییر می‌کنند؛ آن‌وقت مرزبندی درست سرویس‌ها مهم‌تر از انتخاب اولیه یک مدل خاص است.

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