Exclusão em lote

Exclua dados em massa do Communications Mining usando a CLI, a partir de uma única origem ou bucket por intervalo de tempo ou em conjuntos de dados inteiros com retenção baseada na idade.

A CLI fornece três maneiras de excluir dados em massa, por exemplo ao limpar dados históricos ou aplicar uma política de retenção.

Command	Escopo	USE-O PARA
re delete bulk	Uma origem	Excluindo comentários por intervalo de tempo
re delete bulk-emails	Um bucket	Excluindo emails brutos por intervalo de tempo
re prune	Cada origem e bucket nos conjuntos de dados que você lista	Aplicação da retenção baseada em idade a um conjunto de dados, comentários e e-mails brutos juntos

AVISO:

re delete bulk e re delete bulk-emails são excluídos assim que você os executa. Não há solicitação de confirmação, nenhuma simulação e nenhum backup — faça um você mesmo primeiro. re prune faz backup apenas do que ele exclui.

Esta seção pressupõe que você já instalou e configurou a CLI. Você precisa de permissões de leitura e exclusão em todos os projetos dos quais você está excluindo. A restauração de um backup também precisa de permissão para carregar comentários e e-mails e Conjunto de dados - Revisão para restaurar anotações.

Para as opções que um comando assume, execute re <command> --help ou consulte a referência do comando.

Observação:

Para todos os três comandos, o período de tempo é baseado no campo timestamp do comentário ou e-mail, em vez da data e hora em que foi carregado no Communications Mining™.

Para re delete bulk e re delete bulk-emails, ambas as extremidades do intervalo são opcionais: não forneça nenhum e o comando cobrirá toda a origem ou o bucket. --from-timestamp é inclusivo; --to-timestamp é inclusivo para comentários e exclusivo para e-mails.

Fazendo backup dos dados antes de excluí-los

Antes de excluir ou modificar seus comentários, pode ser que você queira, opcionalmente, fazer backup dos comentários anotados para não perder acidentalmente o trabalho manual dos treinadores dos modelos:

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

Se a origem foi adicionada a vários conjuntos de dados, você deve executar o comando mencionado anteriormente para cada um desses conjuntos de dados.

Esse comando captura os comentários que --include-annotated=false mantém, não aqueles que uma exclusão remove. Para captura-los, exporte o mesmo intervalo que você está prestes a excluir: para uma origem, use re get comments com --from-timestamp e --to-timestamp conforme descrito em Download em lote e para um bucket:

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

Observação:

O conteúdo do anexo é exportado apenas quando você passa --attachments true para re get comments e só é carregado novamente quando você passa --attachments <directory> para re create comments. Sem eles, um backup contém os metadados do anexo, mas não os próprios arquivos.

Exclusão de comentários de uma origem

AVISO:

Excluir anotações altera o desempenho do modelo.

Se os comentários que você deseja excluir tiverem sido adicionados a um ou mais conjuntos de dados onde poderiam ter sido anotados, a exclusão dos comentários anotados resultará em uma alteração do desempenho do modelo nesses conjuntos de dados daqui para frente. Os modelos publicados não serão afetados.

Opcionalmente, você pode configurar a CLI para ignorar comentários anotados.

O seguinte comando exclui todos os comentários em uma origem entre FROM_TIMESTAMP e TO_TIMESTAMP , excluindo comentários anotados. O carimbo de data/hora precisa estar no formato RFC 3339, por exemplo 1970-01-02T03:04:05Z.

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

Se tiver certeza de que deseja excluir comentários anotados, você pode definir --include-annotated=true.

Observação:

Aqui, --include-annotated=false um comentário que é anotado em qualquer conjunto de dados que contém a origem, incluindo conjuntos de dados que você não pode ver. re prune usa uma regra mais restrita.

A exclusão de comentários não remove os emails brutos dos quais foram analisados.

Exclusão de emails de um bucket

Para excluir os próprios emails brutos, segmente o bucket por intervalo de tempo:

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

Isso exclui todos os emails no intervalo, incluindo emails que foram analisados em fontes diferentes daquela com a qual você está trabalhando. Os comentários já analisados desses emails não são excluídos.

Para excluir emails individuais, passe até 32 IDs de cada vez:

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

AVISO:

Sempre transmita pelo menos um id. Nem re delete emails nem re delete comments verificam uma lista vazia, e uma solicitação de exclusão que não carrega ids riscos de remover muito mais do que você pretendido — portanto, tome cuidado com espaços reservados não expandidos e variáveis de shell vazias.

Podendo dados antigos em um conjunto de dados

re prune aplica retenção baseada em idade em um ou mais conjuntos de dados em uma única execução, excluindo:

• Comentários mais antigos que o corte, de todas as origens nos conjuntos de dados que você listar.
• Emails mais antigos que o corte, de cada bucket dos quais essas origens leram.

O corte é o momento exato em que a execução começa, menos --older-than-days, em vez de um limite de dia corrido.

AVISO:

re prune exclui dados permanentemente. O backup que ele grava é a única maneira de desfazer uma execução e contém dados pessoais. Grave backups em um lugar seguro, mantenha-os seguros e sempre faça uma simulação primeiro.

Como uma execução de podar funciona

1. Resolver escopo. Cada origem nos conjuntos de dados que você passa para --datasets está no escopo, junto com cada bucket do qual essas origens leram.
2. Verifique se há origens compartilhadas. Se uma origem no escopo também pertencer a um conjunto de dados que você não listou, a execução será anulada e o nomeará. Apenas conjuntos de dados que você tem permissão para ler podem ser verificados.
3. Confirmar. O comando resume o escopo e as ressalvas que se aplicam a ele e aguarda você. --dry-run e -y ignoram essa opção.
4. Faça backup. Primeiro, cada comentário revisado em cada conjunto de dados no escopo e, em seguida, os comentários e os emails selecionados para exclusão.
5. Verifique e depois exclua. A execução verifica cada arquivo de backup na contagem de registros e soma de verificação no manifesto, e uma única incompatibilidade é anulada antes que algo seja excluído.

Uma simulação é interrompida após a etapa 4: ela grava um backup real e relata o que excluiria, mas não verifica nem exclui.

Execução de uma pod

Comece com --dry-run.

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

Quando as contagens estiverem certas, execute o mesmo comando --dry-run sem.

Por padrão, um comentário é mantido, independentemente da idade, se for revisado em um dos conjuntos de dados que você listou. Um comentário anotado apenas em um conjunto de dados que você não pode acessar não conta e é excluído. Transmita --include-annotated para excluir comentários antigos, estejam eles anotados ou não, tendo em mente o efeito no desempenho do modelo descrito acima.

Podendo uma única caixa de correio

--mailbox o que é excluído dos dados sincronizados de uma caixa de correio, o que é útil quando um bucket recebe mais de uma caixa de correio e apenas uma delas precisa de podação. A plataforma filtra emails no nome exato da caixa de correio. Os comentários são correspondidos, sem diferenciação entre maiúsculas e minúsculas, em sua propriedade Mailbox ID do usuário, que a análise de e-mail define apenas quando a tag de transformação da origem registra o nome da caixa de correio.

Observação:

Um comentário que não carrega um Mailbox ID correspondente nunca é correspondido, portanto, se os comentários no escopo não carregarem essa propriedade, uma execução com escopo de caixa de correio não excluirá nenhum deles. Verifique a tag de transformação com re get sources antes de confiar em --mailbox.

--mailbox não restringe o backup da anotação.

O que o backup contém

Cada execução cria uma nova pasta em --backup-dir, nomeada após o horário UTC em que a execução começou. re prune nunca reutiliza uma pasta existente.

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

PATH	Conteúdo
manifest.json	Resumo da execução e o índice de cada arquivo de backup.
annotations/	Cada comentário revisado em cada conjunto de dados no escopo, com suas anotações, um arquivo por conjunto de dados e origem — não apenas os que estão sendo excluídos.
deleted-comments/	Os comentários selecionados para exclusão, um arquivo por origem, no mesmo formato re get comments que, mas sem suas anotações.
deleted-emails/	Os emails selecionados para exclusão, um arquivo por bucket, incluindo seu conteúdo MIME bruto.

O manifesto registra os parâmetros da execução (run_id, cutoff, include_annotated, mailbox, datasets), o tamanho do conjunto de exclusão (comment_count, email_count) e para cada arquivo de backup, o resource abrange, seu caminho file relativo à pasta de backup, seu registro count e uma soma de verificação crc32.

Observação:

comment_count e email_count são o tamanho do conjunto de exclusão que a execução selecionada. O manifesto é escrito antes que qualquer coisa seja excluído e não é atualizado posteriormente, portanto, ele não é um registro do que foi excluído com sucesso.

Restaurando a partir de um backup

A restauração é manual e usa os comandos re create comuns. Os arquivos de backup são nomeados por id: re get datasets, re get sources e re get buckets listam os ids ao lado dos nomes, e o manifesto fornece a origem ou o bucket que cada arquivo definido para exclusão abrange em seu campo resource. O count de cada arquivo no manifesto é quantos registros ele contém, que deve ser comparado com o que você restaurar.

Restaure os comentários excluídos na sua origem:

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

Uma podar padrão mantém os comentários anotados nos conjuntos de dados que você listou, então as anotações só precisam ser restauradas após uma execução com --include-annotated. Restaure-as a partir do backup da anotação — re create annotations lê esse arquivo e carrega apenas as anotações, deixando os próprios comentários inalterados:

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

Restaure os emails excluídos no bucket:

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

AVISO:

Um backup de anotação cobre todos os comentários revisados no conjunto de dados, não apenas os excluídos; portanto, ao restaurar, você reaplica as anotações como estavam no momento da execução. O trabalho de revisão feito desde a execução, em um comentário que está no backup, foi substituído.

Carregar emails brutos de volta para um bucket faz com que a plataforma os analise nas origens que lidam desse bucket, recriando comentários. Não restaure os emails e os comentários para a mesma origem, a menos que você pretenda. Se você restaurar os e-mails em vez dos comentários, aguarde os comentários reaparecerem antes de restaurar as anotações, que só podem ser aplicadas a comentários que já existem.

re create comments e re create emails são uploads, então a CLI pede seu consentimento com as cobranças da AI Unit para eles. re create annotations não é cobrado.

Limitações e ressalvas

Backup e restauração:

• Não é feito backup do conteúdo do anexo do comentário. Apenas os metadados do anexo são, portanto, o conteúdo do anexo não pode ser restaurado. É feito backup inteiro dos e-mails, então os anexos carregados em seu conteúdo MIME são preservados.
• As anotações de campos de extração descartados não são restauradas. Eles estão presentes no backup, mas o formato de carregamento não tem como reaplicá-los.
• Uma simulação grava um backup real. Ele lê todos os dados que excluiria e os grava em --backup-dir; portanto, trate sua saída com a mesma segurança de qualquer outro backup.

Escopo e comportamento da exclusão:

• Apenas anotações em conjuntos de dados que você listou protegem um comentário. Um comentário anotado apenas em um conjunto de dados que você não pode acessar é tratado como não anotado: ele é excluído e essa anotação não é copiada.
• A exclusão de e-mails é do bucket inteiro por idade. Sem --mailbox, todos os emails datados antes do corte são excluídos de cada bucket no escopo, incluindo emails que alimentam outras fontes ou conjuntos de dados, estejam eles ou não no escopo.
• As origens fora dos conjuntos de dados listados estão fora do escopo. Seus comentários não são excluídos, mesmo quando os e-mails em seu bucket são. Isso pode deixar comentários cujo email bruto não existe mais.
• A verificação de origem compartilhada só vê o que você pode ler. Se uma origem no escopo também pertencer a um conjunto de dados em um projeto que você não puder acessar, esse conjunto de dados perderá os comentários excluídos aqui, e a execução não poderá avisar você.
• A exclusão não é transacional. Se falhar parcialmente, por exemplo, em um erro de rede, os dados já excluídos permanecerão excluídos. O backup está intacto; então, execute novamente o comando ou restaure a partir do backup.