ה-AI שלכם עלול להפוך אתכם לשבויים של ספק
כל ספק AI מוכר היום "קונטקסט" — מ-Salesforce שהוציאה 8 מיליארד דולר על Informatica ועד IBM שרכשה את Confluent ב-11 מיליארד. אבל הגישות שונות לגמרי: הגדרה מראש, שליפה מהנתונים, metadata, וממשל. המלכודת: אם לא תיקחו בעלות על שכבת ההגדרות של הנתונים שלכם, אתם הופכים לשבויים של הפלטפורמה.
כשכולם מוכרים "קונטקסט" — מי באמת מחליט מה המילים שלכם אומרות?
בשנתיים האחרונות שמעתם את המילה "קונטקסט" בכל כנס, בכל גיוס, בכל מצגת. אבל מה שמעניין זה לא מי אומר אותה — אלא מה הוא מנסה למכור לכם. כי מאחורי המילה הזו מסתתרים גישות שונות לחלוטין, ובחירה לא נכונה יכולה להפוך אתכם לשבויים של ספק אחד.
נתחיל מהמציאות: מודל בינה מלאכותית ינפק לכם תשובה שוטפת ובטוחה בעצמה בלי לדעת מספיק על העסק שלכם כדי שהתשובה הזו תהיה נכונה. קונטקסט הוא מה שמגשר על הפער. זה המידע שהמערכת שולפת רגע לפני שהיא פועלת.
קחו דוגמה: נציג תמיכה עומד לאשר החזר כספי. הוא צריך את מדיניות ההחזרים, את היסטוריית הלקוח, מידע על המוצר, ואת החוק שמאשר את החריגה. תנו לו פרט אחד שגוי — והתשובה תחזור בטוחה ו... שגויה. כשמדובר בטיוטת אימייל, זה מטרד. כשה-AI מורשה לבצע החזרים בפועל או לעדכן תחזית מכירות — הטעות הזו עולה כסף רב.
8 מיליארד דולר על "קונטקסט"
ה-vendors לא רק מדברים — הם משקיעים כסף רציני.
IBM שילמה כ-11 מיליארד דולר על Confluent כדי להניח מידע בזמן אמת מתחת לסוכנים שלה. Salesforce הוציאה כ-8 מיליארד דולר על Informatica לבסיס נתונים מנוהל מתחת לפלטפורמה שלה. ואלה רק שתיים מהעסקאות הגדולות.
העניין הוא שקונטקסט זו מילה רופפת. חברות שעובדות ב-storage, מסדי נתונים, BI, observability, הגנת נתונים, ממשל, אבטחה ויישומי עסקים — כולן טוענות שהן מוכרות קונטקסט. וכולן צודקות. אבל אם תשאלו אותן איך הן מייצרות אותו — הן יתפצלו מהר מאוד.
שלוש גישות, שלוש מלכודות
מחנה 1: הגדר מראש (Semantic Layer + Ontology)
הגישה הזו אומרת: תחליטו מה המונחים שלכם אומרים ותכתבו את זה במקום מרכזי אחד. "לקוח פעיל" מקבל הגדרה אחת, לא חמש סותרות מפוזרות על גבי dashboards שונים.
זה ה-semantic layer המוכר, ומובילי אנליטיקה כמו Qlik, ThoughtSpot ו-Domo מכרו אותו שנים. עכשיו הם קוראים לזה "קונטקסט ל-AI".
קחו את זה צעד קדימה ותגיעו ל-ontology — מפה של איך כל העסק מחובר, כדי שהתוכנה תוכל לעקוב משרשרת מלקוח להזמנה למוצר לחוזה לניחושים.
Palantir בנתה על זה את העסק שלה — מודלים של כל הפעילות של חברה לפני שמשחררים AI. היתרון: אמון. מערכת שמחפשת הגדרה מוגדרת לא מנחשת. החסרון: מידול עסקי ידני תמיד היה איטי ויקר, וזה הדבר הראשון שיחתכו כשהתקציבים יתקמצנו.
מחנה 2: חלץ מהנתונים (Retrieval-Augmented Generation)
כאן אומרים שהמידול מראש איטי מדי, ושמים את הכסף על המודל. מפנים AI למסמכים, טיקטים ולוגים ונותנים לו לשלוף מה שנראה רלוונטי.
זו הגישה של retrieval-augmented generation (RAG). זו הסיבה שבכלל הופיע תפקיד חדש השנה — context engineer — כדי לעצב מה סוכן רואה ומתי.
היתרון: מהירות. אין פרויקט מידול של שנה. מפנים את ה-AI לנתונים ויוצאים לדרך.
הבעיה מופיעה בפרודקשן: מודל ששולף טקסט שמזכיר את השאלה עדיין לא מבין איך העסק עובד. הוא ממציא קשרים שלא קיימים, ו-retrieval חד-שלבי מתקשה ברגע שמשימה דורשת יותר מקפיצה אחת.
גרסאות חדשות של agentic retrieval ו-graph-based retrieval מטפלות בזה — אבל הן עושות את זה על ידי הוספת מבנה מחדש. לאיזה צרכן שרוצה עזרה יומיומית מהירה, retrieval עובד בסדר גמור, כל עוד אתם סוקרים את התשובות ומזהים כשמשהו לא נכון. לעסק? זה הופך למכירה קשה יותר ויותר כשלעצמה.
מחנה 3: תשתיות ו-metadata
Dell, NetApp ו-Everpure (לשעבר Pure Storage) טוענים שלפני שאתם יכולים להגדיר משמעות או להסיק אותה, אתם צריכים למצוא את הנתונים שלכם, לסמן אותם ולהעביר אותם למודל מהר מספיק כדי לשמור את השבבים היקרים עסוקים.
המטבע שלהם הוא metadata — הנתונים על הנתונים שלכם. התאריך, שיטת התשלום וסטטוס האחריות של הזמנת ההחזר — אלה עוזרים לתאר את הרשומה בלי להיות הרשומה.
אבל metadata לבדו לא מספיק. התאריך, שיטת התשלום וסטטוס האחריות עדיין לא אומרים למודל אם הלקוח נחשב "פעיל", אם ההחזר יוצא מה-net revenue, או איזה חוק מאפשר לאישור. המשמעות הזו באה מהגדרת מונחים מראש — ואין כמות metadata שמפיקה אותה.
מחנה 4: ממשל ואיכות נתונים
Collibra, Alation, Atlan וחברות observability כמו Acceldata ו-Monte Carlo טוענות שקונטקסט שה-AI לא יכול לערוב לו הוא חבות. אם סוכן פועל על נתונים מיושנים, שגויים או כאלה שאין למשתמש מסוים גישה אליהם — מודל מהיר יותר פשוט מגיע לתוצאה הגרועה יותר מהר.
Informatica מכרה את עצמה כשכבת הנתונים המהימנה שיושבת מתחת לערימת ה-AI של כולם.
היתרון של הפלטפורמות — והמלכודת
השחקנים הגדולים לא צריכים לבחור רק גישה אחת; הם מארחים את כולן. Snowflake, Databricks, Oracle ומנועי הנתונים בתוך Google, Microsoft ו-AWS בונים קונטקסט ישירות על גבי הנתונים שכבר מאוחסנים אצלם — בזמן שכולם צריכים קודם לגשת לנתונים האלה ולשמור אותם עדכניים.
Snowflake מפרידה בין קונטקסט שהלקוח מכריז עליו לבין קונטקסט שהפלטפורמה מפיקה לבד. Databricks הניחה knowledge graph מתחת לכלי ה-Genie שלה. Microsoft קוראת לגרסה שלה Fabric IQ. Google Cloud מיתגה את אותו רעיון דרך Agentic Data Cloud ו-Knowledge Catalog.
רוב ההיצע הזה עדיין בשלב preview, וההבטחה שכל סוכן ירש את ההגדרות שלכם מתארת לאן המוצרים האלה הולכים יותר מאשר איפה הם נמצאים היום. תפילו אחד מהם לארגון אמיתי — והדבר הראשון שיחשף זה כמה לא עקביות ההגדרות הקיימות שלכם.
אז מי שולט לכם בקונטקסט?
ויש סוג אחר של שחקן — חברות היישומים. הן מוכרות קונטקסט על איך החברה שלכם עובדת, לא מה הנתונים שלכם אומרים. Microsoft, דרך Copilot, ממפה איך האנשים, הקבצים והפגישות שלכם מתחברים. Salesforce מחברת נתוני לקוחות ישירות מתחת לסוכנים שלה. ServiceNow עושה את אותו הדבר בתוך ה-workflows שלה — ולכן קנתה את data.world.
ההבטחה מכולם: הנוחות. העבודה שלכם כבר אצלנו — בואו נפעיל לכם את הקונטקסט.
והמלכודת: השכבה שגורמת לכל ה-AI שלכם להיות שימושי, אז שייכת לספק — ולא לכם.
מה זה אומר עלינו?
האזהרה ברורה: ארגונים חייבים לקחת בעלות על שכבת ההגדרות של הנתונים שלהם. אם "לקוח פעיל" מוגדר ב-Salesforce, ה-net revenue מחושב ב-Databricks, ומדיניות ההחזרים יושבת במסמך SharePoint — אתם בבעיה.
אף ספק לא יפתור לכם את זה. ה-semantics, ה-ontology, המפה של איך העסק שלכם עובד — אלה צריכים להיות שלכם, ניידים, נגישים לכלים שונים.
ועם ההשקעות העצומות שאנחנו רואים — 11 מיליארד דולר פה, 8 מיליארד דולר שם — ברור שה-vendors משקיעים בקונטקסט לא כדי לעזור לכם לנייד אותו החוצה. הם בונים את החומה.
כשאתם בוחרים פלטפורמה, תשאלו שאלה אחת: אם מחר נרצה לעבור, כמה מההגדרות, ה-ontology ומבנה הקונטקסט שלנו יוצאים איתנו?
כי בעולם שבו כולם מוכרים "קונטקסט" — מי שבאמת שולט בו שולט בכם.