Tamaño adecuado de los LLM: enrutamiento, recuperación y evaluación en lugar del tamaño del modelo bruto
Aprende cómo elegir entre modelos de lenguaje pequeños y grandes según la carga de trabajo, mide el costo por tarea completada con éxito y utiliza primero la enrutación, RAG, caché y validación.
Las cifras de los parámetros permiten crear titulares sencillos, y es tentador tratarlas como un indicador de la calidad del producto: un modelo de 70 mil millones debe ser mejor que uno de 7 mil millones, por lo que el modelo más grande que se pueda permitir debe ser la opción segura. En la producción, este atajo deja de funcionar rápidamente. Los modelos más grandes suelen costar más por llamada, responden más lentamente, añaden carga a la infraestructura y a menudo resuelven problemas que la aplicación nunca tuvo. Esta guía muestra cómo elegir un modelo según la carga de trabajo y no según su tamaño, cómo considerar conjuntamente el costo, la latencia y las fallas, y qué elementos arquitectónicos (enrutamiento, recuperación, validación, caché y código puro) suelen ofrecer más beneficios que una simple actualización.
Por qué el principio de “cuanto más grande, mejor” deja de funcionar en la producción
La intuición es comprensible. Los ingenieros de software han pasado décadas viendo cómo las actualizaciones de hardware generan beneficios: una CPU más rápida, más RAM, discos más grandes y una GPU más moderna son casi siempre mejoras. Cuando los modelos de lenguaje se volvieron más grandes y capaces, parecía natural trasladar ese modelo mental. Si un modelo razona mejor que otro, ¿por qué alguien elegiría deliberadamente el más débil?
La respuesta aparece en el momento en que un modelo se utiliza para una tarea real. La pregunta que planteas pasa de “¿cuál es el modelo más inteligente?” a “¿cuál modelo produce el mejor resultado para esta tarea específica?”. Son preguntas muy diferentes. El candidato más potente podría dar una respuesta ligeramente mejor, pero ser mucho más lento. Puede costar varias veces más. Puede resultar inútil para una simple tarea de clasificación, generar respuestas demasiado largas como para que las muestre la interfaz de usuario, agotar el presupuesto de contexto disponible y complicar su implementación. Lo más importante es que podría estar resolviendo un problema que en realidad no tienes.
Comienza con la carga de trabajo, no con el número de parámetros
Una forma más fiable de seleccionar un modelo comienza con una descripción de la tarea en sí. Antes de comparar cualquier modelo, responde a estas preguntas:
- ¿Cómo es la entrada?
- ¿Qué salida se espera?
Esa última pregunta es la verdadera cuestión de ingeniería, y el resto de esta guía está dedicado a responderla: por qué el modelo más grande no es automáticamente el mejor, cómo decidir entre modelos pequeños y grandes, cuándo un modelo grande realmente justifica su costo y qué aspecto tiene un diseño de producción sensato.
Un producto de soporte, dos cargas de trabajo completamente diferentes
Considere una aplicación de soporte empresarial. Un usuario escribe “Restablecer mi contraseña”. ¿Qué debería hacer la capa de IA en este caso? Lo más probable es que simplemente reconozca la intención y la asocie a una etiqueta como la siguiente, para que la aplicación pueda pasarla a un flujo de trabajo fijo y determinista.
PASSWORD_RESET
No se necesita un modelo de razonamiento complejo para llegar a esa etiqueta. Enviar esta solicitud a través de uno sería una elección de diseño cuestionable, ya que un modelo ligero o incluso el coincidencia de palabras clave y reglas podrían manejarla adecuadamente.
Ahora imagine un mensaje diferente: los clientes europeos han estado experimentando fallos intermitentes en los pagos desde el despliegue de ayer, y el usuario quiere que el sistema compare las diferencias del despliegue con los registros del servicio de pagos, identifique posibles patrones de fallo, determine si está involucrado el nuevo mecanismo de intentos y sugiera un plan de reversión. Esta solicitud requiere mucho más:
- recuperación de los cambios relevantes en el despliegue y de los registros
- una gran cantidad de contexto
- la capacidad de leer y comprender código
- análisis de los resultados de los registros
- razonamiento que abarca varios pasos
- correlación de eventos entre sistemas
- una explicación técnica clara
- manejo honesto de la incertidumbre
Aquí un modelo más potente puede realmente aportar valor. El error no radica en usar un modelo grande, sino en tratar estas dos solicitudes como si fueran el mismo trabajo.
Una definición práctica del valor de un modelo
Una forma útil de enmarcar esta elección es mediante una heurística aproximada:
Valor del modelo = capacidad × fiabilidad × utilidad ÷ costo
Esto no es una fórmula que se calcule. Es una forma de pensar. Un modelo que es un 10% más capaz, pero cinco veces más caro y tres veces más lento, no es automáticamente la mejor opción de producción. De igual manera, un modelo que es extremadamente barato pero poco fiable para su tarea también es una mala elección. Lo que se debe optimizar no es la inteligencia máxima, sino la inteligencia más útil por unidad de costo, latencia y complejidad.
Por qué los modelos grandes son tentadores, y dónde aparecen las limitaciones
Preferir modelos grandes no es irracional, porque brindan ventajas reales. A menudo manejan mejor el razonamiento complejo, tienen un rendimiento más uniforme en tareas variadas, interpretan instrucciones vagas de manera más adecuada, navegan por bases de código complicadas con mayor eficacia, necesitan menos indicaciones específicas para la tarea y pueden ser mucho más capaces en trabajos verdaderamente difíciles.
Entonces, ¿por qué no usar el modelo más potente en todas partes? Porque la producción introduce limitaciones que rara vez se reflejan en las cifras de los rankings. Imagine un endpoint que maneja 100,000 solicitudes al día. Si el modelo más grande cuesta significativamente más por llamada, esa diferencia deja de ser abstracta; se refleja en el presupuesto de infraestructura. Si además es más lento, los usuarios se dan cuenta. Si tiende a dar respuestas extensas, el gasto en tokens de salida aumenta. Y si la aplicación ejecuta miles de tareas pequeñas, enviar cada una a un modelo avanzado de razonamiento es simplemente un desperdicio.
Elegir un modelo es un problema de optimización, no una competencia por popularidad.
El modelo que está en la cima de una tabla de pruebas no necesariamente es el que genera la mejor aplicación.
La cantidad de parámetros es solo un factor
Las comparaciones entre modelos tienden a centrarse en el tamaño: 7B, 13B, 34B, 70B, cientos de miles de millones. El tamaño por sí solo no dice mucho sobre su idoneidad. Una comparación práctica analiza varias dimensiones al mismo tiempo, por ejemplo:
- la capacidad para tareas específicas
- la latencia, tanto el tiempo hasta el primer token como el tiempo total de generación
- el costo por solicitud y por tarea completada con éxito
- el rendimiento bajo la carga esperada
- el tamaño de contexto que realmente necesita la tarea
- la fiabilidad y consistencia en ejecuciones repetidas
- las opciones de despliegue, incluyendo el alojamiento local o privado
- la capacidad de control
La capacidad de control merece especial atención porque es fácil pasarla por alto. Un modelo puede ser altamente capaz, pero difícil de mantener dentro de límites razonables. En los flujos de trabajo empresariales, un comportamiento predecible suele valer más que la creatividad.
La extracción estructurada es un objetivo diferente
Tomemos como ejemplo la extracción de facturas. Esta función necesita una estructura fija, como la que se muestra a continuación, y no un ensayo detallado sobre el documento.
{
"invoiceNumber": "...",
"invoiceDate": "...",
"vendor": "...",
"total": 0
}
Lo importante aquí es obtener una salida fiable y bien formada que el código posterior pueda analizar en cada ocasión. Eso constituye un objetivo de optimización distinto de la capacidad general de razonamiento, y los modelos más pequeños o con restricciones suelen cumplirlo bien, especialmente cuando se combinan con la validación de esquemas.
Latencia: la primera trampa en entornos de producción
En una demostración, esperar seis segundos no parece un problema. La respuesta es impresionante, la compartes con el equipo y todos quedan satisfechos. Pero si colocas esa misma llamada detrás de un botón en una aplicación real, la experiencia cambia: el usuario hace clic, aparece un indicador de carga y pasan tres, cinco u ocho segundos. En ese momento nadie admira la inteligencia del modelo; todos se preguntan por qué la aplicación es tan lenta.
La latencia es una característica del producto, y en el software interactivo tiene una importancia enorme.
Por qué los modelos más grandes tienden a responder con mayor lentitud
La relación exacta depende de muchos factores: la arquitectura del modelo, el hardware, la capa de servidores, la cuantización, el agrupamiento de solicitudes, la cantidad de tokens generados, el tamaño del prompt y el diseño del modelo. Sin embargo, como tendencia general, los modelos que requieren más recursos computacionales necesitan más recursos por token y pueden devolver resultados con mayor lentitud. Esto es especialmente relevante en:
- interfazes de chat
- asistentes de programación y autocompletado
- asistentes de voz
- Herramientas de soporte al cliente
- paneles interactivos
- flujos de trabajo basados en agentes, donde las esperas se acumulan en cada paso
El autocompletado ilustra este punto claramente. Una sugerencia de código que tarda cinco segundos ya no es autocompletado; es una interrupción. Un modelo más pequeño que responde casi al instante suele ser mucho más útil que uno más potente que hace esperar al desarrollador.
La transmisión en tiempo real mejora la percepción, no el cálculo
La transmisión en tiempo real es la forma estándar de hacer que las esperas parezcan más cortas. Sin ella, el usuario no ve nada hasta que la respuesta completa está lista:
[wait...]
Hello! Here is the answer...
Con la transmisión en tiempo real, el texto aparece en la pantalla a medida que llegan los tokens:
Hello
Hello, here
Hello, here is
Hello, here is the
Hello, here is the answer...
Es necesario mantener clara esta distinción. La transmisión en tiempo real reduce la latencia percibida porque las primeras palabras aparecen rápidamente, pero no disminuye el cálculo necesario ni el tiempo total hasta que se obtiene la respuesta. Se trata de una mejora en la experiencia del usuario, no de una optimización de rendimiento, y no sirve para pasos no interactivos como un clasificador dentro de una pipeline.
Costo: mézcalo por tarea completada con éxito
Muchos prototipos se convierten en sistemas costosos justo en este punto. Durante el desarrollo, los gastos parecen insignificantes: un ingeniero envía unas pocas solicitudes y nadie piensa en la factura. Luego llega el tráfico real, y cada solicitud puede contener mucho más que el mensaje del usuario:
- múltiples usuarios concurrentes
- varias solicitudes por sesión
- solicitudes largas
- documentos recuperados
- resultados de herramientas
- historial de conversaciones
- respuestas generadas
El volumen de tokens crece rápidamente, y la elección del modelo comienza a ser de gran importancia.
Una métrica más honesta que el precio por llamada es el costo para realizar la tarea correctamente. Compare dos modelos hipotéticos (las cifras son ilustrativas, no resultados de pruebas de rendimiento):
- Modelo A: $0.01 por solicitud, 90% de precisión en la tarea, se necesitan aproximadamente 1.11 solicitudes por éxito, lo que equivale a unos $0.011 por tarea completada con éxito.
- Modelo B: $0.05 por solicitud, 96% de precisión en la tarea, se necesitan aproximadamente 1.04 solicitudes por éxito, lo que equivale a unos $0.052 por tarea completada con éxito.
El número esperado de intentos es simplemente uno dividido por la tasa de éxito, por lo que el costo por éxito es el precio de la solicitud dividido entre la precisión. Si el Modelo B cuesta cinco veces más pero solo mejora ligeramente los resultados, la empresa puede preferir razonablemente al Modelo A. La situación cambia cuando una respuesta incorrecta es costosa, por ejemplo cuando provoca un reembolso, un problema de cumplimiento o una interrupción del servicio. Por eso el costo siempre debe sopesarse junto con las consecuencias del fracaso, y no por separado.
Modelos demasiado grandes para problemas de tamaño reducido
Un patrón antiestándar común se ve así: cada mensaje recibido se clasifica como una queja, una pregunta o una solicitud de reembolso, y cada uno de ellos va al modelo más sofisticado disponible. La razón es la conveniencia: una API, un comando, un modelo, listo. Pero la arquitectura no consiste en hacer que un único componente sea capaz de todo; se trata de asociar cada tarea con el componente adecuado. Para una clasificación sencilla, las opciones incluyen:
- reglas deterministas
- embeddings
- un modelo de lenguaje pequeño
- un clasificador dedicado
- un modelo más grande reservado para casos de baja confianza
La última opción conduce a uno de los patrones más efectivos en entornos de producción.
Escalación: el modelo costoso como manejador de excepciones
El diseño ingenuo envía todo directamente al modelo grande:
Every request
↓
Large model
Un diseño de escalada permite que un modelo económico intente primero y verifique cuán confiado está:
Every request
↓
Small/cheap model
↓
Confidence check
↓
┌───────────────┐
│ │
High confidence Low confidence
│ │
Fast answer Large model
Las respuestas de alta confianza se devuelven inmediatamente; solo los casos inciertos pasan al modelo más potente. El modelo costoso deja de ser la opción predeterminada y se convierte en un manejador de excepciones. Este patrón depende de contar con una señal de confianza fiable, como una puntuación de clasificador calibrada, acuerdo entre métodos o un validador capaz de rechazar resultados mal formados; por lo tanto, mida con qué frecuencia las respuestas de baja calidad se filtran a través de la rama de “alta confianza” antes de confiar en ella.
Ruteo de solicitudes entre diferentes niveles de modelos
Una vez que se piensa de esta manera, los modelos dejan de parecerse a competidores y comienzan a verse como trabajadores especializados. Un enrutador de solicitudes puede situarse delante de varios niveles y elegir el adecuado para cada solicitud, con un paso de validación compartido antes de que nada llegue al usuario:
User Request
|
v
Request Router
|
+-----------+-----------+
| | |
v v v
Simple Medium Complex
| | |
v v v
Small LLM Mid Model Large Model
| | |
+-----------+-----------+
|
v
Validation Layer
|
v
Response
El enrutador necesita alguna noción de complejidad. La versión más simple es un pequeño conjunto de categorías:
SIMPLE
MEDIUM
COMPLEX
La lógica de despacho puede ser entonces tan sencilla como un interruptor basado en el veredicto del clasificador. El ejemplo a continuación está escrito en C#, pero el lenguaje es secundario; la misma estructura funciona igual de bien en un servicio de TypeScript.
public async Task<string> ProcessAsync(Request request)
{
var complexity = await classifier.ClassifyAsync(request);
return complexity switch
{
Complexity.Simple =>
await smallModel.GenerateAsync(request),
Complexity.Medium =>
await mediumModel.GenerateAsync(request),
Complexity.Complex =>
await largeModel.GenerateAsync(request),
_ => throw new InvalidOperationException()
};
}
Lo importante es la declaración arquitectónica que hace el código: no toda solicitud merece un nivel máximo de inteligencia. Aplicada de manera consistente, esa única decisión puede cambiar drásticamente la eficiencia económica de un sistema de IA. Tenga en cuenta que el clasificador en sí mismo agrega una llamada y algo de latencia a cada solicitud, por lo que debería ser mucho más económico que los modelos a los que redirige, y una categoría desconocida debería generar un error evidente, como ocurre con la rama por defecto aquí.
Cuando la brecha es de conocimiento, no de inteligencia
Otro reflejo frecuente es: “El modelo no conoce nuestra documentación interna, así que cambiemos a uno más grande”. El tamaño no soluciona la falta de conocimiento. Cuando la información es propietaria, reciente o altamente específica para un dominio determinado, el problema es el acceso al conocimiento y no la capacidad de razonamiento. Eso es precisamente lo que aborda la Generación Aumentada por Búsqueda (RAG). El flujo básico se ve así:
User Question
|
v
Embedding / Retrieval
|
v
Relevant Documents
|
v
Prompt + Retrieved Context
|
v
Language Model
|
v
Answer
Si un usuario pregunta sobre la política interna de reembolsos de su empresa para clientes empresariales, ningún modelo de uso general, por más grande que sea, conoce la respuesta. Debe proporcionar el texto relevante en la solicitud. Para conocer mejor cómo funciona este paso de recuperación, consulte nuestra guía sobre cómo los sistemas RAG recuperan conocimiento actualizado bajo demanda.
Corrija la cadena de información antes del modelo
Esto conduce a un principio que vale la pena adoptar como regla:
Mejore lo que alimenta al modelo antes de actualizarlo.
Los equipos suelen intentar solucionar respuestas deficientes pasando a un modelo más grande, cuando la verdadera causa está en otro lugar:
- recuperación deficiente
- documentos irrelevantes
- metadatos faltantes
- fragmentación deficiente
- contexto insuficiente
En esos casos el modelo no es el cuello de botella; lo es la cadena de procesamiento de información.
La calidad del contexto supera a su cantidad
Las ventanas de contexto grandes son impresionantes, pero más contexto no significa automáticamente mejor rendimiento. Entregarle a un modelo 200 páginas de documentación cuando dos párrafos contienen la respuesta técnicamente le proporciona la información, pero en la práctica dificulta la tarea, ya que ahora debe encontrar la señal entre el ruido. Un contexto excesivo tiende a aumentar:
- el consumo de tokens
- la latencia
- el costo
- las distracciones
- la posibilidad de información contradictoria
Un objetivo mejor es la menor cantidad posible de contexto de alta calidad que aún permita al modelo responder correctamente. Por eso los sistemas RAG maduros invierten tanto en la capa de recuperación, mediante técnicas como:
- búsqueda semántica e híbrida
- filtrado por metadatos
- reescritura de la consulta del usuario
- reclasificación de los fragmentos candidatos
- mantenimiento de la actualidad de los documentos
- generación de fragmentos bien estructurados
Las alucinaciones requieren verificación, no un modelo más grande
Una verdad incómoda: utilizar un modelo lo suficientemente potente no hace que desaparezcan las alucinaciones. Los modelos más avanzados tienden a acertar en más hechos y razonar mejor en diversas tareas, pero un modelo de lenguaje sigue siendo un generador de texto, nunca una fuente de verdad a la que se pueda consultar como una base de datos. Por lo tanto, la solución está en el diseño: se debe añadir una verificación explícita al proceso, por ejemplo:
User Request
↓
Retrieve Evidence
↓
Generate Answer
↓
Validate Claims
↓
Return Response
En flujos de trabajo de alto valor, se puede reforzar esto con:
- citas que apuntan a pruebas
- resultados estructurados verificados contra un esquema
- validación según reglas de negocio
Deje que el modelo razonee y que el software aplique las reglas
Esto crea un límite importante en la arquitectura. Si se le pide a un modelo que calcule el total de una factura, no hay razón para confiar en su aritmética cuando la aplicación puede realizar los cálculos con exactitud. En lugar de eso, divida las responsabilidades:
Model:
Extract line items
Application:
Calculate subtotal
Application:
Calculate tax
Application:
Calculate total
Model:
Explain the result
El modelo extrae los elementos de la factura y explica el resultado; la aplicación calcula el subtotal, el impuesto y el total. Cada parte hace lo que sabe hacer de manera fiable, y las cifras que ve el usuario siempre son correctas por diseño.
Dónde brillan los modelos pequeños y dónde fallan
Los modelos de lenguaje pequeños a menudo se consideran “menos inteligentes”, lo cual es técnicamente cierto en muchos entornos. Pero la ingeniería no se trata únicamente de la inteligencia, y los modelos pequeños ofrecen ventajas concretas:
- menor costo de inferencia
- menor latencia
- despliegue local más sencillo
- menores requisitos de infraestructura
- rendimiento potencialmente mayor
- escalabilidad más fácil
- ideal para tareas específicas
- útil en escenarios periféricos
- privacidad potencialmente mejor al ejecutarse localmente
Son especialmente atractivos para la clasificación, extracción, resumen, enrutamiento, autocompletado, transformaciones simples y flujos de trabajo específicos de un dominio. Si desea profundizar en esta tendencia, nuestro resumen sobre los pequeños modelos especializados que superan a los LLMs gigantes lo aborda con más detalle.
No obstante, ser pequeño no significa automáticamente ser mejor. Algunas tareas exceden las capacidades que un modelo pequeño puede realizar de forma fiable: razonamiento sofisticado a partir de múltiples fuentes, análisis complejo de código, problemas de planificación difíciles o interpretaciones sutiles. En esos casos, un modelo más potente justifica su costo. Ambos extremos son malos consejos. “Usar siempre el más grande” desperdicia dinero, mientras que “usar siempre el más pequeño” genera productos de mala calidad. La regla mejor es:
Utilice el modelo más pequeño que cumpla con el umbral de calidad de su aplicación.
Cargas de trabajo que justifican el uso de modelos grandes
Nada de esto constituye un argumento en contra de los modelos grandes. Son extremadamente útiles, y ciertas cargas de trabajo claramente compensan con creces sus capacidades adicionales.
Razonamiento complejo de múltiples pasos
Cuando una función depende de un razonamiento en cadena, un modelo más potente puede ofrecer resultados significativamente mejores.
Trabajo de codificación manual
Los modelos grandes demuestran su valor en requisitos complejos, bases de código desconocidas, decisiones arquitectónicas y sesiones de depuración difíciles.
Lenguaje natural ambiguo
Algunas solicitudes no encajan en categorías predefinidas. Un modelo más potente suele ser mejor para interpretar matices e intenciones.
Síntesis a partir de varios documentos
Cuando la respuesta requiere combinar información de muchas fuentes, la capacidad del modelo es aún más importante.
Flujos de trabajo agentes
Un agente normalmente tiene que:
- entender un objetivo
- planificar acciones
- elegir herramientas
- inspeccionar resultados
- recuperarse de fallos
- revisar el plan
- finalizar la tarea
Eso es mucho más difícil que la clasificación, y un modelo más potente está completamente justificado. La prueba en todos los casos es la misma: utilizar modelos grandes cuando su capacidad adicional genere un valor que se pueda medir.
El costo operativo de una arquitectura inteligente
Existe un costo que las pruebas de rendimiento nunca muestran: la complejidad arquitectónica. El diseño más simple posible es una aplicación, un modelo grande y una respuesta:
Application
↓
Large Model
↓
Response
Ahora imagine optimizar todo al mismo tiempo:
Application
↓
Router
↓
Classifier
↓
Small Model
↓
Confidence Evaluator
↓
RAG
↓
Reranker
↓
Large Model
↓
Validator
↓
Fallback Model
↓
Human Review
Este pipeline podría generar un sistema mejor, pero también introduce muchos más componentes, y cada componente conlleva:
- monitoreo y registros adicionales
- nuevos modos de fallo
- una superficie de pruebas más amplia
- infraestructura adicional para ejecutarlo
- despliegues más complicados
- más conocimientos que el equipo debe tener para operarlo
Por lo tanto, la optimización debe ser deliberada. Construir una arquitectura con siete modelos para ahorrar unos pocos centavos por solicitud rara vez es una buena inversión; solo añada cada capa cuando las mediciones demuestren que justifica su mantenimiento.
Evalúe según su propio volumen de trabajo, no según las clasificaciones
Los puntos de referencia públicos son un punto de partida, no una decisión. Su aplicación tiene su propio punto de referencia, y es el único que cuenta. Para un asistente de revisión de código de IA, un conjunto de evaluación podría incluir:
- Vulnerabilidades de inyección SQL
- Condiciones de carrera
- Bug de referencia nula
- Fallas en la autorización
- Manejo incorrecto de excepciones
- Problemas de rendimiento
- Violaciones arquitectónicas
Para un asistente de soporte al cliente, se medirían diferentes aspectos:
- Cumplimiento de políticas
- Exactitud factual
- Tono
- Precisión en la escalada de casos
- Comportamiento ante rechazos
- Validez de la salida estructurada
El conjunto de evaluación debe ser lo más similar posible al tráfico real de producción.
Crear una herramienta de comparación
El procedimiento básico es sencillo: recopilar solicitudes similares a las de producción con resultados esperados, probar cada modelo candidato con ellas y compararlos.
Production-like prompts
↓
Expected outcomes
↓
Run Model A
↓
Run Model B
↓
Compare
↓
Measure
Métricas útiles para registrar en cada ejecución:
- Corrección y finalización de tareas
Con esto en cuenta, elegir un modelo se convierte en una decisión de ingeniería en lugar de una suposición, y puedes volver a ejecutar el mismo sistema cada vez que un proveedor lanza una nueva versión del modelo.
Un proceso de selección de modelos en cuatro pasos
Para una nueva función de IA, un proceso simple y repetible funciona bien.
Paso 1: Definir la tarea con precisión
No comiences con “¿qué modelo deberíamos usar?”. Comienza con “¿qué debe lograr exactamente el modelo?” y escribe la respuesta en términos concretos:
Input:
Customer email
Output:
Intent + urgency + recommended workflow
Una especificación como esta, con una entrada clara y una salida clara, es mucho más útil que un objetivo vago.
Paso 2: Definir qué significa “lo suficientemente bueno”
Establezca criterios de aceptación claros antes de probar cualquier cosa. Por ejemplo:
Intent accuracy >= target threshold
Structured output must always validate
Response should normally arrive within target latency
Los umbrales reales dependen de la aplicación; lo importante es que existan antes de comparar modelos, para que los resultados no puedan justificarse posteriormente.
Paso 3: Pruebe primero el modelo más sencillo viable
Este es el paso que los equipos omiten con mayor frecuencia. Comience con algo sencillo, mida los resultados y deténgase si funciona. Solo avance si falla:
Small Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Larger Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Stronger architecture/model
En efecto, está subiendo por una escalera de capacidades paso a paso, y cada peldaño debe ganarse mediante una evaluación fallida.
Paso 4: Optimice el sistema circundante
Antes de pasar al siguiente peldaño, revise el resto del sistema:
- ¿Devuelve la recuperación el material correcto?
- ¿Es la instrucción clara y sin ambigüedades?
- ¿Es realmente relevante cada elemento del contexto?
- ¿Se valida la salida antes de usarla?
A veces, las mejoras en este aspecto eliminan por completo la necesidad de un modelo más grande.
Otras medidas que vale la pena tomar antes de una actualización
Prompts como contratos
La ingeniería de prompts no es magia, pero una tarea mal especificada puede hacer que incluso un modelo capaz funcione mal. Compare una instrucción vaga:
Analyze this customer message.
con otra que define la salida esperada y las reglas para la incertidumbre:
Analyze the customer message.
Return JSON with:
- intent
- urgency
- sentiment
- recommended_action
Do not invent information that isn't present.
If the intent is unclear, return "unknown".
La segunda versión le proporciona al modelo un contrato claro: campos con nombres definidos, una prohibición explícita de incluir hechos inventados y un valor por defecto establecido. Añadir algunos ejemplos suele mejorar aún más los resultados. Sin embargo, existe un límite: por más que se redacten las instrucciones, no se pueden otorgar al modelo capacidades que fundamentalmente carece, y cuando esa capacidad falta, los ajustes en las instrucciones generan beneficios cada vez menores. Considere las instrucciones como una capa más dentro del proceso de optimización, no como la solución completa.
Afinamiento, RAG o validación?
Otra reacción común ante resultados deficientes es decir “afinémoslo”. A veces eso es exactamente lo correcto, pero primero hay que diagnosticar el problema:
- Si el modelo carece de conocimientos actualizados o específicos de la empresa, como las políticas actuales, la recuperación de información suele ser una opción mejor que el afinamiento, ya que los conocimientos cambian y el reentrenamiento es lento.
Aplicar la solución adecuada al fallo real ahorra tiempo y dinero.
Caché: la optimización sencilla que funciona
El caché no es llamativo, pero es muy eficaz. Si los usuarios siguen preguntando “¿cuál es su política de devoluciones?”, no hay razón para llamar al modelo cada vez. Cuando la respuesta es estable, guárdala en caché. El ejemplo en C# a continuación verifica primero el caché, llama al modelo solo cuando no está disponible y almacena el resultado durante 30 minutos:
public async Task<string> GetAnswerAsync(string question)
{
var key = CreateCacheKey(question);
var cached = await cache.GetStringAsync(key);
if (cached is not null)
return cached;
var answer = await model.GenerateAsync(question);
await cache.SetStringAsync(
key,
answer,
TimeSpan.FromMinutes(30));
return answer;
}
El cacheo semántico real es más sofisticado que la coincidencia exacta de cadenas, ya que dos preguntas formuladas de manera diferente pueden requerir la misma respuesta, y se necesita una política para invalidar las respuestas cuando cambian los hechos subyacentes. La idea arquitectónica sigue siendo válida:
La solicitud de IA más rápida es aquella que nunca se realiza.
El mismo principio se aplica a la deduplicación, la precomputación, las respuestas deterministas, el reuso de los resultados de recuperación, el cacheo de prefijos de prompts cuando el proveedor lo permite, y el reuso directo de respuestas. Antes de invertir en más recursos de procesamiento, elimine aquellos que no necesita.
Trate los tokens como un presupuesto de recursos
Cuando se considera a un sistema de IA como uno distribuido, los tokens pasan a ser otro recurso más que hay que gestionar. Los servicios tradicionales administran la CPU, la memoria, la red y el almacenamiento. Las aplicaciones de IA añaden tokens de entrada, tokens de salida, tamaño del contexto y tiempo de inferencia, lo que convierte el diseño de los prompts en un factor que afecta al rendimiento.
Considere enviar todo el historial de conversaciones con cada solicitud. El prompt sigue creciendo, y luego se suman los documentos recuperados, las salidas de las herramientas, las instrucciones del sistema y las acciones anteriores del agente. Una pregunta simple puede terminar cargando con una enorme cantidad de información. Un diseño más eficiente selecciona solo el historial relevante antes de realizar la recuperación y crea un contexto compacto:
Conversation
↓
Relevant history selection
↓
Retrieval
↓
Compact context
↓
Model
en lugar de reenviar todo lo que el sistema ha visto alguna vez:
Everything we've ever seen
↓
Model
Más contexto nunca es gratuito: se paga por él en términos de costos económicos, latencia y, con frecuencia, calidad de las respuestas.
Los agentes multiplican cada una de estas decisiones
Los sistemas basados en agentes hacen que la selección de modelos sea aún más importante. Una sola solicitud del usuario puede dividirse en muchos pasos:
User Request
↓
Planning
↓
Tool Selection
↓
Search
↓
Database Query
↓
Code Execution
↓
Analysis
↓
Final Response
Si cada paso se ejecuta con el modelo más costoso, los gastos pueden dispararse. Sin embargo, rara vez se necesita la misma capacidad en todos los pasos. Una asignación mixta podría verse así:
Intent classification → Small model
Simple tool selection → Small model
Complex planning → Large model
Data extraction → Small model
Final explanation → Medium model
Se trata de una arquitectura de IA heterogénea, y hacia allí se dirigen muchos sistemas en producción: no un modelo gigante que haga todo, sino varios modelos, herramientas, componentes deterministas, pipelines de recuperación y validadores que trabajan juntos. Nuestro análisis de por qué los costos de la IA basada en agentes se disparan explora este aspecto relacionado con los costos con más detalle.
Considere los modelos como miembros de un equipo
Una analogía útil: imagine a tres ingenieros. Uno es muy experimentado, costoso y está sobrecargado de trabajo. Otro es experimentado y eficiente. El tercero es junior pero muy rápido en tareas repetitivas. No le entregaría todas las tareas al ingeniero senior; asignaría el trabajo según su dificultad:
Simple repetitive task
→ Engineer C
Normal feature
→ Engineer B
Complex architecture problem
→ Engineer A
Los modelos pueden tratarse de la misma manera. Un modelo más pequeño no es “malo”; simplemente puede estar adaptado a responsabilidades más limitadas. La habilidad clave es dividir el trabajo en partes. En lugar de buscar un modelo que haga todo, divida el flujo de trabajo para que cada componente se encargue de lo que hace mejor. Esa forma de pensar permite una escalabilidad mucho mayor.
Combinándolo todo: una arquitectura de referencia
Al combinar estas ideas, un asistente de IA empresarial podría estructurarse de la siguiente manera:
User
|
v
API / Gateway
|
v
Request Router
|
+-------------+-------------+
| |
v v
Simple Request Complex Request
| |
v v
Small Model Planner
|
+------------+------------+
| | |
v v v
Search Database Tools
| | |
+------------+-------------+
|
v
Context
|
v
Strong Model
|
v
Validator
|
+------+------+
| |
Valid Invalid
| |
v v
Response Retry/Fallback
Observe lo que no está sucediendo: al modelo más potente no se le pide que haga todo. Las solicitudes simples van a un modelo pequeño. Las complejas pasan por un planificador que recopila evidencia de búsquedas, bases de datos y herramientas, y solo entonces un modelo potente trabaja con un contexto seleccionado cuidadosamente. Un validador verifica el resultado, y los resultados inválidos provocan un intento de nuevo o una solución alternativa. El diseño se basa en:
- un router que elige la ruta
- procedimientos de recuperación y herramientas para obtener evidencia
- sistemas deterministas para un trabajo preciso
- modelos especializados según la función
- validación junto con estrategias de intento repetido y solución alternativa
Aquí el modelo es solo una parte del sistema, no todo el sistema.
Diez errores que siguen repitiéndose
- Elegir primero un modelo y describir el problema después. Ese orden está invertido; primero se debe definir la carga de trabajo antes que nada más.
Lista de verificación para elegir un modelo
Cuando surja la necesidad de decidir sobre un modelo, responda a estas preguntas en orden:
- ¿Puede resolverlo un código determinista? Si es así, escriba el código. No utilice la IA solo porque esté disponible.
- ¿Es la tarea simple y repetitiva? Pruebe con un modelo pequeño.
Esta lista de verificación es mucho más útil que preguntar cuál es el modelo más grande disponible.
Una pregunta que vale la pena hacer a ingenieros senior de IA
Una pregunta reveladora para una posición en arquitectura de IA es: "¿Por qué no elegir simplemente el modelo más capaz del mercado para todo?"
Una respuesta débil se limita a decir “los modelos más pequeños son más económicos”. Eso es cierto, pero incompleto. Una respuesta sólida tiene en cuenta la capacidad para la tarea específica, la fiabilidad, la latencia y el ancho de banda, el costo, cuánto contexto se necesita, el enrutamiento entre modelos, la recuperación de información, las tareas que debe realizar el código, la evaluación, cuál es el costo de los fallos y la carga operativa.
La pregunta lógica siguiente es: “¿Cómo demostraría que el modelo que eligió es lo suficientemente bueno?”. La respuesta debe referirse a la evaluación, no a opiniones, hilos de redes sociales, capturas de pantalla de tableros de clasificación o diapositivas del proveedor. Lo que lo determina es su carga de trabajo, sus datos y sus métricas.
Optimizando una aplicación existente paso a paso
Cuando una función de IA es demasiado lenta o costosa, resista la tentación de cambiar de modelo de inmediato. En su lugar, investigue de manera sistemática:
- Mide. Recopila los conteos de solicitudes, tokens de entrada y salida, latencia, tasa de errores, tasa de éxito de las tareas y costo del modelo.
- Identifica las cargas de trabajo costosas. Determina qué tipos de solicitudes consumen la mayor cantidad de recursos.
- Elimina las llamadas innecesarias. Utiliza caché, lógica determinista, deduplicación y precomputación.
- Reduce el contexto. Descarta la historia y los documentos irrelevantes.
- Mejora la recuperación de información. Devuelve pruebas más relevantes en lugar de más pruebas en general.
- Prueba con un modelo más pequeño. Verifica si la calidad sigue siendo aceptable.
- Introduce enrutamiento. Envía solo los casos difíciles a modelos más potentes.
- Valida lo que es importante. Aplica esquemas, reglas, herramientas y revisión humana cuando sea apropiado.
Si esto te resulta familiar, es normal. Esencialmente se trata de la misma disciplina que se utiliza para optimizar el software convencional.
La mejor arquitectura de IA suele ser híbrida
La imagen de una aplicación de IA como un frontend que llama a una API de LLM y devuelve la respuesta está desapareciendo:
Frontend
↓
LLM API
↓
Response
Las aplicaciones reales cada vez se asemejan más a una pasarela que coordina reglas, recuperación de datos, modelos, herramientas y validaciones:
Application
|
v
AI Gateway
|
+-----------+-----------+
| | |
v v v
Rules Retrieval Models
| | |
+-----------+-----------+
|
v
Tools
|
v
Validation
|
v
Application
Dicho diseño combina la ingeniería de software clásica con el aprendizaje automático, los modelos de lenguaje y la recuperación de información, además de bases de datos, APIs, seguridad, capacidad de observabilidad y lógica empresarial escrita en código. Eso es una buena noticia para los ingenieros de software: la ingeniería de IA no está reemplazando a la ingeniería de software, sino que le agrega un componente poderoso nuevo.
Un cambio de perspectiva relacionado también ayuda: deja de preguntarte qué modelo es el más inteligente y comienza a preguntarte qué sistema es el más inteligente. Un modelo brillante dentro de un sistema mal diseñado puede generar resultados terribles, mientras que un modelo de capacidad moderada dentro de una arquitectura bien diseñada puede impulsar un producto excelente. Los buenos sistemas compensan las debilidades de un modelo mediante la recuperación y herramientas, el enrutamiento y el caché, salidas estructuradas y validación, código para tareas precisas, y evaluación continua. En ese sentido, la capacidad de la IA es una propiedad de la arquitectura, no solo del modelo.
Comienza con poco y escala con pruebas
Una estrategia por defecto sensata para cualquier nueva función de IA se resume en este flujo:
Start
|
v
Define the workload
|
v
Can code solve the problem?
/ \
Yes No
| |
Use code v
Try small model
|
v
Evaluate
|
+----------+----------+
| |
Pass Fail
| |
Ship v
Improve architecture
|
v
Evaluate
|
v
Try stronger model
|
v
Evaluate
Esto evita un error muy común: gastar dinero en un problema que una mejor ingeniería podría haber resuelto.
A veces el modelo adecuado es ninguno
La lección no es que los modelos pequeños sean mejores; eso sería tan incorrecto como la afirmación opuesta. El modelo adecuado es aquel que satisface los requisitos de la tarea, equilibrando al mismo tiempo la capacidad y fiabilidad frente a la latencia, el costo y la complejidad. A veces es un modelo pequeño, a veces uno grande, a veces una combinación, y otras veces ni siquiera un modelo de IA. Si un tipo de solicitud puede manejarse con una estructura simple como esta, no hay razón para utilizar un LLM:
if (request.Type == "PasswordReset")
{
return StartPasswordResetWorkflow();
}
Eso no es anti-IA; es buena ingeniería. No comprarías un servidor con CPU ilimitada para un servicio que necesita solo dos núcleos, ni asignarías un terabyte de memoria para un proceso que utiliza 4 GB. El mismo razonamiento se aplica a los modelos: la capacidad que no necesitas es un costo que tampoco necesitas.
Puntos clave
- Sustituya “¿Cuál es el modelo más grande que podemos permitirnos?” por “¿Cuál es la arquitectura más simple que resuelve de manera fiable este problema?”. Esa pregunta lo llevará naturalmente al enrutamiento, la recuperación de datos, el caché, el código determinista, la evaluación, la latencia y el manejo de fallos.
- Evalúe los modelos según el costo por tarea exitosa, teniendo en cuenta las consecuencias de una respuesta incorrecta, y no según el precio por llamada o la cantidad de parámetros.
- Trate el conocimiento faltante como un problema de recuperación de datos y las operaciones aritméticas o reglas como un problema de software; ninguno se soluciona con un modelo más grande.
- Elija por defecto el modelo más pequeño que pase una evaluación basada en sus propios datos similares a los de producción, y solo aumente el tamaño del modelo si hay evidencias que lo justifiquen.
- Mantenga la arquitectura tan simple como lo justifiquen los ahorros, y siga midiendo después del lanzamiento, ya que los modelos, las instrucciones y los usuarios cambian constantemente.
Diseña primero en torno al problema y elige un modelo que se adapte a ese diseño posteriormente. A veces ese modelo será enorme, otras veces sorprendentemente pequeño, y en ocasiones la decisión más inteligente es no utilizar ningún modelo.
Lecturas relacionadas
- Explicación de la generación aumentada con recuperación: arreglando las fallas en el conocimiento de LLM — Aprende por qué los LLM generan información falsa y pierden actualidad, y luego observa paso a paso cómo la RAG recupera datos, los divide en fragmentos, los incrusta y los complementa para solucionarlo.
- RAG vs Agentic RAG vs Graph RAG: elegir la arquitectura de recuperación adecuada — Aprende cómo la RAG simple falla con preguntas de múltiples pasos y datos estructurados, y cómo los bucles agenciales y la recuperación basada en grafos resuelven sus respectivas debilidades.