אוטומציה של בדיקת ניצול של תביעות ביטוח בריאות באמצעות AI גנרטיבי

Last reviewed 2024-08-19 UTC

במסמך הזה מתוארת ארכיטקטורת הפניה לחברות ביטוח בריאות שרוצות להפוך לאוטומטיות את תהליכי הטיפול בבקשות לאישור מראש (PA) ולשפר את תהליכי בדיקת הניצול (UR) שלהן באמצעות Google Cloud. התוכנית מיועדת למפתחי תוכנה ולאדמינים של תוכניות בארגונים האלה. הארכיטקטורה הזו עוזרת לספקי תוכניות בריאות לצמצם את ההוצאות האדמיניסטרטיביות, לשפר את היעילות ולשפר את תהליך קבלת ההחלטות באמצעות אוטומציה של הכנסת נתונים ושל חילוץ תובנות מטפסים קליניים. היא גם מאפשרת להם להשתמש במודלים של AI כדי ליצור הנחיות ולקבל המלצות.

ארכיטקטורה

בתרשים הבא מתוארת ארכיטקטורה וגישה לאוטומציה של תהליך העבודה של הכנסת נתונים ולשיפור תהליך הבדיקה של ניהול השימוש (UM). הגישה הזו משתמשת בשירותי נתונים ו-AI ב- Google Cloud.

סקירה כללית של תהליך הטמעת הנתונים ותהליך הבדיקה של UM.

ארכיטקטורת העזר שלמעלה מכילה שני זרימות נתונים, שנתמכות על ידי מערכות המשנה הבאות:

  • הכלי להפעלת נתוני תביעות (CDA), שמחלץ נתונים ממקורות לא מובְנים, כמו טפסים ומסמכים, ומזין אותם למסד נתונים בפורמט מובְנה שניתן לקריאה על ידי מכונה. הכלי CDA מיישם את זרימת הנתונים להזנת טפסים של בקשות PA.
  • שירות לבדיקת ניצול (UR), שמשלב נתונים של בקשות PA, מסמכי מדיניות והנחיות אחרות לטיפול כדי ליצור המלצות. שירות ה-UR מיישם את זרימת הנתונים כדי לבדוק בקשות של PA באמצעות AI גנרטיבי.

בקטעים הבאים מתוארים זרימות הנתונים האלה.

זרימת הנתונים ב-CDA

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

זרימת הנתונים של מנהלי תיקים ב-PA.

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

  1. מנהלי הטיפול בבקשות לאישור מראש מקבלים את טופסי הבקשה לאישור מראש (pa_forms) מספק שירותים רפואיים ומעלים אותם לקטגוריה של Cloud Storage‏ pa_forms_bkt.
  2. שירות ingestion_service מאזין לשינויים בדלי pa_forms_bkt. שירות ingestion_service אוסף טפסים ממאגר pa_forms_bkt.pa_forms השירות מזהה את מעבדי Document AI שהוגדרו מראש, שנקראים form_processors. מעבדי המידע האלה מוגדרים לעיבוד הטפסים pa_forms. ingestion_service השירות מחלץ מידע מהטפסים באמצעות המעבדים.form_processors הנתונים שחולצו מהטפסים הם בפורמט JSON.
  3. שירות ingestion_service כותב את המידע שחולץ עם ציוני מהימנות ברמת השדה לאוסף מסד הנתונים של Firestore, שנקרא pa_form_collection.
  4. אפליקציית hitl_app שולפת את המידע (JSON) עם ציוני מהימנות ממסד הנתונים של pa_form_collection. האפליקציה מחשבת את ציון המהימנות ברמת המסמך מתוך ציוני המהימנות ברמת השדה שזמינים בפלט של מודלים ללמידת מכונה (ML) של form_processors.
  5. אפליקציית hitl_app מציגה את המידע שחולץ עם ציוני רמת הביטחון של השדה והמסמך למנהלי הטיפול בבקשות PA, כדי שהם יוכלו לבדוק ולתקן את המידע אם הערכים שחולצו לא מדויקים. מנהלי הטיפול בבקשות PA יכולים לעדכן את הערכים השגויים ולשמור את המסמך במסד הנתונים של pa_form_collection.

זרימת הנתונים בשירות UR

התרשים הבא מציג את זרימת הנתונים בשירות UR.

זרימת הנתונים של מומחה ל-UR.

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

רצף האירועים הוא כזה:

  1. באפליקציה ur_app מוצגת רשימה של בקשות לגישה לנתונים וסטטוס הבדיקה שלהן למומחים לזכויות המשתמש. הסטטוס מוצג כ-in_queue,‏ in_progress או completed.
  2. הרשימה נוצרת על ידי שליפת נתוני pa_form information ממסד הנתונים pa_form_collection. מומחה ה-UR פותח בקשה על ידי לחיצה על פריט מהרשימה שמוצגת באפליקציית ur_app.

  3. האפליקציה ur_app שולחת את הנתונים pa_form information למודל prompt_model. הוא משתמש ב-Vertex AI Gemini API כדי ליצור הנחיה שדומה להנחיה הבאה:

    Review a PA request for {medication|device|medical service} for our member, {Patient Name}, who is {age} old, {gender} with {medical condition}. The patient is on {current medication|treatment list}, has {symptoms}, and has been diagnosed with {diagnosis}.

  4. ההנחיה שנוצרה מוצגת בבקשה למומחי UR לבדיקה ולמשוב.ur_app מומחי UR יכולים לעדכן את ההנחיה בממשק המשתמש ולשלוח אותה לאפליקציה.

  5. אפליקציית ur_app שולחת את ההנחיה למודל ur_model עם בקשה ליצירת המלצה. המודל יוצר תשובה וחוזר לאפליקציה. האפליקציה מציגה את התוצאה המומלצת למומחים של UR.

  6. מומחי ה-UR יכולים להשתמש באפליקציית ur_search_app כדי לחפש את clinical documents, care guidelines ו-plan policy documents. הנתונים clinical documents, care guidelines ו-plan policy documents עוברים אינדוקס מראש וזמינים באפליקציית ur_search_app.

רכיבים

הארכיטקטורה כוללת את הרכיבים הבאים:

  • קטגוריות של Cloud Storage. שירותי האפליקציות של UM דורשים את הקטגוריות הבאות של Cloud Storage בפרויקט Google Cloud :

    • ‫pa_forms_bkt: קטגוריה להעלאת טפסים של בקשות לגישה שצריכים אישור.
    • ‫training_forms: קטגוריה לאחסון טפסים היסטוריים של PA לצורך אימון מעבדי הטפסים של DocAI.
    • ‫eval_forms: קטגוריה לאחסון טפסים של PA לצורך הערכת הדיוק של מעבדי הטפסים של DocAI.
    • ‫tuning_dataset: קטגוריה לאחסון הנתונים שנדרשים לכוונון מודל השפה הגדול (LLM).
    • ‫eval_dataset: קטגוריה לאחסון הנתונים שנדרשים להערכת ה-LLM.
    • ‫clinical_docs: מאגר לאחסון המסמכים הקליניים שהספקים שולחים כקבצים מצורפים לטופסי אישור מראש או לאחר מכן כדי לתמוך בבקשה לאישור מראש. המסמכים האלה עוברים אינדוקס על ידי אפליקציית החיפוש בשירות Agent Search.
    • ‫um_policies: קטגוריה להכללת מסמכים בנושא הצורך הרפואי והנחיות לטיפול, מסמכי מדיניות של תוכניות ביטוח בריאות והנחיות לכיסוי. המסמכים האלה נוספים לאינדקס על ידי אפליקציית החיפוש בשירות Agent Search.

  • ‫form_processors: המעבדים האלה אומנו לחילוץ מידע מטפסים של pa_forms.

  • ‫pa_form_collection: מאגר נתונים של Firestore לאחסון המידע שחולץ כמסמכי JSON באוסף מסד הנתונים של NoSQL.

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

  • ‫hitl_app: מיקרו-שירות (אפליקציית אינטרנט) שמביא ומציג ערכי נתונים שחולצו מ-pa_forms. בנוסף, הוא מציג את ציון רמת הביטחון שדווח על ידי מעבדי הטפסים (מודלים של ML) למנהל התיק של PA, כדי שהוא יוכל לבדוק, לתקן ולשמור את המידע במאגר הנתונים.

  • ‫ur_app: מיקרו-שירות (אפליקציית אינטרנט) שמומחי UR יכולים להשתמש בו כדי לבדוק את בקשות ה-PA באמצעות AI גנרטיבי. הוא משתמש במודל שנקרא prompt_model כדי ליצור הנחיה. המיקרו-שירות מעביר את הנתונים שחולצו מטפסים של pa_forms למודל prompt_model כדי ליצור הנחיה. ההנחיה שנוצרה מועברת למודל ur_model כדי לקבל המלצה לגבי פנייה.

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

    • ‫prompt_model: מתאם ב-LLM שעבר התאמה ליצירת הנחיות על סמך הנתונים שחולצו מ-pa_forms.
    • ‫ur_model: מתאם ב-LLM שמכוון ליצירת טיוטה של המלצה על סמך הנחיית הקלט.

  • ‫ur_search_app: אפליקציית חיפוש שמבוססת על Agent Search ומיועדת למומחי UR כדי למצוא מידע רלוונטי ומותאם אישית במסמכים קליניים, במדיניות UM ובקווים מנחים לגבי כיסוי.

המוצרים שהשתמשו בהם

ארכיטקטורת ההפניה הזו כוללת את המוצרים הבאים Google Cloud :

  • ‫ Vertex AI: פלטפורמה ללמידת מכונה שמאפשרת לאמן ולפרוס מודלים של למידת מכונה ואפליקציות מבוססות-AI, ולהתאים אישית מודלים של שפה גדולה (LLM) לשימוש באפליקציות מבוססות-AI.
  • Agent Search: פלטפורמה שמאפשרת למפתחים ליצור ולפרוס סוכנים ואפליקציות מבוססי-AI ברמה ארגונית.
  • ‫ Document AI: פלטפורמה לעיבוד מסמכים שמקבלת נתונים לא מובְנים ממסמכים והופכת אותם לנתונים מובְנים.
  • ‫ Firestore: מסד נתונים מסוג NoSQL לאחסון מסמכים שמיועד להתאמה לעומס (automatic scaling), לביצועים גבוהים ולפיתוח אפליקציות בקלות.
  • ‫ Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לו, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ‫ Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.
  • ‫ Cloud Monitoring: שירות שמאפשר לראות את הביצועים, הזמינות והתקינות של האפליקציות והתשתית שלכם.

תרחיש שימוש

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

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

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

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

שיקולים לגבי העיצוב

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

אבטחה, פרטיות ותאימות

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

בארצות הברית, חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA, כולל התיקונים, לרבות Health Information Technology for Economic and Clinical Health Act – חוק HITECH) מחייב עמידה בדרישות של כלל האבטחה, כלל הפרטיות וכלל הודעת הפרצה של HIPAA. Google Cloud תומך בתאימות ל-HIPAA, אבל בסופו של דבר, אתם אחראים להערכת התאימות שלכם ל-HIPAA. האחריות לתאימות ל-HIPAA היא משותפת לכם ול-Google. אם הארגון שלכם כפוף ל-HIPAA ואתם רוצים להשתמש במוצרים כלשהם של Google בקשר למידע רפואי מוגן (PHI), אתם צריכים לעיין בהסכם השותפות העסקית (BAA) של Google ולאשר אותו. Google Cloudהמוצרים של Google שמכוסים בהסכם BAA עומדים בדרישות של HIPAA ותואמים לאישורי ISO/IEC 27001,‏ 27017 ו-27018 ולדוח SOC 2 שלנו.

לא כל מודלי ה-LLM שמתארחים ב-Vertex AI Model Garden תומכים ב-HIPAA. להעריך את מודלי ה-LLM שתומכים ב-HIPAA ולהשתמש בהם.

כדי להעריך איך מוצרי Google יכולים לעמוד בדרישות HIPAA, תוכלו לעיין בדוחות הביקורת של צד שלישי בCompliance resource center.

מומלץ ללקוחות לשקול את הנקודות הבאות כשבוחרים תרחישי שימוש ב-AI, ולתכנן את השימוש בהתאם:

  • פרטיות נתונים: פלטפורמת Google Cloud Vertex AI ו-Document AI לא משתמשות בנתוני לקוחות, בשימוש בחבילת הגלישה, בתוכן או במסמכים כדי לשפר או לאמן את מודלי הבסיס. אתם יכולים לכוונן את מודלי הבסיס עם הנתונים והמסמכים שלכם בדייר המאובטח שלכם ב- Google Cloud.
  • ספריות לקוח של שרת Firestore משתמשות בניהול זהויות והרשאות גישה (IAM) כדי לנהל את הגישה למסד הנתונים. מידע על האבטחה והפרטיות ב-Firebase זמין במאמר פרטיות ואבטחה ב-Firebase.
  • כדי לעזור לכם לאחסן מידע אישי רגיש, אפשר להצפין תמונות של שירותים ingestion_service, hitl_app ו-ur_app באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) או לשלב אותן עם Secret Manager.
  • ‫Vertex AI מטמיע אמצעי בקרה לאבטחה כדי לעזור לכם לאבטח את המודלים ואת נתוני האימון. Google Cloud חלק מאמצעי הבקרה בנושא אבטחה לא נתמכים בתכונות שמבוססות על AI גנרטיבי ב-Vertex AI. מידע נוסף זמין במאמרים אמצעי אבטחה ב-Vertex AI ואמצעי אבטחה ב-AI גנרטיבי.
  • מומלץ להשתמש ב-IAM כדי ליישם את העקרונות של הרשאות מינימליות והפרדת תפקידים במשאבי ענן. אפשר להשתמש באמצעי הבקרה הזה כדי להגביל את הגישה ברמת הפרויקט, התיקייה או מערך הנתונים.
  • ב-Cloud Storage הנתונים מאוחסנים באופן אוטומטי במצב מוצפן. מידע נוסף על שיטות נוספות להצפנת נתונים זמין במאמר אפשרויות להצפנת נתונים.

המוצרים של Google פועלים בהתאם לעקרונות של AI אחראי.

עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security (נקודת מבט על AI ו-ML: אבטחה) ב-Well-Architected Framework.

אמינות

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

‫Document AI‏ form_processors הוא שירות אזורי. הנתונים מאוחסנים באופן סינכרוני בכמה אזורים בתוך אזור. תעבורת הנתונים מאוזנת באופן אוטומטי בין האזורים. אם מתרחשת הפסקה זמנית בשירות באזור, הנתונים לא אובדים1. אם מתרחשת הפסקה זמנית בשירות באזור, השירות לא זמין עד ש-Google פותרת את הבעיה.

אפשר ליצור קטגוריות של Cloud Storage באחד משלושת המיקומים הבאים: אזורי, שני אזורים או מספר אזורים, באמצעות קטגוריות pa_forms_bkt, ‏training_forms, ‏eval_forms, ‏tuning_dataset, ‏eval_dataset, ‏clinical_docs או um_policies. נתונים שמאוחסנים בקטגוריות אזוריות משוכפלים באופן סינכרוני בכמה אזורים בתוך אזור. כדי להשיג זמינות גבוהה יותר, אפשר להשתמש בקטגוריות של שני אזורים או מספר אזורים, שבהן הנתונים משוכפלים באופן אסינכרוני בין אזורים.

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

השירותים של Cloud Run‏, ingestion_service,hitl_app ו-ur_app, הם שירותים אזוריים. הנתונים מאוחסנים באופן סינכרוני בכמה אזורים בתוך אזור. התעבורה מאוזנת אוטומטית בין האזורים. אם מתרחש הפסקת חשמל באזור, משימות Cloud Run ממשיכות לפעול והנתונים לא אובדים. אם מתרחש שיבוש באזור, המשימות של Cloud Run מפסיקות לפעול עד ש-Google תפתור את השיבוש. יכול להיות שמשימות או משימות משנה ספציפיות ב-Cloud Run ייכשלו. כדי לטפל בכשלים כאלה, אפשר להשתמש בניסיונות חוזרים של משימות ובשמירת נקודות ביקורת. מידע נוסף זמין במאמר בנושא שיטות מומלצות לניסיונות חוזרים של משימות ולנקודות ביקורת. במאמר טיפים כלליים לפיתוח ב-Cloud Run מפורטות כמה שיטות מומלצות לשימוש ב-Cloud Run.

‫Vertex AI היא פלטפורמה מקיפה וידידותית ללמידת מכונה, שמספקת סביבה מאוחדת למחזור החיים של למידת מכונה, מהכנת הנתונים ועד לפריסת המודל ולמעקב אחריו.

עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.

הוזלת עלויות

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

סוגי אחסון ב-Cloud Storage: כדאי להשתמש בסוגי אחסון שונים (Standard,‏ Nearline,‏ Coldline או Archive) בהתאם לתדירות הגישה לנתונים. סוגי האחסון Nearline,‏ Coldline ו-Archive חסכוניים יותר לנתונים שניגשים אליהם בתדירות נמוכה יותר.

מדיניות מחזור החיים של Cloud Storage: אפשר להטמיע מדיניות מחזור חיים כדי להעביר אובייקטים באופן אוטומטי לסוגי אחסון (storage class) בעלות נמוכה יותר או למחוק אותם על סמך גיל ודפוסי גישה.

התמחור של Document AI מבוסס על מספר המעבדים שנפרסו ועל מספר הדפים שעובדו על ידי המעבדים של Document AI. כמה נקודות שכדאי לחשוב עליהן:

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

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

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

החיובים ב-Cloud Run מחושבים על סמך השימוש במעבד (CPU) על פי דרישה, הזיכרון ומספר הבקשות. חשוב לחשוב היטב על הקצאת המשאבים. הקצאת משאבי מעבד וזיכרון על סמך מאפייני עומס העבודה. כדאי להשתמש בהתאמה אוטומטית לעומס כדי להתאים את המשאבים באופן דינמי לפי הביקוש.

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

החיובים על מנוע החיפוש של Agent Search תלויים בתכונות שבהן אתם משתמשים. כדי לעזור לכם לנהל את העלויות, תוכלו לבחור מבין שלוש האפשרויות הבאות:

  • ‫Search Standard Edition, שמציע יכולות חיפוש לא מובנות.
  • מהדורת Search Enterprise, שמציעה יכולות חיפוש לא מובנה וחיפוש באתר.
  • תוסף LLM לחיפוש, שמציע סיכום ויכולות חיפוש רב-שלביות.

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

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

אם תביאו בחשבון את הגורמים האלה ותיישמו את האסטרטגיות המומלצות, תוכלו לנהל ולשפר את העלות של הפעלת ארכיטקטורת הפעולות האוטומטיות של PA ו-UR ב- Google Cloud.

עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.

פריסה

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

קוד ההתחלה של ארכיטקטורת ההפניה הזו זמין במאגרי ה-Git הבאים:

  • מאגר ה-Git של CDA: המאגר הזה מכיל סקריפטים של פריסת Terraform להקצאת משאבים בתשתית ולפריסה של קוד האפליקציה.
  • מאגר Git של שירות UR: במאגר הזה יש דוגמאות קוד לשירות UR.

אפשר לבחור באחת משתי האפשרויות הבאות להטמעה של תמיכה ושירותים לארכיטקטורת ההפניה הזו:

המאמרים הבאים

שותפים ביצירת התוכן

Author: Dharmesh Patel | Industry Solutions Architect, Healthcare

תורמי תוכן אחרים:

  1. מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.  ↩