Planteamiento y contexto
Un equipo tiene un dataset de clasificación creado a partir de registros de comportamiento online y etiquetas humanas. Varios modelos, evaluaciones offline y proyectos de analítica lo reutilizarán, pero los usuarios no saben cómo se recopilaron las muestras, quién produjo las etiquetas, qué grupos están representados, cómo se trataron los valores faltantes o si se permite un nuevo uso comercial. Diseña una Data Card y explica cómo se mantiene auditable.
Esto encaja en entrevistas de ingeniería de datos, ciencia de datos, ingeniería de machine learning y gobernanza de datos. La prueba consiste en determinar si puedes transformar la documentación de un dataset en evidencia para tomar decisiones, en lugar de solo listar columnas o generar una página de estadísticas atractiva. Cubre procedencia y propiedad, uso previsto y prohibido, calidad y representatividad, privacidad y licencias, riesgos conocidos, versionado y mantenimiento.
Qué evalúa el entrevistador
Una respuesta sólida parte de la decisión que el lector necesita tomar y organiza la tarjeta en torno a la evidencia. Separa hechos, inferencias y aspectos desconocidos; reporta el tamaño de la muestra, el rango temporal, las condiciones de recopilación, el protocolo de etiquetado, las correcciones de datos faltantes y los segmentos clave. Nombra a la persona que aprueba el lanzamiento, registra las versiones, gestiona nuevos usos y hallazgos graves, y actualiza la tarjeta a partir de comprobaciones de reproducibilidad y comentarios de los usuarios.
Preguntas para aclarar primero
- ¿Cuál es la unidad de datos: un evento, un usuario, una sesión o una anotación?
- ¿El dataset es para entrenamiento, evaluación, recuperación, generación de informes o una decisión de seguridad?
- ¿Qué periodos de tiempo, regiones, dispositivos y canales produjeron las muestras, y cuál es la población objetivo?
- ¿Cuáles son las definiciones de las etiquetas, las cualificaciones de los anotadores, el proceso ante desacuerdos y las reglas de auditoría?
- ¿Contiene datos personales, atributos sensibles, licencias de terceros o restricciones de propósito? ¿Quién lo aprueba y lo mantiene?
Respuesta en 30 segundos
“Primero expondría el propósito del dataset, la audiencia y los usos prohibidos; luego registraría la procedencia, la ventana de recopilación, el recuento y la unidad de muestra, el proceso de etiquetado, la versión y el propietario. Validaría la representatividad, completitud, consistencia, calidad de las etiquetas, privacidad y licencias, reportando los resultados por segmentos clave de personas y tiempo. La tarjeta listaría aspectos desconocidos, sesgos conocidos y límites de uso. Un propietario aprueba cada lanzamiento, y las instantáneas versionadas, las comprobaciones de reproducibilidad y los comentarios de uso la mantienen actualizada. Si un nuevo uso excede la evidencia, pausaría la aprobación y ejecutaría validaciones adicionales.”
Respuesta paso a paso
Paso 1: Definir usos y límites de decisión
Transforma el «este dataset es bueno» en preguntas con respuesta: quién lo usará, para qué y qué ocurre si falla. Lista los usos aprobados, los usos que requieren evidencia adicional y los usos prohibidos. Un dataset para clasificación de intenciones de clientes no queda autorizado automáticamente para la selección de personal; una etiqueta de comparación offline puede no respaldar decisiones de fraude en tiempo real.
Paso 2: Registrar procedencia, unidad y generación
La tarjeta debe identificar los sistemas de origen, las fechas de recopilación, las versiones y regiones cubiertas, la unidad de observación y los pasos de filtrado, desduplicación, anonimización y derivación. Por cada corrección, registra el motivo, quién la realizó, cuándo y qué se vio afectado. La guía de calidad de datos de Google señala que los instrumentos, los flujos de trabajo humanos y el redondeo pueden crear una brecha entre los datos y la realidad; el archivo final por sí solo no es evidencia.
Paso 3: Estructurar la evidencia de calidad por capas
Reporta recuentos, valores faltantes, duplicados, comprobaciones de tipos y unidades, concordancia entre etiquetas, gestión de valores atípicos, comprobaciones de filtraciones (leakage) y resultados de reejecución. Asocia una ventana temporal, un denominador y un umbral a cada métrica; declarar «cero valores faltantes» debe especificar qué campos se excluyeron. Conserva ejemplos revisados y evidencia de adjudicación para que otra persona pueda reproducir la afirmación.
Paso 4: Evaluar la representatividad y las diferencias por segmentos
Define la población objetivo y luego segmenta por región, idioma, dispositivo, tiempo, etapa del ciclo de vida u otra dimensión que pueda alterar el rendimiento. Reporta el tamaño del segmento, la distribución de etiquetas y las métricas de calidad clave, indicando la incertidumbre en muestras pequeñas. Una alta precisión general no puede ocultar un grupo crítico con poca evidencia, y una diferencia observada no es automáticamente causal.
Paso 5: Describir etiquetas y decisiones humanas
Especifica definiciones operativas, ejemplos positivos y negativos, casos límite, perfil de los anotadores, capacitación, doble revisión, adjudicación y tasas de auditoría. Si las etiquetas provienen del comportamiento del usuario, llámalas resultados proxy en lugar de verdad fundamental (ground truth). Versiona las etiquetas y registra los cambios semánticos para que el entrenamiento no mezcle significados incompatibles.
Paso 6: Declarar privacidad, licencias y acceso
Lista los campos personales y sensibles, los métodos de anonimización, los riesgos de reidentificación, la retención, las fuentes de licencias, el alcance de divulgación y las aprobaciones. La anonimización no hace que cualquier uso sea permisible; las combinaciones de campos aún pueden exponer a ciertos grupos. Vincula la tarjeta a los procedimientos de acceso y eliminación, y advierte sobre licencias no verificadas o vacíos de procedencia.
Paso 7: Vincular versiones, propietarios y material de reproducción
Asocia cada lanzamiento a una instantánea de datos, una revisión de código, una configuración de procesamiento, versiones de dependencias, un resumen estadístico y un checksum. Nombra a un propietario de negocio, un responsable técnico y un contacto de riesgos, con la fecha de la última revisión y los desencadenantes de una nueva revisión. Un nuevo uso requiere una nueva comparación de población, segmentos, licencias y riesgos conocidos; duplicar la tarjeta antigua resulta insuficiente.
Paso 8: Revisar la tarjeta con cinco tipos de preguntas
Revisa la rendición de cuentas, la utilidad, la calidad, el impacto y los riesgos. La guía de Data Cards de Google subraya que una tarjeta debe ayudar a los lectores a decidir si el dataset se ajusta a su tarea, qué consecuencias pueden derivarse y qué restricciones son necesarias. Los revisores deben remitirse a la evidencia, las incógnitas y los propietarios para el seguimiento en lugar de asignar una única puntuación no explicada.
Compensaciones y límites
Un mayor nivel de detalle facilita la reutilización responsable, pero incrementa el costo de mantenimiento. Haría obligatorios la procedencia, el uso, la calidad y el riesgo en todos los proyectos, dejando los análisis puntuales en un apéndice. Las estadísticas resumidas no sustituyen la revisión de ejemplos sin procesar; las métricas generales no reemplazan a los segmentos críticos; las comprobaciones automatizadas no suplen la revisión humana del significado de las etiquetas y sus consecuencias de negocio.
Cuando falte evidencia, escribe «desconocido» y adjunta un plan para obtenerla. Restringe el uso a la exploración o pospón la aprobación en lugar de utilizar una cifra de precisión no validada para justificar una decisión de alto riesgo.
Plan de despliegue y evidencia
Comienza con un dataset cuyo conjunto de consumidores y cuyo impacto sean limitados. En la primera semana, registra el propósito, la procedencia, la unidad de observación y los propietarios. En la segunda semana, ejecuta comprobaciones de calidad y de segmentos. En la tercera semana, haz que representantes de ciencia de datos, privacidad y negocio revisen la tarjeta, luego reejecuta las estadísticas a partir de una instantánea anclada y publica una versión. El registro piloto debe incluir hallazgos, correcciones, incógnitas pendientes y la fecha de la próxima revisión.
Tras el lanzamiento, recopila malentendidos de los usuarios, defectos en los datos, solicitudes de nuevos usos y discrepancias en el rendimiento de los modelos. Si los problemas se detectan primero aguas abajo, a la tarjeta le falta evidencia o visibilidad. Si nadie puede explicar un campo o una limitación, la propiedad y la terminología siguen sin estar claras.
Errores comunes y preguntas de seguimiento
Un diccionario de columnas sin límites de uso
Los nombres y los tipos no indican cómo se produjeron las muestras, qué significan las etiquetas o qué usos podrían causar daños. Añade la población objetivo, los usos aprobados y prohibidos, y el nivel de evidencia.
Ocultar brechas de segmentos tras un promedio general
Los grupos grandes pueden dominar las métricas agregadas. Reporta los tamaños de los segmentos críticos, las distribuciones, la incertidumbre y dónde la evidencia es insuficiente.
Tratar el resultado de la limpieza como la realidad
Eliminar valores atípicos, imputar valores faltantes y normalizar unidades modifica el dataset. Registra las reglas, el impacto y los problemas no resueltos; no consideres el valor procesado como verdad fundamental por defecto.
Duplicar la tarjeta antigua para un nuevo uso
Cambiar de propósito altera los riesgos, la población objetivo y la evidencia requerida. Reevalúa licencias, representatividad, idoneidad de las etiquetas y consecuencias, y registra la aprobación o el rechazo del propietario.
¿Cómo demuestras que la Data Card es útil?
Comprueba si los usuarios detectan limitaciones antes de modelar y toman decisiones más seguras. Compara dónde se detectan los problemas por primera vez, el éxito de reproducibilidad, el retrabajo en aprobaciones y los incidentes de uso indebido de alto riesgo. Interpreta los cambios considerando la versión del dataset, el volumen de uso y el esfuerzo de revisión; una simple reducción de incidentes no demuestra causalidad.