Suppression par lot

Supprimez des données en bloc de Communications Mining à l’aide de la CLI, soit à partir d’une source ou d’un compartiment unique par plage de temps, soit sur des ensembles de données entiers avec une rétention basée sur l’ancienneté.

La CLI propose trois façons de supprimer des données en bloc, par exemple lors du nettoyage des données historiques ou de l’application d’une stratégie de conservation.

Commande	Étendue	L'utiliser pour
re delete bulk	Une source	Suppression de commentaires par plage de temps
re delete bulk-emails	Un compartiment	Suppression des e-mails bruts par plage de temps
re prune	Chaque source et chaque compartiment dans les ensembles de données que vous répertoriez	Application d'une rétention basée sur l'âge à un ensemble de données, de commentaires et d'e-mails bruts ensemble

Avertissement :

re delete bulk et re delete bulk-emails suppriment dès que vous les exécutez. Il n’y a pas d’invite de confirmation, pas d’exécution du test et pas de sauvegarde — commencez par en prendre une vous-même. Seul re prune sauvegarde ce qu'il supprime.

Cette section suppose que vous avez déjà installé et configuré la CLI. Vous avez besoin d'autorisations de lecture et de suppression pour chaque projet que vous supprimez. La restauration à partir d’une sauvegarde nécessite en outre l’autorisation de charger des commentaires et des e-mails, ainsi que l’autorisation Ensemble de données - Révision pour restaurer les annotations.

Pour connaître les options prises par une commande, exécutez re <command> --help ou consultez la référence de la commande.

Remarque :

Pour les trois commandes, la période est basée sur le champ timestamp du commentaire ou de l’e-mail, plutôt que sur la date et l’heure de téléchargement dans Communications Mining™.

Pour re delete bulk et re delete bulk-emails, les deux fins de la plage sont facultatives: donnez ni l’un ni l’autre, et la commande couvre l’ensemble de la source ou du compartiment. --from-timestamp est inclusif; --to-timestamp inclut les commentaires et est exclusif des e-mails.

Sauvegarder les données avant de les supprimer

Avant de supprimer ou de modifier vos commentaires, vous pouvez éventuellement sauvegarder les commentaires annotés, afin de ne pas perdre accidentellement le travail manuel des entraîneurs de modèle :

re get comments \
  <project_name/source_name> \
  --dataset <project_name/dataset_name> \
  --reviewed-only true \
  --file <output_file_name.jsonl>

Si la source a été ajoutée à plusieurs ensembles de données, vous devez exécuter la commande mentionnée précédemment pour chacun de ces ensembles de données.

Cette commande capture les commentaires que --include-annotated=false conserve, et non ceux supprimés par la suppression. Pour capturer ceux-ci, exportez la même plage que vous êtes sur le point de supprimer: pour une source, utilisez re get comments avec --from-timestamp et --to-timestamp comme décrit dans Téléchargement par lots, et pour un compartiment:

re get emails \
  <project_name/bucket_name> \
  --from-timestamp FROM_TIMESTAMP \
  --to-timestamp TO_TIMESTAMP \
  --file <output_file_name.jsonl>

Remarque :

Le contenu de la pièce jointe est uniquement exporté lorsque vous transmettez --attachments true à re get comments, et n’est rechargé que lorsque vous transmettez --attachments <directory> à re create comments. En l’absence de celles-ci, une sauvegarde contient les métadonnées des pièces jointes, mais pas les fichiers eux-mêmes.

Supprimer des commentaires d'une source

Avertissement :

La suppression des annotations modifie les performances du modèle.

Si les commentaires que vous souhaitez supprimer ont été ajoutés à un ou plusieurs ensembles de données où ils auraient pu être annotés, la suppression de commentaires annotés entraînera une modification des performances du modèle dans ces ensembles de données à l’avenir. Les modèles publiés ne seront pas affectés.

Vous pouvez éventuellement configurer la CLI pour ignorer les commentaires annotés.

La commande suivante supprime tous les commentaires d’une source comprise entre FROM_TIMESTAMP et TO_TIMESTAMP , à l’exception des commentaires annotés. L'horodatage doit être au format RFC 3339, par exemple 1970-01-02T03:04:05Z.

re delete bulk \
  --source <project_name/source_name> \
  --include-annotated=false \
  --from-timestamp FROM_TIMESTAMP \
  --to-timestamp TO_TIMESTAMP

Si vous voulez vraiment supprimer les commentaires annotés, vous pouvez définir --include-annotated=true.

Remarque :

Ici, --include-annotated=false conserve un commentaire qui est annoté dans n'importe quel ensemble de données contenant la source, y compris les ensembles de données que vous ne pouvez pas voir. re prune utilise une règle plus étroite.

La suppression de commentaires ne supprime pas les e-mails bruts à partir desquels ils ont été analysés.

Suppression des e-mails d'un compartiment

Pour supprimer les e-mails bruts, ciblez le compartiment par plage de temps:

re delete bulk-emails \
  --bucket <project_name/bucket_name> \
  --from-timestamp FROM_TIMESTAMP \
  --to-timestamp TO_TIMESTAMP

Cela supprime chaque e-mail de la plage, y compris les e-mails qui ont été analysés dans des sources autres que celle avec laquelle vous avez travaillé. Les commentaires déjà analysés dans ces e-mails ne sont pas supprimés.

Pour supprimer des e-mails individuels à la place, transmettez jusqu’à 32 identifiants à la fois:

re delete emails \
  --bucket <project_name/bucket_name> \
  <email_id>...

Avertissement :

Transmettez toujours au moins un identifiant. Impossible de re delete emails ni de re delete comments de vérifier si une liste est vide, et une demande de suppression qui ne comporte aucun identifiant risque d'en supprimer beaucoup plus que ce que vous prévoyiez. Faites donc attention aux espaces réservés non étendus et aux variables de shell vides.

Extraction des anciennes données dans un ensemble de données

re prune applique une rétention basée sur l'ancienneté dans un ou plusieurs ensembles de données en une seule exécution, supprimant:

• Commentaires plus anciens que le seuil, provenant de chaque source dans les ensembles de données que vous répertoriez.
• E-mails plus anciens que le seuil, à partir de chaque compartiment à partir duquel ces sources sont lues.

La date limite est le moment exact où le runtime commence, moins --older-than-days, plutôt qu’une limite de jours calendaires.

Avertissement :

re prune supprime définitivement les données. La sauvegarde qu'il écrit est le seul moyen d'annuler une exécution et contient des données personnelles. Écrivez des sauvegardes dans un endroit sécurisé, conservez-les en sécurité et effectuez toujours un test au préalable.

Fonctionnement d'une exécution d'ajustement

1. Résoudre l’étendue. Chaque source dans les ensembles de données que vous transmettez à --datasets est dans l'étendue, ainsi que chaque compartiment à partir duquel ces sources sont lues.
2. Vérifiez les sources partagées. Si une source intégrée à l’étendue appartient également à un ensemble de données que vous n’avez pas répertorié, l’exécution l’interrompt et la nomme. Seuls les ensembles de données que vous avez l’autorisation de lire peuvent être vérifiés.
3. Confirmez. La commande résume l’étendue et les mises en garde qui s’y appliquent, et vous attend. --dry-run et -y ignorent cela.
4. Sauvegardez. D’abord, chaque commentaire examiné dans chaque ensemble de données de l’étendue, puis les commentaires et e-mails sélectionnés pour la suppression.
5. Vérifiez, puis supprimez. L'exécution vérifie chaque fichier de sauvegarde par rapport au nombre d'enregistrements et à la somme de contrôle dans le manifeste, et une incompatibilité unique est abandonnée avant que tout ce qui soit supprimé.

Un test s'arrête après l'étape 4: il écrit une sauvegarde réelle et signale ce qu'il supprimerait, mais ne vérifie ni ne supprime.

Exécution d'un réduction

Commencez par --dry-run.

re prune \
  --datasets <project_name/dataset_name> \
  --older-than-days 730 \
  --backup-dir <backup_directory> \
  --dry-run

Lorsque les chiffres apparaissent à droite, exécutez la même commande sans --dry-run.

Par défaut, un commentaire est conservé, quel que soit son âge, s'il est examiné dans l'un des ensembles de données que vous avez répertorié. Un commentaire annoté uniquement dans un ensemble de données auquel vous ne pouvez pas accéder ne compte pas et est supprimé. Transmettez --include-annotated pour supprimer les anciens commentaires, qu’ils aient été annotés ou non, en tenant compte de l’impact sur les performances du modèle décrit ci-dessus.

Suppression d'une boîte aux lettres unique

--mailbox limite les données supprimées aux données synchronisées à partir d'une boîte aux lettres, ce qui est utile lorsqu'un compartiment reçoit plusieurs boîtes aux lettres et qu'une seule d'entre elles nécessite d'être épurée. La plate-forme filtre les e-mails par nom de boîte aux lettres exact. Les commentaires sont mis en correspondance, insensibles à la casse, sur leur Mailbox ID propriété utilisateur, que l'analyse des e-mails définit uniquement lorsque la balise de transformation de la source enregistre le nom de la boîte aux lettres.

Remarque :

Un commentaire qui ne porte pas un Mailbox ID correspondant n'est jamais mis en correspondance. Par conséquent, si les commentaires de l'étendue ne comportent pas cette propriété, une exécution au niveau de la boîte aux lettres n'en supprime aucun. Vérifiez la balise de transformation avec re get sources avant de vous fier à --mailbox.

--mailbox ne réduit pas la sauvegarde de l'annotation.

Le contenu de la sauvegarde

Chaque exécution crée un nouveau dossier sous --backup-dir, nommé d’après l’heure UTC de début de l’exécution. re prune ne réutilise jamais un dossier existant.

<backup_directory>/20260807T104500Z/
├── manifest.json
├── annotations/<dataset-id>/<source-id>.jsonl
├── deleted-comments/<source-id>.jsonl
└── deleted-emails/<bucket-id>.jsonl

PATH	Contenus
manifest.json	Résumé de l'exécution et l'index de chaque fichier de sauvegarde.
annotations/	Chaque commentaire examiné dans chaque ensemble de données de l'étendue, avec ses annotations, un fichier par ensemble de données et source, et pas seulement ceux en cours de suppression.
deleted-comments/	Les commentaires sélectionnés pour la suppression, un fichier par source, dans le même format que re get comments, mais sans leurs annotations.
deleted-emails/	Les e-mails sélectionnés pour la suppression, un fichier par compartiment, y compris leur contenu MIME brut.

Le manifeste enregistre les paramètres de l'exécution (run_id, cutoff, include_annotated, mailbox, datasets), la taille de l'ensemble de suppression (comment_count, email_count) et, pour chaque fichier de sauvegarde, le resource, il couvre, son chemin file par rapport au dossier de sauvegarde, son enregistrement count et une somme de contrôle crc32.

Remarque :

comment_count et email_count représentent la taille de l'ensemble de suppression de l'exécution sélectionnée. Le manifeste est écrit avant la suppression et n'est pas mis à jour par la suite, de sorte qu'il ne s'agit pas d'un enregistrement de ce qui a été supprimé avec succès.

Restauration à partir d’une sauvegarde

La restauration est manuelle et utilise les commandes re create ordinaires. Les fichiers de sauvegarde sont nommés par leur ID: re get datasets, re get sources et re get buckets répertorient les ID avec les noms, et le manifeste indique à la source ou au compartiment que chaque fichier de l’ensemble de suppressions couvre dans son champ resource. Le count de chaque fichier dans le manifeste correspond au nombre d'enregistrements qu'il contient, ce qui méritent d'être comparés à ce que vous restaurez.

Restaurez les commentaires supprimés dans leur source:

re create comments \
  --source <project_name/source_name> \
  --file <backup_directory>/<run_id>/deleted-comments/<source-id>.jsonl

Une réduction par défaut conserve les commentaires annotés dans les ensembles de données que vous avez répertoriés, de sorte que les annotations n’ont besoin d’être restaurées qu’après une exécution avec --include-annotated. Restaurez-les à partir de la sauvegarde de l’annotation — re create annotations lit ce fichier et ne télécharge que les annotations, laissant les commentaires inchangés:

re create annotations \
  --source <project_name/source_name> \
  --dataset <project_name/dataset_name> \
  --file <backup_directory>/<run_id>/annotations/<dataset-id>/<source-id>.jsonl

Restaurez les e-mails supprimés dans leur compartiment:

re create emails \
  --bucket <project_name/bucket_name> \
  --file <backup_directory>/<run_id>/deleted-emails/<bucket-id>.jsonl

Avertissement :

Une sauvegarde d'annotation couvre chaque commentaire examiné dans l'ensemble de données, et pas uniquement les éléments supprimés, de sorte que la restauration réapplique les annotations telles qu'elles étaient au moment de l'exécution. Examinez le travail effectué depuis l'exécution, sur un commentaire qui se trouve dans la sauvegarde, est écrasé.

Le téléchargement des e-mails bruts dans un compartiment amène la plate-forme à les analyser dans les sources qui lisent à partir de ce compartiment, en recréant les commentaires. Ne restaurez pas les e-mails et les commentaires pour la même source, sauf si vous avez l’intention de le faire. Si vous restaurez les e-mails plutôt que les commentaires, attendez que les commentaires réapparaissent avant de restaurer les annotations, qui ne peuvent être appliquées qu’aux commentaires qui existent déjà.

re create comments et re create emails sont des téléchargements, de sorte que la CLI vous demande de consentir aux frais d'AI Unit pour eux. re create annotations ne se charge pas.

Limitations et mises en garde

Sauvegarde et restauration:

• Le contenu de la pièce jointe de commentaire n’est pas sauvegardé. Seules les métadonnées de la pièce jointe l’ont été, le contenu de la pièce jointe ne pouvant pas être restauré. Les e-mails sont entièrement sauvegardés, de sorte que les pièces jointes portées dans leur contenu MIME sont conservées.
• Les annotations de champ d’extraction ignorées ne sont pas restaurées. Elles sont présentes dans la sauvegarde, mais le format de téléchargement n’a aucun moyen de les appliquer à nouveau.
• Un test écrit une sauvegarde réelle. Il lit toutes les données qu'il supprimerait et les écrit dans --backup-dir, de sorte à traiter sa sortie aussi en toute sécurité que toute autre sauvegarde.

Étendue et comportement de la suppression:

• Seules les annotations dans les ensembles de données que vous avez répertoriés protègent un commentaire. Un commentaire annoté uniquement dans un ensemble de données auquel vous ne pouvez pas accéder est traité comme non annoté: il est supprimé et cette annotation n’est pas sauvegardée.
• La suppression des e-mails est effectuée dans tout le compartiment par âge. Sans --mailbox, chaque e-mail datant avant la date limite est supprimé de chaque compartiment dans l'étendue, y compris les e-mails qui alimentent d'autres sources ou ensembles de données, que ceux-ci soient ou non dans l'étendue.
• Les sources hors des jeux de données répertoriés sont hors du cadre. Leurs commentaires ne sont pas supprimés, même lorsque les e-mails de leur compartiment le sont. Il peut laisser des commentaires dont l’e-mail brut n’existe plus.
• La vérification de la source partagée ne voit que ce que vous pouvez lire. Si une source intégrée à l'étendue appartient également à un ensemble de données dans un projet auquel vous ne pouvez pas accéder, cet ensemble de données perdra les commentaires supprimés ici et l'exécution ne pourra pas vous avertir.
• La suppression n'est pas transactionnelle. S'il échoue à mi-parcours, par exemple en raison d'une erreur réseau, les données déjà supprimées resteront supprimées. La sauvegarde est intacte, vous pouvez donc réexécuter la commande ou restaurer à partir de la sauvegarde.