הסוכן Data ב-ChatGPT Work: המדריך המלא

• 01מה זה Data, ומה זה לאסוכן בתוך Work, לא עוד כלי BI
• 02להתקין ולהתחילארבעה צעדים, ואז ריצה מלאה על נתוני דוגמה: מההקשר ועד הדשבורד
• 03למה זה מתחברמחסני נתונים, קבצים, שכבת ההגדרות וכלי ה-BI
• 04ההקשר הוא המוצרContext skill: מה נותנים לסוכן לפני השאלה הראשונה
• 05איך זה עובד בתוך OpenAIמה צוות הדאטה שלהם עושה אחרת, במספרים
• 06פרומפטים לצוות שיווקשלושה רשמיים, שלוש התאמות, ושאלות ההמשך
• 07מי מדליק, מי רואההרשאות, אישורים, ומה לבדוק לפני שפותחים לצוות
• 08ChatGPT for Financial Servicesהגרסה לבנקים, ולמה היא מעניינת גם מי שלא בפיננסים
• 09החלק הפחות נוחמה עוד לא כתוב, מה בדקתי, ואיפה זה נשבר

זה לא כלי BI חדש, ולא "ChatGPT שיודע אקסל". זה סוכן שיושב בתוך Work, מתחבר למקורות הנתונים שהארגון כבר אישר, ועושה שלושה דברים: בודק מה השתנה, מסביר למה, ובונה מזה דשבורד שאפשר לשתף.

על השם: בהודעה הרשמית הוא Data agent, בספרייה הוא Data, ובפוסט שנזכיר עוד רגע הוא Data plugin. אותו דבר. בשיחה פונים אליו עם @Data.

מה ההבדל מדשבורד

יומיים לפני ההשקה פרסם Vijaye Raji פוסט בלינקדאין על איך צוות הדאטה של OpenAI עובד. Raji הוא ה-CTO of Applications של OpenAI, האחראי על הנדסת המוצר של ChatGPT ושל Codex. לפני כן הקים את Statsig, פלטפורמת ניסויים ש-OpenAI רכשה בספטמבר 2025, ולפני זה עשור ב-Meta. הוא יחזור כאן הרבה, כי הפוסט שלו הוא המקור המעשי ביותר על הכלי.

הוא מתאר את זה מהצד של צוות הדאטה: דשבורדים ענו על השאלות החוזרות, אבל כמעט תמיד הולידו שאלה חדשה. למה המספר השתנה, אילו לקוחות הושפעו, אפשר פילוח אחר. ושאלות ההמשך נחתו אצל מדען נתונים. הסוכן נבנה בדיוק בשביל שאלת ההמשך: שואלים בשיחה, הוא חוקר, ומראה ראיות.

מה הוא מייצר בסוף

• תשובה עם ראיות. מספר עם הטבלה והשאילתה שמאחוריו, לבדיקה.
• דשבורד אינטראקטיבי. הצוות עורך, משתף ומרענן. אפשר לתת לו את הנחיות המותג והוא מיישר את התוצר אליהן.
• המלצה לצעד הבא. מי צריך להיות מעורב, שליחה ב-Slack או במייל, ופעולות שאישרת בכלים מחוברים.

ומה הוא לא: תחליף להגדרות. אם אין הסכמה כתובה מה נחשב "ליד", הוא יבחר פירוש סביר, יכתוב אותו בשורה קטנה, וימשיך בביטחון. הוא טוב בדיוק כמו ההגדרות שמאחוריו, וזה הנושא של פרקים 03 ו-04.

1. לעבור ל-Work. הטוגל Chat / Work בראש המסך. כל מה שבמדריך הזה קורה במצב Work.
2. לפתוח את ספריית ה-Plugins ולחפש Data. בעמוד שלו יש כפתור Install plugin. בארגון, אדמין יכול להתקין אותו לכל הצוות מראש דרך Workspace settings › Plugins.
3. להשלים חיבור חשבון אם מתבקש. חיבורים למחסני נתונים כמו Snowflake או Databricks הם plugins נפרדים, שאדמין מדליק ומגדיר מי רשאי להשתמש בהם.
4. לפתוח שיחה עם @Data ולשאול את השאלה העסקית. ברגע שהוא מזוהה, מופיע צ'יפ Data בתחילת תיבת הכתיבה.

שלושת הפרומפטים לפתיחה, וסדר שונה מהמסך

בעמוד הם מופיעים כך: להתחיל משימה ראשונה, לנתח נתונים ולהמליץ איפה להתמקד, ולהפוך קישורי מדדים והעדפות עבודה ל-Data context לשימוש חוזר. ההמלצה של Vijaye Raji מ-OpenAI (פרק 01) היא סדר אחר: קודם לחבר, אחר כך ליצור את ההקשר, ורק אז לשאול שאלה אמיתית. כלומר 1, 3, 2.

מהמסך, מילה במילה official

כדי להראות מה הוא עושה בלי לחשוף נתונים של אף לקוח, הרצתי אותו בחשבון האישי שלי על קובץ דוגמה סינתטי: 26 שבועות של משפך שיווקי בחמישה ערוצים, עם ירידה מתוכננת בהמרה מ-MQL ל-SQL בערוץ אחד מאמצע אוגוסט. שני פרומפטים באותה שיחה: קודם ההקשר מפרק 04, ואז שאלת האבחון מפרק 06, מותאמת לעמודות שיש בקובץ. המודל: GPT-6 Astra.

שלב 4, הפרומפט האחרון מפרק 06, באותה שיחה: דשבורד. מה שנפתח הוא אפליקציית ווב, לא תמונה ולא קובץ. פילטרים למעלה, תאריך רענון, כפתור Ask וכפתור Publish. מדדתי: קובץ HTML אחד, 2.9MB, שכולל את הנתונים ואת הקוד בתוכו, ורץ מקומית במחשב שלי בתוך הדפדפן המובנה של ChatGPT.

השכבה שרוב הארגונים מדלגים עליה

השורה השלישית בטבלה היא הפחות מוכרת, והכי חשובה. "שכבה סמנטית" נשמע כמו עניין של מהנדסי דאטה, אבל זה המקום שבו כתוב מה זה ליד, ממתי לקוח נחשב נוטש, ובאיזה מטבע מחשבים הכנסות. OpenAI כותבת במפורש שהסוכן משתמש במונחים העסקיים ובהגדרות המדדים של הארגון כדי לפרש את הנתונים. אם אין כאלה, הוא בוחר פירוש, מציין אותו, וממשיך.

בשיווק זה קונקרטי. "המרה" יכולה להיות מילוי טופס, פגישה שנקבעה או עסקה שנסגרה, ושלושה אנשים באותו צוות יענו שלוש תשובות. הסוכן יבחר אחת. השאלה היא רק אם את בחרת אותה בשבילו. ואם אין dbt ואין Genie, נותנים לו את ההגדרות ידנית, כ-Data context. זה הפרק הבא.

ההנחיה של Vijaye Raji, ה-CTO of Applications של OpenAI, לארגונים שמתחילים היא בת שלוש שורות, והיא הדבר הכי שימושי בכל ההשקה: להתחיל מתחום עסקי אחד שמכירים היטב, לחבר את הנתונים שלו, ולתת לסוכן את הרקע שהיית נותנת לאנליסט חדש. איפה הנתונים, איך מגדירים את המדדים, ומה הצוות מנסה להשיג.

את הרקע הזה שומרים כ-context skill, וזה מה שהפרומפט השלישי בעמוד ה-plugin עושה. ואז שואלים שאלה אמיתית מהשבוע הזה. בודקים את התשובה כמו שבודקים עבודה של קולגה. אם הוא השתמש במדד הלא נכון או פספס משהו, מתקנים ושומרים את התיקון חזרה ל-skill. במילים שלו: לא אמורים להסביר את אותו דבר כל פעם מחדש.

מה נכנס ל-context skill של צוות שיווק

נקודת פתיחה ל-context skill התאמה שלי

שלוש טעויות בכתיבת ההקשר

• לכתוב מה המדד אומר, לא איך מחשבים אותו. "לקוחות פעילים" זו כותרת. "כניסה אחת לפחות ב-30 יום, לא כולל חשבונות פנימיים" זו הגדרה שסוכן יכול לעבוד איתה.
• לדלג על מה שלא סופרים. רוב הפערים בין "המספר של השיווק" ל"המספר של המכירות" הם החרגות שאף אחד לא כתב.
• לכתוב פעם אחת ולשכוח. הגדרה משתנה כשמוצר משתנה. בלי בעלים ל-skill הוא מתיישן בשקט. הבעלים: מי שמדווח על המדד להנהלה ונשאל עליו כשהוא זז.

מה נשמר בפועל: קובץ, לא "זיכרון"

ביקשתי לראות את מה שנשמר. זה לא הגדרה עמומה איפשהו בהגדרות, אלא קובץ skill קריא: markdown עם שם ותיאור למעלה, ואז סעיפים. הנחיות עבודה, כללי זמן והשוואה, היעד והמעקה של הרבעון, ולבסוף טבלאות: ישויות, מדדים, פילטרים, ממדים, מלכודות, שאלות פתוחות ומקורות. אפשר לפתוח, לתקן ולשלוח למישהו.

• יש היררכיה מובנית. Individual מעל Team מעל Business unit מעל Company. ההקשר של הצוות גובר על של החברה, ושל האדם על של הצוות. זו שאלת הבעלות מפרק 03, רק שהפעם המוצר כופה אותה.
• הוא כתב לעצמו כללים שלא ביקשתי. "Do not silently carry this dated goal into later quarters". ורשם ב-Open Questions מה לא ידוע (קריטריוני qualification, חותמות זמן) כדי לא להמציא אותם בשאלה הבאה.
• שמירה היא לא הפצה. "It is not installed for automatic use in other tasks or shared with teammates". כדי שהצוות יעבוד עם אותן הגדרות צריך צעד נוסף, וזה בדיוק המקום שבו רוב הארגונים ייעצרו.
• לקרוא לפני שמשתפים. בסעיף Sources הוא רשם את הנתיב המלא של הקובץ במחשב שלי. skill הוא מסמך, ומסמכים בודקים לפני שהם יוצאים החוצה.

הסיפור המעניין הוא לא שהמודל כותב SQL. זה שצוות דאטה רזה תומך במוצר עם יותר ממיליארד משתמשים שבועיים בלי לגדול ביחס לעסק, ושהוא עשה את זה בשני מהלכים מקבילים: מדעני הנתונים מאצילים חלקים מהעבודה שלהם לסוכנים, ושאר החברה עונה על יותר שאלות לבד.

ארבעה דברים שהם עושים ושווה להעתיק

• הסוכן קורא את ההחלטות, לא רק את הטבלאות. חיברו לו Slack, Google Drive, Notion, Gmail, Salesforce ו-Gong, כדי שיבין למה החלטה התקבלה ולא רק מה קרה אחריה.
• סוכן בערוץ ה-Slack שבו כבר שואלים. הוא עונה ראשון, מדען נתונים מאשר או מתקן, והתיקון נשאר לשאלה הבאה. דוגמה מהפוסט: שאילתה לרשימת תפוצה של משתמשי Realtime API נכתבה תוך חמש דקות ואושרה על ידי אדם.
• כל הדשבורדים הם אפליקציות ווב. כולל דשבורדי ההנהלה. מגדירים את השאלות שהדשבורד צריך לענות עליהן, והסוכן בונה ומשפר. ככה מחברים נתונים מובנים מהמחסן עם טקסט מטיקטים ומ-Slack באותו מסך.
• הזמן שנחסך הולך לעומק, לא לעוד דוחות. ניתוח שהיה לוקח שבועות לוקח שעות עד ימים, ומדעני הנתונים משתמשים בזמן לניסויים סטטיסטיים ולבניית פרוטוטייפים ב-Codex. הגבול בין להמליץ על שינוי לבין לבצע אותו מיטשטש.

לאבחן שינוי במדד official

אותו מבנה, על משפך שיווקי התאמה שלי

לעצב מסגרת מדדים official

מסגרת מדדים לקמפיין חדש התאמה שלי

דיווח להנהלה official

אותו דיווח, כדשבורד שמתעדכן התאמה שלי

שאלות ההמשך: כאן נמצא הערך

הפרומפט הראשון פותח את החקירה. הערך נמצא בשאלות שבאות אחריו, וזה בדיוק המקום שבו דשבורד רגיל נעצר. Raji מתאר בפוסט שלו איך הצוות ב-OpenAI עובד: בודקים את הראיות, מאתגרים הנחות ומסקנות, ומבקשים מהסוכן לבחון הסברים אחרים. ממשיכים עד שאפשר להמליץ בביטחון.

שש שאלות המשך שעובדות על כל ניתוח התאמה שלי

המודל של OpenAI כאן פשוט, ושווה להבין אותו לפני שה-IT מסביר אותו בישיבה. אדמין בוחר אילו חיבורי נתונים זמינים ואילו תפקידים רשאים להשתמש בהם. והשאילתות של הסוכן מכבדות את ההרשאות הקיימות של החשבון המחובר, כולל הגבלות ברמת טבלה, שורה ועמודה. ופעולות, כמו שליחת ממצא ב-Slack או שינוי בכלי מחובר, קורות רק אחרי שאישרת אותן.

כלומר הסוכן לא רואה יותר ממה שהמשתמש היה רואה בעצמו. החלק הפחות מרגיע: ברוב הארגונים אף אחד לא יודע מה המשתמש היה רואה בעצמו, כי אף אחד לא שאל את המחסן שאלה חופשית עד עכשיו.

יש כאן שתי שכבות נפרדות: Data עצמו, שאפשר להתקין לצוות אחד בלבד, והחיבורים למחסנים, שכל אחד מהם plugin נפרד עם הרשאות משלו.

מה קורה כשלוחצים Publish

בסוף הדוגמה בפרק 02 לחצתי על Publish בדשבורד, רק כדי לראות מה נפתח. לא פרסמתי. זה מה שמופיע, ושלוש השורות הקטנות בו הן התשובה לשאלה של הפרק הזה:

• הצופים רואים רק מה שפורסם. לא את מקור הנתונים. מי שקיבל את הדשבורד לא קיבל גישה ל-Snowflake.
• מי שרוצה להמשיך לחקור צריך הרשאות משלו. "Viewers iterating on it require their own permissions to access source data". הדשבורד הוא חלון, לא דלת.
• שתי רמות בלבד בשלב הזה. מוזמנים בלבד, או כל מי שב-workspace עם הלינק. אין כאן "כל הארגון חוץ מ..." ואין פרסום החוצה מהתיבה הזו.
• עורכים יכולים לקבוע אוטומציה לעדכון. כלומר הדשבורד יכול להתרענן בלי שמישהו נכנס לשיחה, וזה בדיוק המקום שבו הגדרה שהתיישנה ממשיכה לחיות בשקט.

אם את לא בפיננסים אפשר לדלג, אבל כדאי לא, כי זה מראה לאן כל הסיפור הולך. הגרסה הזו היא ChatGPT Work עם נתונים פיננסיים מובנים, תבניות של הפירמה, ו-GPT-6 Astra, ארוזים למקצוע אחד.

למה זה נוגע גם למי שלא בבנק

הנוסחה ניתנת להעתקה: מצב Work, פלוס נתונים שהמקצוע סומך עליהם, פלוס התבניות שהפירמה כבר עובדת בהן. OpenAI כותבת שהעבודה עם השותפים תכוון התרחבות לקטגוריות נוספות בפיננסים. ההערכה שלי, לא נתון: כל מקצוע עם ספקי נתונים ותבניות מקובלות הוא מועמד לאותה אריזה, ושיווק, עם ספקי מדידה ותבניות דיווח, נמצא ברשימה.

מה שהתיעוד לא אומר

• מגבלות שימוש. עמוד ההשקה לא מפרט כמה שאילתות, כמה זמן ריצה, או מה קורה כשנגמרת המכסה באמצע חקירה.
• איזה מסלול מקבל מה. ההודעה מדברת על "לקוחות ChatGPT Work". בפועל, בחשבון אישי, הוא רץ אצלי מקצה לקצה על קובץ שהעליתי (פרק 02). חיבורים למקורות נתונים ארגוניים כן דורשים אדמין.

איפה זה נשבר, גם כשהכל מותקן נכון

• הגדרות שקיימות רק בראש של אנשים. הסוכן לא יכול להשתמש בהגדרה שלא נכתבה, אז הוא בוחר אחת סבירה, כותב אותה בשורה קטנה, ומדווח בביטחון. השורה הקטנה והראיות הן ההגנה היחידה, ורק אם קוראים אותן.
• הרשאות שנבנו לדשבורד, לא לשאלה חופשית. דשבורד מראה מה שבנו לו. שאלה חופשית מגיעה לכל מה שהחשבון רואה, והרשאות שהיו "בסדר" מתגלות כבסדר רק כי אף אחד לא הסתכל.
• ניסוי מוצלח שלא הופך לשגרה. ההדגמה מרשימה, ואז אף אחד לא אחראי על ה-context skill, ההגדרות מתיישנות, והתשובות סוטות בשקט.

לא לחבר את כל המחסן. לבחור מדד אחד שאת מדווחת עליו כל שבוע, שאת מכירה מספיק טוב כדי לזהות תשובה שגויה תוך שלושים שניות. לכתוב את ההגדרה שלו במשפט אחד, כולל מה לא נספר. ולשמור אותה כ-context.

1. תחום אחד. משפך הלידים, או הוצאות המדיה, או הנטישה. לא שלושתם.
2. הגדרה אחת בכתב. אם לוקח יותר מעשר דקות להסכים עליה בצוות, מצאת את הבעיה האמיתית, והיא לא הסוכן.
3. שאלה אחת מהשבוע הזה. לא "מה מעניין בנתונים", אלא "למה ה-SQL ירדו בשבועיים האחרונים".
4. לפתוח את הראיות. לפני שמאמינים למספר הראשון.
5. תיקון אחד שנשמר. הוא יטעה במשהו. התיקון הזה, שמור חזרה ל-skill, הוא הרגע שבו זה הפסיק להיות ניסוי.

הכלים ימשיכו להשתנות כל חודש. מה שלא משתנה הוא מי בארגון יודע להגדיר מדד בכתב, לזהות תשובה שגויה, ולהחליט מי רואה מה. אלה לא מיומנויות של כלי. אלה מיומנויות של ניהול, והן נשארות רלוונטיות גם כשהמודל הבא יוצא.