מסדי נתונים גרפיים: איך הופכים קשרים בין נתונים לתשתית חכמה ל-AI

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

אם גרפים הם דרך לחשוב על מידע, ידע והקשר, מסדי נתונים גרפיים הם הדרך לשמור, לנהל ולתשאל את המידע הזה בפועל. כאמור זה מרכיב חיוני בהפעלה של סוכני בינה מלאכותית. מסד נתונים גרפי או Graph Database הוא אחד המושגים החשובים ביותר להבנת האופן שבו ארגונים מכינים את הדאטה והמידע הפנימי שלהם כמקור להבנת הסביבה העסקית של הארגון כאשר מפעילים סוכני בינה מלאכותית באמצעות Knowledge Graphs ו-Graph RAG (אשר נדון בהם בפוסטים הבאים).

מסדי נתונים גרפיים

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

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

מדוע בסיס נתונים רלציוני מסורתי אינו מספיק?

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

אבל העולם העסקי לא תמיד שואל שאלות פשוטות על רשומות בודדות.

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

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

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

שלושת הרכיבים המרכזיים של מסד נתונים גרפי

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

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

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

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

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

יתרונות אחזור המידע בבסיס נתונים גרפי

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

• 1 מתחילים מצומת מסוים, למשל לקוח, מוצר, מסמך או נושא.
• 2 משם “הולכים” על הקשרים שמחברים אותו לצמתים אחרים.
• 3 אפשר להמשיך עוד צעד, ועוד צעד, לפי עומק השאלה.
• 4 בסוף מחזירים את הצמתים, הקשרים, המסלולים או הדפוסים שנמצאו.

דוגמא לשאילתה של משתמש: “מצא לי מוצרים שלקוחות דומים לדנה רכשו, אבל דנה עדיין לא רכשה.” בגרף זו שאלה טבעית מאוד. מתחילים בדנה, עוברים ללקוחות דומים, משם עוברים למוצרים שהם רכשו, ואז מסננים מוצרים שדנה כבר רכשה. השאילתה בשפות גרפיות כמו Cypher, שמשמשת בין היתר ב-Neo4j, נראית כמו תרשים של הקשרים:

MATCH (dana:Customer {name: "Dana"})-[:SIMILAR_TO]->(other:Customer)-[:BOUGHT]->(product:Product)WHERE NOT (dana)-[:BOUGHT]->(product)RETURN product

התרגום של השאילתה הזו לשפה טבעית הוא:
1 מצא לקוחה בשם דנה.
2 לך ממנה דרך קשר מסוג “דומה ל” אל לקוחות אחרים.
3 מהלקוחות האלה לך דרך קשר מסוג “רכש” אל מוצרים.
4 החזר רק מוצרים שדנה עצמה עדיין לא רכשה.

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

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

SELECT p.*FROM customers danaJOIN customer_similarity cs ON dana.id = cs.customer_idJOIN purchases pu ON cs.similar_customer_id = pu.customer_idJOIN products p ON pu.product_id = p.idLEFT JOIN purchases dana_purchases ON dana_purchases.customer_id = dana.id AND dana_purchases.product_id = p.idWHERE dana.name = 'Dana' AND dana_purchases.product_id IS NULL;

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

היתרונות של שאילתות גרפיות

לשאילתות גרפיות מספר יתרונות מרכזיים אל מול שאילתות מבוססות SQL במסדי נתונים רלציונים.

היתרון הראשון הוא שאפשר לשאול שאלות על מסלולי הקשרים. לדוגמא: “איזה מסלול מחבר בין תקלה מסוימת למוצר, לגרסה ולצוות שאחראי עליה?”

MATCH path = (issue:Issue {id: $issueId}) -[:AFFECTS]->(product:Product) -[:HAS_VERSION]->(version:Version) -[:OWNED_BY]->(team:Team)RETURN path, issue, product, version, team;

התרגום של השאילתה הזו לשפה טבעית הוא: 1 מצא תקלה מסוימת לפי מזהה.
2 עבור ממנה למוצר שהיא משפיעה עליו.
3 מהמוצר עבור לגרסה הרלוונטית.
4 מהגרסה עבור לצוות שאחראי עליה.
5 החזר את כל המסלול.

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

היתרון השני הוא שאפשר לשאול על עומק משתנה ומוגדר מראש של קשרים. לדוגמא: “מצא לי את כל הגורמים שקשורים לבעיה הזו עד שלושה צעדים ממנה.”

MATCH path = (issue:Issue {id: $issueId}) -[*1..3]- (related)RETURN path, relatedORDER BY length(path);

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

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

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

MATCH (customer:Customer)-[viewed:VIEWED]->(product:Product)MATCH (customer)-[added:ADDED_TO_CART]->(product)MATCH (product)-[:SIMILAR_TO]-(similarProduct:Product)MATCH (customer)-[boughtSimilar:BOUGHT]->(similarProduct)WHERE NOT (customer)-[:BOUGHT]->(product) AND viewed.at <= added.at AND boughtSimilar.at >= added.at AND boughtSimilar.at <= added.at + duration({days: 7})RETURN DISTINCT customer, product AS originalProduct, similarProduct, viewed.at AS viewedAt, added.at AS addedToCartAt, boughtSimilar.at AS boughtSimilarAt;

התרגום של השאילתה הזו לשפה טבעית הוא: 1 מצא לקוח שצפה במוצר.
2 בדוק שהוא גם הוסיף את אותו מוצר לעגלה.
3 בדוק שהוא לא רכש את המוצר המקורי.
4 מצא מוצר דומה לאותו מוצר.
5 בדוק שהלקוח רכש את המוצר הדומה בתוך שבעה ימים ממועד ההוספה לעגלה.
6 החזר את הלקוח, המוצר המקורי, המוצר הדומה וציר הזמן של הפעולות.

זו לא רק שליפה של נתונים. זו זיהוי תבנית התנהגות.

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

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

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

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

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

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

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

לסיכום

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