ai-agents-for-beginners
عاملهای هوش مصنوعی در تولید: قابلیت مشاهده و ارزیابی
با حرکت عاملهای هوش مصنوعی از نمونههای آزمایشی به برنامههای دنیای واقعی، توانایی درک رفتار آنها، پایش عملکردشان و ارزیابی سیستماتیک خروجیهایشان اهمیت مییابد.
اهداف یادگیری
پس از تکمیل این درس، شما خواهید دانست یا میفهمید:
- مفاهیم اصلی قابلیت مشاهده و ارزیابی عاملها
- تکنیکهایی برای بهبود عملکرد، هزینهها و اثربخشی عاملها
- چه چیزهایی را و چگونه بهصورت سیستماتیک عاملهای هوش مصنوعی خود را ارزیابی کنید
- چگونه هنگام استقرار عاملها در تولید هزینهها را کنترل کنید
- چگونه عاملهای ساختهشده با Microsoft Agent Framework را ابزارسنجی کنید
هدف این است که شما را مجهز به دانش لازم کنیم تا عاملهای «جعبه سیاه» خود را به سیستمهایی شفاف، قابل مدیریت و قابل اعتماد تبدیل کنید.
Note: It is important to deploy AI Agents that are safe and trustworthy. Check out the ساخت عاملهای هوش مصنوعی قابل اعتماد lesson as well.
ردیابیها و اسپنها
ابزارهای قابلیت مشاهده مانند Langfuse یا Microsoft Foundry معمولاً اجرای عامل را بهصورت ردیابیها و اسپنها نمایش میدهند.
- Trace نمایانگر یک وظیفه کامل عامل از آغاز تا پایان است (مانند پاسخ به یک پرسش کاربر).
- Spans گامهای مجزایی در داخل یک ردیابی هستند (مانند فراخوانی یک مدل زبانی یا واکشی داده).
بدون قابلیت مشاهده، یک عامل هوش مصنوعی میتواند مانند یک “جعبه سیاه” به نظر برسد — وضعیت داخلی و استدلالهای آن شفاف نیستند و این باعث میشود تشخیص مشکلات یا بهینهسازی عملکرد دشوار شود. با قابلیت مشاهده، عاملها به “جعبههای شیشهای” تبدیل میشوند و شفافیتی ارائه میدهند که برای ساخت اعتماد و اطمینان از کارکرد مطابق انتظار ضروری است.
چرا قابلیت مشاهده در محیطهای تولید مهم است
انتقال عاملهای هوش مصنوعی به محیطهای تولید مجموعهای جدید از چالشها و الزامات را به همراه دارد. قابلیت مشاهده دیگر یک “خوب است که داشته باشید” نیست، بلکه یک قابلیت حیاتی است:
- اشکالزدایی و تحلیل علت ریشهای: وقتی یک عامل شکست میخورد یا خروجی غیرمنتظرهای تولید میکند، ابزارهای قابلیت مشاهده ردیابیهای لازم را برای تعیین منبع خطا فراهم میکنند. این موضوع بهویژه در عاملهای پیچیده که ممکن است شامل چندین فراخوانی LLM، تعامل با ابزارها و منطق شرطی باشند، اهمیت دارد.
- مدیریت تأخیر و هزینه: عاملهای هوش مصنوعی اغلب به LLMها و سایر APIهای خارجی وابستهاند که بر اساس توکن یا فراخوانی هزینهگذاری میشوند. قابلیت مشاهده امکان ردیابی دقیق این فراخوانیها را فراهم میکند و به شناسایی عملیاتهای بسیار کند یا پرهزینه کمک میکند. این موضوع به تیمها اجازه میدهد تا پرامپتها را بهینه کنند، مدلهای کارآمدتری انتخاب کنند یا جریانهای کاری را بازطراحی کنند تا هزینههای عملیاتی را مدیریت کرده و تجربه کاربری خوبی تضمین شود.
- اعتماد، ایمنی و انطباق: در بسیاری از برنامهها، مهم است که عاملها بهصورت ایمن و اخلاقی رفتار کنند. قابلیت مشاهده مسیر حسابرسی از اعمال و تصمیمات عامل را فراهم میکند. این میتواند برای شناسایی و کاهش مواردی مانند prompt injection، تولید محتوای مضر یا سوءمدیریت اطلاعات شناساییشوندهٔ شخصی (PII) استفاده شود. برای مثال، میتوانید ردیابیها را مرور کنید تا بفهمید چرا یک عامل پاسخ خاصی داده یا از ابزار مشخصی استفاده کرده است.
- حلقههای بهبود مستمر: دادههای قابلیت مشاهده پایهای برای یک فرآیند توسعه تکرارشونده هستند. با پایش عملکرد عاملها در دنیای واقعی، تیمها میتوانند حوزههای بهبود را شناسایی کنند، دادههایی برای فاینتیون مدلها جمعآوری کنند و تأثیر تغییرات را اعتبارسنجی کنند. این یک حلقه بازخورد ایجاد میکند که در آن بینشهای تولیدی از ارزیابی آنلاین به آزمایشها و پالایشهای آفلاین اطلاع میدهد و منجر به بهبود پیوسته عملکرد عامل میشود.
شاخصهای کلیدی برای رصد
برای پایش و درک رفتار عامل، باید مجموعهای از شاخصها و سیگنالها رصد شوند. در حالی که شاخصهای خاص ممکن است بر اساس هدف عامل متفاوت باشند، برخی شاخصها بهطور جهانی مهم هستند.
در ادامه برخی از رایجترین شاخصهایی که ابزارهای قابلیت مشاهده رصد میکنند آمده است:
Latency: عامل با چه سرعتی پاسخ میدهد؟ زمانهای انتظار طولانی تجربه کاربری را تحت تأثیر منفی قرار میدهد. باید تأخیر برای وظایف و گامهای فردی را با ردیابی اجرای عامل اندازهگیری کنید. برای مثال، عاملی که برای تمام فراخوانیهای مدل 20 ثانیه زمان میبرد میتواند با استفاده از مدلی سریعتر یا اجرای فراخوانیهای مدل بهصورت موازی تسریع شود.
Costs: هزینه هر اجرای عامل چقدر است؟ عاملهای هوش مصنوعی به فراخوانیهای LLM که بر اساس توکن هزینهگذاری میشوند یا به APIهای خارجی وابستهاند. استفاده مکرر از ابزارها یا ارسال پرامپتهای متعدد میتواند بهسرعت هزینهها را افزایش دهد. برای مثال، اگر عاملی برای بهبود کیفیت جزئی پنج بار یک LLM را فراخوانی کند، باید ارزیابی کنید که آیا هزینه توجیهپذیر است یا میتوانید تعداد فراخوانیها را کاهش دهید یا از مدل ارزانتری استفاده کنید. پایش زمان واقعی نیز میتواند به شناسایی اوجهای غیرمنتظره (مثلاً باگهایی که باعث حلقههای مکرر API میشوند) کمک کند.
Request Errors: چند درخواست توسط عامل ناموفق بوده است؟ این میتواند شامل خطاهای API یا فراخوانی ابزارهای ناموفق باشد. برای مقاومتر کردن عامل در برابر این موارد در تولید، میتوانید راهحلهای پشتیبان یا تلاش مجدد (retries) تنظیم کنید. مثلاً اگر ارائهدهنده LLM A از کار افتاد، بهعنوان پشتیبان به ارائهدهنده LLM B سوئیچ کنید.
User Feedback: پیادهسازی ارزیابیهای مستقیم کاربران بینشهای ارزشمندی فراهم میکند. این میتواند شامل امتیازدهی صریح (👍رضایت/👎نارضایتی، ⭐1-5 ستاره) یا نظرات متنی باشد. بازخورد منفی مداوم باید شما را هشدار دهد زیرا نشانهای است که عامل طبق انتظار عمل نمیکند.
Implicit User Feedback: رفتار کاربران بازخورد غیرمستقیم را حتی بدون امتیازدهی صریح فراهم میکند. این میتواند شامل بازفرمولبندی سریع سؤال، پرسشهای تکراری یا کلیک روی دکمه تلاش مجدد باشد. مثلاً اگر ببینید کاربران مرتباً همان سؤال را میپرسند، این نشانهای است که عامل طبق انتظار عمل نمیکند.
Accuracy: چند وقت یکبار عامل خروجیهای صحیح یا مطلوب تولید میکند؟ تعریف دقت میتواند متفاوت باشد (مثلاً درستی حل مسئله، دقت بازیابی اطلاعات، رضایت کاربر). اولین گام تعریف این است که موفقیت برای عامل شما چگونه به نظر میرسد. میتوانید دقت را از طریق بررسیهای خودکار، امتیازهای ارزیابی یا برچسبهای تکمیل وظیفه رصد کنید. برای مثال، نشانگذاری ردیابیها بهعنوان “موفق” یا “ناموفق”.
Automated Evaluation Metrics: میتوانید ارزیابیهای خودکار را نیز تنظیم کنید. بهعنوان مثال، میتوانید از یک LLM برای امتیازدهی خروجی عامل استفاده کنید، مثلاً اینکه آیا مفید، دقیق یا خیر است. همچنین چندین کتابخانه متنباز وجود دارند که به شما کمک میکنند جنبههای مختلف عامل را امتیازدهی کنید. مثلاً RAGAS برای عاملهای RAG یا LLM Guard برای شناسایی زبان مضر یا prompt injection.
در عمل، ترکیبی از این شاخصها پوشش بهتری از سلامت عامل هوش مصنوعی فراهم میکند. در دفترچهٔ نمونه این فصل، نشان خواهیم داد که این شاخصها در مثالهای واقعی چگونه به نظر میرسند، اما ابتدا بیایید ببینیم یک جریان کاری ارزیابی معمولی چگونه است.
ابزارسنجی عامل خود
برای جمعآوری دادههای ردیابی، باید کد خود را ابزارسنجی کنید. هدف این است که کد عامل را طوری ابزارسنجی کنید که ردیابیها و شاخصهایی را صادر کند که یک پلتفرم قابلیت مشاهده بتواند آنها را ضبط، پردازش و مصورسازی کند.
OpenTelemetry (OTel): OpenTelemetry بهعنوان یک استاندارد صنعتی برای قابلیت مشاهده LLM مطرح شده است. این مجموعهای از 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"):
# اجرای عامل بهطور خودکار ردیابی میشود
pass
دفترچهٔ نمونه در این فصل (example notebook) نشان میدهد چگونه عامل 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()
ارزیابی عامل
قابلیت مشاهده به ما شاخصها را میدهد، اما ارزیابی فرآیند تحلیل آن دادهها (و انجام تستها) برای تعیین نحوهٔ عملکرد عامل هوش مصنوعی و چگونگی بهبود آن است. به عبارت دیگر، وقتی آن ردیابیها و شاخصها را دارید، چگونه از آنها برای قضاوت درباره عامل و تصمیمگیری استفاده میکنید؟
ارزیابی منظم مهم است زیرا عاملهای هوش مصنوعی اغلب غیرقطعی هستند و میتوانند تکامل پیدا کنند (از طریق بهروزرسانیها یا تغییر رفتار مدل) — بدون ارزیابی، متوجه نخواهید شد که آیا «عامل هوشمند» شما واقعاً کار خود را به درستی انجام میدهد یا اینکه دچار پسرفت شده است.
دو دسته ارزیابی برای عاملهای هوش مصنوعی وجود دارد: ارزیابی آنلاین و ارزیابی آفلاین. هر دو ارزشمند هستند و یکدیگر را تکمیل میکنند. معمولاً از ارزیابی آفلاین شروع میکنیم، زیرا این حداقل گام لازم قبل از استقرار هر عاملی است.
ارزیابی آفلاین
این شامل ارزیابی عامل در یک محیط کنترلشده است، معمولاً با استفاده از مجموعهدادههای آزمایشی، نه پرسشهای زندهٔ کاربران. شما از مجموعههای دادهٔ گزینشی استفاده میکنید که میدانید خروجی مورد انتظار یا رفتار صحیح چیست و سپس عامل خود را روی آنها اجرا میکنید.
برای مثال، اگر یک عامل حل مسئلهٔ متنی ریاضی ساختهاید، ممکن است یک مجموعهدادهٔ آزمون شامل 100 مسئله با پاسخهای شناختهشده داشته باشید. ارزیابی آفلاین اغلب در طول توسعه انجام میشود (و میتواند بخشی از خطوط CI/CD باشد) تا بهبودها را بررسی کند یا از پسرفتها جلوگیری کند. مزیت آن این است که قابل تکرار است و میتوانید شاخصهای دقت واضحی بهدست آورید چون حقیقت مبنای دارید. شما همچنین ممکن است پرسشهای کاربران را شبیهسازی کرده و پاسخهای عامل را در برابر پاسخهای ایدهآل اندازهگیری کنید یا از شاخصهای خودکار همانطور که در بالا توضیح داده شد استفاده کنید.
چالش کلیدی در ارزیابی آفلاین این است که اطمینان حاصل کنید مجموعهدادهٔ آزمایشی شما جامع و مرتبط باقی میماند — ممکن است عامل در یک مجموعهٔ آزمایشی ثابت عملکرد خوبی داشته باشد اما در تولید با پرسشهای بسیار متفاوتی مواجه شود. بنابراین باید مجموعههای آزمایشی را با موارد لبهای جدید و مثالهایی که منعکسکنندهٔ سناریوهای دنیای واقعی هستند، بهروز نگه دارید. ترکیبی از موارد کوچک “آزمون سریع (smoke test)” و مجموعههای ارزیابی بزرگتر مفید است: مجموعههای کوچک برای بررسیهای سریع و مجموعههای بزرگتر برای شاخصهای عملکرد گستردهتر.
ارزیابی آنلاین
این به ارزیابی عامل در یک محیط زنده و دنیای واقعی اشاره دارد، یعنی در طول استفادهٔ واقعی در تولید. ارزیابی آنلاین شامل پایش عملکرد عامل در تعاملات واقعی کاربران و تحلیل مداوم نتایج است.
برای مثال، ممکن است نرخهای موفقیت، امتیازهای رضایت کاربران یا سایر شاخصها را در ترافیک زنده رصد کنید. مزیت ارزیابی آنلاین این است که مواردی را ثبت میکند که ممکن است در محیط آزمایشگاهی پیشبینی نکنید — میتوانید انحراف مدل را در طول زمان مشاهده کنید (اگر اثربخشی عامل با تغییر الگوهای ورودی کاهش یابد) و پرسشها یا وضعیتهای غیرمنتظرهای را که در دادههای آزمون شما نبودهاند، شناسایی کنید. این یک تصویر واقعی از نحوه رفتار عامل در محیط واقعی ارائه میدهد.
ارزیابی آنلاین اغلب شامل جمعآوری بازخوردهای ضمنی و صریح کاربران است، همانطور که قبلاً بحث شد، و ممکن است اجرای تستهای سایه یا A/B (جایی که نسخهٔ جدید عامل بهصورت موازی اجرا میشود تا با نسخهٔ قدیمی مقایسه شود) را نیز در بر بگیرد. چالش این است که ممکن است گرفتن برچسبها یا امتیازهای قابلاعتماد برای تعاملات زنده دشوار باشد — ممکن است به بازخورد کاربران یا شاخصهای پاییندستی (مانند اینکه آیا کاربر روی نتیجه کلیک کرده است) متکی باشید.
ترکیب این دو
ارزیابیهای آنلاین و آفلاین یکدیگر را نفی نمیکنند؛ آنها بهشدت مکمل یکدیگر هستند. بینشهای حاصل از پایش آنلاین (مثلاً نوع جدیدی از پرسشهای کاربران که عامل در آنها ضعیف عمل میکند) را میتوان برای افزایش و بهبود مجموعهدادههای آزمایشی آفلاین استفاده کرد. برعکس، عاملهایی که در آزمونهای آفلاین عملکرد خوبی دارند میتوانند با اطمینان بیشتری استقرار یابند و بهصورت آنلاین پایش شوند.
در واقع، بسیاری از تیمها یک حلقه را اتخاذ میکنند:
ارزیابی آفلاین -> استقرار -> پایش آنلاین -> جمعآوری موارد شکست جدید -> افزودن به مجموعهدادهٔ آفلاین -> پالایش عامل -> تکرار.
مشکلات رایج
با استقرار عاملهای هوش مصنوعی در تولید ممکن است با چالشهای مختلفی مواجه شوید. در اینجا برخی از مشکلات رایج و راهحلهای احتمالی آنها آمده است:
| مشکل | راهحل احتمالی |
|---|---|
| عامل هوش مصنوعی وظایف را بهطور مداوم انجام نمیدهد | - پرامپت دادهشده به عامل را اصلاح کنید؛ در مورد اهداف شفاف باشید. - مشخص کنید در کجا تقسیم وظایف به زیروظایف و سپردن آنها به چند عامل میتواند کمک کند. |
| عامل هوش مصنوعی وارد حلقههای بیپایان میشود | - مطمئن شوید شرایط و قواعد خاتمه روشن وجود دارد تا عامل بداند چه زمانی فرایند را متوقف کند. - برای وظایف پیچیده که نیازمند استدلال و برنامهریزی هستند، از مدل بزرگتری استفاده کنید که برای وظایف استدلالی تخصصی شده است. |
| فراخوانیهای ابزار توسط عامل عملکرد مناسبی ندارند | - خروجی ابزار را خارج از سیستم عامل آزمایش و اعتبارسنجی کنید. - پارامترها، پرامپتها و نامگذاری ابزارها را بهبود دهید. |
| سیستم چندعاملی بهطور سازگار عمل نمیکند | - پرامپتهای دادهشده به هر عامل را اصلاح کنید تا مطمئن شوید مشخص و متمایز از یکدیگر هستند. - یک سیستم سلسلهمراتبی بسازید که از یک عامل “routing” یا کنترلکننده برای تعیین اینکه کدام عامل صحیح است استفاده کند. |
بسیاری از این مسائل را میتوان با داشتن قابلیت مشاهده تشخیص داد. ردیابیها و شاخصهایی که در بالا بحث شد به شما کمک میکنند دقیقاً مشخص کنید مشکل در کدام بخش از جریان کاری عامل رخ میدهد و اشکالزدایی و بهینهسازی را بسیار کارآمدتر میسازند.
مدیریت هزینهها
در اینجا چند راهکار برای مدیریت هزینههای استقرار عاملهای هوش مصنوعی در محیط تولید آورده شده است:
استفاده از مدلهای کوچکتر: مدلهای زبانی کوچک (SLMs) میتوانند در برخی موارد استفاده عاملمحور عملکرد خوبی داشته باشند و هزینهها را بهطور قابلتوجهی کاهش دهند. همانطور که قبلاً ذکر شد، ساخت یک سیستم ارزیابی برای تعیین و مقایسه عملکرد در مقابل مدلهای بزرگتر بهترین راه برای فهمیدن این است که یک SLM چقدر در مورد مورد استفادهٔ شما خوب عمل خواهد کرد. استفاده از SLMها را برای وظایف سادهتر مانند طبقهبندی قصد یا استخراج پارامتر در نظر بگیرید و مدلهای بزرگتر را برای استدلال پیچیده محفوظ نگه دارید.
استفاده از یک مدل مسیردهی: یک استراتژی مشابه استفاده از تنوعی از مدلها و اندازههاست. میتوانید از یک LLM/SLM یا تابع بدونسرور برای مسیردهی درخواستها بر اساس پیچیدگی به مدل مناسب استفاده کنید. این کار به کاهش هزینهها کمک میکند و در عین حال تضمین میکند که وظایف مناسب به مدلهای مناسب سپرده شوند. برای مثال، پرسوجوهای ساده را به مدلهای کوچکتر و سریعتر مسیردهی کنید و تنها برای وظایف استدلالی پیچیده از مدلهای بزرگ و پرهزینه استفاده کنید.
کش کردن پاسخها: شناسایی درخواستها و وظایف رایج و ارائهٔ پاسخها پیش از اینکه از طریق سیستم عاملی شما عبور کنند، راه خوبی برای کاهش حجم درخواستهای مشابه است. حتی میتوانید جریانی را پیادهسازی کنید تا با استفاده از مدلهای هوش مصنوعی پایهتر بررسی کند یک درخواست چقدر شبیه درخواستهای کششدهٔ شماست. این استراتژی میتواند هزینهها را برای پرسشهای پرتکرار یا گردشکارهای متداول بهصورت چشمگیری کاهش دهد.
بیایید ببینیم چگونه این در عمل کار میکند
در نمونهی دفترچهٔ این بخش، نمونههایی خواهیم دید از نحوهٔ استفاده از ابزارهای قابلیتمشاهده برای پایش و ارزیابی عامل خود.
سؤالهای بیشتری درباره عاملهای هوش مصنوعی در تولید دارید؟
به سرور Microsoft Foundry در Discord بپیوندید تا با دیگر یادگیرندگان ملاقات کنید، در ساعات اداری شرکت کنید و سؤالات خود درباره عاملهای هوش مصنوعی را پاسخ بگیرید.
درس قبلی
درس بعدی
سلب مسئولیت: این سند با استفاده از سرویس ترجمهٔ هوش مصنوعی Co-op Translator ترجمه شده است. در حالی که ما در تلاش برای دقت هستیم، لطفاً توجه داشته باشید که ترجمههای خودکار ممکن است حاوی خطا یا نادرستی باشند. نسخهٔ اصلی سند به زبان مبدأ باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حساس یا حیاتی، ترجمهٔ حرفهای انسانی توصیه میشود. ما مسئول هیچگونه سوءتفاهم یا تفسیر نادرستی که از استفاده از این ترجمه ناشی شود، نیستیم.