‏ارزیابی ابزارهای هوش مصنوعی: وقتی «کار می‌کنه» کافی نیست

نیک نیسی، توسعه‌دهنده WorkOS، چند هفته‌ای رو صرف ساختن دو ابزار هوش مصنوعی کرد. یه روز بهش خورد که اصلاً نمی‌دونه این ابزارها واقعاً درست کار می‌کنن یا نه. نه به اون معنا که «آیا اجرا می‌شن» — بله، اجرا می‌شدن — بلکه به این معنا که «آیا واقعاً کار توسعه‌دهنده رو بهتر می‌کنن؟» این یه سوال خیلی سخت‌تره، به‌خصوص وقتی خروجی ابزار هر بار فرق می‌کنه.

ابزار اول یه دستور CLI به اسم workos install بود که از Claude Agent SDK استفاده می‌کنه تا به‌صورت خودکار WorkOS AuthKit رو توی پروژه‌های مختلف نصب کنه. ۱۶ فریم‌ورک مختلف از Next.js گرفته تا Flask و React SPA. ابزار کد پروژه رو می‌خونه، ساختارش رو می‌فهمه و فایل‌های درست رو می‌سازه یا تغییر می‌ده. جادوئیه. و جادو به‌طور پیش‌فرض قابل تست نیست.

برای حل این مشکل، یه سیستم eval ساخته شد. پایه‌اش fixture projectها بودن: پروژه‌های استارتر مینیمال برای هر فریم‌ورک با حالت‌های مختلف مثل example، example-auth0، partial-install و conflicting-middleware. قبل از هر اجرا، ریپو گیت init می‌شه و بعد از اینکه agent کارش رو کرد، diff گیت به‌عنوان منبع حقیقت برای بررسی تغییرات استفاده می‌شه.

مهم‌ترین نکته اینه که agent روی کد واقعی اجرا می‌شه — نه mock، نه stub. همون code path تولید. اگه agent شکست بخوره، می‌تونه تا دو بار self-correct کنه و سیستم eval ثبت می‌کنه که نتیجه از اول موفق بوده، با correction موفق شده، یا نیاز به retry داشته.

نیک اول با چک‌های ساده‌ی فایل شروع کرد: «آیا middleware.ts وجود داره؟ آیا SDK درست import شده؟» ولی خیلی زود فهمید که «پاس شدن» با «خوب بودن» فرق داره. مثلاً یه چک مهم اینه که نه middleware.ts و نه proxy.ts با هم وجود داشته باشن، چون Next.js 16 با هر دو error می‌ده. این نوع دانش domain-specific رو باید توی graderها کدنویسی کرد.

بعد یه مرحله دوم ارزیابی اضافه شد: یه quality grader که کد رو به Claude Haiku می‌ده تا روی چهار بُعد نمره بده: سبک کد، مینیمالیسم، error handling و idiomaticness. هر بُعد از ۱ تا ۵ نمره می‌گیره و مدل باید با chain-of-thought استدلالش رو توضیح بده.

معیار موفقیت هم نه pass/fail ساده، بلکه نرخه:

• ۸۰٪ در اولین تلاش بدون نیاز به تصحیح
• ۹۰٪ با self-correction
• ۹۵٪ با full retry

ابزار دوم یه مشکل کاملاً متفاوت داشت: مجموعه‌ای از skill documentها برای WorkOS که به‌صورت خودکار از مستندات تولید می‌شن و توی system prompt مدل لود می‌شن. سوال اینجا اینه: «آیا دادن این context به مدل واقعاً خروجیش رو بهتر می‌کنه؟» نیک فکر می‌کرد جواب بله‌ست. اشتباه می‌کرد — حداقل برای بعضی‌هاشون.

برای این eval یه رویکرد A/B طراحی شد: هر prompt دوبار اجرا می‌شه، یه بار با skill در system prompt و یه بار بدون. بعد هر دو خروجی مقایسه و نمره‌گذاری می‌شن. test caseها به‌صورت YAML declarative نوشته می‌شن:

- id: sso-node-basic
  product: sso
  skill: workos-sso
  prompt: |
    Implement SSO login flow for a Node.js Express app using the WorkOS SDK.
  expected:
    methods:
      - workos.sso.getAuthorizationUrl
      - workos.sso.getProfileAndToken
    imports:
      - '@workos-inc/node'

این رویکرد نشون داد که بعضی skillها واقعاً خروجی رو بهتر می‌کنن و بعضی‌ها نه. بدون این eval، همه‌شون ship می‌شدن بدون اینکه کسی بدونه کدوم‌ها مفیدن.

درس کلی اینه که eval با test فرق داره. تست رفتار قطعی رو verify می‌کنه: input X، output Y. ولی eval کیفیت آماری می‌سنجه: آیا توزیع خروجی‌ها به threshold کیفیتی می‌رسه؟ test suite باید ۱۰۰٪ سبز باشه؛ eval suite نه — و این by design‌ه.

نکات کلیدی:

• تست‌های سنتی برای LLMها کافی نیستن چون خروجی هر بار فرق می‌کنه
• eval به‌جای pass/fail، نرخ موفقیت رو می‌سنجه (مثلاً ۸۰٪ در اولین تلاش)
• fixture projectهای واقعی مهم‌ترند؛ fixture مصنوعی ممکنه شکست‌های کاذب بده
• grading باید دو لایه داشته باشه: functional (کار می‌کنه؟) و quality (خوب هست؟)
• برای ارزیابی context/skill، رویکرد A/B (با و بدون context) خیلی مفیده
• بعضی skillها واقعاً خروجی رو بهتر نمی‌کنن — eval این رو آشکار می‌کنه