OpenJev را نباید صرفاً یک چت‌بات تازه یا نسخه رایگان هر سرویسی با نام Jev دانست. کاربرد اصلی آن تصمیمگیری ساختاریافته است: انتخاب یک گزینه، برآورد یک وضعیت یا امتیازدهی بر اساس متن. اگر مسئله شما مسیریابی درخواست‌هاست، این تفاوت مهم‌تر از مقایسه طول پاسخ یا توانایی نوشتن مقاله است.
در این راهنما، نوع مسئله مناسب، شکل ورودی، ارزیابی و محدودیت مجوز را بررسی می‌کنیم. نام OpenJev با شناسه‌هایی مانند typesafe/jev-1.13 یکسان نیست. همچنین انتشار این مقاله به معنی ارائه OpenJev در فهرست مدل‌های API پاستا نیست؛ برای استفاده، باید مدل و نوع endpoint واقعاً در حساب شما در دسترس باشند.
OpenJev دقیقاً چه مسئله‌ای را هدف می‌گیرد؟
در کارت رسمی OpenJev، ورودی به شکل وضعیت و مجموعه پرسش‌ها تعریف شده است. خروجی برای انتخاب، برآورد دودویی و امتیازدهی طراحی شده، نه تولید آزاد متن. endpoint نمونه آن /v1/systemone است؛ بنابراین نباید بدون بررسی، همان کلاینت Chat Completions را با یک نام مدل تازه به آن متصل کرد.
مثال مناسب، دسته‌بندی تیکت میان تیم مالی، فنی و ارسال است. مثال نامناسب، انتظار یک مقاله بلند یا گفتگوی عمومی از همان قرارداد تصمیم است. پیش از انتخاب مدل، خروجی موردنیاز را روی کاغذ بنویسید: یک شناسه دسته می‌خواهید، یک عدد می‌خواهید یا توضیح طبیعی برای کاربر؟ اگر این نیاز روشن نباشد، مقایسه مدل‌ها به چند پاسخ نمایشی محدود می‌شود.
تفاوت OpenJev، Jev و API قابل خرید
نام خانواده، وزن قابل دانلود، سرویس میزبانی‌شده و شناسه مدل در یک واسط API چهار مفهوم جدا هستند. ممکن است یک ارائهدهنده مدلی از خانواده Jev را عرضه کند، اما این به معنی یکسان‌بودن وزن، مجوز، قیمت، قرارداد درخواست یا امکانات آن با OpenJev نیست. نتیجه بنچمارک یکی را نیز نباید به دیگری نسبت داد.
برای خرید API، فهرست زنده مدل‌ها و مستندات همان ارائهدهنده معیار است. در پاستا، مدل قابل استفاده باید با کلید و endpoint پشتیبانی‌شده حساب شما سازگار باشد. برای زمینه بیشتر، راهنمای Jev را جدا مطالعه کنید. این مقاله درباره ارزیابی OpenJev است و وعده فعال‌بودن آن روی پاستا نمی‌دهد.
نکته مهم مجوز: وزن باز الزاماً تجاری نیست
کارت مدل هنگام بررسی در ۱۴ اکتبر ۲۰۲۶، مجوز CC-BY-NC-4.0 را اعلام می‌کند. بخش NonCommercial برای تصمیم استفاده تجاری مهم است. دانلود عمومی وزن‌ها را مجوز ارائه یک سرویس پولی یا استفاده آزاد در هر کسب‌وکار تلقی نکنید. نسخه مجوز و شرایط استفاده را پیش از استقرار دوباره بررسی کنید و برای کاربرد تجاری از صاحب حق، شرایط روشن بگیرید.
این موضوع فقط یک پاورقی نیست؛ باید پیش از صرف هزینه زیرساخت بررسی شود. اگر مجوز با کاربرد شما سازگار نیست، آزمون پژوهشی محدود و مسیر تولید را جدا نگه دارید. یک API تجاری جایگزین نیز شرایط خاص خود را دارد. این مقاله تفسیر حقوقی اختصاصی برای کسب‌وکار شما ارائه نمی‌کند.
نمونه ورودی برای مسیریابی تیکت
برای آزمون، از داده ساختگی شروع کنید. مثال زیر متن یک درخواست و دو تصمیم را کنار هم قرار می‌دهد. نام فیلدهای قرارداد را تغییر ندهید؛ از جمله noul در نمونه رسمی نوع خاص پرسش است و غلط املایی دلخواه در برنامه شما نیست. پیش از اتصال، قرارداد نسخه انتخابی را کنترل کنید.
{
"model": "openjev",
"state": "The customer was charged twice and asks for a refund.",
"questions": {
"team": {
"type": "choice",
"instructions": "Choose the team responsible for this request.",
"criteria": {
"billing": null,
"technical": null,
"shipping": null
}
},
"needs_review": {
"type": "noul",
"instructions": "Does this request concern a payment dispute?"
}
}
}این JSON یک نمونه قرارداد است، نه فرمان قابل ارسال به API پاستا. خروجی دقیق و ساختار احتمال‌ها را از سرویس انتخابی بخوانید و سپس parser بنویسید. روی برچسب شناخته‌شده، نوع مقدار و محدوده عددی اعتبارسنجی داشته باشید. پاسخ نامعتبر را به یک دسته پیش‌فرض حساس مثل «بازپرداخت خودکار» تبدیل نکنید.