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