הכנת נתונים להטמעה

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

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

נתונים מהאתר

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

לפני שמבצעים אינדוקס של נתוני האתר:

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

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

      לדוגמה, תבניות ה-URL של דפי האינטרנט שבהם מוצגות תוצאות החיפוש, כמו www.example.com/search?*. נניח שמשתמש מחפש את הביטוי Nobel prize, כתובת ה-URL הדינמית של החיפוש יכולה להיות כתובת URL ייחודית: www.example.com/search?q=nobel%20prize/UNIQUE_STRING. אם תבנית כתובת ה-URL www.example.com/search?* לא מוחרגת, כל כתובות ה-URL הייחודיות והדינמיות לרשת החיפוש שמתאימות לתבנית הזו יתווספו לאינדקס. כתוצאה מכך, האינדקס מתנפח ואיכות החיפוש יורדת.

    • הסרת כתובות URL כפולות באמצעות תבניות של כתובות URL קנוניות. הפעולה הזו מספקת כתובת URL קנונית יחידה לחיפוש Google בזמן הסריקה של האתר, ומסירה את אי הבהירות. דוגמאות לקביעת כתובת URL כגרסה הרשמית (הקנונית) ומידע נוסף זמינים במאמרים מהי קביעת כתובת URL כגרסה הרשמית (הקנונית) ואיך מציינים כתובת URL קנונית באמצעות rel="canonical"‎ ושיטות אחרות.

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

    סוג ההוספה לאינדקס אתרים כלולים אתרים מוחרגים
    חיפוש בסיסי באתר עד 50 תבניות URL עד 50 תבניות URL
    תהליך מתקדם להוספת אתרים לאינדקס עד 500 תבניות URL עד 500 תבניות URL

  • אם אתם משתמשים בקובץ robots.txt באתר, אתם צריכים לבצע את הפעולות הבאות:

    בטבלה הבאה מפורטת מחרוזת סוכן המשתמש כפי שהיא מופיעה בבקשות HTTP, וטוקן של סוכן משתמש ב-robots.txt עבור Google-CloudVertexBot.

    סוכן משתמש בבקשות HTTP 
    Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.7559.132 Mobile Safari/537.36 (compatible; Google-CloudVertexBot; +https://cloud.google.com/enterprise-search)
    robots.txt
    טוקן של סוכן משתמש בrobots.txt Google-CloudVertexBot
    דוגמה לקבוצה robots.txt 
                  user-agent: Google-CloudVertexBot
              allow: /

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

    מידע נוסף זמין במאמרים מבוא ל-robots.txt ואיך לכתוב ולשלוח קובץ robots.txt.

  • בנוסף לאישור הסורק בקובץ robots.txt, הארגון שלכם צריך לאשר את בקשות החיפוש דרך כל שרתי ה-proxy שבהמשך השרשרת, שהמשתמשים עשויים להיתקל בהם.

  • אם אתם מתכננים להשתמש באינדוקס מתקדם של אתרים, אתם צריכים להיות מסוגלים לאמת את הדומיינים של דפוסי כתובות ה-URL במאגר הנתונים שלכם.

  • כדי לשפר את יצירת האינדקס, כדאי להוסיף נתונים מובְנים בצורה של תגי meta ו-PageMaps לסכימת מאגר הנתונים, כמו שמוסבר במאמר שימוש בנתונים מובְנים ליצירת אינדקס מתקדם של אתרים.

נתונים לא מובנים

התכונה 'חיפוש באמצעות סוכן' תומכת בחיפוש במסמכים בפורמטים TXT,‏ JSON,‏ Markdown,‏ PDF,‏ HTML,‏ DOCX,‏ PPTX,‏ XLSX ו-XLSM.

הגודל המקסימלי של קובץ הוא 200MB, ואפשר לייבא עד 100,000 קבצים בכל פעם.

אתם מייבאים את המסמכים מקטגוריה של Cloud Storage. אפשר לייבא באמצעות מסוף Google Cloud , באמצעות ה-method ImportDocuments או באמצעות הטמעת עדכונים בזמן אמת דרך שיטות CRUD. מידע על הפניות ל-API זמין במאמרים DocumentService ו-documents. אם אתם מתכננים לכלול הטמעות בנתונים הלא מובְנים, כדאי לעיין במאמר בנושא שימוש בהטמעות בהתאמה אישית.

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

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

אפשר לייבא נתונים לא מובְנים מהמקורות הבאים:

Cloud Storage

אפשר לייבא נתונים מ-Cloud Storage עם או בלי מטא-נתונים.

ייבוא הנתונים הוא רקורסיבי. כלומר, אם יש תיקיות בתוך ה-bucket או התיקייה שציינתם, הקבצים בתיקיות האלה מיובאים.

אם אתם מתכננים לייבא מסמכים מ-Cloud Storage בלי מטא-נתונים, אתם צריכים להוסיף את המסמכים ישירות לקטגוריה של Cloud Storage. מזהה המסמך הוא דוגמה למטא-נתונים.

לצורך בדיקה, אפשר להשתמש בתיקיות הבאות של Cloud Storage שזמינות לציבור ומכילות קובצי PDF:

  • gs://cloud-samples-data/gen-app-builder/search/alphabet-investor-pdfs
  • gs://cloud-samples-data/gen-app-builder/search/CUAD_v1
  • gs://cloud-samples-data/gen-app-builder/search/kaiser-health-surveys
  • gs://cloud-samples-data/gen-app-builder/search/stanford-cs-224

אם אתם מתכננים לייבא נתונים מ-Cloud Storage עם מטא-נתונים, אתם צריכים להוסיף קובץ JSON שמכיל את המטא-נתונים לקטגוריה של Cloud Storage שאת המיקום שלה אתם מציינים במהלך הייבוא.

המסמכים הלא מובנים יכולים להיות באותה קטגוריה של Cloud Storage כמו המטא-נתונים או בקטגוריה אחרת.

קובץ המטא-נתונים חייב להיות קובץ JSON Lines או קובץ NDJSON. מזהה המסמך הוא דוגמה למטא-נתונים. כל שורה בקובץ המטא-נתונים צריכה להיות באחד מפורמטי ה-JSON הבאים:

  • שימוש ב-jsonData:
    • { "id": "<your-id>", "jsonData": "<JSON string>", "content": { "mimeType": "<application/pdf or text/html>", "uri": "gs://<your-gcs-bucket>/directory/filename.pdf" } }
  • שימוש ב-structData:
    • { "id": "<your-id>", "structData": { <JSON object> }, "content": { "mimeType": "<application/pdf or text/html>", "uri": "gs://<your-gcs-bucket>/directory/filename.pdf" } }

משתמשים בשדה uri בכל שורה כדי להפנות למיקום ב-Cloud Storage של המסמך.

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

{"id":"doc-0","jsonData":"{\"title\":\"test_doc_0\",\"uri\":\"https://test_doc_0.html\",\"description\":\"This document uses a blue color theme\",\"color_theme\":\"blue\"}","content":{"mimeType":"application/pdf","uri":"gs://test-bucket-12345678/test_doc_0.pdf"}}
{"id":"doc-1","jsonData":"{\"title\":\"test_doc_1\",\"uri\":\"https://test_doc_1.html\",\"description\":\"This document uses a green color theme\",\"color_theme\":\"green\"}","content":{"mimeType":"application/pdf","uri":"gs://test-bucket-12345678/test_doc_1.pdf"}}
{"id":"doc-2","structData":{"title":"test_doc_2","uri":"https://test_doc_2.html", "description":"This document uses a red color theme","color_theme":"red"},"content":{"mimeType":"application/pdf","uri":"gs://test-bucket-12345678/test_doc_3.pdf"}}
{"id":"doc-3","structData":{"title":"test_doc_3","uri":"https://test_doc_3.html","description":"This is document uses a yellow color theme","color_theme":"yellow"},"content":{"mimeType":"application/pdf","uri":"gs://test-bucket-12345678/test_doc_4.pdf"}}

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

BigQuery

אם אתם מתכננים לייבא מטא-נתונים מ-BigQuery, אתם צריכים ליצור טבלה ב-BigQuery שמכילה מטא-נתונים. מזהה המסמך הוא דוגמה למטא-נתונים.

מכניסים את המסמכים הלא מובנים לקטגוריה של Cloud Storage.

משתמשים בסכימת BigQuery הבאה. משתמשים בשדה uri בכל רשומה כדי להפנות למיקום של המסמך ב-Cloud Storage.

[
  {
    "name": "id",
    "mode": "REQUIRED",
    "type": "STRING",
    "fields": []
  },
  {
    "name": "jsonData",
    "type": "STRING",
    "fields": []
  },
  {
    "name": "content",
    "type": "RECORD",
    "mode": "NULLABLE",
    "fields": [
      {
        "name": "mimeType",
        "type": "STRING",
        "mode": "NULLABLE"
      },
      {
        "name": "uri",
        "type": "STRING",
        "mode": "NULLABLE"
      }
    ]
  }
]

מידע נוסף זמין במאמר יצירה ושימוש בטבלאות במאמרי העזרה של BigQuery.

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

Google Drive

סנכרון נתונים מ-Google Drive נתמך בחיפוש מותאם אישית.

אם אתם מתכננים לייבא נתונים מ-Google Drive, אתם צריכים להגדיר את Google Identity כספק הזהויות שלכם ב-Agent Search. מידע על הגדרת בקרת גישה זמין במאמר שימוש בבקרת גישה למקורות נתונים.

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

נתונים מובְנים

מכינים את הנתונים בהתאם לשיטת הייבוא שבה מתכננים להשתמש. אם אתם מתכננים להטמיע נתוני מדיה, כדאי לעיין גם במאמר בנושא נתוני מדיה מובְנים.

אפשר לייבא נתונים מובְנים מהמקורות הבאים:

כשמייבאים נתונים מובנים מ-BigQuery או מ-Cloud Storage, יש אפשרות לייבא את הנתונים עם מטא-נתונים. (נתונים מובְנים עם מטא-נתונים נקראים גם נתונים מובְנים משופרים).

BigQuery

אפשר לייבא נתונים מובְנים ממערכי נתונים של BigQuery.

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

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

אם אתם מתכננים לכלול הטמעות בנתונים המובְנים, כדאי לעיין במאמר בנושא שימוש בהטמעות מותאמות אישית.

אם בוחרים לייבא נתונים מובנים עם מטא-נתונים, צריך לכלול שני שדות בטבלאות ב-BigQuery:

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

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

אפשר להשתמש בסכימת BigQuery הבאה לייבוא נתונים מובנים עם מטא-נתונים:

[
  {
    "name": "id",
    "mode": "REQUIRED",
    "type": "STRING",
    "fields": []
  },
  {
    "name": "jsonData",
    "mode": "NULLABLE",
    "type": "STRING",
    "fields": []
  }
]

הוראות ליצירת מאגר נתונים זמין במאמרים יצירת מאגר נתוני חיפוש או יצירת מאגר נתוני המלצות.

Cloud Storage

נתונים מובנים ב-Cloud Storage צריכים להיות בפורמט JSON Lines או NDJSON. כל קובץ צריך להיות קטן מ-2GB, וכל שורה בקובץ צריכה להיות קטנה מ-1MB. אפשר לייבא עד 1,000 קבצים בכל בקשת ייבוא.

דוגמאות לנתונים מובְנים שזמינים לציבור מופיעות בתיקיות הבאות ב-Cloud Storage, שמכילות קובצי NDJSON:

  • gs://cloud-samples-data/gen-app-builder/search/kaggle_movies
  • gs://cloud-samples-data/gen-app-builder/search/austin_311

אם אתם מתכננים לכלול הטמעות בנתונים המובְנים, כדאי לעיין במאמר בנושא שימוש בהטמעות מותאמות אישית.

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

{"id": 10001, "title": "Hotel 1", "location": {"address": "1600 Amphitheatre Parkway, Mountain View, CA 94043"}, "available_date": "2024-02-10", "non_smoking": true, "rating": 3.7, "room_types": ["Deluxe", "Single", "Suite"]}
{"id": 10002, "title": "Hotel 2", "location": {"address": "Manhattan, New York, NY 10001"}, "available_date": "2023-07-10", "non_smoking": false, "rating": 5.0, "room_types": ["Deluxe", "Double", "Suite"]}
{"id": 10003, "title": "Hotel 3", "location": {"address": "Moffett Park, Sunnyvale, CA 94089"}, "available_date": "2023-06-24", "non_smoking": true, "rating": 2.5, "room_types": ["Double", "Penthouse", "Suite"]}

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

נתוני JSON מקומיים

אפשר להעלות ישירות מסמך או אובייקט בפורמט JSON באמצעות ה-API.

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

אם אתם מתכננים לכלול הטמעות בנתונים המובְנים, כדאי לעיין במאמר בנושא שימוש בהטמעות מותאמות אישית.

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

נתוני מדיה מובְנים

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

נתוני FHIR רפואיים

אם אתם מתכננים להטמיע נתוני FHIR מ-Cloud Healthcare API, ודאו את הדברים הבאים:

  • מיקום: מאגר ה-FHIR של המקור חייב להיות במערך נתונים של Cloud Healthcare API שנמצא במיקום us-central1, us או eu. מידע נוסף מופיע במאמר בנושא יצירה וניהול של מערכי נתונים ב-Cloud Healthcare API.
  • סוג מאגר FHIR: מאגר ה-FHIR של המקור חייב להיות מאגר נתונים R4. אפשר לבדוק את הגרסאות של מאגרי ה-FHIR על ידי הצגת רשימה של מאגרי ה-FHIR במערך הנתונים. במאמר יצירת מאגרי FHIR מוסבר איך ליצור מאגר FHIR R4.
  • מכסת ייבוא: בחנות FHIR של המקור צריכים להיות פחות ממיליון משאבי FHIR. אם יש יותר ממיליון משאבי FHIR, תהליך הייבוא ייפסק אחרי שמגיעים למגבלה הזו. מידע נוסף זמין במאמר מכסות ומגבלות.
  • כדאי לעיין ברשימת המשאבים של FHIR R4 שנתמכים ב-חיפוש מבוסס סוכנים. מידע נוסף זמין במאמר הפניה לסכימת נתונים של FHIR R4 בתחום הבריאות.

  • הפניות למשאבים: מוודאים שההפניות היחסיות למשאבים הן בפורמט Resource/resourceId. לדוגמה, הערך של subject.reference חייב להיות Patient/034AB16. מידע נוסף על התמיכה של Cloud Healthcare API בהפניות למשאבי FHIR זמין במאמר הפניות למשאבי FHIR.

  • הקבצים שאליהם יש הפניה במשאב DocumentReference צריכים להיות קובצי PDF,‏ RTF או תמונות שמאוחסנים ב-Cloud Storage. הקישור לקבצים שאליהם מתבצעת ההפניה צריך להיות בשדה content[].attachment.url של המשאב בפורמט הנתיב הסטנדרטי של Cloud Storage:‏ gs://BUCKET_NAME/PATH_TO_REFERENCED_FILE.

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