Perplexity Decider

אנו משחררים את Decider v1.3 ואת Decider Flash v1.3, היורשים של מודלי ההחלטה הקודמים שלנו: v1, v1.1, v1.2 ו-Flash v1.2.

Decider Flash v1.3 הוא מודל קטן יותר שזוקק מ-Decider v1.3. שני המודלים זמינים ב-Hugging Face תחת רישיון Apache, דרך OpenRouter ודרך Perplexity Decisions API.

Perplexity Decider שואב השראה מ-Jev, ה-System One Model של TypeSafe AI. הוא תומך בסיווג בינארי ורב-מחלקתי עם תוויות סדורות או לא סדורות, ומחזיר הסתברויות שיישומים יכולים להשתמש בהן כדי לסווג, לנתב, לדרג ולהעריך קלטים.

שני מודלי v1.3 משפרים את הביצועים ואת העמידות במגוון רחב של משימות טקסט וראייה ממוחשבת, באמצעות קשב דו-כיווני, נתוני אימון שנבחרו ועובדו בקפידה רבה יותר ומתכון אימון משופר. אנו גם מציגים את locate, תכונה חדשה להדגשת התוכן הנבחר במשימות של זיהוי ישויות בעלות שם, זיהוי מידע אישי ומענה חילוצי על שאלות.

בפוסט זה נסביר כיצד אנו מאמנים ומעריכים את Decider, ונשתף כיצד אנו משתמשים בו באופן פנימי ב-Perplexity.

מהו מודל החלטה?

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

• כן / לא: החלטות בינאריות.
• רב-ברירה: תוויות מותאמות אישית מרובות מחלקות.
• ציון: רמות מדורגות.

מודלי החלטה תומכים במגוון רחב של משימות סיווג ומתן ציונים:

• שיפוט פלטים: הערכת נאמנות, איכות ובטיחות.
• ניתוב: הפניית בקשות למודלים קטנים או גדולים יותר בהתאם לרמת הקושי.
• ניהול תוכן ואבטחה: זיהוי תוכן מזיק, פישינג והחדרת הנחיות (prompt injection) בפלטים של כלים.
• סינון ותיוג: ארגון אוספים גדולים של תוכן.
• אחזור ודירוג מחדש: מתן ציונים לתוצאות חיפוש לפי רלוונטיות.

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

אימון

הפיכת LLM גנרטיבי למודל החלטה

אנו בונים את Decider באמצעות התאמה של מודלי LLM גנרטיביים חזקים כמודלי בסיס. כדי להסביר את ההתאמה, נתאר תחילה כיצד בקשה מיוצגת. כפי שמוצג להלן, בקשה מורכבת מהקשר משותף (המצב) וממספר שאלות. כל השאלות יעשו שימוש חוזר במצב.

לדוגמה, בהינתן מסמך והסיכום שלו, בקשה אחת יכולה לשאול אם הסיכום מייצג נאמנה את המסמך והאם הוא מיועד למומחה או לקהל הרחב. אחרי המצב, כל בלוק שאלה מכיל שאלה ואת התשובות האפשריות לה, שלכל אחת מהן מוקצה טוקן תווית מוגדר מראש כמו A, B או C. טוקן מיוחד <|marker|> מציין מאיפה לקרוא את החיזוי של המודל. במיקום זה, שכבת פלט ליניארית נלמדת (ראש החלטה) ממפה את המצב החבוי לציונים עבור אפשרויות התשובה של השאלה, ואלה מומרים לאחר מכן להסתברויות.

הגדלה

אנו מאתחלים את שכבת הפלט ממודל הבסיס, שבדרך כלל נותנת ציון לטוקן הבא מתוך אוצר המילים כולו, ושומרים רק את השורות שמתאימות לטוקני האפשרויות המוגדרים מראש כמו A, B או C. לאחר מכן, השכבה המקוצצת הזו מאומנת להפוך את המצב החבוי של <|marker|> לציוני תשובה. גישה זו מכסה את כל שאלות הסיווג, מכיוון שאת כולן אפשר לנסח כשאלות רב-ברירה.

לצורך האימון, אנו לוקחים מאות מערכי נתונים ציבוריים המשתרעים על פני משימות מגוונות (סנטימנט, הסקה בשפה טבעית, זיהוי כוונה, התאמת ישויות, ניהול תוכן, בדיקת עובדות, דירוגים וכו') וממירים כל דוגמה לפורמט האחיד שתואר לעיל: מצב, שאלה אחת או יותר, האפשרויות שלהן ויעד. היעד יכול להיות האפשרות הנכונה היחידה אם יש לנו תוויות זהב (gold labels), או התפלגות הסתברויות על פני האפשרויות.

בגרסה v1.3 אנו מציגים את locate, שמחלץ טקסט מתוך המצב במקום לבחור מתוך אפשרויות מוגדרות מראש. שאלת locate מתארת מה יש למצוא, באמצעות תווית קצרה כמו "מיקום" או הוראה כמו "חלץ את שם העיר שבה ממוקמת המשרה." המודל מחזיר את הטקסט התואם המדויק מתוך המצב, יחד עם מיקומי התווים של תחילתו וסופו. אם הוא אינו מזהה התאמות, הוא מחזיר רשימה ריקה.

הגדלה

בזכות המצב המשותף, בקשה אחת יכולה לשלב שאלות locate, סיווג ומתן ציונים לגבי אותו קלט. לדוגמה, היא יכולה לשאול אם משרה דורשת ניסיון ברמה בכירה ולחלץ את המיומנויות הנדרשות.

קשב דו-כיווני: לאפשר למודל לקרוא בשני הכיוונים

המודלים שלנו מתבססים על שלדים (backbones) גנרטיביים חזקים שאומנו מראש, שהקשב הסיבתי שלהם מאפשר לכל טוקן לתת קשב רק לעצמו ולטוקנים שקודמים לו. מחקרי האבלציה שלנו הראו שהפיכת שכבות הקשב המלא של השלד לדו-כיווניות משפרת את הביצועים, ולכן אימצנו תכנון זה כדי לאפשר לכל טוקן לשלב הקשר מכל הקלט.

קשב דו-כיווני מציב בחירת תכנון נוספת: כיצד המצב והשאלות צריכים לקיים אינטראקציה? שקלנו שלושה דפוסי קשב, עם השלכות שונות על הביצועים, על יציבות התשובות ועל שימוש חוזר במטמון:

• הכול רואה הכול (v1.2): המצב וכל השאלות מעובדים יחד עם קשב דו-כיווני מלא. החישוב על המצב משותף, אך התשובה לשאלה אחת עשויה להשתנות בהתאם לשאלות האחרות שנשאלות.
• שאלות מבודדות (v1.3): המצב נותן קשב לכל השאלות, בעוד שכל שאלה נותנת קשב רק למצב ולטוקנים שלה. שאלות עדיין יכולות להשפיע זו על זו באופן עקיף דרך המצב המשותף, אך התוצאות יציבות יותר.
• ניתן לשמירה מלאה במטמון: המצב מפנה קשב רק לעצמו, בעוד שכל שאלה מפנה קשב למצב ולטוקנים שלה עצמה. המצב אינו תלוי בשאלות, וניתן לעשות בו שימוש חוזר בין בקשות כדי לנצל שמירת פרומפטים במטמון (prompt caching). איננו משתמשים בתצורה זו כברירת מחדל, משום שהיכולת של המצב לראות את השאלות חשובה מאוד במספר משימות, אך כוונון עדין קל יכול להעביר מודל לתצורה זו.

בסופו של דבר בחרנו בשאלות מבודדות בזכות הביצועים החזקים והיציבות שלהן.

הגדלה

מתכון האימון

האימון מתבצע בשלושה שלבים בשני גדלי המודלים. תחילה אנו מאמנים את המודל הגדול יותר, המבוסס על Qwen3.8-27B, באמצעות אנטרופיה צולבת (cross-entropy) על מערכי נתונים גדולים, ולאחר מכן מזקקים אותו למודל הקטן יותר, Qwen3.5-4B.

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

לאחר שהמודל הכללי הזה מאומן, אנו מריצים שלב שני, מפורט יותר, באמצעות LoRA. הנתונים שבשימוש בשלב זה ממוקדים בתחומים ובמשימות ספציפיים. אנו מוסיפים נתונים בשלב השני ולא בראשון אם אנו מבחינים בשיפורים מצומצמים בלבד או בנסיגה מסוימת במשימות אחרות. אנו משתמשים ב-LoRA כדי להימנע מסטייה גדולה מדי מהמודל הכללי ומהסיכון לאבד ביצועים לטובת התאמה לתחומים הספציפיים האלה. המטרה היא לשפר את הביצועים תוך שמירה על הידע הכללי של מודל הבסיס. אנו גם משתמשים במשקל בעת מיזוג ה-LoRA בחזרה לתוך מודל הבסיס, כדי לשלוט בסטייה בצורה מדויקת יותר ולהעדיף מדדים על נתונים מוחזקים (held-out) על פני שיפורים בתוך התחום.

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

בשני שלבי הטקסט אנו משתמשים בממוצע המשקלים משלוש הרצות, שבכל אחת מהן נעשה שימוש בזרע אקראי (random seed) שונה. גילינו שהדבר משפר את הביצועים ואת העמידות של המודל המאוחד.

לאחר שמתקבל המודל הגדול הסופי, אנו מיישמים את אותו הליך אימון תלת-שלבי על המודל הקטן יותר. כאן, המודל הגדול משמש כמורה: התפלגות הפלט החזויה שלו מחליפה את תוויות הזהב (gold labels), והמודל הקטן יותר מאומן למזער את סטיית KL בין התחזיות שלו לבין אלה של המורה. מטרת הזיקוק הזו עולה בביצועיה על אנטרופיה צולבת על אותם נתוני אימון. אנטרופיה צולבת אמנם מניבה ביצועים טובים יותר במבחני ביצועים (benchmarks) שיש להם נתוני אימון ייעודיים, אך היכולת שלה להכליל לנתונים מוחזקים (held-out) פחותה. אנו משערים שזיקוק מעביר טוב יותר את התפלגות הפלט של המורה, כולל רמת הביטחון שלו בחלופות שאינן תוויות הזהב, ואילו אנטרופיה צולבת מעודדת התאמת יתר להתפלגות האימון הספציפית למבחן הביצועים. לכן אנו מאמצים את מטרת הזיקוק מבוססת ה-KL.

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

הוספת היכולת לחלץ מידע

תכונת locate מחלצת מידע כמו ישויות בעלות שם מתוך טקסט, מבלי לשנות את האופן שבו היא עונה על בקשות רגילות. לשם כך אנו מוסיפים שלב אימון נוסף: אנו מוסיפים ל-Decider טוקן מיוחד חדש, <|locate|>, ראש span ומתאם LoRA.

אנו מאתחלים את ההטמעה של <|locate|> מתוך <|marker|> שנלמד בשלבי האימון הקודמים. אנו מאמנים רק את ההטמעה החדשה הזו, את ראש ה-span ואת מתאמי ה-LoRA, תוך שמירה על משקלי השלד המקוריים ועל ראש ההחלטה במצב מוקפא. כל שדה מבוקש מקבל טוקן <|locate|> משלו.

ראש המקטעים (span head) משתמש בייצוג של <|locate|> יחד עם הייצוגים של טוקני המצב כדי לתת ציון למיקומים שבהם מקטעים תואמים מתחילים ומסתיימים, ולזוגות של התחלה וסוף ששייכים זה לזה. הוא גם משתמש בייצוג של הטוקן <|locate|> כדי לחזות ספים ייעודיים לכל שדה עבור ציונים אלה. המקטעים שנבחרו מוחזרים כמיקומי תווים בטקסט המקורי.

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

אנו מאמנים על תמהיל של משימות חילוץ טווחים (span), כולל זיהוי ישויות בעלות שם, זיהוי PII ומענה חילוצי על שאלות. אנו מגוונים את תיאורי השדות מתוויות קצרות ועד הוראות מפורטות, כך שהמודל לומד למלא אחר הבקשה במקום לשנן קבוצת תוויות קבועה.

Locate מלמד את המודל משימה שונה מבחינה מבנית, ואנו רוצים להוסיף אותה בלי לאבד את מה שהמודל כבר עושה היטב. מיזוג מתאמי ה-locate לתוך מודל הבסיס גורם לנסיגה מסוימת בבקשות החלטה. כדי להגביל זאת, אנו עורכים בדיקות של גישות כמו נתוני חזרה (replay) נוספים משלבים קודמים ומטרות עזר ששומרות על פלטי המודל בבקשות החלטה קרובים לאלה של המודל המקורי. עם זאת, אנו מגלים שהמיזוג עדיין אינו נטול אובדן, ולכן אנו משאירים את המתאמים לא ממוזגים ומפעילים אותם רק עבור בקשות locate.

הערכה

אנו מעריכים את Decider v1.3 ואת Decider Flash v1.3 במבחני ביצועים חיצוניים מתוך Hugging Face Decision Index, ClaimBench של Vals AI ו-Artificial Analysis Decision Index.

בכל ההערכות האלה, המודלים שלנו מפגינים ביצועים חזקים. אף שטבלאות דירוג אלה כוללות משימות פרטיות, עדיין אפשר לתמרן אותן באמצעות הגשות חוזרות וכוונון איטרטיבי על סמך המשוב מטבלת הדירוג. כדי להשלים את טבלאות הדירוג האלה, אנו מעריכים את המודלים על חבילה פנימית המשלבת משימות ייצור פרטיות עם הערכות מוחזקות (held-out) שנלקחו ממערכי נתונים ציבוריים שאינם מבחני ביצועים. הערכות אלה מספקות בדיקה נוספת של יכולת ההכללה מעבר למבחני הביצועים הציבוריים, ומסייעות לנו להבחין בין שיפורים רחבים יותר לבין שיפורים שספציפיים לחבילות הערכה מוכרות.

בנינו באופן פנימי חבילה של למעלה מ-200 משימות המשתרעות על פני תחומים ומשימות שונים, כגון סיווג, מתן ציונים, דירוג מחדש וחילוץ ישויות. כדי להעריך בכנות את הביצועים של Decider בעולם האמיתי, כל ההערכות מבוצעות במצב zero-shot, ללא כוונון עדין ייעודי למשימה, וכך אנו מקבלים אינדיקציה ברורה לגבי היכן יש לשפר את המודל.

סיווג שאילתות

ב-Perplexity אנו משתמשים במערכת סיווג מרובת ראשים כדי לעבד כל שאילתת משתמש. כל שאילתה עוברת תחילה דרך מודל הטמעה (embedding) שמשמש כמחלץ תכונות. לאחר מכן ההטמעה שמתקבלת מוזנת למספר ראשי סיווג נפרדים, הכוללים מסווגים בינאריים ומסווגים מרובי תוויות. לדוגמה, ראש אחד קובע אם שאילתת משתמש צריכה להפעיל חיפוש באינטרנט.

ב-63 משימות סיווג עם תשובות ייחוס שתויגו מחדש באופן עצמאי על ידי LLM מוביל (frontier), Decider v1.3 משיג דיוק ממוצע של 91.6%, ועולה על מסווגי הייצור שלנו ב-6.54 נקודות אחוז. גם Decider Flash v1.3 עולה על מודל הייחוס של הייצור, ו-Decider v1.3 עולה על Jev 1.14.

הגדלה

סיווג ייעודי לתחום

הרכבנו חבילת הערכה ייעודית לתחומים מתוך מערכי נתונים ציבוריים, כדי להעריך את ביצועי הסיווג של מודלי החלטה בשבעה תחומים: אימות טענות (6 משימות), בריאות (7), אבטחת סייבר (8), תכנות (16), ממשל (7), משפט (9) ופיננסים (9).

לדוגמה, "שפוט את סיבוכיות הזמן של תוכנית Python", או "השתמש בדוח כספי שנתי כדי לקבוע אם המזומנים הבלתי מוגבלים של חברה מכסים את קרן החוב שמועד פירעונה בתוך שנים-עשר החודשים הבאים". Decider v1.3 מוביל בכל שבעת התחומים, ועולה על Jev 1.14 בעד 12.9 נקודות אחוז בפיננסים וב-9.3 נקודות במשפט. Decider Flash v1.3 מפגר אחרי Jev 1.14 בפיננסים, בתכנות ובמשפט, ומציג ביצועים דומים בתחומים האחרים.

הגדלה

אחזור ודירוג מחדש

החיפוש נמצא בלב Perplexity. אנו מתחזקים חבילה רחבה של משימות אחזור כדי להעריך את ביצועי הדירוג מחדש של המודלים שלנו. בכל משימה, אנו משתמשים תחילה במאגר של מודלי הטמעה כדי לאחזר את 50 המסמכים המועמדים המובילים מכל קורפוס. לאחר מכן אנו מדרגים מחדש את המועמדים האלה באמצעות Decider ומשווים את ביצועיו למודל ייחוס חזק לדירוג מחדש, Qwen3-Reranker-8B.

אנו מעריכים את Decider בתצורת zero-shot נקודתית (pointwise), ומשתמשים במודל כדי לתת ציון ישיר לכל זוג של שאילתה–מסמך באופן עצמאי ולדרג מסמכים לפי רלוונטיות. ב-72 משימות אחזור, Decider v1.3 משיג nDCG@10 ממוצע של 83.99, ועולה על Qwen3-Reranker-8B ב-1.81 נקודות ועל Jev 1.14 ב-2.24 נקודות.

במדד הייחוס BEIR, שני המודלים עולים על Qwen3-Reranker-8B ב-8.78 וב-7.05 נקודות nDCG@10, בהתאמה. בהשוואה ל-Jev 1.14, Decider v1.3 גבוה ב-1.33 נקודות, בעוד שגרסת Flash משיגה ציון נמוך ב-0.4.

הגדלה

סיווג רב-לשוני

כדי להעריך מודלי החלטה מעבר לאנגלית, הרכבנו מדד ייחוס (benchmark) לסיווג רב-לשוני הכולל 19 משימות ייעודיות לשפה מתוך 8 מערכי נתונים ציבוריים, עם 46,484 דוגמאות בשמונה שפות: גרמנית, ספרדית, צרפתית, איטלקית, רוסית, יפנית, קוריאנית וסינית. מדד הייחוס מכסה זיהוי כוונה, סיווג נושאים, ניתוח סנטימנט, הסקה בשפה טבעית, זיהוי פרפרזות, זיהוי שפה פוגענית ותקינות דקדוקית.

אנו מדווחים על דיוק ממוצע על פני המשימות בכל שפה, כשלכל משימה משקל שווה. Decider v1.3 עולה על Jev 1.14 בכל שמונה השפות, ו-Decider Flash v1.3 עושה זאת בשש מהן, עם דיוק משימה ממוצע של 88.16% ב-Decider v1.3 ו-86.50% ב-Decider Flash v1.3, לעומת 85.41% ב-Jev 1.14.

הגדלה

NER, PII ומענה חילוצי על שאלות

אנו מעריכים את תכונת locate על 17 משימות מחוץ לתחום (out-of-domain) שבודקות את יכולת החילוץ שלה במגוון תחומים, פורמטים של קלט (טקסט, טבלאות, מסמכים מובנים) והוראות (תוויות קצרות, שאלות ותיאורים מפורטים). התחומים נעים מוויקיפדיה ועד מאמרים מדעיים, דוחות על איומי סייבר, תמיכה טכנית, מדיניות פרטיות, קורות חיים וחוזים משפטיים. הבקשות נעות משמות תוויות קצרים כמו "אדם" או "כתובת אימייל", דרך שאלות על טבלה או על פנייה לתמיכה, ועד תיאורי שדות מפורטים לחילוץ מובנה, כמו הצדדים להסכם סודיות (NDA) או הסכום הכולל בחשבונית.

אנו מעריכים NER ו-PII באמצעות F1 של מקטע מדויק (exact-span F1), שדורש שהמקטעים החזויים יתאימו בדיוק לגבולות של הייחוס. מענה מחלץ על שאלות (Extractive QA) משתמש ב-F1 ברמת התו, שמעניק ניקוד חלקי על חפיפה בטקסט התשובה, ואילו חילוץ מובנה משתמש בדיוק שדות – שיעור השדות שחולצו נכון. לניתוח קורות חיים, אנו מחשבים את הממוצע של ציוני ה-exact-span F1 של NER ושל PII.

אנו משווים את המודלים שלנו למודלי חילוץ כלליים בגדלים שונים: GLiNER large v2.5 (0.5B), Liquid d1 (2B) ו-Clairic של Cloudflare (גודל לא פורסם). Decider v1.3 מגיע לציון ממוצע של 69.0 (לפי המדד העיקרי של כל משימה) ו-Decider Flash v1.3 מגיע ל-63.6, לעומת 43.3 ב-Liquid d1, 41.5 ב-Clairic ו-33.6 ב-GLiNER large v2.5. שני מודלי Decider מובילים בכל קטגוריה.

הגדלה

סיווג תמונות

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

Decider v1.3 משיג דיוק ממוצע של 76.99% בחמש המשימות החזותיות, ועולה על Jev 1.14 ב-1.47 נקודות אחוז. Decider Flash v1.3 משיג 72.77%, מה שמדגים יכולות סיווג חזותי במודל קטן יותר.

הגדלה

בקשות החלטה מהעולם האמיתי

דגמנו מיליון בקשות ללא כפילויות ועם מיסוך PII, שנשלחו אל Perplexity Decision API במהלך 18 הימים הראשונים לזמינותו. מכיוון שכל בקשה יכולה להכיל מספר שאלות על אותו מצב, המדגם כולל 2,318,887 שאלות בודדות. כל הבקשות נכללו בהרשאה מפורשת של המשתמשים לצורכי מחקר.

בקשות בסביבת הייצור אינן מגיעות עם תוויות אמת (ground truth), ולכן אנו משתמשים במודלי LLM מובילים (frontier) כשופטים כדי ליצור תשובות ייחוס ולמדוד את מידת ההסכמה של כל מודל איתן. אנו גם מקבצים את הבקשות ל-10 קטגוריות משימה, כולל חילוץ מידע, סיווג תחום, ניתוח סנטימנט, כוונה וניתוב, דירוג רלוונטיות, ניהול תוכן (מודרציה), בדיקת איכות ותאימות, התאמת ישויות, ניתוח עסקי וקטגוריית "אחר". פילוח זה מראה כיצד הביצועים משתנים בין תרחישי שימוש מהעולם האמיתי.

תמהיל המשימות אינו אחיד: חילוץ מידע מהווה 425,402 שאלות, סיווג תחום 409,564 וניתוח סנטימנט 344,158. יחד, שלוש הקטגוריות האלה מהוות 50.8% מהשאלות שנדגמו.

Decider v1.3 משיג את רמת ההסכמה הגבוהה ביותר עם השופטים, 93.98%, לעומת 93.68% ב-Decider v1.2 ו-93.35% ב-Jev 1.14. Decider v1.3 ו-Jev 1.14 צמודים זה לזה בסיווג תחום ובניתוח סנטימנט, עם פערים של 0.34 ו-0.07 נקודות אחוז, בהתאמה. Jev מוביל ב-0.69 נקודות בדירוג רלוונטיות, בעוד ש-Decider v1.3 מוביל ב-0.93 נקודות בחילוץ מידע (המשימה הנפוצה ביותר במדגם) וב-1.21 נקודות בכוונה וניתוב.

הגדלה

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

הגדלה

עמידות

הערכנו את הרגישות לתוויות על 372 שאלות רב-ברירה, עם 4,788 בקשות לכל מודל. שינינו את סדר האפשרויות, הקצינו מחדש תוויות לטקסטים של התשובות ושינינו את שמות התוויות תוך שמירה על משמעות כל שאלה, ולאחר מכן בדקנו אם התשובה הסמנטית של המודל השתנתה. שיעורי היפוך נמוכים יותר מצביעים על יציבות גבוהה יותר.

Decider v1.3 שינה את תשובתו ב-0.27% בלבד מהשאלות תחת כל טרנספורמציה, לעומת 2.69–4.84% ב-Jev 1.14. כמו כן חזרנו על קלטים זהים כדי למדוד את השונות בהגשת המודל: ב-Decider v1.3 לא נצפו שינויים, בעוד ש-Jev 1.14 שינה את תשובתו ב-1.88% מהשאלות.

הגדלה

כיצד אנו משתמשים ב-Decider

Decider נבנה עבור תהליכי עבודה שדורשים החלטות מהירות ומובנות. בחלק זה נבחן כיצד למנף אותם כדי להשפיע באופן משמעותי על הדרך שבה אנו עובדים. הנה כמה מהם שבלטו.

כללי אבטחה שמשפרים את עצמם

כבר כעת אנו משתמשים ב-Decider באופן פנימי כדי לשפר את מדיניות האבטחה שלנו.

הפעילות של הסוכנים שלנו מתועדת, ומבוצעת סדרה של בדיקות מבוססות כללים כדי לזהות כל התנהגות בעייתית. גישה מבוססת כללים מאפשרת לנו לנטר את הסוכנים שלנו בזמן אמת, בתוספת זמן השהיה זניחה. במצב לא מקוון, אנו משתמשים ב-Decider כדי לבחון דגימות מיומני הסוכנים המתועדים האלה. במקרה שלא סומנה התנהגות בעייתית, Decider בודק אם יש משהו שמערכת הכללים שלנו החמיצה; ובמקרה שהופעלה התראה, Decider בודק אם מדובר בהתראת שווא. כל רשומה שבה מערכת הכללים שלנו נכשלת באחד מהמקרים נשלחת לסוכן לצורך מיון (triage), ומוצע תיקון לכללים, שטעון אישור של חבר בצוות האבטחה שלנו.

ביום אחד, Decider קרא מיליארד טוקנים ב-7,000 הפעלות של סוכנים וזיהה פגמים שהובילו ל-14 תיקוני כללים, ש-6 מהם אושרו והושקו תוך יומיים. בהרצה חוזרת על יומנים של שבוע, התיקונים הפחיתו ב-52% את הנפח של הכלל העמוס ביותר שלנו, והכללים המורחבים תפסו כ-40% יותר פעולות לגיטימיות לחקירה.

הגדלה

ניטור הרצות RL

כשאנו מבצעים אימון המשך (post-training) למודלים באמצעות למידת חיזוק, מדדים מצרפיים כמו תגמול סופי אינם מסבירים מדוע הרצה (rollout – ניסיון בודד לבצע משימה) הצליחה או נכשלה. הרצה עלולה לאבד תגמול שלא בצדק משום ששירות כלי או ארגז החול נכשלו, או לקבל תגמול שאינו מגיע לה אם המעריך מתעלם מטענה שאינה נתמכת, כמו ערך מומצא שאף כלי לא החזיר.

אנו משתמשים ב-Decider כדי לנטר הרצות במקרים אלה. תחילה, קוד מזהה חלקים בהרצה שמצדיקים בדיקה מעמיקה יותר: קריאה לכלי שנכשלה וההנמקה שסביבה, קוד שרץ ללא שגיאות, או התשובה הסופית. לאחר מכן Decider עונה על שאלות רב-ברירה לגבי כל חלק, כמו מה נכשל בשלב מסוים (שירות כלי, אתר חיצוני, ארגז החול, ה-harness או הקוד של הסוכן עצמו) והאם הסוכן פירש את התוצאה נכון. אנו מאגדים את כל השאלות על חלק נתון בבקשה אחת ושומרים את ההסתברויות במקום פסק דין, כך שנוכל לכוונן ספים בהמשך מבלי לשלוח שוב שאילתות ל-Decider. המנטר רק צופה ומאבחן: הוא לעולם אינו משנה תגמול ואינו עוצר הרצה.

הגדלה

סינון דפים לפי איכות

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

בעזרת Decider, אנו יכולים לשפוט את איכותם של דפים כבר בזמן הסריקה שלהם. באותו מעבר קדימה (forward pass), אנו מבצעים שורה של משימות סיווג נוספות, כמו זיהוי התחום וקהל היעד של התוכן, ובדיקה אם הוא מכיל מידע מזיק, בלתי חוקי או מידע מזהה אישי. בהשוואה לשימוש ב-LLM כשופט, Decider מהיר וזול משמעותית.

הגדלה

מעבר לשימושים פנימיים אלה, Decider מתאים גם לתהליכי עבודה כמו אלה שלהלן.

מענה על שאלות חזותיות

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

הגדלה

ניווט בדפדפן

סוכנים יכולים להשתמש ב-Decider עבור ההחלטות הקטנות שבתוך משימות גדולות יותר. סוכן דפדפן יכול לשלוח צילום מסך בכל שלב ולקבל מידע מפורט על מצב הדף ועל התוצאה הצפויה של כל פעולה אפשרית.

הגדלה

תכנון משימות מחקר

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

הגדלה

תחילת העבודה

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

אנו ממליצים להשתמש ב-Decider v1.3 לשיפוטים מורכבים, למחוונים מפורטים ולתהליכי עבודה שבהם לטעויות יש מחיר גבוה. בחרו ב-Decider Flash v1.3 לניתוב, לתיוג ולסינון בהיקפים גדולים, כאשר זמן ההשהיה והעלות הם האילוצים העיקריים. העריכו את שני המודלים על דוגמאות מייצגות מעומס העבודה שלכם, ולאחר מכן בחרו את המודל שעומד בדרישות האיכות, זמן ההשהיה והתקציב שלכם.

שני המודלים זמינים כמשקלים להורדה ב-Hugging Face תחת רישיון Apache, דרך OpenRouter ודרך Perplexity Decisions API.

ציטוט

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}