پس از launch قابلیت AI چه چیزهایی را پایش کنیم؟

قبل از انتخاب metric، واحد پایش را تعریف کنید

اول مشخص کنید «یک موفقیت» چیست. در یک قابلیت خلاصه‌سازی، ممکن است task موفق خلاصهٔ قابل استفاده با پوشش نکات مهم و بدون افشای داده باشد. در پاسخ‌گویی، شاید پاسخ درست، citation معتبر یا انتقال به انسان معیار باشد. در workflow فروش، فقط متن خوب کافی نیست؛ شاید نتیجهٔ مهم کاهش کار دستی بدون افزایش خطای qualification باشد.

برای هر use case این چهار چیز را بنویسید:

این تعریف جلوی مقایسهٔ بی‌معنی را می‌گیرد. میانگین token یا تعداد request به‌خودی‌خود نمی‌گوید feature ارزشمند است. باید بدانیم هر request بخشی از کدام کار واقعی بوده است.

• واحد: request، conversation، task، ticket، session یا action.
• outcome: کاربر یا تیم در پایان چه نتیجه‌ای باید بگیرد؟
• failure: چه چیزی فقط بد نیست، بلکه باید به‌عنوان شکست ثبت شود؟
• مالک: چه کسی با دیدن metric تصمیم می‌گیرد؟

پنج لایهٔ metric که باید کنار هم دیده شوند

۱. کیفیت task، نه فقط کیفیت متن: کیفیت را به رفتار مورد انتظار وصل کنید:

اگر هدف قابلیت «پیش‌نویس» است، edit rate الزاماً شکست نیست. ممکن است ویرایش کوتاه نشانهٔ همکاری خوب باشد و ویرایش کامل نشانهٔ خروجی کم‌ارزش. تعریف task کمک می‌کند این دو را از هم جدا کنیم.

۲. سلامت فنی و مسیر workflow: برای هر request فقط پاسخ نهایی را نبینید. زنجیرهٔ کامل را trace کنید:

راهنمای رسمی OpenAI برای production، model monitoring را پیگیری عملکرد مدل در طول زمان و تشخیص degradation توضیح می‌دهد و latency را بخشی از چرخهٔ request می‌داند. برای تیم کوچک، همین نکته کافی است که latency را از quality جدا نکنیم: خروجی عالی که در لحظهٔ نامناسب نمی‌رسد، ممکن است workflow را خراب کند.

۳. اقتصاد واقعی هر task: هزینهٔ ماهانه به‌تنهایی برای تصمیم‌گیری کم است. cost per request، cost per successful task، token usage، هزینهٔ tool و زمان review را کنار هم ببینید. اگر مدل ارزان‌تر شد اما خطای آن review بیشتری ساخت، اقتصاد واقعی بهتر نشده است.

OpenAI در راهنمای production خود به usage tracking، notification threshold و برآورد هزینه بر اساس traffic، دفعات تعامل و مقدار داده اشاره می‌کند. این توصیه را می‌توان به یک قاعدهٔ داخلی تبدیل کرد: alert باید به مصرف غیرعادی و هزینهٔ هر task وصل باشد، نه فقط به صورتحساب پایان ماه.

سه عدد ممکن است از یکدیگر متفاوت باشند:

عدد سوم برای product decision معمولاً مهم‌تر است.

۴. رفتار کاربر و adoption: استفادهٔ بیشتر همیشه نشانهٔ ارزش بیشتر نیست. باید ببینیم کاربر چه می‌کند:

اگر adoption پایین است، سریع نگویید «کاربر AI نمی‌خواهد». شاید activation، جای feature، توضیح محدودیت یا کیفیت یک سناریوی خاص مشکل دارد. monitoring باید به کشف این فرض‌ها کمک کند، نه فقط به گزارش استفاده.

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

NIST در بخش Manage بر پایش پس از استقرار، جمع‌آوری feedback، مدیریت drift، برنامهٔ incident، recovery، تغییر و decommissioning تأکید دارد. این نگاه مهم است چون ریسک فقط هنگام release وجود ندارد؛ با تغییر جامعهٔ کاربر، داده، مدل و زمینهٔ استفاده دوباره شکل می‌گیرد.

• درصد taskهایی که به معیار محتوایی یا ساختاری می‌رسند؛
• نرخ citation درست، extraction معتبر یا schema قابل‌قبول؛
• نرخ اصلاح، regenerate یا override توسط انسان؛
• نرخ escalation و fallback؛
• خطاهای پرریسک به تفکیک severity؛
• نتیجهٔ نمونه‌برداری انسانی روی سناریوهای پرتکرار و مرزی.
• p50 و p95 latency، نه فقط میانگین؛
• timeout، error، retry و fallback؛
• شکست tool، retrieval، parsing یا schema؛
• نرخ پاسخ ناقص یا قطع‌شده؛
• صف، concurrency و محدودیت rate؛
• تغییرات version مدل، prompt، ابزار و dependency.
• هزینهٔ هر فراخوانی مدل؛
• هزینهٔ هر خروجی قابل‌قبول؛
• هزینهٔ کامل task با review، retry، fallback و پشتیبانی.
• چند درصد کاربران feature را امتحان می‌کنند و چند نفر برمی‌گردند؟
• خروجی را می‌پذیرند، ویرایش می‌کنند، کنار می‌گذارند یا گزارش می‌کنند؟
• کجا از feature خارج می‌شوند یا دوباره همان سؤال را می‌پرسند؟
• آیا زمان انجام task، تعداد handoff یا بار تیم تغییر کرده است؟
• آیا گروهی از کاربران به‌دلیل لحن، سرعت یا بی‌اعتمادی از آن استفاده نمی‌کنند؟
• نشت داده یا ورود دادهٔ ممنوع به context؛
• prompt injection، misuse یا رفتار خارج از دامنه؛
• action بدون مجوز یا عبور از human approval؛
• پاسخ گمراه‌کننده، تبعیض‌آمیز یا دارای citation نادرست؛
• شکایت، appeal، override و near-miss؛
• تغییر اثر feature روی گروه‌های مختلف کاربران.

baseline و threshold را پیش از alert بسازید

هشدار «کیفیت افت کرد» بدون baseline قابل اجرا نیست. یک baseline کوچک بسازید:

این عدد پیشنهادی عمومی یا قانون آماری نیست؛ نقطهٔ شروع است. با دادهٔ واقعی و ریسک use case آن را اصلاح کنید. threshold هم باید به action وصل شود:

برای گروه‌های مختلف، threshold کلی را پنهان نکنید. میانگین مناسب ممکن است افت شدید یک گروه کوچک یا یک سناریوی پرریسک را پوشش دهد.

• ۲۰ تا ۵۰ سناریوی ثابت از کارهای مهم؛
• چند failure case و edge case؛
• چند نمونهٔ تولیدشده با رضایت و مبنای مجاز برای پایش؛
• metric فنی و هزینه برای همان بازه؛
• چند نمونهٔ بررسی‌شده توسط انسان با توضیح، نه فقط برچسب.

نمونه‌برداری انسانی را طراحی کنید، نه اینکه به شانس بسپارید

بازبینی همهٔ خروجی‌ها برای بسیاری از تیم‌ها ممکن نیست و بازبینی هیچ‌کدام خطرناک است. یک روش میانه طراحی کنید:

AI می‌تواند خروجی‌ها را دسته‌بندی یا موارد مشکوک را برای review پیشنهاد کند، اما خودش نباید تنها قاضی کیفیت و safety باشد. نمونهٔ انسانی باید به‌گونه‌ای انتخاب شود که dashboard را اصلاح کند، نه اینکه فقط عدد خوبی بسازد.

• نمونه‌برداری تصادفی برای دیدن کیفیت عادی؛
• نمونه‌برداری هدفمند از خطا، شکایت، retry و خروجی خارج از دامنه؛
• بازبینی کامل برای سناریوهای پرریسک؛
• ثبت reason و severity، نه فقط good/bad؛
• بازگرداندن blind spotهای مهم به dataset eval و backlog.

observability بدون تبدیل‌شدن به نظارت بی‌هدف

برای پایش بهتر، وسوسهٔ ذخیرهٔ همه‌چیز وجود دارد. اما دادهٔ بیشتر لزوماً evidence بهتر نیست. log را با هدف مشخص، کمینه و قابل حذف نگه دارید. برای دادهٔ شخصی یا محرمانه، دسترسی نقش‌محور، retention روشن، masking و ناشناس‌سازی را در نظر بگیرید. اگر برای تشخیص یک timeout نیازی به متن کامل prompt نیست، آن را نگه ندارید.

در کنار log فنی، یک decision log کوچک داشته باشید: چه چیزی تغییر کرد، چه کسی approve کرد، کدام baseline استفاده شد و چرا threshold پذیرفته شد. این کار به تیم کمک می‌کند افت کیفیت را به مدل، prompt، داده، audience یا workflow نسبت دهد.

خبر امروز چه چیزی را تغییر می‌دهد؟

در ۱۴ سپتامبر ۲۰۲۶، مستندات رسمی OpenAI اعلام می‌کند Evals platform در حال deprecate شدن است و در ۳۰ نوامبر ۲۰۲۶ تعطیل می‌شود؛ همان راهنما برای شروع، Datasets را پیشنهاد می‌کند. نتیجهٔ عملی برای من این نیست که پایش را متوقف کنیم یا فوراً ابزار عوض کنیم. نتیجه این است که dataset، baseline، grader، alert و decision log باید قابل انتقال باشند و به یک dashboard یا vendor واحد وابسته نباشند.

اصل پایدار این است: بدانیم چه رفتاری را می‌سنجیم، داده از کجا آمده، تغییر نسبت به چه baselineای دیده شده و چه تصمیمی از آن نتیجه می‌شود. ابزارها عوض می‌شوند؛ این قرارداد evidence باید بماند.

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

AI می‌تواند logهای حجیم را خلاصه کند، الگوهای خطا را گروه‌بندی کند، نمونه‌های مشکوک را برای review بیرون بکشد، گزارش روزانه بسازد و بین تغییر model یا prompt و افت metric همبستگی پیشنهاد دهد. این‌ها عمدتاً augmentation هستند و زمان triage را کم می‌کنند.

اما اگر AI هم تولیدکنندهٔ خروجی باشد و هم تنها ارزیاب آن، خطر confirmation bias بالا می‌رود. ممکن است سیستم، خطاهای معنایی یا اثر ناخواسته روی یک گروه را با confidence بالا «عادی» اعلام کند. trade-off اصلی بین پوشش و هزینهٔ review است: automation بیشتر سرعت می‌دهد، اما باید با نمونهٔ انسانی، thresholdهای پرریسک، provenance و امکان توقف متوازن شود.

در Agile، پایش نباید به یک dashboard جدا از تیم تبدیل شود. metricهای اصلی را به acceptance criteria و definition of done وصل کنید؛ در review فقط تعداد request را نشان ندهید، نمونهٔ outcome و failure را هم ببینید؛ در retrospective، threshold شکسته را به backlog اصلاحی تبدیل کنید. در مدیریت پروژه، تغییر model، vendor، prompt یا داده را changeی بدانید که ممکن است cost، scope، latency و کیفیت را هم‌زمان جابه‌جا کند.

معیار موفقیت monitoring تعداد نمودارها نیست. باید بتوانیم زودتر بفهمیم چه چیزی تغییر کرده، شدت آن چقدر است، چه کسی تصمیم می‌گیرد و با چه evidenceای rollback یا ادامهٔ rollout را انتخاب می‌کنیم.

چک‌لیست عملی ده‌مرحله‌ای

• واحد پایش را تعریف کنید: request، task، action یا outcome.
• برای use case، سه failure مهم و چند edge case را ثبت کنید.
• baseline کوچک اما واقعی از کیفیت، latency و هزینه بسازید.
• metricها را در پنج لایهٔ کیفیت، فنی، اقتصاد، adoption و ریسک مرتب کنید.
• metric اصلی و چند guardrail را انتخاب کنید؛ داشبورد را با vanity metric پر نکنید.
• برای هر threshold owner و اقدام مشخص بنویسید.
• نمونه‌برداری تصادفی، هدفمند و پرریسک را جدا طراحی کنید.
• version مدل، prompt، ابزار، داده و policy را کنار event نگه دارید.
• fallback، kill switch، مسیر escalation و زمان بازبینی را آزمایش کنید.
• هر تغییر مهم و هر incident را به eval dataset و backlog برگردانید.

جمع‌بندی

واقعیت عمومی: راهنمای رسمی OpenAI برای production بر model monitoring، latency، usage و هزینه تأکید دارد. NIST در بخش Manage، پایش پس از استقرار، feedback، drift، incident، recovery، تغییر و decommissioning را مطرح می‌کند. مستندات رسمی OpenAI دربارهٔ انتقال Evals هم یادآوری می‌کند که ابزار ارزیابی ممکن است تغییر کند.

تحلیل من: بعد از launch، سؤال اصلی «مدل چند درصد درست است؟» نیست؛ «آیا این workflow برای کاربر، با ریسک و هزینهٔ قابل‌قبول، در طول زمان سالم می‌ماند؟» است. برای جواب، باید نمونهٔ واقعی، metric فنی، هزینهٔ کامل، رفتار کاربر و تصمیم انسانی را کنار هم قرار دهیم.

پیشنهاد حکیم: یک use case مهم انتخاب کنید و در یک صفحه واحد، outcome، failure، baseline، پنج لایه metric، threshold، owner و rollback را بنویسید. هفتهٔ اول با دادهٔ کم و review انسانی شروع کنید. وقتی الگوی خطا را شناختید، alert و automation را اضافه کنید. monitoring خوب سیستم را پر از نمودار نمی‌کند؛ فاصلهٔ میان تغییر، فهم و اقدام را کوتاه می‌کند.

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

راهنمای رسمی OpenAI برای انتقال پروژهٔ AI به production، model monitoring، latency، usage و مدیریت هزینه: https://developers.openai.com/api/docs/guides/production-best-practices/ — بررسی‌شده در 2026-09-14.

راهنمای رسمی OpenAI دربارهٔ eval، test input و وضعیت deprecate شدن Evals platform: https://developers.openai.com/api/docs/guides/evals.md — بررسی‌شده در 2026-09-14.

بخش رسمی NIST AI RMF Playbook دربارهٔ Manage، پایش پس از استقرار، feedback، drift، incident و decommissioning: https://airc.nist.gov/airmf-resources/playbook/manage/ — بررسی‌شده در 2026-09-14.

مرز شواهد و تحلیل

نام چارچوب‌ها، توصیه‌های فنی، تعریف model monitoring، اشاره به latency و هزینه، وضعیت Evals و پیشنهادهای NIST از منابع اولیهٔ رسمی بالا گرفته شده‌اند. چارچوب پنج‌لایهٔ metric، نمونه‌برداری، threshold، جدول اقدام و تفسیر اثر AI بر Agile و مدیریت پروژه تحلیل امین رضا سیدآبادی است. این متن جایگزین طراحی observability، بررسی حریم خصوصی یا ارزیابی ریسک اختصاصی یک محصول نیست.