רברס עם פלטפורמה
Hosted by Ran · רברס עם פלטפורמה
4.9from 28 ratings
- 828
- Episodes
- 28
- Ratings
- Bi-weekly
- Cadence
- 2009
- First episode
About רברס עם פלטפורמה
פודקאסט על תוכנה, מוצר, ותשתיות — בעברית.
- Publisher
- רברס עם פלטפורמה
- Category
- technology
- Language
- he
- Explicit
- No
- First episode
- 1 Jan 2009
- Latest episode
- 11 Nov 2026
Latest episodes
828 episodes in the feed.
11 Nov 2026
522 - Company brain with Shmulik from Lusha
בפרק 522 של רברס עם פלטפורמה, רן ואורי מארחים את שמוליק וילינגר (https://www.linkedin.com/in/shmulikwillinger/), ה-Chief Architect של חברת Lusha (https://www.lusha.com), לשיחה מרתקת על בניית "מוח ארגוני" (Company Brain). נדבר על למה בכלל צריך את זה בעידן ה-AI, מה גרם להם לבחור לבנות את המערכת בעצמם (Build vs. Buy), ואיך גורמים לסוכנים אוטומטיים להכיר את כל ההקשרים והסודות של החברה בלי לשבור מנגנוני הרשאות. [01:51] קצת על לושה והרקע של שמוליק שמוליק התחיל את הקריירה לפני כ-20 שנה, עבר בסטארט-אפים וחברות גדולות, והיום מוביל את הארכיטקטורה ושילוב ה-AI בלושה. Lusha (https://www.lusha.com) היא חברת Business Intelligence שבונה פרופילים מדויקים של חברות ואנשי מקצוע (טלפונים, סיגנלים, אינטגרציות למיילים ול-CRM). בין הלקוחות של החברה אפשר למצוא ענקיות כמו Spotify (https://www.spotify.com), Google (https://www.google.com), ו-Palo Alto Networks (https://www.paloaltonetworks.com). החברה משלבת המון כלי AI וסוכנים (Agents) גם כחלק מהמוצר ללקוחות הקצה (למשל עבור SDRs שמחפשים לידים) וגם בתהליכי הפיתוח הפנימיים. [04:12] איך נולד הצורך במוח ארגוני? (הטריגר) הצורך התחדד כשראו את ההשפעה של כלי ה-AI על פיתוח. המפתחים הואצו (10x), אבל צוואר הבקבוק עבר לאנשים עצמם. במקום שהקוד יהיה החסם, החסם הפך להיות ההקשר (Context): הבנת הדרישות, האילוצים העסקיים והשלכות של שינויים רוחביים. סוכנים יכולים לכתוב מסמכי PRD או קוד במהירות, אבל בלי קונטקסט של "למה הוחלט ככה?" או "מי הלקוחות שמושפעים מזה?" הם עוצרים או גרוע מכך - ממציאים (הזיות). ידע ארגוני נמצא אצל מהנדסים ואנשי מוצר ותיקים. במקום ש-Agent "ידפוק לאנשים על הכתף" לשאול שאלות, צריך להנגיש לו את התורה שבעל-פה. [09:10] Buy vs. Build: למה לבנות לבד? החברה בחנה את השוק ושוחחה עם כ-18 ספקים שונים שהציעו פתרונות למוח ארגוני. חלק מהפתרונות היו מורכבים מדי או יצרו סכנה אמיתית של Vendor Lock-in. ההחלטה ללכת על פיתוח עצמי (Build) נבעה גם מההבנה שהשוק עוד בהתהוות. ההנחה היא שחברות כמו OpenAI (https://openai.com) ו-Anthropic (https://www.anthropic.com) יוציאו בקרוב פתרונות מובנים משלהן למוח ארגוני, ולכן עדיף לבנות תשתית גמישה פנימית עכשיו שיהיה אפשר לנתב החוצה בעתיד בקלות. הגישה: להתחיל בקטן וללמוד תוך כדי תנועה מה עובד ומה לא. [11:14] מי משתמש במוח ואיך מכניסים אליו דאטה (Data Ingestion) קהל היעד הוא כל הארגון, אבל התחילו ממיפוי של מחזור חיי הפיתוח (SDLC) כדי להבין מי הפרסונות. המקורות: GitHub (https://github.com) (מעל 960 Repositories), טיקטים ב-Jira, מסמכים ב-Confluence, ערוצי Slack, ואפילו תמלולים וסיכומים אוטומטיים של פגישות וידאו מתוך החברה. המימוש הראשוני: תיקייה עם אלפי קבצי Markdown (MD) מסודרים בהיררכיה עם קובץ קטלוג שמשמש כתוכן עניינים למודל. [13:43] מוחות נפרדים, אבטחה והרשאות (Access Management) הגישה למסמכים מתבצעת על ידי הרצת Skill מקומי או דרך שרת MCP (Model Context Protocol) ייעודי. תובנה מרכזית: לא מספיק "מוח אחד" לכולם. לארגון ה-Delivery יש צרכים שונים מאשר לארגון ה-Sales. מוח ה-Sales יתחבר למערכות כמו Salesforce (https://www.salesforce.com) או HubSpot (https://www.hubspot.com) ויהיה המומחה לתמחור ומתחרים. מוח ה-Delivery יתחבר לקוד ולארכיטקטורה. הפרדת רשויות: בעלות על ידע מופרדת מהרשאות. מפתח לא צריך לראות נתוני תשלום של לקוחות, ואיש מכירות לא צריך גישה לקוד. אם מוח אחד צריך מידע מדומיין אחר, המוחות מתקשרים ביניהם (אנקפסולציה) מבלי לחשוף את מערכות המקור למשתמש הקצה. [19:31] מה לא עבד? המעבר משכבת Markdown לאונטולוגיה אוסף של קבצי MD התגלה כפתרון חסר. המודל התקשה לעשות חיבורים היסטוריים וסמנטיים. דוגמה: פיצ'ר שהיה קרוי בעבר "List", שונה ל-"Uno" והיום נקרא "Workspace". קבצי MD יראו אותם כישויות נפרדות, למרות שמבחינת העובדים הוותיקים זה אותו מוצר. השלב הבא: בניית שכבת אונטולוגיה מפורשת לקישור ישויות, ושכבה סמנטית. שימוש ב-PostgreSQL (https://www.postgresql.org) כדאטה-בייס רלציוני לאונטולוגיה, ו-PGVector לשכבה הסמנטית (Embeddings). תהליך Build יומי סורק את המערכות ומעדכן את הוקטורים, תוך ניסיון לתת משקל נמוך יותר למידע ישן (כדי למנוע הזיות על מערכות שכבר עברו Deprecation, כמו Cassandra או Snowflake). [25:05] ניטור, בדיקות איכות ומדידת הצלחה הפניות למודל מנוטרות ונשמרות דרך מערכת ה-Observability של Coralogix (https://coralogix.com) כדי לנתח הצלחות וכישלונות. איך בודקים אם התשובות נכונות? יצרו Golden Set של שאלות על ידי מומחי ידע בארגון (Domain Experts). משתמשים ב-LLM as a judge: בכל בוקר, לפני שהגרסה החדשה של המוח עולה לפרודקשן, מודל של OpenAI בוחן את התשובות שמייצר המוח (שמבוסס על מודל של Anthropic) ומשווה אותן לתשובות הייחוס. אם הציון היומי יורד - עוצרים את ה-Build ולא מקדמים לפרודקשן עד לבירור הבעיה (לרוב מידע סותר בין Jira ל-Slack). [33:23] לאן הולכים מפה? סוכנים אישיים (Personal Agents) המעבר ממענה לבני אדם (דרך ממשק צ'אט/UI) לשרת סוכנים אוטומטיים שרצים ברקע (Dark Factory). ההבדל: אדם קורא 300 מילים בדקה וצריך UI ידידותי עם הצעות המשך. סוכן מעבד 300,000 מילים בדקה, פונה מאות פעמים ביום וצריך מידע מובנה (כמו JSON) עם יותר מקורות גולמיים ופחות עיצוב. בניית הפרויקט דורשת השקעה ארגונית: צוות של כ-6 אנשים מתחומי התמחות שונים ב-SDLC עובד על המוח הארגוני במקביל לתפקידיהם האחרים בחברה. האזנה נעימה!
21 Oct 2026
521 - Evaluating risk with Marina from Cyera
רן ואורי מארחים את מרינה גנדלין (https://www.linkedin.com/in/marina-gandlin/), Data Scientist ו-Team Lead מחברת Cyera (סיירה), לשיחה על סייבר, דאטה, ואיך מעריכים סיכונים בעזרת מודלי שפה (LLMs). מרינה חולקת תובנות מרתקות מהפרויקט הראשון שהובילה בחברה להתמודדות עם עומס ההתראות (ניתן לצפות במצגת המקורית (https://docs.google.com/presentation/d/1293FZOY59lfwRLSETREpJPE7mS5Xm1JLgRS3nz7rRMU/edit?usp=sharing) מתוך ההרצאה, וכן בוידאו של 17 דקות (https://www.youtube.com/watch?v=PFWZibppyl8&list=PL1FoIGqsXJ_B3-Bvg3Ww-g1l7R6VNd7kC&index=7) מאותו כנס). [00:00] היכרות עם מרינה, Cyera וכנס רברסים תזכורת: כנס רברסים 2026 מתקרב! יתקיים ב-30 בנובמבר וב-1 בדצמבר. שווה להירשם. היכרות עם מרינה: מגיעה מרקע של עשור ב-AI ומערכות המלצה בחברות כמו טאבולה ו-ZipRecruiter, וכיום עובדת בסיירה. סיירה - "Where data meets cyber security": חברה שעושה מיפוי מלא של דאטה ארגוני, סורקת קבצים, דאטה-בייסים, Jira, GitHub ועוד בסקייל עצום, כדי למצוא איפה מסתתר מידע רגיש. האתגר הנוכחי: פריצה לעולם ה-AI Security והגנה מפני מצבים שבהם סוכנים (Agents) או מודלים ניגשים למידע שאסור להם. [07:33] אתגר עומס ההתראות והמוצר (The Product) צוותי אבטחת מידע קורסים תחת מיליוני התראות (Alerts). הרעיון למוצר: לדרג ולתעדף את רמת החומרה של ההתראות כדי להיות אפקטיביים. יש הבדל עצום בין קובץ טסט שזרוק בסביבה עם כרטיס אשראי אחד, לבין דאטה-בייס פתוח לאינטרנט עם 50,000 כרטיסי אשראי של לקוחות. היתרון של סיירה: יש לה את התוכן, הקונטקסט, מידע על זהויות והרשאות גישה וידע של דומיין כדי לקבל החלטה מושכלת על רמת ה-Severity. [09:53] כשאין "אמת מוחלטת" (Ground Truth) המעבר מגישת Data Science קלאסית (למשל אימון XGBoost) למציאות מורכבת: אין "אמת מוחלטת" אחידה לכולם. חומרת אירוע משתנה מלקוח ללקוח – מה שמסוכן ליצרן מזון (דליפת פוליסה) לא בהכרח יזיז למנכ"ל של בנק ענק עם 100,000 עובדים. רגע של "Let's go anyway!": יציאה מהירה לשטח עם לקוחות ראשונים. נתנו ל-LLM בסביבה פרטית (On-premise deployment) את כל הקונטקסט כדי שיקבע את רמת החומרה ובעיקר - ייצר הסבר גנרטיבי ללקוח למה הוא בחר בה. הלקוחות התאהבו בקונטקסט ובהסבר, והיו סלחניים כל עוד לא נעשתה טעות גסה. [16:05] חיפוש אחר מטריקה ואופטימיזציית עלויות (COST) הבנה שאי אפשר להשתמש במטריקות הקלאסיות של מערכות המלצה (כמו NDCG), אלא פשוט להתמקד ב-Precision של ההתראות החמורות ביותר (Critical ו-High). הלקוח לא רוצה לבזבז זמן על False Positives. העלות: הרצת כל כרטיס אשראי בטקסט חופשי דרך LLM יקר (כמו Gemini Flash) יצרה עומס אדיר עלויות (Tokens). נוצר צורך דחוף בהורדת עלויות, מה שחייב מעבר למודלים זולים יותר והקמת מערך Evaluation (הערכה) מסודר. [17:56] אתגר ההערכה (Evaluation Challenge) שלב 1: יצירת Evaluation set גנרי מדי לא באמת עובדת, ודורשת המון עבודה ידנית של מומחי דומיין. שלב 2: ההתמודדות עם חוסר דטרמיניזם. מודלים גנרטיביים (גם בטמפרטורה 0) משנים את התשובות שלהם והסיווגים שלהם בכ-20% מהמקרים כשמריצים אותם שוב. הפתרון: שימוש במודל חזק כדי לרוץ כמה פעמים על אותו דאטה, ולקיחת תת-הקבוצה שבה המודל הסכים עם עצמו בצורה רובסטית כדי לייצר סט בדיקה יציב. לא נעשה שימוש במספר מודלים שונים לצורך זה. [21:44] שופט מבוסס מודל שפה (LLM-as-a-Judge) שלב 3: כתיבת LLM-as-a-judge כדי להשוות מול המודלים הזולים את איכות ההסבר הגנרטיבי. קל לכתוב את השופט, אבל קשה מאוד לפרש את התוצאות ולהגיע לכיול (Calibration). השופט בדק האם צוין אופי הקובץ, כמות הממצאים והגישות הקיימות. הבעיה: איך מפרשים ממוצעים? מה ההבדל בין ציון 4.2 ל-3.7? הפתרון: הגדרת סף איכות ברור (למשל, כל מה שמקבל ציון מעל 4 נחשב מספיק טוב), והחלטת טרייד-אוף מוצרית שמוכנה להקריב 5% מהאיכות בשביל לחסוך 30% מהעלויות. [31:21] קסטומיזציה (Customization) שלב 4: ה-Pipeline ההנדסי שנבנה מאפשר להחליף בקלות פרומפטים ולהוסיף קונטקסט, מה שאיפשר לתמוך בעשרות פוליסות אבטחה בבת אחת. הוספת היכולת ללקוח לייצר חוקים ספציפיים לארגון שלו (למשל, התראה מיוחדת על פורמט של Gift cards שמתחיל במספרים 5 ו-6). [34:12] פידבק מהשטח (Feedback loop) שלב 5: בחינת הפידבק בשטח. 93% מההתראות שדורגו כ-Critical/High אכן טופלו ונסגרו על ידי הלקוחות (Action taken). הפיצ'ר דילל ללקוחות כ-64% מנפח ההתראות המרעישות. פידבק מצוין מ-Design partners שהגדירו את המערכת כ-"Best feature of the year". האזנה נעימה!
24 Sept 2026
520 - Harness optimization with Or from AI21labs
פרק מספר 520 של רברס עם פלטפורמה. בפרק זה רן מארח את אור דגן (https://www.linkedin.com/in/or-dagan/), COO בחברת AI21 Labs (https://www.ai21.com/), לשיחה עמוקה על עולם ה-Harness Optimization. נדבר על האופן שבו ארגונים יכולים לאמץ בינה מלאכותית ב-Scale, החל משלב האוולואציות (Evals) ועד ל-Post-Training של מודלים. [00:00] הכרות עם אור והסיפור של AI21 אור דגן מציג את ההתפתחות של AI21, חברה שפועלת בתחום כבר 9 שנים. התפתחות החברה לאורך השנים: אימון Foundational Models גדולים כמו משפחות Jurassic ו-Jamba. פיתוח מוצרי B2C מוכרים מבוססי LLM, כמו תוסף הכתיבה Wordtune (https://www.wordtune.com/). המעבר לסוכנים חכמים (Agents כמו Maestro) ולעולמות ה-B2B. המוקד הנוכחי: לעזור לארגונים לאמץ AI בצורה נרחבת תוך התגברות על מכשולי עלות (Cost), זמני תגובה (Latency) ואיכות. [03:39] מה זה בעצם Harness? המונח "Harness" (או Scaffold) מתייחס לכל התוכנה והלוגיקה שעוטפות את מודל השפה עצמו (שמקבל ופולט טקסט). ההרנס יכול לנוע בין מבנה פשוט מאוד (כמו Assistant שלוקח קלט מהמשתמש וזורק למודל), למערכות מורכבות הכוללות זיכרון, שימוש בכלים חיצוניים, שרשראות חשיבה ואג'נטים. המושג "Model-Harness Fit": אותו המודל יכול להפיק תוצאות שונות לחלוטין בהתאם למעטפת שסביבו. [06:51] הכל מתחיל באוולואציות (Evals) It all starts with evals: אי אפשר לעשות אופטימיזציה בלי למדוד. "Vibe testing" של ניסוי וטעייה לא מספיק כדי להרגיש הבדלים משמעותיים באמת. בנצ'מרקים קיימים (כמו משימות קידוד) פעמים רבות לא משקפים את הטראפיק האמיתי בעולם האמיתי (שכולל גם קריאת PRD, חיפושי אינטרנט ושאלות המשך). כדי לאפטם, חייבים לבנות Test-set רלוונטי ולהתחיל לשחק עם ה"כפתורים" השונים (Knobs): החלפת המודלים עצמם, שינוי פרומפטים, ניהול קונטקסט ועוד. [10:21] אתגר האופטימיזציה ו-"Claude Code ל-Data Scientist" האתגר הגדול: איך בודקים את כל הקונפיגורציות האפשריות ביעילות? מרחב החיפוש הוא כמעט אינסופי וכולל תלויות בלתי צפויות. עבודת Applied Research ידנית לוקחת חודשים ועולה עשרות אלפי דולרים בריצות מודל. AI21 פיתחה סוג של "Claude Code ל-Data Scientist" – סוכן אוטונומי (Auto-Researcher) שעושה Vibresearching יעיל במרחב הקינפוגים ומקצר עבודה של שבועות לחיפוש של שש שעות וקצת דולרים בודדים. קשר אדם-מכונה: האוטו-ריסרצ'ר זקוק למפעיל שינחה אותו ויקבל החלטות עסקיות לגבי הטרייד-אוף שבין עלות (Cost) לאיכות התוצאה. [14:29] "GEPA for Harness" וחיפוש במרחב הקינפוגים הרצת אוולואציות על מטריצה של קונפיגורציות כוללת שילוב של מספר גישות אלגוריתמיות מתקדמות: Hyper-parameter tuning לאזורים רציפים. אלגוריתמים גנטיים, בגישת "GEPA for harness" – לוקחים את הניסויים המוצלחים, מוצאים את המשותף, מאחדים ומוציאים "צאצא" חדש. Multi-arm bandit לאיזון מתמטי בין אקספלורציה (Exploration) לאקספלויטציה (Exploitation). [22:30] מדדי הצלחה: Success @k לעומת Success ^k כשעושים אוולואציות לדברים לא דטרמיניסטיים, חשוב להבין את הסטטיסטיקה: Success @k: מתוך K ניסיונות, כמה פעמים המודל הצליח? (בוחן מובהקות). Success ^k: מה הסיכוי שלאחר K ניסיונות נקבל לפחות הצלחה אחת? Test-time compute scaling: במקום לשנות את המודל, אפשר לעשות שינוי בהרנס – להריץ בקשה 16 פעמים במקביל (Swarm), ולהשתמש ב-Judge מבוסס מודל System 1 (מודלים של סיווג מהיר וזול בהמון) כדי לבחור את התשובה הנכונה ולשפר את האיכות דרמטית. [26:49] המעבר ל-Post-Training כאשר ה-Success @k גבוה מאוד אבל היכולת להצליח בניסיון בודד (Single-shot) נמוכה, זה סימן לפוטנציאל חבוי במשקולות המודל. במקרים כאלו, מומלץ לצאת ל-Post-training ו-Reinforcement Learning (RL) כדי לחזק את הסיגנלים הנכונים. המגמה העסקית: חברות לוקחות מודלי Open-Source קטנים ומאמנות אותם כדי לקבל את האיכות של הפרונטיר מודלס (Frontier models) ברבע מהעלות, תוך שמירה על בידול. [31:24] אינטגרציה וגישת ה-Middleware גישה מבוססת Middleware (Middleware based approach): חברות מספקות סט כלים של Skills או Middleware שהלקוחות יכולים לבדוק וליישם בקלות. איך משנים ומתאימים בזמן אמת (Inference time)? Intelligent Gateway: כלי שיושב באמצע ומנתב את הבקשות בזמן אמת למודל הנכון (Low integration). התממשקות ל-SDKs קיימים (כמו LangGraph) או לפתרונות פנימיים שהארגון בנה. האופטימיזציה מתבצעת בדרך כלל End-to-End בשכבה העליונה, אך יכולה לרדת גם לרזולוציות של Sub-agents פנימיים כדי לדייק את הביצועים. האזנה נעימה!
Reach and audience
Public platform figures. Ratings count people who left a rating, not total listeners.
- Apple Podcasts (US)
- 4.4 / 5
- 5 ratings
- Spotify
- 5.0 / 5
- 23 ratings
Contact רברס עם פלטפורמה
- Guest appearances
- Books guests
Based on episode analysis; this does not confirm that the show is currently accepting guests.
Shows with a similar audience
Questions about רברס עם פלטפורמה
Who hosts רברס עם פלטפורמה?
Ran host the show. Published by רברס עם פלטפורמה.
How often do new episodes come out?
The show publishes bi-weekly, based on its RSS feed.
Does רברס עם פלטפורמה take guests?
Yes. Guests have been identified in episode analyses.
Host of רברס עם פלטפורמה?
Claim your podcast to manage its listing and keep your show details accurate.
Pod Engine is an independent podcast discovery and analytics service and is not affiliated with or endorsed by this podcast. Artwork and show content belong to their owners. Full legal notice.
Explore this show
Podcast research with Pod Engine