Regex vs LLM para Análisis de Texto Estructurado
Un marco de decisión práctico para analizar texto estructurado (exámenes, formularios, facturas, documentos). La idea clave: las expresiones regulares (regex) manejan el 95-98% de los casos de forma económica y determinista. Reserve las costosas llamadas a LLM para los casos extremos restantes.
Cuándo activarlo
- Analizar texto estructurado con patrones repetitivos (preguntas, formularios, tablas)
- Decidir entre regex y LLM para extracción de texto
- Construir pipelines híbridos que combinen ambos enfoques
- Optimizar la relación costo/precisión en el procesamiento de texto
Marco de Decisión
¿El formato del texto es consistente y se repite?
├── Sí (>90% sigue un patrón) → Comience con Regex
│ ├── Regex maneja 95%+ → Listo, no necesita LLM
│ └── Regex maneja <95% → Agregue LLM solo para casos extremos
└── No (texto libre, muy variable) → Use LLM directamente
Patrón de Arquitectura
Texto Fuente
│
▼
[Analizador Regex] ─── Extrae estructura (95-98% de precisión)
│
▼
[Limpiador de Texto] ─── Elimina ruido (marcadores, números de página, artefactos)
│
▼
[Puntuador de Confianza] ─── Marca extracciones de baja confianza
│
├── Alta confianza (≥0.95) → Salida directa
│
└── Baja confianza (<0.95) → [Validador LLM] → Salida
Implementación
1. Analizador Regex (Maneja la Mayoría)
import re
from dataclasses import dataclass
@dataclass(frozen=True)
class ParsedItem:
id: str
text: str
choices: tuple[str, ...]
answer: str
confidence: float = 1.0
def parse_structured_text(content: str) -> list[ParsedItem]:
"""Analiza texto estructurado usando patrones regex."""
pattern = re.compile(
r"(?P<id>\d+)\.\s*(?P<text>.+?)\n"
r"(?P<choices>(?:[A-D]\..+?\n)+)"
r"Answer:\s*(?P<answer>[A-D])",
re.MULTILINE | re.DOTALL,
)
items = []
for match in pattern.finditer(content):
choices = tuple(
c.strip() for c in re.findall(r"[A-D]\.\s*(.+)", match.group("choices"))
)
items.append(ParsedItem(
id=match.group("id"),
text=match.group("text").strip(),
choices=choices,
answer=match.group("answer"),
))
return items
2. Puntuación de Confianza
Marque los ítems que pueden necesitar revisión del LLM:
@dataclass(frozen=True)
class ConfidenceFlag:
item_id: str
score: float
reasons: tuple[str, ...]
def score_confidence(item: ParsedItem) -> ConfidenceFlag:
"""Puntúa la confianza de la extracción y marca problemas."""
reasons = []
score = 1.0
if len(item.choices) < 3:
reasons.append("few_choices")
score -= 0.3
if not item.answer:
reasons.append("missing_answer")
score -= 0.5
if len(item.text) < 10:
reasons.append("short_text")
score -= 0.2
return ConfidenceFlag(
item_id=item.id,
score=max(0.0, score),
reasons=tuple(reasons),
)
def identify_low_confidence(
items: list[ParsedItem],
threshold: float = 0.95,
) -> list[ConfidenceFlag]:
"""Devuelve los ítems por debajo del umbral de confianza."""
flags = [score_confidence(item) for item in items]
return [f for f in flags if f.score < threshold]
3. Validador LLM (Solo Casos Extremos)
def validate_with_llm(
item: ParsedItem,
original_text: str,
client,
) -> ParsedItem:
"""Usa LLM para corregir extracciones de baja confianza."""
response = client.messages.create(
model="claude-haiku-4-5-20251001", # Modelo más barato para validación
max_tokens=500,
messages=[{
"role": "user",
"content": (
f"Extrae la pregunta, las opciones y la respuesta de este texto.\n\n"
f"Texto: {original_text}\n\n"
f"Extracción actual: {item}\n\n"
f"Devuelve el JSON corregido si es necesario, o 'CORRECT' si es correcto."
),
}],
)
# Analiza la respuesta del LLM y devuelve el ítem corregido...
return corrected_item
4. Pipeline Híbrido
def process_document(
content: str,
*,
llm_client=None,
confidence_threshold: float = 0.95,
) -> list[ParsedItem]:
"""Pipeline completo: regex -> verificación de confianza -> LLM para casos extremos."""
# Paso 1: Extracción con regex (maneja el 95-98%)
items = parse_structured_text(content)
# Paso 2: Puntuación de confianza
low_confidence = identify_low_confidence(items, confidence_threshold)
if not low_confidence or llm_client is None:
return items
# Paso 3: Validación con LLM (solo para los ítems marcados)
low_conf_ids = {f.item_id for f in low_confidence}
result = []
for item in items:
if item.id in low_conf_ids:
result.append(validate_with_llm(item, content, llm_client))
else:
result.append(item)
return result
Métricas del Mundo Real
De un pipeline de análisis de exámenes en producción (410 ítems):
| Métrica | Valor |
|---|---|
| Tasa de éxito de regex | 98.0% |
| Ítems de baja confianza | 8 (2.0%) |
| Llamadas a LLM necesarias | ~5 |
| Ahorro de costos vs. solo LLM | ~95% |
| Cobertura de pruebas | 93% |
Mejores Prácticas
- Comience con regex — incluso un regex imperfecto le da una línea base para mejorar
- Use puntuación de confianza para identificar programáticamente qué necesita ayuda del LLM
- Use el LLM más barato para la validación (los modelos de clase Haiku son suficientes)
- Nunca mutar los ítems analizados — devuelva nuevas instancias de los pasos de limpieza/validación
- TDD funciona bien para analizadores — primero escriba pruebas para patrones conocidos, luego para casos extremos
- Registre métricas (tasa de éxito de regex, cantidad de llamadas a LLM) para monitorear la salud del pipeline
Anti-Patrones a Evitar
- Enviar todo el texto a un LLM cuando regex maneja el 95%+ de los casos (costoso y lento)
- Usar regex para texto libre, altamente variable (el LLM es mejor aquí)
- Omitir la puntuación de confianza y esperar que regex "simplemente funcione"
- Mutar objetos analizados durante los pasos de limpieza/validación
- No probar casos extremos (entrada mal formada, campos faltantes, problemas de codificación)
Cuándo Usarlo
- Análisis de preguntas de exámenes/pruebas
- Extracción de datos de formularios
- Procesamiento de facturas/recibos
- Análisis de estructura de documentos (encabezados, secciones, tablas)
- Cualquier texto estructurado con patrones repetitivos donde el costo importa