כשהרבה אנשים מסביב נשמעים כמו מומחי LLM Apps, אולי לגיטימי שהצעד הראשון יהיה ליישר קו – ולהישמע גם, ורק משם להמשיך?!
אם זה מקובל עליכם, הנה כמה נקודות חשובות להתחיל בהן.
סוכן אחד אינו מספיק
מערכות של סוכן אחד הן מוגבלות. כשהמשימה מורכבת (למשל: ביצוע מחקר שוק רב-שלבי) סוכן אחד עלול לא לעמוד במשימה. נרצה אם כן לחלק את המערכת לכמה סוכנים כל אחד עם מומחיות משלו (Prompt, RAG) שיתמקד בחלק שלו.
- Agentic Workflow היא ארכיטקטורה פשוטה יותר, בה מספר סוכנים מבצעים שרשרת של שלבים, באופן שהוגדר מראש. למשל: Planner Agent => Market Scanning Agent => Competitive Analyzer Agent => Summarizing Agent.
- ה Workflow לא חייב להיות ליניארי, אפשר לתכנן חזרות לשלבים מוקדמים יותר, אבל חוקי ה workflow מוגדרים מראש.
- Multi Agents System (MAS) היא מערכת אוטונומית בה יש סוכן אחד שהוא Orchestrator שכל פעם בוחן את המצב ומחליט דינמית איזה סוכן להפעיל בשלב הבא. מתחיל עם Planner ואז מבצע את התוכנית, אבל אם נראה לו שמשהו בתוכנית שגוי – יכול להחזיר את הפידבק ל Planner שיתקן את התוכנית, למשל.
המטאפורה היא ארגון אנושי של בעלי מומחיות, כאשר קבוצה של בעלי מומחיות משיגים תוצאה טובה יותר מקבוצה באותו הגודל של ״Generalists״.
יתרונות מובהקים של מערכות Multi-Agent:
- אי ערבוב context בין משימה למשימה (יש context שונה לכל סוכן). ידוע ש Context Dilution (״התפזרות ההקשר״) על מגוון נושאים היא בעיה אמיתית ל Attention. כל סוכן – מנהל context ממוקד ו memory רלוונטי למשימה שלו.
- בדיקה הדדית – מודלי LLM נוטים לטעות תוך כדי שימור ביטחון עצמי גבוה. בדיקה הדדית של התוצאות שלהם היא קריטית. לסוכן אחר, על בסיס מודל שונה / context שונה – יש סיכוי מוגבר (מול אותו המודל עצמו) לאתר טעויות בתשובה.
חסרונות של מערכות Multi-Agent:
- מערכות מורכבות, יקרות יותר (יותר tokens ו latency), וקשות לניטור / troubleshooting
- כמות האפשרויות להרכבת מערכת כזו כמעט ואינה מוגבלת – מה שמקל עלינו כמהנדסים שבונים אותן להתברבר ולבזבז זמן רב בשינויים שלא בהכרח ישפרו את הביצועים.
- יש הרבה תיאוריה וארכיטקטורות שמפורסמות – פחות הצלחות מובהקות בשטח. תחום עם סיכון גבוה לאי-הצלחה.
Context is King
או Context is Everything או Context Engineering is Key, וכו׳.
בניגוד לכל העמיתים שלכם – אתם הבנתם שבניית קונטקסט זה החלק הכי חשוב באפליקציית LLM.
״Good Context wins Intelligence״ – הוא ביטוי שהגעתם אליו בעצמכם. כלומר: context מוצלח עם מודל חלש (נניח GPT-5, חחח איזו היסטוריה) יגבר על מודל חזק בהרבה (למשל Opus 4.5 Pro) עם context פחות מוצלח. קל להחליף מודלים, אבל הרבה פעמים זה לא עוזר – מה שעוזר זה לבנות context נכון.
Context נכון משמע:
- להבין את ה user query / הבעיה שמנסים לפתור בצורה עמוקה.
- להביא ל context מידע ייחודי (שאינו world knowledge שיש כבר למודל), רלוונטי, ואיכותי
- לא להביא יותר מדי מידע, כדי לא לפגוע ב Attention / לגרום ל Context Dilution.
- לא להביא / להסיר מידע סותר או מבלבל – שיגרום לסוכן להתבלבל / לאבד מיקוד.
- כמובן טוב שיהיו instructions טובים (קרי: prompt Engineering) שיאגדו את כל מכלול ה context.
עכשיו אתם יכולים לבחור באחת משתי גישות פופלריות של מומחיות:
גישה ראשונה: RAG איכותי עושים עם Vector DB ו Embedding אבל זו מומחיות שלמה.
אם ״יתנו לכם את המפתחות״, אתם תדעו לעשות את זה ״כמו שצריך״ ולהוביל את המוצר להצלחה.
גישה שנייה: RAG גנרי על בסיס Vector DB ו Embedding הוא לעצלנים / בורים – יש לעשות Custom RAG לבעיה הספציפית.
רק שילוב חכם בין בסיסי-נתונים רלציוניים (נתונים עסקיים מובנים), בסיסי נתונים של Graph (ידע של דומיין) ו Vector DB (מאמרים כלליים) תוך תכנון קפדני. אתם באופן אישי מאוד התרגשתם מהשחרור של pg_textsearch שתומך ב BM25 לפי פרמטרים בתוך ה DB עצמו. עכשיו לא נדרש מכם לעבוד גם עם ElsaticSearch (שבנינו: הוא די מיושן).
אם מישהו רוצה context engineering ״כמו שצריך״ – שייתן לכם לתכנן בקפדנות את הפתרון – ואתם תדעו לשלב בין הגישות בצורה חכמה, בלי התלהמות וריצה אחרי טרנדים.
אפשר לבחור בכל אחת מהגישות – כל אחת נחשבת מקצועית ומובילה.
אפשר כמובן לשלב ביניהן – אבל זה דורש מעט יותר מיומנות אישית.
Observability, Governance, and Safety
כל ילד יכול היום להורות ל LLM לפתח מערכת ששולחת אסטרונאוטים לירח – זה כבר משחק ילדים.
ההבדל בין ילד למקצוען בעולם ה LLM הוא היכולת להבטיח שהמערכת מתנהגת בצורה תקינה וטובה – שווה ערך או טוב יותר מהמקבילה האנושית.
כן, זה כולל דברים לכאורה לא סקסיים כמו Security ו Legal ו HITL (קרי Human-in-the-loop – משמע גם עבודה ידנית) – אבל זה בעצם המומחיות האמיתית במערכות LLM.
כן, תנו למהנדס הג׳וניור לבנות סירת מירוץ ולהשיט אותה בשיא המהירות. בסוף, מה שעושה את ההבדל בין עסק כושל לעסק מצליח בעולם הזה – זה לעשות Safety ו Governance, לוודא שסירת המירוץ לא מתרסקת על סלע (רגולציה) – וזה התבלין המיוחד שאתם מביאים לשולחן.
מה שחשוב עכשיו הוא לשלוט במערכת. להוסיף OpenTelemetry (ועליה: OpenInference – ההתאמה לעולמות ה AI) כדי לדעת לעקוב אחרי ה flows של ה agents ולהבין היכן הם כושלים.
כלים כמו Nemo Guardrails של אנבידיה או Presidio (זיהוי וניקוי של PII) הם ה infra החדש.
כן, לאנוידיה לא תמיד הייתה תדמית טובה בפיתוח תוכנה – אבל הם השתפרו!
יש המון סטארט-אפים חדשים בקטגוריה של Safety ו Guardrails (שם גנרי להגנות שונות) – ואתם יכולים לציין כל שם שנשמע אמין ולא מאוד קליט. אף אחד לא מצליח לעקוב גם ככה. אני עובד עם ב״איקרוס״, אם אתם רוצים לדעת. משהו משהו.
xLM משנה הכל, לכולם – בכל מקום
LLM (שפה) או VLM (חזותי) או SLM (מודל קטן – נושא חם!) או MMLM (מולטי-מודל) או RLM (קרי Reasoning Language model), וכו׳.
אתם כבר הבנתם שמשהו בין 600% ל 1000% מהמשרות בארה״ב יוחלפו בשנים הקרובות ע״י LLM.
תכנות הוא מקצוע שעבר מהעולם, ואין טעם בכלל ללמוד לכתוב קוד – רק specs שה LLM יבצע, או meta specs שה Agents החכמים יהפכו ל specs.
אתם מחכים לחברה (company) של עובד בודד שתהפוך לחד-קרן. רק עניין של זמן. אתם ידעתם.
מצחיק ללכת ללמוד ניהול, כי כבר עכשיו Gemini-3-Flash מנצח במבחנים את בוגרי MBA של פרינסטון, ולנצח את הארוורד זה רק עניין של זמן.
אתם יודעים מה המקצוע היחידי שיישאר רלוונטי.
עתידן? מומחה סושיאל? – אתם מעדיפים כרגע לשמור את זה לעצמכם.
ה AI זו בועה אחת גדולה!
המון כסף הושקע ב AI בשנתיים האחרונות, וקשה מאוד להסביר איך הכסף הזה יניב רווח.
בנוסף, הציפיות מ LLM בשמיים – בעוד בפועל התוצאות בפועל בינתיים … בינוניות. יש הרבה מקורות שמספרים את אותו הסיפור שוב ושוב. כדי להגשים אפילו רבע מההבטחה של LLM – יש עוד הרבה מה להתקדם. למשל:
דוח של BCG (רוב החברות לא מצליחות להפיק ערך מוחשי מ LLM)
- רוב החברות לא מצליחות להפיק ערך מוחשי מ-LLM: רק 26% פיתחו יכולות שמאפשרות לעבור מעבר ל-PoC ולהניב ערך, ו-74% עדיין לא מציגות ערך מוחשי מהשימוש ב-AI.
- רק 4% מהחברות מצליחות לייצר ערך משמעותי מ LLM באופן עקבי. אלו בעיקר חברות תוכנה ופיננסים.
דוח של MIT (״95% מהפיילוטים של LLM נכשלים״)
- רק 5% מהפיילוטים מבוססי LLM מגיעים להאצת הכנסות מהירה. כל ה 95% האחרים כושלים, או מדשדשים.
- הדו״ח ״מאשים״ יישום לא נכון של LLM, הן בבחירת המטרות והן בלמידה של הארגון איך להשתמש בו.
- מה מצליח יותר: לרכוש מוצרים שכבר הצליחו – ממי שכבר ״הצליח לעשות את זה״
רויטרס (AI promised a revolution. Companies are still waiting)
- פורסטר: רק 15% מהחברות שיישמו LLM ראו שיפור במרווחי רווח בשנה האחרונה בזכות ה LLM.
- פורסטר צופה שב 2026 חברות יידחו כ 25% מההשקעות המתוכננות ב LLM.
- השוק מבין ש LLM זה לא ״כפתור קסם״ אלא מיומנות שצריך ללמוד ולפתח.
ועוד… לא חסרים דוח״ות באופי הנ״ל.
אם משהו מסתבך, ומקשים עליכם לגבי ההצלחה של ה LLM במקרה ספציפי או בעולם – הדבר המקצועי הוא להפגין שאתם ידעתם תמיד שזה המצב.
LLM זקוק לנתונים טובים (Context is King, אמרנו?) ולמומחיות והבנה בארגון היכן LLM באמת מתאים. הוא נהדר ב 80%, אבל להביא אותו ל 90%+ – זו לפעמים עבודה מאוד קשה. רק לאבחן מתי הוא לא עובד – ולהעביר לטיפול אנושי – זה לא פשוט.
אתם הרי אמרתם את זה – איי שם עוד לפני לפני התפוצצות בועת הדוט-קום (במידה ונולדתם כבר).
באופנה הנוכחית של שילוב נבון בין מיסאינפורמציה ודיסאינפורמציה – אני בטוח שתסתדרו.
מצד שני, זה רק עניין של זמן, ו 2027 תהיה שנת ה Baby Boom של פתרונות LLM. או שלא.
סיכום
הפוסט הזה משלב קצת ידע High-Level, סרקזם, והומור – כי זה מה שאני יכול לתת לכם בשלב הזה.
אני מקדיש הרבה מזמני ללמוד, להבין, להתייעץ ולשמוע – ועדיין יש הרבה יותר שאלות טובות – מתשובות טובות.
זה עניין של זמן, אבל כנראה זה יגיע. האם נאהב את כל התשובות? בוודאי שלא.
גם מהפיכת האינטרנט ומהפיכת המובייל התחילה בהרבה ורעש + מעט הבנה אמיתית. במהפיכת המובייל הייתי בשלבי ההתחלה – ויש הרבה קווי דמיון.
כן, הפעם זה גדול יותר, קיצוני יותר, דרמטי יותר – כמו סרט המשך הוליוודי ללהיט ענק.
אמשיך לעקוב, לעדכן, ולחוות אתכם ביחד את המהפיכה שמתרחשת כאן.
שיהיה בהצלחה!
נ.ב. זיהיתם טענות מופרכות בפוסט? ״סופגניות חנוכה״ (easter eggs)? כתבו בתגובות.