Aplicaciones sobre LLM que aguantan usuarios reales

Depende de la tarea, y casi siempre son varios en el mismo sistema. Para clasificar, extraer y resumir, un modelo económico basta y cuesta una fracción. Para razonamiento complejo o la respuesta final al usuario, uno capaz. Trabajamos con OpenAI, Anthropic, Google, Azure OpenAI y Amazon Bedrock, y la elección se justifica con números en la propuesta, no por moda.

Con cuatro palancas: enrutamiento por tarea, recorte de contexto para no mandar todo «por si acaso», caché de prompts en instrucciones largas y repetidas, y límites duros por petición y por usuario. En los sistemas que hemos operado, esas cuatro palancas son lo que mantiene la factura previsible cuando el uso se multiplica. Además dejamos el gasto instrumentado, a la vista y sin tener que pedirlo.

Sí, y lo diseñamos para eso desde el principio. La aplicación habla con una capa de abstracción, no directamente con la API de un proveedor, así que cambiar de modelo es configuración más una corrida de evaluación para confirmar que la calidad se mantiene. Sin esa capa, migrar cuesta un trimestre.

Es forzar al modelo a devolver datos con una forma exacta —JSON que cumple un esquema— en vez de texto libre. Importa porque el sistema necesita procesar la respuesta: si a veces devuelve un campo con otro nombre o un número como texto, la integración se rompe en producción de formas difíciles de reproducir. Validamos contra esquema y reintentamos con corrección cuando no cumple.

Es cuando alguien mete instrucciones dentro del contenido que el modelo procesa —un documento, un correo, un mensaje— para hacerle ignorar sus reglas. Se mitiga con jerarquía de instrucciones en el prompt de sistema, separación estricta entre contenido de sistema y de usuario, filtrado de entrada y salida, y limitando qué herramientas puede invocar el modelo. En sistemas con agentes esto deja de ser opcional.

Cuando hace falta un tono, un formato o un vocabulario muy específico que el prompting no logra de forma consistente, y existen al menos unos cientos de ejemplos de buena calidad. No sirve para meter conocimiento actualizable: para eso está RAG. En la práctica, nueve de cada diez casos que llegan pidiendo fine-tuning se resuelven mejor con RAG y mejor prompting.

Con un conjunto de casos reales y su resultado esperado, corriendo antes y después de cada cambio. Medimos calidad de la respuesta, costo por petición y latencia. Sin eso, «mejoramos el prompt» es una opinión, y es exactamente así como los sistemas empeoran sin que nadie se entere.

Sí, y es uno de los usos con retorno más claro: extraer datos de facturas, contratos o formularios en formatos variables, donde las plantillas rígidas fallan. Se combina con validación por esquema y con revisión humana en los casos de baja confianza. Lo vemos también desde automatización de procesos.