UiPath Documentation
ixp
latest
false
Guía del usuario de Communications Mining
Importante :
La localización de contenidos recién publicados puede tardar entre una y dos semanas en estar disponible.

Eliminar lote

Elimine datos en masa de Communications Mining utilizando la CLI, ya sea desde una sola fuente o depósito por rango de tiempo, o en conjuntos de datos completos con retención basada en la edad.

La CLI proporciona tres formas de eliminar datos de forma masiva, por ejemplo, al limpiar datos históricos o aplicar una política de retención.

ComandoÁmbitoUTILIZARLO PARA
re delete bulkUna fuenteEliminar comentarios por intervalo de tiempo
re delete bulk-emailsUn depósitoEliminar correos electrónicos sin procesar por intervalo de tiempo
re pruneCada origen y depósito en los conjuntos de datos que enumereAplicar la retención basada en la edad a un conjunto de datos completo, comentarios y correos electrónicos sin procesar juntos
ADVERTENCIA:

re delete bulk y re delete bulk-emails se eliminan tan pronto como los ejecutes. No hay solicitud de confirmación, no hay ejecución en seco ni copia de seguridad: primero haz una tú mismo. Solo re prune realiza una copia de seguridad de lo que elimina.

Esta sección asume que ya has instalado y configurado el CLI. Necesitas permisos de lectura y eliminación en cada proyecto del que elimines. La restauración desde una copia de seguridad también necesita permiso para cargar comentarios y correos electrónicos, y Conjunto de datos: revisar para restaurar anotaciones.

Para ver las opciones que toma un comando, ejecuta re <command> --help o consulta la referencia de comandos.

Nota:

Para los tres comandos, el período de tiempo se basa en el campo timestamp del comentario o correo electrónico, en lugar de la fecha y hora en que se cargó en Communications Mining™.

Para re delete bulk y re delete bulk-emails, ambos extremos del rango son opcionales: no proporciones ninguno y el comando cubre todo el origen o depósito. --from-timestamp es inclusivo; --to-timestamp es inclusivo para los comentarios y exclusivo para los correos electrónicos.

Copia de seguridad de los datos antes de eliminarlos

Antes de eliminar o modificar tus comentarios, puedes realizar una copia de seguridad de los comentarios anotados, para no perder accidentalmente el trabajo manual de los entrenadores de modelos:

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

Si el origen se añadió a varios conjuntos de datos, debes ejecutar el comando mencionado anteriormente para cada uno de esos conjuntos de datos.

Ese comando captura los comentarios que --include-annotated=false mantiene, no los que elimina una eliminación. Para capturarlos, exporta el mismo rango que estás a punto de eliminar: para un origen, utiliza re get comments con --from-timestamp y --to-timestamp como se describe en Descarga por lotes, y para un depósito:

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

El contenido de los archivos adjuntos solo se exporta cuando pasas --attachments true a re get comments, y solo se vuelve a cargar cuando pasas --attachments <directory> a re create comments. Sin ellos, una copia de seguridad conserva los metadatos de los archivos adjuntos, pero no los archivos en sí.

Eliminar comentarios de un origen

ADVERTENCIA:

Eliminar anotaciones cambia el rendimiento del modelo.

Si los comentarios que deseas eliminar se añadieron a uno o más conjuntos de datos en los que podrían haberse anotado, eliminar los comentarios anotados dará como resultado un cambio en el rendimiento del modelo en esos conjuntos de datos en el futuro. Los modelos publicados no se verán afectados.

Opcionalmente, puedes configurar la CLI para omitir los comentarios anotados.

El siguiente comando elimina todos los comentarios en un origen entre FROM_TIMESTAMP y TO_TIMESTAMP , excluyendo los comentarios anotados. La marca de tiempo debe estar en formato RFC 3339, por ejemplo 1970-01-02T03:04:05Z.

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

Si está seguro de que desea eliminar los comentarios anotados, puede establecer --include-annotated=true.

Nota:

Aquí, --include-annotated=false mantiene un comentario que se anota en cualquier conjunto de datos que contenga el origen, incluidos los conjuntos de datos que no puedes ver. re prune utiliza una regla más estrecha.

Eliminar comentarios no elimina los correos electrónicos sin procesar de los que se analizaron.

Eliminar correos electrónicos de un depósito

Para eliminar los correos electrónicos sin procesar, orienta el depósito por intervalo de tiempo:

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

Esto elimina todos los correos electrónicos del rango, incluidos los correos electrónicos que se analizaron en fuentes distintas de la que has estado trabajando. Los comentarios ya analizados de esos correos electrónicos no se eliminan.

Para eliminar correos electrónicos individuales, pasa hasta 32 ID a la vez:

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

Transfiera siempre al menos un ID. Ni re delete emails ni re delete comments comprueban si hay una lista vacía, y una solicitud de eliminación que no lleva identificadores corre el riesgo de eliminar mucho más de lo previsto, así que ten cuidado con los marcadores de posición no expandidos y las variables de shell vacías.

Podar datos antiguos en un conjunto de datos

re prune aplica la retención basada en la edad en uno o más conjuntos de datos en una sola ejecución, eliminando:

  • Comentarios anteriores al límite, de cada origen en los conjuntos de datos que enumere.
  • Correos electrónicos anteriores al límite, de cada depósito de los que lean esas fuentes.

El límite es el momento exacto en que comienza la ejecución, menos --older-than-days, en lugar de un límite de día natural.

ADVERTENCIA:

re prune elimina permanentemente los datos. La copia de seguridad que escribe es la única forma de deshacer una ejecución y contiene datos personales. Escribe copias de seguridad en algún lugar seguro, mantenlas a salvo y haz siempre una ejecución en seco primero.

Cómo funciona una ejecución de poda

  1. Resolver ámbito. Cada origen de los conjuntos de datos que pasas a --datasets está dentro del ámbito, junto con cada depósito del que leen esos orígenes.
  2. Comprobar fuentes compartidas. Si un origen dentro del ámbito también pertenece a un conjunto de datos que no enumeraste, la ejecución se anula y le da nombre. Solo se pueden comprobar los conjuntos de datos para los que tenga permiso de lectura.
  3. Confirmar. El comando resume el ámbito y las advertencias que se le aplican, y te espera. --dry-run y -y omitir esto.
  4. Copia de seguridad. Primero cada comentario revisado en cada conjunto de datos dentro del ámbito, luego los comentarios y correos electrónicos seleccionados para su eliminación.
  5. Verifique y luego elimine. La ejecución comprueba cada archivo de copia de seguridad con el recuento de registros y la suma de comprobación en el manifiesto, y una sola falta de coincidencia se aborta antes de que se elimine algo.

Una ejecución en seco se detiene después del paso 4: escribe una copia de seguridad real e informa de lo que eliminaría, pero no verifica ni elimina.

Ejecutar una poda

Comienza con --dry-run.

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

Cuando los recuentos sean correctos, ejecuta el mismo comando sin --dry-run.

De forma predeterminada, un comentario se mantiene, independientemente de su antigüedad, si se revisa en uno de los conjuntos de datos que has enumerado. Un comentario anotado solo en un conjunto de datos al que no puedes acceder no cuenta y se elimina. Transmite --include-annotated para eliminar los comentarios antiguos, estén o no anotados, teniendo en cuenta el efecto en el rendimiento del modelo descrito anteriormente.

Podar un único buzón

--mailbox restringe lo que se elimina a los datos sincronizados de un buzón, lo que es útil cuando un depósito recibe más de un buzón y solo uno de ellos necesita poda. La plataforma filtra los correos electrónicos en función del nombre exacto del buzón. Los comentarios coinciden, sin distinción entre mayúsculas y minúsculas, en su propiedad de usuario Mailbox ID , que el análisis de correo electrónico establece solo cuando la etiqueta de transformación de origen registra el nombre del buzón.

Nota:

Un comentario que no lleva un Mailbox ID coincidente nunca coincide, por lo que si los comentarios en el ámbito no llevan esa propiedad, una ejecución con ámbito de buzón no elimina ninguno de ellos. Comprueba la etiqueta de transformación con re get sources antes de confiar en --mailbox.

--mailbox no reduce la copia de seguridad de la anotación.

Contenido de la copia de seguridad

Cada ejecución crea una nueva carpeta en --backup-dir, llamada así por la hora UTC en la que se inició la ejecución. re prune nunca reutiliza una carpeta existente.

<backup_directory>/20260807T104500Z/
├── manifest.json
├── annotations/<dataset-id>/<source-id>.jsonl
├── deleted-comments/<source-id>.jsonl
└── deleted-emails/<bucket-id>.jsonl
<backup_directory>/20260807T104500Z/
├── manifest.json
├── annotations/<dataset-id>/<source-id>.jsonl
├── deleted-comments/<source-id>.jsonl
└── deleted-emails/<bucket-id>.jsonl
PATHContenido
manifest.jsonResumen de la ejecución y el índice de cada archivo de copia de seguridad.
annotations/Cada comentario revisado en cada conjunto de datos dentro del ámbito, con sus anotaciones, un archivo por conjunto de datos y origen, no solo los que se eliminan.
deleted-comments/Los comentarios seleccionados para su eliminación, un archivo por origen, en el mismo formato que re get comments, pero sin sus anotaciones.
deleted-emails/Los correos electrónicos seleccionados para su eliminación, un archivo por depósito, incluido su contenido MIME sin procesar.

El manifiesto registra los parámetros de la ejecución (run_id, cutoff, include_annotated, mailbox, datasets), el tamaño del conjunto de eliminación (comment_count, email_count) y, para cada archivo de copia de seguridad, el Cubre resource, su ruta file relativa a la carpeta de copia de seguridad, su registro count y una suma de comprobación crc32.

Nota:

comment_count y email_count son el tamaño del conjunto de eliminación que seleccionó la ejecución. El manifiesto se escribe antes de que se elimine algo y no se actualiza después, por lo que no son un registro de lo que se eliminó correctamente.

Restaurar desde una copia de seguridad

La restauración es manual y utiliza los comandos re create normales. Los archivos de copia de seguridad se nombran por id: re get datasets, re get sources y re get buckets enumeran los id junto con los nombres, y el manifiesto proporciona el origen o depósito que cubre cada archivo de conjunto de eliminaciones en su campo resource. El count de cada archivo en el manifiesto es cuántos registros contiene, que vale la pena comparar con lo que restauras.

Restaura los comentarios eliminados a su origen:

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

Una poda predeterminada mantiene los comentarios anotados en los conjuntos de datos que enumeraste, por lo que las anotaciones solo necesitan restaurarse después de una ejecución con --include-annotated. Restáuralos desde la copia de seguridad de las anotaciones: re create annotations lee ese archivo y carga solo las anotaciones, dejando los comentarios intactos:

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

Restaura los correos electrónicos eliminados a su depósito:

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

Una copia de seguridad de la anotación cubre todos los comentarios revisados en el conjunto de datos, no solo los eliminados, por lo que restaurar uno vuelve a aplicar las anotaciones tal como estaban en el momento de la ejecución. El trabajo de revisión realizado desde la ejecución, en un comentario que está en la copia de seguridad, se sobrescribe.

Cargar correos electrónicos sin procesar de nuevo en un depósito hace que la plataforma los analice en las fuentes que leen de ese depósito, recreando comentarios. No restaures tanto los correos electrónicos como los comentarios para el mismo origen a menos que tengas la intención de hacerlo. Si restauras los correos electrónicos en lugar de los comentarios, espera a que vuelvan a aparecer los comentarios antes de restaurar las anotaciones, que solo se pueden aplicar a los comentarios que ya existen.

re create comments y re create emails son cargas, por lo que CLI te pide que aceptes los cargos de AI Unit por ellas. re create annotations no se carga.

Limitaciones y advertencias

Copia de seguridad y restauración:

  • No se realiza una copia de seguridad del contenido del archivo adjunto del comentario. Solo se muestran los metadatos del archivo adjunto, por lo que el contenido del archivo adjunto no se puede restaurar. Los correos electrónicos se copian completos, por lo que se conservan los archivos adjuntos en su contenido MIME.
  • Las anotaciones de campo de extracción descartadas no se restauran. Están presentes en la copia de seguridad, pero el formato de carga no tiene forma de volver a aplicarlos.
  • Una ejecución en seco escribe una copia de seguridad real. Lee todos los datos que eliminaría y los escribe en --backup-dir, por lo que trata su salida de forma tan segura como cualquier otra copia de seguridad.

Ámbito de eliminación y comportamiento:

  • Solo las anotaciones en los conjuntos de datos que has enumerado protegen un comentario. Un comentario anotado solo en un conjunto de datos al que no puedes acceder se trata como no anotado: se elimina y no se hace una copia de seguridad de esa anotación.
  • La eliminación de correo electrónico es de todo el depósito por edad. Sin --mailbox, cada correo electrónico con fecha anterior al límite se elimina de cada depósito dentro del ámbito, incluidos los correos electrónicos que alimentan otras fuentes o conjuntos de datos, estén o no dentro del ámbito.
  • Las fuentes fuera de los conjuntos de datos enumerados están fuera del ámbito. Sus comentarios no se eliminan, incluso cuando se eliminan los correos electrónicos de su depósito. Esto puede dejar comentarios cuyo correo electrónico sin procesar ya no existe.
  • La comprobación de origen compartido solo ve lo que puedes leer. Si un origen dentro del ámbito también pertenece a un conjunto de datos en un proyecto al que no puedes acceder, ese conjunto de datos pierde los comentarios eliminados aquí y la ejecución no puede advertirte.
  • La eliminación no es transaccional. Si falla parcialmente, por ejemplo en un error de red, los datos ya eliminados permanecen eliminados. La copia de seguridad está intacta, así que vuelve a ejecutar el comando o restaura desde la copia de seguridad.

¿Te ha resultado útil esta página?

Conectar

¿Necesita ayuda? Soporte

¿Quiere aprender? UiPath Academy

¿Tiene alguna pregunta? Foro de UiPath

Manténgase actualizado