معماری و اجرا · ۹ دقیقه مطالعه · بنیان‌گذاران، مدیران محصول و رهبران تیم‌هایی که می‌خواهند قابلیت AI را به محصول واقعی تبدیل کنند
قبل از انتخاب مدل AI، معماری تصمیم بگیرید؛ راهنمای portability، هزینه و fallback
مدل AI فقط یکی از اجزای یک قابلیت محصولی است. تصمیم پایدار از مسئله، داده و معیار موفقیت شروع می‌شود و بعد به انتخاب مدل می‌رسد.
- مدل AI خروجی معماری و مسئله است، نه نقطهٔ شروع آن.
- portability یعنی مدیریت وابستگی و داشتن مسیر خروج، نه وعدهٔ تعویض بدون هزینه.
- داده، latency، هزینه، fallback و ارزیابی باید پیش از launch تصمیم‌گیری شوند.
- انتخاب یک provider مدیریت‌شده، مدل اختصاصی یا معماری چندگزینه‌ای به سناریو و ظرفیت تیم بستگی دارد.
- Product Lead مالک تصمیم محصول و trade-off است؛ جای تیم فنی تصمیم اجرایی نمی‌گیرد.
چرا انتخاب مدل نباید شروع پروژه باشد؟
واقعیت محصول چیست؟: واقعیت این است که مدل فقط در یک زنجیره کار میکند: داده وارد می‌شود، درخواست ساخته می‌شود، مدل پاسخ می‌دهد، پاسخ ارزیابی یا محدود می‌شود و نتیجه به کاربر یا سیستم دیگر می‌رسد. کیفیت قابلیت به کل این زنجیره وابسته است.
تحلیل حکیم چیست؟: تحلیل من این است که شروع از مدل، گفت‌وگو را از مسئله به مقایسهٔ benchmark می‌برد. پیش از انتخاب باید یک سناریوی واقعی، چند نمونهٔ ورودی و خروجی مورد انتظار، و یک معیار شکست داشته باشیم.
اقدام پیشنهادی چیست؟: برای قابلیت موردنظر یک برگهٔ تصمیم یک‌صفحه‌ای بسازید و این موارد را در آن بنویسید:
اگر پاسخ چند مورد روشن نیست، هنوز در مرحلهٔ انتخاب مدل نیستید؛ در مرحلهٔ روشن‌کردن مسئله و قرارداد قابلیت هستید.
- کاربر دقیقاً چه کاری را سریع‌تر، دقیق‌تر یا ارزانتر انجام می‌دهد؟
- مدل به چه داده‌ای دسترسی دارد و چه داده‌ای نباید ببیند؟
- چه نوع خطایی برای محصول پرهزینه است؟
- latency، هزینهٔ هر تعامل و حجم مورد انتظار چه محدودیتی می‌سازند؟
- اگر provider در دسترس نبود یا قیمتش تغییر کرد، مسیر جایگزین چیست؟
کدام بخش‌های معماری باید پیش از مدل مشخص شوند؟
داده و قرارداد دسترسی چه نقشی دارند؟: پیش از مقایسهٔ مدل‌ها مشخص کنید داده از کجا می‌آید، چه کسی مالک آن است، چه مدت نگهداری می‌شود و آیا پاسخ باید به منبع قابل‌مشاهده برگردد یا نه. این تصمیم، معماری retrieval، permission و logging را تعیین میکند.
به‌جای جملهٔ کلی «یک chatbot می‌خواهیم»، قرارداد دقیق‌تری بنویسید: «کاربر باید از اسناد مجاز، پاسخی با ارجاع بگیرد؛ اگر منبع کافی نبود، سیستم باید عدم اطمینان را اعلام کند.»
portability و قرارداد خروج یعنی چه؟: Portability به معنی این نیست که هر مدل را بدون هیچ تغییری جایگزین کنیم. یعنی بدانیم کدام لایه از محصول به provider خاص وابسته است و بتوانیم وابستگی را مدیریت کنیم. قالب پیام، ابزارها، embeddings، محدودیت rate، روش moderation و فرمت پاسخ همگی می‌توانند بخشی از این وابستگی باشند.
قرارداد خروج باید روشن کند داده و promptها کجا نگهداری می‌شوند، ارزیابی مستقل است یا نه، منطق کسب‌وکار چقدر در prompt دفن شده و خروجی ساختاریافته داریم یا نه. اگر پاسخ این سؤال‌ها «نمی‌دانیم» باشد، قفل‌شدن فقط فنی نیست؛ در roadmap و مذاکره با provider هم ظاهر می‌شود.
سه سناریوی انتخاب به‌جای یک توصیهٔ عمومی
سناریوی اول: هدف، یادگیری سریع با ریسک کم است: اگر مسئله هنوز اعتبارسنجی نشده، حجم استفاده کم است و دادهٔ حساس در جریان نیست، یک provider مدیریت‌شده می‌تواند انتخاب منطقی باشد. مزیت آن سرعت آزمایش و کاهش کار عملیاتی است. trade-off آن وابستگی بیشتر به قیمت، محدودیت و رفتار همان سرویس است.
در این سناریو، portability کامل از روز اول ضروری نیست؛ اما خروجی ساختاریافته، نمونههای ارزیابی، جداسازی prompt از منطق محصول و ثبت هزینه ضروری است. سریع شروع کنید، اما وابستگی را پنهان نکنید.
سناریوی دوم: کیفیت و کنترل داده مهم‌تر از سرعت است: اگر پاسخ به دادهٔ داخلی، مجوزهای سازمانی یا فرایند حساس متصل است، باید مرز داده و دسترسی پیش از مدل مشخص شود. ممکن است یک مدل کوچکتر با retrieval خوب و کنترل permission از مدل بزرگ‌تری که دادهٔ بیشتری می‌بیند مناسب‌تر باشد.
در اینجا هزینهٔ اصلی فقط token نیست؛ ارزیابی، logging، مدیریت داده، بررسی خطا و نگهداری هم باید دیده شوند. انتخاب مدل باید از قرارداد کیفیت و امنیت پیروی کند.
سناریوی سوم: حجم، هزینه یا استقلال عملیاتی تعیین‌کننده است: اگر مصرف قابل‌توجه است، latency باید قابل‌پیش‌بینی باشد یا خروج از یک provider برای کسب‌وکار مهم است، معماری باید از ابتدا چند گزینهٔ قابل‌آزمایش داشته باشد. این الزام الزاماً به معنی اجرای چند مدل هم‌زمان نیست. یعنی لایهٔ orchestration، قرارداد ورودی/خروجی، ارزیابی و telemetry طوری جدا شوند که مقایسه و جابهجایی ممکن بماند.
trade-off این سناریو روشن است: کنترل بیشتر، پیچیدگی و مسئولیت عملیاتی بیشتری می‌آورد؛ بنابراین استقلال روی کاغذ می‌تواند از وابستگی مدیریت‌شده پرهزینه‌تر باشد.
latency، هزینه و fallback را چه زمانی تصمیم بگیریم؟
این سه موضوع نباید بعد از ساخت prototype بررسی شوند. latency بخشی از تجربهٔ کاربر است؛ هزینه بخشی از مدل کسب‌وکار؛ و fallback بخشی از اعتماد. وقتی مدل کند است، سرویس قطع می‌شود یا confidence کافی ندارد، محصول باید رفتار مشخصی داشته باشد: درخواست را ساده‌تر کند، پاسخ محدود بدهد، کار را به انسان بسپارد یا صریحاً بگوید نتیجه آماده نیست.
پیشنهاد عملی من این است که برای هر قابلیت، حداقل سه مسیر تعریف کنید:
هزینه و زمان پاسخ را برای چند نمونهٔ واقعی اندازه بگیرید. عددها باید از خود محصول بیایند؛ benchmark عمومی جای اندازه‌گیری را نمی‌گیرد.
- مسیر عادی با مدل و دادهٔ مورد انتظار.
- مسیر ضعیف‌شدن سرویس، مانند timeout، پاسخ ناقص یا محدودیت نرخ.
- مسیر خروج، مانند جایگزینی provider، استفاده از پاسخ ازپیش‌تأییدشده یا ارجاع به انسان.
ارزیابی مدل را چگونه از نمایش جدا کنیم؟
دموی خوب نشان می‌دهد یک مسیر ممکن است. ارزیابی نشان می‌دهد آن مسیر در شرایط مختلف چقدر قابل‌اعتماد است. برای شروع، مجموعه‌ای کوچک اما واقعی از نمونه‌ها بسازید و آن‌ها را بر اساس معیارهای محصول بررسی کنید: درستی، کامل‌بودن، ارجاع به منبع، لحن، زمان پاسخ و رفتار در نبود اطلاعات.
این مجموعه باید بعد از تغییر prompt، retrieval، مدل یا provider دوباره اجرا شود تا بهبود واقعی از بهترشدن چند نمونهٔ نمایشی جدا بماند. خطاهای مهم را نیز دسته‌بندی کنید؛ افشای داده با یک پاسخ نادرست کم‌اهمیت یکسان نیست.
تیم فنی ابزار ارزیابی و مشاهده‌پذیری را می‌سازد؛ تیم محصول معیار را به outcome کاربر وصل میکند؛ و Product Lead trade-off سازگار با هدف محصول را انتخاب میکند.
Product Lead در انتخاب مدل چه کاری نباید انجام دهد؟
Product Lead نباید مدل محبوب را تحمیل کند، کیفیت ارزیابی‌نشده را وعده بدهد یا portability را بهانهٔ پیچیدگی کند. کاربر با سیستم کامل مواجه است، نه فقط با مدل؛ پس مسئولیت خطا را نمی‌توان به مدل واگذار کرد.
نقش درست، شفاف‌کردن سؤال و trade-off است: تیم فنی محدودیت را می‌گوید و تیم محصول نتیجه و ریسک قابلقبول را روشن میکند. سرعت باید کنار هزینه و مسیر خروج ثبت شود.
جمع‌بندی عملی: از فردا چه کنیم؟
برای یک قابلیت AI از roadmap، این ترتیب را اجرا کنید:
این فرایند بحث مدل را در جای درست خود قرار می‌دهد: مدل ممکن است تغییر کند، اما مسئله، قرارداد محصول، شواهد و مسیر تصمیم باید قابل‌فهم بمانند.
- مسئله، کاربر و رفتار قابل‌مشاهده را در یک جمله بنویسید.
- سه سناریوی واقعی و چند نمونهٔ ورودی بسازید.
- داده، permission، معیار کیفیت، latency و سقف هزینه را مشخص کنید.
- حداقل دو گزینهٔ مدل یا provider را با یک ارزیابی یکسان مقایسه کنید.
- fallback، telemetry و قرارداد خروج را پیش از launch ثبت کنید.
- بعد از انتشار، تصمیم را با دادهٔ واقعی بازبینی کنید؛ نه با وفاداری به انتخاب اولیه.
پرسش‌های متداول
آیا باید از روز اول چند مدل AI را هم‌زمان پشتیبانی کنیم؟
نه. ابتدا مسئله و معیار ارزیابی را روشن کنید. اگر ریسک provider، هزینه یا نیاز به کنترل بالا است، لایه‌های وابستگی را جدا کنید تا چند گزینه قابل‌آزمایش بماند؛ اما اجرای هم‌زمان چند مدل فقط وقتی ارزش دارد که هزینه و پیچیدگی آن توجیه داشته باشد.
آیا انتخاب مدل کوچکتر همیشه ارزانتر و بهتر است؟
نه. مدل کوچکتر ممکن است هزینهٔ مستقیم کمتری داشته باشد، اما اگر خطا، بازبینی انسانی یا پیچیدگی retrieval را زیاد کند، هزینهٔ کل محصول بالاتر میرود. باید هزینه و کیفیت را روی نمونههای واقعی و با معیار یکسان بسنجید.
قرارداد خروج از provider باید شامل چه چیزی باشد؟
حداقل باید محل نگهداری داده و prompt، قالب ورودی و خروجی، معیارهای ارزیابی، وابستگیهای orchestration، روش logging و گزینهٔ جایگزین را روشن کند. هدف، حذف همهٔ هزینههای جابهجایی نیست؛ هدف، پنهاننکردن آنهاست.
از چه زمانی قابلیت AI برای launch آماده است؟
وقتی مسئله و معیار موفقیت روشن باشد، کیفیت روی نمونههای واقعی بررسی شده باشد، رفتار سیستم در خطا مشخص باشد، هزینه و latency قابلقبول باشند و تیم بداند بعد از launch چه چیزی را پایش و بازبینی میکند. دمو بهتنهایی معیار آمادگی نیست.