مهلت، تلاش دوباره، و مسیر جایگزین برای نقطه پایانی AI را مثل پرداخت طراحی کن
نقطه پایانی AI قابل اعتماد بیشتر به سیستم پرداخت شبیه است تا به دمو. باید رفتار شکستش صریح باشد. تعداد زیادی از این endpointها هنوز موفقیت را مسیر پیش‌فرض فرض می‌کنند. بعد ارائه‌دهنده کند می‌شود، schema از اعتبار می‌افتد، یا صدای ابزار گیر می‌کند، و تجربه کاربر می‌شود اسپینری که به سکوت ختم می‌شود.
این را وقتی می‌سازم که گردش کار تکرار می‌شود و محصول می‌داند «به اندازه کافی خوب» یعنی چه. اگر خود کاربرد هنوز مبهم است، اول دامنه را تنگ کن. زیرساخت عمومی برای مسئله حل‌نشده، انعطافی است که هیچ کاربری هنوز از آن سود نبرده.
کار صورتحساب، مجوز، داده پروداکشن، و گذار وضعیت قابل مشاهده را اپ با اعتبار سخت مالک شود. مدل جایی کمک کند که کار فازی است. پیامد را اپ مالک شود.
شکست را سه دسته کن
قبل از کتابخانه، شکست‌ها را نام ببر.
قابل تکرار: قطع کوتاه شبکه، پاسخ 429، خطای درگاه که بدنه‌اش می‌گوید دوباره امتحان کن. این‌ها بودجه تکرار محدود با jitter می‌خواهند تا همه کلاینت‌ها هم‌زمان برنگردند.
قابل تنزل: مهلت مدل گران، ظرفیت منطقه، یا ابزاری که برای این وظیفه ضروری نیست. اگر قرارداد خروجی با مدل ارزان‌تر یا مسیر غیرمدلی واقعاً یکی است، جایگزین معنی دارد. اگر قرارداد یکی نیست، جایگزین فقط شکل دیگری از جواب غلط است.
باید فوراً دیده شود: خروجی نامعتبر نسبت به schema، ابزار غیرمجاز، ورودی خارج از محدوده، خطای مجوز. تکرار این‌ها پول را آتش می‌زند و کاربر را معطل می‌کند. خطای قابل فهم با زمینه کافی برای اصلاح بهتر است.
این طبقه‌بندی را در لاگ ساخت‌یافته بنویس: کدام شاخه اجرا شد، چند بار تکرار شد، مهلت چند بود، و آیا پاسخ نهایی کامل بود یا تنزل‌یافته. بدون این، نمودار «خطا» همه چیز را یکی نشان می‌دهد و کسی نمی‌داند باید ارائه‌دهنده را عوض کند یا پرامپت را.
مهلت را به شکل کار ببند
مسیر تعاملی مهلت کوتاه می‌خواهد. کاربر پای صفحه است. اگر در چند ثانیه جواب قابل نمایش نداری، یا وضعیت میانی راست‌گو نشان بده یا کار را به پس‌زمینه ببر. مسیر پس‌زمینه می‌تواند مهلت بلندتر داشته باشد چون کسی اسپینر را نگاه نمی‌کند، ولی باز هم بی‌نهایت نیست. صف بدون سقف، حادثه هزینه است.
تکرار را به کار دارای اثر جانبی نچسبان مگر اینکه آن کار idempotent باشد. ساخت رکورد، ارسال ایمیل، یا کسر اعتبار اگر با هر retry دوباره اجرا شود، قابلیت اطمینان دروغین است. کلید یکتا یا وضعیت «در حال انجام» را قبل از صدای مدل ثبت کن.
جایگزین ارائه‌دهنده فقط وقتی که ورودی و خروجی همان قرارداد را دارند. مدل دوم که شکل JSON دیگری برمی‌گرداند، fallback نیست. یک پارسر دوم است که شب حادثه کسی یادش نیست.
حالت تنزل را در محصول نشان بده
به کاربر بگو کی جواب جزئی است، کی کار کندتر در پس‌زمینه ادامه دارد، و کی قابلیت موقتاً در دسترس نیست. قایم کردن شکست پشت جمله مبهم، اعتماد را بدتر می‌کند. «چیزی اشتباه شد» برای خطای اعتبار با «مدل الان شلوغ است، دوباره تلاش کن» یکی نیست. متن را از روی دسته شکست بساز نه از روی یک catch کلی.
مشاهده‌پذیری حداقل: تأخیر، تعداد شکست، و هزینه به تفکیک همین گردش کار، نه یک شمارنده سراسری AI. بدون این سه، نمی‌فهمی تغییر تو محصول را بهتر کرده یا فقط دمو را هیجان‌انگیزتر.
نسخه اول باید بتواند صادقانه خراب شود. وضعیت جزئی روشن، خطای قابل بازیابی، و یک مسیر موفقیت باریک، سالم‌تر از این است که سیستم قبل از اینکه استحقاقش را داشته باشد خودمختار به نظر برسد.
اشتباه‌هایی که هنوز می‌بینم
تکرار بی‌سقف روی خطای اعتبار. مهلت شصت ثانیه‌ای روی دکمه‌ای که کاربر فکر می‌کند آنی است. fallback به مدلی که ابزار یا schema را پشتیبانی نمی‌کند. و لاگی که فقط می‌گوید `error` بدون نام شاخه.
انتزاع بزرگ «موتور تاب‌آوری» را روز اول نساز. برای یک endpoint، سه دسته بالا و یک جدول کوچک مهلت کافی است. وقتی گردش کار دوم همان جدول را خواست، آن وقت اشتراک را در بیاور. زودتر از آن، انعطاف را نگهداری می‌کنی نه رفتار را.
هدف این نیست که AI خطاناپذیر حس شود. هدف این است که وقتی چیزی خراب شد، سیستم طوری رفتار کند که انگار بزرگسال طراحی‌اش کرده.
بودجه را کنار مهلت بنویس
مهلت بدون سقف هزینه، فقط کندی را به صورتحساب تبدیل می‌کند. برای هر گردش کار یک سقف ساده داشته باش: حداکثر تکرار، حداکثر مدل جایگزین، و حداکثر هزینه تقریبی در یک درخواست کاربر. لازم نیست سیستم صورتحساب کامل باشد. یک شمارنده که بعد از سقف، مسیر را به خطای راست‌گو می‌برد کافی است تا یک حلقه پنهان شبانه حساب را تمام نکند.
کلید idempotency را برای کاری که اثر بیرونی دارد از اول بگذار، حتی اگر امروز فقط یک ارائه‌دهنده داری. فردا که fallback اضافه می‌کنی، بدون آن کلید نمی‌دانی صدای دوم ادامه صدای اول است یا اجرای دوباره. این را در تست با قطع مصنوعی اتصال تمرین کن، نه در اولین حادثه واقعی.
پرسش‌های کوتاه
هر 500 را تکرار کنم؟ نه. فقط چیزی را که سند ارائه‌دهنده یا تجربه تو نشان می‌دهد گذرا است، با سقف و jitter. خطای منطق و اعتبار را تکرار نکن.
fallback همیشه مدل دوم است؟ نه. گاهی مسیر قطعی، پاسخ ذخیره‌شده، یا پیام «الان نه» از یک جواب ارزانِ بی‌ربط بهتر است.
مهلت تعاملی را چند ثانیه بگذارم؟ عدد را از روی تحمل همان صفحه بگیر نه از یک ثابت تیمی. اگر از آن گذشتی، یا وضعیت میانی نشان بده یا کار را از مسیر کلیک خارج کن.