Synchronisation automatique des connaissances et configuration des métadonnées

La synchronisation automatique des connaissances maintient certains contenus publics WordPress disponibles dans la base de connaissances AI-Kit sans devoir publier manuellement chaque document source généré. Elle est distincte de Static Publisher : l'une met à jour la source de connaissances utilisée par la recherche et le chat ; l'autre déploie des pages statiques publiques.

Connecter le site​

Ouvrez SmartCloud → AI-Kit Settings → Knowledge Base → Automatic Knowledge Sync. La fonctionnalité Pro connectée nécessite un backend AI-Kit compatible. AI-Kit 1.4.19 et les versions ultérieures exigent une capacité knowledge.automation de niveau 5 pour la livraison automatique des documents, disponible dans la version backend 1.0.85 et les versions compatibles ultérieures. Les états de source prenant en compte la synchronisation ci-dessous sont disponibles à partir d'AI-Kit 1.4.20.

1. Configurez d'abord API Settings. Il s'agit de la source de vérité pour le backend : une URL directe est utilisée directement ; un nom d'API Gatey REST est résolu vers son point de terminaison configuré. Backend from API Settings est en lecture seule.
2. Sous Connection and runner, sélectionnez l'environnement approprié et le stockage de clé privée. L'option Encrypted WordPress option est disponible ; l'option Protected file outside webroot nécessite que l'emplacement serveur protégé soit configuré. Disabled ne peut pas inscrire le site.
3. Enregistrez les paramètres de connexion, puis sélectionnez Create pairing code and enroll. Le code à durée de vie courte établit une clé de signature spécifique au site pour les requêtes côté serveur ultérieures.
4. Confirmez Enrolled et utilisez Verify connection si nécessaire.

L'inscription seule n'active pas tous les types de contenu pour la synchronisation.

Choisir le contenu et la politique d'approbation​

Sous Content policy, sélectionnez un type de contenu public, activez Automatically synchronize this content type, configurez sa politique, puis Save content policy. Répétez l'opération pour chaque type souhaité. Les articles et pages standard sont pris en charge, tout comme les types de contenu personnalisés publics éligibles avec des URL publiques.

• WordPress publish is approval autorise la livraison automatique des modifications de contenu publiées.
• Manual KB review retient les modifications jusqu'à ce qu'un administrateur les examine et sélectionne Approve selected content type sous Operational status.
• Taxonomies included in metadata choisit les taxonomies qui contribuent aux termes du document et au vocabulaire dérivé de WordPress. Sélectionner des taxonomies sans activer et enregistrer la politique de contenu ne publie pas de vocabulaire.
• Document profile est un libellé de routage avancé stocké avec les métadonnées du document backend. Conservez default sauf si vos filtres de récupération utilisent explicitement un autre profil ; cela ne modifie pas la conversion ni l'ingestion en soi.

Seuls les contenus publiés éligibles appartenant aux types de contenu publics sélectionnés sont livrés. Les brouillons, les révisions, les propositions non publiées et les contenus à statut privé ne sont pas des sources de livraison automatique. La dépublication de contenu précédemment synchronisé produit une demande de suppression plutôt que le téléversement de la version non publiée. Les ensembles de suppression volumineux peuvent nécessiter une approbation explicite.

Planification et synchronisation initiale​

AI-Kit enregistre un événement cron WordPress toutes les cinq minutes. Le trafic WP-Cron habituel peut l'exécuter. Sur les sites peu fréquentés, ou lorsque WP-Cron piloté par le trafic est désactivé, planifiez wp cron event run --due-now toutes les cinq minutes sur le serveur WordPress. Un verrou de runner empêche les exécutions qui se chevauchent.

Il s'agit d'un workflow PHP/côté serveur, pas d'une tâche effectuée par les visiteurs du front-end statique. L'hôte WordPress a besoin d'une connectivité sortante vers le backend résolu. Le chatbot et Doc Search basés sur le navigateur peuvent toujours fonctionner sur un site statique une fois que l'installation WordPress source a synchronisé son contenu.

Run one sync pass exécute un passage borné, pas nécessairement l'import initial complet. Les tailles des lots de base et de transport limitent le travail par passage ; cron poursuit le travail restant. Consultez Operational status pour les éléments en attente, les enregistrements de base, les motifs de blocage, l'état d'ingestion et le dernier résultat du runner.

Couches de configuration des métadonnées​

La boîte Metadata configuration layers combine trois entrées possédées indépendamment. Il ne s'agit pas de trois copies modifiables du même fichier généré.

Tous les éditeurs et aperçus de couches de métadonnées utilisent YAML. Ce format de présentation et de stockage ne modifie pas les objets JSON structurés de requête et de réponse de l'API, ni les sidecars *.metadata.json par document requis par l'ingestion de la base de connaissances ; ceux-ci restent en JSON.

Le résultat généré fusionne les vocabulaires externes et WordPress activés avec la politique manuelle. Utilisez allowedCategories, allowedTags et namespaceTags pour les valeurs que vous souhaitez conserver intentionnellement dans la couche manuelle ; les valeurs de namespaceTags doivent également apparaître dans allowedTags. Les champs existants comme categoryPolicies restent une politique rédigée. Utilisez vocabularyPolicy uniquement lorsque des alias, des exclusions ou des valeurs d'affichage verrouillées sont nécessaires pour normaliser les entrées automatiques. Modifiez les entrées ou la politique, pas le résultat généré.

Par exemple, un vocabulaire externe peut exprimer une hiérarchie de catégories sans transformer une catégorie enfant en autre catégorie de premier niveau :

- id: docusaurus
  enabled: true
  namespaces:
    category:
      - slug: guides
        label: Guides
      - slug: setup
        label: Setup
        parentSlug: guides
    post_tag:
      - ai-kit

Conservez des identifiants de producteur stables. La liste YAML externe contient des enveloppes de vocabulaire, pas des documents à téléverser. Le rafraîchissement de ce panneau lit seulement son état actuel ; exécutez un passage de synchronisation ou attendez que cron livre le vocabulaire WordPress modifié.

Migrer une configuration existante​

Lorsque Legacy config ready to migrate apparaît, les entrées externes et WordPress sont mises en scène tandis que la configuration effective actuelle reste inchangée. Examinez Proposed result avant de choisir Establish manual layer. La couche manuelle proposée préserve les champs de politique manuelle uniquement et les champs inconnus tout en laissant le vocabulaire fourni par les producteurs sous le contrôle des producteurs.

L'établissement de la couche manuelle active la fusion mise en scène. Ce n'est pas une instruction pour supprimer la politique personnalisée existante, et cela ne supprime pas les anciens documents de la base de connaissances. Examinez délibérément toute valeur manuelle de catégorie et de tag conservée ; ne les effacez pas simplement parce qu'un autre producteur utilise aussi ces termes. Après la migration, de nouveaux enregistrements valides d'entrée ou de politique peuvent mettre à jour le résultat effectif sans autre étape d'établissement.

URL source et remplacements de document​

Pour un document source généré automatiquement, la priorité de l'URL source est la suivante :

1. Source URL explicite du document dans Edit Base Document Metadata.
2. KB Settings → Base URL Override, appliqué au permalien WordPress.
3. Permalien WordPress d'origine.

Utilisez le remplacement global lorsqu'un site éditorial a une origine publique différente, par exemple lorsque vous éditez sur un hôte de développement mais servez le contenu sur l'hôte de production. Une URL explicite par document est prioritaire.

La synchronisation automatique respecte également les remplacements du titre, de la description, de la catégorie, de la sous-catégorie et des tags du document source. Ces remplacements de métadonnées ne verrouillent pas à eux seuls le Markdown généré. Les modifications de métadonnées entrent dans le workflow de synchronisation sous la même politique d'approbation ; la modification du remplacement global Base URL Override déclenche le rapprochement des documents existants.

Lire correctement l'état​

Le filtre et les badges de statut de publication KB Sources distinguent les états de livraison automatique tels que en attente de synchronisation, synchronisation en cours, livré, erreur, bloqué et supprimé. Les erreurs incluent leur raison spécifique lorsqu'elle est disponible.

Delivered signifie que le backend a reçu la génération actuelle du document. Cela ne signifie pas que l'indexation de la base de connaissances est terminée. Vérifiez l'ingestion backend sous Operational status avant d'attendre des résultats de recherche ou de chat mis à jour.

Needs Review reste pertinent pour les travaux à approbation manuelle, les documents manuels séparés ou les remplacements verrouillés obsolètes. Une livraison automatique réussie d'un document source de base n'approuve pas automatiquement ces éléments séparés. À l'inverse, l'absence d'un enregistrement de publication manuel ne place pas à elle seule un document source synchronisé en revue.