YUV.AI - בינה מלאכותית בעברית

אני בהלם של החיים מהיכולות של טקסט לדיבור במודל החדש של ElevenLabs. יצרתי פודקאסט של דקה, אני ומורגן פרימן על Vibe Coding. בעברית. מטקסט. עם שיבוט קולי של שנינו. מרגיש ששנים של ציפייה הגיעו לקיצן - זה *מטורף*!! יצרתי את זה בעורך הטקסט לדיבור תוך שימוש במודל החדש v3 של ElevenLabs עם מנוי בתשלום (של 5 דולר בחודש). אין לי מילים!

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

הלילה דפקתי את הראש על פיתוח שרת MCP כי לנגרף החליטו שסוכני AI יכולים להשתמש בשרתי MCP מבוססי Streamable HTTP בלבד, אבל למה ומה זה אומר? כשאנחנו מפתחים שרת MCP (או משתמשים בשרת קיים של מישהו אחר), אנחנו יכולים להגדיר את הדרך שבה הלקוח (הסוכן, קלוד, קרסר וכדומה) יתקשר עם שרת ה-MCP. יש 3 צורות תקשורת: 1. תקשורת מקומית עם stdio - המחשב שלנו מריץ את שרת ה-MCP והתקשורת מתבצעת באופן מקומי 2. תקשורת עם sse - במקרה כזה שרת ה-MCP שלנו לא נמצא מקומית אצלנו אלא מתארח במיקום מרוחק וזמין דרך האינטרנט. השרת מקבל מהלקוח 2 פניות, אחת כדי ליצור את החיבור ולשמור אותו פתוח, והשנייה כדי לשלוח משימות לביצוע לשרת ה-MCP 3. תקשורת עם Streamable HTTP - מה זה אומר? כמו סעיף 2. שרת שמתארח בצורה מרוחקת ואפשר לפנות אליו על גבי האינטרנט. רק שכאן יש חידוש: מספיק לשלוח בקשה אחת והתקשורת נשארת פתוחה לניהול הבקשות ולביצוע המשימות לנגרף, חבילת יצירת הסוכנים ״המתקדמים״ מבית לנגצ׳יין החליטו לתמוך רק בתצורה 3, שנכנסה לתוקף מסוף מרץ בערך. הבעיה היא שכל שרתי ה-MCP הקיימים עובדים בתצורה 1-2, ולכן צריך למצוא שרתים זמינים מסוג 3 או לפתח לבד, כפי שאני ניסיתי הלילה עוד מסתבר, שהתקשורת בשרתי MCP, יותר נכון המידע שמועבר בין הלקוח לשרת, עובד אחרת מ-REST API. הוא משתמש ב-JSON-RPC בגרסא 2, שמה שזה אומר - מעבירים את הפרמטרים דרך אובייקט JSON ושם מציינים איזה פעולה להריץ, ערכים שמועברים וכדומה. שרתי stream עוזרים לנו לעבוד טוב יותר בזמן אמת. כמו צ׳אט שמשיב לנו בזמן אמת אות אחר אות, או מודל קולי שמדברים איתו והוא הופך כל מילה לקובץ שמע ומנגן אותה בזמן אמת (במקום שנחכה שכל הטקסט יהפוך לאודיו). זה מאוד שימושי, אנחנו מתקדמים גם בזה. את כל זה למדתי לעומק הלילה והייתי מוכרח לשתף כי זה יכול לעשות סדר לכולם - בעולם שכולו מבולגן. מעתה אמרו - לפתח שרתי MCP עם Streamable HTTP ופריסה שלהם בענן - זה הדיבור! וזה מה שמאפשר לפתח סוכן על שזמין דרך לנגרף, שמנהל תקשורת בין סוכנים בתצורת A2A, והם עצמם מחזיקים כלים שהם שרתי MCP מרוחקים. שמחתי לבלגן, לעשות סדר בבלאגן, ולנסות להשאיר מסודר יותר.

באמצע פגישה עם לקוח מחו״ל ראינו ש-GPT נפל היום. לאחר מכן באמצע פגישה נוספת - אזעקה. כמה זה סמלי. GPT שנפל הרגיש עבורם בערך כמו אזעקות אצלנו. להבדיל. כל מדינה ״והצרות״ שלה. רציתי לשתף קצת מהנעשה אצלי בימים אלה. אני עסוק בפיתוח מוצר ללקוח מחו״ל, בהרצאות ובסדנאות, בכנס שלי ובייעוץ למספר ארגונים - ובנוסף בהפקת הכנס שלי בסוף יוני. בשל כך אני לא מצליח להשתלט על הפניות ועל התיוגים ועל התגובות - וחשוב לי מאוד להתנצל בפני מי שאני לא מספיק להשיב לו / לה. אני באמת משתדל להקדיש זמן למענה לפניות. אני גם עובד על לוגאן, שיהיה זמין לכל פונה ויהיה העוזר שלי בפועל, יוכל להמליץ על חיבורים לאנשים מוכשרים שאני ממליץ עליהם אישית, להשיב על שאלות לפי ידע שאני מזין לתוכו מהניסיון שלי, ואפילו לקחת פניות כשצריך. אני חלילה לא מתעלם, לא מסנן, לא מתחמק, זה הכל נטו מחוסר יכולת להגיע לכל הודעה בזמן אמת. אם לא הגבתי בזמן סביר תרגישו בנוח להקפיץ. לגבי הפיתוח ללקוח מחו״ל זה מאוד מעניין. זה התחיל מזה שהוא שכר בית תוכנה, המשיך דרך זה שהוא רוצה אותי במקום בית התוכנה, ומכאן זה באמת נעשה מעניין: הקמנו ״סיירת״. מנהל פרויקט שהוא גם מנהל מוצר וגם מאפיין חוויית משתמש וגם מעצב. דוקטורנט לבינה מלאכותית (למידת מכונה) ששותף ללוגיקת הסוכנים, מנהל תפעול, ועבדכם הנאמן. הלקוח התחיל עם Lovable, הקים אתר לעצמו. ראה כי טוב. קיבל הצעה יקרה פיצוצים מבית תוכנה ולוחות זמנים של 10 חודשים לביצוע. בשלב הזה עירב אותי, ביקש הערכה להפיכת המוצר שלו לאפליקציה אמיתית ברמת MVP, אמרתי לו באיזה כלים אני הייתי ממליץ להשתמש לתשתית, הוא אהב את הרעיון ואמר שההמלצות שלי הן יותר ממה שבית התוכנה נתן לו מזה חודשיים. החלטנו לשלב כוחות. מנהל המוצר בנה גם הוא פרוטוטייפ עם v0, לקח לו בערך 400 פרומפטים כדי להגיע לתוצר שהוא רצה. משם אני לקחתי את המושכות. פיתחתי אפליקציית NextJS ובעבודה מאומצת עם קרסר וקלוד סונט 4, הפכתי את v0 לאפליקציית פרונט מלאה, עם אותנטיקציה ודאטה בייס. דאגתי גם לפריסה על AWS ובסיס נתונים עם MongoDB Atlas. בשלב הזה הדוקטורנט החל ליצור Endpoints של הסוכנים שמבצעים מגוון פעולות, ואני צריך לשלב אותם בנקודות המפתח של האפליקציה. לשם כך הייתי צריך לנהל גם את כל נושא ה-JWT Token מול AWS API Gateway, להגדיר ״קהל״ ועוד כמה דברים. במקביל, אני גם עובר על הטיקטים של הלקוח, מתעדכנים באופן יומי בסלאק, בפגישות וידאו קצרות, אני עובר על הריג׳קטים ב-Miro ומתקן עם קרסר את ה-UI ואת ה-Backend. אם הכל יעבוד כמו שצריך, אנחנו כנראה נסיים את ה-MVP תוך רבעון אחד במקום 3 כפי שהוצע במקור. העניין הוא שזה אפשרי לא רק בגלל שיש AI. אמנם AI מאיץ תהליכים מאוד אבל ההילוך המהיר מתאפשר בגלל ש: - מנהל הפרויקט / מוצר ידע מה הוא רוצה לקבל ופיתח פרוטוטייפ מדויק לצרכיו - הוא גם מעצב ולכן הוא נותן הערות מפורטות ומדויקות שמאוד קל אח״כ לתקן זה מראה איזה תותח הוא וכמה ידע ואיך הוא שם לב לפרטים לאחר מכן אני והד״ר מדברים באותה שפה, הוא רץ ואני רץ, תוך שיש לנו הבנה של העומק, פותרים בעיות תוך כדי ריצה, ובעיקר שמים לב להמון דקויות ומצליחים להבין זה את זה בקלות דרך כמה הודעות בסלאק המסר שלי הוא שכיף שיש AI ובזכותו הפרויקט הזה ממש כיפי ומעניין ועוזר לדהור קדימה בקצב מסחרר, אבל האמת היא שזה לא מספיק. אם לא היינו סיירת שיודעת מה היא עושה - גם שנה לא הייתה מספיקה לנו. כך שזה שוב חוזר לנקודה, מבחינתי, זה לא הכלים, אלא הידע של מי שמפעיל אותם.

מכירים את זה שמתייגים מישהו במייל עם @ כדי שיגיב? אז הגדרתי טריגר לסוכן שלי, Logan, שעכשיו גם עוזר לי בזכות הסוכנים שהוא מפעיל! אני מתייג את לוגאן במייל ונותן לו הנחיה, כמו למשל - תבדוק זמינות, תקרא את השרשור ותציע תגובה, תייצר לי טיוטה להצעות מחיר מותאמות אישית, דוחות ביצוע על בסיס מיילים ופגישות. אבל איך זה עובד? בניתי סוכן על דרך LanGraph והגדרתי לו כלים, כל כלי הוא סוכן AI נפרד לאחר מכן עשיתי Deploy דרך AWS כך שהסוכן זמין דרך קריאת API רגילה עם טוקן אימות ברגע שהוא מאמת את הטוקן, הוא מנתח את הבקשה, מבין באיזה כלי עליו להשתמש, שזה אומר איזה סוכן הוא צריך להפעיל, עושה דלגציה לסוכן הרלוונטי. כל סוכן מכיל כלי, שהוא שרת MCP. ההפרדה בין הסוכנים הוגדרה לפי הפרדה בין משימות. הסיבה ליצירת מספר סוכנים היא כדי שאוכל לתקן ולשנות בצורה פרטנית כל סוכן מבלי לפגוע בכל הלוגיקה. כמו מיקרו-שירותים. אז כל סוכן יודע להפעיל כלי, ולהבין שעליו לעשות דלגציה לסוכן אחר אם המשימה כבר לא תחת אחריותו. זאת אומרת, נניח שיש סוכן שמטרתו לכתוב דוח שעות ללקוח, הוא יודע שתחום האחריות של חיפוש במייל ובלוח השנה הוא לא התחום שלו - אז הוא יודע שאם הבקשה הזו הגיעה אליו - הוא צריך להעביר אותה הלאה. כמו ניתוב רשתות. רק לאחר שהוא יקבל את המידע הדרוש, הוא ייגש למשימה וייצור את הדוח. כל סוכן זמין על פורט נפרד ויכול להטריג אחד את השני. כך מימשתי את תצורת Agent2Agent (A2A), והאמת שניסיתי שני כיוונים: הראשון הוא שכל סוכן יהיה זמין על פורט נפרד באותו שרת, השני הוא שכל סוכן הוא קריאת API Endpoint נפרדת. בסופו של דבר, אני פונה ללוגאן, הוא מעביר לסוכנים לביצוע המשימה, לפני שהמשימה הושלמה - סוכן נוסף מבקר את התוצר - ואם הכל בסדר הוא מעדכן בסטטוס את לוגאן - שמעדכן אותי. הטריגר ללוגאן מתבצע גם דרך המייל וכרגע גם דרך הטלגרם. דרך המייל - יש טריגר אוטומציה שבודק האם התקבל מייל חדש, אם כן - מתחיל התהליך של האוטומציה, מענה לפי מה שביקשתי וכו׳. דרך המייל - כי אז שומרים על קונטקסט של השרשור עצמו מתוך המייל. אני משווה בין n8n לבין make המון, ובכלל נוטה להגדיר את זה בעצמי, אם כי כרגע יותר קל ומהיר דרך make. זאת אומרת, יותר נוח לעבוד עם n8n אם רוצים לפתח גם את הסוכנים דרך שם, אבל אם יש כבר סוכן פרוס על כתובת, אני מעדיף כרגע את make. דרך הטלגרם - כי לפעמים אני רוצה לעבוד עם לוגאן על משימות אחרות וקל להתנהל דרך טלגרם עם בוטים. גם פה, יש טריגר שמופעל כי הבוט פרוס כשרת פייתון. מניח שאתם מנחשים לבד למה קראתי לו לוגאן, ואם לא אז סימן שאתם לא עוקבים אחרי מספיק 😂

שנתיים וחצי אחרי ההייפ: מה עלה בגורלם של סוכני ה-AI שכל כך הלהיבו את התעשייה? אני זוכר שכל כך התלהבתי לפתח סוכני AI ל-Slack. צוות שלהם שכולו סוכני AI. גברים ונשים. מפתחים, מתמללים, מעצבים גרפיים, מעצבי מוצר, משאבי אנוש, כותבי תוכן ואפילו שירות ותמיכה. צוות שלם שכולו זמין על ידי תיוג ב-Slack. בלי משכורת. בלי תן ביס. את הסוכנים בניתי בקלות עם LangChain. חבילת הפיתוח שפורסמה בשל יכולתה להוסיף שכבת הפשטה על LLMs ולאפשר למפתחים לפתח סוכני AI בקלות יתירה. כך היה אפשר לבנות סוכנים, להוסיף להם זיכרון, לתת להם כלים, ובצורה הפשוטה ביותר גם לתת זהות לכל סוכן באמצעות הגדרה פשוטה בהנחיית המערכת (System Prompt, החלק שגלוי ל-LLM ולמפתחים אך סמוי מעין המשתמש). מאז החלה מגמה אדירה: רצון לפתח סוכני AI שמאגר הידע שלהם הוא ידע ארגוני פנימי. למה? כדי להנגיש לעובדים, כדי להפוך מערכי לימוד לאינטראקטיביים יותר, בין אם זה Onboarding, LMS, Support, מענה על שאלות Confluence, ניהול טיקטים ב-JIRA, שימוש בהם בעולמות ה-Data Science למשימות סיווג (קלסיפיקציה), שיפוט, קבלת החלטות, אנליזות, כתיבת קוד, חישובים ואפילו כתיבת תוכן. המגמה הייתה ברורה. השוק הגיב. LangChain כבר לא הספיק. למה? כי הסתבר שהוא לא חסכוני במיוחד. ״סוכן AI״ היה קריאת API למודל שפה גדול, ואז התשובה שהתקבלה עברה שוב למודל שפה לקריאה נוספת יחד עם התשובה שהתקבלה זה הרגע, כך שעכשיו אנחנו משלמים כפול: גם השאלה והתשובה של הסבב הראשון, וגם הוספת שאלה ותשובה בסבב שני, וכך הלאה. מובן למה סוכן AI במעטפת LangChain לא חסכונית במיוחד. כמו LangChain צצו פתרונות נוספים, כמו קריאות ״רגילות״ למודלים של שפה אבל עם יכולת להפעיל כלים, Function Calling, וחבילות נוספות כמו LlamaIndex, ו-PyDantic AI, ו-Instructor, כולם התחרו על השוק. ואז השוק נתקל בבעיות אחרות: - איך גורמים ל-LLM לספק תשובות יציבות במשימות של סיווג? - איך מוודאים שה-LLM לא משיב עם הזיות? - איך שומרים על עלות סבירה של טוקנים בצורה לא בזבזנית מדי? - איך מבצעים השוואת ו/או הערכת ביצועים של סוכנים לפי פרומפטים או מודלים של שפה שונים? - איך פורסים / מטמיעים סוכנים ב-Production ועולים שלב מעבר לגימיק? - איך חוסכים קריאות מיותרות? - איך גורמים לסוכנים לעבוד ביחד כדי לנהל משימות ביחד? כדי לפתור את הבעיות האלה צצו המון כלים (איך לא). גוגל עם חבילת פיתוח משלה, ו-OpenAI עם חבילת פיתוח סוכנים משלה, מייקרוסופט עם AutoGen, ו-CrewAI, ו-HayStack, וכמובן LangChain שפתחו מבערים והשיקו לא פחות מ-5 מוצרים: מעקב אחר בזבזנות של סוכן עם LangSmith בענן או LangFuse כפיתרון לוקאלי פיתוח סוכנים ללא קוד עם LangFlow - מתאים ליצירת פרוטוטייפים מהירים פיתוח סוכנים ו-Orchestration ביניהם עם LanGraph - כלי מבוסס ״גרף״, הקשר, בין סוכנים, מה שיפה פה הוא שיש סוכן על שהוא מנתב את הבקשות ויש לו כלים, כל כלי הוא סוכן AI, וכל סוכן AI יכול לקבל כלי שהוא שרת MCP אחד או יותר (בתצורת Streamable HTTP) פיתוח סוכנים קבוצתיים ״ללא קוד״ עם Open Agent Platform אז מה עלה בגורל הסוכנים שאלתי? הבינו שהם לא מספיקים והחליטו לצייד אותם בכלים חזקים יותר, בצוותים חזקים יותר, ובעיקר הבינו ששילוב שלהם תחת סוכן על שמנהל ומנתב הכל - זה הכח האמיתי. המגמה דוהרת לשם. הם יתחזקו ויקבלו גוף פיזי בדמות מכשירים חכמים ואפילו רובוטיקה. וכמו שאמר מארק צוקרברג: יהיו יותר סוכני AI בעולם - מאשר בני אדם. ובהצלחה לנו ולאנושות!

האם ידעתם שיש פלטפורמה של לנגצ'יין בשם Open Agent Platform לבניית סוכני AI ללא קוד? מה שמעניין הוא שלכל אחד מסוכני ה-AI האלה אפשר להגדיר כלי שהוא כשלעצמו שרת MCP שעובד בתצורת STREAMABLE HTTP (ולא SSE או תצורה קיימת אחרת)? לא רק זה, יש גם סוכן על שיודע לאיזה סוכן לנתב את הבקשות! בואו נדבר על כל הטוב הזה בכמה דקות >>>

הפלטפורמה המדהימה הזו נקראת Tavus ועפתי עליה

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

אם עד עכשיו חשבנו שמזיזים למפתחים את הגבינה - לאחרונה שוחרר MCP SSE שטורף מחדש את כל הקלפים: בהגדרה פשוטה אפשר לתת ל-LLM כלים שמתחברים (כמעט) לכל מקור מידע *ומבצעים פעולות*, והכל בחיבור *מרוחק*! בא נעשה סדר בדברים כשאנחנו רוצים לפתח מוצרים, הכח האמיתי הוא בחיבורי API לשירותים חיצוניים. כך היה תמיד. מפתחים מסגרת, פונים ב-API לשירות, מקבלים תגובה, מראים אותה במוצר שלנו. הבעיה היא שבשביל להתחבר כמו שצריך לשירותים אחרים, צריך "לדבר" את שפת ה-API. לקרוא תיעודים, דוקומנטציות, להבין מה קורה שם, להבין איך פנייה נראית וכו'. לדוגמא, אם אני מדבר על שירות שמאפשר ליצור אוואטר וידאו, אז בקריאת ה-API של אותו שירות, נמצא הנחיות על איך לפנות ב-API כדי ליצור אוואטר, ואיך לפנות בדרך אחרת כדי לשלוח בקשה ליצירת וידאו של האוואטר, ואיך לפנות בדרך אחרת כדי לראות מה סטטוס יצירת הווידאו, ואיך לפנות כדי לקבל את התוצר וכו וכו וכו. כך היה תמיד. מה שהשתנה לאחרונה, הוא שאנת'רופיק השיקו פרוטוקול בשם MCP, שבא לעשות סדר בעבודה של מודלים גדולים של שפה (AI) עם חיבור לכלים חיצוניים. זאת אומרת, במקום ש"רק נתכתב" עם מודל שפה, אנחנו רוצים שמודל השפה ידע שיש לו כלים שהוא יכול להשתמש בהם (כמו לחפש במייל שלנו, להגיב להודעות, או ליצור אוואטרים). במקום לאפשר זאת ע"י הגדרת API כפי שקרה בשנתיים וחצי האחרונות, באו אנת'רופיק ואמרו: בואו נגדיר מעטפת לכל API. במקום לצלול לכל הדוקומנטציה בעצמנו, נגדיר שירות, נקרא לו MCP. מודל השפה יפנה ל-MCP הזה, והוא כבר ידע לנהל את כל האינטראקציה מול ה-API. לבד. לא צריך יותר מפתחים שישברו את הראש. תם העידן הזה. רק מה, כדי להגדיר את שירות ה-MCP הזה, היה צריך או לפתח אותו בעצמנו, או למצוא שרתי MCP שאחרים פיתחו - אבל אז זה אומר שמתחברים לשירותים של אנשים אחרים ונותנים את המפתחות הסודיים שלנו כדי לגשת לשירותים האלה כשאנחנו לא באמת יודעים מה קורה בקוד שלהם עד הסוף אם אנחנו לא קוראים אותו לפני כן - או לחכות ל-MCP רשמיים. למשל, לחכות ש-ATLASSIAN ישיקו כזה כדי שנוכל להתחבר אליהם "רשמית". במילים פשוטות, MCP הופך אותנו לעצלנים יותר. גם לא צריך יותר לקרוא בעצמנו API DOCS, וגם נותנים ל-AI לשבור את הראש במקומנו. זה עובד. זה עולה לנו ביותר קריאות לכלים, ובעידן שבו "משלמים" ל-AI עם מטבע שנקרא טוקנים, אנחנו מבזבזים יותר טוקנים, אבל חוסכים זמן. ה-TRADEOFF הזה שווה. איפה הבעיה? שכדי להגדיר זאת היינו צריכים להגדיר לא מעט דברים טכנית על המחשב שלנו, בין אם זה בקלוד דסקטופ, או קרסר או וואטאבר. לאחרונה החלו לזרוח שרתי MCP חדשים בתצורת SSE, SERVER SIDE EVENTS, שזה אומר: אנחנו מקבלים קישור אחד בלבד לפנות אליו, והשירות כבר דאג בצד שלו לעטוף את ה-API שלו. כך שזה חוסך מאיתנו את הצורך לקרוא API באופן "רשמי" ואפילו לא צריך יותר להגדיר דברים לוקאלית כמו קודם. מגדירים את הפניות הרלוונטיות בקוד, והוא יודע לפנות ל-MCP הרלוונטי. יש לנו MCP לג'ירה, לקונפלואנס, לסלאק, אפילו לייצר וידאו ותמונות עם מודלים, טקסט לדיבור, אוואטרים, סוכני AI ומה לא. מה שאומר שעוד רמה של הפשטה נכנסה וחדרה אלינו לעולם הפיתוח, ושוב הגבינה זזה, ושוב גם מי שמעולם לא התנסה בפיתוח - יכול לרוץ קדימה מהר ולעלות על רכבת המהפכה הזו. תחשבו על זה. הייחודיות שנשמרה "בסוד" ל"גאוני API" הופכת לנחלת הכלל עם MCP SSE. ושוב נצטרך להמציא מחדש את עצמנו באמצעות היצירתיות שלנו. מחסומים טכניים נשברים מהר מאוד - מה שנשאר זו היצירתיות.

אני מאוד אוהב את טל פלורנטין וראיתי בספר שלו מוצר שעוזר למנהלי מוצר ולמאפייני חוויית משתמש - אז צילמתי (עם הטלפון) את המוצר והעליתי לבייס44 ועכשיו המוצר הזה שעוזר למנהלי מוצר - הוא מוצר אמיתי 😂 האמת היא שאני באמת לא תיארתי לעצמי כמה עומק יש בעולם חוויית המשתמש ובעולמות ניהול המוצר. בעברי עבדתי בתחום הטמעת מערכות מידע ואני מכיר את סביבות העבודה של: מנהל/ת פרויקט, מנתח מערכות, מעצבת גרפית, מפתחים, ומנהלי מוצר זכורים לי בעיקר מטבלאות האקסל הנוראיות שלהם, לוחות הזמנים המפלצתיים והרצון האימתני לדלוור כבר אתמול. בעידן של היום שבו ככ קל לפתח מוצרים עם וייב קודינג, ולתחושתי כולנו הופכים בעל כורחנו למנהלי מוצר, אנחנו מוכרחים גם לתת דגש לחוויית המשתמש במוצר שלנו, וחלק מזה מתבצע באמצעות ההבנה שאנחנו לא המשתמשים, שכדי להבין מה ייחשב מוצר מוצלח, עלינו לדבר עם משתמשים ברמות ידע ומיומנויות שונות, לקבל פידבק ומשם לצאת לדרך. כחלק מהמסע הזה, טל הציג מערכת שאפיין, וזה ככ גאוני לפתח עוד מזמן מערכת יצירת ותשאול פרסונות ולקבל פידבקים גם בלי ראיונות אמיתיים. אז כאמור לקחתי לבייס44 והתוצאה מדהימה, ויש אפילו LLM מובנה כך שבאמת אפשר לדבר עם כל פרסונה! ולמי שעוד לא קרא את הספר של טל, זה אוצר אמיתי שפשוט אי אפשר לפספס. ממליץ בחום! Tal Florentin 🎗 אתה מלך!!!! Maor Shlomo עוד יוז קייס מדהים עם המוצר הגאוני שלך!!! Base44

זה באמת מטורף בעיני: הייג׳ן השיקו מודל חדש שיודע להנפיש תמונות ולהוסיף תנועות, מחוות והבעות, והכל מתמונה אחת בלבד! כדי לבחון את היכולת שהם טוענים, יצרתי תמונה שלי עם המודל החדש של Flux Kontext, שזה אומר שסך הכל העליתי תמונה שלי וכתבתי פרומפט. בלי לאמן מודל ובלי כלום. לקחתי את התוצר להייג׳ן, למודל החדש, העליתי את התמונה, כתבתי טקסט ובחרתי להשתמש בקול שלי (שכפלתי את הקול שלי שם בעבר), והופ: הווידאו הזה נוצר. זה כנראה לא מקרי שרק אתמול ElevenLabs סחפה את קהילת ה-AI בזכות המודל החדש שלה של יצירת טקסט לדיבור שכעת מסוגל להתמודד עם הבעות קוליות מרשימות מאוד, והנה לפתע הייג׳ן נותנים פייט ומוסיפים הבעות - מירוץ שכולנו מרוויחים ממנו! כמה חיכיתי לזה 😳🤯