Configurer les paramètres de champs

Cette page vous explique comment configurer les champs de schéma pour configurer une application pour les données structurées, pour les données non structurées avec des métadonnées ou pour les données de site Web avec des attributs structurés personnalisés.

Les paramètres de champ permettent de déterminer comment la recherche d'agent utilise les champs dans ses résultats. Vous pouvez utiliser l'onglet Schéma de la consoleGoogle Cloud pour configurer les paramètres des champs.

La configuration des paramètres de champ n'est disponible que pour les applications dont les data stores contiennent des données structurées ou des données non structurées avec des métadonnées.

Paramètres de champ

Les paramètres de champ suivants sont disponibles pour de nombreux types de champs dans vos données de recherche ou de recommandations, mais pas pour tous les types de données. Un schéma contient plusieurs paramètres de champ pour les champs individuels. Le tableau suivant contient les paramètres qui peuvent être appliqués à un champ dans un schéma. Nous vous recommandons vivement d'utiliser des données structurées pour les paramètres de champ suivants :

Paramètre Définition Objectif Exemple de cas d'utilisation
Indexable

Définir des champs comme indexables permet d'effectuer des opérations telles que le filtrage, l'amplification et le facettage sur des champs structurés dans un document.

Les champs de type Object ne peuvent pas être définis sur Indexable.

Marquer un champ comme Indexable permet des recherches plus rapides.

Notez que le fait de marquer un champ comme Indexable augmente la taille de l'index de recherche et peut ralentir l'indexation.

 Dans un data store d'hôtels, vous pouvez définir un champ, tel que hotel_chain, comme indexable. Cela vous permet d'appliquer des opérations de classement, de filtrage et de boosting sur hotel_chain. Par exemple, vous pouvez appliquer un filtre pour que la recherche ne renvoie que les résultats de recherche contenant la chaîne hôtelière filtrée.
Inclus dans l'index de recherche

Les champs les plus susceptibles d'être liés aux recherches sont désignés par Searchable. Un champ peut être consultable sans être indexable ni récupérable.

Seuls les champs contenant des valeurs textuelles peuvent être marqués comme pouvant faire l'objet d'une recherche. Par conséquent, un champ de prix numérique peut être indexable (pour le filtrage ou la segmentation), mais ne peut pas faire l'objet d'une recherche en tant que texte intégral.

Définir un champ sur Inclus dans l'index de recherche améliore le rappel pour ce champ dans les requêtes de recherche, ce qui permet aux utilisateurs de trouver du contenu, comme des pages Web, en interrogeant le texte de ces champs. Marquer un champ comme pouvant faire l'objet d'une recherche permet d'appliquer un classement. Par conséquent, le fait de marquer un nombre excessif de champs comme pouvant faire l'objet d'une recherche peut avoir un impact négatif sur la précision de la recherche en sursaturant l'algorithme de classement et en renvoyant trop de résultats. Cela peut entraîner des résultats de recherche non pertinents.

Vous pouvez appliquer une pondération relative aux champs pouvant faire l'objet d'une recherche. Toutefois, cela est rarement nécessaire en raison des paramètres par défaut robustes. Consultez les champs de poids pouvant faire l'objet d'une recherche ci-dessous.

Le système de tickets d'assistance d'un fournisseur d'accès à Internet stocke chaque ticket sous la forme d'un document structuré. Si ces documents contiennent des champs de texte pouvant faire l'objet d'une recherche, tels que issue_description ou resolution_notes, un agent d'assistance peut effectuer une requête liée au contenu de ces champs, par exemple comment résoudre les problèmes de lenteur de connexion Internet après le redémarrage du modem.Le système affichera ensuite les documents contenant l'un de ces termes de recherche, y compris modem, Internet et vitesse, dans l'un ou l'autre des champs issue_description ou resolution_notes.
Correspondance de préfixe
(Aperçu)

Permet la correspondance de préfixes pour les champs de texte à l'aide de l'opérateur STARTS_WITH dans les expressions de filtre. Seuls les champs de type String ou String Array peuvent être définis comme "Correspondance de préfixes".

Pour en savoir plus, consultez la section Rendre les champs disponibles pour la correspondance partielle et par préfixe ci-dessous.

Si vous définissez un champ comme pouvant être mis en correspondance avec un préfixe, le moteur de recherche peut faire correspondre les chaînes de requête qui sont des préfixes de la valeur du champ. Cela est particulièrement utile pour faire correspondre les identifiants, chemins ou codes hiérarchiques dont le début de la chaîne est connu. La correspondance avec un préfixe est limitée aux 12 premiers caractères de la valeur normalisée du champ et augmente la taille de l'index de recherche. Vous ne pouvez pas définir plus de 10 champs comme pouvant être mis en correspondance avec un préfixe.

Vous disposez d'un champ, ticket_id, qui utilise un format tel que <country-code><city-code><number>. Par exemple, UKLON100, UKMAN100, UKMAN101 et USNY200. Pour trouver tous les billets de Manchester (Royaume-Uni), vous pouvez définir le champ ticket_id comme pouvant être mis en correspondance avec un préfixe, puis utiliser le filtre ticket_id: STARTS_WITH("UKMAN"), qui renvoie UKMAN100 et UKMAN101.
Correspondance partielle
(aperçu)

Permet la correspondance partielle de chaînes sur les champs de texte à l'aide de l'opérateur CONTAINS dans les expressions de filtre. Seuls les champs de type String ou String Array peuvent être définis comme partiellement correspondants.

Pour en savoir plus, consultez la section Rendre les champs disponibles pour la correspondance partielle et par préfixe ci-dessous.

Définir un champ comme partiellement correspondable permet d'effectuer une mise en correspondance basée sur des jetons dans un champ. Les utilisateurs peuvent ainsi trouver du contenu lorsqu'ils ne connaissent qu'une partie de la valeur du champ. Le moteur de recherche fait correspondre les jetons de requête aux jetons de la valeur du champ, quel que soit leur ordre. Notez que le fait de marquer un champ comme partiellement correspondable augmente la taille de l'index de recherche. Vous ne pouvez pas définir plus de 10 champs comme partiellement correspondants.

Vous souhaitez filtrer les régions en Europe. Les noms region incluent Central Europe et Eastern Europe. Si votre filtre est défini sur region: ANY("Europe"), vous n'obtiendrez aucun résultat. Toutefois, si le champ region est défini comme partiellement correspondable, vous pouvez filtrer avec region: CONTAINS("Europe") et obtenir des correspondances pour Central Europe et Eastern Europe.

Ajout d'attributs dynamique Fournit des filtres contextuels pour mieux cibler les recherches des utilisateurs. Définir un champ comme Dynamic Facetable permet au système de générer automatiquement des filtres interactifs (facettes) en fonction des valeurs uniques présentes dans le champ. Définir un champ sur Dynamic facetable permet aux utilisateurs d'affiner dynamiquement les résultats de recherche en sélectionnant des catégories ou des attributs directement dérivés de vos données ingérées, sans avoir à prédéfinir manuellement toutes les options de filtrage possibles. Cela permet à l'utilisateur d'affiner sa recherche pour trouver des contenus Web très spécifiques.
Utilisez Dynamic Facetable avec Searchable pour obtenir de meilleurs résultats, ce qui améliore à la fois le rappel de votre recherche et la qualité des facettes proposées à l'utilisateur. 		Les pages d'une base de connaissances interne à l'entreprise, telles que les règles RH, sont ingérées avec des données telles que department, document_type ou last_modified_date. Si ces champs sont tagués comme dynamic facetable, une recherche d'employé pour un terme tel que remboursement de frais génère dynamiquement des filtres interactifs basés sur les résultats pertinents trouvés. Dans ce cas, l'interface Web peut afficher des facettes pour Service : Finances, Voyages, Type de document : Règlement, FAQ ou Date de dernière modification : Ce trimestre, L'année dernière.
Récupérable Lorsqu'une requête de recherche correspond à un contenu, le moteur de recherche peut extraire les valeurs des champs récupérables pour les afficher ou les utiliser dans l'application. Cela signifie que les informations du document d'origine sont affichées dans les résultats de recherche. Les champs clés (identifiants uniques des documents) sont configurés comme récupérables. Les champs récupérables fournissent un contexte de recherche en distinguant les champs dont les valeurs peuvent être affichées de ceux qui ne doivent être utilisés que dans la logique de recherche, mais dont les valeurs brutes ne sont pas destinées à être affichées à l'utilisateur final. Pour une recherche de produits sur le site d'un marchand, product_id, name, price et image_url sont des champs que vous souhaitez généralement définir comme récupérables. En revanche, le internal_tracking_code peut être indexé et filtrable à des fins administratives uniquement, mais ne peut pas être récupéré dans les résultats de recherche publics.
À compléter Permet d'utiliser le contenu d'un champ pour les suggestions de requêtes de recherche. Pour en savoir plus, consultez Configurer la saisie semi-automatique.

Ce paramètre permet d'utiliser les valeurs de ce champ pour fournir des suggestions de requêtes en temps réel à mesure que les utilisateurs saisissent du texte. Cette fonctionnalité aide vos utilisateurs à trouver du contenu pertinent et accélère le processus de recherche. Certains facteurs, tels que l'utilisation du filtrage en langage naturel, peuvent avoir un impact sur ces performances.

 Si le champ completable est défini sur product_name, brand et category, lorsque l'utilisateur saisit Tech, les suggestions de saisie semi-automatique peuvent afficher :
  • TechCo (à partir du champ brand)
  • TechCo UltraBook X1 (à partir du champ product_name)
  • Technologie GameMaster Pro (autre produit du champ category)
Filtrable Permet aux recommandations d'utiliser un champ pour filtrer les résultats recommandés, en déterminant les résultats de recherche que vos utilisateurs voient. Pour en savoir plus sur le filtrage des recommandations, consultez Filtrer les recommandations. Définir un champ sur Filterable permet de personnaliser les recommandations pour les utilisateurs. Notez que des limites de filtrage s'appliquent. Un paramètre de filtre par langue et par genre (drame) pourrait ressembler à ceci : language_code: ANY("en", "fr") OR categories: ANY("drama").

Différences entre les paramètres couramment utilisés

Il existe des différences importantes entre les paramètres de champ "Indexable", "Consultable" et "Récupérable". Le tableau suivant résume ces différences.

Fonctionnalité Indexable Inclus dans l'index de recherche Récupérable
Rôle principal Rend le contenu du champ disponible pour les moteurs de recherche Permet d'effectuer des requêtes en texte intégral sur le contenu des champs. Permet de renvoyer la valeur du champ dans les résultats de recherche.
Analyse Le contenu est traité et placé dans un index. Elle fait généralement l'objet d'une analyse lexicale approfondie. La valeur est stockée telle quelle pour l'affichage.
Peut-il s'agir de… ?
...inclus dans l'index de recherche ? Oui (souvent une condition préalable) ND Pas nécessairement (peut être récupérable sans être consultable)
… récupérable ? Pas nécessairement Pas nécessairement ND
...filtrable/triable/facettable ? Oui (généralement une condition préalable pour ceux-ci aussi) Non directement. Il s'agit d'attributs distincts souvent basés sur un champ indexable. Non directement. Ces attributs sont liés à la façon dont le champ est indexé et interrogé, et pas seulement affiché.

En pratique, de nombreux champs essentiels à l'expérience utilisateur (comme les titres, les descriptions et les informations d'identification) sont souvent définis sur indexable, searchable et retrievable.

Limites

Les paramètres de champ présentent les limites suivantes :

  • Vous pouvez configurer jusqu'à 50 champs comme indexables, inclus dans l'index de recherche, récupérables ou avec des attributs dynamiques.
  • Pour configurer un champ comme pouvant être utilisé pour le filtrage dynamique, il doit d'abord être configuré comme indexable.
  • La modification du paramètre d'indexation nécessite une réindexation des données, ce qui peut prendre des heures, en particulier pour les grands data stores.

Si vous configurez des champs pour une application de recherche de contenus multimédias et que vous souhaitez obtenir des informations détaillées sur les champs du schéma, consultez À propos des documents multimédias et des data stores.

Modifier les paramètres des champs

Pour modifier les paramètres d'un champ :

  1. Dans la console Google Cloud , accédez à la page Applications d'IA.

    AI Applications

  2. Cliquez sur le nom de l'application que vous souhaitez modifier.

  3. Cliquez sur Data (Données).

  4. Cliquez sur l'onglet Schéma. Cet onglet affiche les paramètres de champ actuels.

    L'onglet Schéma ne s'affiche pas si votre data store contient des données de site Web de base ou des données non structurées sans métadonnées.

  5. Cliquez sur Modifier.

  6. Sélectionnez ou désélectionnez les paramètres de champ que vous devez modifier. Certains paramètres de champ ne sont pas acceptés. Par exemple, les champs numériques ne peuvent pas être définis sur Consultable.

  7. Cliquez sur Enregistrer pour appliquer les modifications.

Si vous marquez un champ comme pouvant être inclus dans l'index de recherche, vous pouvez spécifier une pondération pour indiquer son importance relative dans les résultats de recherche. Dans la plupart des cas, vous n'avez pas besoin de spécifier de pondérations pour les champs individuels, car les pondérations par défaut fonctionnent bien.

Toutefois, il peut être nécessaire d'ajuster les pondérations dans certaines situations, par exemple :

  • Vous migrez des données depuis une plate-forme de recherche existante qui utilise déjà des champs pondérés.

  • Lorsque les pondérations par défaut ne fournissent pas de résultats de recherche satisfaisants. Cela peut se produire lorsque vous avez de nombreux champs pouvant faire l'objet d'une recherche et que certains sont nettement plus importants que d'autres.

    Le résumé est peut-être le champ le plus important pour les recherches. Vous souhaitez donc donner la priorité à ce texte.

    Ou bien, le schéma comporte un champ contenant des mots clés très pertinents qui sont d'excellents indicateurs pour les résultats de recherche. Toutefois, comme ce champ est beaucoup plus court que les autres, son influence est souvent éclipsée par les champs plus longs. Augmenter son poids permet de s'assurer qu'il a l'impact souhaité.

Niveaux de pondération

Les pondérations sont réparties dans les niveaux suivants :

Importance du champ Explication
Très faible Valeur faible que le système prend toujours en compte lorsqu'il combine les scores de tous les champs. Si vous souhaitez que l'effet soit négligeable, ne cochez pas la case "Peut être recherché".
Faible Pondération inférieure à celle par défaut.
Par défaut Pondération standard pour les champs pouvant faire l'objet d'une recherche. Ce poids offre des performances raisonnablement bonnes dans la plupart des cas.
Élevée Un poids nettement supérieur à la valeur par défaut.
Très élevé Pondération dominante. En règle générale, vous la réservez à un champ maximum.

Mise à jour du schéma et réindexation

L'ajout de pondérations aux champs pouvant faire l'objet d'une recherche nécessite une mise à jour du schéma et une réindexation ultérieure des données dans le data store. La mise à jour du schéma prend des heures, et il n'existe pas d'indicateur fiable pour vous indiquer quand l'indexation est terminée. Vous devez donc surestimer le temps d'indexation.

Définir des niveaux de pondération pour les champs

La tâche de définition des niveaux de pondération pour les champs peut être fastidieuse, car vous ne devez apporter que de petites modifications et examiner attentivement les résultats de recherche par la suite pour vérifier qu'il n'y a pas de conséquences indésirables. Après chaque modification, vous devez attendre la fin de la réindexation avant de pouvoir évaluer l'impact de la modification.

Vous ne pouvez configurer la pondération des champs de recherche que via l'API. Cette fonctionnalité n'est pas disponible dans la console Google Cloud .

Pour définir des pondérations, vous devez mettre à jour le schéma du data store via la méthode d'API projects.locations.dataStores.schemas.patch.

  1. Si vous n'avez pas encore votre schéma, suivez les instructions pour l'obtenir dans Afficher la définition d'un schéma.

  2. Suivez les instructions pour mettre à jour le schéma de manière programmatique. Ajoutez des pondérations à un ou plusieurs champs pouvant faire l'objet d'une recherche, comme dans ces exemples :

    "summary": {
   "type": "string",
   "searchable": true,
   "weight": "high"
 },
 "uri": {
   "type": "string",
   "searchable": true,
   "weight": "low"
 },

    Dans cet exemple, le champ summary est défini sur une pondération supérieure à la normale, et le champ uri sur une pondération inférieure. Si vous souhaitez rétablir la valeur par défaut d'un poids, définissez-le sur default.

    Les valeurs autorisées pour le paramètre "weight" sont les suivantes :

    • very_low
    • low
    • default
    • high
    • very_high

  3. Attendez que la réindexation soit terminée, puis testez le comportement de la recherche.

Rendre les champs disponibles pour la correspondance des préfixes et la correspondance partielle (preview)

Pour les champs de type string, vous pouvez modifier le schéma afin de rendre les champs disponibles pour la correspondance de préfixe ou la correspondance partielle. Cela vous permet d'utiliser STARTS_WITH ou CONTAINS dans les expressions de filtre.

Mise à jour du schéma et réindexation

Pour que les champs soient disponibles pour la correspondance par préfixe ou partielle, vous devez mettre à jour le schéma et réindexer les données dans le data store. La mise à jour du schéma prend des heures, et il n'existe pas d'indicateur fiable pour vous indiquer quand l'indexation est terminée. Vous devez donc surestimer le temps d'indexation.

Mettre à jour le schéma pour la correspondance des préfixes et partielle

Pour spécifier que des champs sont disponibles pour la correspondance de préfixe ou la correspondance partielle, vous devez mettre à jour le schéma du data store à l'aide de la méthode d'API projects.locations.dataStores.schemas.patch.

  1. Si vous n'avez pas encore votre schéma, suivez les instructions pour l'obtenir dans Afficher la définition d'un schéma.

  2. Suivez les instructions pour mettre à jour le schéma de manière programmatique. Définissez les paramètres correspondants sur true dans le schéma, comme dans les exemples suivants :

    "zone": {
   "type": "string",
   "searchable": true,
   "prefixMatchable": true
 },
 "region": {
   "type": "string",
   "searchable": true,
   "partialMatchable": true
 },
 "model": {
   "type": "string",
   "searchable": true,
   "prefixMatchable": true,
   "partialMatchable": true
 },

    Dans cet exemple, le champ zone est défini comme pouvant correspondre à un préfixe. Vous pouvez utiliser jusqu'à 12 caractères (sans tenir compte de la casse) dans l'expression de filtre pour faire correspondre la valeur du champ. Le champ region est défini comme partiellement correspondable.

  3. Attendez la fin de la réindexation.

Informations sur la correspondance de préfixe

La correspondance de préfixe dans la recherche d'agent vous permet de filtrer les résultats en fonction de la valeur d'un champ qui commence par une chaîne spécifique. Cette fonctionnalité est optimisée par l'opérateur STARTS_WITH et nécessite que le champ de texte cible soit configuré comme prefixMatchable dans le schéma.

Logique de normalisation et de mise en correspondance

Pour optimiser les performances et assurer la cohérence, le système applique un processus de normalisation spécifique à la valeur du champ (lors de l'indexation) et à la chaîne de requête (lors de la recherche).

  1. Mise en minuscules : tous les caractères sont convertis en minuscules. La correspondance ne tient pas compte de la casse.

  2. Troncature à 12 caractères : le système ne prend en compte que les 12 premiers caractères de la chaîne. Tous les caractères au-delà de cette limite sont ignorés pour la correspondance de préfixe.

Fonctionnement

Lors de l'indexation, pour un champ marqué comme prefixMatchable, le système génère des jetons de préfixe pour les 12 premiers caractères. Pour une valeur telle que asia-south1-c, l'index stocke les jetons pour a, as, asi, asia, asia-, etc., jusqu'au 12e caractère (asia-south1-).

Au moment de la requête, la chaîne fournie à l'opérateur STARTS_WITH est également mise en minuscules et tronquée à 12 caractères. La requête est ensuite comparée aux jetons de préfixe stockés.

Exemples

Les exemples suivants montrent comment la normalisation sur 12 caractères affecte les résultats de recherche :

  • Requête large : STARTS_WITH("A") correspond à n'importe quelle valeur commençant par "a" (sans tenir compte de la casse), comme asia, australia ou africa.

  • Préfixes partiels : STARTS_WITH("asia-south") correspond à asia-south1-a et à asia-southeast1-b, car les deux commencent par la chaîne de 10 caractères spécifiée.

  • Comportement de troncature : comme seuls les 12 premiers caractères sont mis en correspondance, STARTS_WITH("asia-south1-a") correspond à une valeur de champ de asia-south1-c. Cela se produit, car les deux chaînes sont normalisées avec le même préfixe de 12 caractères : asia-south1-.

Informations sur la correspondance partielle

La correspondance partielle dans la recherche d'agents vous permet de filtrer les résultats selon que la valeur d'un champ contient des mots ou des jetons spécifiques. Cette fonctionnalité est optimisée par l'opérateur CONTAINS et nécessite que le champ de texte cible soit configuré comme partialMatchable dans le schéma.

Logique de normalisation et de tokenisation

La recherche d'agents normalise et tokenise à la fois la valeur du champ (lors de l'indexation) et la chaîne de requête (lors de la recherche) :

  • Mise en minuscules : la recherche d'agent convertit les caractères en minuscules, ce qui rend la correspondance insensible à la casse.

  • Tokenisation : la recherche d'agent divise la chaîne en jetons (mots) individuels à l'aide d'espaces et d'autres caractères comme délimiteurs.

    • Délimiteurs standards : les espaces et la ponctuation courante servent de délimiteurs. Il s'agit, entre autres, des tirets (-), des barres obliques (/), des virgules (,), des points (.), des astérisques (*), des accolades ({ }), des crochets ([ ]), des parenthèses (( )) et des apostrophes (').

    • Non-délimiteurs : l'esperluette (&) et le trait de soulignement (_) ne servent pas de délimiteurs. Le système traite les caractères joints par ces symboles comme un seul jeton.

    • Délimiteur d'adresse e-mail (@) : le symbole @ sert de délimiteur spécial pour faciliter la reconnaissance des adresses e-mail. Le système génère des jetons pour les composants individuels ainsi que pour les formes combinées. Par exemple, il tokenise support+tier1@example.com en support, tier1, example, com, support+tier1@example.com et support@example.com.

Fonctionnement

Au moment de l'indexation, pour un champ marqué comme partialMatchable, le système normalise et tokenise la valeur du champ, puis stocke les jetons obtenus dans l'index. Par exemple, il tokenise une valeur de champ 25-meter, outdoor, swimming pool en [25, meter, outdoor, swimming, pool].

Au moment de la requête, la chaîne fournie à l'opérateur CONTAINS subit le même processus de normalisation et de tokenisation. Le moteur de recherche vérifie ensuite que tous les jetons de requête obtenus correspondent aux jetons stockés pour le champ. L'ordre des jetons n'a aucune importance.

Exemples

Les exemples suivants montrent comment la tokenisation affecte les résultats de la correspondance partielle :

  • Correspondance de jetons de base : si la valeur du champ est 25-meter, outdoor, swimming pool, un filtre CONTAINS("Outdoor pool") correspond. Le système tokenise la requête en [outdoor, pool], qui existent tous les deux dans les jetons du champ.

  • Indépendance de l'ordre : un filtre CONTAINS("pool outdoor") correspond également à la valeur de champ 25-meter, outdoor, swimming pool, car le système vérifie la présence de chaque jeton indépendamment de son ordre.

  • Correspondance des adresses e-mail : si un champ stocke l'adresse e-mail support+tier1@example.com, les filtres tels que CONTAINS("support"), CONTAINS("example.com") ou CONTAINS("support@example.com") correspondent tous, grâce à la tokenisation spéciale du symbole @.

Étapes suivantes