وقتی عوامل هوش مصنوعی از نمونههای اولیه آزمایشی به کاربردهای واقعی منتقل میشوند، توانایی درک رفتار آنها، نظارت بر عملکردشان و ارزیابی سیستماتیک خروجیهایشان اهمیت پیدا میکند.
پس از تکمیل این درس، شما خواهید دانست که چگونه/درک کنید:
هدف این است که شما را با دانش لازم برای تبدیل عوامل “جعبه سیاه” به سیستمهای شفاف، قابل مدیریت و قابل اعتماد مجهز کنیم.
توجه: استقرار عوامل هوش مصنوعی ایمن و قابل اعتماد بسیار مهم است. درس ساخت عوامل هوش مصنوعی قابل اعتماد را نیز بررسی کنید.
ابزارهای مشاهدهپذیری مانند Langfuse یا Azure AI Foundry معمولاً اجرای عوامل را به صورت ردپاها و بخشها نمایش میدهند.
بدون مشاهدهپذیری، یک عامل هوش مصنوعی ممکن است مانند یک “جعبه سیاه” به نظر برسد - حالت داخلی و استدلال آن مبهم است، که تشخیص مشکلات یا بهینهسازی عملکرد را دشوار میکند. با مشاهدهپذیری، عوامل به “جعبههای شیشهای” تبدیل میشوند، شفافیتی که برای ایجاد اعتماد و اطمینان از عملکرد صحیح آنها ضروری است.
انتقال عوامل هوش مصنوعی به محیطهای تولید چالشها و نیازهای جدیدی را معرفی میکند. مشاهدهپذیری دیگر یک قابلیت “خوب داشتن” نیست، بلکه یک قابلیت حیاتی است:
برای نظارت و درک رفتار عامل، باید طیف وسیعی از معیارها و سیگنالها را ردیابی کنید. در حالی که معیارهای خاص ممکن است بر اساس هدف عامل متفاوت باشند، برخی معیارها به طور جهانی مهم هستند.
در اینجا برخی از رایجترین معیارهایی که ابزارهای مشاهدهپذیری نظارت میکنند آورده شده است:
تأخیر: عامل چقدر سریع پاسخ میدهد؟ زمانهای انتظار طولانی تجربه کاربری را تحت تأثیر قرار میدهد. باید تأخیر را برای وظایف و مراحل جداگانه با ردیابی اجرای عامل اندازهگیری کنید. به عنوان مثال، عاملی که برای همه فراخوانیهای مدل ۲۰ ثانیه زمان میبرد، میتواند با استفاده از یک مدل سریعتر یا اجرای فراخوانیهای مدل به صورت موازی تسریع شود.
هزینهها: هزینه هر اجرای عامل چقدر است؟ عوامل هوش مصنوعی به فراخوانیهای LLM که بر اساس تعداد توکن یا APIهای خارجی هزینهبردار هستند، متکی هستند. استفاده مکرر از ابزار یا درخواستهای متعدد میتواند به سرعت هزینهها را افزایش دهد. به عنوان مثال، اگر یک عامل پنج بار یک LLM را فراخوانی کند تا کیفیت بهبود یابد، باید ارزیابی کنید که آیا هزینه توجیهپذیر است یا میتوانید تعداد فراخوانیها را کاهش دهید یا از یک مدل ارزانتر استفاده کنید. نظارت در زمان واقعی همچنین میتواند افزایشهای غیرمنتظره را شناسایی کند (مانند اشکالاتی که باعث حلقههای API بیش از حد میشوند).
خطاهای درخواست: چند درخواست توسط عامل شکست خورده است؟ این میتواند شامل خطاهای API یا فراخوانیهای ابزار ناموفق باشد. برای مقاومتر کردن عامل خود در برابر این موارد در تولید، میتوانید تنظیمات پشتیبان یا تلاش مجدد را انجام دهید. به عنوان مثال، اگر ارائهدهنده LLM A از دسترس خارج شود، به عنوان پشتیبان به LLM B تغییر دهید.
بازخورد کاربر: ارزیابیهای مستقیم کاربران اطلاعات ارزشمندی ارائه میدهند. این میتواند شامل رتبهبندیهای صریح (👍بالا/👎پایین، ⭐۱-۵ ستاره) یا نظرات متنی باشد. بازخورد منفی مداوم باید شما را هشدار دهد زیرا این نشانهای است که عامل به درستی کار نمیکند.
بازخورد ضمنی کاربر: رفتارهای کاربران حتی بدون رتبهبندی صریح بازخورد غیرمستقیم ارائه میدهند. این میتواند شامل بازنویسی فوری پرسش، درخواستهای مکرر یا کلیک بر روی دکمه تلاش مجدد باشد. به عنوان مثال، اگر مشاهده کنید که کاربران مکرراً یک پرسش را میپرسند، این نشانهای است که عامل به درستی کار نمیکند.
دقت: عامل چقدر خروجیهای صحیح یا مطلوب تولید میکند؟ تعریف دقت متفاوت است (مانند صحت حل مسئله، دقت بازیابی اطلاعات، رضایت کاربر). اولین قدم تعریف موفقیت برای عامل شماست. میتوانید دقت را از طریق بررسیهای خودکار، امتیازات ارزیابی یا برچسبهای تکمیل وظیفه ردیابی کنید. به عنوان مثال، علامتگذاری ردپاها به عنوان “موفق” یا “ناموفق”.
معیارهای ارزیابی خودکار: همچنین میتوانید ارزیابیهای خودکار تنظیم کنید. به عنوان مثال، میتوانید از یک LLM برای امتیازدهی به خروجی عامل استفاده کنید، مانند اینکه آیا مفید، دقیق یا خیر است. همچنین چندین کتابخانه متنباز وجود دارد که به شما کمک میکند جنبههای مختلف عامل را امتیازدهی کنید. به عنوان مثال، RAGAS برای عوامل RAG یا LLM Guard برای شناسایی زبان مضر یا تزریق درخواست.
در عمل، ترکیبی از این معیارها بهترین پوشش را از سلامت عامل هوش مصنوعی ارائه میدهد. در دفترچه یادداشت نمونه این فصل، نشان خواهیم داد که این معیارها در مثالهای واقعی چگونه به نظر میرسند، اما ابتدا یاد خواهیم گرفت که یک جریان کاری ارزیابی معمولی چگونه به نظر میرسد.
برای جمعآوری دادههای ردیابی، باید کد خود را ابزارگذاری کنید. هدف ابزارگذاری کد عامل این است که ردپاها و معیارهایی تولید کند که بتوانند توسط یک پلتفرم مشاهدهپذیری جمعآوری، پردازش و بصریسازی شوند.
OpenTelemetry (OTel): OpenTelemetry به عنوان یک استاندارد صنعتی برای مشاهدهپذیری LLM ظاهر شده است. این ابزار مجموعهای از APIها، SDKها و ابزارها برای تولید، جمعآوری و صادرات دادههای تلهمتری ارائه میدهد.
کتابخانههای ابزارگذاری زیادی وجود دارند که چارچوبهای عامل موجود را پوشش میدهند و صادرات بخشهای OpenTelemetry به یک ابزار مشاهدهپذیری را آسان میکنند. در زیر یک مثال از ابزارگذاری یک عامل AutoGen با کتابخانه ابزارگذاری OpenLit آورده شده است:
import openlit
openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)
دفترچه یادداشت نمونه در این فصل نشان خواهد داد که چگونه عامل AutoGen خود را ابزارگذاری کنید.
ایجاد دستی بخشها: در حالی که کتابخانههای ابزارگذاری یک خط پایه خوب ارائه میدهند، اغلب مواردی وجود دارد که اطلاعات دقیقتر یا سفارشی مورد نیاز است. میتوانید بخشها را به صورت دستی ایجاد کنید تا منطق برنامه سفارشی اضافه کنید. مهمتر از همه، میتوانند بخشهای ایجادشده به صورت خودکار یا دستی را با ویژگیهای سفارشی (که به عنوان برچسبها یا متادادهها نیز شناخته میشوند) غنی کنند. این ویژگیها میتوانند شامل دادههای خاص کسبوکار، محاسبات میانی یا هر زمینهای باشند که ممکن است برای اشکالزدایی یا تحلیل مفید باشد، مانند 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 باشد) تا بهبودها را بررسی کند یا از پسرفتها جلوگیری کند. مزیت این نوع ارزیابی این است که قابل تکرار است و میتوانید معیارهای دقت واضحی دریافت کنید زیرا حقیقت زمین دارید. همچنین ممکن است پرسشهای کاربران را شبیهسازی کنید و پاسخهای عامل را با پاسخهای ایدهآل مقایسه کنید یا از معیارهای خودکار همانطور که در بالا توضیح داده شد استفاده کنید.
چالش اصلی در ارزیابی آفلاین اطمینان از جامع بودن و مرتبط بودن مجموعه داده آزمایشی شماست – ممکن است عامل در یک مجموعه آزمایشی ثابت عملکرد خوبی داشته باشد اما با پرسشهای بسیار متفاوت در تولید مواجه شود. بنابراین، باید مجموعههای آزمایشی را با موارد جدید و مثالهایی که سناریوهای واقعی را منعکس میکنند بهروز نگه دارید. ترکیبی از موارد کوچک “آزمایش دود” و مجموعههای ارزیابی بزرگتر مفید است: مجموعههای کوچک برای بررسی سریع و مجموعههای بزرگتر برای معیارهای عملکرد گستردهتر.
این نوع ارزیابی به ارزیابی عامل در یک محیط زنده و واقعی اشاره دارد، یعنی در طول استفاده واقعی در تولید. ارزیابی آنلاین شامل نظارت بر عملکرد عامل در تعاملات واقعی کاربران و تحلیل نتایج به صورت مداوم است.
به عنوان مثال، ممکن است نرخهای موفقیت، امتیازات رضایت کاربران یا سایر معیارها را در ترافیک زنده ردیابی کنید. مزیت ارزیابی آنلاین این است که چیزهایی را که ممکن است در یک محیط آزمایشگاهی پیشبینی نکنید، ثبت میکند – میتوانید تغییر مدل را در طول زمان مشاهده کنید (اگر اثربخشی عامل با تغییر الگوهای ورودی کاهش یابد) و پرسشها یا موقعیتهای غیرمنتظرهای را که در دادههای آزمایشی شما نبودند، شناسایی کنید. این نوع ارزیابی تصویر واقعی از نحوه رفتار عامل در دنیای واقعی ارائه میدهد.
ارزیابی آنلاین اغلب شامل جمعآوری بازخورد ضمنی و صریح کاربران، همانطور که بحث شد، و احتمالاً اجرای آزمایشهای سایه یا A/B (که در آن نسخه جدید عامل به صورت موازی برای مقایسه با نسخه قدیمی اجرا میشود). چالش این نوع ارزیابی این است که ممکن است برچسبها یا امتیازات قابل اعتماد برای تعاملات زنده دشوار باشد – ممکن است به بازخورد کاربران یا معیارهای پاییندستی (مانند اینکه آیا کاربر روی نتیجه کلیک کرده است) متکی باشید.
ارزیابی آنلاین و آفلاین متقابل نیستند؛ آنها به شدت مکمل یکدیگر هستند. بینشهای حاصل از نظارت آنلاین (مانند انواع جدید پرسشهای کاربران که عامل در آنها عملکرد ضعیفی دارد) میتوانند برای تقویت و بهبود مجموعه دادههای آزمایشی آفلاین استفاده شوند. به طور مشابه، عواملی که در آزمایشهای آفلاین عملکرد خوبی دارند، میتوانند با اطمینان بیشتری مستقر شده و به صورت آنلاین نظارت شوند.
در واقع، بسیاری از تیمها یک حلقه را اتخاذ میکنند:
ارزیابی آفلاین -> استقرار -> نظارت آنلاین -> جمعآوری موارد شکست جدید -> افزودن به مجموعه داده آفلاین -> اصلاح عامل -> تکرار.
هنگام استقرار عوامل هوش مصنوعی در تولید، ممکن است با چالشهای مختلفی مواجه شوید. در اینجا برخی از مشکلات رایج و راهحلهای احتمالی آنها آورده شده است:
مشکل | راهحل احتمالی |
---|---|
عامل هوش مصنوعی وظایف را به طور مداوم انجام نمیدهد | - درخواست دادهشده به عامل هوش مصنوعی را اصلاح کنید؛ اهداف را به وضوح مشخص کنید. - شناسایی کنید که تقسیم وظایف به زیروظایف و مدیریت آنها توسط عوامل متعدد میتواند کمککننده باشد. |
عامل هوش مصنوعی وارد حلقههای مداوم میشود | - اطمینان حاصل کنید که شرایط و ضوابط خاتمه واضحی دارید تا عامل بداند چه زمانی باید فرآیند را متوقف کند. |
در اینجا برخی از مشکلات رایج که ممکن است هنگام کار با سیستمهای عامل هوش مصنوعی با آنها مواجه شوید و راهحلهای پیشنهادی آورده شده است:
مشکل | راهحل |
---|---|
ابزارهای عامل به درستی کار نمیکنند | - خروجی ابزار را خارج از سیستم عامل آزمایش و اعتبارسنجی کنید. - پارامترها، دستورات و نامگذاری ابزارها را بهبود دهید. |
سیستم چندعاملی عملکرد یکنواختی ندارد | - دستورات دادهشده به هر عامل را اصلاح کنید تا خاص و متمایز از یکدیگر باشند. - یک سیستم سلسلهمراتبی با استفاده از یک عامل “مسیریاب” یا کنترلکننده بسازید تا مشخص کند کدام عامل مناسب است. |
بسیاری از این مشکلات را میتوان با استفاده از قابلیت مشاهده بهتر شناسایی کرد. ردیابیها و معیارهایی که قبلاً بحث کردیم، به شناسایی دقیق محل وقوع مشکلات در جریان کار عامل کمک میکنند و فرآیند اشکالزدایی و بهینهسازی را بسیار کارآمدتر میسازند.
در اینجا چند استراتژی برای مدیریت هزینههای استقرار عوامل هوش مصنوعی در محیط تولید آورده شده است:
استفاده از مدلهای کوچکتر: مدلهای زبانی کوچک (SLM) میتوانند در برخی از موارد استفاده عاملمحور عملکرد خوبی داشته باشند و هزینهها را به طور قابل توجهی کاهش دهند. همانطور که قبلاً اشاره شد، ساخت یک سیستم ارزیابی برای تعیین و مقایسه عملکرد در مقابل مدلهای بزرگتر بهترین راه برای درک عملکرد SLM در مورد استفاده شما است. استفاده از SLM را برای وظایف سادهتر مانند طبقهبندی نیت یا استخراج پارامتر در نظر بگیرید و مدلهای بزرگتر را برای استدلالهای پیچیدهتر نگه دارید.
استفاده از مدل مسیریاب: یک استراتژی مشابه استفاده از تنوعی از مدلها و اندازهها است. میتوانید از یک LLM/SLM یا تابع بدون سرور برای مسیریابی درخواستها بر اساس پیچیدگی به مدلهای مناسب استفاده کنید. این کار نه تنها هزینهها را کاهش میدهد بلکه عملکرد را برای وظایف مناسب تضمین میکند. به عنوان مثال، درخواستهای ساده را به مدلهای کوچکتر و سریعتر هدایت کنید و فقط از مدلهای بزرگ و گران برای وظایف استدلال پیچیده استفاده کنید.
ذخیرهسازی پاسخها: شناسایی درخواستها و وظایف رایج و ارائه پاسخها قبل از عبور از سیستم عامل شما راه خوبی برای کاهش حجم درخواستهای مشابه است. حتی میتوانید یک جریان برای شناسایی میزان شباهت یک درخواست به درخواستهای ذخیرهشده خود با استفاده از مدلهای هوش مصنوعی سادهتر پیادهسازی کنید. این استراتژی میتواند هزینهها را برای سوالات متداول یا جریانهای کاری رایج به طور قابل توجهی کاهش دهد.
در دفترچه نمونه این بخش، مثالهایی از نحوه استفاده از ابزارهای مشاهدهپذیری برای نظارت و ارزیابی عامل خود را خواهیم دید.
به دیسکورد Azure AI Foundry بپیوندید تا با دیگر یادگیرندگان ملاقات کنید، در ساعات اداری شرکت کنید و سوالات خود درباره عوامل هوش مصنوعی را مطرح کنید.
سلب مسئولیت:
این سند با استفاده از سرویس ترجمه هوش مصنوعی Co-op Translator ترجمه شده است. در حالی که ما برای دقت تلاش میکنیم، لطفاً توجه داشته باشید که ترجمههای خودکار ممکن است شامل خطاها یا نادقتیهایی باشند. سند اصلی به زبان اصلی آن باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حساس، ترجمه حرفهای انسانی توصیه میشود. ما هیچ مسئولیتی در قبال سوءتفاهمها یا تفسیرهای نادرست ناشی از استفاده از این ترجمه نداریم.