Laya בהסבר: מודל החלטה שעונה בלי לכתוב אפילו טוקן אחד

הדבר המעניין ביותר ב-Laya אינו המהירות שלה. הוא שכל אפשרות שאתה מציע לה מקבלת ניקוד ב-[MASK] token של עצמה, וההסתברויות עוברות softmax על פני האפשרויות של השאלה האחת הזו. Convai Innovations פרסמה את המשקלים של Laya ב-Hugging Face ב-18 בספטמבר 2026, תחת Apache 2.0 — שלושה צ'קפוינטים, מאגר אחד, 421M פרמטרים למודל האנגלי. אין טוקנים של פלט. אין לולאת פענוח, אין JSON לנתח, אין סוגר מסולסל שאפשר לשכוח לסגור. אתה מוסר לו מצב וקבוצה של שאלות עם טיפוסים, ואחרי forward pass אחד אתה מקבל בחירה מבין אפשרויות בעלות שמות, ניקוד אורדינלי עם רמה צפויה, או הסתברות שטענה היא נכונה. לעיצוב הזה יש תוצאה שאנשים מפספסים: מכיוון שמרחב התשובות נבנה לכל בקשה בנפרד במקום להיות מוטמע לתוך ראש אוצר מילים, סכמה שאתה ממציא אחר הצהריים הזה אינה מצריכה אימון מחדש. יש לזה גם גבול, והפרויקט מציין אותו במפורש בכרטיס המודל שלו: הצ'קפוינטים הבסיסיים משיגים 0.362 בבנצ'מרק typed-decisions, לעומת 0.318 בניחוש אקראי ו-0.461 בתשובה תמיד למחלקת הרוב. המשפט של Convai עצמה הוא זה שכדאי לשמור בראש — "Laya היא בסיס מהיר להתמחות, לא מנוע החלטות zero-shot." נקודת ההשוואה הברורה היא Jev של TypeSafe AI, מודל System One מתארח בלי משקלים מפורסמים, בלי מספר פרמטרים מפורסם ובלי מודל בסיס מפורסם. Laya היא התשובה עם משקלים פתוחים לכך. האם התשובה הזו מועילה לך תלוי כמעט לחלוטין באיזה חצי של ה-pipeline אתה מנסה להחליף.

מה Laya באמת היא, ומה היא לא

התחילו מהשלילי, כי שם רוב המאמרים טועים. Laya אינו LLM. הוא אינו אוטורגרסיבי: מעבר קדימה בודד מפיק את התשובה, והמודל לעולם אינו פולט טקסט. השוואה של זמן השהיה שלו לטוקנים לשנייה של מודל צ׳אט היא השוואה בין שתי פעולות שונות — האחת מסווגת, והאחרת מייצרת. אם אתם צריכים פסקה, סיכום, תוכנית או שרשרת חשיבה, Laya לא יכול לספק לכם דבר כזה ואינו מנסה לעשות זאת.

מה זה: מקודד דו-כיווני עם ראש החלטה המחובר מעליו. הצ'קפוינט האנגלי הוא ModernBERT-large — 395M פרמטרים, מכוונן במלואו — בתוספת ראש שאומן מאפס, המורכב משתי שכבות טרנספורמר, מנקד סמני אפשרות, וראש act/escalate, בסך הכל 421M. הצ'קפוינט הרב-לשוני מחליף את השלד ב-mmBERT-base, 22 שכבות ואוצר מילים של 256k, בסך הכל 322M. שלושה צ'קפוינטים מגיעים במאגר אחד, ורק זה שאתה מבקש מורד:

• convaiinnovations/laya — ModernBERT-large, 421M פרמטרים, חלון הקשר של 512 טוקנים, אנגלית, כ-808 MB בדיסק.

• convaiinnovations/laya-multilingual — mmBERT-base, 322 מיליון פרמטרים, הקשר של 1,024 טוקנים (המקודד תומך בעד 8,192 עם RoPE), יותר מ-100 שפות, מהיר בערך פי 2.2, כ-647 MB.

• convaiinnovations/laya-typed-decisions — ModernBERT-large, 421M פרמטרים, חלון הקשר של 1,024 טוקנים, והיחיד מבין השלושה שנושא את הנתון 0.766 שתראו מצוטט בכל מקום.

Router יושב מלפנים ובוחר את הצ'קפוינט לכל בקשה על ידי זיהוי כתב ושפה בפחות מחצי מילישנייה, בפייתון טהור, לפני שמתרחש מעבר קדימה כלשהו. זו אינה תכונת נוחות. זו תכונת נכונות, והראיות של הפרויקט עצמו מראות מדוע: צ'קפוינט האנגלית משיגה דיוק של 0.000 בחמר בעודה מדווחת על ביטחון של 0.952. מודל שנשאר בטוח בעודו טועה לחלוטין הוא בדיוק המקרה שבו סינון לפי ביטחון לא יכול להציל אותך, ולכן החלטת הניתוב חייבת להתקבל לפני שהמודל רואה את הקלט. לאורך סריקה של 51 שפות, הראוטר הפך 45 מתוך 51 שפות לשמישות — שמוגדר כעולה על פי שלושה מהאקראי — לעומת 23 מתוך 51 עבור צ'קפוינט האנגלית בלבד.

העובדה העיצובית שכדאי להבין: טוקן [MASK] אחד לכל אפשרות

אם תקח דבר אחד מהמאמר הזה, קח את זה. בראש סיווג רגיל, קבוצת התוויות קבועה בזמן האימון: לשכבה האחרונה יש פלט אחד לכל מחלקה, והוספת מחלקה משמעה אימון מחדש. Laya לא עושה זאת. היא מציגה כל אפשרות כטקסט עם סמן, והמעריך של סמן-האפשרות קורא ציון ממיקום ה-[MASK] של אותה אפשרות עצמה. לאחר מכן הוא מבצע softmax על פני האפשרויות השייכות לשאלה הזו.

מרחב התשובות מוגדר אפוא בזמן הבקשה. אתה כותב את האפשרויות, והמודל מדרג אותן. סכימה חדשה אינה זקוקה לאימון מחדש ולא לכוונון עדין, מכיוון שאין דבר במשקלות שמקודד "חיוב" או "טכני" כמחלקה — רק המנגנון להשוואה בין אפשרות מרונדרת אחת לאחרת בהקשר של המצב.

שני תקציבים קובעים עד כמה זה עובד היטב, והם משותפים. כל רצף מתפצל לתקציב פרומפט אפשרויות (head_max_len, 192 אסימונים בנקודת הבדיקה האנגלית ו-256 בשתי האחרות) ותקציב מסמך (מה שנשאר מ-max_len). כל שאלה בקריאה נענית באותו מעבר קדימה בודד, כך שקריאה עם שש שאלות אינה שש הפעלות מודל. אבל אפשרויות חולקות את תקציב האפשרויות, ולכן שאלה עם 77 אפשרויות כמו Banking77 מקצה בערך שלושה עד ארבעה אסימונים לכל תווית והדיוק צונח בחדות — 0.425 לעומת 0.870 שפורסם על ידי Jev. התיקון מתועד ולא מוסתר: העלו את head_max_len וגם max_len, או פצלו קבוצת אפשרויות גדולה לבחירה דו-שלבית מגס לדק.

שלושת הפרימיטיבים

כל מה ש־Laya עושה הוא אחד משלושה סוגי שאלות, וכל אחד מהם מחזיר צורה שונה:

• בחירה — הסתברות לכל אפשרות בעלת שם, בתוספת התווית המובילה ורמת ביטחון. זהו הפרימיטיב לניתוב ולסיווג כוונות.

• ציון — התפלגות על פני מחוון סדור בתוספת רמה צפויה. זהו הפרימיטיב הסודרי: דחיפות, תסכול, חומרה.

• noul — הסתברות מכוילת לכך שטענה נכונה, מ-0.0 עד 1.0. פישינג, סיכון נטישה, הזרקת פרומפט.

הטיפוסים קפדניים באופן שמשנה מבחינה תפעולית. שאלת בחירה לא יכולה להחזיר אפשרות שלא סיפקת, כי האפשרויות היחידות שהיא יכולה לתת להן ניקוד הן אלו שהצגת. זה מסיר מחלקה שלמה של כשלי ייצור — ערך ה-enum המומצא, ה-JSON הקטוע, לולאת הניסיונות החוזרים סביב מפרסר. זה לא מסיר שגיאה סמנטית. מודל שמחזיר billing: 0.94 עבור פנייה שהייתה אמורה לעבור לתמיכה טכנית הוא שגוי, והוא שגוי בביטחון. פלט מטופּס מבטיח את צורת התשובה, ולעולם לא את נכונותה.

RLCD, או למה ההסתברויות אמורות לומר משהו

רוב המסווגים מאומנים להיות צודקים. Laya מאומן להיות כנה לגבי עד כמה הוא צודק, ומתכון האימון הוא המקור לכך.

השיטה נקראת RLCD — למידת חיזוק להחלטות מכוילות. המדיניות מפיקה התפלגות ולא argmax; החקר מוסיף רעש גאוסי בעל תוחלת אפס ללוגיטים; והתגמול הוא כלל ניקוד strictly proper — log ועוד spherical, עם ranked probability score שנוסף עבור שאלות אורדינליות. המילה "proper" היא זו שעושה את העבודה. כלל ניקוד strictly proper מגיע למקסימום בתוחלת רק על ידי דיווח אמונותיך האמיתיות, לכן הסתייגות או הצהרת יתר מאבדות תגמול מכוח הבנייה ולא מכוח הוראה. העדכונים הם REINFORCE עם baseline של ממוצע קבוצתי, בסגנון GRPO, ושיחות רב-תוריות משתמשות ב-TD(λ=1.0) על פני פרוסות prefix.

ההשלכה המעשית היא שסף ביטחון הוא דבר שמוצדק לבנות עליו לוגיקת יישום — טענה שאי אפשר להשמיע לגבי softmax של מסווג שאומן באמצעות אנטרופיה צולבת. זוהי גם טענה עם הסתייגות שהפרויקט גלוי לגביה: נקודות הבדיקה המסופקות הן בעלות ביטחון יתר, ואתם אמורים לבצע התאמה מחדש של טמפרטורה על הנתונים שלכם לפני שתסמכו על המספרים. התאמה מחדש של טמפרטורה אחת לכל סוג שאלה ולכל מספר אפשרויות הזיזה את ECE הממוצע מ-0.466 ל-0.081 בנקודת הבדיקה האנגלית ומ-0.314 ל-0.106 בזו הרב-לשונית. סף ההתחלה המוצע של הפרויקט לאישור אוטומטי לעומת סקירה אנושית הוא בסביבות 0.85.

כמה עולה להפעיל

נתוני השהיה הם של הפרויקט עצמו, שנמדדו על Tesla T4, כאשר כל Checkpoint עונה על שאלות זהות ברמת הבתים באותה הרצה:

• שאלה אחת — 39.5 ms על laya, 32.8 ms על laya-multilingual.

• חמש שאלות — 84.5 מ״ש ו-40.1 מ״ש.

• עשר שאלות במקבץ — 158.6 מ״ש (15.9 מ״ש לשאלה) ו-72.3 מ״ש (7.2 מ״ש לשאלה).

• חמישים שאלות — 771 ms ו־337 ms, או 6.8 ms לשאלה בצ׳קפוינט הרב־לשוני.

• תפוקה באצוות על T4 בודד — 103 עד 332 שאלות בשנייה.

אם ראיתם טענה כמו „מהיר פי 50 מ-Jev” שמסתובבת, זה לא המספר של הפרויקט, והבנצ'מרק של הפרויקט עצמו אינו תומך בה. ההשוואה שפרסמה Convai היא פי 7.8 בהשהיית p50 עבור שאלה אחת: 32.8 ms מול 236–276 ms. זו גם ההשוואה שכדאי לקרוא בקפידה, מפני שהכרטיס של Laya מתייג את הצד של Jev כנתונים מפורסמים של צד שלישי שאותם Convai מעולם לא מדדה — אין לה גישה ל-TypeSafe API — ומפני שהיא מעמידה מעבר קדימה על GPU מקומי מול קריאת API מתארחת הכוללת סבב רשת ותורים. החלק הארכיטקטוני בפער הזה אמיתי. החלק התשתיתי בו אינו תכונה של המודל.

מבחינת זיכרון, טביעת הרגל היא כמה מאות מגה-בייט לכל צ'קפוינט, וכדאי להכיר את טבלת הפריסה לפני שקובעים גודל מארח. ברירת המחדל העצלה מחזיקה שני צ'קפוינטים בזיכרון (אנגלית ורב-לשונית, היחידים שהנתב בוחר ביניהם אוטומטית), כך שלאחר הטעינה הראשונה של כל שפה, החלפה עולה זיהוי בלבד.Router(max_loaded=1) במכונה עם זיכרון מוגבל מבצע טעינה מחדש בכל החלפת שפה, נמדד בחציון של 7.4 שניות ב-CPU ו-10.3 שניות ב-T4.Router(preload=True) היא תצורת השרת: שום דבר לא נטען מחדש, וזמן השהיה לכל בקשה הוא הנתון של 32.8 ms ב-GPU או 193–464 ms ב-CPU.

החצי הכנה

כאן היצירה מצדיקה את עצמה, מפני שהמשטח סביב Laya רועש והמגבלות ספציפיות.

ראשית, מספר הכותרת הוא מספר מכוונן. הדיוק 0.766 שייך ל-laya-typed-decisions, נקודת ביקורת שעברה כיוונון עדין על פיצול האימון של אותו בנצ'מרק עצמו. נקודות הביקורת הבסיסיות משיגות 0.362 ו-0.342 ב-zero-shot מול בסיס אקראי של 0.318 ובסיס של רוב-המחלקה של 0.461 — כלומר, מתחת לבסיס הטריוויאלי. הפרויקט אומר זאת בעצמו ברשימת המגבלות שלו במקום לקבור את זה, ונקודת הביקורת המכווננת עוברת את תקרת ההסכמה העצמית של המורה (teacher self-agreement) של 0.735, וזו תוצאה חזקה באמת עבור מקודד (encoder) של 421M על ארבע זרימות עבודה צרות (עיבוד חשבוניות 0.804, תק"אירועי אבטחה 0.766, שירות לקוחות 0.764, ניטור עקבות סוכנים 0.730). אבל זו תוצאה על התמחות, לא על המודל הבסיסי, וכל מי שמצטט 0.766 כיכולת כללית מפרש שלא כראוי את הכרטיס.

שנית, הפרימיטיבים אינם טובים באותה מידה. לפי דיוק בנקודת הביקורת שעברה כיוונון עדין: noul 0.857, choice 0.733, score 0.723. הפרויקט מכנה את score האורדינלי "הפרימיטיב החלש ביותר" מפורשות, עם SST-5 ב-0.372. אם משטח ההחלטה שלך הוא דירוג חומרה של 1 עד 5, זהו הפרימיטיב שיש לך הכי פחות סיבה לסמוך עליו כברירת מחדל.

שלישית, שתי התנהגויות מתועדות כבאגים במעקב הבעיות של הפרויקט עצמו, ושתיהן ישרפו אותך בפרודקשן אם לא תקרא אותן. action.act_probability לא נושא אות שמיש עדיין — issue #185 — כי הפלט של ה-decision head אינו מנורמל בערך פי 300 מהסקאלה של ה-encoder, מה שמרווה את ה-act head כך שהוא קורא 1.0 כמעט לכל קלט. ה-logits הגולמיים שלו מתנגדים לנכונות, עם AUROC של 0.30 על 396 החלטות מתויגות. הסתמך על confidence במקום, שמגיע ל-AUROC של 0.77 על אותם פריטים. בנפרד, noul יכול לעקוב אחר תוויות האפשרות שלו במקום ה-state — issue #156 — כי render_options מקבע את התוויות של noul אל false: / true:, וזוג התוויות הזה יכול להשתלט על התשובה, ולהחזיר "no" בטוח עבור קלט חיובי בבירור. הפתרון המתועד הוא לשאול את אותה שאלה בתור דו-אפשרי choice עם מפתחות ניטרליים והניסוח של כן/לא שלך בתור התיאורים.

רביעית, פרט כיול שקל להחמיץ וראוי לציין במדויק. ה-checkpoint מגיע עם טמפרטורה מותאמת של 0.1006 עבור דלי choice:11+, והטוען מצמיד כל טמפרטורה לטווח [0.5, 5.0]. ההצמדה הזו עושה לך טובה. טמפרטורה חדה כל כך עלולה לקחת התפלגות מפוצלת באמת ולדווח עליה כוודאות כמעט מוחלטת; ההצמדה פירושה שהמקרה הגרוע ביותר הוא תשובה רכה יותר ממה שההתאמה התכוונה, והטוען פולט אזהרה שמציינת את הדלי המושפע ומורה לך להתייחס לרמת הביטחון הזו כלא מכוילת. קרא את האזהרות בעת הטעינה במקום לדכא אותן.

חמישית, אנגלית בלבד בשורש הריפו, ואופן הכשל מחוץ לאנגלית אינו חינני — מכאן הראוטר, ומכאן ההמלצה להשתמש בlaya-multilingual לכל דבר שאינו פרוזה באנגלית.

התמונה הבלתי־תלויה, ככל שהיא קיימת, צרה יותר מתמונת הספק ואינה סותרת אותה. השוואה ראש בראש בלתי־תלויה — sysone-bench, 751 מצבים על פני תשע סוויטות, מתאריך 2026-09-21, שהורצה על קלטים זהים ברמת הבתים, כאשר גיבובי השאלות אומתו כזהים לפני ההשוואה — מציבה את Jev ביתרון בטריאז', במעקות בטיחות, במודרציה, ב-banking77 ובכוונת רב־לשונית, ואת Laya ביתרון ב-AG News (0.940 לעומת 0.910) וב-MNLI (0.983 לעומת 0.867). תוצאת הסינון לפי רמת ביטחון שלה היא זו שסביבה הייתי מתכנן בפועל: סינון ברמת ביטחון 0.85 שמר 58% מהתעבורה של Laya בדיוק של 0.878, לעומת 78% מהתעבורה של Jev בדיוק של 0.917. זו צורת הפשרה — Laya מבצעת אוטומציה של פחות מהתעבורה בדיוק נמוך יותר על החלק שהיא שומרת, והרצת הנתב שלה עצמה מעלה את כוונת רב־לשונית מ-0.360 ל-0.840.

המשטח שסביבו, שהוא רחב באופן יוצא דופן

עבור פרויקט שהמשקולות שלו בנות ימים ספורים, משטח האינטגרציה הוא החלק שמפתיע. כל זה נמצא במאגר ה-upstream ב-NandhaKishorM/laya, עם 19,871 כוכבים ב-GitHub בזמן כתיבת שורות אלה, והוא כולו Apache 2.0:

• laya-serve — שרת HTTP שחושף את ה-Router על אותו מבנה בקשה ותגובה של POST /v1/systemone כמו ה-Jev API המתארח של TypeSafe, כך שלקוח TypeSafe קיים עובר על ידי שינוי כתובת ה-base URL שלו. שימו לב בכנות לברירת המחדל האבטחתית: הוא מאזין על 0.0.0.0 ללא אימות אלא אם LAYA_API_KEY מוגדר, ואז הוא דורש טוקן bearer. קיימת גרסה מחוזקת של מודול NixOS שפועלת תחת יחידת systemd של DynamicUser ומעבירה את הטוקן דרך LoadCredential במקום לשים אותו ב-store.

• הסבה מלאה ל-TypeScript בתוך laya-ts/ עבור Node והדפדפן, בנוסף לנתיב סוכן ONNX (laya.onnx_agent.ONNXAgent) להרצת מודל מיוצא על ONNX Runtime ללא PyTorch בזמן ריצה.

• שרת MCP מאחורי הרחבה אופציונלית, החושף את laya_predict, laya_route, laya_preset וגם laya_status ככלים.

• אינטגרציות עם LangChain ו-LangGraph — LayaRouter לניתוב קשתות מותנות עם סף ביטחון ומנגנון גיבוי, ו-LayaGuardrail.

• Nix flake עם nix run .#laya-serve ומודול services.laya-serve, ארבעה קובצי Compose, נתיב לתמונת Docker עם התחלה מהירה מתועדת, ומחברת Kaggle שמריצה את לולאת הכוונון העדין המלאה של RLCD על 2xT4 GPUs חינמיים בארבע עד חמש שעות על פני כ-30 אלף שאלות.

Apache 2.0 הוא פרט הרישיון שמכריע אם תוכל לשלב זאת בתוך מוצר: הוא מתיר שימוש מסחרי, שינוי והפצה מחדש, והוא אינו מחייב אותך לפרסם את השינויים שלך או את המשקולות שעברו כוונון עדין. החובה היא חובת הייחוס ושימור ההודעות הרגילה, בתוספת היעדרם המפורש של מענק פטנט או סימן מסחר מעבר למה שהרישיון מציין. עבור שכבת החלטה שיושבת לפני תעבורת לקוחות, זו הצעה שונה מהותית מנקודת קצה מתארחת בגישת גישה מוקדמת, שהמשקולות, הארכיטקטורה ומתכון האימון שלה אינם גלויים כלל — וזה מה ש-Jev הוא היום, ב-$0.042 למיליון טוקני קלט כשהפלט בחינם ומשטח קלט טקסטואלי בלבד.

איפה זה בעצם משתלב: ראש החלטה מלפנים, ו-LLM מנותב מאחור

התבנית ששווה להפנים אינה "מודל החלטה במקום LLM". זהו צינור דו-שלבי, וכל שלב קיים מפני שהשלב האחר גרוע במשהו.

שימו את Laya בחזית עבור השיפוט בהיקף גבוה, צר ומיועד לצריכה על ידי מכונה: לנתב את הפנייה, לסווג את הכוונה, לתת ציון לדחיפות, להחליט אם המסמך הזה רלוונטי לשאילתה, לבדוק אם הטיוטה הזו מפרה מדיניות. לקריאות האלה יש סט תשובות קבוע, הן מתרחשות אלפי פעמים בשעה, ומעבר קדימה מקומי של 33 אלפיות שנייה עם אפס טוקנים בפלט מתאים להן יותר מסבב גנרטיבי. לאחר מכן הציבו מודל גנרטיבי מאחוריו עבור הקריאות שבאמת זקוקות לפרוזה, לסינתזה או להסקה על הקשר ארוך — הניסוח, ההסבר, סיכום ההסלמה.

זה המקום שבו יושב OrcaRouter, וכדאי להיות מדויקים לגבי הגבול. אנחנו לא משרתים את Laya; זהו מקודד של 421M שאתם מריצים בעצמכם, וכל הנקודה בו היא שהוא רץ במקום שבו הנתונים שלכם כבר נמצאים. גם את Jev אנחנו לא משרתים — זהו נקודת קצה בגישה מוקדמת של TypeSafe. מה שאנחנו מכסים הוא החצי הגנרטיבי של אותו צינור: למעלה מ-200 מודלים מאחורי מפתח אחד תואם OpenAI, ב-מחיר המחירון של הספק, מועבר הלאה עם 0% תוספת, עם failover אוטומטי בין ספקים. הסיבה המעשית שזה חשוב כאן היא התפר בין שני החצאים. ברגע שאתם מתחילים לנתב החלטות למודל גנרטיבי עבור המקרים שראש ההחלטה דחה, יש לכם אינטגרציה שנייה, חשבון שני ומצב כשל שני. מפתח אחד לצד הגנרציה, עם failover אם ספק נחלש, משמעו שמסלול ההסלמה של שכבת ההחלטה הוא שינוי תצורה ולא קשר עם ספק שני. זו טענה קטנה, והיא הנכונה.

מי צריך לאמץ אותו, ומי צריך לחכות

אמץ את Laya עכשיו אם יש לך נתונים מתויגים ולולאת אימון, ומשטח החלטה יציב מספיק כדי שיהיה שווה להתמחות בו. מחברת ה-Kaggle קיימת בדיוק כדי ששלב הכיוונון העדין לא יהיה פרויקט מחקרי, נקודות הביקורת הבסיסיות נטענות תוך כשתי שניות על CPU, והרישיון מאפשר לך להפיץ את התוצאה מסחרית בלי לפרסם את המשקלים שלך. עומסי העבודה המתאימים ביותר הם אלה שהפרויקט כבר בחן: מיון פניות, עיבוד חשבוניות, סיווג אירועי אבטחה, מעקות בטיחות ומודרציה, וניטור עקבות סוכנים. שמור על שאלות בחירה מתחת ל-20 אפשרויות בערך, כייל טמפרטורה על נתוני ההחזקה שלך לפני שאתה מגדיר סף בפרודקשן, והפעל שער לפי confidence, אף פעם לא לפי act_probability.

המתן אם ההחלטה שלך צריכה להיות נכונה מיד מהקופסה ללא נתונים מתויגים. צ'קפוינט בסיסי שנמצא מתחת לקו הבסיס של מחלקת הרוב בבנצ'מרק שהוא פורסם מולו אינו מנוע zero-shot, והקריאה הכנה של המספרים של הספק מול גורמים בלתי תלויים היא ש-API החלטות מתארח שמנוהל היטב הוא כיום בחירת ה-zero-shot החזקה יותר. המתן גם אם קבוצות האפשרויות שלך גדולות ואתה לא מוכן לכוונן את תקציב הראש, אם הניקוד הסדורי שלך צריך להיות אמין באופן מיידי, או אם אתה צריך קלט של תמונה, אודיו או מסמך ארוך — Laya היא טקסט בלבד ותקציב ההקשר שלה הוא 512 עד 1,024 טוקנים כברירת מחדל, שזה מבחר ראיות ולא מסמך שלם.

הדבר שיכריע את הקטגוריה הזו אינו מספרי השהיה, שכבר טובים מספיק כדי להפסיק לשמש כטיעון. זה האם מודל קטן שמדווח הסתברויות כנות על משטח החלטה שהגדרת, ושאותו אפשר לאמן מחדש על התוויות שלך, מנצח קריאה למודל גנרטיבי גדול ופענוח הפלט שלו. Laya היא ניסיון רציני ראשון ואמין לגרסת המשקלים הפתוחים של השאלה הזו — והיא בת ימים לכל היותר, וזו הדרך הנכונה לקרוא את כל מה שלמעלה. ה-Base הוא נקודת ההתחלה, לא המוצר.