کدام مدل هوش مصنوعی برای پروژه شما؟ راهنمای انتخاب فنی
وقتی فارسی جستجو میکنید «بهترین مدل هوش مصنوعی»، چیزی که میگیرید فهرست سایتهای چت است: کدام دستیار برای نوشتن مقاله بهتر است، کدام یکی خوشصحبتتر است. اما شما دارید یک محصول میسازید و سؤال کاملاً متفاوتی دارید: کدام مدل را داخل کد قرار دهم که هم جواب درست بدهد، هم دیر نکند، هم وقتی از دسترس خارج شد سرویسم نخوابد، و هم ماه بعد صورتحساب غافلگیرم نکند؟ این مقاله دربارهٔ همان تصمیم است — یک چارچوب، نه یک جدول قیمت. اعداد قیمت هر مدل جای دیگری است: مقایسهٔ قیمت API مدلهای هوش مصنوعی و صفحهٔ مدلها که لحظهای بهروز میشود.
یک تذکر پیش از شروع: در ادامه از خانوادههای مدل بهصورت عمومی حرف میزنیم، اما نمونهکدها با نام مدلهایی نوشته شده که امروز روی درگاه نِت اَرز فعالاند، یعنی خانوادهٔ OpenAI؛ بقیهٔ ارائهدهندهها در حال اتصالاند و پیش از تکیه کردن به نام یک مدل، فهرست فعال حساب خودتان را ببینید.
اول نوع کار را مشخص کنید، بعد سراغ مدل بروید
بزرگترین اتلاف بودجه در پروژههای هوش مصنوعی این است که همهچیز را با گرانترین مدل انجام میدهند. حال آنکه بخش زیادی از کارهای واقعی اصلاً به استدلال سنگین نیاز ندارند. کارتان را در یکی از این دستهها بگذارید:
| نوع کار | مثال واقعی | ردهٔ مدل مناسب | معیار اصلی |
|---|---|---|---|
| طبقهبندی و برچسبگذاری | دستهبندی تیکت، تشخیص احساس نظر | سبکترین ردهٔ موجود | هزینه و تأخیر |
| استخراج داده | بیرون کشیدن مبلغ و تاریخ از فاکتور | ردهٔ میانی با خروجی ساختاریافته | پایداری فرمت JSON |
| تولید متن کوتاه | توضیح محصول، پاسخ پشتیبانی | ردهٔ میانی | کیفیت فارسی |
| گفتگوی چندمرحلهای | چتبات سایت با تاریخچه | ردهٔ میانی سریع | تأخیر تا اولین توکن |
| کدنویسی و بازنویسی | تولید تست، مهاجرت کد | ردهٔ بالا | دقت، پنجرهٔ متن |
| استدلال چندمرحلهای | تحلیل مالی، مسئلهٔ منطقی | مدل استدلالی | دقت، نه سرعت |
قاعدهٔ عملی: از سبکترین ردهٔ ممکن شروع کنید و فقط وقتی بالا بروید که با داده ثابت کرده باشید مدل سبک شکست میخورد. تفاوت هزینهٔ بین یک مدل nano و یک مدل پرچمدار در بعضی موارد بیش از بیست برابر است و برای کاری مثل برچسبگذاری تیکت، این تفاوت هیچ ارزشی تولید نمیکند.
کیفیت فارسی را چطور بسنجیم؟ (نه با حس)
«این مدل فارسیاش بهتر است» جملهای است که همه میگویند و هیچکس اندازه نگرفته است. راه درست، ساختن یک مجموعهٔ ارزیابی کوچک از دادههای واقعی خودتان است: سی تا پنجاه نمونهٔ واقعی از همان کاری که قرار است مدل انجام دهد، بههمراه پاسخ درستی که خودتان تأیید کردهاید. سی نمونه کم به نظر میرسد اما برای رد کردن یک مدل کاملاً کافی است.
در ارزیابی فارسی به این چهار چیز جدا نمره بدهید، چون مدلها در آنها یکسان نیستند: درستی محتوایی؛ روان بودن نگارش فارسی (بعضی مدلها ترجمهزده مینویسند)؛ رعایت دستور (مثلاً وقتی میگویید «فقط سه گزینه بده»)؛ و پایبندی به زبان (مدل وسط جواب فارسی به انگلیسی نپرد). این معیار چهارم را دستکم نگیرید؛ در محصول فارسیزبان، جواب انگلیسی یعنی خطا.
تأخیر: کدام عدد را واقعاً باید اندازه بگیرید؟
دو عدد متفاوت وجود دارد و اشتباه گرفتنشان باعث تصمیمهای غلط میشود. زمان تا اولین توکن چیزی است که کاربر بهعنوان «سرعت» حس میکند، و زمان کل تولید چیزی است که برای کارهای پسزمینه اهمیت دارد. در یک چتبات، مدلی که یک ثانیهای شروع به نوشتن میکند و ده ثانیه طول میکشد، از مدلی که چهار ثانیه سکوت میکند و شش ثانیهای تمام میکند، خیلی سریعتر احساس میشود.
همچنین میانگین را کنار بگذارید و صدک ۹۵ را ببینید؛ تجربهٔ بد کاربر در همان ۵ درصد دم توزیع اتفاق میافتد. مدلهای استدلالی ذاتاً تأخیر بالا و پرنوسان دارند و برای مسیرهای تعاملی مناسب نیستند، مگر اینکه کار را به صف ببرید. این اسکریپت کوچک هر سه معیار را با هم اندازه میگیرد:
import json, os, statistics, time
from openai import OpenAI
client = OpenAI(base_url="https://netarz.ir/api/ai/v1", api_key=os.environ["NETARZ_AI_KEY"])
with open("cases.json", encoding="utf-8") as handle:
CASES = json.load(handle) # [{"input": "...", "must_include": ["..."]}]
def evaluate(model: str) -> dict:
latencies, valid_json, passed = [], 0, 0
for case in CASES:
started = time.perf_counter()
response = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": "Answer in Persian. Return a JSON object only."},
{"role": "user", "content": case["input"]},
],
response_format={"type": "json_object"},
)
latencies.append(time.perf_counter() - started)
try:
data = json.dumps(json.loads(response.choices[0].message.content), ensure_ascii=False)
except json.JSONDecodeError:
continue
valid_json += 1
if all(key in data for key in case["must_include"]):
passed += 1
latencies.sort()
return {
"model": model,
"p50": round(statistics.median(latencies), 2),
"p95": round(latencies[int(len(latencies) * 0.95) - 1], 2),
"json_ok": f"{valid_json}/{len(CASES)}",
"passed": f"{passed}/{len(CASES)}",
}
for candidate in ["gpt-5-mini", "gpt-4.1-mini", "gpt-4o-mini"]:
print(evaluate(candidate))
خروجی این اسکریپت، در عرض چند دقیقه و با هزینهای در حد چند سنت، همان چیزی است که ده مقالهٔ مقایسهای به شما نمیدهند: عدد، روی دادهٔ خودتان.
پنجرهٔ متن؛ چقدر واقعاً لازم دارید؟
پنجرهٔ متن بزرگ جذاب است اما اغلب اوقات پاسخ درست به سؤال اشتباه است. اگر میخواهید مدل به دویست صفحه سند دسترسی داشته باشد، ریختن همهٔ آن در هر درخواست هم گران است و هم دقت را پایین میآورد؛ مدلها در متنهای خیلی طولانی، اطلاعات وسط متن را بیشتر از ابتدا و انتها از دست میدهند. راهحل درست معمولاً بازیابی است: فقط قطعههای مرتبط را پیدا کنید و همان را بفرستید.
پنجرهٔ بزرگ آنجا واقعاً به کار میآید که ورودی بهطور طبیعی یکپارچه است و نمیشود تکهاش کرد: یک فایل کد بلند، یک قرارداد که ارجاعات داخلی زیاد دارد، یا تاریخچهٔ یک گفتگوی طولانی. برای بقیهٔ موارد، پنجرهٔ ۱۲۸ هزار توکنی بیش از حد کافی است.
خروجی ساختاریافته؛ معیاری که همه فراموش میکنند
اگر خروجی مدل قرار است وارد دیتابیس شود، «کیفیت متن» تقریباً بیمعناست و چیزی که اهمیت دارد این است: از هزار درخواست، چند تا JSON معتبر و مطابق ساختار برمیگردد؟ تفاوت ۹۷ درصد و ۹۹٫۹ درصد در مقیاس، تفاوت بین یک صف خطای مدیریتشدنی و یک کابوس عملیاتی است.
سه ابزار برای بالا بردن این نرخ دارید: پارامتر response_format با حالت JSON؛ توصیف صریح ساختار در پیام سیستم بههمراه یک نمونهٔ کامل؛ و اعتبارسنجی سمت خودتان با یک تلاش مجدد که در آن متن خطا را به مدل برمیگردانید. الگوی سوم را همیشه پیاده کنید، حتی با بهترین مدل — چون شکستهای نادر در مقیاس بزرگ نادر نیستند.
هزینه به ازای هر هزار درخواست؛ فرمول، نه جدول
قیمتها تغییر میکنند، پس بهجای حفظ کردن عدد، فرمول را بردارید:
هزینهٔ هزار درخواست =
((میانگین توکن ورودی × نرخ ورودی هر میلیون توکن)
+ (میانگین توکن خروجی × نرخ خروجی هر میلیون توکن)) × 1000 ÷ 1,000,000
سه نکته که این محاسبه را واقعی میکند. اول، برای فارسی حاشیهٔ اطمینان بگذارید؛ متن فارسی معمولاً توکن بیشتری از متن انگلیسی هماندازه مصرف میکند. دوم، پیام سیستم و تاریخچهٔ گفتگو در هر درخواست دوباره فرستاده و دوباره حساب میشوند؛ در یک چتبات، بخش عمدهٔ هزینه معمولاً همینجاست، نه در پاسخ. سوم، اگر پیشوند ثابتی دارید (دستور طولانی، دانش پایه)، کش ورودی هزینهٔ آن بخش را بهشکل چشمگیری پایین میآورد. مبنای محاسبهٔ توکن را با مثال در توکن چیست و هزینهٔ API چطور حساب میشود و مقایسهٔ نرخها را در مقایسهٔ قیمت API مدلها ببینید. اگر هنوز بین API و اشتراک مردد هستید، تفاوت API و اشتراک این تصمیم را جدا حل کرده است.
وقتی مدل از دسترس خارج شود چه میکنید؟
این سؤال، فرق یک نمونهٔ آزمایشی با یک محصول است. هر ارائهدهندهای قطعی، کندی موقت و سقف نرخ دارد. حداقل چیزی که باید داشته باشید یک زنجیرهٔ جایگزین است: مدل اصلی، یک مدل همرده بهعنوان پشتیبان، و یک مدل سبک بهعنوان آخرین خط دفاع.
CHAIN = ["gpt-5-mini", "gpt-4.1-mini", "gpt-4o-mini"]
def ask(messages, timeout=20):
last_error = None
for model in CHAIN:
try:
return client.with_options(timeout=timeout, max_retries=1).chat.completions.create(
model=model,
messages=messages,
)
except Exception as error: # noqa: BLE001
last_error = error
continue
raise last_error
سه قاعده برای اینکه این الگو واقعاً کار کند: تایماوت را کوتاه و صریح بگذارید (بدون تایماوت، جایگزین هیچوقت فعال نمیشود)؛ خروجی همهٔ مدلهای زنجیره را با همان مجموعهٔ ارزیابی بسنجید تا جایگزین، کیفیت را ساکت پایین نیاورد؛ و هر بار که به پلههای پایینتر میافتید لاگ بزنید، وگرنه ماهها با مدل ضعیفتر سرویس میدهید و نمیفهمید. اگر چند مدل را از یک base_url صدا بزنید، این جابهجایی فقط تغییر یک رشته است.
چکلیست تصمیم
- سی تا پنجاه نمونهٔ واقعی از کار خودتان جمع کنید و پاسخ درست را مشخص کنید.
- دو یا سه مدل کاندید را با همان اسکریپت بسنجید و صدک ۹۵ تأخیر، نرخ JSON معتبر و درصد قبولی را ثبت کنید.
- سبکترین مدلی را انتخاب کنید که آستانهٔ قابل قبول شما را رد میکند، نه بهترین مدل مطلق.
- یک زنجیرهٔ جایگزین با تایماوت مشخص تعریف کنید و افت به پلههای پایین را لاگ بزنید.
- مصرف را به تفکیک قابلیت ثبت کنید تا بدانید هزینه کجا تولید میشود.
- هر چند ماه ارزیابی را تکرار کنید؛ مدلها و نرخها هر دو تغییر میکنند.
برای اجرای این چارچوب فقط به یک کلید و کمی اعتبار نیاز دارید؛ همان اسکریپت ارزیابی معمولاً با کمتر از یک دلار کامل اجرا میشود. جزئیات مسیرها و پارامترها در مستندات API نِت اَرز است، فهرست و نرخ لحظهای مدلهای فعال در صفحهٔ مدلها، و تصویر کلی سرویس در API هوش مصنوعی با پرداخت ریالی. تصمیم را با داده بگیرید؛ همین یک عادت، بیشتر از هر انتخاب مدلی به کیفیت محصولتان اضافه میکند.
آموزشهای کاربردی در گیسو
گیسو برند هوش مصنوعی نِت اَرز است، با همین حساب و همین اعتبار. این راهنماها قدمبهقدم نشان میدهند همین کار را چطور با هوش مصنوعی انجام دهید.
پرسشهای پرتکرار
برای شروع یک پروژه جدید کدام رده مدل را انتخاب کنم؟
با سبکترین ردهٔ موجود شروع کنید و فقط وقتی بالاتر بروید که ارزیابی روی دادههای واقعی خودتان نشان دهد مدل سبک شکست میخورد. برای کارهایی مثل طبقهبندی و خلاصهسازی کوتاه، مدلهای اقتصادی معمولاً کافیاند و اختلاف هزینه چند برابر است.
چند نمونه برای ارزیابی مدل کافی است؟
سی تا پنجاه نمونهٔ واقعی از همان کاری که در محصول انجام میشود، برای رد کردن گزینههای نامناسب کافی است. مهمتر از تعداد این است که نمونهها واقعی باشند و پاسخ درستشان را خودتان تأیید کرده باشید، نه اینکه ساختگی نوشته شوند.
مدل استدلالی برای چتبات سایت مناسب است؟
معمولاً نه. این مدلها پیش از پاسخ، مراحل بیشتری طی میکنند و تأخیرشان هم بالاتر و هم پرنوسانتر است که برای تجربهٔ تعاملی مناسب نیست. آنها را برای کارهای پسزمینه و مسائل تحلیلی نگه دارید.
برای جابهجایی بین مدلها باید کدم را بازنویسی کنم؟
اگر از یک آدرس پایهٔ سازگار با فرمت OpenAI استفاده کنید، تغییر مدل فقط عوض کردن مقدار پارامتر model است. روی درگاه نِت اَرز هماکنون مدلهای OpenAI فعال است و بقیهٔ ارائهدهندهها در حال اتصالاند؛ فهرست فعال را در صفحهٔ مدلها ببینید.
نظر خوانندگان
هنوز نظری ثبت نشده. اگر این مقاله پرسشتان را جواب داد یا جای چیزی در آن خالی ماند، همینجا بنویسید.