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