Cómo elegimos la IA adecuada para cada función
Cuando se diseña una función basada en inteligencia artificial, la pregunta "qué modelo uso" parece que debiera responderse una sola vez, al principio. En la práctica de NovLore no fue así: con el tiempo nos dimos cuenta de que tareas distintas del producto tenían necesidades tan diferentes entre sí que un solo proveedor, por bueno que fuera, no podía servirlas todas bien. Este artículo cuenta por qué, y cómo está hecho hoy el sistema que nació de eso.
El problema que impulsó la elección
Al principio Scintilla —el asistente de escritura de NovLore— mantenía juntas dos tareas distintas en un solo canal: la conversación con el usuario y la generación del panel de la obra (personajes, lugares, trama) a partir de esa conversación. Parecían relacionadas, pero tenían necesidades opuestas: la conversación necesita responder rápido, mientras que generar datos estructurados coherentes necesita tomarse el tiempo de razonarlo. Un solo proveedor, optimizado para una de las dos necesidades, penalizaba sistemáticamente la otra.
La solución no fue buscar un proveedor que hiciera bien ambas cosas. Fue dejar de tratarlas como la misma tarea.
Seis ámbitos, no uno
Hoy cada función de IA de NovLore declara su propio ámbito —corrección, reescritura, chat, estructura, capítulo, transcripción— y cada ámbito puede tener un proveedor distinto como primera opción. El chat de Scintilla, por ejemplo, usa un modelo elegido por la rapidez de respuesta; la generación de un capítulo entero, que el usuario lanza sabiendo que tendrá que esperar, usa en cambio un modelo elegido por la calidad de la prosa en una tarea larga.
| Ámbito | Qué hace | Qué importa más |
|---|---|---|
| Chat | conversación con el asistente | velocidad de respuesta |
| Corrección | erratas y coherencia gramatical | precisión, coste bajo |
| Reescritura | modificación de un texto seleccionado | calidad estilística |
| Estructura | datos estructurados sobre personajes/trama | fiabilidad del formato |
| Capítulo | generación de un capítulo entero | calidad en texto largo |
| Transcripción | preparado, aún no activo | — |
Ninguna de estas elecciones es definitiva: un panel de administración permite cambiar el proveedor y la reserva de cada ámbito sin tocar el código, porque el coste y la calidad relativa de los modelos cambian con el tiempo más rápido de lo que cambia el software.
Por qué siete proveedores y no uno "suficientemente bueno"
Con un solo proveedor, cada interrupción de su servicio —y le pasa a todos, incluso a los mejores— se convierte en una interrupción de todo el producto. La solución más común es tener una reserva; la menos obvia, pero más sólida, es que la reserva no debe pasar por el mismo canal que la primera opción. Si la primera opción y la reserva son dos rutas distintas hacia el mismo proveedor de fondo, una indisponibilidad de ese proveedor tira abajo ambas a la vez.
Por eso, cuando la primera opción de un ámbito es un agregador que da acceso a varios modelos con una sola clave, la reserva va deliberadamente a un proveedor directo e independiente. Es una redundancia real, no solo sobre el papel.
Qué ve el usuario cuando se activa la reserva
Nada, si el sistema funciona como debe. Si el proveedor de primera opción para un ámbito no responde, el paso a la reserva es transparente: la solicitud llega igualmente a buen puerto, y solo un dato técnico interno registra que quien respondió fue la segunda opción. En el streaming —las respuestas que aparecen palabra por palabra, como en el chat— la reserva solo puede activarse antes de que llegue el primer fragmento de texto: una vez iniciada la respuesta, cambiar de proveedor a mitad de camino produciría un texto cosido con dos estilos distintos, peor que esperar unos segundos más.
La transparencia de la reserva no es un detalle técnico para aficionados a la infraestructura: es la diferencia entre un usuario que nota una ralentización ocasional y un usuario que ve un error mientras está escribiendo su novela.
El router como único punto de paso
Para que este sistema aguante en el tiempo, cada función de IA del producto —incluidas las de salida estructurada y las de streaming— pasa por un único router interno, nunca directamente por los proveedores. Es una elección que cuesta disciplina (ningún atajo, ni siquiera para una función "temporal") pero que se paga de un modo preciso: cuando un proveedor cambia sus condiciones, o llega uno nuevo que vale la pena añadir, el cambio se hace en un solo lugar, no en diez endpoints distintos escritos en momentos diferentes.
Preguntas frecuentes
¿Por qué no usar siempre el modelo más potente disponible?
Porque "más potente" no es lo mismo que "más adecuado para la tarea". Un modelo excelente en texto largo y creativo puede ser lento y caro para un chat que debe responder en un segundo; usarlo en todas partes haría parecer lenta incluso la parte del producto que debería ser instantánea.
¿Puede el usuario elegir qué IA usar?
No directamente en cada mensaje: la elección es por ámbito y la gestiona quien administra el producto, según la calidad y fiabilidad observadas con el tiempo. Es una elección deliberada —dejarla en manos del usuario trasladaría a él una decisión técnica que requiere monitorizar continuamente siete proveedores distintos.
¿Qué pasa si tampoco responde la reserva?
La operación falla con un error explícito, y en el caso de una acción con créditos, el cargo se anula automáticamente sobre el mismo lote del que se había tomado: el usuario no paga por una solicitud que no recibió respuesta.
¿Este sistema ralentiza el desarrollo de nuevas funciones de IA?
A corto plazo sí, ligeramente: añadir una función requiere pasar por el router en vez de llamar directamente a una API. A medio plazo es lo contrario, porque cada función nueva hereda gratis la gestión de errores, la reserva y el seguimiento de costes ya construidos una sola vez.