راهنمای مدل‌های کلاد — کدام مدل برای چه کاری

سؤال اشتباه: «قوی‌ترین مدل کدام است؟»

الگوی رایج در تیم‌هایی که تازه با کلاد (Claude) کار می‌کنند این است: بزرگ‌ترین مدل را برمی‌دارند، همه‌ی مسیرهای محصول را به آن وصل می‌کنند، و چند ماه بعد که صورت‌حساب و تأخیر پاسخ‌ها بالا رفت دنبال «بهینه‌سازی» می‌گردند. اشکال از بهینه‌سازی نبوده؛ از این بوده که انتخاب مدل زبانی به‌عنوان یک تصمیم سراسری گرفته شده، در حالی که در عمل یک تصمیم به‌ازای هر کار است.

مدل بزرگ‌تر در همه‌چیز بهتر نیست — گران‌تر و کندتر هم هست. در یک محصول هوش مصنوعی واقعی، بخش زیادی از فراخوانی‌ها کارهای کوچک‌اند: دسته‌بندی یک پیام، استخراج چند فیلد از متن، بازنویسی یک جمله، یا تصمیم اینکه کدام ابزار باید صدا زده شود. برای این‌ها مدل کوچک‌تر یک سازش نیست؛ جواب مهندسی درست است.

مدل‌ها و اعداد پایه

سه نکته مستقیم از همین جدول بیرون می‌آید. اول، فاصله‌ی قیمت بین رده‌ها ده‌برابری است نه ده‌درصدی؛ ورودی Haiku 4.5 یک‌دهم ورودی Fable 5.1 است. دوم، در هر پنج مدل قیمت خروجی پنج برابر ورودی است — یعنی کنترل طول پاسخ معمولاً اهرم بزرگ‌تری از کوتاه‌کردن prompt است. سوم، پنجره‌ی زمینه در بیشتر مدل‌ها یک میلیون توکن است و تنها Haiku 4.5 با ۲۰۰ هزار توکن متفاوت است؛ پس «پنجره کم می‌آورد» دیگر دلیل خوبی برای رفتن به رده‌ی بالاتر نیست.

رده‌ها در عمل چه فرقی دارند

روی یک پرسش ساده، تفاوت رده‌ها را احتمالاً اصلاً نمی‌بینید. تفاوت جایی ظاهر می‌شود که کار سخت می‌شود:

• عمق استدلال چندمرحله‌ای. وقتی جواب درست نیازمند چند گام وابسته است و اشتباه در گام دوم کل نتیجه را خراب می‌کند، رده‌ی بالاتر محسوس‌تر است.
• پایبندی به دستور زیر فشار. با یک system prompt طولانی که ده قید همزمان دارد، مدل‌های کوچک‌تر زودتر یکی از قیدها را رها می‌کنند.
• کیفیت روی ورودی نامرتب. متن OCR‌شده‌ی بد، HTML خام، یا فارسی با غلط تایپی و نیم‌فاصله‌ی نادرست، فاصله‌ی رده‌ها را باز می‌کند.
• پایداری در حلقه‌ی ایجنت. یک ایجنت ممکن است سی گام بردارد. خطای کوچک در هر گام تجمعی است و نرخ موفقیت کل کار را سریع پایین می‌آورد.
• تأخیر. مدل‌های سبک‌تر معمولاً سریع‌تر پاسخ می‌دهند. برای مسیرهایی که کاربر منتظر است، این خودش یک معیار کیفیت است.

این تفاوت‌ها پیوسته‌اند، نه پله‌ای. هیچ خط قرمزی وجود ندارد که پایین‌ترش مدل «کار نکند»؛ آنچه تغییر می‌کند نرخ خطاست. برای همین سؤال درست این نیست که «کدام مدل بهتر است»، بلکه این است که «نرخ خطای قابل قبول برای این کار چقدر است و ارزان‌ترین مدلی که به آن می‌رسد کدام است».

کار را دسته‌بندی کنید، نه مدل را

روش عملی این است: فهرست کارهای محصول را بنویسید و هرکدام را در یکی از سه دسته بگذارید.

1. کارهای مکانیکی با خروجی محدود — دسته‌بندی، برچسب‌زنی، تشخیص زبان، استخراج فیلد از فرم، خلاصه‌ی کوتاه، تصمیم اینکه پیام کاربر به کدام مسیر برود. ورودی کوتاه، خروجی کوتاه، معیار درستی روشن. Claude Haiku 4.5 نقطه‌ی شروع درست است.
2. کارهای اصلی محصول — پاسخ به کاربر با تکیه بر اسناد بازیابی‌شده، نوشتن پاسخ پشتیبانی، فراخوانی ابزار در یک گفت‌وگوی چندمرحله‌ای، تبدیل نیاز کاربر به query. کیفیت مستقیم دیده می‌شود اما کار غیرعادی سخت نیست. Claude Sonnet 5 معمولاً تعادل درست بین کیفیت و هزینه است.
3. کارهای سخت و کم‌تعداد — بازسازی یک ماژول کد، تحلیل یک سند بلند، برنامه‌ریزی چندمرحله‌ای که خطایش گران است، یا نقش «داور» برای ارزیابی خروجی مدل‌های دیگر. رده‌ی Opus (claude-opus-5 یا claude-opus-4-8) و برای سخت‌ترین موارد claude-fable-5-1.

اگر مثل بیشتر محصول‌ها بخش عمده‌ی فراخوانی‌های شما در دسته‌ی اول و دوم باشد، سهم دسته‌ی سوم از صورت‌حساب قابل تحمل می‌شود — حتی اگر گران‌ترین مدل را برایش انتخاب کنید.

کجا مدل ارزان‌تر جواب درست است

چند نشانه‌ی روشن که کار به رده‌ی بالا نیاز ندارد:

• خروجی از یک مجموعه‌ی بسته انتخاب می‌شود: یک برچسب، بله/خیر، یا یکی از n ابزار.
• درستی را می‌شود با کد بررسی کرد، نه با قضاوت انسان — JSON معتبر است؟ فیلد اجباری آمده؟ عدد در بازه است؟
• prompt پر از مثال است. few-shot خوب اغلب جای رده‌ی بالاتر را می‌گیرد و خیلی ارزان‌تر تمام می‌شود.
• کار در یک حلقه‌ی پرتکرار اجرا می‌شود و تأخیر برای کاربر محسوس است.
• خطا برگشت‌پذیر است: اگر مدل کوچک شکست خورد، می‌شود همان درخواست را به مدل بزرگ‌تر داد.

مورد آخر مهم‌ترین است. الگوی fallback یعنی هزینه‌ی حالت رایج را با مدل ارزان می‌دهید و فقط برای موارد سخت پول رده‌ی بالا را می‌پردازید. شرطش این است که «شکست» تعریف قابل تشخیص داشته باشد: خروجی نامعتبر، اعلام عدم اطمینان توسط خود مدل، یا ردشدن از یک بررسی برنامه‌ای.

معماری چندمدلی: مسیریابی و زنجیره

دو الگوی رایج وجود دارد. اولی مسیریابی است: یک مدل ارزان تصمیم می‌گیرد درخواست به کدام مدل برود.

def answer(req):
    kind = classify(req, model="claude-haiku-4-5")   # مسیریاب ارزان
    if kind == "simple_lookup":
        return respond(req, model="claude-haiku-4-5")
    if kind == "needs_tools":
        return agent_loop(req, model="claude-sonnet-5")
    return deep_answer(req, model="claude-opus-5")   # فقط کارهای سخت

دو هشدار درباره‌ی مسیریابی: مسیریاب خودش هزینه و تأخیر اضافه می‌کند، پس اگر فاصله‌ی قیمت دو مسیر کم است زحمتش نمی‌ارزد؛ و مسیریاب اشتباه بدترین حالت را می‌سازد — کار سخت به مدل کوچک می‌رود و جواب بد بی‌سروصدا به کاربر می‌رسد. مسیریاب هم مثل بقیه‌ی سیستم باید ارزیابی شود.

الگوی دوم زنجیره است: مدل بزرگ یک بار طرح یا قالب می‌سازد و مدل کوچک هزاران بار آن را اجرا می‌کند. مثلاً Opus روی ۵۰ نمونه‌ی واقعی قواعد استخراج و مثال‌های few-shot را می‌نویسد و Haiku همان را روی میلیون‌ها رکورد اجرا می‌کند. هزینه‌ی طراحی یک‌بار پرداخت می‌شود، هزینه‌ی اجرا در رده‌ی ارزان می‌ماند.

چطور تصمیم را اندازه بگیرید

بدون معیار، انتخاب مدل به سلیقه برمی‌گردد. حداقل کاری که باید انجام دهید:

1. سی تا صد نمونه‌ی واقعی از داده‌ی خودتان جمع کنید — نه نمونه‌های ساختگی، و نه فقط حالت‌های آسان. حالت‌های شکست دیروز، بهترین داده‌ی امروز است.
2. برای هر نمونه خروجی درست یا معیار پذیرش بنویسید.
3. از ارزان‌ترین رده شروع کنید و بالا بروید، نه برعکس. اولین مدلی که به آستانه‌ی قابل قبول می‌رسد، همان است.
4. هزینه و تأخیر را کنار دقت ثبت کنید. مدلی که دو درصد بهتر و سه برابر گران‌تر است، برای یک مسیر پرترافیک احتمالاً انتخاب بدی است.

اگر نمی‌توانید توضیح دهید چرا مدل فعلی‌تان از رده‌ی پایین‌تر بهتر است، احتمالاً نیست — فقط امتحانش نکرده‌اید.

برای جزئیات این کار ارزیابی ایجنت را ببینید. و اگر مسئله‌ی اصلی‌تان صورت‌حساب است، پیش از عوض‌کردن مدل سراغ ساختار هزینه و توکن و prompt caching بروید؛ کاهش هزینه از آن سمت معمولاً بزرگ‌تر و بی‌ریسک‌تر است.

یک نکته‌ی آخر که هزینه‌ی فنی زیادی از تیم‌ها می‌گیرد: شناسه‌ی مدل را در سراسر کد پخش نکنید. یک متغیر پیکربندی به‌ازای هر کار (MODEL_CLASSIFY، MODEL_CHAT، MODEL_DEEP) بگذارید تا جابه‌جایی بین رده‌ها یک تغییر پیکربندی باشد، نه یک refactor. انتخاب مدل تصمیمی نیست که یک بار گرفته شود؛ با تغییر ترافیک، داده و مدل‌های موجود دوباره باید گرفته شود.