בפוסט החמישי והאחרון הזה בסדרה שלנו על חיזוי קישורים באמצעות Neptune ML, אנו צוללים לתוך תהליך ההסקה: הגדרת נקודת קצה לשימוש במודל ה-GNN המיומן שלנו לחיזוי קישור. כדי לקבוע את נקודת הקצה, נשתמש ב-API של אשכול Neptune ובחפצי המודל המאוחסנים ב-S3. עם נקודת הקצה פעילה, נבקש ממנה חיזוי קישורים, באמצעות שאילתת גרמלין כדי לזהות קשרים פוטנציאליים בעלי ביטחון גבוה בגרף שלנו. עד עכשיו, כבר טענו את נתוני הרשת החברתית של Twitch לאשכול נפטון (כמתואר בחלק 1 של סדרה זו), ייצאנו את הנתונים באמצעות פרופיל ML (עיין בחלק 2 לפרטים), עבדנו מראש את הנתונים (כפי שהוסבר בחלק 3), אימנו את המודל (ראה חלק 4), ועכשיו אנחנו מוכנים להשתמש במודל המאומן כדי ליצור תחזיות. קרא את חלק 1 ; חלק 2 ; כאן; וחלק 4 . כאן כאן חלק 3 כאן יצירת נקודת הקצה בואו ניצור את נקודת הסיום באמצעות ה-API של האשכול וחפצי המודל שיש לנו ב-S3. כרגיל, אנו זקוקים תחילה לתפקיד IAM שיש לו גישה ל-S3 ול-SageMaker. לתפקיד חייבת להיות גם מדיניות אמון המאפשרת לנו להוסיף אותו לאשכול נפטון (את מדיניות האמון ניתן למצוא בחלק 3 של מדריך זה). אנחנו גם צריכים לספק גישה ל-SageMaker ול-CloudWatch API מתוך ה-VPC, אז אנחנו צריכים את נקודות הקצה של VPC כפי שהוסבר בחלק 1 של סדרה זו. בוא נשתמש בממשק ה-API של האשכול כדי ליצור נקודת קצה של הסקת מסקנות עם פקודת הסלסול הזו: curl -XPOST https://(YOUR_NEPTUNE_ENDPOINT):8182/ml/endpoints \ -H 'Content-Type: application/json' \ -d '{ "mlModelTrainingJobId": YOUR_MODEL_TRAINING_JOB_ID, "neptuneIamRoleArn": "arn:aws:iam::123456789012:role/NeptuneMLNeptuneRole" }' אנו יכולים להשתמש בפרמטרים ' ' ו' ' כדי לבחור את סוג המופע EC2 שישמש לחיזוי קישור, ולפרוס יותר ממופע אחד. את רשימת הפרמטרים המלאה ניתן למצוא . נשתמש במופע ברירת המחדל ' ' מכיוון שיש לו מספיק מעבד ו-RAM עבור הגרף הקטן שלנו, וסוג מופע זה הומלץ ב- שנוצר לאחר אימון מודל בשלב הקודם שלנו: instanceType instanceCount כאן ml.m5(d).xlarge infer_instance_recommendation.json { "disk_size": 12023356, "instance": "ml.m5d.xlarge", "mem_size": 13847612 } ה-API מגיב עם מזהה נקודת הקצה של ההסקה: {"id":"b217165b-7780-4e73-9d8a-5b6f7cfef9f6"} אז נוכל לבדוק את המצב של נקודת הסיום עם הפקודה הזו: curl https://YOUR_NEPTUNE_ENDPOINT:8182/ml/endpoints/INFERENCE_ENDPOINT_ID?neptuneIamRole='arn:aws:iam::123456789012:role/NeptuneMLNeptuneRole' וברגע שהוא מגיב ' ככה, ב'סטטוס: InService { "endpoint": { "name": "YOUR_INFERENCE_ENDPOINT_NAME-endpoint", "arn": "...", "status": "InService" }, "endpointConfig": {...}, "id": "YOUR_INFERENCE_ENDPOINT_ID", "status": "InService" } זה אומר שאנחנו מוכנים להתחיל להשתמש בו עם שאילתות מסד נתונים. ניתן להציג ולנהל את נקודת הקצה גם ממסוף AWS, תחת SageMaker -> Inference -> Endpoints. שאילתה על נקודת הקצה בואו נשתמש בנקודת הקצה כדי לחזות קישורי 'עקוב' חדשים בגרף. על מנת לעשות זאת, עלינו לבחור את קודקוד המקור של הקישורים החדשים האפשריים. זה עוזר אם לקודקוד המקור כבר יש קישורים, אז נשתמש בשאילתה זו כדי לקבל את הקודקוד עם המספר הגבוה ביותר של קישורים קיימים (חיבורי outE ו-inE): gV() .group() .by() .by(bothE().count()) .order(local) .by(values, Order.desc) .limit(local, 1) .next() התוצאה היא {v[1773]: 1440} מה שאומר שלקודקוד עם ID = 1773 יש 1440 חיבורים (720 inE ו-720 outE). כדי לקבל את מספר הקצוות שמתחילים בצומת 1773 ואת מספר הקצוות המסתיימים בצומת זה, נוכל להשתמש בשאילתות הבאות: gV('1773').outE().count() gV('1773').inE().count() אותו מספר של חיבורי inE ו-outE צפוי מכיוון שמערך הנתונים הראשוני מכיל חברויות הדדיות, והגדלנו את הנתונים בקצוות הפוכים כדי לגרום להם לעבוד עם גרף מכוון נפטון. עכשיו בואו נקבל את הקשרים החזויים. לשם כך, נריץ שאילתת גרמלין עם . ובתפקיד SageMaker שנוסף לאשכול ה-DB , תוך אי הכללת המשתמשים שמשתמש 1773 כבר עוקב אחריהם: פרדיקטים של Neptune ML אנו נשתמש בנקודת הסיום כדי להביא את המשתמשים שמשתמש 1773 עשוי לעקוב אחריהם עם סף ביטחון (סבירות מינימלית לקיום קישור לפי המודל) של לפחות 0.1 (10%) %%gremlin g.with('Neptune#ml.endpoint', 'YOUR_INFERENCE_ENDPOINT_NAME') .with('Neptune#ml.iamRoleArn', 'arn:aws:iam::123456789012:role/NeptuneMLSagemakerRole') .with('Neptune#ml.limit', 10000) .with('Neptune#ml.threshold', 0.1D) .V('1773') .out('follows') .with('Neptune#ml.prediction') .hasLabel('user') .not( __.in('follows').hasId('1773') ) זה מחזיר 4 תוצאות: "Result" "v[755]" "v[6086]" "v[6382]" "v[7005]" אולי נוכל לשפר את המודל על ידי הגדלת מספר משרות ההדרכה לפחות ל-10 כפי שהומלץ על ידי AWS, ולאחר מכן להשוות את הביצועים של המודל המתקבל והקישורים החזויים. באפליקציות אמיתיות, הוספת פרופיל משתמש ונתוני פעילות לגרף גם משפרת את דיוק הניבוי. לפי המודל שלנו, יש לפחות 10% סיכוי שמשתמש 1773 יעקוב אחר כל אחד מארבעת המשתמשים הללו. ניתן להשתמש בחיבורים חזויים במערך נתונים של רשתות חברתיות כדי לספק המלצות מותאמות אישית כמו הצעות חברים ותוכן, שיפור מעורבות המשתמש וצמיחת הקהילה, הפחתת נטישה ומתן נתונים נוספים לפרסום ממוקד. למרות שהחלנו חיזוי קישור על מערך נתונים של רשתות חברתיות, זה רק אחד מני יישומים אפשריים רבים של טכנולוגיה זו. ממנועי המלצות ועד לאופטימיזציה של רשתות, חיזוי קישורים הוא כלי רב תכליתי שמביא ערך על ידי חשיפת קשרים נסתרים בתוך נתונים. ככל שיישומים מבוססי גרפים ממשיכים להתרחב, הפוטנציאל של חיזוי קישור בין תעשיות מבטיח תובנות חדשות, יעילות וחוויות משתמש משופרות.
