Es posible que parte de la información de esta página (o toda) no se aplique a Cloud de Confiance de S3NS. Consulta Diferencias con Google Cloud para obtener más información.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Descripción general del registro de conversaciones

El registro de conversaciones de Conversational Analytics te permite registrar las conversaciones de un agente de datos en una tabla de BigQuery de tu proyecto para que puedas revisar la calidad de las respuestas, hacer un seguimiento de la adopción y supervisar los costos en tus agentes de Conversational Analytics. En cada turno, el registro captura la pregunta del usuario, la respuesta del agente, la latencia, el uso de tokens del modelo y los identificadores que necesitas para agrupar los turnos por agente, conversación y usuario. Las filas se escriben con el esquema de análisis de agentes de BigQuery a través de la API de BigQuery Storage Write (gRPC).

Qué se registra

Cada turno registrado escribe varias filas de eventos (events) en la tabla de destino que registran la siguiente información:

La pregunta del usuario.
La respuesta del agente: el texto, las estadísticas, las suposiciones, las preguntas de seguimiento sugeridas, las fuentes de citas y los nombres de los resultados o gráficos de datos.
Latencia por turno.
El uso de tokens del modelo, la versión del modelo y el motivo de finalización (por qué el modelo dejó de generar tokens) para cada llamada al modelo.
El ID del agente de datos y el ID de la conversación, para que puedas analizar varios agentes en una tabla.
Es un identificador de usuario. Para obtener más información sobre los identificadores de usuario, consulta Identidad del usuario.
Detalles del estado y del error.

¿Qué no se registra?

El registro de conversaciones no registra lo siguiente:

Las consultas en SQL que ejecuta el agente: El registro contiene la respuesta final y los nombres de los resultados de los datos y los gráficos a los que se hace referencia, pero no las consultas que los produjeron. La excepción es cuando un usuario le pide explícitamente al agente que muestre o explique SQL. En ese caso, el SQL puede aparecer en el texto de la respuesta.
Llamadas a herramientas del agente: Cada llamada al modelo escribe una fila LLM_RESPONSE, incluidas las llamadas en las que el modelo decide ejecutar una herramienta. Antes de que se escriba la fila, se quita el resultado del modelo, incluidos el nombre y los argumentos de cualquier herramienta a la que haya llamado. Solo se conservan el uso de tokens, la versión del modelo y el motivo de finalización.
Comentarios de los usuarios: No se registran los comentarios de Me gusta o No me gusta.

Algunas conversaciones no se registran en absoluto, como las conversaciones en el panel de vista previa de BigQuery Studio. Para obtener más información sobre las plataformas de conversación no compatibles, consulta Limitaciones.

Cómo funciona el registro de conversaciones

Cuando un usuario chatea con un agente de datos que tiene habilitado el registro de conversaciones, las estadísticas conversacionales procesan cada turno a través de las siguientes etapas:

Configuración: El propietario de un agente habilita el registro de conversaciones y selecciona un conjunto de datos de destino y un nombre de tabla existentes en el proyecto del agente en BigQuery Studio.
Pregunta: Un usuario envía una pregunta al agente. En BigQuery Studio, los usuarios ven un aviso de que se registran sus conversaciones.
Verificación de privacidad: Antes de que el agente comience a trabajar en el turno, una verificación de privacidad lee los metadatos de las tablas de fuentes de conocimiento del agente con las credenciales del usuario que chatea. Esta verificación confirma que ninguna de las tablas usa seguridad a nivel de fila (políticas de acceso a filas), seguridad a nivel de columna (etiquetas de política) ni enmascaramiento de datos dinámico. Si la verificación encuentra una política o no puede confirmar que no haya ninguna, el turno no se registra y el agente sigue respondiendo la pregunta del usuario.
Respuesta: El agente responde al usuario como de costumbre.
Escritura: El agente de servicio de la API de Conversational Analytics del proyecto (service-PROJECT_NUMBER@gcp-sa-geminidataanalytics.s3ns-system.iam.gserviceaccount.com) escribe las filas de registro en la tabla de destino a través de la API de Storage Write (gRPC). En el primer turno registrado, el agente de servicio crea la tabla si aún no existe.
Consulta: Las filas suelen aparecer unos segundos después de que se completa la respuesta. No se garantiza el tiempo de entrega.

Los errores de registro nunca fallan en un turno, y la verificación de privacidad y la escritura de registros pueden agregar latencia. La falta de un permiso en el conjunto de datos de registro, un conjunto de datos que no existe o una cuota agotada no hace que falle la solicitud de chat. Las estadísticas de conversación no informan fallas de registro en la interfaz de chat ni en Cloud Logging.

Privacidad, administración de datos y seguridad

Cuando habilitas el registro de conversaciones para un agente, revisa cómo se aplican a tus registros los avisos para el usuario final, el acceso a los datos, la encriptación y los controles de red.

Avisos para usuarios finales y contenido registrado

Los siguientes avisos y reglas rigen lo que registra el registro de conversaciones y quién puede ver los datos registrados:

Aviso para el usuario final en BigQuery Studio: Cuando se activa el registro de conversaciones para un agente, los usuarios que chatean con el agente en BigQuery Studio ven el siguiente aviso cada vez que se habilita el registro de conversaciones, incluso en la pantalla de conversación nueva antes de que el usuario envíe una primera instrucción:

Todas las instrucciones y respuestas se registran en BigQuery, y todos los usuarios con permisos del conjunto de datos pueden acceder a ellas.
Tus responsabilidades cuando usas la API: Si habilitas el registro de conversaciones (registro de seguimiento) en un agente de datos y lo pones a disposición de los usuarios finales a través de tu propia aplicación o integración, Google no puede mostrar un aviso a esos usuarios. Eres responsable de los avisos, las divulgaciones o los consentimientos que se apliquen a las conversaciones registradas según la ley aplicable y tus acuerdos con los usuarios finales. Para obtener más información, consulta Seguridad, privacidad, riesgo y cumplimiento de la API de Conversational Analytics.
Qué contiene el registro y quién puede verlo: La tabla de destino almacena el contenido de preguntas y respuestas según estas reglas de privacidad:
- Preguntas y respuestas completas: Las respuestas pueden incluir valores que se devuelven de tus fuentes de conocimiento. Cualquier persona que pueda leer la tabla de registro puede ver los datos que el agente devolvió a un usuario, incluidos los datos que no puede leer en las tablas de origen. Otorga acceso de lectura al conjunto de datos de registro solo a las personas que deben ver este contenido.
- Identificadores de usuario y ubicación de escritura: La columna user_id identifica al emisor que hizo la pregunta (consulta Identidad del usuario), y las filas se escriben solo en el destino que configuras en el proyecto del agente.
- Tablas con seguridad a nivel de fila, seguridad a nivel de columna o enmascaramiento de datos: Si las fuentes de conocimiento de un agente usan seguridad a nivel de fila (políticas de acceso a filas), seguridad a nivel de columna (etiquetas de política) o enmascaramiento de datos dinámico, no se registran sus turnos. La verificación de privacidad omite las tablas en bigquery-public-data y solo analiza las tablas y vistas que seleccionas como fuentes de conocimiento, no las tablas detrás de una vista:
  - Una vista sobre una tabla que usa estas políticas puede pasar la verificación, por lo que se pueden registrar sus turnos. Antes de activar el registro, asegúrate de que las tablas detrás de las vistas no usen políticas de acceso de fila, etiquetas de política ni enmascaramiento de datos.
  - Si agregas una de estas políticas a una tabla de origen más adelante, las filas que ya se registraron permanecerán en la tabla de registro. Si tu política de retención o administración prohíbe conservar esas filas, bórralas.

Control de acceso, encriptación y seguridad de redes

Puedes administrar la retención, el acceso, la encriptación y la seguridad perimetral de tus registros de conversaciones con los siguientes parámetros de configuración:

Control de acceso y retención en el conjunto de datos de registro: Configura la retención, los roles del conjunto de datos, las políticas de tablas y los registros de auditoría para la tabla de destino:
- Retención: Google no borra las filas de registros. Establece un vencimiento de partición en el conjunto de datos o la tabla de registros que coincida con tu política (por ejemplo, 90 días).
- Privilegio mínimo: Mantén el conjunto de datos de registro separado de tus otros conjuntos de datos para que el acceso de escritura del agente de servicio de la API de Conversational Analytics compartido se mantenga alejado de tus otras tablas. Otorga a los analistas roles/bigquery.dataViewer en el conjunto de datos de registro o dales acceso solo a las vistas autorizadas o a los conjuntos de datos autorizados.
- Controles a nivel de columna y de fila en la tabla de registros: Puedes aplicar etiquetas de política, enmascaramiento de datos o políticas de acceso a filas a la tabla de registros en sí, como en content o user_id. Estos controles de la tabla de registros no afectan la verificación de privacidad de la fuente de conocimiento.
- Registro de auditoría: Los cambios en un agente de datos se registran en los registros de auditoría de actividad del administrador. En los registros de auditoría de BigQuery, la creación de tablas y las actualizaciones de metadatos por parte del agente de servicio se registran en bigquery.googleapis.com, y las adiciones de filas a través de la API de Storage Write (gRPC) se registran en bigquerystorage.googleapis.com.
CMEK, Controles del servicio de VPC y residencia de los datos: Los siguientes controles de encriptación, perímetro y ubicación se aplican al registro de conversaciones:
- CMEK: Si el conjunto de datos de registro usa claves de Cloud KMS administradas por el cliente (CMEK), otorga a la cuenta de servicio de encriptación de BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.s3ns-system.iam.gserviceaccount.com) el rol roles/cloudkms.cryptoKeyEncrypterDecrypter en la clave. La CMEK en un agente de datos encripta el recurso del agente, no la tabla de registros (consulta Claves de encriptación administradas por el cliente).
- Controles del servicio de VPC: Si usas un perímetro de servicio, incluye geminidataanalytics.googleapis.com y bigquery.googleapis.com en el perímetro que contiene el proyecto del agente. El agente de servicio escribe en la tabla de registros desde la infraestructura administrada por Google, por lo que, si el perímetro restringe bigquery.googleapis.com, agrega una regla de entrada como la siguiente. Reemplaza PROJECT_NUMBER por el número de proyecto del agente:
```
- ingressFrom:
    identities:
    - serviceAccount:service-PROJECT_NUMBER@gcp-sa-geminidataanalytics.s3ns-system.iam.gserviceaccount.com
    sources:
    - accessLevel: "*"
  ingressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - permission: bigquery.tables.get
      - permission: bigquery.tables.create
      - permission: bigquery.tables.update
      - permission: bigquery.tables.updateData
    resources:
    - projects/PROJECT_NUMBER
```
  Para obtener más información, consulta Configura la seguridad del perímetro con los Controles del servicio de VPC.
- Residencia de datos: Las filas de registro y la tabla creada automáticamente se almacenan en la ubicación del conjunto de datos de registro, donde se aplican las políticas de la organización de ubicación de recursos (gcp.resourceLocations).

Limitaciones

El registro de conversaciones tiene las siguientes limitaciones:

El panel Vista previa del editor de agentes de BigQuery Studio no se registra.
No se registran las conversaciones directas sin un agente de datos.
No se registran los agentes que usan un permiso de búsqueda en lugar de tablas específicas o que no declaran ninguna tabla de BigQuery. No se registran los agentes que configuran grafos de propiedades de BigQuery como fuentes de conocimiento.
No se registran el SQL generado, las llamadas a herramientas ni los eventos de herramientas o solicitudes del Kit de desarrollo de agentes (ADK) (TOOL_STARTING, TOOL_COMPLETED, TOOL_ERROR y LLM_REQUEST). Solo se registran la respuesta y los nombres de sus resultados de datos y gráficos. Los turnos que se responden directamente desde una consulta verificada no escriben filas de LLM_RESPONSE, y los turnos de consultas verificadas que fallaron no se registran.
No se registran los comentarios de los usuarios que indican Me gusta o No me gusta.
Los turnos no se registran si las fuentes de conocimiento usan políticas de acceso a filas, seguridad a nivel de columna (etiquetas de política) o enmascaramiento de datos, o si la verificación de privacidad no se puede completar. La verificación no analiza las vistas de las tablas que están detrás de ellas.
Solo se admiten los agentes de tablas de BigQuery. No se admiten las fuentes de datos de Looker, Data Studio, AlloyDB, Spanner ni Cloud SQL.
El conjunto de datos de destino ya debe existir en el mismo proyecto que el agente.
Los cambios de esquema en las tablas existentes solo son aditivos; un tipo o modo de columna en conflicto detiene las escrituras en esa tabla.
Cada turno apto se registra sin un parámetro de configuración de muestreo; en su lugar, se realiza un muestreo en el momento de la consulta (consulta Muestra preguntas y respuestas en todos los agentes para su revisión).
La columna agent contiene el tipo de agente en lugar del nombre visible del agente. Usa el ID del agente de datos en attributes.
Los llamadores de la API que usan una cuenta de servicio para muchos usuarios finales ven el correo electrónico de esa cuenta de servicio en cada fila.
Los valores de texto de más de 512,000 caracteres (500 * 1,024) se cortan con el sufijo ...[TRUNCATED], y la parte quitada no se puede recuperar.
Las escrituras se realizan de la mejor manera posible con reintentos limitados. Los turnos que no se escriben no se registran, y los reintentos pueden producir filas duplicadas de forma ocasional (usa event_id para anular la duplicación).
Un agente no hereda el parámetro de configuración de observabilidad a nivel del proyecto.

Precios

Conversational Analytics no cobra por separado el registro de conversaciones. Tu proyecto paga los precios estándar de BigQuery por la transferencia de datos de la API de BigQuery Storage Write (gRPC), el almacenamiento y las consultas de análisis. La transferencia de la API de BigQuery Storage Write (gRPC) incluye 2 TiB de uso gratuito por mes para cada cuenta de facturación, compartido entre el uso de la API de Storage Write (gRPC). Filtra las consultas en timestamp para reducir los bytes analizados. La verificación de privacidad previa a la ejecución lee los metadatos de la tabla y ejecuta consultas de prueba sin cargo.