Parseo de Datos en Múltiples Formatos para IA Conversacional

Cómo el Layer 1 de UNCASE procesa exportaciones de WhatsApp, logs de CRM, transcripciones JSON y más — unificando formatos de conversación dispares en un esquema estandarizado.

ArchitectureParserData PipelineWhatsApp
M
Escrito porMariano Morales
Tiempo de lectura7 min
Publicado el15 de enero de 2026
Architecture
Parseo de Datos en Múltiples Formatos para IA Conversacional

El problema con los formatos de datos

Las conversaciones del mundo real existen en decenas de formatos incompatibles entre sí. Una organización de salud, por ejemplo, puede tener:

  • WhatsApp Business con exportaciones de soporte al paciente
  • Logs del CRM generados por el sistema de turnos
  • Archivos de transcripción de llamadas de consulta
  • Logs del chat web embebido en su sitio
  • Hilos de email de seguimiento post-consulta

Cada formato tiene estructuras distintas, formatos de timestamp diferentes, indicadores de rol propios y metadatos incompatibles. El Layer 1 del framework SCSF resuelve esto con un parser universal que normaliza todo hacia un esquema estandarizado.

Formatos soportados

Exportaciones de WhatsApp

Las exportaciones de WhatsApp son una de las fuentes de conversación más frecuentes, en especial en mercados latinoamericanos donde WhatsApp Business es el canal de atención al cliente por excelencia.

from uncase.core.parser import Parser

parser = Parser()

# Parse WhatsApp export
conversations = parser.parse(
    "./whatsapp-export.txt",
    format="whatsapp"
)

El parser de WhatsApp maneja:

  • Múltiples formatos de fecha (MM/DD/YY, DD/MM/YY, YYYY-MM-DD)
  • Placeholders de archivos adjuntos multimedia
  • Mensajes del sistema (ingresos, salidas, avisos de cifrado)
  • Mensajes multilínea
  • Chats grupales con detección de roles

Exportaciones JSON de CRM

# Parse CRM JSON
conversations = parser.parse(
    "./crm-tickets.json",
    format="json",
    mapping={
        "turns_key": "messages",
        "role_key": "sender_type",
        "content_key": "body",
        "timestamp_key": "created_at"
    }
)

Transcripciones VTT/SRT

# Parse call transcription
conversations = parser.parse(
    "./call-recording.vtt",
    format="vtt",
    speaker_map={"Speaker 1": "agent", "Speaker 2": "client"}
)

El esquema estandarizado

Sin importar el formato de entrada, todas las conversaciones se normalizan hacia el esquema interno de SCSF:

interface ParsedConversation {
  id: string
  source_format: string
  language: string
  turns: Turn[]
  metadata: ConversationMetadata
  validation: ValidationResult
}

interface Turn {
  index: number
  role: 'agent' | 'client' | 'system'
  content: string
  timestamp?: string
  metadata?: Record<string, unknown>
}

Reglas de validación

Toda conversación parseada debe pasar los siguientes controles:

ReglaDescripciónAcción ante fallo
Turnos mínimosAl menos 4 turnosRechazada
Alternancia de rolesLos roles deben alternarse (con excepciones para mensajes múltiples)Advertencia
Longitud de contenidoCada turno debe tener ≥ 5 caracteresRechazada
Consistencia de idiomaTodos los turnos deben estar en el mismo idiomaAdvertencia
Pre-escaneo de PIIEscaneo rápido de PII antes del procesamiento completoMarcada
CodificaciónCodificación UTF-8 válidaAutocorregida
result = parser.parse("./data.txt", format="whatsapp")

print(f"Total: {result.total}")
print(f"Valid: {result.valid}")
print(f"Rejected: {result.rejected}")
print(f"Warnings: {result.warnings}")

# Access validation details
for error in result.errors:
    print(f"  {error.conversation_id}: {error.rule} — {error.message}")

Uso desde la CLI

# Parse WhatsApp export
uncase parse whatsapp ./export.txt --output ./parsed/

# Parse with custom format
uncase parse json ./crm-data.json \
  --mapping '{"turns_key":"messages","role_key":"type"}' \
  --output ./parsed/

# Batch parse directory
uncase parse batch ./raw-data/ \
  --formats whatsapp,json,vtt \
  --output ./parsed/ \
  --report ./parsing-report.json

Manejo de errores

El parser aplica una jerarquía estricta de errores:

  1. Errores fatales: archivo inválido, formato no reconocido → lanza excepción
  2. Errores a nivel de conversación: demasiado pocos turnos, roles inválidos → conversación descartada y registrada
  3. Errores a nivel de turno: contenido vacío, problemas de codificación → turno corregido o descartado
  4. Advertencias: quiebres en la alternancia de roles, mezcla de idiomas → marcadas pero no rechazadas

Todos los errores se registran con logging estructurado para garantizar trazabilidad y cumplimiento normativo:

import structlog
logger = structlog.get_logger()

# Automatic structured logging
logger.info("conversation_parsed",
    conversation_id=conv.id,
    format="whatsapp",
    turns=len(conv.turns),
    validation="passed"
)

Conclusiones clave

  1. Las conversaciones reales existen en decenas de formatos — un parser universal elimina la conversión manual
  2. La normalización del esquema garantiza un procesamiento downstream consistente sin importar la fuente
  3. Las reglas de validación detectan problemas de calidad antes de que contaminen el pipeline
  4. El parser es extensible — se pueden incorporar formatos personalizados mediante plugins de formato
  5. El logging estructurado mantiene una trazabilidad completa para cumplimiento normativo

Comienza a Construir IA Privacy-First Hoy

Despliega el pipeline completo, conecta tus fuentes de datos, enruta a cualquier proveedor LLM y produce adaptadores LoRA conformes — todo sin exponer un solo dato.

0%PII en datos finales
0+Endpoints de API
0Industrias reguladas
0+Tests pasando