Capítulo 01: Datos, datasets y linaje: la primera decisión de IA

Qué deberías poder hacer al terminar

Este facsímil cambia el foco. Hasta ahora hemos hablado de modelos, APIs, agentes, operación, evaluación, calibración e interpretabilidad. Pero todos esos sistemas tienen una pieza anterior que condiciona casi todo: qué datos entran, de dónde vienen, para qué pueden usarse y cómo sabemos que no nos estamos engañando.

La frase central del capítulo es esta:

Un dataset no es una carpeta con filas. Es una decisión técnica congelada.

Al terminar deberías poder hacer esto:

Resultado de aprendizaje	Evidencia de que lo sabes hacer
Distinguir dato, ejemplo, dataset y artefacto derivado.	No llamas “datos” a cualquier texto metido en un prompt.
Diseñar un contrato de datos mínimo.	Defines columnas, splits, licencias, sensibilidad, owner y checks.
Explicar linaje.	Puedes responder qué fuente produjo cada fila y qué hash identifica el snapshot.
Detectar leakage básico.	Sabes buscar duplicados o equivalencias entre train, validation y test.
Separar uso de entrenamiento, evaluación y consulta.	No usas el mismo dato para todo si su licencia o finalidad no lo permite.
Conectar datos con RAG, fine-tuning y evals.	Ves que documentos, chunks, embeddings, labels y trazas son artefactos de datos.
Ejecutar un gate de datos.	Generas un reporte, una dataset card y una decisión técnica reproducible.

La ciencia de datos en IA no empieza entrenando. Empieza preguntando: ¿puedo usar este dato para esta decisión?

La escena: el modelo falla, pero el bug estaba en el dataset

Imagina un asistente académico que responde dudas sobre matrícula, becas, pagos y horarios. El equipo detecta errores en producción y lo primero que se propone es cambiar de modelo. Parece razonable: si la respuesta falla, el modelo será peor de lo esperado.

Pero al mirar los datos aparecen cosas menos vistosas:

Hallazgo	Consecuencia
Varias respuestas de evaluación también estaban en entrenamiento.	La métrica era demasiado optimista.
Algunos documentos del corpus estaban obsoletos.	El RAG citaba bien, pero citaba una fuente vieja.
Una licencia permitía consulta interna, no entrenamiento.	El fine-tuning propuesto no era aceptable.
El campo producto cambió de nombre en producción.	El modelo recibía una feature rota.
Las etiquetas se pusieron con criterios distintos según el equipo.	La métrica mezclaba desacuerdos humanos con errores del modelo.

En ese punto, cambiar de modelo es secundario. El sistema no necesita más brillo; necesita DataOps.

Qué no es un dataset

Un dataset no es “unos CSV que encontré”, una carpeta de PDFs, una tabla de tickets o un export rápido de una herramienta interna. Eso puede ser una fuente de datos, pero todavía no es un dataset listo para ingeniería de IA.

Tampoco es un objeto neutral. La forma de recogerlo, filtrar filas, etiquetar casos, borrar columnas, crear splits y elegir qué queda fuera define qué aprenderá o evaluará el sistema.

Y no es intercambiable entre usos. Un dato puede servir para consultar en RAG, pero no para entrenar. Puede servir para evaluación interna, pero no para publicar resultados. Puede servir con metadatos, pero no si se separa de su fuente.

Confusión	Lectura de ingeniería
“Tengo datos, ya puedo entrenar”.	Primero contrato, linaje, licencia, sensibilidad y splits.
“Es texto público, puedo usarlo para todo”.	Hay que revisar licencia, finalidad, atribución y restricciones.
“Los embeddings no son texto”.	Son datos derivados y deben protegerse como parte del corpus.
“La eval salió alta”.	Si hay leakage, duplicados o etiquetas débiles, la métrica no vale lo que parece.
“Lo arreglamos limpiando después”.	La limpieza sin contrato crea versiones imposibles de reproducir.

Datasheets for Datasets propuso documentar motivación, composición, recogida, preprocesamiento, usos y distribución de datasets para mejorar transparencia y responsabilidad técnica.¹ Data Cards sigue esa línea con fichas de dataset orientadas a decisiones de uso y documentación práctica.²

Qué sí es un dataset para IA

En este libro llamaremos dataset a un conjunto de ejemplos con datos, metadatos, finalidad, propietario, versión, permisos, splits y checks verificables.

Ejemplo de fórmula: podemos escribirlo así para recordar qué piezas mínimas debe traer un dataset profesional. No es una definición universal de la literatura; es una notación de trabajo para este facsímil.

$$D = (X, Y, M, S, L, V, Q)$$

Símbolo	Significado	Ejemplo
$D$	Dataset.	Casos de soporte académico.
$X$	Entradas o features.	Texto del ticket, producto, canal, idioma.
$Y$	Etiquetas o salidas esperadas.	answer, ask_more, escalate.
$M$	Metadatos.	Fuente, fecha, owner, licencia, sensibilidad.
$S$	Splits.	train, validation, test.
$L$	Linaje.	Hash del snapshot, documento origen, transformación.
$V$	Versión.	support-cases@2026-06-06.
$Q$	Checks de calidad.	Schema, duplicados, missing, licencias, leakage.

Ejemplo de fórmula: cada fila también debería poder leerse como un objeto trazable. De nuevo, no pretende imponer un estándar único; sirve para que el alumno no olvide etiqueta, metadatos, split y linaje cuando mira una fila.

$$e_i = (x_i, y_i, m_i, s_i, l_i)$$

Símbolo	Significado
$e_i$	Ejemplo individual.
$x_i$	Entrada del ejemplo.
$y_i$	Etiqueta, referencia o salida esperada.
$m_i$	Metadatos del ejemplo.
$s_i$	Split asignado.
$l_i$	Linaje del ejemplo.

La diferencia con “un CSV” es brutal: ahora el dataset tiene contrato. Puedes auditarlo, versionarlo, discutirlo y bloquear su uso si no cumple.

Cómo se estructura un dataset

Un dataset se estructura según la tarea. Esta frase parece obvia, pero evita muchos errores. No tiene la misma forma un dataset para clasificar tickets, un corpus RAG, un conjunto de preferencias, una tabla de features o una traza de agente.

La pregunta que conviene hacerse primero no es “qué formato uso”, sino cuál es la unidad de decisión. En clasificación puede ser una fila. En RAG puede ser un chunk con su documento origen. En preferencias puede ser una comparación entre dos respuestas. En agentes puede ser una trayectoria completa. Si no defines esa unidad, acabas mezclando cosas que parecen datos parecidos, pero que responden a decisiones distintas.

También hay una pregunta de tiempo: ¿este dato describe algo que ya estaba disponible cuando el sistema debía decidir, o se calculó después? Esta distinción marca la frontera entre un dataset honesto y un dataset que da ventaja irreal al modelo. En ingeniería de IA, el tiempo del dato importa tanto como el valor del dato.

Dataset tabular

Un dataset tabular suele tener una fila por ejemplo y columnas para entrada, etiqueta y metadatos:

case_id | split | product   | label
d001    | train | matricula | answer

Columna	Por qué importa
case_id	Permite rastrear una fila concreta.
split	Evita mezclar entrenamiento y evaluación.
source_id	Conecta el ejemplo con su fuente original.
label	Define lo que aprende o mide el sistema.
license	Decide si puede entrenarse, evaluarse o solo consultarse.
pii_risk	Define controles de tratamiento y revisión.

Este formato sirve para clasificación, regresión, scoring, routing, análisis por segmentos y evaluación con referencias.

La lectura importante es que una fila no debería ser solo “texto y etiqueta”. Si source_id falta, no sabes de dónde salió el caso. Si split falta, no sabes si el ejemplo mide o entrena. Si license falta, no sabes si el uso que quieres hacer es aceptable. Y si pii_risk falta, el sistema puede tratar todos los casos igual aunque unos necesiten más cuidado que otros.

En un proyecto real, muchas discusiones se resuelven mirando estas columnas. Producto pregunta si el asistente puede contestar consultas de becas; datos mira cuántos ejemplos de becas hay por split; legal o compliance mira permisos; ingeniería mira si el schema se mantiene estable. Esa es la diferencia entre un CSV suelto y un dataset gobernable.

Dataset JSONL para LLMs

En LLMs se usa mucho JSONL porque cada línea puede representar una conversación, una instrucción, una preferencia o una traza:

{"prompt":"Resume","response":"Falta dato","split":"train"}
{"prompt":"Decide","response":{"action":"ask_more"},"split":"test"}

Lo importante no es que sea JSON. Lo importante es que cada línea sea independiente, versionable y validable. Si una línea trae messages, tools, expected_output, rubric_id o trace_id, el contrato debe declararlo.

JSONL se usa mucho porque encaja bien con pipelines: puedes leer línea a línea, validar ejemplos de forma aislada, partir en splits y detectar qué registro falló sin cargar un archivo gigante completo. Para un alumno de ingeniería, esta ventaja es muy concreta: si la línea 842 rompe el contrato, no tienes que interpretar una conversación entera o un export opaco; puedes señalar el ejemplo exacto.

Hay otra consecuencia: el orden de campos no es el contrato. El contrato vive en lo que esperas de cada campo. prompt puede ser texto plano, pero response puede ser texto, JSON estructurado o una lista de mensajes. Si mañana cambias de prompt/response a messages, no has cambiado solo nombres: has cambiado la interfaz de datos que alimenta al sistema.

Dataset de RAG

Un corpus RAG no es solo texto. Cada chunk debería traer metadatos:

{
  "document_id": "doc-pay-001",
  "chunk_id": "doc-pay-001#001",
  "source_uri": "intranet://academico/pagos/justificantes",
  "version": "2026-05-02",
  "text": "El justificante de pago se revisa...",
  "license": "internal_retrieval_allowed",
  "expires_at": "2026-12-31"
}

Campo	Pregunta que responde
document_id	¿Qué documento produjo este chunk?
chunk_id	¿Qué fragmento exacto se recuperó?
source_uri	¿Dónde está la fuente original?
version	¿Qué versión estaba vigente?
expires_at	¿Cuándo caduca esta evidencia?
license	¿Puede recuperarse, indexarse o mostrarse?

Si un RAG falla, muchas veces el problema no es el modelo. Puede ser un chunk sin fecha, una fuente obsoleta, un embedding generado con otro modelo, metadatos incompletos o un índice que no refleja el snapshot esperado.

Piensa en una consulta académica sobre pagos. Si el retriever encuentra un fragmento correcto pero de una normativa antigua, el modelo puede sonar seguro y aun así guiar mal. Por eso version y expires_at no son decoración: permiten decidir si una evidencia sigue viva. En RAG, recuperar “algo parecido” no basta; hay que recuperar algo pertinente, vigente y permitido.

Además, el chunk es un dato derivado. Se ha creado al partir un documento, quizá después de limpiar HTML, pasar OCR, eliminar cabeceras y generar embeddings. Cada paso puede cambiar el resultado. Si no guardas el document_id, la versión del chunking y el modelo de embedding, reconstruir un fallo se vuelve una conversación de memoria en vez de una investigación técnica.

Dataset de preferencias

Un dataset de preferencias enseña comparaciones:

{
  "prompt": "Responde una consulta sin evidencia",
  "chosen": "No tengo evidencia suficiente...",
  "rejected": "La anulacion siempre se puede hacer...",
  "preference_policy": "abstencion_con_evidencia"
}

Aquí el dato no dice solo “esta respuesta es buena”. Dice: “entre estas dos respuestas, bajo esta política, preferimos esta”. Eso exige documentar quién etiquetó, con qué rúbrica, en qué fecha y para qué entrenamiento o evaluación se puede usar.

La parte delicada es que una preferencia siempre depende de criterio. En un asistente académico quizá preferimos una respuesta que pregunta por documentación antes que otra que inventa una solución. En un asistente de programación quizá preferimos una respuesta que añade test y explica el riesgo. La preferencia no flota en el aire: necesita una política escrita.

Si no guardas preference_policy, un equipo puede interpretar que chosen significa “más amable”, otro que significa “más corta” y otro que significa “más correcta”. El dataset parecerá grande, pero estará enseñando señales mezcladas. Para post-entrenamiento y evaluación comparativa, esa ambigüedad es veneno lento: no rompe el script, pero degrada la decisión.

Dataset de trazas

En agentes, un dataset útil puede ser una traza:

{
  "trace_id": "tr_001",
  "goal": "resolver ticket",
  "state": "falta evidencia",
  "action": "retrieve_documents",
  "observation": "2 chunks recuperados",
  "outcome": "ask_more"
}

Este formato sirve para evaluar trayectorias, herramientas, costes, pasos innecesarios, criterios de parada y handoffs. Si solo guardamos la respuesta final, perdemos el dato que explica cómo llegó el sistema hasta allí.

La traza cambia la pregunta. Ya no miras solo si la respuesta final fue aceptable; miras si el sistema eligió bien los pasos. ¿Consultó una herramienta cuando hacía falta? ¿Pidió aclaración cuando la evidencia era insuficiente? ¿Repitió una llamada sin ganar información? ¿Terminó por el motivo correcto? Esa información es oro para ingeniería porque permite mejorar el sistema sin tocar necesariamente el modelo.

También convierte observabilidad en dataset. Las trazas que vimos en facsímiles anteriores no sirven solo para depurar una incidencia puntual. Bien muestreadas y revisadas, pueden transformarse en evals, casos de regresión, datasets de herramientas o ejemplos para entrenar políticas de orquestación.

Dataset de features

En ML clásico y sistemas híbridos aparece otra estructura: una entidad con features calculadas en un tiempo concreto.

entity_id | event_time | wait_days | label
s001      | 2026-05-01 | 12        | urgent

Aquí hay una trampa crítica: las features deben existir en el momento de la predicción. Si calculas una feature usando información posterior al evento, el modelo aprende con ventaja irreal. Este error se llama leakage temporal y suele producir métricas preciosas en notebook y decepción en producción.

El campo event_time es el ancla. Si quieres predecir el 1 de mayo si un caso será urgente, no puedes usar una variable calculada el 5 de mayo. Parece una obviedad, pero ocurre mucho cuando se agregan tablas históricas sin respetar la fecha de disponibilidad de cada columna.

Por eso un feature store no es simplemente “una base de datos con variables”. Su valor está en mantener la misma definición de feature para entrenamiento e inferencia, controlar frescura, guardar versiones y evitar que el notebook use una realidad distinta a la que verá el servicio en producción.

Taxonomía práctica de datasets en IA

Tipo de dataset	Unidad mínima	Uso típico	Riesgo principal
Tabular supervisado	Fila con features y etiqueta.	Clasificación, regresión, routing.	Leakage, desbalance, etiqueta ruidosa.
Corpus RAG	Documento o chunk con metadatos.	Recuperación y citas.	Fuente obsoleta, chunk sin linaje.
Instrucciones	Entrada y salida esperada.	SFT, evaluación, formato.	Enseñar estilo sin cubrir casos reales.
Preferencias	Prompt, respuesta elegida y rechazada.	Preferencias, ranking, post-entrenamiento.	Rúbrica ambigua o etiqueta inconsistente.
Trazas	Estado, acción, observación y resultado.	Agentes y EvalOps.	Guardar solo el final y perder diagnóstico.
Features	Entidad, tiempo y variables calculadas.	Modelos online/offline.	Desalineación entre entrenamiento e inferencia.
Multimodal	Texto, imagen/audio/video y metadatos.	Visión, documentos, OCR, audio.	Calidad de OCR, resolución, permisos.
Producción muestreada	Run real revisada.	Drift, regresiones, mejora continua.	Sesgo de muestreo y falta de owner.

Esta tabla no pretende encerrar todos los casos. Sirve para que el alumno aprenda a hacer una separación mental: qué unidad estoy midiendo, qué uso tendrá y cuál es el riesgo dominante. Si el dataset es RAG, el riesgo dominante suele estar en la fuente y el linaje. Si es preferencias, en la rúbrica. Si es features, en el tiempo y la consistencia entre entrenamiento e inferencia.

Una buena práctica es nombrar el dataset por su uso, no solo por su origen. tickets_soporte.csv dice poco. support_cases_eval_v2026_06 ya indica una finalidad. support_cases_sft_v2026_06 indica otra. Puede venir de la misma fuente, pero no tiene el mismo contrato ni debería tener los mismos permisos.

Hugging Face Datasets popularizó una interfaz donde un dataset puede cargarse como DatasetDict, con splits como train, validation y test, y operaciones reproducibles de carga, transformación y procesamiento.³ No hace falta usar esa librería para aprender la idea: un dataset moderno debe declarar estructura, particiones y transformaciones de forma explícita.

Fecha de corte del estado del arte

Fecha de corte: 6 de junio de 2026.
Fuentes consultadas: Datasheets for Datasets, Data Cards, Model Cards, Hidden Technical Debt in Machine Learning Systems, Software Engineering for Machine Learning, TFX, ML Test Score, ODCS, TensorFlow Data Validation, ML Metadata, OpenLineage, DataHub, Great Expectations, Feast, Evidently, DVC, lakeFS, Delta Lake, Apache Iceberg y Hugging Face Datasets.

Lo estable es la disciplina: datos versionados, schema verificable, linaje, documentación, validación, separación de splits, evaluación por segmentos y monitorización de cambios. Lo coyuntural son herramientas, paneles, proveedores y formatos exactos.

Las fuentes de este bloque no dicen todas lo mismo, y eso es bueno. Unas hablan de documentación, otras de pipelines, otras de contratos, otras de linaje y otras de monitorización. Juntas dibujan una idea muy importante: en IA, la calidad del sistema no se puede separar de la vida del dato. El dato nace, cambia, se transforma, se versiona, se consume y se degrada.

Sculley et al. explicaron que los sistemas de ML acumulan deuda técnica especial: dependencias de datos, realimentaciones escondidas, configuraciones frágiles y cambios no locales.⁴ Amershi et al. mostraron desde Microsoft que construir ML exige prácticas de ingeniería diferentes al software clásico, especialmente alrededor de datos, experimentos y evolución del sistema.⁵

TFX formalizó una plataforma de ML a escala de producción donde ingestión, validación, transformación, entrenamiento, evaluación y serving forman un pipeline reproducible.⁶ El ML Test Score propuso una rúbrica para madurez de producción que incluye tests de datos, validación, monitorización y gestión de cambios.⁷

En herramientas actuales, ODCS define una estructura abierta para contratos de datos con secciones de fundamentos, schema, referencias, calidad, soporte, equipo, roles y acuerdos de servicio.⁸ TensorFlow Data Validation analiza datos, genera estadísticas, infiere schema y detecta anomalías contra expectativas.⁹ ML Metadata registra artefactos, ejecuciones y contextos para recuperar linaje en workflows de ML.¹⁰

OpenLineage aporta un estándar abierto para capturar metadatos de linaje en ejecuciones de jobs.¹¹ DataHub se presenta como catálogo de datos para metadatos, búsqueda, linaje, perfilado, gobernanza y contratos.¹² Great Expectations organiza calidad de datos mediante expectations reutilizables.¹³

Feast es un feature store que separa offline store para generar datos de entrenamiento y online store para servir features de baja latencia.¹⁴ Evidently documenta métricas de drift para comparar distribuciones y detectar cambios en datos o modelos.¹⁵ DVC, lakeFS, Delta Lake y Apache Iceberg tratan el problema de reproducibilidad y versionado desde ángulos distintos: proyectos ML versionados, data lakes con semántica tipo Git, time travel, schema enforcement, snapshots y evolución de schema.^16171819

La lección práctica para este facsímil: los datos no son un paso previo; son parte del sistema.

Arquitectura de datos para IA

Una arquitectura mínima de datos para IA tiene varias capas. No todas hacen falta en un proyecto pequeño, pero todas deben existir como pregunta mental:

Capa	Qué guarda	Pregunta que responde
Fuente	Tabla, documento, log, traza, imagen o evento original.	¿De dónde salió este dato?
Ingestión	Copia controlada del dato.	¿Cuándo entró y bajo qué contrato?
Validación	Estadísticas, schema, expectations y anomalías.	¿Cumple lo prometido?
Transformación	Limpieza, chunking, OCR, features, embeddings.	¿Qué se cambió y con qué versión?
Versionado	Snapshot, hash, commit, tabla Delta/Iceberg, DVC/lakeFS.	¿Puedo reconstruir el mismo dataset?
Catálogo	Owner, descripción, sensibilidad, contrato, documentación.	¿Quién responde por esto y para qué sirve?
Linaje	Jobs, inputs, outputs, columnas y artefactos derivados.	¿Qué rompemos si cambia esta fuente?
Consumo	Entrenamiento, RAG, eval, dashboard, agente, producto.	¿Qué sistema usa este dato?
Monitorización	Drift, frescura, calidad, cobertura, feedback.	¿Producción sigue pareciéndose a lo validado?

La arquitectura correcta depende del tamaño. Para un proyecto didáctico, un CSV, un contrato JSON y un script bastan. Para una organización, quizá necesitas catálogo, feature store, lineage estándar, lakehouse y gates en CI. Lo importante es no saltarse la pregunta: qué evidencia tengo de que este dato sigue siendo el dato que creo que es.

Una forma sencilla de leer esta arquitectura es seguir una fila. Primero existe en una fuente: un ticket, un documento, una traza. Después entra en una zona controlada mediante ingestión. Luego se valida: tipos, nulos, valores permitidos, licencias. Más tarde se transforma: quizá se limpia, se trocea, se convierte en embedding o se convierte en feature. Finalmente se consume: entrena, evalúa, alimenta un RAG o aparece en un dashboard.

Si cada paso deja evidencia, puedes investigar un fallo con calma. Si no la deja, dependes de recordar quién exportó qué archivo, con qué filtro y en qué día. Eso no escala, y además impide que un alumno aprenda ingeniería reproducible. La meta no es montar una plataforma enorme desde el primer día; la meta es que incluso el proyecto pequeño tenga una línea clara entre fuente, transformación, versión y decisión.

Anatomía de un contrato de datos para IA

Las fórmulas que sí conviene saber

Ejemplo de fórmula: la primera fórmula útil no es estadística. Es de ingeniería y resume una política de release de datos. Podríamos añadir más condiciones en otro proyecto, pero si una de estas falla, el dataset no debería avanzar sin revisión.

$$data\_ok = schema\_ok \land lineage\_ok \land license\_ok \land split\_ok \land quality\_ok$$

Término	Qué exige
schema_ok	Columnas, tipos y valores permitidos coinciden con el contrato.
lineage_ok	Cada fila tiene fuente, fecha, owner y hash reproducible.
license_ok	El uso previsto respeta licencia y consentimiento declarados.
split_ok	Train, validation y test están separados sin fuga obvia.
quality_ok	No hay missing, duplicados, etiquetas imposibles o señales rotas por encima del umbral.

La tasa de valores faltantes por columna puede escribirse como:

$$miss(c) = \frac{ \sum_{i=1}^{n} \mathbb{1}[x_{i,c}=\varnothing] }{n}$$

Símbolo	Significado
$miss(c)$	Proporción de filas donde falta la columna $c$.
$n$	Número de filas del dataset.
$x_{i,c}$	Valor de la columna $c$ en la fila $i$.
$\mathbb{1}$	Indicador: vale 1 si la condición se cumple, 0 si no.

Para leakage simple entre train y test podemos mirar huellas de texto:

$$leak(D_{train}, D_{test}) = \frac{ |F(D_{train}) \cap F(D_{test})| }{ |F(D_{test})| }$$

Símbolo	Significado
$F(D)$	Conjunto de huellas normalizadas de ejemplos en un dataset.
$D_{train}$	Split de entrenamiento.
$D_{test}$	Split de prueba.
$leak$	Proporción de ejemplos de test que aparecen también en train.

Esto no detecta todos los problemas. Un duplicado semántico puede no tener el mismo texto. Pero ya evita una trampa básica: evaluar con respuestas que el sistema pudo ver durante ajuste.

Para revisar balance de etiquetas podemos usar proporciones:

$$p(y=k)= \frac{n_k}{n}$$

Símbolo	Significado
$p(y=k)$	Proporción de ejemplos con etiqueta $k$.
$n_k$	Número de ejemplos de esa etiqueta.
$n$	Número total de ejemplos.

Si una clase tiene muy pocos ejemplos, el modelo puede aprender a ignorarla y aun así sacar una métrica global aceptable. Por eso conviene mirar distribución de labels, productos, canales e idiomas.

La entropía resume cuán repartida está una distribución:

$$H(Y)= -\sum_k p(y=k)\log p(y=k)$$

Símbolo	Significado
$H(Y)$	Entropía de la distribución de etiquetas.
$p(y=k)$	Proporción de la etiqueta $k$.

Una entropía baja no es necesariamente mala. Puede significar que el mundo real está desbalanceado. Lo importante es no confundir “realista” con “suficiente para entrenar o evaluar bien”.

Para drift entre una muestra de referencia $P$ y una muestra actual $Q$, una medida sencilla es distancia total variation:

$$D_{TV}(P,Q)= \frac{1}{2} \sum_i |P_i-Q_i|$$

Símbolo	Significado
$P_i$	Proporción de la categoría $i$ en la referencia.
$Q_i$	Proporción de la categoría $i$ en la muestra actual.
$D_{TV}$	Distancia entre distribuciones categóricas.

También se usa PSI (Population Stability Index) en entornos de scoring:

$$PSI = \sum_i (Q_i-P_i) \log \frac{Q_i}{P_i}$$

Símbolo	Significado
$PSI$	Índice de estabilidad poblacional.
$P_i$	Proporción esperada o de referencia.
$Q_i$	Proporción observada o actual.

No lo uses como oráculo. Úsalo como señal: si sube, mira la distribución, el tamaño muestral, la fecha, el origen y si la evaluación sigue representando producción.

Para etiquetas humanas, si dos personas anotan los mismos casos, conviene medir acuerdo. Una versión clásica es kappa de Cohen:

$$\kappa = \frac{p_o-p_e}{1-p_e}$$

Símbolo	Significado
$p_o$	Acuerdo observado.
$p_e$	Acuerdo esperado por azar según las distribuciones de anotación.
$\kappa$	Acuerdo corregido por azar.

Si las personas no se ponen de acuerdo, quizá el problema no es el modelo. Quizá la etiqueta está mal definida.

Los siete contratos que debería tener un dataset

Un contrato de datos no tiene que ser enorme para ser útil. Debe responder siete preguntas:

Contrato	Pregunta	Ejemplo
Schema	¿Qué columnas existen y qué valores son válidos?	label solo puede ser answer, ask_more, escalate.
Linaje	¿De dónde viene cada fila?	source_id, created_at, owner, dataset_hash.
Uso permitido	¿Para qué puede usarse?	Entrenar, evaluar, consultar, indexar o solo revisar.
Sensibilidad	¿Qué cuidado exige?	Riesgo de PII bajo, medio o alto.
Splits	¿Qué se usa para entrenar y qué para medir?	train, validation, test.
Calidad mínima	¿Qué bloquea uso?	Missing, duplicado, licencia incompatible, etiqueta no permitida.
Decisión	¿Qué hacemos con el resultado?	pass, review, block.

Estos contratos no son burocracia. Son una forma de convertir intuiciones en reglas que se puedan revisar. Si alguien dice “este dataset es bueno”, podemos preguntar: ¿bueno para qué uso?, ¿con qué permisos?, ¿para qué población?, ¿con qué fecha de corte?, ¿con qué separación entre entrenamiento y evaluación? Un contrato no elimina la discusión, pero la vuelve concreta.

También evita que el dato cambie silenciosamente. Si un productor añade una columna, cambia el significado de label o deja de enviar source_id, el consumidor no debería enterarse semanas después por una caída de calidad. El contrato permite detectar el cambio en el momento en que entra al pipeline.

Esta idea conecta con model cards. Una model card documenta un modelo; una dataset card documenta el material que lo alimenta o lo evalúa.²⁰ Las dos cosas se necesitan: un modelo sin datos documentados es difícil de interpretar; un dataset sin uso previsto puede acabar aplicado donde no toca.

Herramientas: qué problema resuelve cada una

No hay una herramienta única para “datos de IA”. Hay piezas distintas:

Herramienta o estándar	Resuelve	Sirve cuando	No sustituye
ODCS	Contrato de datos legible y extensible.	Varios equipos producen y consumen datos.	La validación ejecutable si no conectas checks.
TensorFlow Data Validation	Estadísticas, schema y anomalías.	Quieres perfilar y validar datasets de ML.	Decidir si la licencia o finalidad son correctas.
ML Metadata	Linaje de artefactos, ejecuciones y contextos.	Tienes pipelines ML reproducibles.	Un catálogo de negocio completo.
OpenLineage	Estándar de eventos de linaje de jobs.	Necesitas linaje entre orquestadores y sistemas.	Documentación semántica de cada campo.
DataHub	Catálogo, metadatos, linaje y gobernanza.	Una organización necesita descubrir y gobernar datos.	Checks específicos de entrenamiento si no los defines.
Great Expectations	Expectations y suites de calidad.	Quieres tests de datos repetibles.	Versionado de snapshots o linaje completo.
Feast	Feature store online/offline.	Necesitas features consistentes en train e inferencia.	Limpieza de datos fuente o evaluación de modelo.
Evidently	Drift y monitorización de datos/modelos.	Comparas referencia contra producción.	Arreglar por sí solo una distribución que cambió.
DVC	Versionado de datos y pipelines con Git.	Equipos pequeños o medianos quieren reproducibilidad ML.	Catálogo empresarial o tabla transaccional.
lakeFS	Versionado tipo Git sobre data lake.	Necesitas ramas, commits y rollbacks de datos a escala.	Validación semántica de columnas.
Delta Lake	Tablas con transacciones, schema enforcement y time travel.	Lakehouse con necesidad de historial y rollback.	Contrato de uso por dominio.
Apache Iceberg	Tablas con snapshots y evolución de schema/partición.	Data lake analítico con motores múltiples.	Evaluación de calidad del dataset.
Hugging Face Datasets	Carga, splits y procesamiento reproducible.	Datasets de NLP, multimodalidad y benchmarks.	Gobernanza interna, licencias y owner.

Una forma práctica de ordenar estas herramientas es por pregunta. Si preguntas “¿qué columnas prometo?”, estás cerca de contratos. Si preguntas “¿cumple lo prometido?”, estás cerca de validación. Si preguntas “¿de dónde viene este resultado?”, estás cerca de linaje. Si preguntas “¿qué versión exacta usé?”, estás cerca de versionado. Y si preguntas “¿ha cambiado producción?”, estás cerca de monitorización.

En un proyecto pequeño no necesitas instalar todo. Puedes empezar con un contrato JSON, scripts de validación, hashes y una dataset card. En un proyecto de empresa, esas mismas ideas pueden acabar repartidas entre DataHub, OpenLineage, Great Expectations, Feast, DVC, lakeFS o tablas lakehouse. La escala cambia; la lógica no.

La lectura correcta para ingeniería no es “elige la herramienta de moda”. Es:

1. ¿Dónde vive la verdad del dataset?
2. ¿Cómo versiono el snapshot?
3. ¿Cómo valido schema y calidad?
4. ¿Cómo registro linaje?
5. ¿Cómo documento finalidad y límites?
6. ¿Cómo detecto que producción cambió?

Si no puedes responder esas seis preguntas, el stack todavía no está maduro aunque tenga nombres modernos. Y al revés: si puedes responderlas con herramientas simples, ya tienes una base didáctica y profesional bastante sana.

Cómo los datos alteran algoritmos

Un dataset no solo alimenta modelos; cambia el comportamiento de los algoritmos.

Algoritmo o sistema	Qué dato lo condiciona	Qué pasa si el dato está mal
Árbol de decisión	Features categóricas, umbrales, missing.	Puede elegir un split cómodo pero espurio.
Regresión logística	Escala, colinealidad, balance de clases.	Pesos inestables o clase minoritaria ignorada.
k-means	Escalado y distancia.	Una variable con rango grande domina los clusters.
Embeddings	Corpus, idioma, longitud y objetivo de entrenamiento.	Vecinos semánticos pobres o sesgo de dominio.
RAG	Chunking, metadatos, vigencia, índice.	Recupera texto irrelevante o caducado.
Fine-tuning	Pares entrada-salida y etiquetas.	Aprende formato superficial o errores de anotación.
Preferencias	chosen, rejected, rúbrica.	Optimiza gustos mal definidos.
Evaluador LLM	Casos, criterios y ejemplos calibrados.	Premia estilo en vez de verdad operativa.
Agente	Trazas, tools, outcomes y costes.	Aprende trayectorias largas o acciones no útiles.

La parte incómoda es que muchos algoritmos parecen matemáticamente limpios cuando se explican en abstracto, pero se vuelven frágiles al tocar datos reales. Un k-means no “sabe” que una variable está en euros y otra en días; solo ve magnitudes. Una regresión no “sabe” que una clase minoritaria es crítica para negocio; solo optimiza sobre lo que le das. Un retriever no “sabe” que un documento caducó si no lo marcas.

Esto no resta importancia a los algoritmos. Al contrario: para usarlos bien hay que respetar sus supuestos. Si el algoritmo usa distancia, revisa escalado. Si usa etiquetas, revisa criterios de anotación. Si usa ranking, revisa qué documentos pueden aparecer arriba. Si usa trazas, revisa si esas trazas representan la operación real o solo casos cómodos.

Un ejemplo sencillo: si un dataset de soporte tiene casi todo answer y muy pocos ask_more, un clasificador puede responder siempre y sacar buen accuracy. Pero producto necesita saber cuándo preguntar. En ese caso, el problema no es solo el algoritmo: el dataset no representa suficientemente la decisión que queremos automatizar.

Otro ejemplo: en RAG, dos chunks pueden tener texto parecido, pero uno está vigente y otro caducado. Si no guardas version y expires_at, el retriever puede hacer lo que le pediste técnicamente y aun así devolver evidencia mala.

La ingeniería de datos para IA consiste justo en esto: mirar dónde se rompen los supuestos antes de culpar al modelo. A veces el modelo falla; muchas otras, el dataset no estaba contando el mundo que creíamos.

Datasets en LLMs: no solo entrenamiento

En sistemas con LLMs, la palabra datos aparece en muchas capas:

Capa	Artefacto de datos	Pregunta de ingeniería
Pre-entrenamiento	Corpus masivo.	¿Qué mezcla de idioma, dominio y calidad aprende el modelo base?
SFT o ajuste	Pares entrada-salida.	¿Enseñan formato y comportamiento estable?
Preferencias	Comparaciones o rankings.	¿Qué criterio humano o automático se está optimizando?
RAG	Documentos, chunks y metadatos.	¿La fuente está vigente, citada y recuperable?
Embeddings	Vectores derivados de texto o imagen.	¿Se protegen como parte del corpus?
Evals	Casos, referencias y rúbricas.	¿Separan baseline y candidate con evidencia?
Observabilidad	Traces, errores y feedback.	¿Se pueden convertir en regresiones o mejoras del dataset?

Esta tabla ayuda a desmontar una confusión habitual: “datos de LLM” no significa solo corpus de entrenamiento. Un documento de ayuda puede no tocar jamás los pesos del modelo y aun así condicionar una respuesta mediante RAG. Una traza de producción puede no entrenar nada hoy, pero convertirse mañana en un caso de evaluación. Una conversación puede servir para mejorar formato, pero no para actualizar conocimiento vivo.

La clave: un dato cambia de papel según su uso. Un documento puede ser fuente RAG, caso de evaluación, ejemplo de fine-tuning o evidencia de una incidencia. Cada uso necesita permiso y contrato.

Por eso el contrato debe hablar de usos, no solo de columnas. La misma fila puede estar permitida para evaluación interna, prohibida para entrenamiento, permitida para recuperación sin mostrar texto literal, o reservada para análisis manual. Sin esa distinción, el dataset se vuelve una bolsa de material disponible y el equipo acaba tomando decisiones por costumbre.

Manos a la obra

El kit del capítulo está en:

kit/

Construye una auditoría pequeña pero completa sobre un dataset sintético de soporte académico. No entrena ningún modelo porque esa no es la decisión de este capítulo. La decisión es anterior: este dataset puede entrar en una cadena de IA o debe quedarse en revisión.

El kit cubre cuatro formas de datos:

Forma	Archivo	Para qué sirve
Dataset tabular	data/support_cases.csv	Clasificación, splits, etiquetas, licencias y linaje por fila.
Corpus RAG	data/rag_documents.jsonl	Chunks con versión, caducidad, fuente y permiso de recuperación.
Preferencias	data/preference_pairs.jsonl	Pares chosen/rejected con política de preferencia.
Muestra actual	data/production_sample.csv	Comparar producción contra el dataset de referencia y detectar drift.

La idea es que el alumno no solo lea nombres de archivos. Debe entender qué papel juega cada uno. support_cases.csv representa el dataset que queremos aprobar. rag_documents.jsonl enseña cómo debería documentarse un corpus recuperable. preference_pairs.jsonl enseña que una preferencia necesita política. production_sample.csv introduce la vida real: aunque el dataset base pase, producción puede moverse.

Cuando termines el laboratorio, deberías poder llevarte el patrón a otro proyecto. Cambiarás columnas, dominios y umbrales, pero mantendrás la secuencia: contrato, auditoría, manifest, card, decisión y revisión de drift.

Estructura

kit/
  README.md
  data/support_cases.csv
  data/rag_documents.jsonl
  data/preference_pairs.jsonl
  data/production_sample.csv
  contracts/data_contract.json
  contracts/odcs_like_contract.yaml
  ops/data/audit_dataset_contract.py
  ops/data/compare_drift.py
  output/data_quality_report.json
  output/lineage_manifest.json
  output/data_release_gate.json
  output/leakage_report.json
  output/dataset_card.md
  output/data_release_decision.md
  output/drift_report.json
  output/drift_decision.md

La estructura separa datos, contratos, código y salidas. Esta separación importa. Si mezclas todo en una carpeta, es fácil editar una salida a mano, confundir un reporte viejo con uno nuevo o no saber si el contrato usado coincide con el dataset. En cambio, cuando cada cosa tiene su sitio, el proyecto enseña una disciplina simple: entrada, regla, ejecución y evidencia.

Cómo lo ejecutas

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/data/audit_dataset_contract.py --write
python3 ops/data/compare_drift.py --write
cat output/data_release_decision.md
cat output/drift_decision.md

No hay dependencias externas. Es deliberado: el alumno debe poder abrir el código y ver cada comprobación.

En una organización usarías librerías y servicios más completos, pero aquí interesa ver la mecánica sin capas intermedias. El script lee el contrato, carga el dataset, calcula checks, decide el gate y escribe artefactos. Ese recorrido es exactamente el mismo que luego haría un pipeline más grande con Airflow, Dagster, dbt, Great Expectations o una plataforma interna.

Qué audita el primer script

Pieza	Qué produce	Por qué importa
Schema	Comprueba columnas obligatorias y columnas extra.	Si cambia la forma, puede romper entrenamiento, eval o RAG.
Unicidad	Verifica que case_id no se repite.	Una fila duplicada puede inflar métricas o sesgar conteos.
Splits	Comprueba valores permitidos y mínimos por split.	Una evaluación sin test suficiente no permite decidir.
Etiquetas	Verifica catálogo y cantidad mínima total.	Una clase sin ejemplos es una promesa falsa.
Missing	Calcula tasa de valores faltantes.	Los huecos no son inocentes: pueden ocultar un pipeline roto.
Licencias	Comprueba si cada split permite ese uso.	Entrenar, evaluar e indexar no son el mismo permiso.
Sensibilidad	Bloquea valores de riesgo no permitidos.	El contrato debe saber qué dato necesita más cuidado.
Linaje	Revisa fuente, fecha, owner, licencia y consentimiento.	Sin linaje no puedes explicar ni reconstruir la decisión.
Leakage	Busca duplicados de texto entre splits.	Evita medir con ejemplos que ya estaban cerca del entrenamiento.
Manifest	Genera hashes del dataset y del contrato.	Permite saber exactamente qué snapshot se aprobó.
Dataset card	Documenta finalidad, distribución y resultado.	Sustituye memoria oral por evidencia revisable.
Gate	Escribe pass, review o block.	Convierte calidad de datos en decisión operativa.

El punto más importante es que el gate no dice “el dataset es perfecto”. Dice algo más humilde y útil: “con las reglas actuales, este snapshot cumple lo suficiente para el uso declarado”. Si el uso cambia, el contrato debe cambiar. Si el contrato cambia, el gate debe volver a ejecutarse.

También conviene mirar los checks que pasan, no solo los que fallan. Un reporte con todo en verde enseña qué condiciones está garantizando: no hay IDs repetidos, los splits existen, las licencias encajan, el linaje está completo. Esa evidencia permite defender una decisión técnica sin depender de impresiones.

Qué audita el segundo script

El segundo script compara support_cases.csv contra production_sample.csv en columnas categóricas:

Columna	Qué mira	Cómo se lee
product	Si cambió la mezcla de temas.	Si aparecen muchas consultas nuevas, la eval puede no representar producción.
label	Si cambió la distribución de acciones esperadas.	Si suben casos de ask_more, una política de respuesta directa puede quedarse corta.
channel	Si cambió el canal de entrada.	Un canal nuevo trae estilo, longitud y ruido distintos.
pii_risk	Si cambió la sensibilidad.	La operación necesita otro control antes de reutilizar trazas.

Calcula tres señales:

Señal	Qué mide	Lectura práctica
total_variation	Diferencia total entre dos distribuciones categóricas.	Buena para entender cuánto se ha movido la mezcla.
jensen_shannon	Separación suavizada entre distribuciones.	Útil porque es simétrica y estable para comparar perfiles.
psi	Estabilidad poblacional.	Señal habitual en scoring y monitorización, pero siempre requiere mirar el dato.

El drift no significa automáticamente que haya que tirar el dataset. Significa que hay que mirar. Si producción cambia de titulos a pagos, quizá es una semana rara; quizá hubo una campaña; quizá el producto cambió; quizá la evaluación ya no cubre lo que importa. La métrica abre una revisión, no la sustituye.

En el ejemplo, psi salta especialmente porque una categoría que existía en la referencia deja de aparecer en la muestra actual. Eso no convierte el número en una verdad absoluta, pero sí en una buena alarma didáctica. El siguiente paso no es discutir el decimal: es abrir distribuciones, mirar fechas, revisar tamaño muestral y decidir si hace falta actualizar la eval.

Salida esperada de calidad

El reporte actual genera:

{
  "row_count": 18,
  "split_counts": {
    "train": 8,
    "validation": 4,
    "test": 6
  },
  "label_distribution": {
    "answer": 11,
    "ask_more": 4,
    "escalate": 3
  },
  "gate": "pass",
  "recommendation": "usar como dataset didactico"
}

La decisión importante es:

Estado: pass.

Este dataset puede usarse como material didactico.
Tiene contrato, schema esperado, splits definidos,
licencias compatibles, linaje por fila y hashes reproducibles.

Esta salida no autoriza a usar datos reales sin más. Autoriza este snapshot didáctico bajo este contrato didáctico. En un proyecto real, la decisión debería incluir quién aprueba, qué uso se permite, qué fecha de caducidad tiene el dataset y qué cambios obligan a repetir la auditoría.

Salida esperada de drift

La muestra de producción está preparada para que haya una señal de revisión:

{
  "gate": "review",
  "recommendation": "revisar drift antes de reutilizar la eval"
}

La lectura no es “todo está roto”. La lectura profesional es más precisa: producción cambió lo suficiente como para revisar si el test sigue representando la realidad.

Esta diferencia de lenguaje es importante. review no es fracaso; es una pausa técnica. Si el dataset de evaluación ya no representa los casos actuales, comparar modelos con ese test puede llevarte a elegir mal. El gate de drift protege la decisión, no solo el dataset.

Cómo lo adaptas a tu caso

Si tu proyecto es...	Añade al contrato	Añade al gate
RAG documental	document_version, chunk_id, retrieval_scope, expires_at, embedding_model.	Fuente vigente, chunk con cita, embedding regenerado con versión esperada.
Fine-tuning	training_allowed, label_source, reviewer_id, label_policy_version.	Licencia compatible, etiqueta revisada, ejemplos por etiqueta y por segmento.
Evaluación	expected_output, rubric_id, criticality, baseline_version.	Leakage, cobertura por caso crítico, acuerdo entre anotadores.
Agentes	tool_context, action_allowed, approval_required, trace_id, stop_reason.	Trayectoria válida, coste máximo, herramienta permitida, salida verificable.
Multimodal	media_type, resolution, ocr_quality, caption_source, asset_license.	Resolución mínima, OCR revisado, permiso de uso y metadatos completos.
Feature store	entity_id, event_time, feature_view, freshness_slo.	Sin leakage temporal, consistencia offline/online, frescura mínima.

Para adaptar el laboratorio, empieza por escribir una historia de uso: “quiero evaluar un asistente de soporte”, “quiero indexar documentación interna”, “quiero ajustar el formato de respuesta”, “quiero entrenar un clasificador”. Después traduce esa historia a columnas. Si una columna no ayuda a decidir, quizá sobra. Si una decisión no se puede tomar con las columnas actuales, falta contrato.

La mejor adaptación no es la más larga. Es la que deja claro qué está permitido, qué se mide, qué se bloquea y qué evidencia queda. Un contrato pequeño pero ejecutable gana a una política enorme que nadie puede comprobar.

Qué entregaría un alumno

1. data_quality_report.json ejecutado sin editar a mano.
2. lineage_manifest.json con hashes reproducibles.
3. dataset_card.md revisada como ficha de uso.
4. data_release_decision.md con una decisión clara.
5. drift_report.json comparando referencia y muestra actual.
6. Una propuesta de cambio al contrato para su propio caso.
7. Una respuesta escrita a esta pregunta: “¿qué uso permitiría y qué uso no permitiría con estos datos?”.

El objetivo no es copiar este contrato. Es aprender la forma mental: antes de usar datos, escribe qué significa usarlos bien y haz que una máquina lo compruebe.

Cómo encaja todo

El mapa siguiente conecta este capítulo con lo que ya hemos trabajado. RAG necesita documentos y chunks; embeddings son datos derivados; observabilidad produce trazas; evals necesitan casos separados; interpretabilidad necesita linaje para explicar por qué un sistema decidió algo. Por eso este facsímil no va aparte: es el suelo sobre el que pisan los facsímiles anteriores.

También prepara los siguientes capítulos. Calidad de datos, splits, features, slices, drift y experimentos no son temas aislados. Son capas de una misma pregunta: qué evidencia tenemos de que el dato representa bien la decisión que queremos tomar.

graph TD
    subgraph "Este capítulo"
        SRC["Fuente y formato"]
        CONTRACT["Contrato de datos"]
        LIN["Linaje<br/>hashes · permisos"]
        SPLIT["Splits iniciales"]
        CHECK["Checks de calidad"]
        CARD["Dataset card"]
        DEC["Decisión de uso"]
    end
    subgraph "Mismo facsímil"
        C02["Calidad<br/>cap. 2"]
        C03["Splits<br/>cap. 3"]
        C04["Features y embeddings<br/>cap. 4"]
        C05["Slices<br/>cap. 5"]
        C06["DataOps<br/>cap. 6"]
        C07["Experimentos<br/>cap. 7"]
    end
    subgraph "Otros facsímiles"
        RAG["RAG<br/>fasc. 4"]
        EMB["Embeddings<br/>fasc. 4"]
        OBS["Observabilidad<br/>fasc. 6"]
        EVAL["Evals<br/>fasc. 7"]
        GOV["Gobernanza<br/>fasc. 9"]
    end

    RAG -->|"necesita documentos"| SRC
    EMB -->|"genera datos derivados"| LIN
    OBS -->|"aporta trazas"| SRC
    EVAL -->|"necesita casos separados"| SPLIT

    SRC -->|"se formaliza en"| CONTRACT
    CONTRACT -->|"exige"| LIN
    CONTRACT -->|"define"| SPLIT
    CONTRACT -->|"activa"| CHECK
    LIN -->|"documenta"| CARD
    CHECK -->|"alimenta"| CARD
    CARD -->|"permite"| DEC

    CONTRACT -->|"abre"| C02
    SPLIT -->|"prepara"| C03
    LIN -->|"protege"| C04
    CHECK -->|"se mira por"| C05
    CARD -->|"se opera en"| C06
    DEC -->|"da población a"| C07
    DEC -->|"deja evidencia"| GOV

    style SRC fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CONTRACT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LIN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SPLIT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CHECK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CARD fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DEC fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C02 stroke-dasharray: 5 5
    style C03 stroke-dasharray: 5 5
    style C04 stroke-dasharray: 5 5
    style C05 stroke-dasharray: 5 5
    style C06 stroke-dasharray: 5 5
    style C07 stroke-dasharray: 5 5
    style RAG stroke-dasharray: 5 5
    style EMB stroke-dasharray: 5 5
    style OBS stroke-dasharray: 5 5
    style EVAL stroke-dasharray: 5 5
    style GOV stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición breve
Dataset	Conjunto de ejemplos con datos, metadatos y finalidad de uso.
Fuente de datos	Lugar original del que sale el dato: tabla, documento, log, traza o evento.
DatasetDict	Estructura que agrupa splits como train, validation y test.
JSONL	Formato de una línea JSON por ejemplo, muy útil para LLMs, RAG y trazas.
Linaje	Registro de origen, transformación, versión, owner y hash.
Contrato de datos	Especificación verificable de columnas, permisos, splits y checks.
ODCS	Estándar abierto para describir contratos de datos.
Split	Partición destinada a entrenar, validar, probar o evaluar.
Leakage	Fuga de información que contamina la evaluación.
Dataset card	Ficha que documenta finalidad, composición, límites y usos previstos.
Dato derivado	Chunk, embedding, feature, resumen, etiqueta o traza producida desde otro dato.
Feature store	Sistema para mantener features consistentes entre entrenamiento e inferencia.
Drift	Cambio en una distribución respecto a una referencia.
PSI	Índice de estabilidad poblacional usado como señal de drift.
Sensibilidad	Nivel de cuidado por privacidad, licencia, permisos o impacto.
Schema	Forma esperada del dataset: columnas, tipos y valores válidos.
Snapshot	Copia concreta y fechada del dataset.
Time travel	Capacidad de consultar una versión anterior de un dato o tabla.
Hash	Huella criptográfica que identifica una versión exacta.
Owner	Equipo o persona responsable del contrato y sus cambios.
Gate de datos	Decisión automatizada de pass, review o block sobre un dataset.

Dónde solía tropezar yo

Tropiezo	Por qué ocurre	Antídoto
Entrenar antes de escribir contrato	El dataset parece obvio porque está delante.	Escribir schema, uso permitido, splits y checks antes de tocar modelo.
Mezclar train y test sin darse cuenta	Duplicados, textos parecidos o casos derivados cruzan particiones.	Calcular huellas y revisar leakage básico.
Usar el mismo dato para RAG, fine-tuning y eval	Todo vive en la misma carpeta y parece “texto útil”.	Declarar finalidad y permiso por fila o documento.
Tratar embeddings como si no fueran datos	Al ser vectores, parecen menos sensibles.	Heredar permisos, linaje y protección del texto origen.
Creer que una licencia vale para todo	Consulta, evaluación y entrenamiento son usos distintos.	Registrar license y consent_scope por fila.
Guardar preferencias sin política	Un chosen sin rúbrica parece verdad universal.	Versionar preference_policy, anotador, fecha y criterio.
Documentar solo el modelo	Es más visible presentar una model card.	Añadir dataset card y manifest de linaje.
Limpiar sin versionar	La limpieza mejora algo, pero borra el camino.	Guardar contrato, hashes y decisión de cada snapshot.
Ignorar producción después de aprobar la eval	El test aprobado da tranquilidad falsa durante meses.	Comparar muestras nuevas contra referencia y revisar drift.
Confundir feature store con base de datos normal	Parece solo una tabla más.	Verificar event_time, frescura, consistencia offline/online y leakage temporal.

Antes de pasar página

Antes de avanzar, deberías poder responder:

1. ¿Por qué un dataset no es simplemente una carpeta de filas?
2. ¿Qué diferencia hay entre fuente de datos, dataset y dato derivado?
3. ¿Qué campos mínimos incluirías en un contrato de datos?
4. ¿Por qué una licencia puede permitir RAG pero no fine-tuning?
5. ¿Qué es linaje y qué aporta un hash?
6. ¿Cómo detectarías leakage básico entre train y test?
7. ¿Por qué los embeddings deben tratarse como datos derivados?
8. ¿Qué cambia entre un CSV, un JSONL, un DatasetDict y un corpus RAG?
9. ¿Qué debería contener una dataset card?
10. ¿Qué significa que un gate de datos devuelva pass, review o block?
11. ¿Qué mide PSI y por qué no basta con mirar solo ese número?
12. ¿Qué metadatos necesita un chunk RAG para ser confiable?
13. ¿Qué información mínima debe traer un par de preferencias?
14. ¿Qué problema resuelve un feature store y qué problema no resuelve?
15. ¿Cómo conecta este capítulo con evaluación e interpretabilidad?

En resumen

Idea	Qué te llevas
Los datos son parte del sistema.	No son una entrada pasiva ni una fase previa menor.
Un dataset necesita contrato.	Schema, linaje, uso permitido, sensibilidad, splits y checks.
La estructura depende de la tarea.	Tabular, JSONL, RAG, preferencias, trazas y features no piden lo mismo.
La evaluación depende del dato.	Si hay leakage o etiquetas débiles, la métrica miente.
RAG y embeddings también son DataOps.	Chunks y vectores heredan permisos, versiones y linaje.
El drift cambia decisiones.	Un test aprobado puede dejar de representar producción.
La documentación importa.	Dataset card, manifest y decisión técnica evitan memoria oral.
La práctica empieza con un gate.	Antes de entrenar, indexar o evaluar, audita el dataset.
Lo profesional es dejar evidencia.	Contrato, hashes, reportes y decisión deben poder repetirse.

Para saber más

Baylor, D., Breck, E., Cheng, H.-T., Fiedel, N., Foo, C. Y., Haque, Z., Haykal, S., Ispir, M., Jain, V., Koc, L., Koo, C. Y., Lew, L., Mewald, C., Modi, A. N., Polyzotis, N., Ramesh, S., Roy, S., Whang, S. E., Wicke, M., Wilkiewicz, J., Zhang, X. y Zinkevich, M. (2017). TFX: A TensorFlow-Based Production-Scale Machine Learning Platform. KDD, 1387-1395. https://doi.org/10.1145/3097983.3098021

Bitol. (2026). Open Data Contract Standard. https://bitol-io.github.io/open-data-contract-standard/latest/

Breck, E., Cai, S., Nielsen, E., Salib, M. y Sculley, D. (2017). The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. IEEE Big Data, 1123-1132. https://research.google/pubs/pub46555/

DataHub. (2026). DataHub Documentation. https://docs.datahub.com/

DVC. (2026). What is DVC? https://dvc.org/doc/user-guide/what-is-dvc

Evidently AI. (2026). Data Drift Documentation. https://docs.evidentlyai.com/metrics/explainer_drift

Feast. (2026). Feast Documentation. https://docs.feast.dev/

Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. y Crawford, K. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), 86-92. https://doi.org/10.1145/3458723

Great Expectations. (2026). Expectations Overview. https://docs.greatexpectations.io/docs/cloud/expectations/expectations_overview/

Hugging Face. (2026). Datasets Documentation. https://huggingface.co/docs/datasets/

lakeFS. (2026). lakeFS Documentation. https://docs.lakefs.io/

Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. y Gebru, T. (2019). Model Cards for Model Reporting. FAT, 220-229. https://doi.org/10.1145/3287560.3287596

OpenLineage. (2026). OpenLineage Documentation. https://openlineage.io/docs/

Pushkarna, M., Zaldivar, A. y Kjartansson, O. (2022). Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI. arXiv. https://arxiv.org/abs/2204.01075

Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F. y Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. NeurIPS. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html

TensorFlow. (2026). ML Metadata. https://tensorflow.github.io/tfx/guide/mlmd/

TensorFlow. (2026). TensorFlow Data Validation. https://www.tensorflow.org/tfx/data_validation/get_started/

Notas

1. Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. y Crawford, K. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), 86-92. https://doi.org/10.1145/3458723 ↩

2. Pushkarna, M., Zaldivar, A. y Kjartansson, O. (2022). Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI. arXiv. https://arxiv.org/abs/2204.01075 ↩

3. Hugging Face. (2026). Datasets Documentation. https://huggingface.co/docs/datasets/. Consultado el 6 de junio de 2026. ↩

4. Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NeurIPS. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html ↩

5. Amershi, S. et al. (2019). Software Engineering for Machine Learning: A Case Study. ICSE-SEIP, 291-300. https://doi.org/10.1109/ICSE-SEIP.2019.00042 ↩

6. Baylor, D. et al. (2017). TFX: A TensorFlow-Based Production-Scale Machine Learning Platform. KDD, 1387-1395. https://doi.org/10.1145/3097983.3098021 ↩

7. Breck, E., Cai, S., Nielsen, E., Salib, M. y Sculley, D. (2017). The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. IEEE Big Data, 1123-1132. https://research.google/pubs/pub46555/ ↩

8. Bitol. (2026). Open Data Contract Standard. https://bitol-io.github.io/open-data-contract-standard/latest/. Consultado el 6 de junio de 2026. ↩

9. TensorFlow. (2026). TensorFlow Data Validation. https://www.tensorflow.org/tfx/data_validation/get_started/. Consultado el 6 de junio de 2026. ↩

10. TensorFlow. (2026). ML Metadata. https://tensorflow.github.io/tfx/guide/mlmd/. Consultado el 6 de junio de 2026. ↩

11. OpenLineage. (2026). OpenLineage Documentation. https://openlineage.io/docs/. Consultado el 6 de junio de 2026. ↩

12. DataHub. (2026). DataHub Documentation. https://docs.datahub.com/. Consultado el 6 de junio de 2026. ↩

13. Great Expectations. (2026). Expectations Overview. https://docs.greatexpectations.io/docs/cloud/expectations/expectations_overview/. Consultado el 6 de junio de 2026. ↩

14. Feast. (2026). Feast Documentation. https://docs.feast.dev/. Consultado el 6 de junio de 2026. ↩

15. Evidently AI. (2026). Data Drift Documentation. https://docs.evidentlyai.com/metrics/explainer_drift. Consultado el 6 de junio de 2026. ↩

16. DVC. (2026). What is DVC?. https://dvc.org/doc/user-guide/what-is-dvc. Consultado el 6 de junio de 2026. ↩

17. lakeFS. (2026). lakeFS Documentation. https://docs.lakefs.io/. Consultado el 6 de junio de 2026. ↩

18. Delta Lake. (2026). Delta Lake Documentation. https://docs.delta.io/. Consultado el 6 de junio de 2026. ↩

19. Apache Iceberg. (2026). Apache Iceberg Documentation. https://iceberg.apache.org/docs/latest/evolution/. Consultado el 6 de junio de 2026. ↩

20. Mitchell, M. et al. (2019). Model Cards for Model Reporting. FAT, 220-229. https://doi.org/10.1145/3287560.3287596 ↩

Capítulo 02: Calidad de datos: schema, duplicados, leakage y etiquetas

Qué deberías poder hacer al terminar

En el capítulo anterior construimos una idea base: un dataset serio no empieza en el modelo, empieza en el contrato. Ahora damos un paso más. Un contrato escrito no sirve de mucho si no se ejecuta. La calidad de datos aparece justo ahí: en convertir el contrato en comprobaciones que puedan aprobar, revisar o bloquear un dataset antes de que llegue al modelo, al RAG o a una evaluación.

Calidad no significa “datos bonitos”. Significa datos suficientemente correctos para la decisión que queremos tomar. Un dataset puede ser aceptable para un prototipo, insuficiente para una evaluación pública, útil para RAG interno y prohibido para entrenamiento. La calidad siempre se lee junto al uso.

Al terminar deberías poder hacer esto:

Resultado de aprendizaje	Evidencia de que lo sabes hacer
Distinguir schema, expectation y contrato.	No confundes “la columna existe” con “el dato es válido”.
Detectar duplicados exactos y cercanos.	Sabes mirar claves repetidas, textos normalizados y similitud.
Explicar leakage con ejemplos de datos.	Puedes detectar cuándo test se contaminó con train o cuándo una feature mira el futuro.
Revisar etiquetas con criterio.	No borras ejemplos difíciles; los llevas a una cola de revisión.
Calcular acuerdo entre anotadores.	Entiendes $p_o$, $p_e$ y $\kappa$.
Diseñar un gate de calidad.	Produces un reporte con pass, review o block.
Conectar calidad con evaluación.	Ves que una métrica puede caer por modelo o por dataset, y sabes separarlo.

La idea central es esta:

La calidad de datos no se inspecciona al final. Se prueba antes de decidir.

La escena: el modelo parece peor, pero el dataset cambió

Imagina que tenemos una eval de soporte académico. Durante semanas el asistente funciona razonablemente bien. Un día, tras cambiar algunos datos, la métrica baja. El primer impulso es pensar que el modelo ha empeorado o que el prompt ya no sirve.

Pero al mirar el dataset aparecen señales menos espectaculares y más importantes: una etiqueta nueva llamada resolve se coló en un catálogo donde solo existían answer, ask_more y escalate; un caso de train aparece casi igual en test; un campo source_id está vacío; una fila de validación lleva licencia de entrenamiento; y dos anotadores no se ponen de acuerdo en varios ejemplos.

Nada de eso requiere cambiar el modelo. Requiere parar la cadena y preguntar: ¿este dataset puede sostener la decisión que estamos tomando? Si no puede, la métrica deja de ser una medida limpia. Se convierte en una mezcla de comportamiento del modelo, fallos de contrato, errores de etiqueta y contaminación entre splits.

Qué no es calidad de datos

Calidad de datos no es “no tener nulos”. Los nulos importan, pero son solo una parte pequeña. Un dataset puede no tener ningún valor vacío y aun así estar mal: etiquetas inconsistentes, licencia incompatible, duplicados entre splits, texto caducado, clases desbalanceadas o columnas con significado ambiguo.

Tampoco es “pasar un script de limpieza”. Limpiar sin contrato puede empeorar el problema. Si borras todos los casos difíciles porque ensucian la métrica, quizá destruyes justo los ejemplos que el sistema necesita aprender o evaluar. Si deduplicas sin mirar splits, puedes eliminar evidencia legítima o dejar contaminación.

Y no es una puntuación universal. La misma tabla puede estar bien para explorar, mal para entrenar y completamente inaceptable para evaluar. Por eso la pregunta correcta no es “¿tiene calidad?”, sino “¿tiene calidad suficiente para este uso, con este contrato y esta fecha de corte?”.

Malentendido	Lectura de ingeniería
“Si no hay nulos, está limpio”.	Faltan catálogo, licencias, duplicados, leakage, etiquetas y linaje.
“Un duplicado siempre se borra”.	Primero hay que saber si es repetición real, evento legítimo o contaminación.
“La etiqueta registrada es verdad”.	La etiqueta es una decisión humana o automática que puede fallar.
“Si la métrica baja, el modelo empeoró”.	Puede haber cambiado el dataset, el split o la distribución.
“Calidad es cosa de datos, no de ingeniería”.	Un gate de calidad es parte del pipeline de software.

Qué sí es calidad de datos para IA

En este libro llamaremos calidad de datos al grado en que un dataset cumple las condiciones necesarias para una decisión de IA: entrenar, evaluar, indexar, recuperar, monitorizar o revisar.

Ejemplo de fórmula: una forma compacta de escribirlo es la siguiente. No es una ley académica cerrada; es una regla de lectura para recordar que la calidad depende del uso previsto.

$$quality(D, u) = schema(D) \land values(D) \land lineage(D) \land license(D, u) \land splits(D, u) \land labels(D, u)$$

Símbolo	Significado	Ejemplo
$D$	Dataset que queremos usar.	Casos de soporte académico.
$u$	Uso previsto.	Evaluación interna, RAG o fine-tuning.
$schema(D)$	El dataset tiene la forma esperada.	Están case_id, split, label, text.
$values(D)$	Los valores respetan catálogos y tipos.	label no contiene resolve si no está permitido.
$lineage(D)$	Cada fila conserva origen y versión.	source_id no está vacío.
$license(D,u)$	El permiso encaja con el uso.	support_eval_only no se usa para entrenamiento.
$splits(D,u)$	Las particiones no contaminan la decisión.	test no repite casos de train.
$labels(D,u)$	Las etiquetas son coherentes con la política.	Dos anotadores no discrepan masivamente.

Esta fórmula no pretende ser una verdad matemática absoluta. Es una forma de recordar que la calidad es una conjunción: si una pieza crítica falla, el dataset no debería avanzar como si nada.

Fecha de corte del estado del arte

Fecha de corte: 6 de junio de 2026.
Fuentes consultadas: TensorFlow Data Validation, Great Expectations, Pandera, Deequ, Cleanlab, Snorkel, scikit-learn y literatura clásica sobre acuerdo entre anotadores.

La idea estable es que la validación de datos debe ser declarativa, reproducible y cercana al pipeline. TensorFlow Data Validation perfila datasets, infiere schema y detecta anomalías contra expectativas.¹ Su referencia de anomalías muestra que un sistema de validación no solo dice “hay error”, sino que clasifica problemas como tipo inválido, dominio inesperado, valor ausente o cambio de distribución.²

Great Expectations organiza la calidad como expectations: afirmaciones verificables sobre columnas, rangos, nulos, formatos o relaciones entre datos.³ Pandera lleva esa misma filosofía al mundo de DataFrames, con schemas programáticos para validar tipos y propiedades de columnas.⁴ Deequ propone “unit tests for data” sobre Spark, una frase muy útil porque acerca la calidad de datos a una práctica que cualquier ingeniero de software reconoce.⁵

Para etiquetas, confident learning propone estimar incertidumbre y errores de etiqueta en datasets, y Cleanlab lo popularizó como herramienta práctica.⁶ El trabajo sobre errores de etiqueta en test sets mostró algo incómodo: incluso benchmarks muy usados pueden contener errores de etiqueta suficientes para desestabilizar conclusiones.⁷

Snorkel es importante porque enseña otra vía: crear datos de entrenamiento con supervisión débil mediante funciones de etiquetado, y después combinar señales ruidosas de forma sistemática.⁸ La lección para este capítulo no es “usa una herramienta concreta”. Es más básica: si una etiqueta puede fallar, la etiqueta también necesita ingeniería.

Las tripas de la calidad: de schema a decisión

La calidad empieza con schema, pero no termina ahí. El schema responde a la forma: qué columnas existen, qué tipos tienen, qué valores son válidos. Después vienen reglas de contenido: nulos, catálogos, rangos, licencias, duplicados, distribución de clases, coherencia entre anotadores y leakage entre splits.

Una expectation sencilla puede escribirse como una función booleana:

$$E_j(D) \in \{0,1\}$$

Símbolo	Significado	Ejemplo
$E_j$	Expectation o check número $j$.	“label pertenece al catálogo permitido”.
$D$	Dataset evaluado.	quality_cases_dirty.csv.
$0$	La regla falla.	Aparece resolve aunque no está permitido.
$1$	La regla pasa.	Todas las etiquetas están en catálogo.

Ejemplo de fórmula: un gate del kit agrupa expectations y les asigna severidad. En otro equipo podrían cambiar los nombres o los umbrales, pero la idea operativa es la misma: no todo fallo pesa igual.

$$gate(D)=s,\quad s\in\{\mathrm{block},\mathrm{review},\mathrm{pass}\}$$

La tabla concreta cuándo devuelve cada estado:

Resultado	Qué significa	Qué haría un equipo
block	Hay fallos que impiden usar el dataset.	No entrenar, no evaluar, no indexar ese snapshot.
review	No hay bloqueo técnico, pero hay dudas que requieren criterio.	Abrir cola de revisión y documentar decisión.
pass	Cumple el contrato actual para el uso declarado.	Usarlo y guardar reporte/versionado.

La parte importante es la palabra “actual”. Un pass no significa que el dataset sea perfecto para siempre. Significa que, bajo este contrato y este uso, no hemos encontrado fallos que impidan avanzar.

Missing y valores fuera de catálogo

El missing se calcula como proporción de celdas vacías sobre las celdas obligatorias:

$$miss(D) = \frac{ \sum_{i=1}^{n} \sum_{c \in C} \mathbb{1}[x_{i,c}=\varnothing] }{ n \cdot |C| }$$

Símbolo	Significado	Ejemplo
$n$	Número de filas.	19 casos.
$C$	Columnas obligatorias.	case_id, source_id, label, text, etc.
$x_{i,c}$	Valor de la columna $c$ en la fila $i$.	source_id de q007.
$\mathbb{1}$	Indicador: 1 si falta, 0 si no.	Vale 1 si source_id está vacío.
$miss(D)$	Tasa total de missing.	0.003096 en el kit.

Un missing bajo puede seguir siendo grave. Si falta una columna secundaria quizá es revisable; si falta source_id, perdemos linaje. Por eso la tasa agregada no basta: hay que mirar qué columna falta y para qué uso era necesaria.

Los valores fuera de catálogo son otra familia de errores. Si label solo permite answer, ask_more y escalate, una etiqueta resolve no es una variación inocente: rompe la semántica del dataset. Quizá representa una nueva clase legítima, pero entonces el contrato debe cambiar y la evaluación debe rehacerse.

Duplicados exactos y duplicados cercanos

Un duplicado exacto puede detectarse normalizando texto:

$$dup_{exact}(a,b) = \mathbb{1}[norm(text_a)=norm(text_b)]$$

Símbolo	Significado	Ejemplo
$a,b$	Dos ejemplos comparados.	q001 y q017.
$norm$	Normalización de texto.	Minúsculas, quitar signos, compactar espacios.
$dup_{exact}$	Indicador de duplicado textual exacto.	1 si el texto normalizado coincide.

Pero muchos duplicados no son idénticos. Cambian una palabra o añaden un adjetivo. Para enseñar la idea sin dependencias externas, el kit usa Jaccard sobre conjuntos de tokens:

$$J(A,B)= \frac{|A \cap B|}{|A \cup B|}$$

Símbolo	Significado	Ejemplo
$A$	Tokens del primer texto.	consulta, documentacion, beca.
$B$	Tokens del segundo texto.	consulta, documentacion, beca, necesaria.
$	A \cap B	$
$	A \cup B	$
$J(A,B)$	Similitud de Jaccard.	0.833333 en un par del kit.

Jaccard no entiende semántica profunda. No sabe que “matrícula” y “inscripción” pueden estar relacionadas. Pero es suficiente para enseñar una idea crítica: si un caso muy parecido aparece en train y test, la evaluación deja de ser limpia.

Leakage entre splits

Leakage no es solo duplicado textual. Es cualquier información que permite al sistema obtener ventaja en evaluación porque ya vio directa o indirectamente la respuesta.

Una tasa básica puede escribirse así:

$$leak(D_{train}, D_{test}) = \frac{ |\{e \in D_{test}: sim(e,D_{train}) \ge \tau\}| }{ |D_{test}| }$$

Símbolo	Significado	Ejemplo
$D_{train}$	Split de entrenamiento.	8 filas en el kit.
$D_{test}$	Split de prueba.	7 filas en el kit.
$e$	Ejemplo de test.	q017 o q019.
$sim$	Función de similitud.	Coincidencia exacta o Jaccard.
$\tau$	Umbral de similitud.	0.82 para duplicado cercano.

En el próximo capítulo entraremos más a fondo en splits y leakage. Aquí basta con una regla operativa: si algo de test está demasiado cerca de train, no uses ese test para decidir si el sistema generaliza.

Distribución de etiquetas

Una etiqueta no es solo un texto. Es una decisión que influye en el aprendizaje o en la evaluación. Por eso conviene mirar proporciones:

$$p(y=k)= \frac{n_k}{n}$$

Símbolo	Significado	Ejemplo
$y$	Etiqueta.	answer, ask_more, escalate.
$k$	Clase concreta.	ask_more.
$n_k$	Número de ejemplos de esa clase.	4 casos.
$n$	Número total de ejemplos.	19 casos.

Si casi todo es answer, el sistema puede aprender a contestar siempre. Si casi no hay escalate, puede parecer correcto hasta que aparece un caso crítico. En clasificación y evaluación, mirar la distribución por split es obligatorio.

Para comparar la distribución global con la de cada split podemos usar distancia total variation:

$$D_{TV}(P,Q)= \frac{1}{2} \sum_i |P_i-Q_i|$$

Símbolo	Significado	Ejemplo
$P_i$	Proporción global de la clase $i$.	Proporción global de answer.
$Q_i$	Proporción de la clase $i$ en un split.	Proporción de answer en test.
$D_{TV}$	Distancia entre distribuciones.	0.172932 para test en el kit.

scikit-learn permite hacer splits estratificados con train_test_split(..., stratify=y) cuando esa estrategia encaja con el problema.⁹ Estratificar no arregla etiquetas malas, pero ayuda a que cada partición conserve una mezcla parecida de clases.

Calidad de etiquetas y acuerdo entre anotadores

Las etiquetas son datos, no dogmas. En el kit aparecen tres señales de revisión: desacuerdo entre anotadores, diferencia con una referencia didáctica y baja confianza de un modelo auxiliar. En un proyecto real no siempre tendrás expected_label, pero sí puedes tener doble anotación, reglas de revisión, muestras auditadas o modelos que prioricen casos dudosos.

El acuerdo observado se calcula así:

$$p_o = \frac{ \sum_{i=1}^{n} \mathbb{1}[a_i=b_i] }{ n }$$

Símbolo	Significado	Ejemplo
$a_i$	Etiqueta del anotador A para el ejemplo $i$.	answer.
$b_i$	Etiqueta del anotador B para el ejemplo $i$.	ask_more.
$p_o$	Proporción de acuerdo observado.	0.789474 en el kit.

Pero parte del acuerdo puede ocurrir por azar, especialmente si una clase domina. Kappa de Cohen corrige ese efecto:¹⁰

$$\kappa = \frac{p_o-p_e}{1-p_e}$$

Símbolo	Significado	Ejemplo
$p_o$	Acuerdo observado.	0.789474.
$p_e$	Acuerdo esperado por azar según distribuciones marginales.	0.518006.
$\kappa$	Acuerdo corregido por azar.	0.563218.

En el kit, $\kappa$ queda por debajo del umbral 0.6, así que no bloquea por sí solo, pero exige revisión. Esta distinción importa: una etiqueta dudosa no siempre se borra; se revisa con política.

Anatomía de un gate de calidad

Severidad: cuándo bloquear, cuándo revisar y cuándo aceptar deuda

Un gate útil no trata todos los fallos igual. Si una etiqueta dudosa y una licencia incompatible aparecen en la misma lista sin severidad, el equipo pierde criterio. La severidad existe para responder a una pregunta muy concreta: ¿qué daño produce avanzar con este fallo?

En ingeniería de IA conviene separar tres niveles. Un fallo bloqueante invalida el uso automático del dataset. Un fallo revisable no permite publicar una decisión todavía, pero sí permite abrir trabajo humano. Una deuda aceptada es un problema conocido que no afecta al uso actual o que tiene un plan explícito de corrección.

Nivel	Pregunta de decisión	Ejemplo	Acción
block	¿Puede invalidar entrenamiento, evaluación, permiso o seguridad del uso?	Leakage entre train y test; licencia incompatible; etiqueta fuera de catálogo.	Detener uso automatizado.
review	¿Necesita criterio humano antes de confiar en la decisión?	Kappa bajo; baja confianza de etiqueta; distribución rara.	Abrir cola de revisión.
accepted_debt	¿Se puede vivir con esto durante una ventana concreta?	Missing en un campo no usado por este modelo.	Documentar owner, fecha y plan.

Esta tabla evita dos extremos. El primero es bloquearlo todo y convertir calidad en un cuello de botella imposible. El segundo es dejar pasar todo porque “ya lo arreglaremos”. La severidad obliga a escribir el riesgo y la acción. Si no puedes explicar por qué algo es block o review, quizá la regla todavía no está bien formulada.

La matriz también debe depender del uso. Un source_id vacío puede ser revisable para exploración local, pero bloqueante para evaluación trazable. Una etiqueta dudosa puede ser tolerable en entrenamiento con millones de ejemplos, pero bloqueante en un test pequeño que decide entre dos modelos. La severidad no vive aislada: vive con el contrato.

SLI, SLO y presupuesto de error de datos

En operación ya vimos que un SLI es un indicador medible, un SLO es un objetivo y el presupuesto de error dice cuánto margen queda antes de actuar. Esa idea encaja muy bien con calidad de datos.

Un SLI de datos mide una propiedad concreta del dataset. Un SLO de datos fija el umbral aceptable. Un presupuesto de error de datos define qué ocurre cuando nos acercamos al límite o lo superamos. No es una frase de marketing: es una herramienta para que el equipo sepa cuándo parar.

SLI de datos	Qué mide	SLO posible	Acción si falla
critical_missing_rate	Missing en columnas críticas.	<= 0.5%	Bloquear snapshot si afecta linaje o etiqueta.
cross_split_duplicates	Duplicados entre splits.	0	Bloquear evaluación.
invalid_catalog_values	Valores fuera de catálogo.	0	Bloquear hasta migrar contrato o datos.
license_mismatches	Uso incompatible con licencia.	0	Bloquear uso automatizado.
annotator_kappa	Acuerdo corregido por azar.	>= 0.6	Abrir revisión de política de anotación.
label_review_queue_size	Casos pendientes de revisar.	<= 2	No cerrar release si supera el umbral.

En el kit, estos objetivos aparecen en:

kit/contracts/quality_slos.json

El presupuesto de error evita discusiones vagas. Por ejemplo: si el SLO exige cero duplicados entre train y test, un solo duplicado consume todo el presupuesto y bloquea. Si el SLO permite hasta dos casos en cola de revisión, un tercero no significa que el dataset sea inútil, pero sí que la release no debería cerrarse sin mirar esos casos.

Ciclo de vida de una incidencia de datos

Detectar un fallo es el principio, no el final. Una incidencia de datos debería tener un ciclo de vida tan claro como una incidencia de software:

1. Detectar: el gate marca un check fallido.
2. Clasificar: se decide severidad, owner y uso afectado.
3. Diagnosticar: se busca causa raíz.
4. Corregir: se cambia dato, contrato, pipeline o política.
5. Reejecutar: se vuelve a correr el gate.
6. Versionar: se guarda snapshot, reporte y decisión.
7. Aprender: se añade un check para que no vuelva a pasar igual.

La causa raíz importa porque no todos los fallos se arreglan tocando el CSV. Si aparece una etiqueta resolve, puede ser un error de anotación, pero también una señal de que el dominio necesita una nueva clase. Si aparece admisiones en product, puede ser un campo mal escrito, o puede ser que el producto haya crecido y el contrato esté viejo. Si baja kappa, quizá los anotadores fallaron, pero quizá la política era ambigua.

Síntoma	Causa raíz posible	Arreglo pobre	Arreglo de ingeniería
Etiqueta nueva	Catálogo real cambió.	Reemplazarla por la clase más parecida.	Versionar contrato y migrar evaluación.
Duplicado entre splits	Split creado después de deduplicar mal.	Borrar una fila sin registro.	Rehacer split desde snapshot limpio.
Kappa bajo	Política de anotación ambigua.	Pedir “más cuidado”.	Añadir casos frontera y regla de desempate.
Licencia incompatible	Export mezcló permisos.	Ignorar en prototipo.	Separar usos permitidos por split.
Missing en linaje	Pipeline perdió metadatos.	Rellenar a mano.	Corregir ingestión y reejecutar.

Esta forma de pensar es muy de ingeniería: no arreglar solo el síntoma, sino el mecanismo que permitió que apareciera.

Schema evolution: cuando el dataset cambia sin pedir permiso

Los datasets vivos cambian. Aparecen columnas, se renombran campos, se añaden etiquetas, se deprecan productos y cambian tipos. Ese cambio no es malo. Lo peligroso es que ocurra sin versión, sin migración y sin compatibilidad.

Schema evolution significa gestionar cambios de forma controlada. En un dataset de IA, no basta con que el código lea la nueva columna. Hay que saber si el significado cambió. Una columna label puede mantener el mismo nombre y cambiar por completo si el equipo añade una política nueva. Un valor resolve puede ser un error hoy y una clase legítima mañana.

Cambio	Riesgo	Estrategia
Nueva columna opcional	Los consumidores antiguos la ignoran.	Añadirla como optional y documentar fecha.
Columna obligatoria nueva	Pipelines antiguos fallan.	Crear versión v2 del contrato y periodo de convivencia.
Nuevo valor de catálogo	Métricas antiguas no comparan igual.	Versionar label set y rehacer splits/evals.
Cambio de tipo	Validación y transformación pueden romper.	Migración explícita con tests de datos.
Cambio de significado	El peor caso: parece compatible, pero no lo es.	Nota de contrato, ejemplos y revisión humana.

Una regla útil: si un cambio altera una decisión, no es un detalle técnico. Es una nueva versión del contrato.

Política de anotación: la etiqueta también necesita contrato

Una etiqueta como answer parece sencilla hasta que aparecen casos frontera. ¿Qué hacemos si falta un dato menor? ¿Y si el usuario mezcla beca y matrícula? ¿Y si el asistente podría responder, pero con riesgo de orientar mal? Sin política, cada anotador inventa su criterio.

El kit incluye una política mínima en:

kit/contracts/annotation_policy.md

Una política de anotación profesional debería incluir:

Pieza	Por qué importa
Definición de cada etiqueta	Evita que dos personas usen palabras iguales con criterios distintos.
Ejemplos positivos	Muestran cuándo sí aplica la etiqueta.
Ejemplos negativos	Muestran cuándo no aplica aunque se parezca.
Casos frontera	Reducen desacuerdo donde el dominio es ambiguo.
Regla de desempate	Permite cerrar conflictos sin improvisar.
Versión de política	Hace trazable qué criterio produjo cada etiqueta.

Esto conecta directamente con kappa. Si el acuerdo es bajo, no siempre significa que los anotadores sean malos. Puede significar que la política no explica los casos difíciles. En ese caso, el siguiente paso no es reetiquetar a ciegas: es mejorar la política y después revisar.

Calidad por segmentos

Una media global puede esconder un problema local. El dataset puede tener buen missing global, pero fallar en becas; buen kappa global, pero mucho desacuerdo en chat; buen reparto de etiquetas, pero ningún caso crítico en test.

Por eso la calidad debería mirarse por segmentos:

Segmento	Pregunta
product	¿Todos los temas tienen cobertura y etiquetas coherentes?
channel	¿Chat, email y portal tienen estilos comparables?
split	¿Train, validation y test mantienen distribuciones razonables?
pii_risk	¿Los casos sensibles tienen controles suficientes?
language	¿La calidad se mantiene si hay varios idiomas?
criticality	¿Los casos de alto impacto están representados y revisados?

Esta idea preparará el capítulo de slices. La intuición es sencilla: un dataset no se rompe siempre “en general”. Muchas veces se rompe en un rincón. La ingeniería consiste en encontrar ese rincón antes de que lo encuentre producción.

Leakage temporal

Hasta ahora hemos hablado de leakage entre splits. Hay otro tipo especialmente traicionero: leakage temporal. Ocurre cuando el dataset usa información que no existía en el momento en que el sistema habría tenido que decidir.

Ejemplos:

Caso	Leakage temporal
Predicción de urgencia	Usar days_to_resolution, que solo se conoce después de cerrar el caso.
RAG académico	Evaluar con un documento actualizado después de la consulta original.
Feature de pagos	Usar un estado de pago corregido días después del evento.
Etiqueta de soporte	Etiquetar con información de resolución posterior y usarla como entrada.

La regla de oro es: para cada feature o documento, pregunta “¿esto estaba disponible en ese momento?”. Si la respuesta es no, quizá sirve para análisis histórico, pero no para entrenar o evaluar una decisión que pretende simular producción.

Esto en un proyecto real

En un equipo de IA, la calidad de datos debería estar cerca de CI. Igual que un cambio de código no debería desplegarse si rompe tests, un snapshot de datos no debería llegar a entrenamiento o evaluación si rompe checks críticos.

La práctica madura tiene cuatro capas:

Capa	Pregunta	Artefacto
Contrato	¿Qué prometen los datos?	JSON, YAML, ODCS, schema programático.
Validación	¿Cumplen lo prometido?	Reporte de checks y anomalías.
Revisión	¿Qué casos requieren criterio?	Cola de etiquetas, duplicados, incidencias.
Decisión	¿Qué hacemos con el snapshot?	pass, review, block y plan de limpieza.

La parte difícil no es escribir if row["label"] not in allowed_labels. Eso lo puede hacer cualquiera. La parte difícil es decidir qué fallos bloquean, cuáles abren revisión y cuáles se aceptan temporalmente con una nota. Ahí aparece la ingeniería: convertir incertidumbre en reglas operativas que un equipo pueda sostener.

En CI/CD, el patrón mínimo sería:

python3 ops/data_quality_gate.py --write
python3 ops/ci_assert_gate.py

Si release_gate.json contiene block, el segundo comando termina con error y el pipeline se detiene. Si el equipo permite releases en review para entornos manuales, podría ejecutarlo con:

python3 ops/ci_assert_gate.py --allow-review

La clave es que el pipeline no decide por intuición. Lee un artefacto. Ese artefacto queda guardado y puede revisarse después.

Por qué debería importarte

Si no revisas calidad, puedes entrenar con etiquetas rotas, evaluar con leakage, elegir un modelo por una métrica falsa o indexar documentos que no debían usarse. Todo eso produce sistemas que parecen funcionar hasta que llegan a producción o hasta que alguien intenta explicar una decisión.

Además, la calidad de datos es una de las formas más baratas de mejorar IA. Cambiar de modelo puede costar dinero, latencia y complejidad. Corregir una etiqueta mal puesta, separar bien splits o bloquear una licencia incompatible puede mejorar la decisión sin tocar arquitectura.

La calidad no compite con el modelado. Lo hace posible.

Manos a la obra

El kit del capítulo está en:

kit/

La práctica trabaja con un dataset deliberadamente problemático. Esto es intencional: si el gate devolviera pass a la primera, aprenderíamos menos. Aquí queremos ver cómo se organiza una revisión real.

Estructura

kit/
  README.md
  data/quality_cases_dirty.csv
  contracts/quality_contract.json
  contracts/quality_slos.json
  contracts/annotation_policy.md
  ops/data_quality_gate.py
  ops/ci_assert_gate.py
  output/quality_report.json
  output/release_gate.json
  output/duplicate_candidates.csv
  output/label_review_queue.csv
  output/clean_actions.md

Cómo lo ejecutas

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/data_quality_gate.py --write
python3 ops/ci_assert_gate.py
cat output/clean_actions.md

No necesita dependencias externas. La idea es que puedas abrir el script, seguir cada check y modificarlo para tu proyecto.

En este dataset, ci_assert_gate.py debe fallar porque el gate es block. Eso no es un error del kit: es el comportamiento esperado. Si un pipeline siguiera adelante con este snapshot, estaría ignorando su propio contrato.

Qué detecta

El gate busca problemas de distinta naturaleza:

Familia	Ejemplo en el kit	Severidad
ID duplicado	q004 aparece dos veces.	block
Valor fuera de catálogo	Producto admisiones.	block
Etiqueta inválida	resolve.	block
PII fuera de contrato	high.	block
Licencia incompatible	Fila de validation con licencia de entrenamiento.	block
Duplicado exacto entre splits	q001 y q017.	block
Duplicado cercano entre splits	q007 y q019 con Jaccard 0.833333.	block
Etiqueta dudosa	q006, q008, q011, q015.	review
Acuerdo bajo	$\kappa=0.563218$.	review

La lectura correcta no es “el dataset es un desastre”. La lectura correcta es: el gate ha convertido una intuición difusa en una lista priorizada. Primero se corrigen bloqueos. Después se revisan etiquetas. Luego se reejecuta.

Además, ahora el kit trae dos contratos complementarios. quality_slos.json traduce salud del dataset a SLI/SLO y presupuesto de error. annotation_policy.md explica cómo deberían decidirse answer, ask_more y escalate. Si la cola de revisión crece, no basta con corregir filas: hay que mirar si la política está incompleta.

Salida esperada

El release_gate.json debería resumir algo así:

{
  "gate": "block",
  "blocking_failures": [
    "case_id_unique",
    "product_values",
    "label_values",
    "pii_risk_values",
    "license_compatibility",
    "exact_cross_split_duplicates",
    "near_cross_split_duplicates"
  ],
  "review_failures": [
    "label_review_queue",
    "annotator_agreement"
  ]
}

Y clean_actions.md debería empezar con una decisión clara: no usar este snapshot de forma automatizada hasta corregir fallos de contrato, leakage y etiquetas.

Cómo lo adaptas a tu caso

Si tu dataset es...	Añade checks
RAG documental	Documento vigente, chunk_id único, fuente recuperable, permiso de indexación.
Fine-tuning	Licencia de entrenamiento, formato de mensajes, revisión de salidas esperadas.
Evaluación	Separación estricta de splits, casos críticos, rúbrica, acuerdo de anotadores.
Agentes	Herramienta permitida, estado inicial, acción final, coste máximo, criterio de parada.
Features	event_time, frescura, rango, consistencia offline/online, leakage temporal.

El patrón es siempre el mismo: escribe el contrato, codifica checks, decide severidades, genera evidencia y reejecuta tras cada cambio.

Si quieres llevarlo a un repositorio real, añade el comando del gate a CI y guarda output/ como artefacto de ejecución. Así una persona revisora no solo ve que el pipeline falló; ve por qué falló y qué casos debe revisar.

Qué entregaría un alumno

1. quality_report.json generado.
2. release_gate.json con decisión.
3. duplicate_candidates.csv revisado.
4. label_review_queue.csv con acciones propuestas.
5. clean_actions.md ampliado con decisiones justificadas.
6. Una modificación al contrato para un caso propio.
7. Una propuesta de SLI/SLO de datos.
8. Una versión de política de anotación con casos frontera.
9. Una explicación corta de por qué un fallo es block y otro es review.

Cómo encaja todo

El capítulo anterior nos dio contrato y linaje. Este capítulo ejecuta ese contrato. El siguiente capítulo se centrará en splits y leakage con más profundidad. Más adelante veremos features, slices, drift y análisis aplicado. La calidad de datos es el puente entre “tengo datos” y “puedo tomar una decisión con ellos”.

graph TD
    subgraph "Este capítulo"
        CONTRACT["Contrato heredado"]
        SCHEMA["Schema y valores"]
        DUP["Duplicados"]
        LEAK["Leakage"]
        LABEL["Etiquetas y acuerdo"]
        GATE["Gate de calidad"]
        EVID["Evidencia"]
    end
    subgraph "Mismo facsímil"
        C01["Datos y linaje<br/>cap. 1"]
        C03["Splits<br/>cap. 3"]
        C04["Features<br/>cap. 4"]
        C05["Slices<br/>cap. 5"]
        C06["DataOps<br/>cap. 6"]
    end
    subgraph "Otros facsímiles"
        EVAL["Evals<br/>fasc. 7"]
        OBS["Observabilidad<br/>fasc. 6"]
        GOV["Gobernanza<br/>fasc. 9"]
    end

    C01 -->|"declara"| CONTRACT
    EVAL -->|"necesita etiquetas"| LABEL
    OBS -->|"aporta casos"| LABEL

    CONTRACT -->|"se ejecuta como"| SCHEMA
    SCHEMA -->|"detecta"| DUP
    DUP -->|"alerta de"| LEAK
    LABEL -->|"se mide con"| GATE
    SCHEMA -->|"alimenta"| GATE
    LEAK -->|"bloquea"| GATE
    GATE -->|"produce"| EVID

    LEAK -->|"se profundiza en"| C03
    SCHEMA -->|"condiciona"| C04
    LABEL -->|"se analiza por"| C05
    EVID -->|"se opera en"| C06
    GATE -->|"deja control para"| GOV

    style CONTRACT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SCHEMA fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DUP fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LEAK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LABEL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style GATE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style EVID fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C01 stroke-dasharray: 5 5
    style C03 stroke-dasharray: 5 5
    style C04 stroke-dasharray: 5 5
    style C05 stroke-dasharray: 5 5
    style C06 stroke-dasharray: 5 5
    style EVAL stroke-dasharray: 5 5
    style OBS stroke-dasharray: 5 5
    style GOV stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición breve
Calidad de datos	Grado en que un dataset cumple el contrato necesario para una decisión concreta.
Schema	Forma esperada de los datos: columnas, tipos, catálogos y reglas.
Expectation	Regla verificable sobre el dataset.
Gate	Decisión automatizada de pass, review o block.
Duplicado exacto	Registro que repite clave o texto normalizado.
Duplicado cercano	Registro muy parecido según una medida de similitud.
Jaccard	Similitud entre conjuntos basada en intersección y unión.
Leakage	Información que contamina entrenamiento, evaluación o tiempo de decisión.
Etiqueta	Clase o salida esperada asociada a un ejemplo.
Ruido de etiqueta	Sospecha de que la etiqueta registrada no sigue la política.
Kappa	Acuerdo entre dos anotadores corregido por azar.
Cola de revisión	Lista priorizada de casos que necesitan criterio humano.
SLI de datos	Indicador medible de salud del dataset.
SLO de datos	Objetivo mínimo aceptable para un indicador de datos.
Presupuesto de error de datos	Margen de fallos tolerables antes de bloquear o revisar.
Schema evolution	Gestión versionada de cambios en columnas, tipos y catálogos.
Leakage temporal	Uso de información que no existía en el momento de decisión.

Dónde solía tropezar yo

Tropiezo	Por qué ocurre	Antídoto
Mirar solo nulos	Es el check más fácil de programar.	Separar schema, catálogo, licencias, duplicados, leakage y etiquetas.
Borrar duplicados sin mirar splits	Parece una limpieza obvia.	Revisar si el duplicado contamina evaluación o representa un evento legítimo.
Tratar una etiqueta como verdad	La columna label da falsa seguridad.	Medir acuerdo, revisar baja confianza y documentar política de anotación.
Mezclar fallos bloqueantes y revisables	Todo se mete en una lista única.	Asignar severidad: block para lo que invalida uso, review para lo que pide criterio.
Celebrar un pass sin contexto	Suena a certificado universal.	Leerlo siempre junto a contrato, uso, fecha y versión del dataset.
Cambiar schema sin versión	El código sigue funcionando y parece compatible.	Versionar contrato si cambia una decisión o significado.
Mirar calidad solo global	Las medias esconden problemas locales.	Revisar por producto, canal, split, sensibilidad e idioma.

Antes de pasar página

Antes de avanzar, deberías poder responder:

1. ¿Por qué calidad de datos no significa solo “sin nulos”?
2. ¿Qué diferencia hay entre schema y expectation?
3. ¿Por qué un valor fuera de catálogo puede bloquear un dataset?
4. ¿Qué diferencia hay entre duplicado exacto y duplicado cercano?
5. ¿Cómo se calcula Jaccard y qué limitación tiene?
6. ¿Por qué un duplicado entre train y test puede contaminar una evaluación?
7. ¿Qué significa que una etiqueta vaya a cola de revisión?
8. ¿Por qué kappa corrige el acuerdo observado?
9. ¿Qué diferencia hay entre block, review y pass?
10. ¿Qué archivo del kit usarías para justificar una decisión ante otra persona?
11. ¿Qué SLI y SLO definirías para duplicados entre splits?
12. ¿Cuándo un cambio de schema exige nueva versión del contrato?
13. ¿Qué problema resuelve una política de anotación?
14. ¿Qué es leakage temporal y por qué no lo detecta siempre un deduplicador?
15. ¿Cómo conectarías el gate de datos a CI/CD?

En resumen

Idea	Qué te llevas
Calidad es calidad para un uso.	No existe un dataset bueno en abstracto.
El schema es el principio.	La forma importa, pero no basta.
Los duplicados pueden contaminar.	Especialmente si cruzan splits.
Leakage rompe la evaluación.	El test deja de medir generalización.
Las etiquetas son datos revisables.	Necesitan política, acuerdo y cola de revisión.
Un gate organiza la decisión.	block, review y pass separan tipos de acción.
La práctica debe dejar evidencia.	Reporte, cola, duplicados y plan de limpieza.
Los SLOs hacen operativa la calidad.	Un indicador sin objetivo no guía una decisión.
El schema evoluciona.	Los cambios de significado necesitan versión y migración.
La calidad se mira por segmentos.	El fallo puede vivir en un producto, canal o split concreto.
CI/CD también sirve para datos.	El pipeline puede bloquear snapshots con evidencia reproducible.

Para saber más

AWS Labs. (2026). Deequ: Unit Tests for Data. https://github.com/awslabs/deequ

Cohen, J. (1960). A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement, 20(1), 37-46. https://doi.org/10.1177/001316446002000104

Great Expectations. (2026). Expectations Overview. https://docs.greatexpectations.io/docs/cloud/expectations/expectations_overview/

Northcutt, C. G., Athalye, A. y Mueller, J. (2021). Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks. NeurIPS Datasets and Benchmarks. https://arxiv.org/abs/2103.14749

Northcutt, C. G., Jiang, L. y Chuang, I. L. (2021). Confident Learning: Estimating Uncertainty in Dataset Labels. Journal of Artificial Intelligence Research, 70, 1373-1411. https://doi.org/10.1613/jair.1.12125

Pandera. (2026). Pandera Documentation. https://pandera.readthedocs.io/en/stable/

Ratner, A., Bach, S. H., Ehrenberg, H., Fries, J., Wu, S. y Ré, C. (2017). Snorkel: Rapid Training Data Creation with Weak Supervision. PVLDB, 11(3), 269-282. https://doi.org/10.14778/3157794.3157797

scikit-learn. (2026). train_test_split. https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.train_test_split.html

TensorFlow. (2026). TensorFlow Data Validation. https://www.tensorflow.org/tfx/data_validation/get_started/

TensorFlow. (2026). TensorFlow Data Validation Anomalies Reference. https://www.tensorflow.org/tfx/data_validation/anomalies

Notas

1. TensorFlow. (2026). TensorFlow Data Validation. https://www.tensorflow.org/tfx/data_validation/get_started/. Consultado el 6 de junio de 2026. ↩

2. TensorFlow. (2026). TensorFlow Data Validation Anomalies Reference. https://www.tensorflow.org/tfx/data_validation/anomalies. Consultado el 6 de junio de 2026. ↩

3. Great Expectations. (2026). Expectations Overview. https://docs.greatexpectations.io/docs/cloud/expectations/expectations_overview/. Consultado el 6 de junio de 2026. ↩

4. Pandera. (2026). Pandera Documentation. https://pandera.readthedocs.io/en/stable/. Consultado el 6 de junio de 2026. ↩

5. AWS Labs. (2026). Deequ: Unit Tests for Data. https://github.com/awslabs/deequ. Consultado el 6 de junio de 2026. ↩

6. Northcutt, C. G., Jiang, L. y Chuang, I. L. (2021). Confident Learning: Estimating Uncertainty in Dataset Labels. Journal of Artificial Intelligence Research, 70, 1373-1411. https://doi.org/10.1613/jair.1.12125 ↩

7. Northcutt, C. G., Athalye, A. y Mueller, J. (2021). Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks. NeurIPS Datasets and Benchmarks. https://arxiv.org/abs/2103.14749 ↩

8. Ratner, A., Bach, S. H., Ehrenberg, H., Fries, J., Wu, S. y Ré, C. (2017). Snorkel: Rapid Training Data Creation with Weak Supervision. PVLDB, 11(3), 269-282. https://doi.org/10.14778/3157794.3157797 ↩

9. scikit-learn. (2026). train_test_split. https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.train_test_split.html. Consultado el 6 de junio de 2026. ↩

10. Cohen, J. (1960). A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement, 20(1), 37-46. https://doi.org/10.1177/001316446002000104 ↩

Capítulo 03: Splits, muestreo y leakage: medir sin engañarse

Qué deberías poder hacer al terminar

El capítulo anterior nos enseñó a bloquear un dataset con fallos de calidad. Pero un dataset puede pasar schema, licencias, etiquetas y duplicados básicos, y aun así medir mal. La razón suele estar en cómo lo partimos.

Un split no es un porcentaje. Es una promesa de evaluación. Cuando decimos train, validation y test, no estamos repartiendo filas al azar como quien reparte cartas. Estamos diciendo qué puede ver el sistema, qué usamos para ajustar decisiones y qué reservamos para comprobar si generaliza.

Al terminar deberías poder hacer esto:

Resultado de aprendizaje	Evidencia de que lo sabes hacer
Explicar para qué sirve cada split.	No usas test para elegir prompt, modelo o umbral.
Elegir estrategia de muestreo según la pregunta.	No haces random split si hay tiempo, grupos o fuentes repetidas.
Detectar leakage por entidad, fuente, texto y tiempo.	Sabes buscar estudiantes, documentos o textos que cruzan splits.
Medir distribución de etiquetas por split.	No celebras un split si test pierde clases críticas.
Comparar estrategias de partición.	Puedes justificar random, estratificado, por grupo, temporal o híbrido.
Construir un manifiesto de split.	Dejas asignaciones y hallazgos versionados.

La frase central del capítulo:

Un split mide una pregunta. Si partes mal, la respuesta parece científica y no lo es.

La escena: una métrica que sube demasiado

Imagina que evaluamos un asistente académico. Hacemos un train/test split aleatorio y obtenemos una métrica preciosa. El sistema responde muy bien sobre matrículas, becas y pagos. Todo parece listo para enseñar.

Luego alguien mira los casos. Un estudiante aparece en train y test. Un documento fuente está repetido en ambos. Una consulta de test es casi igual a una de train. Además, algunos ejemplos de train tienen fecha posterior a ejemplos de test. La métrica no está midiendo generalización: está midiendo familiaridad.

Este es uno de los errores más caros porque no rompe el código. Al contrario: el código funciona, el reporte se ve profesional y la gráfica sube. Justo por eso hay que tratar los splits como ingeniería, no como una llamada rápida a una función.

Qué no es un split

Un split no es “60/20/20 y ya”. Esos números dicen cuántas filas hay, no si la partición responde bien a la pregunta. Si hay varios tickets de la misma persona, un random split puede poner unos en train y otros en test. Si hay documentos con versiones parecidas, puede partir la misma evidencia en dos. Si hay tiempo, puede entrenar con eventos posteriores y evaluar con eventos anteriores.

Tampoco es una garantía automática de independencia. Dos filas distintas pueden compartir entidad, fuente, plantilla, texto, anotador o evento. Para un modelo o un retriever, esa cercanía puede ser suficiente para inflar resultados.

Y test no es un lugar donde mirar muchas veces. Si usamos test para decidir prompts, elegir modelo, ajustar umbrales, cambiar chunking o seleccionar features, test deja de ser una medida final. Se convierte en otra validación, aunque sigamos llamándolo test.

Qué sí es un split de evaluación

Un split es una partición diseñada para responder a una pregunta de generalización:

$$D = D_{train} \cup D_{val} \cup D_{test}$$

con:

$$D_{train} \cap D_{val} \cap D_{test} = \varnothing$$

Símbolo	Significado	Ejemplo
$D$	Dataset completo.	24 casos de soporte.
$D_{train}$	Datos que el sistema puede usar para aprender.	Casos anteriores usados para ajustar.
$D_{val}$	Datos para elegir decisiones durante desarrollo.	Elegir prompt, umbral o estrategia.
$D_{test}$	Datos reservados para medir al final.	Casos no usados para ajustar nada.
$\varnothing$	Intersección vacía.	Ninguna fila debería estar en dos splits.

La intersección vacía de filas es necesaria, pero no suficiente. También necesitamos evitar solapamiento de entidades, fuentes o información temporal cuando esas dimensiones afecten a la pregunta.

Fecha de corte del estado del arte

Fecha de corte: 6 de junio de 2026.
Fuentes consultadas: documentación oficial de scikit-learn sobre train_test_split, GroupKFold, StratifiedGroupKFold y TimeSeriesSplit; literatura sobre leakage en data mining y reproducibilidad de evaluación con machine learning; y el paper original de Retrieval-Augmented Generation para situar por qué, en RAG, documentos y consultas también forman parte de la evaluación.

train_test_split permite partir arrays o matrices en subconjuntos aleatorios de entrenamiento y test, con opciones como test_size, train_size, random_state, shuffle y stratify.¹ Esa función es útil, pero no decide por nosotros si un random split es correcto.

GroupKFold mantiene grupos no solapados entre folds, y StratifiedGroupKFold intenta preservar proporciones de clases sin partir grupos.²³ TimeSeriesSplit trabaja con particiones ordenadas en el tiempo, donde cada train es anterior al test correspondiente.⁴

Kaufman, Rosset, Perlich y Stitelman definieron leakage como la introducción de información sobre el objetivo que no debería estar disponible legítimamente para el modelo, y lo trataron como un error recurrente en proyectos reales y competiciones.⁵ Kapoor y Narayanan revisaron leakage como una fuente importante de problemas de reproducibilidad en ciencia basada en machine learning.⁶

Lewis y colaboradores formalizaron RAG como una combinación de modelo paramétrico y memoria no paramétrica recuperada desde documentos.⁷ Esa idea cambia la conversación sobre splits: no basta con partir preguntas, también hay que controlar documentos, versiones, chunks e índices de recuperación.

La lección estable es esta: las funciones de partición ayudan, pero la garantía viene de entender la estructura del dato.

Estrategias de muestreo

Antes de elegir una estrategia, debemos escribir la pregunta de evaluación. ¿Queremos saber si el sistema generaliza a nuevos casos de las mismas personas? ¿A nuevas personas? ¿A documentos futuros? ¿A otro periodo? ¿A clases raras? Cada pregunta pide un split distinto.

Estrategia	Qué preserva	Qué puede romper
Random por fila	Proporciones aproximadas si hay suficientes datos.	Grupos, fuentes, tiempo y textos cercanos.
Estratificado por etiqueta	Distribución de clases.	Entidades repetidas o tiempo.
Por grupo	Entidades no solapadas.	Distribución de etiquetas o cronología.
Temporal	Simulación de futuro.	Grupos repetidos o clases raras.
Temporal por grupo	Tiempo y entidad a la vez.	Puede dejar alguna distribución en revisión.

No hay estrategia universal. Si todos los casos de una misma persona se parecen, necesitas grupo. Si el producto cambia con el tiempo, necesitas tiempo. Si hay clases muy raras, necesitas mirar cobertura por etiqueta. Si hay documentos comunes, quizá necesitas agrupar por fuente.

Las fórmulas que sí conviene saber

Para medir si los splits conservan etiquetas, podemos comparar proporciones:

$$p_s(y=k)= \frac{n_{s,k}}{n_s}$$

Símbolo	Significado	Ejemplo
$s$	Split.	train, validation, test.
$k$	Etiqueta concreta.	escalate.
$n_{s,k}$	Ejemplos de la etiqueta $k$ en el split $s$.	Casos escalate en test.
$n_s$	Total de ejemplos del split $s$.	5 casos de test.

Para comparar la distribución de un split con la global usamos distancia total variation:

$$D_{TV}(P,Q)= \frac{1}{2} \sum_i |P_i-Q_i|$$

Símbolo	Significado
$P_i$	Proporción global de la clase $i$.
$Q_i$	Proporción de la clase $i$ en el split.
$D_{TV}$	Distancia entre ambas distribuciones.

Para textos cercanos usamos Jaccard, igual que en el capítulo anterior:

$$J(A,B)= \frac{|A \cap B|}{|A \cup B|}$$

Símbolo	Significado
$A$	Tokens del primer texto.
$B$	Tokens del segundo texto.
$	A \cap B
$	A \cup B

Y para leakage temporal podemos mirar si train contiene filas posteriores al primer test:

$$future\_train = \{e \in D_{train}: t(e) > \min(t(D_{test}))\}$$

Símbolo	Significado
$e$	Ejemplo individual.
$t(e)$	Fecha del ejemplo.
$D_{train}$	Split de entrenamiento.
$D_{test}$	Split de prueba.

Si ese conjunto no está vacío en una evaluación temporal, tenemos una señal clara de que la partición no simula futuro.

Tipos de leakage que debe mirar un ingeniero

Leakage no siempre se ve como una fila duplicada. Muchas veces aparece como una relación escondida.

Tipo	Cómo aparece	Qué check ayuda
Por fila	Mismo case_id o mismo texto.	Duplicado exacto.
Por entidad	Misma persona, cliente, documento o dispositivo en train y test.	Group split.
Por fuente	Mismo source_id o versión documental.	Agrupar por fuente.
Por texto cercano	Preguntas casi iguales en splits distintos.	Jaccard, embeddings o revisión.
Temporal	Train ve eventos posteriores a test.	Split temporal.
De preprocesamiento	Escalado, imputación o selección de features hecha con todo el dataset.	Fit solo con train.
De decisión	Test se usa para elegir prompt, modelo o umbral.	Separar validation y test real.

El leakage de preprocesamiento merece una frase aparte. Si calculas la media de una columna con todo el dataset y luego escalas train y test, test ya influyó en train. La solución es sencilla conceptualmente: fit de transformaciones solo en train; transform en validation y test.

El split como contrato de evaluación

En ingeniería conviene dejar de hablar del split como una operación suelta y empezar a tratarlo como un contrato. Un contrato de split responde a preguntas que deberían quedar por escrito:

Pregunta	Respuesta que debe quedar versionada
¿Qué decisión medimos?	Clasificador, RAG, prompt, modelo, retriever, umbral o pipeline completo.
¿Qué estrategia se eligió?	Random, estratificada, por grupo, temporal, temporal por grupo o una combinación propia.
¿Qué claves protegen la independencia?	case_id, student_id, source_id, created_at, label, text.
¿Qué puede hacerse con cada split?	Train entrena, validation decide, test mide, holdout confirma.
¿Qué está prohibido después de mirar test?	Elegir modelo, reescribir prompt, ajustar umbral, cambiar chunking o modificar el retriever.
¿Qué hashes demuestran reproducibilidad?	Hash del dataset, hash de la política y asignaciones por split.

El artefacto que recoge todo eso es el manifiesto de split. En el kit se genera como output/split_manifest.json. Un manifiesto mínimo debería contener:

{
  "policy_id": "support-split-policy-v1",
  "dataset": {
    "sha256": "..."
  },
  "split_contract": {
    "selected_strategy": "time_group_holdout",
    "gate": "review",
    "keys": {
      "group": "student_id",
      "source": "source_id",
      "time": "created_at"
    }
  }
}

El hash no es decoración. Si cambias una fila, una etiqueta o una fecha, el hash del dataset cambia. Si cambias una regla de la política, el hash de la política cambia. Eso permite reconstruir qué se midió, con qué reglas y por qué la métrica era defendible en ese momento.

En un equipo real, el manifiesto evita discusiones imposibles semanas después. Si alguien pregunta “¿por qué aquella métrica bajó al repetir el experimento?”, no deberíamos responder mirando una gráfica suelta. Deberíamos poder abrir el manifiesto, comprobar el hash del dataset, ver qué política estaba activa, saber qué estrategia asignó cada case_id y revisar si test se usó solo para medir o también para decidir. Esa diferencia parece administrativa, pero es ingeniería: sin trazabilidad, una métrica deja de ser una medida y se convierte en una anécdota difícil de reproducir.

El manifiesto también ayuda a integrar evaluación en CI/CD. Puedes bloquear una ejecución si cambia el hash del dataset sin regenerar el split, si falta una predicción para un caso de test, si validation o test se usan para hacer fit de un transformador, o si una política nueva modifica los umbrales sin actualizar la decisión. En proyectos de IA, muchas regresiones no vienen de una línea de modelo, sino de una línea de datos que cambió sin que nadie la registrara.

Ejemplo de fórmula: para este facsímil podemos pensar el manifiesto de split así. No es una especificación estándar; es una forma compacta de recordar qué debe quedar versionado para que la evaluación sea reproducible.

$$M = (h_D, h_P, S, A, G)$$

Símbolo	Significado
$M$	Manifiesto de split.
$h_D$	Hash del dataset.
$h_P$	Hash de la política de split.
$S$	Estrategia elegida.
$A$	Asignación de IDs a train, validation y test.
$G$	Resultado del gate: pass, review o block.

La métrica sin manifiesto es débil. Puede estar bien, pero no sabemos repetirla ni auditarla.

Leakage de preprocesamiento

Una fuga clásica no aparece en el split, sino en el pipeline. Suele pasar cuando hacemos esto:

1. Cargar todo el dataset.
2. Normalizar, imputar, seleccionar variables o crear vocabulario.
3. Partir en train, validation y test.
4. Entrenar y medir.

El problema está en el paso 2. Si una transformación aprende algo del dataset completo, validation y test ya han participado en el entrenamiento, aunque el modelo principal no los haya visto.

La versión correcta es:

$$\theta_T = fit(T, D_{train})$$ $$X'_s = transform(T_{\theta_T}, X_s), \quad s \in \{train, val, test\}$$

Símbolo	Significado
$T$	Transformación: escalado, imputación, PCA, vectorizador, calibrador.
$\theta_T$	Parámetros aprendidos por la transformación.
$D_{train}$	Datos usados para aprender esos parámetros.
$X_s$	Features originales del split $s$.
$X'_s$	Features transformadas del split $s$.

La regla práctica:

Transformación	Qué aprende	Dónde se hace fit	Qué se aplica a validation/test
Normalización	Media, desviación, mínimos o máximos.	Solo train.	transform con parámetros de train.
Imputación	Media, moda, percentil o modelo auxiliar.	Solo train.	Relleno con reglas aprendidas en train.
Selección de features	Variables que parecen predictivas.	Solo train, o dentro de cada fold.	Mismas features elegidas.
PCA	Componentes y proyección.	Solo train.	Misma proyección.
TF-IDF	Vocabulario e IDF.	Solo train.	Misma matriz de vocabulario.
Oversampling	Ejemplos sintéticos o pesos.	Solo train.	Nunca se sintetiza test.

La frase que debería quedar pegada a la pantalla: primero partes, luego aprendes transformaciones.

En el kit, esta idea se convierte en un script ejecutable: ops/preprocessing_fit_audit.py. El script no entrena un modelo grande; hace algo más pequeño y muy útil para aprender: compara el vocabulario que obtendrías si ajustas un vectorizador con solo train frente al vocabulario que obtendrías usando todo el dataset. Si el vocabulario global aprende palabras que solo aparecen en validation o test, acabas de demostrar una fuga de preprocesamiento con un ejemplo que cabe en una terminal.

Por ejemplo, con el split recomendado del kit, el vectorizador ajustado solo con train no conoce algunos términos que aparecen en test, como convocatoria, abonado, confirmacion o bloqueada. Eso es normal: test representa futuro o datos reservados. Si ajustas el vectorizador con todo el dataset antes de partir, esas palabras entran en el vocabulario desde el principio. El modelo todavía no ha visto la etiqueta de test, pero su representación ya fue preparada con información del test. En texto, ese detalle es importante porque vocabulario, IDF, normalizadores y reglas de tokenización forman parte de lo que el sistema aprende.

Puedes ejecutarlo así:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/split_audit.py --write
python3 ops/preprocessing_fit_audit.py --write
cat output/preprocessing_fit_decision.md

La salida no pretende decir “este vocabulario es malo”. Dice algo más concreto: si quieres medir honestamente, el fit del vectorizador debe ocurrir después del split y solo con train. Luego aplicas ese mismo vectorizador a validation y test. Ese patrón se traslada igual a StandardScaler, imputadores, PCA, selección de features, calibración, oversampling o cualquier transformación que aprenda parámetros.

RAG y LLM eval también tienen splits

En un clasificador tabular, solemos pensar en filas. En RAG y evaluación de LLMs hay más piezas:

Objeto	Por qué puede contaminar la evaluación
Documento	El mismo documento puede generar chunks, preguntas y respuestas en varios splits.
Chunk	Dos chunks hermanos pueden contener casi la misma evidencia.
Pregunta sintética	Si se genera desde un documento, hereda su grupo.
Respuesta esperada	Si acaba en trazas de desarrollo, el test deja de ser final.
Prompt few-shot	Ejemplos demasiado parecidos al test facilitan la tarea artificialmente.
Índice de recuperación	Si mezcla corpus de desarrollo y test, la medición no separa conocimiento.
Herramientas y trazas	Logs de ejecución pueden contener soluciones, IDs o rutas documentales.

Para RAG, la regla no debería ser “parto preguntas”. Debería ser:

$$g(d_i) = g(d_j) \Rightarrow split(d_i) = split(d_j)$$

Símbolo	Significado
$d_i, d_j$	Documentos, chunks o preguntas derivadas.
$g(\cdot)$	Grupo documental: document_id, source_id, versión o URL canónica.
$split(\cdot)$	Partición asignada.

Si dos chunks vienen del mismo documento, no deberían terminar uno en train y otro en test salvo que la evaluación esté diseñada explícitamente para medir recuperación sobre documentos compartidos. Y si ese caso existe, debe declararse, porque ya no estamos midiendo generalización documental.

En evaluación de LLMs hay otra trampa: mirar fallos de test para mejorar el prompt. La primera vez puede ser análisis. La segunda empieza a parecer ajuste. Si cambiamos el prompt, el modelo, el formato de salida, el sistema de herramientas o la rúbrica porque vimos test, test ya no es final. Necesitamos validation o un nuevo holdout.

Un ejemplo operativo: supón que tienes 200 preguntas para evaluar un RAG de normativa universitaria. Si generas 100 preguntas desde un documento de becas y luego repartes esas preguntas al azar, algunas acabarán en train, otras en validation y otras en test. El modelo o el equipo no ven exactamente la misma pregunta, pero sí ven el mismo documento, los mismos términos y a veces la misma respuesta escrita de otra manera. Para medir generalización documental, eso no vale. El grupo no debería ser la pregunta: debería ser el documento, la versión del documento o la fuente canónica.

Otro caso frecuente: usas ejemplos few-shot en el prompt. Esos ejemplos también tienen que salir de train o validation, no del test. Si al mirar el test descubres que el modelo falla en “matrícula bloqueada” y copias un ejemplo parecido al prompt, has convertido el test en una herramienta de ajuste. La práctica correcta no es dejar de aprender del error; es mover esa decisión a validation y reservar un nuevo holdout si quieres comunicar una cifra final.

Validación cruzada avanzada

La validación cruzada no arregla por sí sola un split mal pensado. Solo repite una regla de partición varias veces. Si la regla parte grupos o mezcla futuro, el problema se repite en cada fold.

Método	Cuándo sirve	Riesgo si se usa sin pensar
KFold	Datos independientes y suficientes.	Parte entidades repetidas.
StratifiedKFold	Clasificación con clases desbalanceadas.	Conserva etiquetas, pero puede mezclar grupos.
GroupKFold	Hay usuarios, estudiantes, clientes, pacientes, documentos o dispositivos.	Puede dejar folds con etiquetas descompensadas.
StratifiedGroupKFold	Necesitas grupos no compartidos y proporciones de clases razonables.	No siempre puede satisfacer ambas cosas si el dataset es pequeño.
TimeSeriesSplit	Evaluación hacia futuro.	No protege entidades repetidas por sí solo.
Validación cruzada anidada	Separar selección de hiperparámetros y estimación final.	Es más cara y exige disciplina con pipelines.

La validación cruzada anidada se usa cuando queremos seleccionar hiperparámetros sin engañar la estimación. La idea:

$$CV_{outer} \rightarrow \hat{R}$$ $$CV_{inner} \rightarrow \lambda^*$$

Símbolo	Significado
$CV_{outer}$	Bucle externo que estima rendimiento.
$CV_{inner}$	Bucle interno que elige configuración dentro de cada train externo.
$\hat{R}$	Estimación de rendimiento.
$\lambda^*$	Hiperparámetros elegidos.

Si usas el mismo fold para elegir y medir, el resultado tiende a ser optimista. No porque nadie haya hecho nada extraño, sino porque el proceso de selección ya miró esa señal.

Negativos difíciles, ranking y recuperación

En RAG, ranking y clasificación semántica, los ejemplos negativos importan mucho. Un negativo fácil es un caso claramente distinto. Un negativo difícil es uno que se parece mucho al positivo pero requiere distinguir un detalle.

Caso	Positivo	Negativo difícil
Beca	“requisitos de beca general”	“requisitos de beca de movilidad”
Pago	“justificante de pago pendiente”	“pago duplicado reclamado”
Matrícula	“plazo ordinario de matrícula”	“ampliación de matrícula fuera de plazo”

Los negativos difíciles enseñan y evalúan mejor, pero también pueden contaminar si se generan mezclando splits. La regla operativa:

1. Si generas negativos antes de partir, agrupa por entidad y fuente para que no crucen splits.
2. Si generas negativos después de partir, hazlo dentro de cada split.
3. Si usas embeddings para buscar negativos, no uses el índice de test para seleccionar ejemplos de train.
4. Si ajustas un reranker, mide con consultas y documentos que no hayan participado en su selección.

Para un retriever, una evaluación mínima debería reportar:

Métrica	Qué pregunta responde
recall@k	¿El documento correcto aparece entre los $k$ primeros?
MRR	¿A qué altura aparece el primer resultado útil?
Precisión de contexto	¿Cuánto contexto recuperado es realmente relevante?
Cobertura por fuente	¿El sistema recupera bien todos los tipos de documento?
Latencia	¿La recuperación cabe en el presupuesto operativo?

Este punto prepara el capítulo de embeddings y los capítulos de RAG: la evaluación de recuperación también empieza por un split honesto.

Tamaño mínimo, intervalos y slices

Un test pequeño puede ser honesto y aun así poco informativo. Si medimos accuracy con 20 ejemplos, pasar de 15 a 16 aciertos cambia la métrica de 75% a 80%. Eso no es una mejora estable; puede ser ruido muestral.

Una aproximación rápida para una proporción es:

$$SE(\hat{p}) = \sqrt{\frac{\hat{p}(1-\hat{p})}{n}}$$ $$IC_{95} \approx \hat{p} \pm 1.96 \cdot SE(\hat{p})$$

Símbolo	Significado
$\hat{p}$	Métrica como proporción: accuracy, tasa de acierto, recall binario.
$n$	Número de ejemplos del test.
$SE$	Error estándar aproximado.
$IC_{95}$	Intervalo de confianza aproximado al 95%.

Ejemplo: si $\hat{p}=0.80$ y $n=25$, entonces:

$$SE \approx \sqrt{\frac{0.8 \cdot 0.2}{25}} = 0.08$$

El intervalo aproximado sería $0.80 \pm 0.16$. Es decir, el test dice algo, pero todavía no permite presumir precisión quirúrgica. Para métricas más complejas, bootstrap suele ser una opción práctica: remuestrear el test muchas veces y observar la distribución de la métrica.

Además de mirar la media global, hay que mirar slices. Un sistema puede tener buen resultado global y fallar justo en el segmento que importa.

Slice	Por qué mirarlo
product	Matrícula, becas, pagos, horarios o prácticas pueden tener dificultad distinta.
channel	Portal, email y chat no generan el mismo lenguaje.
label	Las clases raras suelen desaparecer en tests pequeños.
source_id	Algunas fuentes documentales son más ambiguas.
Fecha	Cambios de periodo pueden alterar vocabulario y reglas.
Criticidad	No todos los errores cuestan lo mismo.
Idioma o región	Si existen, pueden cambiar distribución y estilo.

La pregunta técnica no es solo “¿cuánto acierta?”. También es: “¿dónde falla, con cuánta evidencia y qué decisión puedo tomar sin engañarme?”.

El segundo script práctico del kit trabaja justo esta parte: ops/evaluate_test_slices.py. Lee data/model_predictions.csv, toma del manifiesto los IDs asignados a test y evalúa solo esos casos. Esto es importante: no deja que se cuele una predicción de train o validation en la métrica final. Después calcula accuracy, intervalo aproximado, latencia y slices por product, channel y label.

Con el dataset pequeño del capítulo, el resultado esperado es deliberadamente incómodo: accuracy de 0.75 con solo 4 casos de test, un fallo en el caso s023 y una decisión review_test_too_small. Eso enseña una lección que muchos proyectos aprenden tarde: una métrica global puede sonar bien y seguir sin ser suficiente para tomar una decisión fuerte. Si el único caso escalate del test falla, la media global no cuenta toda la historia. Si cada producto tiene un único ejemplo, ningún slice tiene evidencia suficiente. El reporte no bloquea por capricho; te obliga a mirar la métrica con tamaño, contexto y coste del error.

Puedes ejecutarlo así:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/evaluate_test_slices.py --write
cat output/evaluation_slice_decision.md
python3 -m json.tool output/evaluation_slice_report.json

Este ejemplo sí se puede reutilizar. Cambias data/model_predictions.csv por las predicciones de tu modelo, mantienes case_id, predicted_label, confidence y latency_ms, y el script usa el manifiesto para decidir qué pertenece a test. Si tu proyecto mide otra cosa, cambias la función de métrica, pero mantienes el contrato: IDs versionados, split congelado, slices explícitos y decisión documentada.

Política de test y holdout final

La política sencilla:

Split	Permiso
Train	Aprender.
Validation	Elegir.
Test	Medir una decisión cerrada.
Holdout final	Confirmar una conclusión importante.

Cuando test se usa para decidir, deja de ser test final. En un proyecto real eso no debería vivirse como culpa, sino como trazabilidad: se anota y se crea una nueva partición final si hace falta.

Un ejemplo concreto:

1. Entrenas tres modelos con train.
2. Eliges el mejor con validation.
3. Mides una vez con test.
4. Ves que falla en “becas”.
5. Cambias el prompt, el chunking o el retriever.
6. La siguiente medición ya no debería venderse como test puro.

La solución profesional es reservar un holdout final para decisiones importantes o crear una nueva versión de evaluación. No siempre hace falta en un ejercicio pequeño; sí hace falta cuando vas a comunicar rendimiento, comparar sistemas o tomar una decisión con impacto.

Anatomía de una partición que no se engaña

Esto en un proyecto real

Un equipo profesional debería discutir el split antes de mirar resultados. Si elegimos estrategia después de ver métricas, ya estamos contaminando la decisión. La pregunta correcta es: “¿qué uso real queremos simular?”.

Situación	Split razonable	Por qué
Tickets de los mismos clientes	Por cliente o cuenta.	Evita que el sistema vea estilos repetidos.
Documentación viva	Temporal por versión.	Evalúa contra futuro documental.
Datasets médicos o académicos por persona	Por sujeto o estudiante.	Evita que la misma entidad cruce particiones.
Clases raras	Estratificado con revisión manual.	Evita perder casos críticos en test.
Logs de producto	Temporal.	Simula despliegue hacia adelante.

La regla profesional: si una entidad puede generar varias filas parecidas, no partas por fila hasta demostrar que no contamina.

Por qué debería importarte

Una mala partición puede hacer que un modelo mediocre parezca excelente. También puede hacer que un modelo bueno parezca inestable si el test no cubre clases importantes. En ambos casos, la decisión técnica se apoya en una medición defectuosa.

Este capítulo importa porque casi todo lo que sigue depende de aquí: features, embeddings, slices, drift, análisis causal y gobernanza. Si test no es honesto, los capítulos posteriores están midiendo sobre una base torcida.

Manos a la obra

El kit del capítulo está en:

kit/

Compara cinco estrategias sobre el mismo dataset:

Estrategia	Qué intenta	Resultado esperado en el kit
random_row	Repartir filas con orden pseudoaleatorio estable.	block.
stratified_label	Conservar proporción de etiquetas.	block.
group_holdout	No partir estudiantes.	block.
time_cutoff	Respetar cronología.	block.
time_group_holdout	Combinar tiempo y grupos.	review.

Estructura

kit/
  README.md
  data/model_predictions.csv
  data/support_split_cases.csv
  contracts/evaluation_use_policy.md
  contracts/preprocessing_policy.json
  contracts/rag_llm_eval_policy.json
  contracts/split_policy.json
  ops/evaluate_test_slices.py
  ops/preprocessing_fit_audit.py
  ops/split_audit.py
  output/evaluation_slice_decision.md
  output/evaluation_slice_report.json
  output/preprocessing_fit_decision.md
  output/preprocessing_fit_report.json
  output/split_manifest.json
  output/split_report.json
  output/strategy_comparison.csv
  output/leakage_findings.csv
  output/split_assignments.csv
  output/split_decision.md

Cómo lo ejecutas

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/split_audit.py --write
cat output/split_decision.md
python3 -m json.tool output/split_manifest.json
python3 ops/preprocessing_fit_audit.py --write
cat output/preprocessing_fit_decision.md
python3 ops/evaluate_test_slices.py --write
cat output/evaluation_slice_decision.md

Qué deberías ver

La estrategia recomendada debería ser time_group_holdout, pero con gate review. Esto es importante: la estrategia evita leakage fuerte por grupo, fuente, texto y tiempo, pero deja una revisión por distribución de etiquetas. No todo se arregla automáticamente.

{
  "chosen_strategy": "time_group_holdout",
  "recommendation": "revisar label_distribution_shift"
}

En output/split_manifest.json deberías ver cuatro cosas especialmente importantes:

Campo	Por qué importa
dataset.sha256	Si cambia el dataset, cambia la medición.
policy.sha256	Si cambia la política, cambia el contrato.
split_contract.keys	Explica qué claves protegen grupos, fuentes, tiempo y etiquetas.
assignments_by_split	Permite reconstruir qué casos estaban en train, validation y test.

Después, output/preprocessing_fit_decision.md debería bloquear el fit con todo el dataset. La lectura útil no es memorizar los términos concretos del ejemplo, sino entender el patrón: si una transformación aprende parámetros con validation o test, la evaluación queda preparada con información reservada.

Por último, output/evaluation_slice_decision.md debería dejar la evaluación en revisión por tamaño de test. Verás una accuracy global de 0.75, pero también un fallo en s023, slices con una sola muestra y un intervalo demasiado ancho para vender una conclusión fuerte. Eso es exactamente lo que queremos que aprenda un alumno: una evaluación seria no solo imprime una métrica, también dice cuánto puedes fiarte de ella.

Cómo lo adaptas a tu caso

Si tu problema tiene...	Añade al contrato
Clientes repetidos	group_field: customer_id.
Documentos versionados	source_group: document_id y version_date.
Tiempo crítico	Ventanas temporales y fecha mínima de test.
Clases raras	Labels obligatorias en validation y test.
Transformaciones	Regla de fit solo con train.
RAG	Prohibir que chunks del mismo documento crucen splits.
Evaluaciones de LLM	Separar prompt, ejemplos few-shot, rúbrica y respuestas esperadas.
Ranking o retriever	Generar negativos difíciles sin cruzar splits.
Métricas públicas	Holdout final o nueva versión de evaluación.

Qué entregaría un alumno

1. split_report.json generado.
2. strategy_comparison.csv explicado.
3. leakage_findings.csv revisado.
4. split_manifest.json con hashes y asignaciones.
5. split_decision.md con decisión propia.
6. preprocessing_fit_report.json y decisión de preprocesado.
7. evaluation_slice_report.json y lectura por slices.
8. Una regla de preprocesado que demuestre fit solo con train.
9. Una propuesta de split para un dataset real, justificando grupos, tiempo, RAG si aplica y cobertura.

Cómo encaja todo

Este capítulo conecta calidad de datos con evaluación. El capítulo 02 detectaba fallos dentro del dataset; este capítulo pregunta si la partición permite medir sin engañarse. El capítulo 04 usará estos splits para hablar de features y embeddings: ahí veremos que una transformación también puede introducir leakage si se ajusta con todo el dataset.

graph TD
    subgraph "Este capítulo"
        Q["Pregunta de evaluación"]
        CONTRACT["Contrato de split"]
        UNIT["Unidad y muestreo"]
        LEAK["Leakage"]
        FIT["Fit solo con train"]
        MANIFEST["Split manifest"]
        DEC["Decisión de split"]
        HOLD["Holdout final"]
    end
    subgraph "Mismo facsímil"
        C01["Datos y linaje<br/>cap. 1"]
        C02["Calidad<br/>cap. 2"]
        C04["Features<br/>cap. 4"]
        C05["Slices<br/>cap. 5"]
        C06["DataOps<br/>cap. 6"]
    end
    subgraph "Otros facsímiles"
        RAG["RAG<br/>fasc. 4"]
        EVAL["Evals<br/>fasc. 7"]
        GOV["Gobernanza<br/>fasc. 9"]
    end

    C01 -->|"declara campos"| CONTRACT
    C02 -->|"bloquea datos rotos"| CONTRACT
    EVAL -->|"necesita test honesto"| DEC

    Q -->|"se escribe en"| CONTRACT
    CONTRACT -->|"elige"| UNIT
    UNIT -->|"puede introducir"| LEAK
    LEAK -->|"obliga a"| FIT
    FIT -->|"se registra en"| MANIFEST
    UNIT -->|"se registra en"| MANIFEST
    MANIFEST -->|"sostiene"| DEC
    DEC -->|"reserva"| HOLD

    FIT -->|"protege"| C04
    UNIT -->|"se revisa por"| C05
    MANIFEST -->|"se monitoriza en"| C06
    MANIFEST -->|"prepara evaluación RAG"| RAG
    HOLD -->|"cierra afirmaciones"| EVAL
    MANIFEST -->|"documenta"| GOV

    style Q fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CONTRACT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style UNIT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LEAK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style FIT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MANIFEST fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DEC fill:#F5F5F5,stroke:#000000,stroke-width:2
    style HOLD fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C01 stroke-dasharray: 5 5
    style C02 stroke-dasharray: 5 5
    style C04 stroke-dasharray: 5 5
    style C05 stroke-dasharray: 5 5
    style C06 stroke-dasharray: 5 5
    style RAG stroke-dasharray: 5 5
    style EVAL stroke-dasharray: 5 5
    style GOV stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición breve
Split	Partición de un dataset con finalidad concreta.
Train	Split que puede usarse para aprender o ajustar.
Validation	Split para elegir decisiones durante desarrollo.
Test	Split reservado para medir al final.
Holdout	Conjunto separado que no se usa durante ajuste.
Estratificación	Mantener proporciones de etiquetas o segmentos.
Split por grupo	Mantener todas las filas de una entidad juntas.
Split temporal	Respetar orden cronológico.
Leakage	Información indebida que contamina la evaluación.
Purga	Separar o retirar ejemplos demasiado cercanos.
Distancia TV	Medida de diferencia entre distribuciones.
Manifiesto de split	Documento técnico con hashes, estrategia, claves, permisos y asignaciones.
Leakage de preprocesamiento	Fuga causada por transformaciones ajustadas antes de partir o usando splits reservados.
RAG leakage	Fuga en documentos, chunks, preguntas, respuestas esperadas, prompts o índices.
Negativo difícil	Ejemplo muy parecido al positivo, pero con etiqueta o respuesta distinta.
Holdout final	Partición reservada para confirmar una conclusión después de cerrar decisiones.
Slice	Subconjunto relevante del test: producto, canal, etiqueta, fuente, fecha o criticidad.
Error estándar	Estimación de cuánto puede variar una métrica por tamaño de muestra.

Dónde solía tropezar yo

Tropiezo	Por qué ocurre	Antídoto
Confundir porcentaje con validez	60/20/20 parece profesional.	Preguntar qué decisión simula cada split.
Estratificar y olvidarme de grupos	Las clases quedan bonitas.	Revisar student_id, cliente, fuente o documento.
Hacer split después de transformar	El pipeline parece más cómodo.	Separar primero; ajustar transformaciones solo en train.
Mirar test demasiadas veces	Es tentador ajustar contra la métrica final.	Usar validation para decisiones y test para cierre.
Ignorar el tiempo	Random parece estable.	Usar split temporal si producción será futura.
Partir preguntas RAG sin agrupar documentos	Parece que cada pregunta es independiente.	Agrupar por documento, versión, fuente o URL canónica.
Hacer negativos difíciles con todo el índice	Sale una evaluación más dura, pero mezclada.	Generarlos dentro de cada split o con grupos congelados.
No guardar manifiesto	El reporte parece suficiente.	Versionar hashes, política, estrategia e IDs por split.
Celebrar una métrica con test pequeño	El número tiene demasiada varianza.	Acompañar con tamaño, intervalo y slices.

Antes de pasar página

Antes de avanzar, deberías poder responder:

1. ¿Por qué un split no es solo un porcentaje?
2. ¿Qué diferencia hay entre train, validation y test?
3. ¿Cuándo usarías split por grupo?
4. ¿Cuándo usarías split temporal?
5. ¿Por qué una estrategia estratificada puede seguir contaminada?
6. ¿Qué mide Jaccard en el kit?
7. ¿Qué significa future_train_vs_test?
8. ¿Por qué time_group_holdout queda en review y no en pass?
9. ¿Qué archivo del kit explica los hallazgos de leakage?
10. ¿Cómo evitarías leakage de preprocesamiento?
11. ¿Por qué un documento RAG puede contaminar varias preguntas?
12. ¿Qué pasa si miras test para cambiar el prompt?
13. ¿Qué diferencia hay entre validation, test y holdout final?
14. ¿Qué debería guardar un split_manifest.json?
15. ¿Cuándo usarías StratifiedGroupKFold en vez de KFold?
16. ¿Por qué una métrica global puede esconder fallos por slice?
17. ¿Qué te dice el error estándar cuando el test es pequeño?
18. ¿Qué demuestra preprocessing_fit_audit.py?
19. ¿Por qué evaluate_test_slices.py filtra por IDs del manifiesto?
20. ¿Qué cambiarías en model_predictions.csv para usarlo con tu propio modelo?

En resumen

Idea	Qué te llevas
Un split mide una pregunta.	La estrategia depende del uso real.
Random no siempre es inocente.	Puede mezclar grupos, fuentes y tiempo.
Estratificar no basta.	Conserva labels, pero no protege entidades.
El tiempo cambia la evaluación.	Entrenar con futuro infla resultados.
La mejor estrategia puede quedar en review.	Evitar leakage no garantiza cobertura perfecta.
El split debe versionarse.	Asignaciones, hallazgos y decisión son artefactos.
Preprocesar también aprende.	Todo fit que aprende parámetros debe usar train.
RAG añade nuevas fronteras.	Documentos, chunks, prompts y respuestas esperadas también se separan.
Test no decide.	Si test decide, necesitas validation nueva o holdout final.
Los negativos difíciles se controlan.	Son útiles, pero deben respetar grupos y particiones.
El tamaño importa.	Un test pequeño necesita intervalo, cautela y lectura por slices.
Los ejemplos deben ejecutarse.	El kit genera reportes de split, preprocesado y evaluación por slices.

Para saber más

Kapoor, S. y Narayanan, A. (2023). Leakage and the Reproducibility Crisis in Machine-Learning-Based Science. Patterns, 4(9), 100804. DOI

Kaufman, S., Rosset, S., Perlich, C. y Stitelman, O. (2012). Leakage in Data Mining: Formulation, Detection, and Avoidance. ACM Transactions on Knowledge Discovery from Data, 6(4), 1-21. DOI

Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W., Rocktäschel, T., Riedel, S. y Kiela, D. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. Paper

scikit-learn. (2026). GroupKFold

scikit-learn. (2026). StratifiedGroupKFold

scikit-learn. (2026). TimeSeriesSplit

scikit-learn. (2026). train_test_split

Notas

1. scikit-learn. (2026). train_test_split. Documentación oficial. Consultado el 6 de junio de 2026. ↩

2. scikit-learn. (2026). GroupKFold. Documentación oficial. Consultado el 6 de junio de 2026. ↩

3. scikit-learn. (2026). StratifiedGroupKFold. Documentación oficial. Consultado el 6 de junio de 2026. ↩

4. scikit-learn. (2026). TimeSeriesSplit. Documentación oficial. Consultado el 6 de junio de 2026. ↩

5. Kaufman, S., Rosset, S., Perlich, C. y Stitelman, O. (2012). Leakage in Data Mining: Formulation, Detection, and Avoidance. ACM Transactions on Knowledge Discovery from Data, 6(4), 1-21. DOI. ↩

6. Kapoor, S. y Narayanan, A. (2023). Leakage and the Reproducibility Crisis in Machine-Learning-Based Science. Patterns, 4(9), 100804. DOI. ↩

7. Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. Paper. ↩

Capítulo 04: Features y representaciones: de tablas a embeddings

Qué deberías poder hacer al terminar

En el capítulo anterior congelamos una partición honesta. Ahora toca una pregunta igual de importante: ¿qué entra realmente al modelo? Un dataset no se convierte solo en inteligencia por estar en una tabla. Hay que transformar fechas, categorías, texto y metadatos en números que una función pueda operar.

Ese paso se llama representación. A veces es tan sencillo como convertir email en una columna binaria. A veces implica normalizar una fecha. A veces convierte un texto completo en un vector de cientos o miles de dimensiones. En todos los casos hay una decisión de ingeniería: qué información permitimos, qué información prohibimos, cuándo se ajusta la transformación y qué versión queda registrada.

Al terminar deberías poder hacer esto:

Resultado de aprendizaje	Evidencia de que lo sabes hacer
Distinguir dato crudo, feature y representación.	No llamas “dato” a cualquier columna sin mirar cómo se transforma.
Diseñar un contrato de features.	Declaras columnas permitidas, prohibidas, tipos y fit_scope.
Explicar one-hot, normalización, TF-IDF y embeddings.	Puedes escribir sus fórmulas y decir qué aprende cada pieza.
Evitar leakage de representación.	Ajustas vocabulario, escalas e IDF solo con train.
Leer una dimensión de embedding como coste y contrato.	No tratas d=64, d=768 o d=3072 como decoración.
Evaluar una búsqueda vectorial mínima.	Miras top-k, términos fuera de vocabulario, metadata y slices.

La frase central del capítulo:

Una feature no es una columna: es una promesa sobre cómo una columna se convierte en señal.

La escena: el modelo no sabe leer tu tabla

Imagina una tabla con casos de soporte académico. Tiene columnas como created_at, product, channel, student_id, source_id, label y text. Una persona puede leerla y entender bastante: esto va de becas, aquello de matrícula, esto llegó por email, aquello por portal.

El modelo, en cambio, no ve “becas” como idea ni “email” como canal humano. Ve números. Si le das texto, alguien debe tokenizarlo o vectorizarlo. Si le das fechas, alguien debe convertirlas en una escala útil. Si le das categorías, alguien debe decidir si se codifican como one-hot, índices, embeddings aprendidos o metadata para filtrar.

Aquí aparece una parte muy de ingeniería de datos e IA: no basta con tener datos. Hay que construir una representación coherente, reproducible y alineada con el uso real. Si esa representación se construye mal, el modelo puede aprender una señal falsa, olvidar una señal importante o medir con información que no debería haber visto.

Qué no es una feature

Una feature no es cualquier columna que tengamos a mano. student_id existe en la tabla, pero quizá no debería entrar al modelo. Si entra, el sistema podría aprender estilos de estudiantes concretos en vez de patrones generales. source_id existe, pero puede actuar como atajo si cada documento está demasiado asociado a una etiqueta. label existe, pero usarla como entrada sería convertir la respuesta en pista.

Tampoco es una transformación hecha “porque mejora la métrica”. Si una feature mejora mucho el resultado, hay que preguntar por qué. Puede ser una señal legítima, como la antigüedad de un caso. Puede ser una fuga, como una fecha de resolución disponible solo después de cerrar el ticket. Puede ser una variable de identidad, como un código interno que en train coincide con la etiqueta pero en producción cambia.

Y un embedding no es conocimiento puro. Es una representación numérica aprendida o calculada. Puede capturar parecido semántico, pero no garantiza verdad, actualidad, permisos ni relación exacta. Si un vector store devuelve un fragmento cercano, todavía necesitamos comprobar si ese fragmento contiene evidencia suficiente para la pregunta.

Qué sí es una representación

Una representación es la forma en que describimos un objeto para que un algoritmo pueda trabajar con él. En aprendizaje estadístico, el punto de partida suele ser una matriz $X$, donde cada fila representa un ejemplo y cada columna representa una feature.¹ La etiqueta o valor que queremos predecir suele separarse como $y$.

$$X \in \mathbb{R}^{n \times d}$$

Símbolo	Significado	Ejemplo
$X$	Matriz de features.	24 casos por 49 features.
$n$	Número de ejemplos.	24 filas.
$d$	Número de features.	49 columnas generadas por el kit.
$x_{i,j}$	Valor de la feature $j$ para el ejemplo $i$.	product__becas = 1.

En un proyecto de IA moderna, $X$ puede mezclar varias familias de señal:

Familia	Ejemplo	Qué aporta
Numérica	Días desde la primera fecha de train.	Orden temporal, recencia, duración.
Categórica	Producto, canal, país, tipo de usuario.	Segmentos y contexto operativo.
Texto disperso	TF-IDF, bolsa de palabras, BM25.	Coincidencia lexical y términos técnicos.
Texto denso	Embeddings de frases o documentos.	Parecido semántico y paráfrasis.
Metadata	case_id, permisos, versión de documento.	Trazabilidad, filtros y auditoría.

La clave es no mezclar funciones. Metadata puede ser imprescindible para auditar o filtrar, pero no necesariamente debe ser feature del modelo. El contrato decide esa frontera.

Cómo se construye una feature por dentro

Construir una representación es una cadena de decisiones. Primero elegimos columnas permitidas. Después definimos transformaciones. Luego ajustamos lo que tenga que aprenderse usando solo train. Finalmente transformamos train, validation y test con los parámetros ya congelados.

Una feature numérica puede normalizarse así:

$$\tilde{x} = \frac{x - x_{min}^{train}} {x_{max}^{train} - x_{min}^{train}}$$

Símbolo	Significado	Ejemplo
$x$	Valor original.	Día 10 desde el inicio.
$x_{min}^{train}$	Mínimo observado en train.	Día 0.
$x_{max}^{train}$	Máximo observado en train.	Día 15.
$\tilde{x}$	Valor normalizado.	$10/15 = 0.67$.

La parte importante está en los superíndices: mínimo y máximo salen de train. Si usas todo el dataset, test participa en la escala. Puede parecer poco, pero en pipelines grandes esa pequeña comodidad se acumula con imputación, selección de variables, vocabularios e índices.

Una categoría puede codificarse con one-hot:

$$onehot(c)_k = \begin{cases} 1 & \text{si } c = k \ 0 & \text{si } c \ne k \end{cases}$$

Símbolo	Significado	Ejemplo
$c$	Categoría de la fila.	becas.
$k$	Categoría concreta del vocabulario.	matricula.
$onehot(c)_k$	Columna binaria para $k$.	0 si el producto es becas.

Si en train vemos becas, horarios, matricula, pagos, practicas y titulos, esas son las columnas que crea el contrato. Si mañana aparece doctorado, el sistema no debería improvisar silenciosamente una columna nueva en producción. Debe registrarlo como categoría desconocida, decidir cómo tratarla y actualizar el contrato si procede.

Para texto lexical, TF-IDF pondera términos usando frecuencia local y rareza global. Una forma habitual es:

$$tfidf(t,d) = tf(t,d) \cdot \left( \log \frac{1 + N}{1 + df(t)} + 1 \right)$$

Símbolo	Significado	Ejemplo
$t$	Término.	beca.
$d$	Documento o texto de una fila.	“requisitos de beca”.
$tf(t,d)$	Veces que aparece $t$ en $d$.	1.
$N$	Número de textos de train.	15.
$df(t)$	Número de textos de train que contienen $t$.	2.
$tfidf(t,d)$	Peso final del término.	Mayor si el término es informativo.

BM25, una familia clásica de ranking lexical, parte de una intuición parecida pero ajusta saturación de frecuencia y longitud del documento.² En RAG híbrido, estas señales lexicales siguen siendo muy útiles: los embeddings toleran paráfrasis; lo lexical rescata términos exactos, códigos, siglas y nombres propios.

Embeddings: vectores densos con contrato

Un embedding es un vector denso:

$$e = f_{\theta}(objeto) \in \mathbb{R}^{m}$$

Símbolo	Significado	Ejemplo
$objeto$	Lo que queremos representar.	Texto de un caso, imagen, usuario, producto.
$f_{\theta}$	Encoder o función de representación.	Modelo de embeddings o encoder local.
$\theta$	Parámetros del encoder.	Pesos entrenados o reglas congeladas.
$m$	Dimensión del vector.	64 en el kit; 768 en muchos modelos BERT.
$e$	Vector resultante.	[0.0, -0.12, ...].

La historia moderna de embeddings no empieza con los LLM actuales. Bengio y colaboradores ya propusieron representar palabras mediante vectores aprendidos dentro de modelos de lenguaje neuronales.³ Word2Vec popularizó embeddings preentrenados eficientes para palabras.⁴ BERT llevó la idea a representaciones contextuales: el vector de una palabra depende de la frase completa.⁵ Sentence-BERT adaptó arquitecturas BERT para producir embeddings de frases útiles en similitud semántica.⁶

La similitud coseno compara direcciones:

$$\cos(a,b) = \frac{a \cdot b} {\|a\| \|b\|}$$

Símbolo	Significado	Ejemplo
$a,b$	Dos vectores.	Query y caso indexado.
$a \cdot b$	Producto escalar.	Suma de productos dimensión a dimensión.
$\|a\|$	Norma de $a$.	Longitud del vector.
$\cos(a,b)$	Similitud por dirección.	1 si apuntan igual; 0 si son ortogonales.

Dimensión no significa “inteligencia”. Significa longitud del vector y, por tanto, memoria, coste de cálculo, coste de índice y capacidad de representar matices. Un embedding de 64 dimensiones cabe barato y sirve como baseline local. Uno de 768 o más puede capturar mucha más estructura, pero cuesta más guardar, comparar y servir.

La anatomía de una representación publicable

Esto en un proyecto real

En un equipo profesional, las features no deberían vivir escondidas dentro de un notebook. Deben tener nombre, definición, propietario, tipo, fuente, ventana temporal, reglas de null, método de cálculo, versión y criterio de retirada. Cuando la misma feature se usa para entrenamiento offline y predicción online, además aparece un problema clásico: que el cálculo de entrenamiento y el cálculo de producción no coincidan.

Ahí entra la idea de feature store: un sistema o una disciplina para compartir definiciones de features, materializarlas, servirlas y versionarlas. Feast, por ejemplo, documenta esta filosofía de definir entidades, feature views y fuentes para servir features de manera consistente.⁷ Lo importante para este libro no es casarnos con una herramienta concreta, sino entender la responsabilidad: si una feature decide, esa feature debe poder explicarse.

En RAG ocurre algo parecido. El embedding de un chunk no es una columna tradicional, pero es un dato derivado. Debe conservar document_id, versión del documento, versión del chunking, encoder, dimensión, fecha de creación y permisos. Si cambias cualquiera de esas piezas, el índice ya no es el mismo aunque el texto visible parezca igual.

Por qué debería importarte

Una mala representación puede arruinar un sistema sin que el error sea evidente. El modelo compila, la API responde y la métrica puede subir, pero quizá aprendió una identidad, una fecha posterior, una categoría mal codificada o un embedding sin metadata. La representación es el lugar donde se decide qué puede aprender el sistema.

También es una cuestión de coste. Si tienes 10 millones de documentos y pasas de 384 a 3072 dimensiones, multiplicas almacenamiento y cálculo. Si además replicas el índice, guardas metadata y añades estructuras de vecinos aproximados, el coste ya no es marginal. FAISS y HNSW existen porque buscar vecinos en espacios vectoriales grandes requiere estructuras especializadas.⁸⁹

Manos a la obra

El kit del capítulo está en:

kit/

Construye dos artefactos: una matriz de features y una búsqueda vectorial mínima. Todo se hace sin dependencias externas para que puedas leer el mecanismo completo.

Estructura

kit/
  README.md
  data/feature_cases.csv
  data/search_queries.csv
  data/split_assignments.csv
  contracts/feature_contract.json
  ops/build_feature_vectors.py
  ops/search_feature_vectors.py
  output/feature_manifest.json
  output/feature_matrix.csv
  output/dense_embedding_matrix.csv
  output/feature_quality_report.json
  output/feature_decision.md
  output/search_results.csv
  output/search_report.json
  output/search_decision.md

Cómo lo ejecutas

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/build_feature_vectors.py --write
cat output/feature_decision.md
python3 ops/search_feature_vectors.py --write
cat output/search_decision.md

Qué deberías ver

El primer script debería dejar el gate en pass:

Genera 49 features tabulares/textuales y embeddings densos locales de 64 dimensiones.

La matriz feature_matrix.csv incluye columnas como product__becas, channel__email y tfidf__matricula. El archivo dense_embedding_matrix.csv incluye embedding_00 hasta embedding_63. El manifiesto guarda hashes, vocabularios, dimensión y fit_scope.

El segundo script debería quedar en review, no porque el sistema esté roto, sino porque algunas consultas tienen términos fuera del vocabulario de train:

q002 -> justificante, pendiente
q004 -> bloqueada

Eso es una lección real: si el vocabulario se ajusta solo con train, validation y test pueden contener palabras nuevas. Un buen pipeline no las esconde; las reporta. Después puedes decidir si necesitas más datos, un encoder neural, búsqueda híbrida, expansión de consultas o revisión del split.

Cómo lo adaptas a tu caso

Si tu proyecto tiene...	Qué cambias
Nuevas columnas tabulares	Añádelas a allowed_input_columns y define transformación.
IDs o columnas sensibles	Mételas en forbidden_input_columns.
Más texto	Sube max_terms o cambia el encoder.
Embeddings reales	Sustituye deterministic_hash_projection, pero conserva dimensión y versión.
Índice de producción	Añade metadata, permisos, fecha de indexado y versión de corpus.
Evaluación RAG	Calcula recall@k, cobertura por producto, latencia y out-of-vocabulary.

Qué entregaría un alumno

1. feature_manifest.json generado.
2. feature_quality_report.json explicado.
3. search_report.json con una lectura de cada consulta.
4. Tres consultas nuevas y su resultado top-k.
5. Una propuesta para sustituir el encoder local por embeddings reales sin perder trazabilidad.

Cómo encaja todo

Este mapa debe leerse como una brújula, no como un inventario de técnicas. Los capítulos anteriores del facsímil nos dieron linaje, calidad y splits; los facsímiles previos nos dieron tokens, embeddings, RAG y vector stores. Este capítulo hace de puente: decide qué puede ver el sistema y cómo queda esa decisión convertida en matriz, vector, manifiesto y búsqueda.

La continuidad posterior también es importante. Una representación no termina cuando se genera feature_matrix.csv: se evalúa por slices, se monitoriza cuando cambia la producción, se mide como recuperación si entra en RAG y se gobierna si toca permisos, identidad o decisiones sensibles.

graph TD
    subgraph "Este capítulo"
        Q["Qué puede ver<br/>el sistema"]
        BOUND["Señal útil<br/>vs atajo"]
        CONTRACT["Contrato<br/>de representación"]
        FIT["Fit solo<br/>con train"]
        REP["Matriz y vector"]
        MANIFEST["Feature manifest"]
        DEC["Decisión de uso"]
    end
    subgraph "Mismo facsímil"
        C01["Linaje<br/>cap. 1"]
        C02["Calidad<br/>cap. 2"]
        C03["Split honesto<br/>cap. 3"]
        C05["Slices<br/>cap. 5"]
        C06["DataOps<br/>cap. 6"]
    end
    subgraph "Otros facsímiles"
        TOK["Tokens y embeddings<br/>fasc. 1"]
        RAG["RAG y vector stores<br/>fasc. 4"]
        EVAL["Evaluar retrieval<br/>fasc. 7"]
        GOV["Gobernanza<br/>fasc. 9"]
    end

    C01 -->|"aporta procedencia"| CONTRACT
    C02 -->|"exige datos sanos"| CONTRACT
    C03 -->|"limita el ajuste"| FIT
    TOK -->|"da intuición"| REP
    RAG -->|"usa índice"| REP

    Q -->|"define"| BOUND
    BOUND -->|"se formaliza en"| CONTRACT
    CONTRACT -->|"ordena"| FIT
    FIT -->|"produce"| REP
    REP -->|"se registra en"| MANIFEST
    MANIFEST -->|"sostiene"| DEC

    DEC -->|"se mide por"| C05
    MANIFEST -->|"se compara en"| C06
    REP -->|"se evalúa en"| EVAL
    CONTRACT -->|"declara límites"| GOV

    style Q fill:#F5F5F5,stroke:#000000,stroke-width:2
    style BOUND fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CONTRACT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style FIT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style REP fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MANIFEST fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DEC fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C01 stroke-dasharray: 5 5
    style C02 stroke-dasharray: 5 5
    style C03 stroke-dasharray: 5 5
    style C05 stroke-dasharray: 5 5
    style C06 stroke-dasharray: 5 5
    style TOK stroke-dasharray: 5 5
    style RAG stroke-dasharray: 5 5
    style EVAL stroke-dasharray: 5 5
    style GOV stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición breve
Feature	Variable de entrada que un modelo puede usar.
Representación	Forma numérica de describir un objeto.
One-hot	Codificación binaria de categorías.
Normalización	Cambio de escala para comparar valores.
TF-IDF	Peso lexical basado en frecuencia local y rareza global.
Embedding	Vector denso que permite comparar objetos por similitud.
Dimensión	Longitud del vector o número de coordenadas.
Similitud coseno	Comparación de dirección entre dos vectores.
Out-of-vocabulary	Término que no estaba en el vocabulario ajustado.
Feature manifest	Artefacto que versiona columnas, vocabulario, hashes y dimensiones.

Dónde solía tropezar yo

Tropiezo	Por qué ocurre	Antídoto
Usar todas las columnas	Parece que más información siempre ayuda.	Separar entradas, target, IDs y metadata.
Ajustar vocabulario con todo el dataset	Es más cómodo hacerlo antes del split.	Crear split primero y hacer fit solo con train.
Llamar conocimiento a un embedding	El vector parece semántico.	Conservar evidencia, metadata, permisos y evaluación.
Ignorar dimensión y coste	El modelo de embeddings se ve como una caja externa.	Calcular almacenamiento, latencia e índice.
Mirar solo el top-1	El primer vecino puede ser casual.	Evaluar top-k, slices y términos fuera de vocabulario.

Antes de pasar página

Antes de avanzar, deberías poder responder:

1. ¿Por qué una feature no es simplemente una columna?
2. ¿Qué diferencia hay entre feature, metadata y target?
3. ¿Por qué one-hot necesita vocabulario ajustado en train?
4. ¿Qué aprende TF-IDF y por qué puede contaminar si se ajusta con todo el dataset?
5. ¿Qué significa que un embedding viva en $\mathbb{R}^{m}$?
6. ¿Qué mide la similitud coseno?
7. ¿Por qué la dimensión afecta coste y ranking?
8. ¿Qué guarda feature_manifest.json?
9. ¿Por qué search_report.json queda en review?
10. ¿Qué cambiarías para usar embeddings reales sin perder trazabilidad?

En resumen

Idea	Qué te llevas
La representación es parte del sistema.	No se improvisa dentro de un notebook.
El fit pertenece a train.	Escalas, vocabularios e IDF se congelan antes de validation y test.
Embedding no significa verdad.	Es una geometría útil que necesita metadata y evaluación.
La dimensión tiene coste.	Afecta memoria, latencia, índice y calidad de ranking.
Una práctica real deja artefactos.	Contrato, matriz, manifiesto, reporte y decisión.

Para saber más

Bengio, Y., Ducharme, R., Vincent, P. y Janvin, C. (2003). A Neural Probabilistic Language Model. Journal of Machine Learning Research, 3, 1137-1155. Paper

Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. NAACL-HLT 2019, 4171-4186. DOI

Feast. (2026). Feast Documentation. Documentación

Hastie, T., Tibshirani, R. y Friedman, J. (2009). The Elements of Statistical Learning (2.ª ed.). Springer. Libro

Johnson, J., Douze, M. y Jégou, H. (2019). Billion-Scale Similarity Search with GPUs. IEEE Transactions on Big Data, 7(3), 535-547. DOI

Malkov, Y. A. y Yashunin, D. A. (2020). Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. IEEE Transactions on Pattern Analysis and Machine Intelligence, 42(4), 824-836. DOI

Mikolov, T., Chen, K., Corrado, G. y Dean, J. (2013). Efficient Estimation of Word Representations in Vector Space. arXiv

Reimers, N. y Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. EMNLP-IJCNLP 2019, 3982-3992. DOI

Robertson, S. y Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval, 3(4), 333-389. DOI

Notas

1. Hastie, T., Tibshirani, R. y Friedman, J. (2009). The Elements of Statistical Learning (2.ª ed.). Springer. Libro. ↩

2. Robertson, S. y Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval, 3(4), 333-389. DOI. ↩

3. Bengio, Y., Ducharme, R., Vincent, P. y Janvin, C. (2003). A Neural Probabilistic Language Model. Journal of Machine Learning Research, 3, 1137-1155. Paper. ↩

4. Mikolov, T., Chen, K., Corrado, G. y Dean, J. (2013). Efficient Estimation of Word Representations in Vector Space. arXiv. ↩

5. Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. NAACL-HLT 2019, 4171-4186. DOI. ↩

6. Reimers, N. y Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. EMNLP-IJCNLP 2019, 3982-3992. DOI. ↩

7. Feast. (2026). Feast Documentation. Documentación. Consultado el 6 de junio de 2026. ↩

8. Johnson, J., Douze, M. y Jégou, H. (2019). Billion-Scale Similarity Search with GPUs. IEEE Transactions on Big Data, 7(3), 535-547. DOI. ↩

9. Malkov, Y. A. y Yashunin, D. A. (2020). Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. IEEE Transactions on Pattern Analysis and Machine Intelligence, 42(4), 824-836. DOI. ↩

Capítulo 05: Slices, sesgos y decisión algorítmica

Qué deberías poder hacer al terminar

En el capítulo anterior convertimos datos en representaciones. Ahora viene una pregunta menos cómoda: ¿esa representación se comporta igual de bien en todas las partes importantes del problema?

La respuesta casi nunca sale mirando solo la media global. Una accuracy de 0,86, un recall de 0,78 o un coste medio aceptable pueden esconder que el sistema falla en un producto, un canal, un idioma, una fuente de datos, una necesidad de accesibilidad o una combinación pequeña pero importante. A esa partición útil del comportamiento la llamamos slice.

Al terminar deberías poder hacer esto:

Resultado de aprendizaje	Evidencia de que lo sabes hacer
Definir slices útiles.	No partes por columnas al azar: eliges segmentos conectados con la decisión.
Separar atributo de auditoría y feature.	Entiendes que un campo puede servir para medir aunque no deba entrar al modelo.
Calcular métricas por slice.	Obtienes recall, tasa de revisión, falsos positivos, coste y captura segura por grupo.
Leer disparidades sin convertirlas en eslogan.	Sabes qué métrica se compara, qué tamaño de muestra la sostiene y qué acción permite.
Entender criterios clásicos de equidad algorítmica.	Distingues paridad demográfica, igualdad de oportunidad, odds igualadas y calibración por grupo.
Convertir una auditoría en decisión.	Produces un reporte, un CSV de slices, una ficha y una decisión operativa.

La frase central del capítulo:

Un sistema no se publica porque la media global suene bien; se publica cuando sabes dónde funciona, dónde no y qué harás con esa diferencia.

La escena: la media global llega demasiado tarde

Imagina un sistema que ayuda a priorizar casos académicos. Cada caso recibe un score. Si el score es alto, se prioriza. Si es bajo, sigue el flujo normal. Si cae en medio, se manda a revisión.

La métrica global parece razonable. El sistema acierta muchos casos, revisa una parte manejable y mantiene buena latencia. En una reunión rápida alguien podría decir: “vamos adelante”.

Pero al partir los resultados por slices aparece otra lectura. Los casos con necesidad de adaptación tienen más casos prioritarios enviados al flujo normal. En inglés se revisa mucho más. En un producto concreto, los casos importantes no quedan capturados. La media global no mentía; simplemente comprimía demasiado.

Este capítulo enseña a no dejar que eso pase.

Qué no es auditar por slices

Auditar por slices no es hacer una tabla enorme con todas las columnas del CSV. Si cada valor distinto se convierte en una fila de auditoría, obtienes ruido. Un slice debe existir porque representa una hipótesis: “este canal cambia la forma de escribir”, “este producto tiene más ambigüedad”, “este idioma tiene menos ejemplos”, “este grupo necesita que no confundamos silencio con baja prioridad”.

Tampoco es declarar que una diferencia numérica demuestra una injusticia completa. Una disparidad es una señal medible, no una sentencia universal. Puede venir de datos escasos, etiquetas inconsistentes, política de negocio, diseño del umbral, cobertura desigual, drift o un error real del modelo. La ingeniería consiste en separar esas causas antes de automatizar más.

Y no es lo mismo usar un atributo para decidir que usarlo para auditar. En muchos sistemas, ciertos campos no deben entrar como feature. Aun así, puede ser imprescindible medir resultados agregados por esos campos para detectar si el sistema está fallando justo donde más importa. El contrato debe decirlo: campo no usado por el modelo, campo permitido para auditoría agregada.

Qué sí es un slice

Un slice es un subconjunto definido por una condición. Si $D$ es el conjunto evaluado y $A$ es un atributo de auditoría, el slice asociado al valor $a$ es:

$$D_a = \{(x_i, y_i, \hat{s}_i) \in D : A_i = a\}$$

Símbolo	Significado	Ejemplo
$D$	Dataset de evaluación.	36 casos de test del kit.
$A$	Atributo usado para auditar.	language.
$a$	Valor concreto del atributo.	en.
$D_a$	Slice formado por casos con ese valor.	Casos de test en inglés.
$x_i$	Entrada o representación del caso.	Texto, producto, canal, metadata.
$y_i$	Etiqueta real.	true_priority = 1.
$\hat{s}_i$	Score producido por el sistema.	0.84.

La parte importante es que el slice conserva la unidad de decisión. No evaluamos “idioma” en abstracto. Evaluamos decisiones sobre casos dentro de un idioma, producto, canal o combinación de condiciones.

Ejemplo de fórmula: en el kit del capítulo, una política de triaje convierte score en decisión. Los números son umbrales didácticos congelados para la práctica; en un proyecto real se fijarían con validación, capacidad humana y coste operativo antes de mirar test.

$$d(\hat{s}) = \begin{cases} P & \hat{s} \ge 0.78 \ N & \hat{s} < 0.38 \ R & \text{otro caso} \end{cases}$$

Símbolo	Significado	Ejemplo
$\hat{s}$	Score producido por el sistema.	0,36.
$P$	Priorizar.	Caso claro de alta prioridad.
$N$	Flujo normal.	Caso claro de baja prioridad.
$R$	Revisar.	Caso intermedio.
0,78	Umbral alto congelado antes de mirar test.	Priorizar casos claros.
0,38	Umbral bajo congelado antes de mirar test.	Enviar al flujo normal casos claros.

Esta política no se ajusta en test. Test sirve para medir. Si tocamos umbrales mirando el slice que falla, ya no estamos auditando: estamos usando la evaluación como desarrollo. Eso lo vimos en el capítulo 03 del facsímil 08.

Métricas por slice: lo mínimo que un ingeniero debería mirar

Para cada slice conviene calcular una matriz de confusión. En una decisión binaria clásica, tendríamos TP, FP, FN y TN. En una política con revisión, añadimos una tercera salida: revisar. Eso cambia la lectura.

Si un caso prioritario se manda a normal, tenemos un fallo operativo fuerte. Si se manda a revisar, no se ha automatizado bien, pero tampoco se ha dejado pasar sin mirar. Por eso el kit distingue tres métricas:

Métrica	Fórmula	Lectura
Auto-recall	$TP / P$	De los casos prioritarios, cuántos se priorizan automáticamente.
Miss rate	$FN / P$	De los casos prioritarios, cuántos se envían a flujo normal.
Captura segura	$(TP + review_P) / P$	De los prioritarios, cuántos quedan priorizados o revisados.

Donde:

Símbolo	Significado	Ejemplo
$P$	Número de casos positivos reales en el slice.	6 casos prioritarios.
$TP$	Positivos reales priorizados.	2 casos.
$FN$	Positivos reales enviados a flujo normal.	4 casos.
$review_P$	Positivos reales mandados a revisión.	1 caso.

La diferencia entre auto-recall y captura segura es muy útil. Si auto-recall es bajo pero captura segura es alta, quizá el sistema no automatiza mucho, pero protege la decisión con revisión. Si captura segura es baja, el problema es más serio: casos importantes están pasando al flujo normal.

Ejemplo de fórmula: para no olvidar el coste, el kit usa esta función lineal. Es una plantilla pedagógica: cada equipo debería cambiar pesos y unidades según impacto real, tiempo de revisión, riesgo y capacidad.

$$C = c_{FN} \cdot FN + c_{FP} \cdot FP + c_R \cdot R$$

Símbolo	Significado	Ejemplo del kit
$C$	Coste operativo total del slice.	19,6.
$c_{FN}$	Coste de enviar un prioritario a flujo normal.	8,0.
$c_{FP}$	Coste de priorizar un no prioritario.	3,0.
$c_R$	Coste de revisión.	1,2.
$R$	Número de casos revisados.	3.

Un coste no tiene que ser euros. Puede ser minutos de equipo, riesgo operativo, saturación de soporte o coste de oportunidad. Lo importante es hacerlo explícito antes de elegir política.

Criterios clásicos: nombres útiles, no dogmas

La literatura de equidad algorítmica distingue varios criterios. Conviene conocerlos porque aparecen en papers, herramientas y auditorías, pero no deben usarse como recetas automáticas.

La paridad demográfica compara tasas de selección entre grupos. En nuestro caso sería comparar qué proporción de casos se prioriza en cada slice:

$$P(\hat{Y}=1 \mid A=a)$$

Sirve para detectar diferencias de tasa de salida. No sabe si los casos positivos reales estaban distribuidos igual. Si un producto recibe más casos realmente prioritarios que otro, exigir la misma tasa de priorización puede ser una mala idea.

La igualdad de oportunidad compara la tasa de verdaderos positivos entre grupos, es decir, si los casos positivos reales reciben la salida positiva con tasas parecidas.¹ En el kit se parece al auto-recall por slice:

$$P(\hat{Y}=1 \mid Y=1, A=a)$$

Las odds igualadas comparan tanto verdaderos positivos como falsos positivos entre grupos. Pide que el sistema tenga comportamiento parecido para positivos reales y negativos reales. Es más exigente que mirar solo recall.

La calibración por grupo pregunta si un score significa lo mismo en cada grupo. Si los casos con score 0,8 aciertan el 80 % en un slice y el 55 % en otro, no basta con decir que el score ordena bien globalmente. Esto conecta con calibración e incertidumbre en el facsímil 07.

Hay un punto clave: algunos criterios no se pueden satisfacer todos a la vez salvo en condiciones especiales. Chouldechova y Kleinberg, Mullainathan y Raghavan mostraron incompatibilidades entre nociones de equidad cuando las tasas base difieren entre grupos.²³ Traducido a ingeniería: elegir una métrica de equidad es elegir qué error quieres controlar y qué compromiso aceptas.

Sesgo no siempre significa lo mismo

La palabra sesgo se usa demasiado rápido. Para ingeniería, decir “el modelo tiene sesgo” sin precisar de qué tipo es casi no ayuda. Necesitamos localizar dónde entra, cómo se manifiesta, qué métrica lo hace visible y qué acción permite.

En este capítulo no usamos sesgo como insulto técnico. Lo usamos como una diferencia sistemática que puede afectar a una decisión. Puede estar en los datos, en el objetivo, en la representación, en el modelo, en el umbral, en la interfaz o en la forma de medir. Si no separas esas capas, acabas arreglando el sitio equivocado.

Fuente de sesgo	Qué ocurre	Cómo se detecta	Qué suele hacerse
Cobertura	Un slice tiene pocos ejemplos o no aparece en train.	Conteos, intervalos, unknowns, categorías raras.	Recoger más datos, limitar automatización, declarar cobertura.
Selección	Los datos observados no representan el uso real.	Comparar distribución de train, test y producción.	Rehacer split, muestreo, ponderación o contrato de uso.
Medición	Un campo no mide lo mismo en todos los grupos.	Revisar definición, instrumento de captura y linaje.	Cambiar proxy, añadir variable mejor, documentar límite.
Proxy	Una variable cómoda sustituye mal al concepto real.	Correlación con slices, errores concentrados, revisión de dominio.	Sustituir proxy o cambiar objetivo.
Etiquetado	Las etiquetas se aplican con criterios distintos.	Acuerdo entre anotadores, desacuerdo por slice, revisión de casos frontera.	Reescribir política de anotación y reetiquetar muestra.
Representación	Las features o embeddings capturan peor un segmento.	OOV, vecinos pobres, recall por slice, sensibilidad a idioma o formato.	Cambiar encoder, vocabulario, normalización o datos de entrenamiento.
Agregación	Un único modelo o umbral mezcla subpoblaciones con comportamientos distintos.	Buen promedio global con slices débiles.	Umbrales por contexto, rutas de revisión o modelos especializados con control.
Evaluación	El test no contiene el problema que aparecerá en producción.	Falta de slices críticos, test pequeño, ausencia de intersecciones.	Nueva eval, holdout, monitorización por slice.
Interacción	La interfaz cambia lo que el usuario escribe o aporta.	Diferencias por canal, longitud, idioma, plantilla o formulario.	Rediseñar entrada, instrucciones y validaciones.
Política	El mismo score produce consecuencias distintas según contexto.	Coste, revisión, capacidad operativa y efectos por segmento.	Cambiar umbrales, limitar automatización o exigir revisión.

Un caso clásico de la literatura sanitaria mostró que usar coste sanitario como proxy de necesidad médica podía reducir la identificación de pacientes con necesidades reales en ciertos grupos, porque el gasto histórico no medía necesidad de forma neutral.⁴ La lección para este libro no es copiar ese dominio; es entender el patrón: un proxy cómodo puede cambiar la decisión que crees estar midiendo.

Por eso el capítulo 01 insistía en linaje y uso permitido, el 02 en calidad, el 03 en splits y el 04 en representación. Los slices son donde esas decisiones anteriores se vuelven visibles.

Qué sabemos por estudios en modelos reales

Los sesgos no aparecen solo en clasificadores tabulares. También se han observado en embeddings, modelos de lenguaje, clasificadores de texto, sistemas de visión y sistemas de decisión basados en proxies. Ver esos estudios ayuda porque cambia la pregunta: ya no es “¿puede pasar?”, sino “¿cómo lo detectaría en mi caso?”.

Estudio	Tipo de modelo o sistema	Qué mostró	Señal detectable
Bolukbasi et al. (2016)	Word embeddings	Algunas analogías en embeddings capturaban asociaciones de género no deseadas.5	Direcciones en el espacio vectorial y vecinos semánticos.
Caliskan et al. (2017)	Embeddings entrenados con corpus	WEAT mostró asociaciones recuperables desde lenguaje ordinario.6	Test de asociación entre conjuntos de términos.
Buolamwini y Gebru (2018)	Clasificación facial comercial	Las tasas de error variaban mucho por intersección de tono de piel y género en sistemas evaluados.7	Accuracy por grupos e intersecciones, no solo global.
Dixon et al. (2018)	Clasificación de toxicidad	Ciertos términos de identidad podían disparar predicciones tóxicas aunque el texto no lo fuera.8	Falsos positivos asociados a términos concretos.
CrowS-Pairs (2020)	Modelos de lenguaje enmascarados	Comparó pares de frases para medir preferencias por frases con estereotipo.9	Probabilidad relativa entre pares mínimos.
StereoSet (2021)	Modelos de lenguaje preentrenados	Midió sesgo estereotípico junto con capacidad de modelado lingüístico.10	Relación entre score lingüístico y score de estereotipo.
BBQ (2022)	Pregunta-respuesta	Evaluó si modelos recurren a estereotipos cuando el contexto es insuficiente o ambiguo.11	Respuestas bajo contexto ambiguo frente a contexto informativo.

Hay dos lecciones de ingeniería en esa tabla.

La primera: el sesgo no siempre aparece como “métrica baja”. A veces aparece como asociación geométrica, falso positivo lexical, peor cobertura en intersecciones, sensibilidad al contexto ambiguo o score calibrado de forma distinta por grupo.

La segunda: cada tipo de sistema necesita su prueba. Para embeddings haces vecinos, direcciones, WEAT o pares mínimos. Para clasificación haces matriz por slice. Para RAG miras recuperación por fuente, idioma, fecha y permisos. Para generación miras pares contrafactuales, respuestas con contexto insuficiente, abstención y criterios de evaluación.

Detectabilidad: cómo se ve un sesgo antes de producción

Una auditoría útil no pregunta “¿hay sesgo?” en abstracto. Pregunta “¿qué señal observable esperaría si este sistema falla de forma sistemática?”.

Señal detectable	Cómo se calcula	Qué indica	Qué no demuestra sola
Slice con poco $n$	Conteo por segmento.	Falta evidencia para concluir.	Que el sistema sea malo en ese slice.
Diferencia de recall	$TP/P$ por slice.	Un grupo de positivos reales se detecta peor.	La causa del problema.
Diferencia de falsos positivos	$FP/N$ por slice.	Un grupo recibe más salidas positivas indebidas.	Que el objetivo esté bien definido.
Captura segura baja	$(TP + review_P)/P$.	Casos importantes pasan sin priorizar ni revisar.	Qué componente lo provocó.
Tasa de revisión dispar	$R/n$ por slice.	Un segmento se automatiza menos o consume más revisión.	Que revisar sea necesariamente malo.
Coste por caso dispar	$C/n$ por slice.	El impacto operativo se concentra.	Que el coste esté bien ponderado.
OOV alto	Términos fuera del vocabulario por slice.	La representación cubre peor un segmento.	Que un embedding real no lo arregle.
Vecinos pobres	Top-k sin evidencia útil para un slice.	Recuperación débil o índice mal cubierto.	Que el generador sea el único culpable.
Pares contrafactuales inestables	Cambiar solo un atributo y comparar salida.	Sensibilidad indeseada a un cambio controlado.	Que todos los casos reales fallen igual.
Contexto ambiguo decide demasiado	Probar preguntas con evidencia insuficiente.	El modelo rellena huecos con asociaciones aprendidas.	Que falle cuando la evidencia es completa.

La palabra “detectable” importa. Si un sesgo no tiene métrica, muestra, caso de prueba o traza, se convierte en debate interminable. El objetivo no es tener todas las respuestas, sino diseñar señales que permitan revisar.

Buenas prácticas para no fabricar un problema nuevo

La buena práctica empieza antes de entrenar. Un equipo serio no espera al final para “pasar fairness”. Diseña la evaluación desde el contrato de datos.

Buena práctica	Qué haces en concreto
Definir la unidad de decisión	No mezclas usuario, caso, documento, chunk y sesión como si fueran lo mismo.
Separar feature y auditoría	Un campo puede no entrar al modelo y aun así medirse de forma agregada.
Escribir slices críticos antes de test	Evitas elegir segmentos solo porque cuentan una historia cómoda.
Medir intersecciones	language=en puede parecer aceptable y language=en + access_need=si no.
Añadir mínimos de muestra	Sin $n$, positivos y negativos suficientes, el slice va a revisión.
Guardar política y hashes	Si cambia el dataset o el contrato, cambia la auditoría.
Congelar umbrales antes de test	Ajustar con test convierte auditoría en desarrollo.
Mirar coste, no solo métrica	Un fallo raro puede importar más que diez aciertos baratos.
Dejar una acción escrita	pass, review o block con razones y siguiente paso.
Conectar con monitorización	Los mismos slices se observan después en producción.

Y hay cosas que conviene evitar:

Evita	Por qué
“No medimos ese atributo, así que no hay problema”	No usar un campo como feature no implica que el sistema no tenga diferencias por ese campo.
“La muestra es pequeña, pero la media global pasa”	Un slice pequeño no se arregla escondiéndolo dentro del promedio.
“El benchmark público dice que el modelo es bueno”	El benchmark quizá no cubre tu dominio, idioma, interfaz o coste.
“Mitigamos borrando una columna”	Otros campos pueden actuar como proxies.
“Probamos muchos slices y publicamos solo los interesantes”	Eso convierte auditoría en selección de relato.
“Una herramienta lo certifica”	La herramienta calcula; el equipo define uso, consecuencia, coste, límites y acción.
“Arreglamos el test tocando el umbral”	Si el umbral se elige mirando test, necesitas nueva evaluación.
“Todos los slices deben tener la misma tasa”	Algunas tasas base reales pueden diferir; la pregunta es qué error estás controlando.

El kit del capítulo incorpora estas prácticas en pequeño: fields_not_for_model, audit_fields, critical_slices, mínimos de muestra, gates, hashes y decisión Markdown. No es una auditoría completa de un sistema real, pero sí tiene la forma profesional que debe tener una primera revisión.

Anatomía de una auditoría de decisión

Herramientas reales y cómo leerlas

Fecha de corte de esta lectura: 7 de junio de 2026. El mercado cambia rápido, así que no conviene memorizar logos. Conviene memorizar qué artefacto produce cada herramienta: métrica por slice, intervalo, explicación, alerta, comparación de versiones, política de mitigación o evidencia para una revisión.

Una herramienta seria no “quita el sesgo” en abstracto. Hace una de estas cosas: mide una diferencia, ayuda a encontrar causa probable, aplica una técnica de mitigación, deja trazabilidad o vigila si producción se aleja de lo que mediste en validación. Si no produce un artefacto revisable, es una demo bonita, no una práctica de ingeniería.

Herramientas abiertas para auditar y mitigar

Estas herramientas encajan bien cuando el equipo trabaja con notebooks, pandas, scikit-learn, TensorFlow o reportes reproducibles en CI. Son especialmente útiles para enseñar y para construir un primer estándar interno, porque puedes inspeccionar datos, métricas y código.

Herramienta	Dónde encaja	Qué permite ver	Qué puede ayudar a mitigar	Qué no debes delegarle
Fairlearn	Modelos tabulares o pipelines compatibles con scikit-learn.	Métricas agrupadas con MetricFrame, comparación entre grupos y visualización de disparidades.12	Reducciones como ExponentiatedGradient, búsqueda con restricciones y optimización de umbrales.13	La definición de grupos, coste del error y métrica que gobierna la decisión.
AI Fairness 360	Comparar algoritmos de fairness, datasets de referencia y métricas clásicas.	Métricas, detectores, explicadores y API compatible con scikit-learn para parte del toolkit.14	Preprocesamiento, técnicas durante entrenamiento y postprocesamiento.15	El encaje con tu contrato de datos real. Muchos ejemplos académicos no se parecen a tu producto.
Aequitas	Auditoría de scores binarios o continuos con CSV, CLI o interfaz local.	Métricas de grupo, disparidades y criterios sobre scores, etiquetas y atributos.16	No mitiga por sí sola: ayuda a decidir si el modelo o la política deben cambiar.	Convertir una tabla de disparidades en decisión sin revisar el dominio.
Fairness Indicators	Ecosistema TensorFlow, TFMA y evaluación por slices.	Visualización de rendimiento por segmentos, intervalos y métricas en pipelines TensorFlow.17	No es una varita de mitigación; empuja a localizar slices débiles y a rediseñar datos o entrenamiento.	Pensar que solo aplica a “temas sociales”. También sirve para idioma, canal, dispositivo o fuente.
What-If Tool	Exploración interactiva de ejemplos, umbrales y contrafactuales.	Cómo cambian predicciones al mover ejemplos, atributos o umbrales.18	Ayuda a descubrir hipótesis antes de automatizar una prueba.	Sustituir una evaluación versionada. Explorar no es certificar.
Responsibly	Aprendizaje, prototipos y análisis de fairness en clasificación y NLP.	Métricas, visualizaciones y utilidades para enseñar conceptos con código.19	Puede acompañar un primer laboratorio o auditoría exploratoria.	Producción sin controles propios, versionado y trazabilidad.

Para un curso de ingeniería, Fairlearn y AIF360 son buenas primeras estaciones porque obligan a escribir y_true, y_pred, score, atributo sensible o de auditoría y métrica. Ese gesto parece básico, pero es la mitad del aprendizaje: si no sabes pasar esos arrays con nombres correctos, todavía no sabes qué estás auditando.

Plataformas cloud y de ciclo de vida

Cuando el sistema ya vive en una nube concreta, las herramientas integradas aportan algo que una libreta local no tiene: conexión con jobs, registros de modelo, monitorización, permisos, reportes y gobierno de releases.

Plataforma	Qué cubre	Cuándo tiene sentido	Cuidado de ingeniería
Amazon SageMaker Clarify	Sesgo en datos y modelos, explicabilidad, evaluaciones de modelos fundacionales y monitorización integrada con SageMaker.20	Si tu entrenamiento, registro o despliegue ya está en SageMaker.	Hay que fijar qué features o atributos se analizan, en qué split, con qué baseline y qué acción dispara una alerta.
Azure Responsible AI dashboard	Paneles de análisis responsable dentro de Azure ML: errores, importancia de variables, contrafactuales, causalidad y fairness según el tipo de modelo.21	Si trabajas con Azure ML y quieres que evaluación, registro y explicación vivan en el mismo flujo.	Un panel no sustituye un gate en CI/CD. Debe acabar en una decisión reproducible.
SageMaker Model Monitor, Azure ML monitoring o equivalentes	Vigilancia de datos, predicciones, latencia y cambios por segmento.	Si el riesgo no termina al desplegar.	La métrica por slice debe existir antes de producción; no la inventes cuando salta la alerta.

La pregunta correcta para una nube no es “¿tiene dashboard?”. Es: ¿puedo versionar la política, reproducir el reporte, bloquear un release, abrir una incidencia y comparar producción contra validación por los mismos slices? Si no, el panel sirve para mirar, pero no para gobernar.

Observabilidad y herramientas de mercado

En producción aparece otra familia: plataformas de observabilidad de ML y GenAI. No suelen ser la primera herramienta para aprender fairness, pero sí son relevantes cuando tienes tráfico real, múltiples modelos, trazas, embeddings, RAG, usuarios, feedback y alertas.

Herramienta	Qué suele aportar	Dónde ayuda con sesgos	Qué pedir antes de adoptarla
Evidently	Librería y plataforma para calidad de datos, drift, evaluación y reportes.22	Comparar referencia frente a producción, crear reportes por segmento y vigilar si cambian distribuciones.	Exportar reportes, integrarlo en CI y definir tus propios slices, no solo métricas por defecto.
Giskard	Evaluación y testing de modelos, agentes y aplicaciones GenAI.23	Pruebas de comportamiento en LLMs: toxicidad, estereotipos, robustez de prompts, RAG y regresiones de comportamiento.	Datasets de prueba propios y criterios explícitos. Sin casos de tu dominio, solo pruebas una maqueta.
Fiddler	Observabilidad, explicabilidad y métricas de fairness en producción.24	Monitorizar rendimiento por cohortes, explicar predicciones y detectar degradación por grupos.	Acceso a etiquetas o feedback posterior; sin ground truth retrasado, algunas señales serán aproximadas.
Arize	Observabilidad para ML, visión, embeddings y GenAI, con slicing, drift y análisis de rendimiento.25	Slices, cohortes, embeddings, drift y degradación de rendimiento en producción.	Que los atributos de auditoría lleguen al sistema con permisos y granularidad correcta.
WhyLabs	Observabilidad con perfiles de datos, drift, calidad, modelos predictivos y GenAI.26	Vigilar cambios de datos, problemas de calidad, drift, outputs de LLM y trazas.	Que las alertas estén conectadas con owners, SLOs y acciones, no solo con correos.
Arthur, WhyLabs, Fiddler, Arize u otros proveedores enterprise	Gobierno, monitorización, dashboards, explicabilidad y control operativo.27	Cuando hay varios equipos, varios modelos y requisitos de trazabilidad.	Evita comprar “confianza”. Compra integración, auditoría, permisos, exportación y comparabilidad.

El mercado es útil cuando resuelve un problema de operación: logging, trazas, control de versiones, dashboards compartidos, alertas, permisos, exportaciones y soporte. Pero el mercado no conoce por defecto tu coste de error. Tampoco sabe si un falso positivo molesta, si un falso negativo deja a alguien sin atención o si un slice con poca muestra debe bloquear o pedir más datos.

Mitigar no es borrar una columna

Hay una trampa clásica: detectar una diferencia, borrar el atributo sensible y declarar el problema resuelto. En sistemas reales, los proxies aparecen por código postal, idioma, canal, horario, dispositivo, historial, coste, texto libre o fuente documental. Por eso la mitigación debe elegir dónde está la causa probable.

Capa de mitigación	Qué cambia	Ejemplos técnicos	Cuándo usarla	Qué vigilar
Datos	La distribución, cobertura o calidad de las muestras.	Recolectar más casos, reetiquetar, balancear, reponderar, mejorar instrucciones de anotación, separar fuentes.	Hay slices con poca muestra, etiquetas inconsistentes o proxies claros.	No fabricar un dataset artificial que ya no se parezca a producción.
Representación	Cómo se codifica el caso.	Mejorar features, revisar embeddings, normalizar idioma, añadir metadatos permitidos, cambiar encoder, reducir OOV.	El modelo no ve señales suficientes en ciertos grupos o formatos.	No meter campos que expliquen demasiado bien una condición sensible sin justificación.
Entrenamiento	La función objetivo o restricciones del modelo.	Fairlearn reductions, restricciones de paridad, regularización, pérdidas ponderadas, búsqueda de hiperparámetros con gates.	El modelo aprende una frontera útil pero desigual.	Medir trade-off: una restricción puede mejorar un slice y empeorar otro.
Umbral y política	La conversión de score a acción.	Umbral global, banda de revisión, umbrales condicionados con revisión de dominio, abstención, doble lectura humana.	El score está razonablemente calibrado, pero la acción automática concentra riesgo.	Cambiar umbrales por grupo tiene implicaciones de producto, ética, regulación y soporte. No se improvisa.
Producto	La experiencia y el circuito humano.	Explicación al usuario, apelación, revisión manual, colas por capacidad, feedback posterior, monitorización.	La consecuencia de equivocarse es alta o no hay datos suficientes para automatizar.	Que la revisión humana no sea un cajón sin dueño, SLA ni trazabilidad.

La mitigación buena suele ser aburrida: cambiar datos, contratos, umbrales, monitorización, revisión y documentación. La mala mitigación suele parecer elegante: un algoritmo nuevo aplicado sin explicar qué consecuencia reduce.

Cómo elegir herramienta según tu stack

Si estás aquí	Empieza por	Añade después
Notebook con CSV y modelo sklearn	Fairlearn o Aequitas para métricas por grupo.	AIF360 si necesitas comparar técnicas de mitigación.
Pipeline TensorFlow/TFX	Fairness Indicators y What-If Tool.	Reporte versionado y gate por slice en CI.
SageMaker	SageMaker Clarify.	Model Monitor, Model Cards y job recurrente por slice.
Azure ML	Responsible AI dashboard.	Componente de evaluación que exporte métricas a tu release.
Producto con tráfico real	Evidently, Fiddler, Arize, WhyLabs o plataforma equivalente.	SLO por slice, owner, alerta, runbook y comparación contra validación.
LLM, agente o RAG	Giskard, Evidently, Arize Phoenix u otras evals propias.	Dataset de pares mínimos, prompts de regresión, trazas y revisión humana en casos críticos.
Auditoría académica o de clase	Kit propio + Fairlearn/AIF360/Aequitas.	Informe reproducible, model card, data card y defensa oral de decisiones.

Para decidir, yo haría esta prueba: toma diez filas reales, un contrato de política y una métrica por slice. Si la herramienta no puede decirte qué fila falló, en qué slice, con qué métrica, contra qué baseline, desde qué versión y qué acción toca, aún no tienes una herramienta de auditoría; tienes una visualización.

Qué evitar al comprar o adoptar una herramienta

1. Elegir por capturas de pantalla. Hay que pedir exportaciones, API, reproducibilidad y ejemplos con tus datos.
2. Medir fairness solo en validación y olvidarlo en producción. La distribución cambia y los slices también.
3. Usar atributos de auditoría sin política de acceso. Medir requiere permiso, minimización y propósito.
4. Mitigar antes de diagnosticar. No es igual falta de cobertura, proxy, mala etiqueta, mala calibración o umbral mal puesto.
5. Comparar herramientas sin el mismo dataset, split, métrica y política de decisión.
6. Aceptar métricas por defecto sin traducirlas a coste. Paridad, recall, falsos positivos y calibración no responden la misma pregunta.
7. Confundir un panel verde con una decisión publicable. La salida debe ser pass, review o block, con evidencia.

La regla práctica es sencilla: usa herramientas, pero no les delegues el criterio. Una herramienta calcula, visualiza, alerta o ejecuta una técnica. El equipo decide qué métrica representa la consecuencia que quiere controlar, qué slices importan y qué se hace cuando algo no pasa.

Caso completo: de block a review

Un buen capítulo de sesgos no puede quedarse en “usa una herramienta”. Tiene que enseñar una historia completa: una política parece razonable, falla en slices críticos, se propone una mitigación y se vuelve a medir. Eso es lo que hace el kit.

La política base dice:

Decisión	Regla
priorizar	score >= 0.78
normal	score < 0.38
revisar	0.38 <= score < 0.78

Con esa política, el resultado global queda en block: captura segura 0.7778, pérdida operativa 0.2222, tasa de revisión 0.3611 y coste por caso 1.4056. El problema no es solo la media. En los slices críticos aparece algo peor:

Slice crítico	n	Positivos	Auto-recall	Pérdida	Captura segura	Revisión	Coste por caso
language=en	9	4	0.25	0.25	0.75	0.5556	1.5556
access_need=si	12	6	0.0	0.6667	0.3333	0.5	3.2667
`product=practicas	access_need=si`	4	2	0.0	1.0	0.0	0.5

La lectura humana es directa: algunos casos prioritarios con necesidad de accesibilidad o en inglés están yendo a flujo normal. No basta con decir “la accuracy global es aceptable”. La política está dejando pasar casos que el contrato considera críticos.

La mitigación candidata no cambia el modelo. Cambia la política de decisión: amplía la banda de revisión bajando el umbral de flujo normal de 0.38 a 0.32.

Decisión	Política base	Política candidata
priorizar	score >= 0.78	score >= 0.78
normal	score < 0.38	score < 0.32
revisar	0.38 <= score < 0.78	0.32 <= score < 0.78

El antes/después queda así:

Política	Estado	Captura segura	Pérdida operativa	Tasa de revisión	Coste por caso	Flags block	Flags review
Base	block	0.7778	0.2222	0.3611	1.4056	5	7
Banda de revisión	review	1.0	0.0	0.5278	0.7167	0	5

Esto no significa “ya está arreglado”. Significa algo más interesante para ingeniería: la candidata elimina los casos prioritarios enviados a flujo normal, pero aumenta la carga de revisión humana. Pasa de block a review, no a pass. Si el equipo no puede revisar aproximadamente el 53 % de los casos, la mitigación mejora una métrica y rompe la operación. Por eso fairness, coste y capacidad deben leerse juntos.

La matemática mínima de la mitigación

En un proyecto serio no se elige mitigación porque “suena mejor”. Ejemplo de fórmula: podemos formularla como una optimización con restricciones. La estructura viene de optimización con restricciones, pero las variables y límites de este ejemplo son una traducción práctica para el caso del capítulo.

$$\min_{\theta,\tau}\ \mathcal{L}(\theta,\tau;D_{val}) \quad \text{sujeto a}\quad \Delta_m(S) \leq \epsilon_m,\quad C(\tau) \leq B$$

Donde:

Símbolo	Qué significa en este capítulo
$\theta$	Parámetros del modelo o configuración que produce el score.
$\tau$	Política de umbrales: cuándo priorizar, revisar o mandar a flujo normal.
$\mathcal{L}$	Pérdida: error, coste, latencia o combinación definida por el equipo.
$D_{val}$	Validación, no test. Aquí se decide la política antes de medir en test.
$S$	Conjunto de slices auditados.
$\Delta_m(S)$	Disparidad máxima entre slices para una métrica $m$.
$\epsilon_m$	Límite aceptado para esa disparidad.
$C(\tau)$	Coste operativo de la política: revisión, falsos positivos, falsos negativos.
$B$	Presupuesto operativo: capacidad humana, dinero o latencia disponible.

La parte importante es la palabra sujeto a. No queremos solo minimizar error global. Queremos minimizarlo sin romper restricciones de slices, coste y operación. Fairlearn lo expresa con reducciones y restricciones; AIF360 ofrece varias familias de mitigación; nuestro kit lo enseña con algo más humilde pero más transparente: umbrales, gates, slices y coste.

Hay tres familias de respuesta:

Familia	Qué optimiza	Ejemplo en el kit	Cuándo sirve
Cambiar datos	Mejorar cobertura o etiquetas.	Recolectar más casos access_need=si.	Cuando el slice falla porque casi no hay evidencia fiable.
Cambiar modelo	Modificar entrenamiento o representación.	Reentrenar con features, embeddings o pérdidas mejor controladas.	Cuando el score separa mal en ciertos segmentos.
Cambiar política	Modificar umbrales, revisión o automatización.	Ampliar banda de revisión de 0.38 a 0.32.	Cuando el score es incierto y la consecuencia de mandar a flujo normal es alta.

La mitigación por política suele ser la primera que un equipo puede probar porque no exige reentrenar. También es peligrosa si se usa sin capacidad: cada caso enviado a revisión debe tener owner, SLA, registro y criterio de cierre.

De validación a producción

La auditoría no termina al generar slice_metrics.csv. En producción pueden cambiar los canales, idiomas, productos, prompts, documentos, colas humanas o criterios de etiqueta. Por eso los mismos slices deben convertirse en señales operativas.

Señal en producción	Qué mide	Qué acción debería disparar
review_rate por slice	Carga humana que genera la política.	Ajustar capacidad, revisar umbral o limitar automatización.
miss_rate con etiqueta retrasada	Casos importantes que acabaron en flujo normal.	Abrir revisión de política y bloquear aumento de automatización.
Drift de distribución por slice	Cambio en canales, idiomas, productos o perfiles.	Comparar contra validación y revisar datos de entrenamiento.
Latencia p95 por slice	Si ciertos casos tardan más en resolverse.	Revisar pipeline, herramientas o colas específicas.
Tasa de apelación o corrección	Si usuarios o revisores corrigen más un segmento.	Revisar etiqueta, interfaz, rúbrica o explicación.

Esta es la conexión natural con DataOps: un SLI por slice no es una frase bonita, es una medida que se calcula. Un SLO por slice no es “queremos hacerlo bien”, es un objetivo que decide si se mantiene, se revisa o se detiene una política.

En un proyecto real

En un proyecto de IA aplicada, los slices deben definirse antes de mirar el resultado final. Puedes añadir nuevos slices cuando aparece una señal nueva, pero no deberías probar veinte cortes hasta encontrar el que cuenta la historia que querías contar.

Una plantilla mínima de decisión sería:

Pregunta	Respuesta que debe existir
¿Cuál es la unidad de decisión?	Caso, usuario, documento, consulta, turno, sesión.
¿Qué campos se usan como features?	Lista permitida y lista prohibida.
¿Qué campos se usan solo para auditoría?	Segmentos agregados, con permiso y propósito claro.
¿Qué slices son críticos?	Los que no pueden fallar aunque la media global pase.
¿Qué métrica gobierna cada slice?	Recall, miss rate, revisión, coste, latencia, calibración.
¿Qué gate decide?	Umbral medible de pass, review o block.
¿Qué acción sigue si falla?	Más datos, revisión de etiqueta, cambio de umbral, desautomatización, monitorización.

Para un ingeniero, lo más peligroso no es que el reporte diga block. Lo peligroso es que no exista reporte. Sin slices, la decisión parece técnica porque tiene números, pero no tiene trazabilidad.

Manos a la obra

El kit del capítulo está en:

kit/

La práctica parte de predicciones ya generadas. No entrena un modelo. No mueve el umbral para mejorar el resultado. Toma una política congelada, la aplica sobre test y produce una auditoría por slices.

Estructura

kit/
  README.md
  data/decision_predictions.csv
  contracts/slice_decision_policy.json
  contracts/slice_decision_policy_review_band.json
  contracts/bias_audit_playbook.md
  ops/audit_decision_slices.py
  ops/compare_mitigation.py
  ops/audit_with_fairlearn.py
  output/slice_audit_report.json
  output/slice_metrics.csv
  output/slice_decision.md
  output/slice_audit_card.md
  output/mitigation_before_after.md
  output/mitigation_before_after.csv
  output/mitigation_critical_slices.csv

Cómo lo ejecutas

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/audit_decision_slices.py --write
cat output/slice_decision.md
python3 -m json.tool output/slice_audit_report.json

Para ver el antes/después de la mitigación por banda de revisión:

python3 ops/compare_mitigation.py --write
cat output/mitigation_before_after.md

Para repetir parte de la lectura con Fairlearn o con el fallback estándar si no tienes dependencias instaladas:

python3 ops/audit_with_fairlearn.py --field access_need --write
python3 -m json.tool output/fairlearn_metricframe.json

Si quieres obtener el MetricFrame real de Fairlearn, crea un entorno e instala dependencias antes de repetir el comando:

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install pandas fairlearn
python3 ops/audit_with_fairlearn.py --field access_need --write
python3 -m json.tool output/fairlearn_metricframe.json

Qué deberías ver

El resultado esperado queda en block. No porque el sistema no acierte nada, sino porque los gates conectan métricas con consecuencias:

{
  "release_status": "block",
  "overall": {
    "n": 36,
    "safety_capture": 0.7778,
    "miss_rate": 0.2222,
    "review_rate": 0.3611
  }
}

La lectura humana aparece en output/slice_decision.md:

Estado: block
La captura segura global queda por debajo del mínimo.
Un slice crítico contiene casos prioritarios enviados a flujo normal.

La salida más importante para ingeniería es output/slice_metrics.csv. Ahí puedes ordenar por miss_rate, review_rate, cost_per_case o auto_recall. Si solo miras overall, te pierdes el motivo de la decisión.

El archivo contracts/bias_audit_playbook.md funciona como checklist profesional. No calcula nada: obliga a escribir unidad de decisión, fuentes de sesgo, señales detectables, gates, buenas prácticas y cosas que evitar. Es el tipo de documento que conviene tener junto al reporte automático, porque una auditoría no es solo matemática; también es criterio operativo.

El archivo output/mitigation_before_after.md funciona como defensa técnica. Enseña que una mitigación aceptable no se resume en “mejoró la métrica”: debe declarar qué bajó, qué subió, qué coste aparece y por qué la política candidata queda en review.

El script ops/audit_with_fairlearn.py no sustituye el kit. Lo conecta con una herramienta real. Si instalas pandas y fairlearn, genera un MetricFrame por el campo elegido y permite comparar la lectura propia con una librería profesional. Esa comparación es valiosa porque evita dos extremos: reinventarlo todo o delegarlo todo.

Qué cambia si lo adaptas a tu caso

Si tu proyecto tiene...	Cambia esto
Un clasificador de incidencias	true_priority, costes y slices por producto/canal.
Un RAG de soporte	Slices por tipo de documento, idioma, fecha de actualización y fuente.
Un evaluador automático	Slices por criterio de rúbrica, longitud, idioma y tipo de fallo.
Un sistema con revisión humana	Coste de revisión y capacidad diaria.
Un modelo local y uno cloud	Añade slice por proveedor, latencia y coste.
Documentos con permisos	Audita recuperación por permisos y origen, no solo por texto.
Pocos casos por segmento	Usa review y recolecta más datos antes de automatizar.

Qué entregaría un alumno

1. slice_audit_report.json generado.
2. slice_metrics.csv ordenado por una métrica elegida.
3. slice_decision.md explicado con sus propias palabras.
4. Dos slices nuevos justificados para su proyecto.
5. Un cambio en slice_decision_policy.json y explicación de por qué no se ha elegido mirando test.
6. Una propuesta de recogida de datos para slices con muestra insuficiente.
7. Una ficha slice_audit_card.md lista para adjuntar a una model card o data card.
8. Una versión adaptada de bias_audit_playbook.md para su propio dominio.
9. mitigation_before_after.md explicado como trade-off de ingeniería.
10. Una salida opcional de Fairlearn o una justificación de por qué otra herramienta encaja mejor.

Cómo encaja todo

Este mapa debe leerse como continuidad de ingeniería. Los capítulos anteriores construyeron el suelo: linaje, calidad, split honesto y representación. Este capítulo pregunta si la política resultante se comporta de forma defendible en los segmentos que importan. Después, el capítulo 06 usará estos mismos slices como señales de monitorización: si producción cambia, no miraremos solo drift global.

La decisión central aquí es pasar de “mi métrica global mejora” a “sé qué slices sostienen o impiden automatizar”. Esa decisión conecta directamente con evaluación, calibración, interpretabilidad y gobernanza.

graph TD
    subgraph "Este capítulo"
        UNIT["Unidad de decisión"]
        POLICY["Política congelada"]
        FIELDS["Campos de auditoría"]
        SLICE["Slices críticos"]
        MET["Métricas por slice"]
        UNC["Tamaño e intervalo"]
        GATE["Gate de decisión"]
        ART["Reporte y card"]
    end
    subgraph "Mismo facsímil"
        C01["Linaje<br/>cap. 1"]
        C02["Etiquetas<br/>cap. 2"]
        C03["Test honesto<br/>cap. 3"]
        C04["Representación<br/>cap. 4"]
        C06["Drift por slice<br/>cap. 6"]
        C07["Causalidad<br/>cap. 7"]
    end
    subgraph "Otros facsímiles"
        CAL["Calibración<br/>fasc. 7"]
        INT["Interpretabilidad<br/>fasc. 7"]
        OPS["EvalOps<br/>fasc. 6"]
        GOV["Gobernanza<br/>fasc. 9"]
    end

    C01 -->|"define campos"| FIELDS
    C02 -->|"define etiquetas"| MET
    C03 -->|"reserva test"| POLICY
    C04 -->|"define señal"| UNIT
    CAL -->|"da umbrales"| POLICY

    UNIT -->|"se evalúa con"| POLICY
    POLICY -->|"se mira por"| SLICE
    FIELDS -->|"segmenta"| SLICE
    SLICE -->|"calcula"| MET
    MET -->|"exige"| UNC
    UNC -->|"matiza"| GATE
    MET -->|"activa"| GATE
    GATE -->|"documenta"| ART

    GATE -->|"se monitoriza en"| C06
    SLICE -->|"pide experimento en"| C07
    ART -->|"ayuda a explicar"| INT
    GATE -->|"se automatiza en"| OPS
    FIELDS -->|"deja límites"| GOV

    style UNIT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style POLICY fill:#F5F5F5,stroke:#000000,stroke-width:2
    style FIELDS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SLICE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MET fill:#F5F5F5,stroke:#000000,stroke-width:2
    style UNC fill:#F5F5F5,stroke:#000000,stroke-width:2
    style GATE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ART fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C01 stroke-dasharray: 5 5
    style C02 stroke-dasharray: 5 5
    style C03 stroke-dasharray: 5 5
    style C04 stroke-dasharray: 5 5
    style C06 stroke-dasharray: 5 5
    style C07 stroke-dasharray: 5 5
    style CAL stroke-dasharray: 5 5
    style INT stroke-dasharray: 5 5
    style OPS stroke-dasharray: 5 5
    style GOV stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición breve
Slice	Subconjunto de datos definido por una condición útil para evaluar una decisión.
Atributo de auditoría	Campo usado para medir comportamiento por segmentos.
Atributo no usado por el modelo	Campo que no entra como feature, pero puede usarse para auditoría agregada.
Paridad demográfica	Comparación de tasas de selección entre grupos.
Igualdad de oportunidad	Comparación de verdaderos positivos entre grupos positivos reales.
Odds igualadas	Comparación simultánea de verdaderos positivos y falsos positivos entre grupos.
Calibración por grupo	Comprobación de que un score significa algo parecido en cada grupo.
Disparidad	Diferencia medible entre slices para una métrica concreta.
Captura segura	Proporción de casos importantes priorizados o enviados a revisión.
Gate	Regla medible que convierte métricas en decisión de release.
Proxy	Variable que sustituye a otra más difícil de medir, con riesgo de medir otra cosa.
OOV	Término fuera del vocabulario usado para construir una representación textual.
Par mínimo	Dos entradas casi iguales que solo cambian una pieza controlada.
WEAT	Test de asociación para medir relaciones entre grupos de palabras en embeddings.
Intersección	Slice definido por la combinación de varios atributos.

Dónde solía tropezar yo

Tropiezo	Por qué ocurre	Antídoto
Mirar solo la media global	Es cómoda y fácil de explicar.	Exigir slices críticos antes de aprobar.
Partir por demasiadas columnas	Parece más completo.	Empezar por hipótesis de decisión y coste.
Confundir auditoría con feature	Si tengo el campo, parece que puedo usarlo.	Separar fields_not_for_model y audit_fields.
Ajustar umbrales mirando test	Es tentador arreglar el slice que falla.	Congelar umbrales desde validation y versionar la política.
Ignorar tamaños pequeños	Una tabla con números da sensación de rigor.	Añadir mínimos, intervalos y estado review.
Elegir una métrica de equidad sin contexto	La palabra suena suficiente.	Preguntar qué error controla y qué compromiso acepta.
No dejar acción concreta	El reporte se queda en diagnóstico.	Escribir decisión, dueño, gate y siguiente paso.

Antes de pasar página

Antes de avanzar, deberías poder responder:

1. ¿Qué es un slice y por qué no equivale a cualquier columna?
2. ¿Qué diferencia hay entre feature y atributo de auditoría?
3. ¿Por qué una métrica global puede esconder un problema importante?
4. ¿Qué mide la paridad demográfica?
5. ¿Qué mide la igualdad de oportunidad?
6. ¿Por qué odds igualadas mira verdaderos positivos y falsos positivos?
7. ¿Qué significa que algunas nociones de equidad sean incompatibles en ciertos escenarios?
8. ¿Por qué conviene separar auto-recall y captura segura?
9. ¿Qué coste se asigna en el kit a un falso negativo operativo?
10. ¿Por qué access_need=si bloquea la política del kit?
11. ¿Qué archivo contiene la tabla plana de métricas por slice?
12. ¿Qué harías si un slice crítico tiene muestra insuficiente?
13. ¿Por qué no se deben ajustar umbrales mirando test?
14. ¿Cómo conectarías esta auditoría con una model card?
15. ¿Qué slices monitorizarías en producción en el capítulo siguiente?
16. ¿Qué diferencia hay entre sesgo de cobertura, medición, proxy y representación?
17. ¿Por qué los estudios de embeddings no se detectan igual que los de clasificación?
18. ¿Qué señal usarías para detectar falsos positivos asociados a términos concretos?
19. ¿Qué significa probar pares mínimos o contrafactuales?
20. ¿Qué parte del playbook adaptarías primero a tu proyecto?
21. ¿Por qué la política candidata pasa de block a review, pero no a pass?
22. ¿Qué trade-off aparece al ampliar la banda de revisión?
23. ¿Qué representa $\Delta_m(S)$ en una mitigación con restricciones?
24. ¿Qué pedirías a una herramienta antes de incorporarla al ciclo de release?
25. ¿Qué SLI por slice monitorizarías cuando el sistema llegue a producción?

En resumen

Idea	Qué te llevas
La media global no decide sola.	Hay que mirar slices conectados con consecuencias reales.
Un campo puede auditar sin decidir.	No todo atributo útil para medir debe entrar al modelo.
La métrica depende del error.	Paridad, oportunidad, odds y calibración responden preguntas distintas.
El tamaño importa.	Un slice pequeño pide revisión o más datos, no conclusión fuerte.
La auditoría debe producir acción.	Reporte, CSV, card y decisión son artefactos de ingeniería.
Los sesgos tienen mecanismos distintos.	Cobertura, proxy, etiqueta, representación y política requieren pruebas diferentes.
Las buenas prácticas se escriben antes de test.	Si eliges slices y gates después, la auditoría pierde fuerza.
Mitigar implica trade-offs.	La banda de revisión reduce pérdida, pero aumenta carga humana.
Las herramientas no deciden solas.	Fairlearn, AIF360, Clarify o Evidently ayudan si hay contrato, slices y gates.
Producción cambia la pregunta.	Los mismos slices deben convertirse en SLI, SLO, alerta y runbook.

Para saber más

Bellamy, R. K. E., Dey, K., Hind, M., Hoffman, S. C., Houde, S., Kannan, K., Lohia, P., Martino, J., Mehta, S., Mojsilovic, A., Nagar, S., Ramamurthy, K. N., Richards, J., Saha, D., Sattigeri, P., Singh, M., Varshney, K. R. y Zhang, Y. (2019). AI Fairness 360: An Extensible Toolkit for Detecting and Mitigating Algorithmic Bias. IBM Journal of Research and Development, 63(4/5), 4:1-4:15. DOI

Amazon Web Services. (2026). Amazon SageMaker Clarify. Documentación

Arize AI. (2026). ML Observability Platform. Producto

Arthur AI. (2020). Product Update - Bias Monitoring v2.1. Blog

Bolukbasi, T., Chang, K.-W., Zou, J. Y., Saligrama, V. y Kalai, A. T. (2016). Man is to Computer Programmer as Woman is to Homemaker? Debiasing Word Embeddings. Advances in Neural Information Processing Systems 29, 4349-4357. Paper

Buolamwini, J. y Gebru, T. (2018). Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification. Proceedings of Machine Learning Research, 81, 77-91. Paper

Caliskan, A., Bryson, J. J. y Narayanan, A. (2017). Semantics Derived Automatically from Language Corpora Contain Human-Like Biases. Science, 356(6334), 183-186. DOI

Center for Data Science and Public Policy. (2026). Aequitas documentation. Documentación

Chouldechova, A. (2017). Fair Prediction with Disparate Impact: A Study of Bias in Recidivism Prediction Instruments. Big Data, 5(2), 153-163. DOI

Dixon, L., Li, J., Sorensen, J., Thain, N. y Vasserman, L. (2018). Measuring and Mitigating Unintended Bias in Text Classification. Proceedings of the 2018 AAAI/ACM Conference on AI, Ethics, and Society, 67-73. Google Research

Dwork, C., Hardt, M., Pitassi, T., Reingold, O. y Zemel, R. (2012). Fairness Through Awareness. Proceedings of the 3rd Innovations in Theoretical Computer Science Conference, 214-226. DOI

Evidently AI. (2026). Evidently documentation. Documentación

Fairlearn. (2026). Assessment: Performing a Fairness Assessment. Documentación

Fairlearn. (2026). Mitigations. Documentación

Fiddler AI. (2026). Fairness. Documentación

Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. y Crawford, K. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), 86-92. DOI

Giskard. (2026). Giskard documentation. Documentación

Hardt, M., Price, E. y Srebro, N. (2016). Equality of Opportunity in Supervised Learning. Advances in Neural Information Processing Systems 29, 3323-3331. Paper

IBM Research. (2026). AI Fairness 360 documentation. Documentación

Kleinberg, J., Mullainathan, S. y Raghavan, M. (2017). Inherent Trade-Offs in the Fair Determination of Risk Scores. arXiv

Microsoft. (2026). Use the Responsible AI dashboard in Azure Machine Learning studio. Documentación

Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. y Gebru, T. (2019). Model Cards for Model Reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency, 220-229. DOI

Nadeem, M., Bethke, A. y Reddy, S. (2021). StereoSet: Measuring Stereotypical Bias in Pretrained Language Models. ACL-IJCNLP 2021, 5356-5371. DOI

Nangia, N., Vania, C., Bhalerao, R. y Bowman, S. R. (2020). CrowS-Pairs: A Challenge Dataset for Measuring Social Biases in Masked Language Models. EMNLP 2020, 1953-1967. DOI

Obermeyer, Z., Powers, B., Vogeli, C. y Mullainathan, S. (2019). Dissecting Racial Bias in an Algorithm Used to Manage the Health of Populations. Science, 366(6464), 447-453. DOI

Parrish, A., Chen, A., Nangia, N., Padmakumar, V., Phang, J., Thompson, J., Htut, P. M. y Bowman, S. R. (2022). BBQ: A Hand-Built Bias Benchmark for Question Answering. Findings of ACL 2022, 2086-2105. DOI

Raji, I. D., Smart, A., White, R. N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D. y Barnes, P. (2020). Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing. arXiv

Responsibly. (2026). Responsibly documentation. Documentación

TensorFlow. (2026). Fairness Indicators. GitHub

Wexler, J., Pushkarna, M., Bolukbasi, T., Wattenberg, M., Viégas, F. y Wilson, J. (2019). The What-If Tool: Interactive Probing of Machine Learning Models. IEEE Transactions on Visualization and Computer Graphics. Google Research

WhyLabs. (2026). WhyLabs documentation. Documentación

Notas

1. Hardt, M., Price, E. y Srebro, N. (2016). Equality of Opportunity in Supervised Learning. Advances in Neural Information Processing Systems 29, 3323-3331. https://papers.nips.cc/paper/6374-equality-of-opportunity-in-supervised-learning ↩

2. Chouldechova, A. (2017). Fair Prediction with Disparate Impact: A Study of Bias in Recidivism Prediction Instruments. Big Data, 5(2), 153-163. https://doi.org/10.1089/big.2016.0047 ↩

3. Kleinberg, J., Mullainathan, S. y Raghavan, M. (2017). Inherent Trade-Offs in the Fair Determination of Risk Scores. https://arxiv.org/abs/1609.05807 ↩

4. Obermeyer, Z., Powers, B., Vogeli, C. y Mullainathan, S. (2019). Dissecting Racial Bias in an Algorithm Used to Manage the Health of Populations. Science, 366(6464), 447-453. https://doi.org/10.1126/science.aax2342 ↩

5. Bolukbasi, T., Chang, K.-W., Zou, J. Y., Saligrama, V. y Kalai, A. T. (2016). Man is to Computer Programmer as Woman is to Homemaker? Debiasing Word Embeddings. NeurIPS 2016, 4349-4357. https://papers.nips.cc/paper/6228-man-is-to-computer-programmer-as-woman-is-to-homemaker-debiasing-word-embeddings ↩

6. Caliskan, A., Bryson, J. J. y Narayanan, A. (2017). Semantics Derived Automatically from Language Corpora Contain Human-Like Biases. Science, 356(6334), 183-186. https://doi.org/10.1126/science.aal4230 ↩

7. Buolamwini, J. y Gebru, T. (2018). Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification. Proceedings of Machine Learning Research, 81, 77-91. https://proceedings.mlr.press/v81/buolamwini18a.html ↩

8. Dixon, L., Li, J., Sorensen, J., Thain, N. y Vasserman, L. (2018). Measuring and Mitigating Unintended Bias in Text Classification. AIES 2018, 67-73. https://research.google/pubs/measuring-and-mitigating-unintended-bias-in-text-classification/ ↩

9. Nangia, N., Vania, C., Bhalerao, R. y Bowman, S. R. (2020). CrowS-Pairs: A Challenge Dataset for Measuring Social Biases in Masked Language Models. EMNLP 2020, 1953-1967. https://doi.org/10.18653/v1/2020.emnlp-main.154 ↩

10. Nadeem, M., Bethke, A. y Reddy, S. (2021). StereoSet: Measuring Stereotypical Bias in Pretrained Language Models. ACL-IJCNLP 2021, 5356-5371. https://doi.org/10.18653/v1/2021.acl-long.416 ↩

11. Parrish, A. et al. (2022). BBQ: A Hand-Built Bias Benchmark for Question Answering. Findings of ACL 2022, 2086-2105. https://doi.org/10.18653/v1/2022.findings-acl.165 ↩

12. Fairlearn. (2026). Assessment: Performing a Fairness Assessment. https://fairlearn.org/main/user_guide/assessment/. Consultado el 7 de junio de 2026. ↩

13. Fairlearn. (2026). Mitigations. https://fairlearn.org/main/user_guide/mitigation/index.html. Consultado el 7 de junio de 2026. ↩

14. IBM Research. (2026). AI Fairness 360 documentation. https://aif360.readthedocs.io/en/stable/index.html. Consultado el 7 de junio de 2026. ↩

15. Bellamy, R. K. E. et al. (2019). AI Fairness 360: An Extensible Toolkit for Detecting and Mitigating Algorithmic Bias. IBM Journal of Research and Development, 63(4/5), 4:1-4:15. https://doi.org/10.1147/JRD.2019.2942287 ↩

16. Center for Data Science and Public Policy. (2026). Aequitas documentation. https://dssg.github.io/aequitas/. Consultado el 7 de junio de 2026. ↩

17. TensorFlow. (2026). Fairness Indicators. https://github.com/tensorflow/fairness-indicators. Consultado el 7 de junio de 2026. ↩

18. Wexler, J. et al. (2019). The What-If Tool: Interactive Probing of Machine Learning Models. IEEE TVCG. https://research.google/pubs/the-what-if-tool-interactive-probing-of-machine-learning-models/ ↩

19. Responsibly. (2026). Responsibly documentation. https://docs.responsibly.ai/. Consultado el 7 de junio de 2026. ↩

20. Amazon Web Services. (2026). Amazon SageMaker Clarify. https://aws.amazon.com/sagemaker/ai/clarify/. Consultado el 7 de junio de 2026. ↩

21. Microsoft. (2026). Use the Responsible AI dashboard in Azure Machine Learning studio. https://learn.microsoft.com/en-us/azure/machine-learning/how-to-responsible-ai-dashboard. Consultado el 7 de junio de 2026. ↩

22. Evidently AI. (2026). Evidently documentation. https://docs.evidentlyai.com/docs/library/overview. Consultado el 7 de junio de 2026. ↩

23. Giskard. (2026). Giskard documentation. https://docs.giskard.ai/. Consultado el 7 de junio de 2026. ↩

24. Fiddler AI. (2026). Fairness. https://docs.fiddler.ai/observability/fairness. Consultado el 7 de junio de 2026. ↩

25. Arize AI. (2026). ML Observability Platform. https://arize.com/capabilities/. Consultado el 7 de junio de 2026. ↩

26. WhyLabs. (2026). WhyLabs documentation. https://docs.whylabs.ai/docs/. Consultado el 7 de junio de 2026. ↩

27. Arthur AI. (2020). Product Update - Bias Monitoring v2.1. https://www.arthur.ai/blog/product-update-bias-monitoring-v21. Consultado el 7 de junio de 2026. ↩