تاریخ انتشار: ۱۹ مه ۲۰۲۶، آخرین به‌روزرسانی: ۲۸ مه ۲۰۲۶
| توضیحی | وب | برنامه‌های افزودنی | وضعیت Chrome | هدف |
|---|---|---|---|---|
| GitHub |  آزمایش معرفی ویژگی جدید |
مشاهده | قصد آزمایش |
WebMCP از کارگزارانی که از مدل‌های هوش مصنوعی زایا استفاده می‌کنند پشتیبانی می‌کند. برای آزمایش هر سیستمی که از هوش مصنوعی زایا استفاده می‌کند، آزمایش‌های شما باید از نتایج احتمالی پشتیبانی کند: یک ورودی می‌تواند به هزاران پاسخ با درجات مختلف دقت منجر شود. این تکنیک آزمایش ارزیابی‌ها یا ارزیابی نامیده می‌شود.
قبل‌از انتشار ابزارها در محیط تولید، باید مطمئن شوید که کارگزاران می‌دانند چه زمانی باید ابزار را فراخوانی کنند، چگونه آن را اجرا کنند، و چه پاسخ‌هایی قابل‌قبول هستند. پیش‌از اینکه فرصت‌های شکست پیش بیاید، به آن‌ها رسیدگی کنید.
ارزیابی‌هایی بنویسید تا نقاط تماس سیستم خود را با یک مدل زبانی بزرگ (LLM) آزمایش کنید:
- براساس شرح و طرحواره ابزارتان، بررسی کنید که مدل هدف ابزارتان را درک می‌کند یا نه.
- تأیید کنید که مدل ابزار درست را با پارامترهای صحیح برای پشتیبانی از هدف کاربر انتخاب می‌کند.
- تأیید کنید که مدل براساس اطلاعاتی که دریافت کرده است عمل می‌کند، برای مثال از اطلاعات برای فراخوانی ابزاری دیگر استفاده می‌کند.
- سفرهای موفق کاربر را درستی‌سنجی کنید. با توجه به هدف کاربر، آیا عامل می‌تواند سفر کاربر را در وب‌سایت من با ابزارهای ارائه‌شده با موفقیت تکمیل کند؟
باید همچنان برای هرگونه تعامل سیستم که با مدل ارتباط برقرار نمی‌کند، آزمون‌های قطعی کلاسیک بنویسید.
حالت‌های خرابی
توسعه‌دهندگان باید سیستم‌هایشان را آزمایش کنند تا از بروز خطا جلوگیری کنند. برای انجام این کار، باید بدانید که سیستم چه زمانی ممکن است با شکست مواجه شود، هم به‌تنهایی و هم در تعامل با عوامل خارجی. برای WebMCP، ممکن است خود ابزار ازکار بیفتد و کارگزاران نتوانند از ابزارها آن‌طور که انتظار می‌رود استفاده کنند.
ابزارهای WebMCP ممکن است ازکار بیفتند و عامل ممکن است با ابزارهای WebMCP ازکار بیفتد. برای مثال، فرض کنید کاربرتان می‌خواهد تی‌شرتی را به سبد خریدش اضافه کند.
| ناموفق | مثال | عیب‌یابی |
|---|---|---|
| کارگزار نمی‌تواند ابزار صحیح را انتخاب کند یا مستقیماً ابزار اشتباه را فرا می‌خواند. |
عامل از 
|
|
| عامل ابزارها را به‌ترتیب اشتباهی فرا می‌خواند |
عامل با 
|
|
| ابزار تماس نماینده با آرگومان‌های نادرست |
نماینده با 
|
|
اگر کاربر بخواهد محتویات سبد خریدش را بررسی کند، چه؟
| ناموفق | مثال | عیب‌یابی |
|---|---|---|
| برونداد ابزار نادرست است یا ابزار چیزی را ازدست داده است. | کاربر می‌خواهد 
|
|
درنهایت، ابزار می‌تواند به هر روشی که جاوا اسکریپت ناموفق باشد. برای عیب‌یابی کردن، موارد زیر را بررسی کنید:
- آیا کد ابزار به‌درستی از عهده همه خطاها و استثناهای احتمالی زمان اجرا برمی‌آید؟
- آیا خطا به‌طور مناسب به نماینده و مدل گزارش می‌شود؟
- آیا میاناهای برنامه‌سازی کاربردی یا سرویس‌های خارجی که ابزار به آن‌ها متکی است سالم هستند؟
- آیا ساختار خطا به‌اندازه کافی واضح است که مدل بتواند بین مشکل موقت (تلاش مجدد) و خرابی بحرانی تمایز قائل شود؟
ابزارهای آزمایشی در جداسازی
اگر یک عامل نتواند تشخیص دهد که برای درخواستی مثل «پیتزای کوچک می‌خواهم» کدام ابزار را فراخوانی کند، در یک سفر کاربر پیچیده شانسی نخواهد داشت.
با آزمایش کردن ابزارها به‌صورت مجزا، می‌توانید طرحواره‌ها و شرح‌هایتان را قبل‌از اجرای شبیه‌سازی مرورگر بهینه‌سازی کنید.
اندازه‌گیری دقت تماس
به نسخه نمایشی ما،
WebMCP zaMaker، نگاهی بیندازید.
وقتی کاربر می‌گوید «پیتزای کوچک می‌خواهم»، می‌توانید انتظار داشته باشید مدل پاسخی ارائه دهد که نشان‌دهنده قصد انجام تماس set_pizza_size با آرگومان "size":"Small" است.
تابع expectedCall تابع و متغیر مستقل موردانتظار را تعریف می‌کند. این رویکرد تأیید می‌کند که نماینده براساس طرحواره ارائه‌شده، ابزار صحیح را برای پشتیبانی از هدف کاربر انتخاب خواهد کرد.
{
"messages": [
{
"role": "user",
"content": "I'd like a small pizza."
}
],
"expectedCall": [
{
"functionName": "set_pizza_size",
"arguments": { "size": "Small" }
}
]
}
از expectedCall برای انجام آزمایشی قطعی و مبتنی بر قانون استفاده می‌شود:
می‌توانید ابزارهای WebMCP خود را به چرخه حیات یک عنصر پیوند دهید، که یعنی وقتی وضعیت برنامه شما با آنچه WebMCP انتظار دارد مطابقت داشته باشد باید آزمایش کنید. برای مدیریت این موضوع، فهرست کاملی از ابزارهای مرتبط با وضعیتی که می‌خواهید ارزیابی کنید ارائه دهید. برای مثال، کاربری با کارگزار خود درحال مرور مشترک است و WebMCP zaMaker را باز می‌کند.
حالت برنامه
[
...
{
"name": "add_topping",
"description": "Add one or more toppings to the pizza",
...
},
{
"name": "set_pizza_size",
"description": "Set the pizza size directly.",
"inputSchema": {
"type": "object",
"properties": {
"size": {
"type": "string",
"enum": [
"Small",
"Medium",
"Large",
"Extra Large"
],
"description": "The specific size name."
},
}
}
},
{
"name": "set_pizza_style",
"description": "Set the style of the pizza (colors/theme)",
...
},
...
]
تماس موردانتظار
...
"expectedCall": [
{
"functionName": "set_pizza_size",
"arguments": { "size": "Small" }
}
]
...
پس‌از باز شدن، WebMCP ابزارهای add_topping، set_pizza_size، و set_pizza_style را نمایان می‌کند. برای آزمایش دقیق هریک از این ابزارهای فردی،
باید همه ابزارها را اضافه کنید تا وضعیت کامل شبیه‌سازی‌شده‌ای ایجاد شود.
توجه: ممکن است نماینده به ابزارهای بیشتری دسترسی داشته باشد، اما بهترین کاری که می‌توانید انجام دهید این است که ابزارهایی را که ارائه می‌دهید ارزیابی کنید.
اکنون که می‌دانید کارگزار ابزار درست را درصورت نیاز فرا می‌خواند، می‌توانید آزمایش کنید که آیا فراخوانی ابزار پارامترهای درست را دارد و نتیجه همان‌طور که انتظار می‌رود است. دو مرحله وجود دارد: آزمایش‌های قطعی و آزمایش‌های احتمالی.
اجرای آزمایش‌های قطعی
ازآنجایی‌که ابزارهای WebMCP با JavaScript یا به‌عنوان نشانه‌گذاری‌های HTML ساخته می‌شوند، می‌توانید آزمایش‌های قطعی برای انجام وظایف زیر بنویسید:
- منطق ابزار را درستی‌سنجی کنید.
- تأیید کنید که وابستگی‌ها به‌درستی فراخوانی شده‌اند.
- تأیید کنید که میانای کاربر طبق انتظار به‌روز شده است، و همچنین هرگونه عوارض جانبی عمدی.
- درستی‌سنجی کنید که اطلاعات برگشتی با مقدار موردانتظار مطابقت داشته باشد.
- پارامترهای آزمایش را اعتبارسنجی کنید.
برای مثال، اگر ابزار شما از تابع SearchComponent استفاده می‌کند، می‌توانید با
گذراندن یک نمونه ساختگی از SearchComponent آزمایش کنید. به‌خاطر داشته باشید که محیطی را که ابزار در آن کار می‌کند شبیه‌سازی کنید تا بهترین نتایج ممکن را به‌دست آورید. این همان
تکنیکی است که برای نوشتن آزمون یکپارچه‌سازی برنامه دیگر استفاده می‌کنید.
اجرای آزمایش‌های احتمالی
اگر برای فراخوانی صحیح ابزارهای بعدی به برونداد مدل نیاز دارید، باید evals را بنویسید.
کاربران می‌توانند پرسمان‌های مستقیمی به مدل بدهند که به‌طور خاص درباره عملکرد ابزار سؤال می‌کند، یا پرسمان‌های مبهمی که نشان می‌دهد باید از ابزار استفاده شود. برای مثال، «به پیتزای من پپرونی اضافه کن» یک پُرسمان مستقیم است. «همه گوشت‌های پیتزا را می‌خواهم» مبهم‌تر است و مدل باید بفهمد که به ابزار add_topping نیاز دارد و کدام چاشنی‌ها را می‌توان به‌عنوان گوشت تعریف کرد.
هنگام ایجاد مجموعه داده برای ارزیابی‌هایتان، هم پُرسمان‌های مستقیمی را که اجرای ابزار خط پایه را آزمایش می‌کنند و هم پُرسمان‌های باز را که منطق استدلال مدل و انتخاب ابزار را آزمایش می‌کنند اضافه کنید.
اگر فروشگاه قهوه دارید، می‌توانید از کاربرانی که از نماینده‌شان می‌خواهند قهوه‌ای را که ماه قبل سفارش داده‌اند دوباره سفارش دهد پشتیبانی کنید. ابزاری برای جستجوی سفارش‌های قبلی، OrderHistoryService، و ابزاری دیگر برای سفارش قهوه بنویس. برای آزمایش سرویس سابقه سفارش، می‌توانید یک محصول ساختگی ارسال کنید که شناسه محصول قهوه را برمی‌گرداند.
در این مثال، ارزیابی می‌کنید که آیا مدل منظور پُرسمان را می‌فهمد،
ابزار مناسب را انتخاب می‌کند، و آیا آن ابزار اطلاعات صحیح را برای اقدام کردن ارائه می‌دهد.
اگر مدل get_order_history را فراخوانی نکند، نمی‌داند از چه چیزی item_id
برای order_product استفاده کند.
آزمایش سرتاسر
آزمون‌های سرتاسری بنویسید تا مطمئن شوید کاربران و نمایندگان آن‌ها می‌توانند سفرشان را باموفقیت تکمیل کنند. علاوه‌بر آزمایش ابزارهای تکی، شما همچنین آزمایش می‌کنید که کنش‌های چندمرحله‌ای در ترتیب صحیح انجام شوند.
برای مثال، شما یک فروشگاه آنلاین لباس دارید. کاربری از نماینده‌اش می‌پرسد: «می‌خواهم یک ژاکت مشکی و یک شلوار جین بخرم. می‌توانید جزئیات مواد استفاده‌شده را ارائه دهید؟»
سفر موفق یک عامل ممکن است به این شکل باشد:
- به دسته لباس پیمایش کنید.
- یکی از لباس‌های درخواست‌شده را پیدا کنید (ترتیب مهم نیست).
- مورد خاصی را پیدا کنید (
search_clothes). - جزئیات محصولی را که حاوی فهرست مواد است (
get_product_details) دریافت کنید. - مراحل ۲ تا ۴ را برای هر مورد درخواستی تکرار کنید.
وقتی عامل به مرحله ۲ می‌رسد، می‌تواند ابتدا به‌دنبال «مشکی» یا «شلوار جین» بگردد، ترتیب مهم نیست. بااین‌حال، بقیه مراحل باید به‌ترتیب دنبال شوند.
یک ارزیابی سرتاسر بنویسید تا تأیید کنید که کارگزار ابزارها را به ترتیب موردانتظار فرا می‌خواند:
{
"messages": [
{
"role": "user",
"content": "I am looking to buy a black jacket and a pair of jeans.
Could you provide a breakdown of the materials used ?"
}
],
"expectedCall": [
{
"functionName": "navigate_to_category",
"arguments": { "category": "clothes" }
},
{
"unordered": [
{
"ordered": [
{
"functionName": "search_clothes",
"arguments": { "query": "black jacket" }
},
{
"functionName": "get_product_details",
"arguments": { "productId": "JACKET002" }
}
]
},
{
"ordered": [
{
"functionName": "search_clothes",
"arguments": { "query": "jeans" }
},
{
"functionName": "get_product_details",
"arguments": { "productId": "JEANS001" }
}
]
}
]
}
]
}
ارزیابی کردن خطاهای میان زنجیره
start_pizza_creator، set_pizza_style، set_pizza_size، start_checkout، add_discount_coupon، و complete_checkout. add_discount_coupon ناموفق بود، اما فرایند همچنان توانست تکمیل شود، یعنی کاربر تخفیف دریافت نکرد.ممکن است مواقعی پیش بیاید که کارگزاری باید به‌ترتیب با چندین ابزار تماس بگیرد. اگر ابزاری در میانه این فرایند ازکار بیفتد چه اتفاقی می‌افتد؟ برای مثال، کاربری می‌خواهد با کد تخفیفش پیتزا سفارش دهد:
«پیتزای پستو کوچک می‌خواهم. از کد ترویجی من، FreePizza، استفاده کن.»
ممکن است عامل در add_discount_coupon با شکست مواجه شود و به
تسویه‌حساب برای پیتزای با قیمت کامل برود. برای آزمایش ابزار add_discount_coupon، می‌توانید این توالی فراخوانی‌های ابزار را به‌صورت دستی و بدون تعامل با مدل اجرا کنید تا این سناریو را شبیه‌سازی کنید. برنامه‌تان را به وضعیتی که
پیش‌بینی می‌کنید ابزار در آنجا ازکار بیفتد ببرید. در این مورد، این ابزار پس‌از ابزار
start_checkout قرار دارد. سپس می‌توانید add_discount_coupon را به‌صورت
مجزا ارزیابی کنید.
آزمایش با WebMCP
آزمایش کردن ارزیابی‌ها برای ابزارها به‌صورت مجزا و ارزیابی سایت‌های فعال‌شده با WebMCP خودتان با هر عامل سازگار با WebMCP را شروع کنید:
- ابزارهای ارزیابی آزمایشی ما را در GitHub بارگیری کنید.
- دوره ما، ایجاد ارزیابی‌های هوش مصنوعی را مرور کنید.