استک AI که واقعاً پیشنهاد می‌کنم کوچک‌تر از نموداری است که تیم می‌کشد
اول سال وسوسه این است که استک AI را طوری طراحی کنی که انگار همه کاربردهای آینده از الان وجود دارند. نتیجه معمولاً انتزاع پهن، چند فروشنده، و کدبیسی پر از پیچ است که کسی مسئول تنظیمش نیست. استکی که من برای بیشتر تیم‌ها نگه می‌دارم باریک‌تر است: یک ارائه‌دهنده اصلی مدل، یک لایه ارکستراسیون تمیز، خروجی ساخت‌یافته، مرز صریح ابزار، یک حلقه ارزیابی مختصر، و داشبورد هزینه و تأخیر که به جریان واقعی محصول وصل باشد. بازیابی را فقط جایی بگذار که مسئله مشخصی را حل کند. مسیریابی چندمدله را فقط جایی که هزینه خودش را درمی‌آورد.
این سلیقه «کمتر ابزار» نیست. واکنش به مالیاتی است که آرام جمع می‌شود: مالکیت نامعلوم، اشتباه تکراری، هزینه پنهان، دست‌به‌دست شدن ناجور، و تصمیم‌هایی که به پرامپت یا حافظه شفاهی تیم رانده شده‌اند. یک لحظه فاجعه نمی‌شود. فقط تکرار کندتر، حادثه پرسروصداتر، و محصولی که اعتماد کردنش سخت‌تر از چیزی است که باید باشد.
گردش کار باید قابل درس دادن باشد
اگر هم‌تیمی تازه نتواند بگوید سیستم از کجا شروع می‌شود، چه ورودی‌ای می‌خواهد، و قضاوت انسان هنوز کجا مال اوست، گردش کار سالم نیست. پیچیدگی نمودار این را عوض نمی‌کند. مهم این است که مسیر را بشود توضیح داد و بازبینی کرد.
گردش کاری را دوست دارم که شکلش با درجه اتوماسیون عوض نشود. بشود دستی اجرا کرد، نیمه‌خودکار کرد، یا با ابزار حمایت کرد، بدون اینکه قرارداد پایه بشکند. پذیرش راحت‌تر می‌شود چون تیم مجبور نیست یک‌شبه از صفر به «کاملاً ایجنتی» بپرد.
معماری اپ را عمداً کسل نگه دار. مسیر API معمولی، ذخیره عادی، رابط تایپ‌دار، کار ناهم‌زمان پشت صف، و لاگ ساده برای بیشتر تیم‌ها از معماری‌ای که خودش را کاملاً ایجنتی می‌نامد بهتر است. AI داخل استک نرم‌افزار می‌نشیند، نه بالای آن. اگر لایه مدل از بقیه محصول مرموزتر شد، یعنی داری سیستم دوم می‌سازی که کسی مالک حادثه‌اش نیست.
چطور واردش شوی که آشوب تازه نسازی
یک مسیر تکراری بردار که دردش روشن است و ریسک نسخه اول قابل تحمل. قبل از سیم‌کشی ابزار، جریان مطلوب را به زبان ساده بنویس. اتوماسیون اگر روی فرآیند ضعیف سوار شود، ضعف را قایم می‌کند نه اینکه درستش کند.
بعد وضوح عملیاتی: چه چیزی لاگ می‌شود، چه چیزی بازبینی می‌شود، شکست چه شکلی است، و تصمیم نهایی مال کیست. وقتی قدم AI وارد می‌شود این جواب‌ها باید دیده شوند، وگرنه هر بار که خروجی عجیب است جلسه از نو شروع می‌شود.
انتزاع پهن را برای بعد بگذار. گردش کار خوب حق استفاده مجدد را با پایدار شدن به دست می‌آورد. لازم نیست روز اول وانمود کند فریمورک است. اگر همان مسیر اول را هم‌تیمی‌ها داوطلبانه ادامه ندادند، تعمیم دادنش فقط سطح بیشتری برای نگهداری است.
نرده را برای ضعف سیستم نگذار
نرده مال این نیست که سیستم ضعیف است. مال این است که کار مهم است، حالت لبه واقعی است، و قابلیت اطمینان وقتی مرزها روشن باشند جمع می‌شود. در عمل یعنی تعریف کار باریک، دست‌به‌دست شدن تایپ‌دار جایی که می‌شود، رفتار جایگزین قابل دیدن، و حاضر بودن که عمل حساس یا پراثر پشت بازبینی صریح بماند.
بازیابی را به استک پیش‌فرض تبدیل نکن. اگر جواب از سند مشخص یا از وضعیت خود اپ درمی‌آید، پایگاه برداری فقط یک خرابی تازه است. مسیریابی مدل هم همین‌طور. تا وقتی یک کار واقعاً به مدل ارزان‌تر یا مدل قوی‌تر نیاز ثابت دارد، یک مدل اصلی با سقف مشخص ساده‌تر از سیاستی است که هیچ‌کس در حادثه از حفظ ندارد.
داشبورد هزینه و تأخیر را به جریان محصول گره بزن، نه به «مصرف کل سازمان». اگر ندانی کدام قابلیت گران یا کند شده، نمودار قشنگ فقط دعوا را دیرتر شروع می‌کند. حلقه ارزیابی هم لازم نیست پلتفرم باشد. باید بشود بعد از عوض کردن پرامپت یا مدل گفت چه چیزی بهتر شد و چه چیزی برگشت.
چه چیزی را نخر
زیرساخت را قبل از اینکه گردش کار خودش را ثابت کند نخر و نساز. خیلی از بدهی معماری AI در واقع بدهی جاه‌طلبی است. تیم برای مقیاسی می‌سازد که محصول هنوز لایق آن مقیاس نیست.
انعطاف برای تحت تأثیر گذاشتن هم گران است. سطحی که نظری همه‌چیز را بتواند، اغلب سطحی است که هیچ‌کس کامل نمی‌فهمد. اعتماد همان‌جا شروع به خالی شدن می‌کند. هرچه کار گران‌تر، دیدنی‌تر، یا نزدیک‌تر به کسب‌وکار باشد، پیش‌فرض روشن و شاخه پنهان کمتر می‌خواهم. ابهام در اکتشاف قابل تحمل است. در پروداکشن گران است.
چک ساده قبل از اضافه کردن جعبه جدید به نمودار: آیا این جعبه یک درد تکراری را کم می‌کند، یا فقط احتمال می‌دهد روزی به درد بخورد؟ اگر دومی است، جایش سند تصمیم است نه وابستگی تازه.
از کجا شروع کنی
یک درد تکراری را انتخاب کن و جریان مطلوب را به زبان ساده بنویس. نقطه دست‌به‌دست شدن را صریح کن تا انسان و ابزار درباره مسئولیت حدس نزنند. به اندازه کافی دید بگذار که بشود گفت اصطکاک کم شده یا فقط جایی نامرئی‌تر رفته. فقط وقتی نسخه اول آن‌قدر پایدار است که هم‌تیمی داوطلبانه نگهش می‌دارد، گسترش بده.
استک خوب AI آن نیست که بیشترین جعبه را روی نمودار دارد. آن است که تیم بتواند توضیحش دهد، نگهش دارد، و بهترش کند بدون رنج آیینی. اگر نتوانی در یک صفحه بگویی مدل کجا تمام می‌شود و اپ از کجا مالک پیامد است، هنوز استک نداری. یک آزمایش داری که اسم معماری گرفته.
مالک حادثه را هم‌زمان با جعبه نمودار مشخص کن
هر جعبه تازه روی استک یک سؤال عملیاتی دارد: نیمه‌شب که کند یا گران شد، چه کسی بیدار می‌شود؟ اگر جواب «تیم AI» است و آن تیم به لاگ اپ دسترسی ندارد، جعبه را اضافه نکن. ارائه‌دهنده مدل، صف، و داشبورد باید همان مالک محصول را داشته باشند که مسیر API را دارد. جدا کردن «تیم مدل» از «تیم اپ» فقط وقتی معنی دارد که قرارداد بینشان نوشته شده باشد: ورودی، خروجی، سقف، و اینکه شکست به کاربر چه شکلی نشان داده می‌شود.
من جعبه را وقتی قبول می‌کنم که بشود بدون اسلاید توضیح داد چرا وجود دارد و چطور خاموش می‌شود. خاموش کردن مهم‌تر از روشن کردن است. فیچری که نتوانی پرچمش را ببندی، جزئی از استک نیست. بدهی است.