هزینهٔ واقعی قابلیت AI را چگونه حساب کنیم؟

واحد درست اندازه‌گیری چیست؟

اگر فقط «هزینهٔ هر call» را داشبورد کنیم، ممکن است یک سیستم ارزان اما بی‌اثر بسازیم. سه واحد را کنار هم نگه دارید:

معیار اصلی معمولاً سومی است. اگر یک دستیار پشتیبانی در پاسخ اول ارزان باشد اما نیمی از پاسخ‌ها را کارشناس بازنویسی کند، invoice مدل تصویر کاملی از اقتصاد کار نمی‌دهد. cost per successful outcome به ما یادآوری می‌کند محصول برای «تولید متن» پول نمی‌گیرد؛ برای حل مسئله پول می‌گیرد.

• هزینهٔ هر request: برای کنترل مصرف provider و تشخیص جهش ناگهانی مفید است.
• هزینهٔ هر task کامل: شامل همهٔ callها، ابزارها، retrieval، retry و زمان انجام کار است.
• هزینهٔ هر outcome موفق: شامل اصلاح، review، escalation و کاربرانی است که به نتیجهٔ قابل‌قبول رسیده‌اند.

پنج لایهٔ هزینه را از هم جدا کنیم

۱. هزینهٔ مستقیم مدل: این لایه شامل input token، output token، مدل انتخاب‌شده، modality و تعداد دفعات فراخوانی است. قیمت‌ها و شرایط provider تغییر می‌کنند؛ بنابراین عدد قیمت را در مقاله یا spreadsheet برای همیشه ثابت نکنید. نرخ همان روز، مدل، منطقه و نوع endpoint را در برآورد ثبت کنید.

برای یک workflow چندمرحله‌ای، به‌جای این فرمول ساده:

هزینه = یک request × قیمت مدل

از چیزی شبیه این استفاده کنید:

هزینهٔ مدل = مجموع (input token + output token) در همهٔ گام‌ها، با نرخ همان مدل و endpoint

گام‌های پنهان را فراموش نکنید: classifier اولیه، خلاصه‌سازی، tool selection، تولید پاسخ، validation و retry هرکدام ممکن است یک call جدا باشند.

۲. هزینهٔ workflow و داده: مدل معمولاً تنها جزء سیستم نیست. retrieval، embedding، vector store، database، object storage، queue، network و اجرای tool هم هزینه و ظرفیت می‌خواهند. اگر Agent به چند سرویس دسترسی دارد، هزینهٔ هر مسیر را جدا ثبت کنید.

زمینهٔ داده نیز مهم است. یک prompt بزرگ ممکن است کیفیت را بهتر کند، اما input token و latency را بالا ببرد. prompt caching برای prefixهای تکرارشونده می‌تواند کمک کند؛ بااین‌حال cache hit تضمین‌شده نیست و بخش متغیر context باید درست طراحی شود. دادهٔ حساس هم بدون توجه به retention و مرز دسترسی نباید فقط به‌خاطر ارزان‌شدن وارد cache شود.

۳. هزینهٔ خطا و بازکاری: خروجی بد فقط یک response ناموفق نیست. ممکن است کاربر دوباره سؤال کند، agent retry کند، کارشناس اصلاح کند، تراکنش rollback شود یا تیم incident را بررسی کند. برای هر failure case این سؤال‌ها را بپرسید:

نرخ failure را با شدت پیامد ترکیب کنید. یک خطای نادر در draft داخلی با یک خطای نادر در پرداخت یا حذف داده هزینهٔ یکسانی ندارد. بازبینی انسانی در workflowهای AI توضیح می‌دهد چرا سطح کنترل باید با همین ریسک متناسب باشد.

۴. هزینهٔ انسان و تغییر فرایند: اگر خروجی AI نیاز به review دارد، زمان reviewer بخشی از unit economics است. اگر تیم برای استفاده از قابلیت باید داده را پاک‌سازی کند، prompt را اصلاح کند، موردهای مبهم را دستی route کند یا پاسخ‌ها را آموزش دهد، این کارها را هزینهٔ واقعی بدانید.

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

۵. هزینهٔ عملیات، امنیت و یادگیری: قابلیت production به logging، tracing، eval، alert، مدیریت secret، کنترل دسترسی، incident response، تست regression و بازبینی دوره‌ای نیاز دارد. این‌ها ممکن است در قبض provider دیده نشوند، اما بدون آن‌ها هزینهٔ شکست و ناتوانی در تشخیص خطا بالا می‌رود.

مدل، prompt، policy، داده و provider تغییر می‌کنند. هر تغییر به آزمایش، rollout تدریجی و گاهی rollback نیاز دارد. اگر هزینهٔ نگهداری و یادگیری را از ابتدا صفر فرض کنیم، برآورد ماه سوم غیرواقعی خواهد شد.

• چند request اضافه تولید می‌شود؟
• چه مدت از وقت انسان مصرف می‌شود؟
• آیا داده یا action باید rollback شود؟
• آیا اعتماد کاربر یا درآمد در خطر است؟
• چند بار همان خطا در روز یا ماه تکرار می‌شود؟

یک مدل ساده برای برآورد قبل از launch

برای شروع، یک spreadsheet یا سند کوچک با این ستون‌ها بسازید:

بعد سه سناریو بنویسید: کم‌مصرف، معمول و پرمصرف. سناریوی معمول برای برنامه‌ریزی کافی نیست؛ اگر usage دو برابر شد، context بزرگ‌تر شد یا نرخ escalation بالا رفت، باید بدانیم چه اتفاقی می‌افتد. عددها را با فرض و منبع ثبت کنید و بعد از launch با usage واقعی مقایسه کنید.

فرمول مفهومی می‌تواند این باشد:

TCO = هزینهٔ مدل + داده و زیرساخت + ابزارها + review و پشتیبانی + خطا و بازکاری + عملیات و امنیت

و برای مقایسهٔ محصول:

cost per successful outcome = TCO / تعداد outcomeهای موفق و قابل‌قبول

این فرمول حسابداری کامل نیست و جای finance review را نمی‌گیرد؛ یک قرارداد تصمیم است تا هزینه‌های فراموش‌شده را زودتر وارد گفت‌وگو کند.

• سناریو و نوع کاربر
• تعداد task در روز و ماه
• متوسط و صدک بالای token ورودی و خروجی
• تعداد call مدل در هر task
• tool call، retrieval و storage
• نرخ retry، failure و escalation
• زمان review انسانی و نرخ اصلاح
• هزینهٔ عملیات و پشتیبانی
• outcome مورد انتظار و تعریف «موفق»

مدل کوچک‌تر، batch یا caching؛ تصمیم را با outcome بگیرید

مستندات رسمی OpenAI کاهش token و request و انتخاب مدل کوچک‌تر را از راه‌های کاهش هزینه و latency می‌دانند. این‌ها نقطهٔ شروع خوبی هستند، اما هرکدام trade-off دارند.

تصمیم درست از سؤال «کدام گزینه ارزان‌تر است؟» شروع نمی‌شود؛ از سؤال «برای این outcome، چه کیفیت، latency و ظرفیت خطا قابل‌قبول است؟» شروع می‌شود.

• مدل کوچک‌تر: ممکن است ارزان‌تر و سریع‌تر باشد، اما اگر کیفیت لازم را ندهد، retry و review را بالا می‌برد.
• کاهش token: context کوتاه‌تر هزینه را کم می‌کند، اما حذف شواهد لازم می‌تواند خطا و escalation بسازد.
• Prompt caching: prefix تکراری را ارزان‌تر و سریع‌تر می‌کند، اما به تکرار واقعی، طراحی prefix و retention مناسب نیاز دارد.
• Batch API: برای کار غیرهم‌زمان مناسب است؛ وقتی کاربر منتظر پاسخ فوری است، پنجرهٔ تکمیل و رفتار خطا باید در تجربهٔ محصول دیده شود.
• Flex processing: برای کارهای کم‌اولویت یا غیرتعاملی می‌تواند trade-off هزینه و latency ایجاد کند، نه این‌که هزینه را جادویی حذف کند.

مثال فرضی: خلاصه‌سازی تیکت پشتیبانی

یک تیم پشتیبانی را فرض کنید که می‌خواهد قبل از پاسخ کارشناس، تیکت را خلاصه و دسته‌بندی کند. در ظاهر، یک call ساده کافی است. در عمل، مسیر ممکن است شامل دریافت تاریخچه، حذف PII، خلاصه‌سازی، تشخیص priority، پیشنهاد پاسخ، validation و review باشد.

در برآورد اولیه این موارد را جدا می‌کنیم: tokenهای تاریخچه، هزینهٔ حذف یا پردازش داده، call دسته‌بندی، call خلاصه‌سازی، زمان کارشناس برای اصلاح، نرخ ticketهای خارج از دامنه و هزینهٔ نگهداری eval. اگر خروجی فقط وقتی موفق است که کارشناس آن را بدون اصلاح جدی بپذیرد، معیار موفقیت همین است؛ نه تعداد خلاصه‌های تولیدشده.

برای ticketهای کم‌خطر شاید model کوچک و sampling کافی باشد. برای ticketهای حساس، ممکن است خروجی فقط پیشنهاد باشد و کارشناس تصمیم را نگه دارد. اگر مدل کوچک‌تر نرخ اصلاح را بالا ببرد، هزینهٔ هر token پایین آمده ولی cost per successful ticket بالا رفته است. این مثال فرضی است و هیچ عدد، مشتری یا نتیجهٔ سازمانی به آن نسبت داده نمی‌شود.

اثر AI بر Agile و مدیریت پروژه

AI مفهوم «ظرفیت» را تغییر می‌دهد. تعداد بیشتری artifact در زمان کوتاه‌تر تولید می‌شود، اما review، تست، تصمیم و نگهداری ممکن است گلوگاه جدید بسازد. بنابراین در backlog یک ticket با عنوان «افزودن AI» کافی نیست؛ باید مسیر هزینه و outcome آن شکسته شود.

AI در این فرایند بیشتر augmentation است: محاسبه و forecast اولیه را سریع‌تر می‌کند، اما تعریف outcome، budget، تحمل ریسک و تصمیم ادامه یا توقف انسانی می‌ماند. اگر داشبورد فقط token را نشان دهد، تیم ممکن است رفتار اشتباه را بهینه کند. باید هزینهٔ واقعی را به decision و result وصل کنیم.

• در discovery: هزینهٔ حل مسئله و outcome را از هزینهٔ demo جدا کنید.
• در planning: هزینهٔ request، داده، review، failure و عملیات را کنار effort ساخت بیاورید.
• در sprint: قبل از تعهد، سناریو و budget مصرف را مشخص و سقف retry یا tool call را تعریف کنید.
• در review: کیفیت، latency، cost per task و نرخ اصلاح را هم‌زمان با ظاهر feature ببینید.
• در retrospective: رشد usage را از رشد ارزش جدا کنید و جابه‌جایی کار بین مدل و انسان را بررسی کنید.

بعد از launch چه چیزهایی را پایش کنیم؟

حداقل این شاخص‌ها را به تفکیک سناریو و model version دنبال کنید:

هشدار فقط برای افزایش invoice نیست. اگر usage ثابت است ولی نرخ اصلاح، صف review یا failure بالا رفته، هزینهٔ پنهان در حال رشد است. اگر هزینه پایین آمده ولی outcome یا اعتماد افت کرده، بهینه‌سازی موفق نبوده است.

• input و output token و سهم cached token
• تعداد request، tool call، retry و timeout
• هزینهٔ هر task و cost per successful outcome
• latency و صدک‌های آن
• نرخ اصلاح، escalation، fallback و رد خروجی
• زمان review انسانی و طول صف
• خطاهای پرپیامد، نشت داده و actionهای rollback‌شده
• adoption واقعی و تعداد taskهایی که به نتیجهٔ کامل رسیده‌اند

چک‌لیست تصمیم اقتصادی قابلیت AI

• outcome موفق را در یک جمله تعریف کرده‌ایم؟
• هزینهٔ همهٔ callها، ابزارها و مسیرهای retry را می‌دانیم؟
• token و context معمول و بدترین سناریو را جدا کرده‌ایم؟
• داده، retrieval، storage و زیرساخت در برآورد آمده‌اند؟
• زمان review، اصلاح، پشتیبانی و آموزش تیم را حساب کرده‌ایم؟
• failure و rollback هزینهٔ قابل‌تخمین دارند؟
• cost per successful outcome از cost per request جداست؟
• model، prompt و provider قابل‌شناسایی و قابل‌مقایسه‌اند؟
• برای رشد usage، budget و trigger بازبینی داریم؟
• شرط توقف وقتی هزینه، latency یا خطا از آستانه عبور کند ثبت شده است؟

اثر AI بر این فرایند

AI می‌تواند forecast مصرف، دسته‌بندی usage، کشف مسیرهای پرهزینه و مقایسهٔ سناریوها را سریع‌تر کند؛ این نقش عمدتاً augmentation است. اما ممکن است خود AI با retry، context بزرگ، tool call یا خروجی ضعیف هزینه بسازد. trade-off اصلی میان هزینهٔ مستقیم، کیفیت، latency، ظرفیت review و ریسک failure است. معیار بازبینی باید cost per successful outcome را در کنار token و invoice نشان دهد و مالک انسانی budget، تحمل ریسک و تصمیم ادامه یا توقف را نگه دارد.

جمع‌بندی: ارزان‌ترین call الزاماً ارزان‌ترین محصول نیست

واقعیت عمومی: مستندات رسمی OpenAI کاهش request و token، انتخاب مدل متناسب، پردازش غیرهم‌زمان و prompt caching را به‌عنوان اهرم‌های کاهش هزینه و latency توضیح می‌دهند و بر اندازه‌گیری usage واقعی تأکید دارند. نرخ provider و شرایط cache تغییرپذیرند و باید هنگام برآورد از منبع همان روز استفاده شوند.

تحلیل من: قابلیت AI را باید مثل یک workflow با هزینهٔ مستقیم و غیرمستقیم دید. هزینهٔ model، داده، ابزار، review، خطا، پشتیبانی، امنیت و تغییر فرایند در نهایت روی cost per successful outcome اثر می‌گذارند. اگر فقط token را کم کنیم اما اصلاح و failure زیاد شود، مسئله را حل نکرده‌ایم.

پیشنهاد حکیم: یک سناریوی واقعی را انتخاب کنید، TCO را با سه حالت کم، معمول و بد محاسبه کنید، metric موفقیت را قبل از launch ثبت کنید و usage واقعی را پس از انتشار با فرض‌ها مقایسه کنید. AI زمانی ارزش اقتصادی دارد که نه فقط تولید را ارزان‌تر، بلکه رسیدن به نتیجهٔ قابل‌اعتماد را قابل‌اندازه‌گیری‌تر کند.

منابع اولیه برای بررسی

• راهنمای رسمی OpenAI دربارهٔ cost optimization، کاهش request و token، انتخاب مدل، Batch و flex processing: https://developers.openai.com/api/docs/guides/cost-optimization.md — بررسی‌شده در 2026-09-14.
• مستندات رسمی OpenAI دربارهٔ Batch API، کار غیرهم‌زمان، هزینهٔ کمتر و پنجرهٔ تکمیل: https://developers.openai.com/api/docs/guides/batch.md — بررسی‌شده در 2026-09-14.
• مستندات رسمی OpenAI دربارهٔ prompt caching، cache hit، tokenهای cacheشده، latency و محاسبهٔ هزینه: https://developers.openai.com/api/docs/guides/prompt-caching.md — بررسی‌شده در 2026-09-14.