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

שנתיים וחצי אחרי ההייפ: מה עלה בגורלם של סוכני ה-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 בזכות המודל החדש שלה של יצירת טקסט לדיבור שכעת מסוגל להתמודד עם הבעות קוליות מרשימות מאוד, והנה לפתע הייג׳ן נותנים פייט ומוסיפים הבעות - מירוץ שכולנו מרוויחים ממנו! כמה חיכיתי לזה 😳🤯

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

היכולת החדשה של קלוד ו-GPT להתחבר למאגרי מידע ארגוניים כמו Sharepoint, Atlassian וכדומה - פשוט מחקה ומחצה כמות אדירה של חברות שכל המוצר שלהן התבסס על פיתרון נקודת הכאב הזו של חיבור LLM למאגרי מידע פנימיים חלף הרבה זמן מהתופעה הזו. ב-2022 כאשר הושק GPT, מהר מאוד חברות הטמיעו את ה-API שלהם במוצר והפכו את המוצרים ל״מבוססי AI״, גם אם זה היה רק צ׳טבוט בשפה טבעית. באופן כמעט מיידי צצו מוצרים בכמות אדירה ש״פותרים״ את הבעיה שה-AI לא התחבר לשירותים נוספים. מהר מאוד הושקו הפלאגינים, ו-GPT מחקו את החברות שעסקו בזה. דבר נוסף שהושק הוא מודל התמלול, Whisper, שגם הוא מחץ חברות שהשירות שלהן היה תמלול. במקביל, חברות אחרות החלו לפרסם שירותי ״יצירת סוכני AI בקלות וללא קוד״. ואז הושקו GPTs וגם AI Assistants ששוב מעכו את החברות שעסקו בזה. מאז ועד לאחרונה, החל גל נוסף של מוצרים שמתחבר לג׳ירה, לקונפלואנס, לסלאק, לסוויטת המוצרים של גוגל, לגיטהאב, לביט-באקט וכדומה. כפטריות אחר הגשם כך צצים מוצרים כאלה. גם GPT וקלוד הכניסו זאת במעין השקה שקטה. והשבוע האחרון כלל עדכון משמעותי של חיבור לכלים משמעותיים נוספים, שמאפשרים הבאת קונטקסט לשיחה ממאגרי מידע פנימיים, זה מכפיל כוח עוצמתי ברמות שקשה לתאר. כבר לא צריך לשבור את הראש לפתח לבד חיבורים. עוד גל של חברות נמחק. ולא רק זה. גם גל אדיר של סוכני קוד וסוכנים שפועלים לבד בדפדפן מציף אותנו. זה roo, cline, augment code, Claude code, aws developer Q, GitHub copilot, ועכשיו גם OpenAI Codex שיודע להתחבר לאינטרנט. שוב נוק אאוט. זה גורם לי להיזכר בשיחה שלי עם Sharon Kinory , משקיעה חכמה מאוד, ולתהות: איך משקיעים יכולים לקבל כיום ביטחון שההשקעה שלהם משתלמת ושהמוצר לא יהפוך ללא רלוונטי תוך מספר שבועות או חודשים לכל היותר? כפי שקורה כיום? המודלים כבר הגיעו לרמה מאוד גבוהה של ידע. אין איך לשפר אותו כמעט. מה שכן אפשר לשפר זה את המעטפת. את הפיצ׳רים מסביב. את היכולות האג׳נטיות. את ריבוי הקריאות בין הסוכנים השונים. זה מה שחברות מנסות ליישם: תשאול על קודבייס גדול, מבחני ביצועים בין מודלים שונים של Embeddings, Chunking, הנדסת פרומפטים, השוואות של Zero Shot מול Few Shots או Chain of Thoughts וכדומה. שימו לב כמה שרתי MCP צצו בין לילה, ובאיזו מהירות OpenAI וקלוד הכניסו את הקונקטורים בשבוע האחרון. כדי שוב לתת בראש. זה מירוץ מטורף שכדי לנצח בו צריך לפתור נקודת כאב אמיתית - ובעיקר גם לרוץ מהר מאוד. המירוץ הופך להיות מירוץ ספרינט לטווח קצר מאשר פיתוח ארוך טווח. בקיצור, לפני שמפתחים את הסוכן הבא או את האפליקציה שמאפשרת לתשאל קודבייס שלם, גם עם מודל פרטי בתשתית סגורה, כדאי שנשאל את עצמנו: האם כדאי לנו ״לבזבז״ על זה את הזמן או שכבר קיים פיתרון כזה? או אולי זה עניין של שבועות ספורים עד שהפיתרון יצוץ? ואז בכל מקרה חבל להשקיע את הזמן על זה? הדילמות האלה גורמות לנו לחשוב הרבה יותר קשה, שעה שיותר קל לנו לרוץ מהר עם הדימיון שלנו. אבל האמת היא שהעצירה, ההתבוננות, החשיבה, התכנון - כל זה זה מה שיוביל להצדקה ״לבזבז״ את הזמן שלנו. תמיד כדאי לחשוב בעיניים של ״משקיע AI״, ועל אחת כמה וכמה שהמשאב הכי יקר שלנו להשקעה, הוא הזמן שלנו. עם ניצול נכון ויעיל של הזמן, ובחירה נבונה של ״איך להשתמש בו״, נוכל לרוץ מהר יותר - אבל בצורה מתוכננת ומחושבת. הפוסט הזה נכתב לאחר שיחות עם משקיעים, חברות, ייעוץ וליווי, הקשבה לכאב ולתסכול שנגרם בשל ״הנוק אאוט״ של הגדולות שוב ושוב.

סיימתי להעביר סדנא של 3 שעות על GitHub Copilot לעומק אצל Applied Materials הנפלאים! תמיד אני חושש לפני סשן למפתחים/ות - אבל היה כל כך כיף, שאלות חכמות, צלילה לעומק, שיתוף פעולה ומעורבות שבאמת הרגיש לי כיף מתמשך כל הסשן. דיברתי על Context Window Limit, LLMs, RAG, Embeddings, Agents, MCP, Copilot Custom Insteuctions, והכל גם בסביבת ג׳אווה עם IntelliJ וגם במקביל עם PyCharm ו-VSCode. אני באמת חסיד של מקרי בוחן פרקטיים ותמיד כיף להתחבר לשטח ולהרגיש את הצורך האמיתי של חברות וארגונים, ובעיקר לפגוש את האנשים והנשים ולהתפעל מכמה שהם חכמים. מפתחים/ות הם כל כך חכמים, אבל ברגע שהבנתי שאני לא בא להתחרות כאלגוריתמאי הכי טוב, אלא אני מגיע על תקן זה שמאוהב ב-AI ״עמוק״, כזה שמתחבר לסוכנים, לקוד, לארכיטקטורה מעניינת, כזה שמשחק עם כל הכלים בתשוקה אמיתית - ומדבר עליהם, זה עושה את כל ההבדל. אני מגיע גם כדי לשתף מהניסיון שלי, ובמקביל זוכה ללמוד גם בעצמי מהמשתתפים/ות. תודה גדולה ל Ofir Rozenfeld על החיבור ועל הבמה ועל ההזדמנות! תודה גדולה גם לכל מי שלקח/ה חלק, Ofir Rabinian , Noga Hecht , Idan Reuven

למה נמאס לי מ-n8n או make והעדפתי לפתח הכל בקוד עם קרסר? כי אם רוצים לעבוד בסקייל ולא על התשתית שלהם זה הופך להיות בלתי נסבל. תחשבו על זה. ראיתם תרחיש אוטומציה מעניין, עובד מצוין בענן שלהם או אפילו לוקאלית. איך אתם הופכים אותו למשהו שרץ ועובד בסקייל אמיתי? במייק בניתי אוטומציות שנשברו בשלב מסוים והייתי צריך מדי פעם להפעיל אותן שוב. הן נשברו בגלל שהתשובות של ה-LLM לא תמיד זהות במבנה שלהן וזה שובר את השרשרת לפעמים. מעצבן. אבל קורה. במייק ו-n8n מאוד נוח לעבוד אונליין, אבל בפועל בסופו של דבר אני מרגיש שאין תחליף לפיתוח עם קרסר ולפרוס את האוטומציה על איזו Azure Functions או AWS Lambda וכדומה. כדי לפרוס בעצמנו אוטומציה שפיתחנו עם n8n כנראה נצטרך להתעסק עם דוקר, קוברנטיס, אולי ec2, טרה-פורם. לא כיף. לא נעים. לא נחמד. ואם אפשר לעשות את זה קל יותר אז למה לא? נחמד שיש משחקים עם אוטומציות וזה עובד יפה לתרחיש קטן שלנו, אבל כשרוצים מראש משהו שבאמת יעבוד לאורך זמן מבלי להתעסק בהגדרות של הברזלים שוב ושוב - כאן כבר (לדעתי האישית) הכלים האלה מאוד מאכזבים, ומנגד - סוכני הקוד זורחים. ומה הרושם שלכם מפריסה של תהליכי אוטומציות? האם יש לכם העדפה לפיתרון כלשהו?

סדר בבאלגן המודלים של OpenAI: בואו נפרק את זה בפשטות - מתי להשתמש בכל מודל ולאיזו מטרה? אז אתמול אנדרי קארפתי הגאון פרסם ציוץ שעושה סדר בכל המודלים של OpenAI: בואו נפרק את זה: 1. מודל GPT-4o הוא המודל הקלאסי שמספיק לנו לרוב המשימות היום-יומיות, לרבות יצירת תמונות, ניסוח מיילים, תשאול כללי ועוד. עובד מהר. עובד טוב. 2. מודל o3 הוא ה-מודל ה-חכם של OpenAI ונשתמש בו למשימות מורכבות של קוד, חשיבה, מתמטיקה, עומק. מדובר במודל שאומן להשיב ע"י פירוק התשובה לתהליכי "חשיבה" ולכן לוקח לו זמן רב יותר. לא צריך אותו כל הזמן וזה לא אומר שהוא הכי "טוב". 3. אם רוצים להפעיל חיפוש באינטרנט - יש כפתור בשורת הצ'אט של Search, פשוט להפעיל אותו 4. אם רוצים מחקר מעמיק - יש כפתור של Deep Research בשורת הצ'אט - פשוט ללחוץ עליו 5. מודל שזמין למנויי פרו הוא o1 pro mode ואין מה להשתמש בו, בנוסף מודלים o4-mini, o4-mini-high, GPT-4.1-mini הם מודלים שלא מומלץ להשתמש בהם ולא ברור מה התועלת מהם בכלל 6. מודל נוסף הוא GPT-4.5 שמאוד טוב בהתנסחות או סתם צ'אט כללי כלשהו, לא דרמטי מדי, אין מה להתאמץ להשתמש בו כשיש את 4o שהוא מספיק מהיר וטוב 7. מודל GPT-4.1 הוא אחלה ל-Vibe Coding במה שכרוך בשינויים של קטעי קוד קטנים. אם צריך לעבוד על קודבייס גדול, תשתמשו ב-o3, אם אתם יודעים מה אתם רוצים לשנות או לתקן ואתם ממוקדים - לכו על 4.1 והנה התמונה שהוא העלה, מספרת את כל הסיפור בקצרה. מה מהניסיון שלכם עובד הכי טוב - ולאיזה צורך? אני אישית משתמש בעיקר ב-4o עם המודל הקולי, או לשאלות כלליות או כשאני גם משתמש בחיפוש דרכו (כבר כמעט לא נוגע במנועי חיפוש רגילים), ב-o3 אני משתמש לשאלות שצריכות Debug של קוד או הבנה משמעותית מתוך קרסר.