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

אצל GPT, מספר המקורות עלה ל-31
בעוד שאצל קלוד, מספר המקורות עלה ל-358!!!!

מצויד בהתלהבות הזו, חיכיתי מאוד לתוצרים. כששניהם סיימו את המחקר המעמיק, התלהבתי מאוד ממה שקיבלתי מקלוד - עד שקראתי את מה שקיבלתי מ-GPT. המחקר שלו היה הרבה יותר מדויק והרבה יותר ממוקד למה שביקשתי. זה מעניין. הוא קרא כ-10% בלבד מהמאמרים שקלוד קרא (ז"א שקלוד קרא בערך פי 10(!) ממנו), והיה מדויק יותר.

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

אם ניסיתם גם את הכלים אשמח לקרוא את הרושם שלכם מהם!

שבת שלום לכולם.

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

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

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

כמה חיכיתי לזה 😳🤯

אני מאוד אוהב את טל פלורנטין וראיתי בספר שלו מוצר שעוזר למנהלי מוצר ולמאפייני חוויית משתמש - אז צילמתי (עם הטלפון) את המוצר והעליתי לבייס44 ועכשיו המוצר הזה שעוזר למנהלי מוצר - הוא מוצר אמיתי 😂

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

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

ולמי שעוד לא קרא את הספר של טל, זה אוצר אמיתי שפשוט אי אפשר לפספס. ממליץ בחום!

Tal Florentin 🎗 אתה מלך!!!!
Maor Shlomo עוד יוז קייס מדהים עם המוצר הגאוני שלך!!!

Base44

אם עד עכשיו חשבנו שמזיזים למפתחים את הגבינה - לאחרונה שוחרר 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. ושוב נצטרך להמציא מחדש את עצמנו באמצעות היצירתיות שלנו. מחסומים טכניים נשברים מהר מאוד - מה שנשאר זו היצירתיות.

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

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

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

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

שנתיים וחצי אחרי ההייפ: מה עלה בגורלם של סוכני ה-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 בעולם - מאשר בני אדם. ובהצלחה לנו ולאנושות!

מכירים את זה שמתייגים מישהו במייל עם @ כדי שיגיב? אז הגדרתי טריגר לסוכן שלי, Logan, שעכשיו גם עוזר לי בזכות הסוכנים שהוא מפעיל!

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

בניתי סוכן על דרך LanGraph והגדרתי לו כלים, כל כלי הוא סוכן AI נפרד

לאחר מכן עשיתי Deploy דרך AWS כך שהסוכן זמין דרך קריאת API רגילה עם טוקן אימות

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

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

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

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

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

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

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

מניח שאתם מנחשים לבד למה קראתי לו לוגאן, ואם לא אז סימן שאתם לא עוקבים אחרי מספיק 😂

באמצע פגישה עם לקוח מחו״ל ראינו ש-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 ובזכותו הפרויקט הזה ממש כיפי ומעניין ועוזר לדהור קדימה בקצב מסחרר, אבל האמת היא שזה לא מספיק. אם לא היינו סיירת שיודעת מה היא עושה - גם שנה לא הייתה מספיקה לנו. כך שזה שוב חוזר לנקודה, מבחינתי, זה לא הכלים, אלא הידע של מי שמפעיל אותם.