Cómo elegir el modelo de IA adecuado para un proyecto

Porque el modelo más grande, nuevo y capaz casi nunca es la respuesta correcta para una tarea concreta, y elegirlo por defecto sale caro en varios sentidos. Un modelo enorme aplicado a una tarea simple, como clasificar comentarios o extraer un dato de un texto, rinde muchísimo por encima de lo necesario, y ese exceso se paga: cuesta más dinero por cada uso, responde más lento y no aporta ninguna mejora perceptible sobre un modelo más modesto que resuelve la tarea igual de bien. La analogía es usar un camión para llevar una carta. El principio correcto es que el mejor modelo es el más pequeño y económico que resuelve tu tarea con la calidad que necesitás, no el más potente disponible. Reservar los modelos grandes para las tareas que realmente los requieren —razonamiento complejo, redacción sofisticada, programación difícil— y usar modelos más livianos para lo simple es lo que mantiene un proyecto sostenible en costo y ágil en velocidad, especialmente cuando la tarea se ejecuta muchísimas veces.

Son cinco criterios que hay que equilibrar entre sí, siempre después de haber definido claramente la tarea. La capacidad es si el modelo resuelve bien esa tarea específica con la calidad requerida, teniendo en cuenta que más grande no siempre significa mejor para un problema dado. El costo importa porque se paga por uso, generalmente según la cantidad de texto procesado, y un modelo mucho más caro rara vez justifica su precio para una tarea que otro más barato resuelve bien, sobre todo si se ejecuta con mucha frecuencia. La latencia es cuánto tarda en responder, un factor decisivo cuando hay un usuario esperando en tiempo real, donde a veces conviene un modelo más rápido aunque sea algo menos capaz. La privacidad determina si los datos pueden enviarse a un servicio externo o si su sensibilidad obliga a procesarlos dentro de la propia infraestructura. Y la ventana de contexto indica cuánto texto puede procesar el modelo de una sola vez, algo relevante al trabajar con documentos largos. Ninguno de estos criterios se evalúa aislado: la elección es siempre un equilibrio entre todos según lo que el proyecto necesita.

Depende de qué pese más en tu proyecto, porque cada opción tiene ventajas claras. Un modelo cerrado, usado a través de la interfaz de programación de un proveedor, ofrece habitualmente la máxima capacidad disponible sin que tengas que montar ni mantener ninguna infraestructura, lo que permite empezar muy rápido; a cambio, implica enviar tus datos a un tercero y depender de ese proveedor, de sus precios y de sus cambios. Un modelo abierto, que ejecutás en tu propia infraestructura, te da control y privacidad totales porque los datos nunca salen de tu entorno, y un costo predecible basado en tu propia infraestructura en lugar de por uso; la contrapartida es que tenés que montar y mantener esa infraestructura, lo que requiere conocimiento y recursos. En general, cuando pesan mucho la privacidad de los datos o el costo a gran escala, la balanza se inclina hacia un modelo abierto; cuando se busca la máxima capacidad con el mínimo esfuerzo operativo, hacia uno cerrado. Muchos proyectos combinan ambos, usando cada uno para las tareas donde conviene.

Sirven, pero solo hasta cierto punto: son útiles para armar una lista corta de candidatos, no para tomar la decisión final. Las comparativas públicas, que rankean los modelos según capacidad general, costo y velocidad, dan una buena visión panorámica del terreno y ayudan a descartar opciones y a identificar dos o tres candidatos razonables para tu caso. Sin embargo, no bastan para decidir, por una razón importante: un modelo que obtiene excelentes resultados en pruebas genéricas puede rendir mal en tu tarea específica, y a la inversa, un modelo más modesto en los rankings puede resultar ideal para lo que vos necesitás. Las pruebas generales miden un promedio de muchas tareas que no necesariamente se parece a la tuya. Por eso, tras usar las comparativas para preseleccionar candidatos, la decisión debe tomarse midiéndolos con tus propios casos de uso reales y evaluando cuál da mejores resultados al costo y la velocidad que podés asumir. Es la diferencia entre elegir con datos propios y elegir por reputación.

No hay un plazo fijo, pero conviene revisarlo con cierta regularidad y no tratar la decisión como definitiva, porque el panorama de los modelos de inteligencia artificial cambia con una velocidad poco común. Aparecen modelos nuevos con frecuencia, los precios bajan, las capacidades mejoran y opciones que hoy no existen pueden volverse las más convenientes en pocos meses. Un modelo que elegiste por ser la mejor relación entre capacidad y costo puede quedar superado por otro más barato o más capaz al poco tiempo. Por eso es una buena práctica registrar la decisión junto con la fecha y los criterios que la motivaron, de modo que más adelante se pueda reevaluar con la misma lógica pero con las opciones actualizadas. Una revisión periódica, por ejemplo al planificar mejoras del proyecto o cuando el costo o el rendimiento empiezan a incomodar, permite aprovechar los avances sin caer en el extremo opuesto de cambiar de modelo constantemente, que introduce trabajo y riesgo. El equilibrio está en revisar cuando hay un motivo, no por moda.

Sí, y conviene ordenar las decisiones. Elegir el modelo es una decisión previa y de más alto nivel: primero se determina qué modelo base usar según la tarea y los criterios de capacidad, costo, latencia, privacidad y contexto. Recién después entran en juego RAG y fine-tuning, que son formas de adaptar ese modelo elegido a las necesidades concretas del proyecto. RAG le aporta conocimiento propio en el momento de responder, y el fine-tuning le enseña un comportamiento específico modificándolo. Es decir, no son alternativas a elegir el modelo, sino pasos posteriores que se apoyan sobre esa elección. En la práctica, una decisión influye en la otra: por ejemplo, si por privacidad se opta por un modelo abierto en la propia infraestructura, eso también condiciona cómo se implementarán RAG o un eventual ajuste fino. Lo recomendable es abordar las decisiones en orden —qué modelo, luego cómo adaptarlo— y en todos los casos validar las opciones midiéndolas con los propios casos de uso, que es el criterio que atraviesa tanto la elección del modelo como su adaptación.