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.

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:
| Regla | Descripción | Acción ante fallo |
|---|---|---|
| Turnos mínimos | Al menos 4 turnos | Rechazada |
| Alternancia de roles | Los roles deben alternarse (con excepciones para mensajes múltiples) | Advertencia |
| Longitud de contenido | Cada turno debe tener ≥ 5 caracteres | Rechazada |
| Consistencia de idioma | Todos los turnos deben estar en el mismo idioma | Advertencia |
| Pre-escaneo de PII | Escaneo rápido de PII antes del procesamiento completo | Marcada |
| Codificación | Codificación UTF-8 válida | Autocorregida |
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:
- Errores fatales: archivo inválido, formato no reconocido → lanza excepción
- Errores a nivel de conversación: demasiado pocos turnos, roles inválidos → conversación descartada y registrada
- Errores a nivel de turno: contenido vacío, problemas de codificación → turno corregido o descartado
- 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
- Las conversaciones reales existen en decenas de formatos — un parser universal elimina la conversión manual
- La normalización del esquema garantiza un procesamiento downstream consistente sin importar la fuente
- Las reglas de validación detectan problemas de calidad antes de que contaminen el pipeline
- El parser es extensible — se pueden incorporar formatos personalizados mediante plugins de formato
- El logging estructurado mantiene una trazabilidad completa para cumplimiento normativo
Artículos relacionados
Posts Relacionados
Sigue explorando con estos análisis técnicos relacionados.

Seed Engineering: From Real Conversations to Abstract Templates
How the SCSF Layer 0 Seed Engine transforms real-world conversations into privacy-safe, reusable seed templates for synthetic data generation.

Differential Privacy in LLM Training: Theory and Practice
Understanding DP-SGD, privacy budgets, and how to train language models with mathematical privacy guarantees for healthcare and financial applications.

Synthetic Data Quality Metrics: ROUGE-L, TTR, and Fidelity Explained
A deep dive into the quality metrics used to evaluate synthetic conversational data — ROUGE-L for coherence, Type-Token Ratio for diversity, and factual fidelity.
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.