ai-agents-for-beginners
عامل‌های هوش مصنوعی در تولید: قابلیت رصد و ارزیابی
با جابه‌جایی عامل‌های هوش مصنوعی از نمونه‌های آزمایشی به برنامه‌های واقعی، توانایی درک رفتار آنها، نظارت بر عملکردشان و ارزیابی سیستماتیک خروجی‌ها اهمیت می‌یابد.
اهداف یادگیری
پس از اتمام این درس، خواهید دانست چگونه/متوجه خواهید شد:
- مفاهیم اصلی قابلیت رصد و ارزیابی عامل‌ها
- تکنیک‌های بهبود عملکرد، هزینه‌ها و اثربخشی عامل‌ها
- چه چیزهایی و چگونه عامل‌های هوش مصنوعی خود را به طور سیستماتیک ارزیابی کنیم
- چگونه کنترل هزینه‌ها هنگام استقرار عامل‌های هوش مصنوعی در تولید
- چگونه عامل‌هایی که با Microsoft Agent Framework ساخته شده‌اند را ابزاربندی کنیم
هدف این است که شما را با دانش لازم برای تبدیل عامل‌های «جعبه سیاه» به سیستم‌های شفاف، قابل مدیریت و قابل اعتماد مجهز کنیم.
توجه: استقرار عامل‌های هوش مصنوعی ایمن و قابل اعتماد اهمیت دارد. درس ساخت عامل‌های هوش مصنوعی قابل اعتماد را نیز بررسی کنید.
ردیابی‌ها و بازه‌ها
ابزارهای قابلیت رصد مانند Langfuse یا Microsoft Foundry معمولاً اجراهای عامل را به صورت ردیابی‌ها و بازه‌ها نشان می‌دهند.
- ردیابی نمایانگر یک وظیفه کامل عامل از شروع تا پایان است (مانند پاسخ‌دهی به پرسش یک کاربر).
- بازه‌ها گام‌های فردی در داخل ردیابی هستند (مانند فراخوانی یک مدل زبانی یا بازیابی داده‌ها).
بدون قابلیت رصد، عامل هوش مصنوعی می‌تواند مانند یک «جعبه سیاه» به نظر برسد - حالت داخلی و استدلال آن تاریک است، به سختی می‌توان مشکلات را تشخیص داد یا عملکرد را بهینه کرد. با قابلیت رصد، عامل‌ها به «جعبه‌های شیشه‌ای» تبدیل می‌شوند که شفافیتی ارائه می‌دهند که برای ایجاد اعتماد و اطمینان از عملکرد درست حیاتی است.
اهمیت قابلیت رصد در محیط‌های تولید
انتقال عامل‌های هوش مصنوعی به محیط‌های تولید چالش‌ها و نیازهای جدیدی به همراه دارد. قابلیت رصد دیگر یک «ویژگی خوب» نیست بلکه یک توانایی حیاتی است:
- رفع اشکال و تحلیل علت ریشه‌ای: هنگامی که عامل دچار خطا می‌شود یا خروجی غیرمنتظره تولید می‌کند، ابزارهای قابلیت رصد ردیابی‌های لازم برای تعیین منبع خطا را فراهم می‌کنند. این موضوع به ویژه در عامل‌های پیچیده که ممکن است شامل چندین فراخوانی مدل زبانی، تعامل با ابزارها و منطق شرطی باشد، مهم است.
- مدیریت تأخیر و هزینه: عامل‌های هوش مصنوعی اغلب به مدل‌های زبانی بزرگ و APIهای خارجی که به ازای هر توکن یا فراخوانی هزینه دریافت می‌کنند وابسته‌اند. قابلیت رصد اجازه می‌دهد تا این فراخوانی‌ها دقیقاً ردیابی و عملیات کند یا پرهزینه شناسایی شوند. این به تیم‌ها کمک می‌کند پرامپت‌ها را بهینه کنند، مدل‌های کارامدتر انتخاب کنند یا گردش‌های کاری را بازطراحی کنند تا هزینه‌های عملیاتی کنترل شود و تجربه کاربری خوبی فراهم گردد.
- اعتماد، ایمنی و تطابق: در بسیاری از کاربردها ضروری است که اطمینان حاصل شود عامل‌ها به طور ایمن و اخلاقی رفتار می‌کنند. قابلیت رصد یک مسیر حسابرسی از اقدامات و تصمیمات عامل فراهم می‌کند. این قابلیت می‌تواند برای شناسایی و کاهش مشکلاتی مانند تزریق پرامپت، تولید محتوای مضر یا مدیریت نادرست اطلاعات شخصی (PII) استفاده شود. برای مثال، می‌توانید ردیابی‌ها را مرور کنید تا درک کنید چرا عامل پاسخ خاصی داده یا از ابزار مشخصی استفاده کرده است.
- حلقه‌های بهبود مستمر: داده‌های قابلیت رصد پایه فرایند توسعه تکراری هستند. با نظارت بر عملکرد عامل در دنیای واقعی، تیم‌ها می‌توانند مناطق نیازمند بهبود را شناسایی کنند، داده‌هایی برای تنظیم دقیق مدل‌ها جمع‌آوری کرده و تأثیر تغییرات را اعتبارسنجی کنند. این یک حلقه بازخورد ایجاد می‌کند که بینش‌های تولید از ارزیابی آنلاین، آزمایش‌ها و اصلاحات آفلاین را اطلاع‌رسانی می‌کند و منجر به عملکرد بهتر عامل به تدریج می‌شود.
معیارهای کلیدی برای پیگیری
برای نظارت و درک رفتار عامل، باید مجموعه‌ای از معیارها و سیگنال‌ها ردیابی شوند. در حالی که معیارهای خاص بسته به هدف عامل متفاوت است، برخی معیارها به طور جهانی اهمیت دارند.
در اینجا برخی از رایج‌ترین معیارهایی که ابزارهای قابلیت رصد پایش می‌کنند، آورده شده است:
تاخیر: عامل چقدر سریع پاسخ می‌دهد؟ زمان انتظار طولانی تجربه کاربر را منفی می‌کند. شما باید تاخیر را برای وظایف و مراحل فردی با ردیابی اجرای عامل اندازه بگیرید. برای مثال، عاملی که برای همه فراخوانی‌های مدل ۲۰ ثانیه صرف می‌کند، می‌تواند با استفاده از مدل سریع‌تر یا اجرای موازی فراخوانی‌های مدل سریع‌تر شود.
هزینه‌ها: هزینه هر اجرای عامل چقدر است؟ عامل‌های هوش مصنوعی وابسته به فراخوانی مدل‌های زبانی بزرگ هستند که به ازای هر توکن یا API های خارجی هزینه دریافت می‌کنند. استفاده مکرر از ابزارها یا پرامپت‌های متعدد می‌تواند هزینه‌ها را به سرعت افزایش دهد. به عنوان مثال، اگر عاملی برای بهبود کیفیت جزئی پنج بار فراخوانی LLM داشته باشد، باید ارزیابی کنید آیا هزینه توجیه‌پذیر است یا می‌توانید تعداد فراخوانی‌ها را کاهش دهید یا از مدل ارزان‌تری استفاده کنید. نظارت بلادرنگ همچنین می‌تواند افزایش ناگهانی غیرمنتظره (مثلاً اشکالاتی که باعث حلقه‌های بیش از حد API می‌شوند) را شناسایی کند.
خطاهای درخواست: چند درخواست توسط عامل شکست خورد؟ این می‌تواند شامل خطاهای API یا شکست فراخوانی ابزارها باشد. برای قوی‌تر کردن عامل خود در برابر این موارد در محیط تولید، می‌توانید راهکارهای جایگزین یا تلاش مجدد تنظیم کنید. مثلا اگر ارائه‌دهنده LLM A خراب است، به عنوان پشتیبان به ارائه‌دهنده LLM B تغییر دهید.
بازخورد کاربر: اجرای ارزیابی‌های مستقیم کاربر دیدگاه‌های ارزشمندی فراهم می‌کند. این می‌تواند شامل رتبه‌بندی‌های صریح (👍موافق/👎مخالف، ⭐1-5 ستاره) یا نظرات متنی باشد. بازخورد منفی مداوم باید هشدار دهد که عامل مطابق انتظار عمل نمی‌کند.
بازخورد ضمنی کاربر: رفتارهای کاربران بازخورد غیرمستقیم بدون رتبه‌بندی صریح ارائه می‌دهند. این می‌تواند شامل اصلاح فوری سوال، سوالات مکرر یا کلیک روی دکمه تلاش مجدد باشد. مثلاً اگر ببینید کاربران بارها سوال یکسانی می‌پرسند، این نشانه‌ای است که عامل مطابق انتظار کار نمی‌کند.
دقت: چند بار عامل خروجی‌های درست یا مطلوب تولید می‌کند؟ تعاریف دقت متفاوت است (مثلاً صحت حل مسئله، دقت بازیابی اطلاعات، رضایت کاربر). اولین گام تعریف موفقیت برای عامل شماست. می‌توانید دقت را از طریق بررسی‌های خودکار، امتیازهای ارزیابی یا برچسب‌های تکمیل وظیفه پیگیری کنید. مثلا ردیابی‌ها را به عنوان “موفق” یا “ناموفق” علامت‌گذاری کنید.
معیارهای ارزیابی خودکار: می‌توانید ارزیابی خودکار راه‌اندازی کنید. برای مثال، می‌توانید از یک مدل زبانی بزرگ برای ارزیابی خروجی عامل استفاده کنید مثل اینکه مفید، دقیق یا نامناسب بودن آن را امتیازدهی کنید. همچنین چند کتابخانه متن‌باز وجود دارد که به شما کمک می‌کند جنبه‌های مختلف عامل را امتیازدهی کنید، مانند RAGAS برای عامل‌های RAG یا LLM Guard برای شناسایی زبان مضر یا تزریق پرامپت.
در عمل، ترکیبی از این معیارها بهترین پوشش سلامت عامل هوش مصنوعی را فراهم می‌کند. در دفترچه یادداشت مثال این فصل، به شما نشان می‌دهیم که این معیارها در مثال‌های واقعی چگونه هستند اما ابتدا یاد می‌گیریم که گردش کار ارزیابی معمولی چگونه است.
ابزاربندی عامل خود
برای جمع‌آوری داده‌های ردیابی، باید کد خود را ابزاربندی کنید. هدف این است که کد عامل را ابزاربندی کنید تا ردیابی‌ها و معیارهایی تولید کند که توسط پلتفرم قابلیت رصد ضبط، پردازش و نمایه‌سازی شود.
OpenTelemetry (OTel): OpenTelemetry به عنوان استاندارد صنعتی برای قابلیت رصد مدل‌های زبانی بزرگ معرفی شده است. این مجموعه‌ای از APIها، SDKها و ابزارها برای تولید، جمع‌آوری و صادر کردن داده‌های تله‌متری فراهم می‌کند.
بسیاری از کتابخانه‌های ابزاربندی وجود دارد که فریم‌ورک‌های عامل موجود را پوشش می‌دهند و صادرات بازه‌های OpenTelemetry به ابزار رصد را آسان می‌کنند. Microsoft Agent Framework به طور بومی با OpenTelemetry ادغام شده است. در زیر نمونه‌ای از ابزاربندی عامل MAF آمده است:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# Agent execution is traced automatically
pass
در دفترچه یادداشت مثال این فصل نحوه ابزاربندی عامل MAF شما نشان داده خواهد شد.
ایجاد بازه دستی: در حالی که کتابخانه‌های ابزاربندی پایه‌ای خوب فراهم می‌کنند، اغلب نیاز به اطلاعات دقیق‌تر یا سفارشی وجود دارد. می‌توانید به صورت دستی بازه ایجاد کنید تا منطق سفارشی برنامه را اضافه کنید. مهم‌تر اینکه، می‌توانید بازه‌های ایجاد شده خودکار یا دستی را با ویژگی‌های سفارشی (که به عنوان برچسب یا متادیتا نیز شناخته می‌شود) غنی کنید. این ویژگی‌ها می‌توانند داده‌های خاص کسب‌وکار، محاسبات میانی یا هر زمینه‌ای که برای عیب‌یابی یا تحلیل مفید است را شامل شوند، مانند user_id، session_id، یا model_version.
نمونه‌ای از ایجاد دستی ردیابی‌ها و بازه‌ها با Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
ارزیابی عامل
قابلیت رصد به ما معیارها را می‌دهد، اما ارزیابی فرآیند تحلیل آن داده‌ها (و انجام آزمایش‌ها) برای تعیین عملکرد عامل هوش مصنوعی و چگونگی بهبود آن است. به عبارت دیگر، وقتی آن ردیابی‌ها و معیارها را دارید، چگونه از آنها برای قضاوت درباره عامل و اتخاذ تصمیم استفاده می‌کنید؟
ارزیابی منظم اهمیت دارد زیرا عامل‌های هوش مصنوعی اغلب غیر قطعی هستند و می‌توانند تکامل یابند (از طریق به‌روزرسانی‌ها یا رفتار مدل تغییر یافته) – بدون ارزیابی، نمی‌دانید که «عامل هوشمند» شما واقعاً کارش را خوب انجام می‌دهد یا برگشته است.
دو دسته ارزیابی برای عامل‌های هوش مصنوعی وجود دارد: ارزیابی آنلاین و ارزیابی آفلاین. هر دو ارزشمند هستند و مکمل یکدیگرند. معمولاً با ارزیابی آفلاین شروع می‌کنیم، چون حداقل گام لازم پیش از استقرار هر عاملی است.
ارزیابی آفلاین
این شامل ارزیابی عامل در محیطی کنترل‌شده است، معمولاً با استفاده از مجموعه داده‌های آزمایشی، نه پرسش‌های زنده کاربران. شما از مجموعه داده‌های منتخب استفاده می‌کنید که می‌دانید خروجی مورد انتظار یا رفتار صحیح چیست و سپس عامل خود را روی آنها اجرا می‌کنید.
برای مثال، اگر عاملی برای حل مسئله‌های کلامی ریاضی ساخته‌اید، ممکن است یک مجموعه داده آزمایشی شامل ۱۰۰ مسئله با پاسخ‌های شناخته شده داشته باشید. ارزیابی آفلاین اغلب در طول توسعه انجام می‌شود (و می‌تواند بخشی از خطوط CI/CD باشد) تا بهبودها بررسی شود یا از regresion جلوگیری گردد. مزیت این است که تکرارپذیر است و معیارهای دقت واضح چون حقیقت زمینه دارید. ممکن است شبیه‌سازی پرسش‌های کاربران انجام دهید و پاسخ‌های عامل را با جواب‌های ایده‌آل بسنجید یا از معیارهای خودکار که پیش‌تر شرح داده شد، استفاده کنید.
چالش اصلی در ارزیابی آفلاین، اطمینان از جامع و مرتبط بودن مجموعه داده‌های آزمایشی است – ممکن است عامل در مجموعه ثابتی عملکرد خوبی داشته باشد اما در تولید با پرسش‌های بسیار متفاوت مواجه شود. بنابراین باید مجموعه‌های آزمایشی را با موارد حاشیه‌ای جدید و مثال‌هایی که سناریوهای دنیای واقعی را منعکس می‌کنند بروزرسانی کنید. ترکیبی از موارد کوچک «تست دود» و مجموعه‌های ارزیابی بزرگ‌تر مفید است: مجموعه‌های کوچک برای بررسی‌های سریع و مجموعه‌های بزرگ‌تر برای معیارهای گسترده عملکرد.
ارزیابی آنلاین
منظور ارزیابی عامل در محیطی زنده و واقعی است، یعنی در حین استفاده واقعی در تولید. ارزیابی آنلاین شامل نظارت بر عملکرد عامل در تعاملات واقعی کاربران و تجزیه و تحلیل مداوم نتایج است.
برای مثال، ممکن است نرخ موفقیت، امتیازهای رضایت کاربر یا معیارهای دیگر را در ترافیک زنده پیگیری کنید. مزیت ارزیابی آنلاین این است که چیزهایی را ثبت می‌کند که ممکن است در محیط آزمایشگاهی پیش‌بینی نشده باشد – می‌توانید انحراف مدل را در طول زمان مشاهده کنید (اگر اثربخشی عامل با تغییر الگوهای ورودی کاهش یابد) و پرسش‌ها یا موقعیت‌های غیرمنتظره‌ای که در داده‌های آزمایشی نبوده‌اند را شناسایی کنید. این تصویر واقعی از رفتار عامل در محیط واقعی را فراهم می‌آورد.
ارزیابی آنلاین معمولاً شامل جمع‌آوری بازخورد ضمنی و صریح کاربران است، همانطور که بحث شد، و ممکن است تست‌های سایه یا تست‌های A/B (که نسخه جدید عامل به موازات نسخه قدیمی اجرا می‌شود برای مقایسه) را هم اجرا کند. چالش این است که دریافت برچسب‌ها یا امتیازهای قابل اطمینان برای تعاملات زنده می‌تواند دشوار باشد – ممکن است به بازخورد کاربران یا معیارهای پایین‌دستی (مثلاً آیا کاربر روی نتیجه کلیک کرده است) تکیه کنید.
ترکیب هر دو
ارزیابی‌های آنلاین و آفلاین متقابل نیستند؛ بلکه به شدت مکمل یکدیگرند. دیدگاه‌های حاصل از نظارت آنلاین (مثل نوع جدید پرسش‌های کاربران که عامل بد عمل می‌کند) می‌تواند برای افزایش و بهبود مجموعه داده‌های آزمایشی آفلاین استفاده شود. برعکس، عامل‌هایی که در تست‌های آفلاین عملکرد خوبی دارند را می‌توان با اطمینان بیشتر مستقر کرده و آنلاین نظارت کرد.
در واقع، بسیاری از تیم‌ها یک چرخه را اتخاذ می‌کنند:
ارزیابی آفلاین -> استقرار -> نظارت آنلاین -> جمع‌آوری موارد شکست جدید -> افزودن به مجموعه داده آفلاین -> اصلاح عامل -> تکرار.
مسائل رایج
در هنگام استقرار عامل‌های هوش مصنوعی در تولید ممکن است با چالش‌های متعدد مواجه شوید. در اینجا برخی از مسائل رایج و راه‌حل‌های احتمالی آنها آورده شده است:
| مسئله | راه حل احتمالی |
|---|---|
| عامل هوش مصنوعی به طور مداوم وظایف را به درستی انجام نمی‌دهد | - پرامپت ارائه‌شده به عامل را دقیق کنید؛ اهداف را واضح بیان کنید. - تشخیص دهید که تقسیم وظایف به زیروظایف و سپردن به چند عامل چگونه کمک می‌کند. |
| عامل در حلقه‌های تکراری گیر می‌کند | - اطمینان حاصل کنید شرایط و قوانین خاتمه واضح هستند تا عامل بداند چه زمانی فرآیند متوقف شود. - برای وظایف پیچیده که نیاز به استدلال و برنامه‌ریزی دارند، از مدل بزرگ‌تری که برای وظایف استدلال تخصصی است، استفاده کنید. |
| فراخوانی‌های ابزار عامل به خوبی عمل نمی‌کنند | - خروجی ابزار را خارج از سیستم عامل تست و تایید کنید. - پارامترها، پرامپت‌ها و نام‌گذاری ابزارها را اصلاح کنید. |
| سیستم چندعاملی به طور مداوم عمل نمی‌کند | - پرامپت‌های داده شده به هر عامل را دقیق و متمایز از یکدیگر اصلاح کنید. - یک سیستم سلسله‌مراتبی با استفاده از یک عامل «مسیریاب» یا کنترل‌کننده بسازید تا مشخص کند کدام عامل درست است. |
بسیاری از این مسائل را می‌توان با داشتن قابلیت رصد به شکل موثرتری شناسایی کرد. ردیابی‌ها و معیارهایی که پیش‌تر بحث کردیم به دقت محل بروز مشکلات در گردش کار عامل را نشان می‌دهند و اشکال‌زدایی و بهینه‌سازی را بسیار کارآمد می‌سازند.
مدیریت هزینه‌ها
در اینجا برخی استراتژی‌ها برای مدیریت هزینه‌های استقرار عامل‌های هوش مصنوعی در تولید آورده شده است:
استفاده از مدل‌های کوچکتر: مدل‌های زبان کوچک (SLMs) می‌توانند در برخی از موارد کاربردی عاملی عملکرد خوبی داشته باشند و هزینه‌ها را به‌طور قابل‌توجهی کاهش دهند. همانطور که قبلاً ذکر شد، ساخت یک سیستم ارزیابی برای تعیین و مقایسه عملکرد در مقابل مدل‌های بزرگ‌تر بهترین راه برای فهمیدن میزان موفقیت SLM در مورد استفاده شما است. در نظر بگیرید از SLMها برای وظایف ساده‌تری مانند طبقه‌بندی نیت یا استخراج پارامتر استفاده کنید، در حالی که مدل‌های بزرگ‌تر را برای استدلال پیچیده‌تر نگه دارید.
استفاده از مدل مسیریاب: استراتژی مشابه این است که از تنوع مدل‌ها و اندازه‌ها استفاده شود. می‌توانید از یک LLM/SLM یا تابع بدون سرور برای مسیریابی درخواست‌ها بر اساس پیچیدگی به مدل‌های مناسب‌تر استفاده کنید. این همچنین به کاهش هزینه‌ها کمک کرده و اطمینان حاصل می‌کند که عملکرد در وظایف مناسب حفظ شود. به‌عنوان مثال، پرسش‌های ساده را به مدل‌های کوچکتر و سریع‌تر راهنمایی کنید و فقط برای وظایف استدلال پیچیده از مدل‌های بزرگ و گران‌قیمت استفاده کنید.
کش کردن پاسخ‌ها: شناسایی درخواست‌ها و وظایف رایج و ارائه پاسخ‌ها قبل از اینکه از سیستم عاملی شما عبور کنند، راه خوبی برای کاهش حجم درخواست‌های مشابه است. حتی می‌توانید جریانی را پیاده‌سازی کنید تا میزان شباهت یک درخواست به درخواست‌های کش شده را با استفاده از مدل‌های هوش مصنوعی ساده‌تر تشخیص دهد. این استراتژی می‌تواند هزینه‌ها را به طور قابل‌توجهی برای سوالات پرتکرار یا فرآیندهای رایج کاهش دهد.
بیایید ببینیم این در عمل چگونه کار می‌کند
در دفترچه مثال این بخش، نمونه‌هایی را خواهیم دید از اینکه چگونه می‌توانیم از ابزارهای قابل مشاهده‌بودن برای نظارت و ارزیابی عامل خود استفاده کنیم.
سوالات بیشتری درباره‌ی عوامل هوش مصنوعی در تولید دارید؟
به دیسکورد Microsoft Foundry بپیوندید تا با دیگر یادگیرندگان ملاقات کنید، در ساعت‌های اداری شرکت کنید و سوالات خود درباره عوامل هوش مصنوعی را پاسخ بگیرید.
درس قبلی
درس بعدی
سلب مسئولیت: این سند با استفاده از سرویس ترجمه هوش مصنوعی Co-op Translator ترجمه شده است. در حالی که ما در تلاش برای دقت هستیم، لطفاً توجه داشته باشید که ترجمه‌های خودکار ممکن است شامل خطاها یا نادرستی‌هایی باشند. سند اصلی به زبان مادری خود باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حیاتی، ترجمه حرفه‌ای انسانی توصیه می‌شود. ما در قبال هرگونه سوء تفاهم یا برداشت نادرست ناشی از استفاده از این ترجمه مسئولیتی نداریم.