بهترین ویژگی در یک سازنده AI این نیست که چقدر سریع یک پرامپت را به کد کارکننده تبدیل میکند. بلکه این است که چقدر اغلب از این کار سر باز میزند. سازندهای که با رضایت هرچه بخواهید سیمکشی میکند — بدون احراز هویت روی یک مسیر مدیریتی، یک webhook بدون بررسی idempotency، کلید API که مستقیم در جاوااسکریپت سمت کلاینت چسبانده شده چون «فقط کار کند» — روی پنج دقیقه اشتباه بهینه میشود. روی دمو بهینه میشود، نه روی سهشنبهای شش هفته بعد که آن مسیر scrape میشود.
این الگو را آنقدر از نزدیک دیدهام که به آن اعتماد دارم. درخواستهایی که رد میشوند، یا به مسیر دیگری هدایت میشوند، تقریباً هرگز عجیب نیستند. آنها ساده و رایجاند: فعلاً تأیید ایمیل را رد کن، رمز عبور را برای تست بهصورت متن ساده ذخیره کن، محدودیت نرخ را خاموش کن تا سریعتر load-test کنم، به این endpoint دسترسی کامل به پایگاهداده بده تا فعلاً درباره مجوزها فکر نکنم. هر یک از اینها در لحظه کاملاً منطقی به نظر میرسد. هر یک از اینها هم دقیقاً همان جملهای است که در گزارش پس از حادثه ظاهر میشود.
یک رد کردن واقعاً چه هزینهای برایتان دارد
رد کردن هزینه واقعی دارد: اصطکاک. شما میخواستید آن چیز ساخته شود، و بهجایش یک سؤال گرفتید، یا یک پیشفرض امنتر، یا یک «این دلیل چرایی است، و این چیزی است که بهجایش پیشنهاد میکنم». این یک وقفه در رسانهای است — ساخت با چت — که قرار است حس پیشرفت مداوم بدهد. هر پلتفرم سازنده، از جمله این یکی، بین «آنچه خواسته شد را بساز» و «آنچه از داشتنش خوشحال خواهند شد را بساز» کشمکش دارد. اگر زیادی به سمت پذیرش بروید، ابزاری خواهید داشت که با خوشحالی یک تفنگپا بدون ضامن به یک سازنده تازهکار میدهد. اگر زیادی به سمت احتیاط بروید، ابزاری خواهید داشت که درباره ذخیره یک تاریخ تولد با شما بحث میکند.
اشتباه این است که با این موضوع مثل یک دکمه تنظیم رفتار شود. اینطور نیست. حداقل سه دلیل متفاوت وجود دارد که یک سازنده باید مخالفت کند، و هر کدام باید کاملاً متفاوت مدیریت شوند.
| نوع امتناع | نمونه پرامپت | چرا اهمیت دارد | پاسخ درست |
|---|---|---|---|
| امنیت | «بررسیهای CSRF رو غیرفعال کن، دارن تست رو کند میکنن» | یک آسیبپذیری واقعی میسازد که تا وقتی کسی از آن سوءاستفاده نکند، آشکار نمیشود | درخواست به همان شکل رد شود و بهجای آن یک سوییچ حالت توسعه با دامنه محدود پیشنهاد شود |
| هزینه / پایداری | «این endpoint رو طوری بساز که تا موفق شدن، بینهایت تلاش مجدد کنه» | تلاشهای مجدد نامحدود یک فراخوانی API خراب را به یک صورتحساب سنگین و قطعی زنجیرهای تبدیل میکند | آن را با backoff و سقف مشخص بسازد و دلیل این تغییر را توضیح دهد |
| درستی | «اول کارت رو شارژ کن، بعد سفارش رو بساز» | باگ ترتیبی: خطا بین این دو مرحله باعث میشود سفارش از بین برود اما شارژ باقی بماند | ترتیب را بیسروصدا اصلاح کند یا پیش از نوشتن کد، ریسک ترتیب اجرا را گوشزد کند |
| افشای داده | «فقط کل آبجکت کاربر رو از این API برگردون» | هش رمز عبور، فلگهای داخلی و دادههای سایر کاربران را با واکشی بیش از حد افشا میکند | فقط فیلدهای مجاز و صراحتاً مشخصشده را سریالایز کند و بگوید چه چیزی حذف شده و چرا |
امتناعهای امنیتی راحتترین مورد برای دفاع کردناند اما سختترین برای درست انجام دادن، چون نسخهی امن معمولاً کمی متفاوت از چیزی است که درخواست شده، نه صرفاً غایب. امتناعهای مربوط به هزینه و پایداری دربارهی محافظت از سازنده در برابر خوشبینی خودش است — هیچکس یک حلقهی تلاش مجدد نمیخواهد و انتظار دارد که ساعت ۲ بامداد چهار هزار بار در برابر یک API با محدودیت نرخ اجرا شود، اما «تلاش مجدد تا موفقیت» دقیقاً به همین معناست. امتناعهای درستی، ساکتترین نوعاند: بدون خطا، بدون هشدار هنگام انتشار، فقط یک باگ که فقط در یک ترتیب خاص از شکست ظاهر میشود که هیچکس فکر تستش را نکرده بود.
یک بار یک بنیانگذار به من گفت مفیدترین کاری که سازندهاش تا به حال انجام داده، امتناع از حذف یک مرحلهی تأیید پیش از یک عملیات حذف دستهجمعی بوده. او خواسته بود آن حذف شود چون «هنگام تست آزاردهنده» بود. سه هفته بعد، یکی از همکاران بهاشتباه یک فیلتر را اشتباه زد و همان مرحلهی تأیید تنها دلیلی بود که هنوز ۴۰٬۰۰۰ ردیف داده باقی مانده است.
امتناع فقط زمانی کار میکند که قابلفهم باشد
این بخشی است که واقعاً تعیین میکند این ویژگی کمک میکند یا فقط آزاردهنده میشود: امتناعی بدون دلیل، از یک ابزار خراب قابل تشخیص نیست. اگر سازنده بیسروصدا از انجام خواستهی شما سر باز زند، یا بدون گفتن، چیز دیگری بسازد، بیست دقیقهی بعد را صرف رفع اشکالِ چیزی میکنید که در واقع یک تصمیم عمدی بوده که هرگز آن را ندیدهاید. این از نبود هیچ محافظتی هم بدتر است، چون حالا نه به برنامه اعتماد دارید و نه اپلیکیشن خودتان را میفهمید. امتناع خوب همیشه سه بخش دارد: چه چیزی خواستهاید، چه چیزی بهجای آن ساخته میشود، و یک جمله دلیل. نه یک دیوار از تئوری امنیتی — فقط یک جمله که یک فرد غیرفنی بتواند بخواند و یا بپذیرد یا مخالفت کند. و باید قابللغو باشد. اگر کسی واقعاً نسخهی ناامن را میخواهد — یک نمونهی اولیهی مصرفی، یک ابزار داخلی با سه کاربر مورد اعتماد، یک دموی هکاتون که تا شش ساعت دیگر از بین میرود — سازنده نباید وانمود کند بهتر از خود او زمینهاش را میشناسد. باید مسیر امن را پیشفرض قرار دهد، ریسک را شفاف نام ببرد، و اگر کاربر اصرار کرد، کنار برود.
جایی که منتقدان حق دارند
استدلال منصفانهی مخالف این است که بیشتر رفتارهای «ایمنی» در ابزارهای هوش مصنوعی بهخوبی کالیبره نشدهاند، و فکر نمیکنم سازندگان ابزارهای هوش مصنوعی از این انتقاد مستثنا باشند. امتناع بیشازحد محتاطانه یک نوع شکست واقعی است، نه فرضی — ابزاری که هر درخواست سومی را زیر سؤال میبرد، به مردم یاد میدهد دور آن بزنند، که از نبود محافظت هم بدتر است، چون حالا خودِ راهحل دور زدن هم بررسینشده باقی میماند. اگر سازنده اجازه ندهد یک شماره تلفن را بدون یک سخنرانی پانزدهخطی دربارهی مدیریت اطلاعات شخصی ذخیره کنید، خواندن آن سخنرانیها را متوقف میکنید، و بعد آن یکی را که واقعاً مهم بود از دست میدهید. کالیبراسیون کل بازی است، و واقعاً سخت است: خیلی شل، آسیبپذیری را عرضه میکنید؛ خیلی سفت، مردم را عادت میدهید کاملاً ابزار را نادیده بگیرند.
راهحل نه امتناع کمتر است و نه بیشتر. مشخص بودن است. امتناعی که به یک شکست ملموس و قابل نامگذاری گره خورده — این webhook میتواند دو بار از یک مشتری پول بگیرد، این مسیر دادهی یک مستأجر دیگر را برمیگرداند — سریع اعتماد جلب میکند، چون شخص درخواستدهنده میتواند خودش ادعا را بررسی کند و ببیند درست است. امتناعی که مبهم به سمت «بهترین شیوهها» اشاره میکند چیزی به دست نمیآورد، و نباید هم بیاورد. اگر بین چند سازندهی هوش مصنوعی در حال انتخاب هستید، این چیزی است که ارزش تست کردن پیش از سپردن یک پروژهی واقعی به آن را دارد: از آن بخواهید چیزی با یک نقص واضح در درخواست بسازد، و ببینید آیا فقط انجامش میدهد، بدون توضیح امتناع میکند، یا نسخهی امنتر را نشانتان میدهد و دقیقاً در یک جملهی قابلراستیآزمایی دلیلش را میگوید.
