Préparer les données pour l'ingestion

La préparation des données dépend du type de données que vous importez et de la méthode d'importation choisie. Commencez par le type de données que vous prévoyez d'importer :

Pour en savoir plus sur la recherche combinée, qui permet d'associer plusieurs datastores à une seule application de recherche personnalisée, consultez la section Connecter plusieurs datastores.

Données de site Web

Lorsque vous créez un data store pour les données de sites Web, vous fournissez les URL des pages Web que Google doit explorer et indexer pour la recherche ou la recommandation.

Avant d'indexer les données de votre site Web :

  • Déterminez les formats d'URL à inclure dans votre indexation et ceux à exclure. Vous pouvez inclure des formats d'URL provenant de domaines identiques ou différents qui doivent être indexés, et exclure ceux qui ne doivent pas l'être. Le nombre de formats d'URL que vous pouvez inclure et exclure diffère de la manière suivante :

    Type d'indexation Sites inclus Sites exclus
    Recherche de base sur un site Web 50 formats d'URL maximum 50 formats d'URL maximum
    Indexation avancée de site Web 500 formats d'URL maximum 500 formats d'URL maximum

  • Excluez les formats des URL dynamiques. Les URL dynamiques sont des URL qui changent au moment de la diffusion en fonction de la requête.

    Les pages Web qui affichent des résultats de recherche sont un exemple d'URL dynamiques. Les formats d'URL des pages Web qui affichent les résultats de recherche peuvent se présenter sous la forme www.example.com/search?*. Si un utilisateur recherche l'expression Nobel Prize, l'URL de recherche dynamique peut être une URL unique : www.example.com/search?q=nobel%20prize/UNIQUE_STRING. Si le format d'URL www.example.com/search?* n'est pas exclu, toutes les URL de recherche dynamiques uniques qui suivent ce format sont indexées. La qualité de la recherche est alors diluée, l'index est surchargé et les coûts de stockage de l'index augmentent.

    Voici quelques formats courants à exclure :

    Type de format Exemple de format Raison de l'exclusion
    Vues mises en avant example.com/*/highlight/true Autre vue d'un post existant.
    Chemins d'accès aux sujets par rapport aux messages example.com/*/td-p/* Autre chemin canonique pour le même message.
    Permutations de pièces jointes example.com/*?attachment-id=* Pages axées sur les pièces jointes plutôt que sur le contenu.
    Profils utilisateur example.com/*/user/* Pages de métadonnées de faible valeur qui augmentent le nombre de documents.
    Recherche dynamique example.com/search?* Toutes les URL de recherche dynamiques uniques qui suivent ce format sont indexées. La qualité de la recherche est alors diluée, l'index est surchargé et les coûts de stockage de l'index augmentent.

  • Éliminez les URL en double à l'aide de formats d'URL canoniques. Cela fournit une seule URL canonique pour la recherche Google lors de l'exploration du site Web et élimine toute ambiguïté. Pour obtenir des exemples de canonisation et en savoir plus, consultez Qu'est-ce que la canonisation d'URL et Comment spécifier une URL canonique avec rel="canonical" et d'autres méthodes.

  • Évitez le gonflement des documents facturables à partir de variantes d'URL : de nombreux systèmes de gestion de contenu et plates-formes de forums communautaires (par exemple, Khoros et Discourse) diffusent la même page sous plusieurs formats d'URL. La recherche d'agent traite chaque URL unique comme un document distinct, ce qui peut entraîner les conséquences suivantes :

    • Augmentation des coûts, car vous êtes facturé pour chaque variante d'URL unique stockée dans votre data store.

    • Dilution de la qualité de la recherche, car les résultats de recherche peuvent afficher le même contenu plusieurs fois.

    Identifiez les formats d'URL en double avant de créer un datastore de données de site Web.

  • Si vous utilisez le fichier robots.txt sur votre site Web, procédez comme suit :

    Le tableau suivant répertorie la chaîne user-agent telle qu'elle apparaît dans les requêtes HTTP et le jeton user-agent dans robots.txt pour Google-CloudVertexBot.

    User-agent dans les requêtes 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
    Jeton user-agent dans robots.txt Google-CloudVertexBot
    Exemple de groupe robots.txt 
                  user-agent: Google-CloudVertexBot
              allow: /

    Il est nécessaire que le robot de recherche d'agent explore et indexe vos informations, y compris le contenu soumis à un paywall. Pour en savoir plus sur l'exploration et l'indexation de votre contenu, y compris le contenu soumis à un paywall, consultez les ressources suivantes :

    Pour en savoir plus, consultez Présentation du fichier robots.txt et Créer et envoyer un fichier robots.txt.

  • En plus d'autoriser le robot d'exploration dans votre fichier robots.txt, votre organisation doit autoriser les requêtes de recherche via tous les serveurs proxy en amont que vos utilisateurs peuvent rencontrer.

  • Si vous prévoyez d'utiliser l'indexation avancée de sites Web, vous devez pouvoir valider les domaines pour les formats d'URL dans votre data store.

  • Ajoutez des données structurées sous la forme de balises meta et de PageMaps au schéma de votre data store pour enrichir votre indexation, comme expliqué dans Utiliser des données structurées pour l'indexation avancée de sites Web.

Données non structurées

La recherche d'agent est compatible avec la recherche dans les documents aux formats TXT, JSON, Markdown, PDF, HTML, DOCX, PPTX, XLSX et XLSM.

La taille maximale d'un fichier est de 200 Mo, et vous pouvez importer jusqu'à 100 000 fichiers à la fois.

Vous importez vos documents à partir d'un bucket Cloud Storage. Vous pouvez importer à l'aide de la Google Cloud console, de la ImportDocuments méthode ou de l'ingestion en flux continu via des méthodes CRUD. Pour obtenir des informations de référence sur l'API, consultez DocumentService et documents. Si vous prévoyez d'inclure des embeddings dans vos données non structurées, consultez Utiliser des embeddings personnalisés.

Si vous disposez de fichiers PDF dans lesquels la recherche ne peut pas être effectuée (PDF numérisés ou PDF contenant du texte dans des images, comme des infographies), nous vous recommandons d'activer l'analyseur de mise en page lors de la création du data store. Cela permet à la recherche d'agent d'extraire des éléments tels que des blocs de texte et des tableaux. Si vous disposez de fichiers PDF dans lesquels la recherche peut être effectuée, qui sont principalement composés de texte lisible par machine et qui contiennent de nombreux tableaux, vous pouvez envisager d'activer le traitement OCR avec l'option de texte lisible par machine activée afin d'améliorer la détection et l'analyse. Pour en savoir plus, consultez Analyser et segmenter des documents.

Si vous souhaitez utiliser la recherche d'agent pour la génération augmentée par récupération (RAG), activez la segmentation des documents lorsque vous créez votre data store. Pour en savoir plus, consultez Analyser et segmenter des documents.

Vous pouvez importer des données non structurées à partir des sources suivantes :

Cloud Storage

Vous pouvez importer des données depuis Cloud Storage avec ou sans métadonnées.

L'importation de données est récursive. Autrement dit, s'il existe des dossiers dans le bucket ou le dossier que vous spécifiez, les fichiers de ces dossiers sont importés.

Si vous prévoyez d'importer des documents depuis Cloud Storage sans métadonnées, placez-les directement dans un bucket Cloud Storage. L'ID de document est un exemple de métadonnées.

Pour les tests, vous pouvez utiliser les dossiers Cloud Storage suivants, accessibles au public et contenant des fichiers 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

Si vous prévoyez d'importer des données depuis Cloud Storage avec des métadonnées, placez un fichier JSON contenant les métadonnées dans un bucket Cloud Storage dont vous fournissez l'emplacement lors de l'importation.

Vos documents non structurés peuvent se trouver dans le même bucket Cloud Storage que vos métadonnées ou dans un autre.

Le fichier de métadonnées doit être un fichier JSON Lines ou NDJSON. L'ID de document est un exemple de métadonnées. Chaque ligne du fichier de métadonnées doit respecter l'un des formats JSON suivants :

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

Utilisez le champ uri de chaque ligne pour pointer vers l'emplacement Cloud Storage du document.

Voici un exemple de fichier de métadonnées NDJSON pour un document non structuré. Dans cet exemple, chaque ligne du fichier de métadonnées pointe vers un document PDF et contient les métadonnées de ce document. Les deux premières lignes utilisent jsonData, et les deux suivantes utilisent structData. Avec structData, vous n'avez pas besoin d'échapper les guillemets qui apparaissent entre guillemets.

{"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"}}

Pour créer votre data store, consultez Créer un datastore de recherche.

BigQuery

Si vous prévoyez d'importer des métadonnées depuis BigQuery, créez une table BigQuery contenant des métadonnées. L'ID de document est un exemple de métadonnées.

Placez vos documents non structurés dans un bucket Cloud Storage.

Utilisez le schéma BigQuery suivant. Utilisez le champ uri de chaque enregistrement pour pointer vers l'emplacement Cloud Storage du document.

[
  {
    "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"
      }
    ]
  }
]

Pour en savoir plus, consultez Créer et utiliser des tables dans la documentation BigQuery.

Pour créer votre data store, consultez Créer un datastore de recherche.

Google Drive

La synchronisation des données depuis Google Drive est compatible avec la recherche personnalisée.

Si vous prévoyez d'importer des données depuis Google Drive, vous devez configurer Google Identity comme fournisseur d'identité dans la recherche d'agent. Pour en savoir plus sur la configuration du contrôle des accès, consultez Utiliser le contrôle des accès aux sources de données.

Pour créer votre data store, consultez Créer un datastore de recherche.

Données structurées

Préparez vos données en fonction de la méthode d'importation que vous prévoyez d'utiliser. Si vous prévoyez d'ingérer des données multimédias, consultez également Données multimédias structurées.

Vous pouvez importer des données structurées à partir des sources suivantes :

Lorsque vous importez des données structurées depuis BigQuery ou Cloud Storage, vous avez la possibilité de les importer avec des métadonnées. (Les données structurées avec des métadonnées sont également appelées données structurées améliorées.)

BigQuery

Vous pouvez importer des données structurées à partir d'ensembles de données BigQuery.

Votre schéma est détecté automatiquement. Après l'importation, Google vous recommande de modifier le schéma détecté automatiquement pour mapper les propriétés clés, telles que les titres. Si vous importez à l'aide de l'API au lieu de la Google Cloud console, vous avez la possibilité de fournir votre propre schéma en tant qu'objet JSON. Pour en savoir plus, consultez Fournir ou détecter automatiquement un schéma.

Pour obtenir des exemples de données structurées accessibles au public, consultez les ensembles de données publics BigQuery.

Si vous prévoyez d'inclure des embeddings dans vos données structurées, consultez Utiliser des embeddings personnalisés.

Si vous choisissez d'importer des données structurées avec des métadonnées, vous incluez deux champs dans vos tables BigQuery :

  • Un champ id pour identifier le document. Si vous importez des données structurées sans métadonnées, l'id est généré pour vous. L'inclusion de métadonnées vous permet de spécifier la valeur de l'id.

  • Un champ jsonData contenant les données. Pour obtenir des exemples de chaînes jsonData, consultez la section précédente Cloud Storage.

Utilisez le schéma BigQuery suivant pour les importations de données structurées avec des métadonnées :

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

Pour obtenir des instructions sur la création de votre data store, consultez Créer un datastore de recherche ou Créer un datastore de recommandations.

Cloud Storage

Les données structurées dans Cloud Storage doivent être au format JSON Lines ou NDJSON. Chaque fichier doit être inférieur à 2 Go, et chaque ligne du fichier doit être inférieure à 1 Mo. Vous pouvez importer jusqu'à 1 000 fichiers dans une seule requête d'importation.

Pour obtenir des exemples de données structurées accessibles au public, consultez les dossiers suivants dans Cloud Storage, qui contiennent des fichiers NDJSON :

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

Si vous prévoyez d'inclure des embeddings dans vos données structurées, consultez Utiliser des embeddings personnalisés.

Voici un exemple de fichier de métadonnées NDJSON de données structurées. Chaque ligne du fichier représente un document et est composée d'un ensemble de champs.

{"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"]}

Pour créer votre data store, consultez Créer un datastore de recherche ou Créer un datastore de recommandations.

Données JSON locales

Vous pouvez importer directement un document ou un objet JSON à l'aide de l'API.

Google vous recommande de fournir votre propre schéma en tant qu'objet JSON pour obtenir de meilleurs résultats. Si vous ne fournissez pas votre propre schéma, le schéma est détecté automatiquement. Après l'importation, nous vous recommandons de modifier le schéma détecté automatiquement pour mapper les propriétés clés, telles que les titres. Pour en savoir plus, consultez Fournir ou détecter automatiquement un schéma.

Si vous prévoyez d'inclure des embeddings dans vos données structurées, consultez Utiliser des embeddings personnalisés.

Pour créer votre data store, consultez Créer un datastore de recherche ou Créer un datastore de recommandations.

Données multimédias structurées

Si vous prévoyez d'ingérer des données multimédias structurées, telles que des vidéos, des actualités ou de la musique, consultez les ressources suivantes :

Données de santé FHIR

Si vous prévoyez d'ingérer des données FHIR à partir de l'API Cloud Healthcare, assurez-vous des points suivants :

  • Emplacement : le datastore FHIR source doit se trouver dans un ensemble de données de l'API Cloud Healthcare situé dans la région us-central1, us, ou eu. Pour en savoir plus, consultez Créer et gérer des ensembles de données dans l'API Cloud Healthcare.
  • Type de datastore FHIR : le datastore FHIR source doit être un data store R4. Vous pouvez vérifier les versions de vos datastores FHIR en listant les datastores FHIR dans votre ensemble de données. Pour créer un datastore FHIR R4, consultez Créer des datastores FHIR.
  • Quota d'importation : le datastore FHIR source doit contenir moins d'un million de ressources FHIR. S'il contient plus d'un million de ressources FHIR, le processus d'importation s'arrête une fois cette limite atteinte. Pour en savoir plus, consultez Quotas et limites.
  • Consultez la liste des ressources FHIR R4 compatibles avec la recherche d'agent. Pour en savoir plus, consultez la documentation de référence sur le schéma de données FHIR R4 pour la santé.

  • Références aux ressources : assurez-vous que les références relatives aux ressources sont au format Resource/resourceId. Par exemple, subject.reference doit avoir pour valeur Patient/034AB16. Pour en savoir plus sur la compatibilité de l'API Cloud Healthcare avec les références aux ressources FHIR, consultez Références aux ressources FHIR.

  • Les fichiers référencés dans une ressource DocumentReference doivent être des fichiers PDF, RTF ou image stockés dans Cloud Storage. Le lien vers les fichiers référencés doit se trouver dans le champ content[].attachment.url de la ressource au format de chemin d'accès Cloud Storage standard : gs://BUCKET_NAME/PATH_TO_REFERENCED_FILE.

    Le tableau suivant répertorie les limites de taille de fichier pour chaque type de fichier avec différentes configurations (pour en savoir plus, consultez Analyser et segmenter des documents). Vous pouvez importer jusqu'à 100 000 fichiers à la fois.