پرسش‌ها (پریمیتیوها) › مستندات Jev

Choice choice

انتخاب یک گزینه از مجموعه‌ای تعریف‌شده؛ همراه با احتمال هر گزینه و اطمینان.

آخرین به‌روزرسانی: مدل: jev-1.13.0 منبع بازبینی‌شده در منبع انگلیسی

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

ساختار درخواست

type"choice"الزامی

همیشه "choice".

instructionsstring | object | arrayالزامی

پرسشی که مدل پاسخ می‌دهد.

criteriamap<string, string | object | array | null>الزامی

گزینه‌ها به‌صورت نگاشت: هر کلید نام گزینه و هر مقدار توصیف آن. وقتی گزینه به توضیح نیاز ندارد null بگذارید. حداکثر ۲۵۵ گزینه.

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

ساختار پاسخ

  • choice: گزینه‌ای با بیشترین احتمال.
  • probabilities: توزیع کامل احتمال روی همه‌ی گزینه‌ها؛ مجموع مقادیر ۱ است.
  • confidence: عددی بین ۰ و ۱ که از پراکندگی probabilities محاسبه می‌شود. توزیع تخت (احتمال پخش بین چند گزینه) یعنی اطمینان پایین؛ یک قله روی یک گزینه یعنی اطمینان بالا.

این تیکت ساده است، پس همه‌ی احتمال روی returns است و اطمینان ۱٫۰. تیکتی که هم به سایز اشتباه و هم به بازپرداخت از دست‌رفته اشاره کند احتمال را بین returns و billing تقسیم می‌کند و اطمینان پایین می‌آید.

روش خوب: در هر فراخوانی بیش از یک پرسش

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

یک مثال پیچیده‌تر

تیکتی مبهم‌تر که به سه تیم مربوط است و نمی‌گوید مشتری چه می‌خواهد، با پنج پرسش Choice. دو پرسش گمانه‌زنانه‌اند: return_reason فقط اگر بخش returns باشد و shipping_issue فقط اگر shipping باشد اهمیت دارد. پرسش tone توصیف‌های null دارد چون نام گزینه‌ها گویاست.

در پاسخ ثبت‌شده‌ی مستندات رسمی، department برابر returns با احتمال ۰٫۶۱ است اما billing به‌خاطر شارژ دوباره ۰٫۳۵ گرفته و اطمینان ۰٫۴۲ است؛ requested_resolution با اطمینان ۰٫۲۰ به سمت refund متمایل است. بنابراین کد تیکت را به تیم returns می‌دهد، نسخه‌ای برای billing می‌فرستد (۰٫۳۵ بیشتر از آستانه‌ی ۰٫۲۵) و از مشتری می‌پرسد چه می‌خواهد. یک درخواست، پنج پاسخ و منطق مسیریابی فقط چند if معمولی.

دستورالعمل و معیارهای ساختاریافته

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

نام فیلدهایی مثل question، focus، what، not_for و examples جزو API نیستند و رزرو نشده‌اند؛ خودتان انتخابشان می‌کنید. مدل نام‌ها را همراه مقادیر می‌بیند، پس از نام‌های کوتاه و گویا استفاده کنید.