ارزیابی‌ها برای WebMCP

Kasper Kulikowski

منتشر شده: ۱۹ مه ۲۰۲۶

WebMCP از عواملی که از مدل‌های هوش مصنوعی مولد استفاده می‌کنند، پشتیبانی می‌کند. برای آزمایش هر سیستمی با استفاده از هوش مصنوعی مولد، آزمایش‌های شما باید از نتایج احتمالی پشتیبانی کنند: یک ورودی می‌تواند منجر به هزاران پاسخ با درجات مختلفی از دقت شود. این تکنیک آزمایش ، ارزیابی یا سنجش نامیده می‌شود.

قبل از انتشار ابزارها در محیط عملیاتی، باید مطمئن شوید که عامل‌ها می‌دانند چه زمانی ابزار را فراخوانی کنند، چگونه آن را اجرا کنند و چه پاسخ‌هایی قابل قبول هستند. قبل از وقوع، به فرصت‌های شکست رسیدگی کنید.

برای آزمایش نقاط تماس سیستم خود با یک مدل زبان بزرگ (LLM) ارزیابی‌هایی بنویسید:

• بررسی کنید که مدل، بر اساس توضیحات و طرحواره‌اش، هدف ابزار شما را درک می‌کند.
• تأیید کنید که مدل، ابزار مناسب را با پارامترهای صحیح برای پشتیبانی از قصد کاربر انتخاب می‌کند.
• تأیید کنید که مدل بر اساس اطلاعات دریافتی عمل می‌کند، برای مثال از اطلاعات برای فراخوانی ابزار دیگری استفاده می‌کند.
• تأیید موفقیت‌آمیز بودن سفرهای کاربر. با توجه به هدف کاربر، آیا یک عامل می‌تواند با ابزارهای ارائه شده، سفر کاربر را در وب‌سایت من با موفقیت انجام دهد؟

شما باید به نوشتن تست‌های قطعی کلاسیک برای هرگونه تعامل سیستمی که با مدل ارتباط برقرار نمی‌کند، ادامه دهید.

حالت‌های خرابی

توسعه‌دهندگان باید سیستم‌های خود را آزمایش کنند تا از خرابی‌ها قبل از وقوع جلوگیری کنند. برای انجام این کار، باید بفهمید که چه زمانی سیستم ممکن است خراب شود، چه به تنهایی و چه در تعامل با عوامل خارجی. برای WebMCP، خود ابزار ممکن است خراب شود و ممکن است عوامل نتوانند از ابزارها آنطور که انتظار می‌رود استفاده کنند.

ابزارهای WebMCP ممکن است از کار بیفتند و چه زمانی ممکن است عامل با ابزارهای WebMCP از کار بیفتد. به عنوان مثال، فرض کنید کاربر شما می‌خواهد یک تی‌شرت به سبد خرید خود اضافه کند.

شکست	مثال	عیب‌یابی
عامل نمی‌تواند ابزار صحیح را انتخاب کند یا مستقیماً ابزار اشتباه را فراخوانی می‌کند.	کاربر از addToCart صرف نظر می‌کند و مستقیماً به checkout می‌رود.	آیا description ابزار واضح، کامل و به طور دقیق منعکس کننده عملکرد ابزار است؟ آیا functionName قابل فهم و توصیفی است؟ آیا ابزار در وضعیت/زمینه فعلی به درستی در معرض LLM قرار گرفته است؟ آیا طرحواره این ابزار به طور بالقوه بیش از حد شبیه به ابزار دیگری است که منجر به ابهام در فراخوانی می‌شود؟
اپراتور ابزارها را به ترتیب اشتباه فراخوانی می‌کند	اپراتور، تابع checkout و سپس addToCart فراخوانی می‌کند.	آیا توضیحات ابزارها با هم همپوشانی دارند و LLM را در مورد توالی مورد نیاز گیج می‌کنند؟ آیا خروجی ابزار قبلی، زمینه لازم برای فراخوانی ابزار بعدی را فراهم می‌کند؟ آیا وضعیت به درستی به‌روزرسانی شده و آیا ابزارهای جدیدی طبق انتظار در اختیار LLM قرار گرفته است؟ آیا اگر ابزارهای خاصی به ترتیب متفاوتی فراخوانی شوند، مورد استفاده‌ی سرتاسری همچنان صحیح است؟ آیا زنجیره فراخوانی ابزار خاص را به صورت جداگانه آزمایش کرده‌اید و فراخوانی‌های قبلی را مجبور کرده‌اید تا تأیید کنند که LLM گام بعدی صحیح را انتخاب می‌کند؟
عامل، ابزاری را با آرگومان‌های نادرست فراخوانی می‌کند	عامل addToCart فراخوانی می‌کند، اما به جای تی‌شرت، کفش اضافه می‌کند.	آیا inputSchema به وضوح تعریف شده است، شامل مقادیر enum و description خوبی برای هر ویژگی؟ آیا همه پارامترهای مورد نیاز به صراحت علامت گذاری و بررسی شده اند؟ آیا توضیحات آرگومان به صراحت LLM را در مورد نحوه نگاشت ورودی کاربر به داده‌های ساختاریافته مورد انتظار (مانند یک شناسه یا قالب خاص) راهنمایی می‌کند؟

اگر کاربر بخواهد موجودی سبد خرید خود را بررسی کند، چه می‌شود؟

شکست	مثال	عیب‌یابی
خروجی ابزار نادرست است یا ابزار چیزی را از قلم انداخته است.	کاربر درخواست viewCart می‌دهد، اما عامل به جای نام محصولات و قیمت‌های تکی، کل هزینه سبد خرید را نمایش می‌دهد.	آیا منطق ابزار زیربنایی دارای اشکالاتی است (با تست‌های قطعی بررسی کنید)؟ آیا وضعیت رابط کاربری به درستی به‌روزرسانی شده بود و آیا عامل اطلاعات صحیحی در مورد عوارض جانبی دریافت کرده بود؟ اگر خروجی توسط LLM برای فراخوانی‌های بعدی استفاده می‌شود، آیا خروجی به طور واضح برای مصرف LLM قالب‌بندی شده است؟ آیا خروجی بیش از حد طولانی است؟ آیا فقط شامل حداقل اطلاعات ضروری است که LLM برای اقدام بعدی به آن نیاز دارد؟

در نهایت، یک ابزار می‌تواند به هر نحوی باعث عدم موفقیت جاوا اسکریپت شود. برای عیب‌یابی، موارد زیر را بررسی کنید:

• آیا کد ابزار به درستی تمام خطاها و استثنائات احتمالی زمان اجرا را مدیریت می‌کند؟
• آیا خطا به درستی به عامل و مدل گزارش می‌شود؟
• آیا APIها یا سرویس‌های خارجی که ابزار به آنها متکی است، سالم هستند؟
• آیا ساختار خطا به اندازه کافی واضح است که مدل بتواند بین یک مشکل موقت (تلاش مجدد) و یک خطای بحرانی تفاوت قائل شود؟

ابزارهای تست به صورت جداگانه

اگر یک اپراتور نتواند تشخیص دهد که برای درخواستی مانند «من یک پیتزای کوچک می‌خواهم» از کدام ابزار استفاده کند، در یک سفر کاربری پیچیده شانسی نخواهد داشت.

با آزمایش ابزارها به صورت جداگانه، می‌توانید طرحواره‌ها و توضیحات خود را قبل از اجرای شبیه‌سازی مرورگر بهینه کنید.

نکته: می‌توانید using navigator.modelContext.executeTool(...) یک فراخوانی ابزار 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 با جاوا اسکریپت یا به صورت حاشیه‌نویسی‌های HTML ساخته می‌شوند، می‌توانید تست‌های قطعی برای انجام وظایف زیر بنویسید:

• منطق ابزار را تأیید کنید.
• تأیید کنید که وابستگی‌ها به درستی فراخوانی شده‌اند.
• رابط کاربری را مطابق انتظار به‌روزرسانی کنید، به همراه هرگونه عوارض جانبی عمدی دیگر.
• تأیید کنید که اطلاعات برگشتی با مقدار مورد انتظار مطابقت دارد.
• پارامترهای آزمایش را اعتبارسنجی کنید.

برای مثال، اگر ابزار شما از یک تابع SearchComponent استفاده می‌کند، می‌توانید با ارسال یک نمونه آزمایشی از SearchComponent را آزمایش کنید. به یاد داشته باشید که محیطی را که ابزار در آن کار می‌کند شبیه‌سازی کنید تا بهترین نتایج ممکن را بدست آورید. این همان تکنیکی است که برای نوشتن یک تست ادغام برنامه دیگر استفاده می‌کنید.

اجرای آزمون‌های احتمالی

اگر به خروجی مدلی نیاز دارید که بتواند ابزارهای بعدی را به درستی فراخوانی کند، باید توابع ارزیابی (evals) بنویسید.

کاربران می‌توانند پرسش‌های مستقیمی به مدل ارائه دهند که به‌طور خاص بپرسد ابزار چه کاری انجام می‌دهد، یا پرسش مبهمی که نشان دهد باید از ابزاری استفاده شود. برای مثال، «پپرونی را به پیتزایم اضافه کنم» یک پرسش مستقیم است. «من تمام گوشت پیتزایم را می‌خواهم» مبهم‌تر است و مستلزم آن است که مدل بفهمد که به ابزار add_topping نیاز دارد و اینکه کدام یک از مواد روی پیتزا می‌تواند به‌عنوان گوشت تعریف شود.

هنگام ایجاد مجموعه داده‌ها برای ارزیابی‌های خود، هم پرس‌وجوهای مستقیم که اجرای ابزار پایه را آزمایش می‌کنند و هم پرس‌وجوهای باز-پاسخ که استدلال مدل و منطق انتخاب ابزار را آزمایش می‌کنند، لحاظ کنید.

اگر یک کافی‌شاپ اداره می‌کنید، می‌توانید از کاربرانی که از نماینده خود می‌خواهند همان قهوه‌ای را که ماه گذشته سفارش داده‌اند، دوباره سفارش دهد، پشتیبانی کنید. ابزاری برای جستجوی سفارش‌های قبلی، OrderHistoryService ، و ابزاری دیگر برای سفارش قهوه بنویسید. برای آزمایش سرویس تاریخچه سفارش، می‌توانید یک نمونه آزمایشی (mock) ارسال کنید که شناسه محصول قهوه را برمی‌گرداند.

در این مثال، شما ارزیابی می‌کنید که آیا مدل منظور پرس‌وجو را درک می‌کند، ابزار مناسب را انتخاب می‌کند و آیا آن ابزار اطلاعات مناسب را برای اقدام ارائه می‌دهد یا خیر. اگر مدل get_order_history را فراخوانی نکند، نمی‌داند از چه item_id برای order_product استفاده کند.

آزمایش سرتاسری

تست‌های سرتاسری بنویسید تا به شما اطمینان دهد که کاربران و نمایندگان آنها می‌توانند سفر خود را با موفقیت به پایان برسانند. علاوه بر تست ابزارهای تکی، شما همچنین آزمایش می‌کنید که اقدامات چند مرحله‌ای به ترتیب صحیح انجام می‌شوند.

برای مثال، شما یک فروشگاه آنلاین لباس دارید. یک کاربر از نماینده آنها می‌پرسد: «من به دنبال خرید یک ژاکت مشکی و یک شلوار جین هستم. آیا می‌توانید جزئیات مواد استفاده شده را ارائه دهید؟»

یک سفر موفقِ عامل‌محور می‌تواند به شکل زیر باشد:

1. به دسته بندی لباس ها بروید.
2. یکی از لباس‌های درخواستی را پیدا کنید (ترتیب مهم نیست).
3. پیدا کردن یک آیتم خاص ( search_clothes ).
4. جزئیات محصولی که شامل لیست مواد است را دریافت کنید ( get_product_details ).
5. مراحل ۲ تا ۴ را برای هر مورد درخواستی تکرار کنید.

وقتی عامل به مرحله ۲ می‌رسد، می‌تواند ابتدا مشکی یا شلوار جین را جستجو کند، ترتیب آنها مهم نیست. با این حال، بقیه مراحل باید به ترتیب دنبال شوند.

یک ارزیابی سرتاسری بنویسید تا تأیید کند که عامل، ابزارها را به ترتیب مورد انتظار فراخوانی می‌کند:

{
  "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" }
            }
          ]
        }
      ]
    }
  ]
}

ارزیابی خرابی‌های میان‌زنجیره‌ای

ممکن است مواقعی پیش بیاید که یک اپراتور مجبور باشد چندین ابزار را به صورت متوالی فراخوانی کند. اگر ابزاری در وسط این فرآیند از کار بیفتد چه اتفاقی می‌افتد؟ به عنوان مثال، کاربری می‌خواهد با کد تخفیف خود پیتزا سفارش دهد:

«من یک پیتزای کوچک پستو می‌خواهم. از کد تخفیف من، FreePizza استفاده کنید.»

این امکان وجود دارد که عامل در add_discount_coupon شکست بخورد و برای پرداخت یک پیتزا با قیمت کامل اقدام کند. برای آزمایش ابزار add_discount_coupon ، می‌توانید این توالی از فراخوانی‌های ابزار را به صورت دستی و بدون تعامل با یک مدل، اجرا کنید تا این سناریو را شبیه‌سازی کنید. برنامه خود را به حالتی که پیش‌بینی می‌کنید ابزار در آن شکست می‌خورد، بیاورید. در این حالت، این حالت بعد از ابزار start_checkout است. سپس، می‌توانید add_discount_coupon به صورت جداگانه ارزیابی کنید.

با WebMCP آزمایش کنید

شروع به آزمایش ارزیابی ابزارها به صورت جداگانه کنید و سایت‌های دارای قابلیت WebMCP خود را با هر عامل سازگار با WebMCP ارزیابی کنید:

• ابزارهای ارزیابی تجربی ما را از گیت‌هاب دانلود کنید.
• دوره ما را مرور کنید، ارزیابی‌های هوش مصنوعی ایجاد کنید .