Qué es un LLM y cómo elegir un modelo para una empresa

Un LLM (large language model o gran modelo de lenguaje) genera texto prediciendo los tokens siguientes a partir del contexto. Esto explica por qué puede crear respuestas coherentes, pero no constituye por sí mismo un mecanismo para comprobar la verdad. El perfil de IA generativa de NIST describe así el riesgo de confabulación.

De forma deliberada no encontrarás aquí un ranking de «los mejores modelos». Las posiciones de esas clasificaciones pueden cambiar rápido; los criterios de elección —calidad en la tarea propia, coste, latencia, condiciones de datos y posibilidad de mantenimiento— son un punto de referencia más estable.

Qué puede y qué no puede hacer un LLM por definición

Encaja bien para: transformar texto (resumir, traducir o cambiar formato), clasificar, extraer datos de texto no estructurado, generar borradores y traducir una pregunta en una consulta a un sistema, siempre después de comprobar la calidad con ejemplos reales.

No garantiza por naturaleza: la corrección de hechos y cálculos, el conocimiento de tus datos sin proporcionar contexto ni un resultado idéntico en cada ejecución. Estos requisitos deben protegerse mediante código, fuentes y evaluación.

Esta división tiene una consecuencia directa de diseño: el modelo puede interpretar el lenguaje, mientras que las reglas y los cálculos deben permanecer en código controlado. El código calcula un descuento. El modelo puede reconocer qué descuento pregunta un cliente por correo, y el resultado se dirige a una validación adecuada al coste de error.

Seis criterios para elegir el modelo

1. Dificultad de la tarea, no prestigio del modelo

Clasificar un correo en una de cinco categorías a menudo no exige el modelo más potente del mercado. Analizar un contrato para detectar contradicciones puede requerir mayores capacidades, pero lo decide una prueba con documentos representativos. Elegir un modelo «por si acaso» eleva el coste sin garantizar un resultado mejor.

Regla práctica: empieza con un modelo pequeño y económico, mide la calidad en tu propio conjunto de ejemplos y sube solo si no basta. No al revés.

2. Coste por unidad de trabajo, no precio por millón de tokens

La tarifa indica el coste de tokens. A ti te interesa el coste de una solicitud procesada o de una descripción generada. Ambas cifras pueden diferir mucho cuando se introducen muchos documentos como contexto: entonces buena parte del coste puede ser el material de entrada.

Por ello, antes de cambiar de modelo conviene medir también el contexto recuperado por RAG. Un material más corto y pertinente puede reducir a la vez el coste de entrada y el ruido, pero el efecto debe comprobarse con tu propio conjunto de preguntas.

3. Tamaño de la ventana de contexto

Es la cantidad de texto que el modelo admite de una vez. Una ventana grande simplifica algunos escenarios, pero no elimina la selección del material: fragmentos innecesarios elevan el coste y pueden dificultar la distinción de la base correcta para responder.

4. Latencia

En un chat interactivo la persona usuaria suele esperar una respuesta rápida, mientras que el procesamiento nocturno de documentos puede tener un límite mucho más relajado. Son requisitos distintos para el modelo y la arquitectura; los proveedores también pueden ofrecer modos por lotes más económicos, algo que debe confirmarse en la tarifa vigente.

5. Lugar de tratamiento de los datos

Modelo en la nube del proveedor, modelo en una región escogida o modelo en infraestructura propia. Es una decisión de cumplimiento, riesgo y responsabilidad operativa, no solo de tecnología. Comprueba finalidad y retención de datos, ubicación del tratamiento, subencargados, condiciones de contrato, permisos y procedimiento de incidentes.

6. Posibilidad de sustitución

La capa de integración debe limitar la dependencia de la lógica de negocio de una única interfaz de modelo. Un adaptador puede reducir el alcance de los cambios al cambiar de proveedor, pero no elimina la necesidad de reevaluar calidad, seguridad, límites y formatos de respuesta.

¿Modelo por API o con pesos abiertos?

	Modelo disponible por API	Modelo con pesos abiertos en infraestructura propia
Tiempo hasta el primer resultado	suele ser menor porque la infraestructura está lista	suele ser mayor por desplegar y mantener la infraestructura
Coste a pequeña escala	suele ser menor	puede ser mayor por el coste fijo de la infraestructura
Coste a gran escala estable	aumenta con el uso	puede ser menor
Control sobre los datos	depende del contrato y la configuración	mayor, pero exige protecciones propias
Trabajo propio	integración	integración más mantenimiento de infraestructura

Sin limitaciones especiales, una API es un punto de partida útil para medir calidad, uso y coste. Conviene considerar antes infraestructura propia cuando lo requieran el cumplimiento, el control de datos, la latencia o una escala estable que pueda calcularse. «Pesos abiertos» no siempre significa libertad de uso: hay que revisar la licencia del modelo concreto. Decide el modo de tratamiento antes de usar datos de producción, no después del piloto.

Lo que no recomendamos a las empresas de nuestro perfil de clientes es entrenar un modelo desde cero. Normalmente ni la escala de datos ni el presupuesto lo justifican; una prueba más económica es un modelo ya preparado conectado a datos propios y con medición de calidad.

Cómo medir si un modelo es bueno para nosotros

Los rankings públicos hablan de tareas generales, no de la tuya. La versión mínima de una medición propia es:

1. Reúne inicialmente 20–50 ejemplos reales y variados de tu proceso, incluidos casos difíciles y casos que el sistema no debería resolver. Es una muestra de cribado, no una cifra universal suficiente para implantar.
2. Ejecuta dos o tres modelos sobre ellos y cuenta cuántas veces el resultado es correcto.
3. Registra también el coste y el tiempo de una ejecución.
4. Conserva ese conjunto y ejecútalo tras cada cambio de modelo o prompt.

Un conjunto pequeño no sustituye una evaluación completa, pero es un filtro de compra mejor que un ranking general. Cuando la solución entra en producción, el conjunto debe ampliarse con errores y nuevos casos de uso real.

Cuándo un LLM es una mala elección

• Cuando se exige repetibilidad carácter por carácter. Factura, transferencia o cálculo de una obligación. Código, no modelo.
• Cuando la entrada ya está estructurada. Si tienes una buena base de datos, una consulta a ella es más rápida, barata y segura.
• Cuando no hay forma de comprobar el resultado. Una tarea para la que nadie sabe evaluar si una respuesta es buena no es apta para implantación, porque no advertirás cuándo deje de funcionar.

Preguntas frecuentes

¿Un modelo más grande siempre es mejor?

No. Un modelo mayor puede lograr mejores resultados en parte de las tareas difíciles, pero no hay garantía de ventaja en tu proceso y el coste y la latencia pueden ser superiores. Compara candidatos con el mismo conjunto de casos y elige el modelo más pequeño que cumpla el criterio de calidad acordado.

¿Con qué frecuencia hay que cambiar el modelo?

No hay un calendario fijo. Conviene evaluar un modelo nuevo cuando el actual no cumple calidad, coste, latencia o requisitos del proveedor. Un adaptador acorta parte del trabajo técnico, pero el tiempo de decisión depende de la reevaluación y la comprobación de cumplimiento. Revisamos esta entrada trimestralmente.

¿Se pueden usar varios modelos a la vez?

Sí. Uno económico puede encargarse de los casos rutinarios y uno más caro solo de los que superen un umbral definido. Sin embargo, el enrutamiento aumenta la complejidad y solo compensa cuando la medición de ahorro y calidad justifica las reglas, pruebas y supervisión adicionales.

---

Elegimos el modelo para la tarea y el presupuesto, no por moda, y construimos la capa de integración de modo que sustituirlo no obligue a reescribir el sistema. Consulta integraciones LLM o cuéntanos qué quieres conseguir.