1. מבוא
מודלי AI גנרטיביים הם כלי חשיבה חזקים, אבל אין להם הקשר ארגוני. אם מנהל שואל סוכן AI, "מה ההכנסה שלנו ברבעון הראשון?", הסוכן עשוי למצוא עשרות טבלאות בשם "הכנסה" במאגר הנתונים. חלק מהם הם דוחות פיננסיים קפדניים, אחרים הם אומדנים שיווקיים בזמן אמת, ורבים מהם הם כנראה ארגזי חול שהוצאו משימוש.
בלי ביסוס מפורש, סוכן AI יבחר טבלה על סמך דמיון פשוט בשמות, מה שיוביל לתשובות "שגויות באופן משכנע" שמבוססות על נתונים לא מאומתים.
שיעור ה-Codelab הזה הוא חלק מסדרה של שני חלקים שבהם נסביר איך ליצור סוכן AI שמודע למשילות.
בחלק הראשון, תבנו בסיס נתונים. תגדירו אגם נתונים מציאותי ו"מבולגן" ב-BigQuery, תפעילו תגי מטא-נתונים קשיחים (היבטים של Knowledge Catalog) כדי להבדיל בין נתונים תקינים לבין רעש, ותשתמשו ב-CLI של Antigravity (AGY) כדי לבדוק באופן מקומי אם הסוכן פועל בהתאם לכללי משילות המידע (data governance) שלכם.
תוכלו לקרוא את החלק השני של הסדרה, שמסביר איך לפרוס את אב הטיפוס של הסוכן המקומי באפליקציית אינטרנט מאובטחת ברמה שמתאימה לארגונים באמצעות Model Context Protocol (MCP) ו-Cloud Run. 👉 לקריאת חלק 2
מה תלמדו
- פריסת אגם נתונים (data lake) ריאליסטי עם כמה שכבות באמצעות סקריפט הגדרות.
- כדי להבדיל בין מוצרי נתונים רשמיים לבין טבלאות גולמיות בארגז החול, אתם יכולים לעצב ולרשום תבניות מותאמות אישית של מטא-נתונים (סוגי היבטים) ב-Knowledge Catalog.
- לפני שכותבים קוד אפליקציה, מאמתים את כללי משילות המידע (data governance) באופן מקומי באמצעות AGY CLI.
הדרישות
- פרויקט ב-Google Cloud עם חיוב מופעל.
- גישה ל-Google Cloud Shell (ה-CLI של AGY מותקן מראש ב-Cloud Shell).
- הבנה בסיסית והיכרות עם BigQuery ו-Knowledge Catalog.
מושגים מרכזיים
- Knowledge Catalog: השירות המאוחד לניהול מטא-נתונים. אנחנו משתמשים בו כדי להעשיר מטא-נתונים טכניים (סכימות) בהקשר עסקי (משילות).
- Aspect Type: תבנית מטא-נתונים מובְנים. בניגוד לתגים של טקסט חופשי, היבטים אוכפים הקלדה חזקה (ערכים בוליאניים, טיפוסי enum), כך שהמכונות יכולות להעריך אותם בצורה מהימנה.
2. הגדרה ודרישות
הפעלת Cloud Shell
אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה תשתמשו ב-Google Cloud Shell, סביבה של שורת פקודה שפועלת ב-Cloud.
במסוף Google Cloud, לוחצים על הסמל של Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:
ההקצאה והחיבור לסביבה אמורים להימשך רק כמה רגעים. בסיום התהליך, אמור להופיע משהו כזה:
המכונה הווירטואלית הזו נטענת עם כל הכלים למפתחים שתצטרכו. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את ביצועי הרשת והאימות. את כל העבודה ב-Codelab הזה אפשר לבצע בדפדפן. לא צריך להתקין שום דבר.
הפעלת הסביבה
פותחים את Cloud Shell ומגדירים את משתני הפרויקט כדי לוודא שכל הפקודות מטרגטות את התשתית הנכונה.
export PROJECT_ID=$(gcloud config get-value project)
gcloud config set project $PROJECT_ID
export REGION="us-central1"
הפעלת ממשקי ה-API
כדי לבצע את ההוראה הבאה, צריך להפעיל את שירותי Google Cloud הנדרשים.
gcloud services enable \
bigquery.googleapis.com \
dataplex.googleapis.com
שכפול המאגר
מורידים את קוד התשתית ואת הסקריפטים לאוטומציה מהמאגר ב-GitHub. כדי לחסוך מקום בכונן ב-Cloud Shell, נוריד רק את התיקייה הספציפית שנדרשת ל-Lab הזה.
# Perform a shallow clone to get only the latest repository structure without the full history
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
# Specify and download only the folder we need for this lab
git sparse-checkout set data-analytics/governance-context
cd data-analytics/governance-context
יצירת אגם נתונים (data lake) "מבולגן"
סביבות נתונים בעולם האמיתי הן לעיתים רחוקות נקיות. כדי לדמות את המציאות, אנחנו צריכים שילוב של מאגרי נתונים "רשמיים" וטבלאות "ארגז חול" לא מהימנות.
נשתמש בסקריפט הגדרות כדי לפרוס את מערכי הנתונים והטבלאות של BigQuery.
- הופכים את סקריפט ההגדרות לקובץ הפעלה ומריצים אותו. הפעולה הזו תיצור שלושה מערכי נתונים ב-BigQuery (
finance_mart,marketing_prod,analyst_sandbox) ותאכלס את הטבלאות שלהם בנתונים לדוגמה.
chmod +x ./setup_bq_tables.sh
./setup_bq_tables.sh
נקודת בקרה: עכשיו יש לכם אגם נתונים מאוכלס במלואו, אבל לא מנוהל בכלל. מבחינת ה-AI, כל הטבלאות נראות בדיוק אותו דבר.
3. יצירת התבנית של משילות המידע (סוג ההיבט)
עכשיו נגדיר כמה כללים של משילות מידע (data governance). ב-Knowledge Catalog, עושים את זה באמצעות יצירת סוג היבט, שהוא תבנית מטא-נתונים עם סוגים מוגדרים היטב שאפשר לעשות בה שימוש חוזר.
נרשום את התבנית הזו באמצעות ה-CLI של gcloud כדי שתוכלו לראות איך היא מוגדרת.
בדיקת הסכימה של ההיבט
כדי לראות את הגדרת הסכימה, פולטים את התוכן של aspect_template.json.
cat aspect_template.json
יוצג לכם מבנה ה-JSON הבא:
{
"name": "OfficialDataProductSpec",
"type": "record",
"recordFields": [
{
"name": "product_tier",
"type": "enum",
"enumValues": [
{ "name": "GOLD_CRITICAL", "index": 1 },
{ "name": "SILVER_STANDARD", "index": 2 },
{ "name": "BRONZE_ADHOC", "index": 3 }
],
...
},
{
"name": "is_certified",
"type": "bool",
...
}
]
}
שימו לב שהסכימה הזו אוכפת סוגי נתונים מחמירים, כמו enum לרמת הקריטיות (GOLD_CRITICAL, SILVER_STANDARD, BRONZE_ADHOC) ו-bool ל-is_certified. כך המטא-נתונים נשארים מובְנים ובפורמט קריא למכונה.
רישום סוג ההיבט
מריצים את הפקודה הבאה של gcloud כדי לרשום את התבנית הזו במרשם של Knowledge Catalog.
gcloud dataplex aspect-types create official-data-product-spec \
--location="${REGION}" \
--project="${PROJECT_ID}" \
--description="Defines the comprehensive profile of a data product for governance agents." \
--display-name="Official Data Product Spec" \
--metadata-template-file-name="aspect_template.json"
4. החלת משילות
זהו שלב הנדסי קריטי. נכון לעכשיו, הטבלאות finance_mart.fin_monthly_closing_internal ו-analyst_sandbox.tmp_data_dump_v2_final_real נראות זהות ל-LLM. הם פשוט אובייקטים עם עמודות.
כמהנדסי משילות, אתם צריכים לצרף היבט (תווית מטא-נתונים מאושרת) לטבלאות האלה כדי להבדיל ביניהן. בארגון אמיתי, הייתם מבצעים אוטומציה של התהליך הזה באמצעות צינורות עיבוד נתונים של CI/CD. אנחנו נדמה את האוטומציה הזו באמצעות סקריפטים.
יצירת מטענים ייעודיים (payloads) של משילות
מפתחות ההיבטים של Knowledge Catalog חייבים להיות ייחודיים ברמה הגלובלית (עם קידומת של מזהה הפרויקט). הסקריפט ./generate_payloads.sh ייצור באופן דינמי את קובצי המטא-נתונים של YAML.
chmod +x ./generate_payloads.sh
./generate_payloads.sh
פלט:
הפקודה הזו יוצרת תיקייה בשם "./aspect_payloads" שמכילה 4 קובצי YAML, שמגדירים את תרחישי הפיקוח (Gold/Internal, Gold/Public, Silver/Realtime, Bronze/Sandbox).
החלת היבטים באמצעות ה-CLI
לפני שמריצים את הסקריפט, בואו נראה מה אנחנו בעצם עושים כדי להבין את התהליך. כדי לראות את המבנה של המטען הייעודי (payload) הפנימי של הכספים, מריצים את הפקודה הבאה:
cat aspect_payloads/fin_internal.yaml
יוצג לכם התוכן הבא:
your-project-id.us-central1.official-data-product-spec:
data:
product_tier: GOLD_CRITICAL
data_domain: FINANCE
usage_scope: INTERNAL_ONLY
update_frequency: DAILY_BATCH
is_certified: true
שימו לב איך קובץ ה-YAML הזה מגדיר במפורש את ההקשר העסקי, למשל הגדרת הדגל is_certified: true והקצאת הרמה GOLD_CRITICAL. לתת ל-LLM כללים ברורים ומובנים להערכה, במקום רק לנחש על סמך שמות הטבלאות.
עכשיו מריצים את הסקריפט של האפליקציה. הפעולה הזו עוברת על הטבלאות ב-BigQuery ומריצה את הפקודה gcloud dataplex entries update כדי לצרף את המטא-נתונים הקשיחים האלה.
chmod +x ./apply_governance.sh
./apply_governance.sh
אימות (אופציונלי)
לפני שממשיכים, צריך לוודא שהמטא-נתונים הוחלו בצורה נכונה במסוף.
- פותחים את הדף Knowledge Catalog במסוף Google Cloud. אם האפשרות Knowledge Catalog לא מופיעה בתפריט הניווט הימני, מקלידים Knowledge Catalog בשורת החיפוש שבחלק העליון של החלון במסוף Google Cloud, ובוחרים את התוצאה בקטע Top results או Products & Pages.
- חיפוש של
fin_monthly_closing_internal. הטבלה ב-BigQuery אמורה להופיע בתוצאות. לוחצים על שם הטבלה כדי להיכנס לדף הפרטים שלה.
- בדף הפרטים של הטבלה, מחפשים את הקטע Optional tags and aspects בתחתית הדף.
- תמצאו את ההיבט
official-data-product-spec. מוודאים שהערכים תואמים לתרחיש Gold Internal שהחלנו.
עכשיו וידאתם שטבלאות ב-BigQuery זהות מבחינה טכנית (fin_monthly_closing_internal ו-tmp_data_dump_v2_final_real) נבדלות באופן לוגי באמצעות מטא-נתונים קריאים למכונה.
5. הגדרה ויצירת אב טיפוס של הנציג
לפני שנבנה אפליקציה (נעשה את זה בחלק 2), נאמת את הלוגיקה של משילות המידע באופן מקומי. אנחנו צריכים להתקין את הפלאגין של Knowledge Catalog ולהגדיר את המיומנות של הסוכן.
התקנת התוסף
ב-Cloud Shell, מתקינים את הפלאגין של Knowledge Catalog. תתבקשו לאשר את הפעולה ולהזין את פרטי ההגדרה.
export DATAPLEX_PROJECT="${PROJECT_ID}"
agy plugin install https://github.com/gemini-cli-extensions/dataplex
בדיקת הסקיל של הנציג
הסקיל של הסוכן הוא קובץ הגדרה סטטי שאפשר להשתמש בו שוב ושוב, שנמצא ב-.agents/skills/knowledge_catalog_governance/SKILL.md. הוא מכיל את הלוגיקה שמתרגמת כללים אנושיים מופשטים (למשל, "אני צריך נתונים בטוחים") לחיפושים טכניים קפדניים.
בודקים את הקובץ כדי להבין את האלגוריתם שאנחנו מלמדים את ה-AI:
cat .agents/skills/knowledge_catalog_governance/SKILL.md
שימו לב שההנחיה מורה למודל באופן מפורש לפעול לפי לולאה קפדנית של שלב 1 (אימות מטא-נתונים) ושלב 2 (הרצת שאילתות). המודל צריך לגלות ולאמת את המטא-נתונים לפני שהוא יוצר SQL.
הפעלת הנציג ובדיקת תרחישים
מתחילים את הסשן של AGY CLI. הוא יזהה ויטען באופן אוטומטי את המיומנות מספריית .agents/skills.
agy
הערה: יכול להיות שייטענו כמה קובצי הקשר. זהו נוהל רגיל. ממשק שורת הפקודה (CLI) טוען את המיומנות המקומית לכללים הספציפיים של הפרויקט הזה, וגם את ההוראות שמוגדרות כברירת מחדל לפלאגין Knowledge Catalog עצמו.
אימות התקנה
מקלידים /mcp כדי לוודא שהפלאגין Knowledge Catalog פעיל. התוסף knowledge-catalog אמור להופיע ברשימה כתוסף פעיל עם הכלים הזמינים שלו.
/mcp
הפלט המצופה:
MCP Servers
...
> ✓ knowledge-catalog Tools: search_entries, lookup_context, lookup_entry
תרחישי בדיקה (יצירת אב טיפוס)
מדביקים את ההנחיות הבאות בסשן הפעיל של הנציג, אחת אחרי השנייה, כדי לוודא שהוא פועל לפי הכללים.
- תרחיש א' (אישור הנתונים של סמנכ"ל הכספים):
"We are preparing the deck for an internal Board of Directors meeting next week. I need the numbers to be absolutely finalized, trustworthy, and kept strictly confidential. Which table is safe to use?"
התוצאה הצפויה: הנציג מזהה באופן אוטומטי את הפרויקט והאזור הפעילים שלכם מהכלים שלו, שולח שאילתה ל-fin_monthly_closing_internal כי הוא תואם מבחינה סמנטית ל-GOLD_CRITICAL (מדויק) ול-INTERNAL_ONLY (ישיבת דירקטוריון) ב-Aspect שלו, וממליץ עליו.
- תרחיש ב' (חשיפה לציבור):
"I need to share our quarterly financial summary with an external consulting firm. It is critical that we do not leak any raw or internal metrics. Which dataset is officially scrubbed and explicitly approved for external sharing?"
התוצאה הצפויה: הנציג צריך לדלג על הטבלה הפנימית החודשית ולבחור רק את fin_quarterly_public_report כי זה הנכס היחיד שמתויג בתור EXTERNAL_READY.
- תרחיש ג' (צרכים תפעוליים):
"My dashboard needs to show what's happening right now with our ad spend. I can't wait for the overnight load. What do you recommend?"
התוצאה הצפויה: הנציג בוחר ב-mkt_realtime_campaign_performance כי הוא מזהה את תדירות העדכון של REALTIME_STREAMING, ונותן לה עדיפות על פני רמת ה-GOLD_CRITICAL של הנתונים הפיננסיים.
- תרחיש ד' (ניסויים בארגז חול):
"I'm just playing around with some new ML models and need a lot of raw data. It doesn't need to be perfect, just a sandbox environment."
התוצאה הצפויה: הנציג בוחר את tmp_data_dump_v2_final_real כי הוא תואם מבחינה סמנטית ל-BRONZE_ADHOC (נתונים גולמיים) ול-is_certified: false (סביבת ארגז חול) בהיבט שלו.
(כדי לצאת מהסשן של AGY, מקלידים /exit או /quit)
6. מעולה! מה השלב הבא?
הצלחתם ליצור בסיס נתונים מנוהל והוכחתם ש-AI יכול לפעול לפי כללי המטא-נתונים שלכם באמצעות אב טיפוס מקומי של CLI.
עכשיו הגעתם לנקודת ביקורת. מה השלב הבא?
אפשרות א': אני רוצה להמשיך לחלק 2 עכשיו!
אם אתם מוכנים להפוך את אב הטיפוס המקומי הזה לאפליקציית אינטרנט מאובטחת ברמת ייצור באמצעות Model Context Protocol (MCP) ו-Cloud Run:
אפשרות ב': אבצע את חלק 2 מאוחר יותר או שרציתי להשלים רק את חלק 1.
אם אתם רוצים להפסיק להיום ולהימנע מעלויות בענן, כדאי לנקות את המשאבים.
אל דאגה! בחלק 2 נספק "סקריפט למסלול מהיר" שיבנה מחדש את הסביבה של חלק 1 תוך 2 דקות בלבד, כדי שתוכלו להמשיך בדיוק מהמקום שבו הפסקתם.
👉 עוברים לקטע "ניקוי".
7. ניקוי (לאפשרות ב' בלבד)
אם אתם עוצרים כאן, מחקו את המשאבים כדי להימנע מחיובים.
השמדת אגם הנתונים (data lake)
אם אתם נמצאים כרגע בסשן של AGY CLI, צאו מהסשן על ידי לחיצה על Ctrl+C פעמיים או הקלדה של /quit. לאחר מכן, מריצים את הפקודות הבאות:
chmod +x ./cleanup_data_lake.sh
./cleanup_data_lake.sh
הסרת הפלאגין של AGY CLI והסרת קבצים מקומיים
agy plugin uninstall dataplex
cd ~
rm -rf ~/devrel-demos