איך להוזיל את העלויות של פונקציות AI באמצעות זיקוק מודלים

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

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

כדי להבין טוב יותר את צריכת הטוקנים, אתם יכולים לראות את מספר הטוקנים שבהם השתמשה שאילתה במסוףGoogle Cloud . כדי להעריך את השימוש לפני שמריצים שאילתה, אפשר להשתמש בפונקציה AI.COUNT_TOKENS.

בדוגמה הבאה מוסבר איך להשתמש בפונקציה AI.IF במצב אופטימיזציה כדי לזהות כתבות על אסונות טבע, באמצעות text-embedding-005 כמודל ההטמעה:

SELECT
  title,
  body,
  AI.IF(
    ('The following news story is about a natural disaster: ', body),
    embeddings => AI.EMBED(body, endpoint => 'text-embedding-005', task_type => 'CLASSIFICATION').result,
    -- Optional, 'MINIMIZE_COST' is the default when embeddings are provided.
    optimization_mode => 'MINIMIZE_COST'
   ) AS is_natural_disaster
FROM
  `bigquery-public-data.bbc_news.fulltext`;

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

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

איך פועל המצב האופטימלי

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

ככה זה עובד:

תהליך העבודה של פונקציית ה-AI כשמצב האופטימיזציה מופעל

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

מגבלות

למצב האופטימיזציה יש את המגבלות הבאות:

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

לפני שמתחילים

כדי לקבל את ההרשאות שנדרשות להרצת פונקציות AI מנוהלות ב-BigQuery, קראו את המאמר הגדרת הרשאות לפונקציות של AI גנרטיבי שקוראות למודלי LLM של Gemini Enterprise Agent Platform.

בחירת מודל הטמעה

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

כדי להשיג את היחס הטוב ביותר בין עלות לאיכות וליכולת התאמה לעומס, מומלץ לחשב את ההטמעות של הנתונים באמצעות מודל הטמעה, כמו text-embedding-005 או ההטמעות של Gemini למשימות באנגלית או בכמה שפות. לנתונים מולטי-מודאליים (טקסט ותמונות), מומלץ להשתמש במודל הטמעה מולטי-מודאלי כמו Gemini Embedding 2 (gemini-embedding-2).

יצירת הטמעות

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

יצירת הטמעת נתונים אוטונומית

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

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

-- Create a table with an autonomously generated embedding column
CREATE TABLE my_dataset.bbc_news (
  title STRING,
  body STRING,
  body_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>
    GENERATED ALWAYS AS (
      AI.EMBED(
        body,
        connection_id => '<my_connection_id>',
        task_type => 'CLASSIFICATION',
        endpoint => 'text-embedding-005')
    ) STORED
    OPTIONS(asynchronous = TRUE)
);

-- Insert data into the table
INSERT INTO my_dataset.bbc_news (title, body)
SELECT title, body FROM `bigquery-public-data.bbc_news.fulltext`;

-- Run the optimized query.
-- Wait for the background job to finish generating embeddings before running.
SELECT
  title,
  body,
  AI.CLASSIFY(
    body,
    categories => ['tech', 'sport', 'business', 'other']
  ) AS category
FROM
  my_dataset.bbc_news;

מפרט עמודות ידני

אם יש לכם עמודת הטמעה קיימת, ציינו אותה בארגומנט embeddings של AI.IF או AI.CLASSIFY. אפשר ליצור את זה באמצעות הפונקציה AI.EMBED.

בדוגמה הבאה מוסבר איך ליצור טבלה עם עמודת הטמעה, באמצעות text-embedding-005 כמודל ההטמעה, ואז להשתמש בעמודה הזו בשאילתת AI.CLASSIFY:

-- Create a table with an embedding column
CREATE TABLE my_dataset.bbc_news AS
SELECT
  title,
  body,
  AI.EMBED(
    body,
    endpoint => 'text-embedding-005',
    task_type => 'CLASSIFICATION'
  ).result AS body_embedding
FROM
  `bigquery-public-data.bbc_news.fulltext`;

-- Run the optimized query
SELECT
  title,
  body,
  AI.CLASSIFY(
    body,
    categories => ['tech', 'sport', 'business', 'other'],
    embeddings => body_embedding,
  ) AS category
FROM
  my_dataset.bbc_news;

אם ההנחיה מפנה לכמה עמודות, צריך לספק רשימה של שמות העמודות וההטמעות התואמות שלהן בארגומנט embeddings. לדוגמה: embeddings => [('body', body_embedding), ('title', title_embedding)].

מעקב אחרי אופטימיזציה של שאילתות

כדי לבדוק כמה שורות עברו אופטימיזציה במהלך הרצת השאילתה, אפשר לעיין בנתונים הסטטיסטיים של ההרצה במסוף Google Cloud או דרך ה-API:

המסוף

כדי לראות כמה שורות עברו אופטימיזציה ולראות הודעות מערכת לגבי סטטוס האופטימיזציה:

  1. נכנסים לדף BigQuery במסוף Google Cloud .

    כניסה ל-BigQuery

  2. בתפריט הניווט, לוחצים על Jobs explorer.

  3. לוחצים על מזהה המשימה כדי לפתוח את החלונית Job details.

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

    שדה אופטימיזציות של פונקציות AI גנרטיבי בכרטיסיית המידע על המשימה

API

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

פתרון בעיות

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

גודל הנתונים קטן מדי

הבעיה: אין מספיק נתונים לאימון המודל. יכול להיות שתופיע הודעת שגיאה: Fail to apply cost optimizations because the number of rows to process is too small.

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

מעט דוגמאות או בכלל לא בחלק מהמחלקות

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

  • בפונקציה AI.CLASSIFY, יכול להיות שתופיע הודעת השגיאה: Failed to apply cost optimizations because the random training sample did not contain enough examples of all categories.
  • בפונקציה AI.IF, יכול להיות שתופיע הודעת השגיאה: Failed to apply cost optimizations because the random training sample did not include enough examples of both true/false cases.

הפתרון:

  • ב-AI.CLASSIFY:
    • מסירים קטגוריות נדירות או ריקות מהקריאה לפונקציה AI.CLASSIFY.
    • כדי להגדיל את גודל המדגם, אפשר לקבץ קטגוריות נדירות לקטגוריה רחבה יותר. אפשר להשתמש בקטגוריה OTHER כדי לקבץ פריטים שלא נכללים בקטגוריות ספציפיות יותר. עם זאת, אל תוסיפו את המונח OTHER אם רשימת הקטגוריות שלכם כבר מלאה, כי המונח הזה מעורפל ועלול לגרום לבלבול.
  • ב-AI.IF: מעדכנים את תנאי הסינון של ההנחיה כך שגם המקרים של true וגם המקרים של false מיוצגים היטב בשורות הקלט. השגיאה הזו יכולה להיגרם מתנאי שתואם כמעט לכל השורות, או כמעט לאף שורה.

ההטמעות הן בגדלים שונים

הבעיה: חוסר עקביות בין מאפייני ההטמעה בשורות. יכול להיות שתופיע הודעת השגיאה: Failed to apply cost optimizations because the embeddings have inconsistent dimensions.

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

SELECT ARRAY_LENGTH(body_embedding.result), COUNT(*)
FROM `PROJECT_ID.DATASET.TABLE_NAME`
GROUP BY 1;

ההנחיה מורכבת מדי

הבעיה: המודל המזוקק לא יכול להגיע לרמת דיוק גבוהה. יכול להיות שתופיע אחת מהודעות השגיאה הבאות:

  • Fail to apply cost optimizations because the distilled model does not approximate LLM behavior well enough for some categories.
  • Fail to apply cost optimization because the prompt complexity is too high.

הפתרון:

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

  • משתמשים בקבוצה של קטגוריות שיוצרות מחיצה. חשוב לוודא שהקטגוריות חופפות כמה שפחות ומכסות את כל הקלטים האפשריים.

    • הימנעו מקטגוריות חופפות שבהן קלט מסוים יכול להשתייך לכמה קטגוריות בו-זמנית. לדוגמה, כדאי להימנע מקטגוריות כמו ['terrible', 'bad', 'okay', 'good', 'excellent'].
    • חשוב להימנע ממצבים שבהם אין קטגוריות רלוונטיות. לדוגמה, רשימת הקטגוריות ['bad', 'average'] לא כוללת ביקורת שמשבחת את העסק.

    • כדי לעזור למודל ה-LLM להבחין בין קטגוריות דומות, כדאי לתת תיאורים לקטגוריות. לדוגמה:

      AI.CLASSIFY(
  review,
  categories => [
    ('terrible', 'Review where customer was not happy and the message indicates they will never try this product again'),
    ('bad', 'Review where customer was not happy but suggested improvements to the product'),
    ('okay', 'Review where customer was neutral about the product. Short reviews qualify for this category'),
    ('good', 'Review where customers were happy using this product but had minor critiques'),
    ('excellent', 'Review where customers were very happy using this product and will recommend others to try it too')],
  embeddings => review_embeddings)

  • נסו מודלים מתקדמים יותר של הטמעה כמו text-embedding-005 או gemini-embedding-2.

  • כדי לקבל עזרה נוספת בניפוי באגים, אפשר לפנות לכתובת bqml-feedback@google.com.

מספר לא צפוי של שורות שעובדו על ידי ה-LLM

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

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

פתרון: ודאו שההטמעות נוצרות בצורה תקינה ושהן תקינות בכל השורות בנתונים. אם הבעיה נמשכת, פנו אל bqml-feedback@google.com כדי לקבל עזרה בניפוי באגים.

לא זוהתה עמודת הטמעה אוטונומית

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

פתרון: משתמשים בפרמטר embeddings כדי להעביר באופן מפורש עמודת הטמעה אוטונומית, למשל embeddings => content_embedding.result, שמפעילה אופטימיזציה של עלויות.

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