Liquid AI מציגה את d1: החלטות מובנות במקום תשובות בצ'אט
מודלי d1 של Liquid AI מחזירים החלטה מובנית במעבר חישובי יחיד. נתוני המהירות מבטיחים, אך שימוש מקומי בעברית דורש בדיקות עצמאיות.
לא כל משימה עסקית צריכה תשובה מנוסחת: לפעמים המערכת נדרשת רק לבחור לאיזו מחלקה להעביר פנייה או לאיזה מסלול בדיקה להפנות תמונה. ב־7 באוקטובר 2026 שחררה Liquid AI את d1-3B ואת d1-omni-600M, מודלים פתוחי־משקולות שמחזירים החלטה מובנית במעבר חישובי יחיד. עבור מפתחים בישראל, זו הזדמנות לבחון חלופה ממוקדת לצ'אטבוט במשימות סיווג מקומיות, בלי להניח מראש שהיא מדויקת בעברית.
מה הושק: החלטה בלי לנסח תשובה טוקן אחר טוקן
לפי ההכרזה, d1-3B מקבל טקסט ותמונות. d1-omni-600M, המוגדר ניסיוני, מקבל טקסט עם תמונה או עם אודיו. ההבחנה חשובה: לא מדובר בהכרזה על שני מוצרים זהים, וגם לא בהבטחה שמודל האודיו כבר מתאים לפריסה תפעולית. יש להתאים את הבדיקה לסוג הקלט ולבשלות של כל מודל.
החידוש המרכזי הוא באופן הפקת התוצאה. במקום לייצר תשובה ברצף, טוקן אחר טוקן, המודלים מחזירים החלטה מובנית במעבר חישובי יחיד. עבור תוכנה שצריכה לפעול על סמך קטגוריה או מסלול טיפול, תשובה כזו עשויה להתאים יותר מפסקת הסבר. עם זאת, מבנה הפלט כשלעצמו אינו מוכיח שהבחירה נכונה.
גם משקולות פתוחות אינן אישור גורף לכל שימוש. הן מאפשרות לבחון הרצה בשליטת הארגון, אך לפני שילוב במוצר צריך לבדוק בנפרד את הרישיון, סביבת ההרצה ודרישות החומרה. פרטי ההכרזה שבתחקיר אינם מספיקים כדי להסיק מה תהיה עלות ההפעלה אצל עסק מסוים או אילו התאמות יידרשו למערכת קיימת.
נתוני המהירות: מבטיחים, אבל אינם מדידה מקצה לקצה
Liquid AI מדווחת על 8 מילישניות לשאלה ב־RTX 4090 ועל 50 מילישניות ב־Jetson Orin Nano. אלו נתוני החברה בתנאי הבדיקה שלה, לא תוצאות של אימות עצמאי. הם מצביעים על כיוון מעניין למשימות שבהן זמן תגובה קצר חשוב, אך אין להעתיק אותם ישירות לתחזית הביצועים של יישום אחר.
זמן חישוב של מודל אינו בהכרח זמן התגובה שהמשתמש יראה. בבדיקה מקומית צריך למדוד גם הכנת קלט, העברת נתונים, המתנה בתור ועיבוד התוצאה, לצד הדיוק במשימה עצמה.
ההבחנה הזו משמעותית במיוחד בקלט מולטימודלי. מערכת שמקבלת תמונה עשויה להזדקק לעיבוד מקדים, ומערכת שמקבלת אודיו צריכה להגדיר איזה קטע נשלח לבדיקה ומתי. בלי לדעת מה נכלל במדידה ומה נשאר מחוצה לה, מספר בודד במילישניות אינו מספיק לתכנון שירות. גם השוואה בין מערכות צריכה להשתמש באותו קלט ובאותה משימה.
לצד המהירות צריך למדוד את מחיר הטעות. ניתוב מהיר למחלקה הלא נכונה עלול ליצור עבודה חוזרת, ועיכוב קטן עשוי להיות מוצדק אם הוא מונע טעות יקרה. השאלה המחקרית המעניינת אינה רק כמה מהר התקבלה החלטה, אלא איזה דיוק נשמר במהירות הזאת ובאילו תנאים הוא נשחק.
ההקשר המחקרי: לא כל סיווג צריך מודל שמנהל שיחה
סיווג אינו משימה חדשה, ומודלי d1 אינם מייתרים אוטומטית מסווגים מסורתיים או מערכות חוקים. הערך האפשרי שלהם נמצא בחיבור בין קלט כמו טקסט ותמונה לבין החלטה מובנית, בלי שלב של ניסוח תשובה חופשית. כדי להראות יתרון, צריך להשוות אותם לפתרון הפשוט ביותר שכבר מסוגל לבצע את המשימה.
אם המערכת צריכה לבחור תור טיפול, צריך לבחון את איכות הבחירה, לא את איכות הניסוח.
למשל, אם כל הפניות הנוגעות לחשבוניות מזוהות היטב באמצעות חוקים קיימים, אין טעם להחליף אותם רק משום שמודל חדש זמין. לעומת זאת, פנייה שבה התמונה משנה את משמעות הטקסט היא מקרה מתאים לבדיקת הערך של קלט מולטימודלי. זו השערת שימוש לבדיקה, לא יכולת שהוכחה בתחקיר עבור תחום עסקי מסוים.
הוויתור על תשובה חופשית גם מחדד את הגבולות: מי שצריך לנסח מכתב ללקוח, להסביר אבחנה או לנהל בירור מתמשך עדיין זקוק לרכיב שמתאים לכך. אפשר לשקול הפרדה בין רכיב שמנתב לבין רכיב שמנסח, אבל אז יש לבחון את המערכת המשולבת, ולא לייחס לה אוטומטית את מהירות רכיב ההחלטה.
למה זה רלוונטי בישראל: עברית, פרטיות ומחשוב מקומי
תרחיש ישראלי אפשרי הוא מוקד שירות שמקבל הודעות בעברית לצד תמונות של מוצרים. במקום לבקש מצ'אטבוט להסביר כל פנייה, אפשר לבדוק אם מודל החלטה מתאים לבחירת מסלול טיפול. אלא שבתחקיר אין תוצאות על עברית, ולכן אין בסיס להניח שביצועים בשפה אחרת יישמרו בהודעות קצרות, בסלנג או בשילוב עברית ואנגלית.
לניסוי כזה כדאי לבנות מערך בדיקה מתוך פניות מייצגות, לאחר טיפול מתאים במידע אישי. חשוב לכלול לא רק מקרים קלים, אלא גם הודעות עמומות, תמונות באיכות נמוכה ופניות שעוסקות בכמה נושאים. אחרת, תוצאה טובה במבחן עלולה לשקף אוסף דוגמאות נוח מדי, ולא התאמה לעבודה היומיומית.
הרצה מקומית יכולה לאפשר עיבוד בלי לשלוח את הקלט לשירות חיצוני, אם כך בנויה המערכת. זהו שיקול מעשי לעסק שמטפל במידע רגיש, אך לא תחליף לאבטחה: עדיין צריך לבדוק הרשאות, רישום לוגים, גיבויים ורכיבי תוכנה נלווים. מיקום המודל אינו מבטיח לבדו שהמידע נשאר מוגן.
מה הלאה: מבחן השוואתי לפני אוטומציה
לפני פריסה, כדאי לבדוק אם d1 משפר תהליך מוגדר, ולא אם הוא מרשים בהדגמה. ניסוי ראשוני יכול לפעול לצד המערכת הקיימת, בלי שהחלטותיו יפעילו פעולות אצל לקוחות. כך אפשר להשוות בין הבחירות שלו לבין החלטות מאומתות ולזהות סוגי שגיאות חוזרים.
- להגדיר משימה וקטגוריות ברורות, כולל דרך טיפול במקרים שאינם מתאימים לאף קטגוריה.
- להשוות לחוקים או למסווג הקיים על אותן דוגמאות, ולא רק למודל שמנסח תשובות.
- למדוד דיוק בכל קטגוריה ואת עלות הטעויות, לצד זמן תגובה מקצה לקצה תחת עומס מייצג.
- לבדוק בנפרד עברית, קלט מעורב ותמונות או אודיו, בהתאם למודל שנבחר.
- לקבוע באילו מקרים נדרשת בדיקה אנושית ואיך חוזרים לתהליך הקודם אם הביצועים נפגעים.
התרומה המעניינת של Liquid AI היא הצעה ממוקדת: להשתמש במודל כדי להחזיר החלטה, לא בהכרח כדי לכתוב. עבור צוותים בישראל זו סיבה טובה לניסוי השוואתי מקומי. ההכרזה ונתוני החברה עדיין אינם מוכיחים עליונות בעברית או התאמה לכל תהליך, וההכרעה צריכה להישען על איכות ההחלטות בתנאי העבודה האמיתיים.
שאלות נפוצות
מה ההבדל בין מודלי d1 של Liquid AI לצ'אטבוט?
מודלי d1 נועדו להחזיר החלטה מובנית במעבר חישובי יחיד, במקום לנסח תשובה טוקן אחר טוקן. הם רלוונטיים למשימות כמו סיווג וניתוב, אך אינם תחליף לצ'אטבוט כאשר צריך לכתוב הסבר או לנהל שיחה.
האם אפשר להריץ את d1 מקומית ולסווג פניות בעברית?
המודלים פתוחי־משקולות ומאפשרים לבחון הרצה מקומית. התחקיר אינו מספק תוצאות על עברית, ולכן יש לבדוק דיוק על פניות אמיתיות, לרבות שגיאות כתיב ושילוב עברית ואנגלית, לפני שימוש תפעולי.
כמה מהירים מודלי d1 של Liquid AI?
Liquid AI מדווחת על 8 מילישניות לשאלה ב־RTX 4090 ועל 50 מילישניות ב־Jetson Orin Nano בתנאי הבדיקה שלה. אלה אינם נתוני בדיקה עצמאית או הבטחה לזמן התגובה של מערכת שלמה בעומס עבודה אחר.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות