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

Last reviewed 2024-08-19 UTC

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

ארכיטקטורה

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

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

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

  • ‫Claims data activator (CDA), שחולץ נתונים ממקורות לא מובנים, כמו טפסים ומסמכים, ומזין אותם למסד נתונים בפורמט מובנה שניתן לקריאה על ידי מכונה. ב-CDA מיושם תהליך של הטמעת נתונים כדי להטמיע טפסים של בקשות לגישה לנתונים.
  • שירות לבדיקת ניצול (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ממאגר pa_forms_bkt. השירות מזהה את מעבדי 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 הם בדרך כלל אחיות או רופאים עם ניסיון בתחום קליני ספציפי, שעובדים בחברות לביטוח בריאות. הקטע הזה לא מתאר את תהליך העבודה של ניהול פניות והעברה של בקשות לגישה לחשבון.

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

  1. באפליקציית ur_app מוצגת רשימה של בקשות לאישור מראש וסטטוס הבדיקה שלהן למומחי ה-UR. הסטטוס שמוצג הוא 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_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: מאגר (bucket) להחזקת הנתונים שנדרשים לכוונון של מודל שפה גדול (LLM).
    • ‫eval_dataset: קטגוריה לאחסון הנתונים שנדרשים להערכת ה-LLM.
    • ‫clinical_docs: באקט לאחסון המסמכים הקליניים שהספקים שולחים כקבצים מצורפים לטופסי אישור מראש או לאחר מכן לתמיכה בבקשה לאישור מראש. המסמכים האלה נוספים לאינדקס על ידי אפליקציית החיפוש בשירות חיפוש מבוסס-Vertex AI.
    • ‫um_policies: קטגוריה להחזקת מסמכים בנושא הנחיות לגבי הצורך הרפואי והטיפול, מדיניות תוכנית הבריאות והנחיות לגבי הכיסוי. המסמכים האלה נוספים לאינדקס על ידי אפליקציית החיפוש בשירות Vertex AI Search.

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

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

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

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

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

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

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

  • ur_search_app: אפליקציית חיפוש שנבנתה באמצעות חיפוש מבוסס-Vertex AI כדי למצוא מידע רלוונטי בהתאמה אישית למומחי UR מתוך מסמכים קליניים, מדיניות UM והנחיות לגבי כיסוי.

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

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

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

תרחיש לדוגמה

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

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

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

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

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

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

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

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

בארצות הברית, חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA, כולל התיקונים שבו, למשל חוק טכנולוגיית המידע הרפואי לקידום כלכלי ובריאות קלינית – 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. הערכה ושימוש במודלים גדולים של שפה שתומכים ב-HIPAA.

כדי להעריך איך מוצרי Google יכולים לעמוד בדרישות התאימות ל-HIPAA, תוכלו לעיין בדוחות הביקורת של צד שלישי במרכז המשאבים בנושא תאימות.

אנחנו ממליצים ללקוחות לשקול את הנקודות הבאות כשבוחרים תרחישי שימוש ב-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 ב-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.

הוזלת עלויות

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

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

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

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

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

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

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

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

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

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

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

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

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

אם תביאו בחשבון את הגורמים האלה ותיישמו את האסטרטגיות המומלצות, תוכלו לנהל ולבצע אופטימיזציה של העלות של הפעלת ארכיטקטורת הפעולות האוטומטיות של 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. מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.  ↩