Clef و Jev را برای تصمیم‌های محدود، مثل انتخاب گروه یک تیکت، باید با داده همان مسئله مقایسه کرد؛ نه فقط با سرعت اعلام‌شده سازنده. مدل تصمیم‌گیری از میان گزینه‌های مشخص انتخاب میکند. این کار با تولید پاسخ آزاد چت‌بات فرق دارد و میتواند بخشی از یک سامانه پشتیبانی باشد، نه جایگزین کامل کارشناس یا مدل گفت‌وگویی.
این مقاله یک طرح آزمایش قابل تکرار برای تیکت فارسی ارائه میکند، نه گزارش Benchmark انجام‌شده روی دو مدل. نتیجه عددی یا برنده‌ای که اندازه‌گیری نشده باشد اعلام نمی‌کنیم. هدف این است که بتوانید کیفیت مسیریابی، تأخیر، هزینه و خطر اشتباه را بسنجید و در صورت نیاز، اجرای برنامه را روی پلتفرم ابری پاستا انجام دهید.
Clef چیست و چرا با Jev مقایسه می‌شود؟
Cloudflare در معرفی رسمی اول اکتبر ۲۰۲۶، Clef و Clef-flash را در دسته مدلهای تصمیم‌گیری معرفی کرد و درباره سازگاری با API مدل Jev توضیح داد. این ادعای سازنده درباره قرارداد و عملکرد است؛ کیفیت زبان فارسی یا نتیجه روی داده فروشگاه شما را ثابت نمیکند. مدل و مسیر جاری ارائه را از کاتالوگ رسمی Workers AI بررسی کنید.
برای آشنایی با سمت دیگر مقایسه، راهنمای مدل تصمیم‌گیری Jev و معرفی Jev Ultrafast را مطالعه کنید. نام خانواده، نسخه دقیق و endpoint باید در گزارش آزمایش ثبت شود. مقایسه دو نام کلی بدون نسخه و مسیر ارائه، بعداً قابل تکرار نیست.
مسئله مسیریابی تیکت را دقیق تعریف کنید
فرض کنید تیکت‌ها باید به گروه‌های «مالی»، «استقرار»، «دامنه»، «وردپرس» و «بررسی انسانی» بروند. این برچسبها نمونه آموزشی‌اند و باید با ساختار واقعی تیم جایگزین شوند. برای هر گروه تعریف، مثال مثبت و مرز با گروه‌های دیگر بنویسید. اگر خود کارشناسان درباره معنی دسته‌ها توافق ندارند، مدل هم هدف روشنی برای یادگیری یا ارزیابی ندارد.
واژه «دامنه» ممکن است در تیکت خطای اتصال برنامه هم بیاید، بدون آنکه مشکل ثبت دامنه باشد. پس طبقه‌بندی نباید صرفاً بر حضور کلمه انجام شود. متن «پول کم شد ولی سرویس ساخته نشد» هم میتواند چندبخشی باشد. تصمیم بگیرید مسیریابی تک‌برچسبی می‌خواهید یا چندبرچسبی؛ تغییر این تعریف وسط آزمایش، نتیجه را مخدوش میکند.
یک مجموعه داده فارسی سالم بسازید
از تیکت‌های مجاز و ناشناس‌شده نمونه بگیرید. نام، تلفن، ایمیل، توکن، نشانی خصوصی و اطلاعات پرداخت را پیش از ارسال به مدل حذف یا جایگزین کنید. دسترسی به سامانه پشتیبانی به معنی مجوز ارسال همه داده‌ها به هر ارائه‌دهنده نیست. سیاست حریم خصوصی و محل پردازش را برای مسیر انتخابی بررسی کنید.
نمونه‌ها باید زبان رسمی، محاوره، غلط تایپی، متن کوتاه و ترکیب فارسی و انگلیسی داشته باشند. داده خیلی تمیز فقط رفتار روی سؤال‌های ویرایش‌شده را نشان می‌دهد. در عین حال، نمونه مصنوعی را با داده واقعی مخلوط و بدون برچسب گزارش نکنید؛ هرکدام نقش متفاوتی در آزمون دارند.
| متن ساختگی آموزشی | برچسب نمونه | نکته ارزیابی |
|---|---|---|
| پرداخت کردم ولی اعتبارم اضافه نشده | مالی | نباید اقدام مالی خودکار ایجاد کند |
| بعد از deploy خطای build می‌گیرم | استقرار | ترکیب فارسی و شناسه لاتین |
| دامنه وصله ولی گواهی هنوز آماده نیست | دامنه | تفکیک DNS و HTTPS در مرحله بعد |
| هم سفارش مشکل دارد هم مبلغش برگشته | بررسی انسانی | ابهام و نیاز به اطلاعات بیشتر |
تقسیم داده و جلوگیری از نشت ارزیابی
داده تنظیم Prompt و داده آزمون نهایی را جدا نگه دارید. نسخه‌های تقریباً تکراری یک تیکت نباید در دو بخش پخش شوند. اگر پاسخ درست نمونه آزمون در مثال‌های Prompt آمده باشد، دقت بالاتر لزوماً نشانه تعمیم نیست. تقسیم زمانی نیز مفید است: روی گذشته تنظیم کنید و روی بازه بعدی بسنجید.
برای برچسب مرجع، دو نفر نمونه‌های مبهم را مستقل بررسی کنند و اختلاف‌ها ثبت شود. لازم نیست همه اختلاف‌ها را با زور به یک برچسب تبدیل کنید؛ دسته بررسی انسانی بخشی از طراحی است. تعداد نمونه هر گروه را گزارش دهید تا گروه پرحجم، ضعف گروه کم‌تعداد اما حساس را پنهان نکند.