Capstone — Fase 2: el corpus

Con los criterios firmados en la fase 1, la tentación es saltar al agente. Resistimos una fase más, porque el agente de la fase 3 consumirá dos cuerpos de datos que hoy existen solo como materia prima desordenada — y el curso de Data Engineering fue inequívoco sobre qué pasa cuando ese eslabón se improvisa. Esta fase lo ejecuta en pequeño y completo: el pipeline mínimo digno del proyecto.

La tesis de la fase

El agente necesita dos corpus con destinos distintos: el historial de correos etiquetados — que no entrena nada todavía, sino que evalúa (es la materia del dataset contra el que la fase 5 medirá los criterios) — y la base de conocimiento de Finandes, que es de donde el agente sacará cada respuesta con cita. Ambos pasan por la misma disciplina: PII enmascarada antes de persistir, deduplicación antes de cualquier split, auditoría de etiquetas antes de confiar, y metadatos de vigencia — porque en una financiera, responder con la tasa del año pasado no es un error simpático.

Corpus 1: el historial → dataset de evaluación

Finandes tiene lo que el módulo de etiquetado llamó el subproducto operativo: años de correos con la categoría que el equipo les asignó y la respuesta que recibieron. El pipeline que lo convierte en activo, etapa por etapa:

   DEL CRM AL DATASET DE EVALUACIÓN

  CRM (correos + etiquetas históricas)
     │ ingesta incremental (datos-03)
     ▼
  bronce: crudo intacto — retención con
  política, porque hay PII (datos-02/09)
     │
     ▼
  PII scrubbing: [NOMBRE], [RUT], [MONTO_PERSONAL]
  ANTES de la capa de trabajo (datos-09)
     │
     ▼
  dedup difusa MinHash — las plantillas de
  respuesta se repiten por miles (datos-09)
     │
     ▼
  auditoría de etiquetas: muestra de 300 contra
  la guía de anotación nueva (datos-08)
     │
     ▼
  dataset_eval v1: ~1.500 correos etiquetados,
  estratificados por categoría — mart con tests
  y versión (datos-05)

Las tres decisiones que definen la calidad del resultado:

• La auditoría antes que la fe. Las etiquetas históricas traen los incentivos de la operación (el “otro” del agente apurado). La muestra de 300 auditada contra una guía de anotación escrita para el proyecto — con los casos limítrofes de Finandes resueltos: “reclamo mencionado de pasada en consulta de cuota → ¿reclamo o facturación?” — nos dio el techo honesto: 91% de las etiquetas históricas son correctas según la guía. Ese número calibra el criterio de la fase 1 (el 92% de acierto exigido al agente está al nivel del techo humano — un 91% que sube al re-etiquetar las 300 auditadas y las categorías con desacuerdo —, no en la fantasía) y marca qué re-etiquetar: las 300 auditadas + las categorías con más desacuerdo.
• PII antes que todo. Cada correo trae nombre, RUT y datos de crédito. El enmascaramiento con placeholders consistentes corre antes de que el dato toque la capa de trabajo — y el placeholder preserva la estructura que el clasificador necesita (“estimados, mi cuota de [MONTO_PERSONAL] llegó duplicada” clasifica igual de bien). El residuo se mide en la aduana: < 0,5% de PII detectable en muestra, o el pipeline no pasa.
• Dedup antes del split. Las respuestas-plantilla y los correos casi idénticos (“¿cuándo vence mi cuota?” en quinientas variantes) inflarían cualquier métrica si caen a ambos lados del split eval/futuro-entrenamiento. MinHash con umbral calibrado mirando qué agrupa — y la fuga train/test queda cerrada antes de existir.

El entregable: dataset_eval v1 — un mart versionado (~1.500 ejemplos estratificados: las categorías raras sobre-muestreadas para que el criterio “ninguna bajo 85%” sea medible) con tests de aduana: etiquetas en el conjunto válido, cero nulos, cero PII residual sobre umbral, linaje hasta el bronce.

Corpus 2: la base de conocimiento → corpus RAG

Lo que el agente podrá decir vive aquí: las FAQ oficiales, las políticas de productos (tasas, plazos, requisitos), los procedimientos de atención y los formatos de certificados de Finandes. El tratamiento sigue la ingesta y el chunking del curso de RAG con dos decisiones propias del dominio:

• Chunking por estructura documental (rag-03): las políticas tienen secciones y las FAQ son pares naturales — el chunk respeta esas fronteras, lo que además estabiliza el diff de la re-indexación cuando el pipeline de la fase 8 lo mantenga fresco.
• Metadatos de vigencia y alcance, obligatorios: cada chunk lleva vigente_desde, vigente_hasta, producto y fuente. En una financiera, la tasa de 2025 respondida en 2026 es el incidente — el retrieval filtrará por vigencia siempre, y la cita de cada respuesta (el criterio de groundedness de la fase 1) apuntará a fuente. La versión chica del principio grande: la base de conocimiento es un producto de datos con dueño — el área de productos de Finandes firma qué documentos entran y cuándo caducan.

El entregable: corpus_rag v1 — ~400 documentos chunkeados con metadatos completos, indexados en pgvector (la decisión vectorial del punto de partida sano: ya hay Postgres, el volumen es moderado — se gradúa si las métricas lo piden), con su aduana: cero chunks vacíos, cero documentos sin vigencia, conteo cuadrando contra fuentes.

Ojo — lo que NO estamos haciendo todavía: ni fine-tuning ni dataset de entrenamiento. La fase 1 no lo exige: el criterio de clasificación (92%) probablemente se alcanza con un buen prompt y ejemplos — y la economía del caso enseñó a no comprar complejidad antes de que la métrica la pida. El historial limpio queda listo para convertirse en dataset de entrenamiento si la fase 9 lo necesita — esa opcionalidad barata es exactamente lo que un pipeline decente compra.

Errores comunes

• Saltarse la auditoría de etiquetas. Evaluar al agente contra etiquetas 91% correctas creyéndolas perfectas produce un 9% de “errores” que son ruido del oráculo. El techo se mide antes de exigir.
• PII después “para avanzar”. El dataset de trabajo con RUTs reales es el incidente esperando el primer acceso amplio. El scrubbing es etapa de ingesta, no tarea pendiente.
• Dedup después del split. El split primero + dedup después deja gemelos a ambos lados y métricas infladas. El orden es ley: dedup, luego split.
• Base de conocimiento sin vigencia. El corpus RAG donde conviven la política vieja y la nueva sin metadatos es una máquina de responder con la tasa equivocada. Vigencia obligatoria, filtrada en el retrieval.
• Corpus sin dueño de negocio. Los documentos que “alguien subió alguna vez” no son una base de conocimiento: son un riesgo indexado. El área de productos firma el catálogo de fuentes.
• Comprar fine-tuning antes de medir. El dataset de entrenamiento construido “porque ya estamos” es costo sin métrica que lo pida. La opcionalidad se guarda; la complejidad se compra cuando la fase 5 muestre el hueco.

La frase para llevarse

“Dos corpus, dos destinos: el historial auditado y limpio para evaluar (con el techo humano medido: 91%), la base de conocimiento con vigencia y dueño para responder con cita. PII antes que todo, dedup antes del split, aduana antes de confiar — el agente de la próxima fase será exactamente tan bueno como lo que esta produjo.”

Qué viene

Fase 3: el prototipo. Por fin, el agente: el grafo de LangGraph que clasifica, decide y responde — con el retrieval sobre el corpus recién construido, las citas obligatorias desde el primer commit, y la decisión de arquitectura que la economía ya tomó por nosotros: un flujo simple de pasos claros, no el agente librepensador que impresiona en demos y arruina presupuestos.

Material relacionado

• Fase 1: el caso y la definición de éxito
• Fase 3: el prototipo
• Data Engineering — Módulo 8: etiquetado y datos de entrenamiento
• Data Engineering — Módulo 9: datos para LLM
• RAG — Módulo 3: chunking