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