قرارداد خروجی و امکان اعلام ابهام
از مدل فقط قالب مشخصی بخواهید و همان قالب را در بک‌اند بررسی کنید. برای مثال، فیلد گروه از یک فهرست محدود انتخاب شود و پاسخ مبهم اجازه ارجاع داشته باشد. درخواست تولید JSON، جای اعتبارسنجی JSON را نمی‌گیرد؛ پاسخ خالی، متن اضافه یا گروه ناشناخته باید رد یا برای بازبینی علامت‌گذاری شود. عدد اعتماد تولیدشده توسط خود مدل نیز بدون کالیبراسیون، احتمال خطای واقعی نیست. اگر تصمیم روی پول یا دسترسی اثر دارد، گروه پیشنهادی مدل صرفاً ورودی بررسی است و نباید به‌تنهایی اجازه بازپرداخت، حذف یا تغییر منبع ایجاد کند.
{
"task_id": "fixture-001",
"message": "The deployment failed; please help me find the error.",
"allowed_labels": ["technical", "billing", "sales", "review"],
"expected_label": "technical"
}
این داده ساختگی است و برچسب مرجع باید در فایل ارزیابی بماند، نه در درخواست واقعی مدل. اگر پاسخ مورد انتظار را همراه سؤال می‌فرستید، آزمون دیگر توان مدل را نمی‌سنجد. مجموعه آموزش پرامپت را نیز از مجموعه نهایی ارزیابی جدا کنید تا نتیجه از حفظ‌کردن چند مثال به دست نیاید. برای هر تغییر، نسخه داده و پرامپت را ثبت کنید. این ثبت کوچک کمک می‌کند بعداً بفهمید بهبود امتیاز واقعاً مربوط به مدل بوده یا آسان‌ترشدن مجموعه سؤال‌ها و تغییر معیار پذیرش.
اتصال محدود از طریق API پاستا
برای آزمایش، ابتدا کاتالوگ مدل‌های فعال Claude پاستا را بررسی کنید. مدل خبری را با نسخه موجود جایگزین لفظی نکنید؛ Haiku 4.5 و Haiku 5.5 دو نسخه متفاوت‌اند. یک کلید مستقل با دسترسی لازم و سقف هزینه مشخص بسازید و آن را در بک‌اند نگه دارید. آدرس پایه سازگار پاستا https://console.paasta.cloud/api/ai/v1 است. شناسه مدل را از کاتالوگ همان روز بردارید. این مراحل برای بررسی مدل موجود است و به معنی فعالشدن نسخه جدید یا انتقال اشتراک حساب دیگری به پاستا نیست.
در مستندات API پاستا، مسیر درخواست و قابلیت‌های سرویس را بررسی کنید. ابتدا یک پاسخ متنی کوتاه بخواهید و بعد قالب وظیفه خودتان را اضافه کنید. پارامترهای همه خانواده‌ها را یکسان فرض نکنید؛ نبود پشتیبانی یک گزینه نباید با حذف بررسی خطا پنهان شود. پاسخ جریانی، ابزار و ورودی تصویر نیز باید مستقل آزمایش شوند. در این مقاله، برای ساخت جدول مقایسه از استنتاج پولی استفاده نشده است؛ خواننده باید کیفیت و هزینه نسخه در دسترس حساب خود را با یک آزمایش محدود و دارای مجوز بسنجد.
هزینه هر پاسخ پذیرفتهشده را حساب کنیم
قیمت هر میلیون توکن تنها یک نرخ پایه است. برای محصول، مجموع هزینه تلاش‌ها را بر تعداد کارهای پذیرفتهشده تقسیم کنید. اگر بعضی پاسخ‌ها رد شده‌اند، هزینه آن تلاش‌ها حذف نمی‌شود. نمونه زیر فقط محاسبه روی ردیف‌های ساختگی را انجام میدهد و تومان را به‌صراحت در نام فیلد نگه می‌دارد. زمان نیز داده ورودی است؛ تابع هیچ ادعایی درباره سرعت Haiku ندارد. هزینه واقعی باید از مصرف و صورتحساب همان سرویس استخراج شود، نه از اختلاف موجودی حساب یا حدس تعداد توکن بر مبنای طول متن.
export function summarizeModelTrial(rows) {
let totalToman = 0;
let accepted = 0;
const durations = [];
for (const row of rows) {
if (!Number.isSafeInteger(row.cost_toman) || row.cost_toman < 0 ||
!Number.isFinite(row.duration_ms) || row.duration_ms < 0 ||
typeof row.accepted !== "boolean") {
throw new TypeError("Invalid trial row");
}
totalToman += row.cost_toman;
if (!Number.isSafeInteger(totalToman)) throw new RangeError("Total overflow");
accepted += Number(row.accepted);
durations.push(row.duration_ms);
}
durations.sort((a, b) => a - b);
return {
attempts: rows.length,
accepted,
total_toman: totalToman,
cost_per_accepted_toman: accepted ? totalToman / accepted : null,
p95_ms: durations.length ? durations[Math.ceil(durations.length * 0.95) - 1] : null,
};
}
اگر سه تلاش ساختگی به‌ترتیب ۱۲، ۸ و ۱۰ تومان هزینه داشته باشند و دو پاسخ پذیرفته شوند، هزینه هر پاسخ پذیرفتهشده ۱۵ تومان است. این اعداد تعرفه هیچ مدل یا سرویس واقعی نیستند. اگر هیچ پاسخ قابل قبول ندارید، هزینه هر پاسخ نباید صفر نمایش داده شود؛ مقدار نامشخص همراه علت، گزارش درست‌تری است. مقایسه دو مدل نیز باید هزینه ابزار، بازبینی و تلاش دوم را با قرارداد یکسان دربرگیرد. بدون این هم‌ترازی، یک مدل ممکن است فقط به دلیل حذف بخشی از هزینه‌ها ارزانتر به نظر برسد.
تأخیر را فقط با یک درخواست نسنجید
زمان پاسخ یک نمونه تحت تأثیر شبکه، اندازه ورودی، طول خروجی و بار سرویس است. آزمون را در چند نوبت و با ورودی‌های نماینده تکرار کنید و هم‌زمان تعداد درخواست‌ها را بدون برنامه بالا نبرید. زمان نخستین بخش خروجی در پاسخ جریانی با زمان پایان کامل فرق دارد؛ یکی را جای دیگری گزارش نکنید. برای تجربه کاربر، نمونه‌های کند و خطاهای زمان‌سنج نیز مهم‌اند. اگر صف برنامه یا ابزار خارجی عامل اصلی انتظار است، تغییر مدل ممکن است بهبود کمی ایجاد کند. اندازه‌گیری مرحله‌ای را با راهنمای Trace ایجنت ترکیب کنید.
مسیریابی بین مدل‌ها، با قواعد قابل بررسی
یک مسیر ممکن این است که وظیفه محدود ابتدا به مدل سبک‌تر برسد و در صورت خروج از قرارداد، برای بازبینی یا مدل دوم ارجاع شود. اما ارجاع باید سقف تلاش و بودجه داشته باشد؛ حلقه بی‌پایان بین دو مدل، راهکار کیفیت نیست. درخواست حساس را نیز صرفاً براساس کوتاه‌بودن متن ارزان فرض نکنید. برای طراحی مسیر، راهنمای HarnessRouter نکات مرتبط دارد، اما پشتیبانی یک قابلیت در ابزار ثالث را پشتیبانی خودکار همان قابلیت در پاستا ندانید. هر اتصال باید با قرارداد واقعی مدل و کلاینت بررسی شود.
کش، کوتاه‌کردن ورودی و هزینه پنهان کیفیت
کاهش مصرف همیشه به معنی انتخاب مدل دیگر نیست. حذف داده تکراری، محدودکردن خروجی به نیاز واقعی و استفاده درست از کش می‌توانند ارزشمند باشند؛ شرایط کش به مدل و سرویس وابسته است. برای تفاوت کش با حذف یا خلاصه‌کردن اطلاعات، راهنمای Prompt Caching را مطالعه کنید. اگر متن مهم را برای کاهش هزینه حذف می‌کنید، کیفیت را دوباره بسنجید. دستورهای مجوز، محدودیت مسئله و شواهد لازم نباید صرفاً برای کوتاه‌شدن ورودی از بین بروند. بهینه‌سازی زمانی مفید است که پاسخ پذیرفتهشده و قابل اتکا باقی بماند.
اجرای سرویس و جداسازی داده کاربران
بک‌اند ارزیابی یا پاسخ‌گویی را می‌توان روی پلتفرم ابری پاستا منتشر کرد. کلید مدل در متغیر محیطی بک‌اند قرار می‌گیرد و مرورگر نباید آن را دریافت کند. برای هر درخواست، هویت کاربر و مالکیت داده را پیش از تماس با مدل بررسی کنید؛ متن خروجی مدل جای کنترل دسترسی نیست. گزارش نیز باید فقط اطلاعات لازم برای عیب‌یابی را نگه دارد. اگر تاریخچه ذخیره می‌کنید، زمان نگهداری و حذف آن را مشخص کنید. هزینه مشترک کلید را هم بدون حسابداری جدا، مصرف دقیق یک مشتری خاص معرفی نکنید.
چه زمانی انتخاب نسخه جدید منطقی است؟
وقتی نسخه جدید واقعاً در حساب و سرویس مورد نظر موجود شد، همان مجموعه ارزیابی قبلی را اجرا کنید. کیفیت، خطای ساختار، زمان و هزینه هر کار پذیرفتهشده را مقایسه کنید و بخش‌های شکست را دستی بررسی کنید. اگر فقط بعضی گروه‌ها بهتر شدند، لازم نیست همه ترافیک منتقل شود. مسیر بازگشت را حفظ کنید و نام مدل و نسخه پرامپت قبلی را کنار نتیجه نگه دارید. برای انتشار اولیه نیز سهم کوچکی از درخواست‌های غیرحساس مناسب‌تر از تغییر یک‌باره کل سرویس است. نتیجه یک آزمایش محدود را به تمام کاربران، زبان‌ها و کارها تعمیم ندهید.
جمع‌بندی: انتخاب مدل را به مسئله وصل کنید
Haiku 5.5 موضوع مناسبی برای پیگیری مدل‌های کوچک‌تر است، اما تصمیم محصول باید روی نسخه قابل دسترس و نتیجه اندازه‌گیری‌شده بنا شود. امروز می‌توانید قرارداد خروجی، داده فارسی و محاسبه هزینه را با مدل‌های موجود آماده کنید و بعداً نسخه جدید را با همان معیار بسنجید. API پاستا برای بررسی کاتالوگ، قیمت تومانی و کلید مستقل، بخشی از این مسیر است؛ دسترسی به هر نسخه باید در همان کاتالوگ تأیید شود. انتخاب خوب مدلی نیست که فقط روی کاغذ ارزانتر است؛ مدلی است که کار تعریف‌شده شما را با کیفیت قابل قبول و هزینه قابل توضیح انجام میدهد.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.