Los LLMs tienen capacidades analíticas poderosas, pero sin prompts específicos producen resultados inconsistentes.
Situación típica 1 — Extracción incompleta: pedís "extraé la información importante de este email" y el LLM decide qué es "importante" arbitrariamente — omite el deadline, incluye el saludo, mezcla datos con opiniones.
Situación típica 2 — Resúmenes inadecuados: pedís "resumí este documento" y recibís 3 párrafos cuando necesitabas 1 línea, o un resumen ejecutivo cuando necesitabas detalle técnico, perdiendo información crítica que sí necesitabas.
Situación típica 3 — Clasificación inconsistente: pedís "clasificá este ticket" y en 3 ejecuciones obtenés "Problema técnico", "Bug" y "Technical Issue" — tres formas distintas de decir lo mismo, imposibles de agregar en una base de datos.
Por qué es importante: sin prompts estructurados para análisis, la extracción pierde datos críticos o incluye ruido irrelevante, los resúmenes no se ajustan a la audiencia ni al propósito, las clasificaciones no son comparables ni agregables, y no podés automatizar pipelines de procesamiento de texto.
La extracción convierte texto no estructurado en datos estructurados. Necesita: qué extraer (lista explícita de campos, tipo esperado, si puede estar ausente), de dónde extraer (delimitar el texto fuente, indicar si hay múltiples entidades), y cómo manejar ambigüedad (qué hacer si falta un dato, si hay varios valores posibles, o información contradictoria).
// Ejemplo real: extraer de un email comercial 10 campos (remitente, empresa, asunto, solicitud, deadline, monto, moneda, tono, requiere_respuesta) con reglas para fechas relativas ("esta semana" → fecha absoluta) y para inferir tono a partir del lenguaje usado.
Extracción de múltiples entidades — cuando hay varias instancias del mismo tipo de dato (ej: todas las personas mencionadas en una noticia), la estructura pasa a ser un array, con reglas para deduplicar y para clasificar el rol de cada entidad (protagonista / mencionado / citado).
Un buen resumen no es solo "más corto". Debe ser apropiado para su propósito.
Tipos de resumen y cómo pedirlos: un resumen ejecutivo (máx. 5 bullets, para C-level, formato situación → hallazgos → recomendación, tono directo); un resumen técnico (1-2 párrafos, para ingenieros, enfocado en arquitectura y dependencias, sin marketing); o un headline de una línea (máx. 15 palabras, auto-contenido, evitando muletillas como "El artículo trata sobre...").
// Técnica útil: pedir 3 versiones del mismo texto en un solo prompt (tweet de 280 caracteres, resumen ejecutivo de 5 bullets, resumen técnico de 1 párrafo) — te da el mismo contenido adaptado a 3 audiencias de una sola pasada.
La clasificación asigna categorías predefinidas a textos. Necesita: categorías (lista exhaustiva y mutuamente excluyente, con definición y ejemplos de cada una), criterios de decisión (qué define cada categoría, cómo resolver ambigüedad), y formato de salida (solo categoría / categoría + confianza / categoría + justificación).
// Ejemplo real: clasificador de tickets de soporte con 5 categorías (BILLING, TECHNICAL, ACCOUNT, FEATURE_REQUEST, GENERAL), cada una con definición, ejemplos y palabras clave, más 3 reglas de desempate explícitas (ej: "si menciona login + error → ACCOUNT, porque el problema es el acceso, no la app").
Clasificación multi-etiqueta — cuando un texto puede pertenecer a varias categorías a la vez (ej: un artículo sobre "tecnología" y "negocios"), las categorías dejan de ser excluyentes y el formato pasa a devolver un array, con un límite explícito (mínimo 1, máximo 3) y una categoria_principal.
Para análisis complejos, un solo prompt puede encadenar extracción → clasificación → resumen, con un FORMATO DE SALIDA que agrupe las tres secciones en un único JSON — por ejemplo, analizar un email de cliente extrayendo datos del remitente y su producto, clasificando el tipo de mensaje (QUEJA/CONSULTA/SUGERENCIA/AGRADECIMIENTO) con prioridad, y generando un resumen de 1 línea para el agente que lo va a atender.
El campo "confianza": "alta/media/baja" que aparece en varios de estos formatos de salida es una autoevaluación que genera el propio LLM — no está calibrada contra ningún resultado verificado externamente. Un modelo puede decir "alta confianza" y estar equivocado tanto como cuando dice "baja". Es una señal blanda, útil para priorizar qué casos revisar a mano, pero no una probabilidad estadística real. No la uses como criterio único para decidir qué automatizar sin supervisión.
Objetivo: aplicar las tres técnicas de análisis a textos reales y verificar consistencia.
Contexto inicial: usá Claude.ai, ChatGPT, o cualquier LLM.
Definí un schema con 11 campos (título, empresa, ubicación, tipo de contrato, salario mínimo/máximo, moneda, experiencia requerida, tecnologías, beneficios, fecha de publicación) con reglas para casos como "hasta 50K" (→ min: null, max: 50000). Probalo con una oferta real de "Senior Full Stack Developer" que mencione un rango salarial (ej: 55.000€-70.000€), ubicación híbrida (Madrid/Remoto), y una lista de tecnologías (React, Node.js, TypeScript, PostgreSQL, Redis, AWS). Verificá: ¿extrajo el rango salarial como números? ¿las tecnologías son un array completo? ¿la ubicación refleja ambas opciones?
Tomá un artículo de noticias de ~500 palabras y pedí 3 versiones en un mismo prompt: ultra-breve (máximo 20 palabras), ejecutivo (3-5 bullets, para alguien que decide si profundizar), y detallado (1-2 párrafos, autosuficiente, con contexto y matices). Verificá: ¿el ultra-breve es realmente 1 frase? ¿el ejecutivo tiene información accionable? ¿el detallado se entiende sin leer el original?
Diseñá un clasificador de sentimiento con 5 categorías (POSITIVO, NEGATIVO, CONSTRUCTIVO, MIXTO, NEUTRAL), formato con sentimiento_score (1-5) y cita_clave (frase que justifica la clasificación). Ejecutalo 5 veces con este feedback deliberadamente ambiguo:
Registrá categoría, score y si fue consistente en cada ejecución. Si hay inconsistencia, añadí definiciones más precisas a las categorías (probablemente te falte distinguir mejor MIXTO de CONSTRUCTIVO) y repetí el test.
Analizá una reseña de producto combinando las 3 técnicas en un solo prompt: extracción (producto, puntuación 1-5 inferida si no es explícita, aspectos positivos/negativos, si recomendaría), clasificación (sentimiento y tipo de reseña), y resumen (2 líneas para el equipo de producto: qué mejorar y qué mantener). Usá una reseña con sentimientos encontrados (ej: unos auriculares con excelente sonido pero incómodos tras 2 horas de uso) para forzar que el pipeline maneje matices, no solo extremos.
| Si ves esto... | Causa | Solución |
|---|---|---|
| Extracción omite campos | No especificaste qué hacer si falta un dato | Añadí: "Si no está presente: usar null" |
| Resumen demasiado largo | No definiste longitud estricta | Especificá: "Máximo X palabras", no solo "breve" |
| Clasificación inconsistente entre ejecuciones | Categorías ambiguas | Añadí definiciones más precisas y ejemplos por categoría |
| Extrae información que no está en el texto | El LLM está infiriendo/inventando | Añadí: "Solo extraer información explícita en el texto" |
| Resumen pierde información crítica | No priorizaste qué incluir | Sección "Incluir obligatoriamente: [lista]" |
| Clasificación siempre "MIXTO" o "GENERAL" | Categorías se solapan | Definí criterios de desempate claros |
Concepto central: extracción define QUÉ datos querés, summarization define PARA QUIÉN y CUÁNTO, clasificación define EN QUÉ CATEGORÍAS. Sin especificar estos parámetros, el LLM toma decisiones arbitrarias que no vas a poder replicar ni automatizar.
Para recordar: