522 - Company brain with Shmulik from Lusha

בפרק 522 של רברס עם פלטפורמה, רן ואורי מארחים את שמוליק וילינגר, ה-Chief Architect של חברת Lusha, לשיחה מרתקת על בניית “מוח ארגוני” (Company Brain). נדבר על למה בכלל צריך את זה בעידן ה-AI, מה גרם להם לבחור לבנות את המערכת בעצמם (Build vs. Buy), ואיך גורמים לסוכנים אוטומטיים להכיר את כל ההקשרים והסודות של החברה בלי לשבור מנגנוני הרשאות.

[01:51] קצת על לושה והרקע של שמוליק

• שמוליק התחיל את הקריירה לפני כ-20 שנה, עבר בסטארט-אפים וחברות גדולות, והיום מוביל את הארכיטקטורה ושילוב ה-AI בלושה.
• Lusha היא חברת Business Intelligence שבונה פרופילים מדויקים של חברות ואנשי מקצוע (טלפונים, סיגנלים, אינטגרציות למיילים ול-CRM).
  • בין הלקוחות של החברה אפשר למצוא ענקיות כמו Spotify, Google, ו-Palo Alto Networks.
• החברה משלבת המון כלי AI וסוכנים (Agents) גם כחלק מהמוצר ללקוחות הקצה (למשל עבור SDRs שמחפשים לידים) וגם בתהליכי הפיתוח הפנימיים.

[04:12] איך נולד הצורך במוח ארגוני? (הטריגר)

• הצורך התחדד כשראו את ההשפעה של כלי ה-AI על פיתוח. המפתחים הואצו (10x), אבל צוואר הבקבוק עבר לאנשים עצמם.
  • במקום שהקוד יהיה החסם, החסם הפך להיות ההקשר (Context): הבנת הדרישות, האילוצים העסקיים והשלכות של שינויים רוחביים.
• סוכנים יכולים לכתוב מסמכי PRD או קוד במהירות, אבל בלי קונטקסט של “למה הוחלט ככה?” או “מי הלקוחות שמושפעים מזה?” הם עוצרים או גרוע מכך - ממציאים (הזיות).
• ידע ארגוני נמצא אצל מהנדסים ואנשי מוצר ותיקים. במקום ש-Agent “ידפוק לאנשים על הכתף” לשאול שאלות, צריך להנגיש לו את התורה שבעל-פה.

[09:10] Buy vs. Build: למה לבנות לבד?

• החברה בחנה את השוק ושוחחה עם כ-18 ספקים שונים שהציעו פתרונות למוח ארגוני.
  • חלק מהפתרונות היו מורכבים מדי או יצרו סכנה אמיתית של Vendor Lock-in.
• ההחלטה ללכת על פיתוח עצמי (Build) נבעה גם מההבנה שהשוק עוד בהתהוות.
  • ההנחה היא שחברות כמו OpenAI ו-Anthropic יוציאו בקרוב פתרונות מובנים משלהן למוח ארגוני, ולכן עדיף לבנות תשתית גמישה פנימית עכשיו שיהיה אפשר לנתב החוצה בעתיד בקלות.
• הגישה: להתחיל בקטן וללמוד תוך כדי תנועה מה עובד ומה לא.

[11:14] מי משתמש במוח ואיך מכניסים אליו דאטה (Data Ingestion)

• קהל היעד הוא כל הארגון, אבל התחילו ממיפוי של מחזור חיי הפיתוח (SDLC) כדי להבין מי הפרסונות.
• המקורות: GitHub (מעל 960 Repositories), טיקטים ב-Jira, מסמכים ב-Confluence, ערוצי Slack, ואפילו תמלולים וסיכומים אוטומטיים של פגישות וידאו מתוך החברה.
• המימוש הראשוני: תיקייה עם אלפי קבצי Markdown (MD) מסודרים בהיררכיה עם קובץ קטלוג שמשמש כתוכן עניינים למודל.

[13:43] מוחות נפרדים, אבטחה והרשאות (Access Management)

• הגישה למסמכים מתבצעת על ידי הרצת Skill מקומי או דרך שרת MCP (Model Context Protocol) ייעודי.
• תובנה מרכזית: לא מספיק “מוח אחד” לכולם. לארגון ה-Delivery יש צרכים שונים מאשר לארגון ה-Sales.
  • מוח ה-Sales יתחבר למערכות כמו Salesforce או HubSpot ויהיה המומחה לתמחור ומתחרים.
  • מוח ה-Delivery יתחבר לקוד ולארכיטקטורה.
• הפרדת רשויות: בעלות על ידע מופרדת מהרשאות. מפתח לא צריך לראות נתוני תשלום של לקוחות, ואיש מכירות לא צריך גישה לקוד. אם מוח אחד צריך מידע מדומיין אחר, המוחות מתקשרים ביניהם (אנקפסולציה) מבלי לחשוף את מערכות המקור למשתמש הקצה.

[19:31] מה לא עבד? המעבר משכבת Markdown לאונטולוגיה

• אוסף של קבצי MD התגלה כפתרון חסר. המודל התקשה לעשות חיבורים היסטוריים וסמנטיים.
  • דוגמה: פיצ’ר שהיה קרוי בעבר “List”, שונה ל-”Uno” והיום נקרא “Workspace”. קבצי MD יראו אותם כישויות נפרדות, למרות שמבחינת העובדים הוותיקים זה אותו מוצר.
• השלב הבא: בניית שכבת אונטולוגיה מפורשת לקישור ישויות, ושכבה סמנטית.
  • שימוש ב-PostgreSQL כדאטה-בייס רלציוני לאונטולוגיה, ו-PGVector לשכבה הסמנטית (Embeddings).
  • תהליך Build יומי סורק את המערכות ומעדכן את הוקטורים, תוך ניסיון לתת משקל נמוך יותר למידע ישן (כדי למנוע הזיות על מערכות שכבר עברו Deprecation, כמו Cassandra או Snowflake).

[25:05] ניטור, בדיקות איכות ומדידת הצלחה

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

האזנה נעימה!