سرویس تصمیم‌گیری محلی لایا اکنون از طریق دروازه در دسترس است

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

چه کاری انجام می‌دهد

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

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

دو راه برای فراخوانی

نقطه پایانی بومی، که شکل خود لایا است:

curl https://ai.layercloud.ir/v1/systemone \
  -H "Authorization: Bearer $LAYERCLOUD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "این ماه دو بار از من شارژ شد و کسی پاسخ نداد",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "این مورد به کدام تیم مربوط است؟",
        "criteria": ["billing", "technical", "other"]
      }
    }
  }'

نقطه پایانی سازگار با OpenAI، اگر کد شما از پیش با آن کار می‌کند:

curl https://ai.layercloud.ir/v1/chat/completions \
  -H "Authorization: Bearer $LAYERCLOUD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "laya",
    "messages": [{"role": "user", "content": "{\"state\": \"دو بار شارژ شدم\", \"questions\": {\"department\": {\"type\": \"choice\", \"instructions\": \"کدام تیم؟\", \"criteria\": [\"billing\", \"technical\"]}}}"}]
  }'

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

دسترسی

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

دو نکته پیش از اتکا به آن

مقادیر اطمینان کالیبره نشده‌اند. مقدار 0.98 به معنای «۹۸٪ احتمال درستی» نیست. این اعداد را به‌عنوان امتیاز نسبی میان گزینه‌هایی که داده‌اید در نظر بگیرید و caveat پاسخ را بخوانید.

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

سه نوع پرسش

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

choice یک برچسب از فهرستی که خودتان می‌دهید انتخاب می‌کند. برای مسیریابی و دسته‌بندی مناسب است.

{"department": {"type": "choice",
                "instructions": "این مورد به کدام تیم مربوط است؟",
                "criteria": ["billing", "technical", "sales", "other"]}}

score متن را با سطوحی که توصیف می‌کنید می‌سنجد، به ترتیب، از کم به زیاد. برای هر داوری‌ای که به شدت یا کیفیت نیاز دارد - نه به دسته - مناسب است.

{"urgency": {"type": "score",
             "instructions": "این مورد چقدر فوری است؟",
             "criteria": ["قابل تأخیر", "باید امروز رسیدگی شود", "سرویس از کار افتاده"]}}

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

{"is_feedback": {"type": "noul", "instructions": "آیا این بازخورد محصول است و نه درخواست؟"}}

پاسخ چه شکلی است

{
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": {"billing": 0.9867, "technical": 0.0081, "sales": 0.0026, "other": 0.0026},
      "confidence": 0.9277
    }
  },
  "routing": {"model": "english", "reason": "English Latin text"},
  "confidence_calibrated": false,
  "caveat": "..."
}

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

شرکت‌ها چگونه می‌توانند از آن استفاده کنند

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

مسیریابی پشتیبانی. پیش از آنکه کسی تیکت را باز کند، آن را به صف درست بفرستید و بگذارید نوع noul مواردی را علامت بزند که در هیچ دسته‌ای نمی‌گنجند - که معمولاً جالب‌ترین‌ها هستند. امتیازهای اطمینان اجازه می‌دهند ۸۰٪ آسان را خودکار کنید و بقیه را به انسان بسپارید، به‌جای آنکه کل جریان را هم‌سختی فرض کنید.

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

پالایش محتوا. یک گزارش را با دسته‌های سیاست خودتان بسنجید، نه با «سمّی / غیرسمّی» عمومی. چون برچسب‌ها را شما می‌دهید، خروجی با قواعدی که تیم‌تان واقعاً اجرا می‌کند هم‌خوان است و استدلال آن قابل بازبینی است.

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

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

برای چه کاری ساخته نشده

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

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

هزینه و حریم خصوصی

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

چقدر سریع است

دو عدد مهم است و هر کدام به سخت‌افزار متفاوتی تعلق دارد.

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

عدد منتشرشدهٔ خود مدل کمتر از ۳۵ میلی‌ثانیه است، اندازه‌گیری‌شده روی یک GPU مدل T4 توسط سازندگانش. این همان مدل روی سخت‌افزار متفاوت است؛ GPU جای درست اجرای یک گذر رو به جلوست.

آنچه خود دروازه هزینه دارد حدود ۲۵ میلی‌ثانیه است. فراخوانی مستقیم سرویس ۱۰۳۸ میلی‌ثانیه است و فراخوانی از طریق دروازه ۱۰۶۲ میلی‌ثانیه. یعنی مسیریابی، احراز هویت، ثبت مصرف و لایهٔ سازگار با OpenAI روی هم حدود ۲۵ میلی‌ثانیه اضافه می‌کنند. زمان مربوط به مدل و سخت‌افزار است، نه به زیرساخت اتصال.

این را دقیق می‌گوییم چون تعیین می‌کند چه انتظاری داشته باشید: اگر می‌خواهید بدانید یک تیکت پشتیبانی به کدام تیم برود، یک ثانیه در برابر زمانی که یک انسان صرف باز کردن آن می‌کند چیزی نیست. و اگر عدد ۳۵ میلی‌ثانیه را می‌خواهید، آن بحث GPU است.

تماشا کنید

این‌ها توضیح‌دهنده‌های مستقل خانوادهٔ مدل‌های لایا هستند (ساختهٔ دیگران، نه ما). لینک می‌دهیم چون این فناوری را بهتر و سریع‌تر از یک صفحهٔ متن دیگر توضیح می‌دهند، نه به این دلیل که محتوای خود ماست.

• Laya: Open-Source Counterpart to Jev | Multilingual — Mohamed Naji Aboo
• Laya: Non-Autoregressive Decision Model with RL — Cold Boot
• Jev and Laya Explained: Decision Models vs LLMs — TerraNet Technologies LLC
• Jev vs Laya: Closed or Open AI Decision Model? — Join dev

اگر منبع اصلی را می‌خواهید و نه ویدیو، سایت خود پروژه laya.convaiinnovations.com است و وزن‌های مدل به‌صورت باز روی Hugging Face منتشر شده‌اند.

یک نکته را هنگام تماشا در نظر بگیرید. آن ویدیوها دربارهٔ خود مدل‌اند. آنچه ما اجرا می‌کنیم همان مدل است، اما پشت دروازهٔ خودمان، روی پردازنده، با ورودی سازگار با OpenAI و همان کلید API شما. «چه چیزی» یکسان است؛ «کجا» نه.