Un solo archivo le habla al modelo

Si estás metiendo un modelo de lenguaje en un producto que ya funciona, esta nota te dice dónde poner la frontera y qué cinco decisiones tomar en ella. Todas se toman una vez y se pagan durante años.

En todo nuestro repositorio hay un solo archivo que le habla a un modelo de lenguaje. Uno. Las herramientas que consulta, el filtro que tapa los datos personales, la pantalla que enseña la respuesta: ninguno de los tres sabe quién contesta al otro lado.

El criterio es el mismo que aplicamos al archivo que habla con la API de WhatsApp: se aísla la frontera con un sistema que no controlamos. Lo que hay detrás de esa puerta cambia cuando el proveedor quiere, no cuando nosotros queremos.

El día que se cambie de proveedor, se cambia ese archivo y nada más se mueve.

No es una promesa de folleto: es comprobable mirando qué importa cada módulo. Si diez archivos supieran el nombre del proveedor, cambiarlo sería un proyecto. Sabiéndolo uno, es una tarde.

Y lo comprobamos sin querer. El proveedor empezó a exigir una cabecera nueva y a rechazar toda petición que no la llevara. Como ese archivo es lo único que habla con un modelo, se cayeron a la vez las dos cosas que dependen de él: el asistente que consultan las personas y el agente que redacta borradores.

La cara mala: se cayó en silencio. Las dos funciones devuelven el fallo en vez de lanzarlo —que es correcto y no se toca— así que desde fuera no parecía una caída sino que «el modelo no sabía contestar». Se descubrió probando contra el proveedor de verdad, no por una alerta.

La cara buena: el arreglo fue ese archivo y nada más. Dos productos caídos, un archivo tocado.

Casi todo proveedor de inteligencia artificial publica un paquete oficial para su lenguaje. Instalarlo es lo primero que hace todo el mundo.

Nosotros no lo instalamos, y el argumento es aburrido a propósito: este repositorio tiene cinco dependencias en total, y lo que necesitábamos del proveedor son dos peticiones web. Añadir un paquete con sus propias dependencias para ahorrarse dos peticiones es cambiar código que entiendes por código que no.

Ayuda que la interfaz del proveedor sea compatible con la de OpenAI, que se ha convertido en el idioma común. Los mensajes y las herramientas viajan tal cual, sin traducir a una forma propia: traducir solo añadiría un sitio donde equivocarse y una capa que hay que mantener al día cada vez que el formato crezca.

Elegir modelo suele contarse como una comparación de listas de capacidades. En la práctica son tres preguntas, y el orden importa más que las respuestas.

• ¿Admite herramientas? Es decir, ¿puede pedir datos en vez de inventarlos. Todo el diseño cuelga de eso, así que un modelo que no las admita está descartado por bueno que sea escribiendo.
• ¿Le cabe una bandeja entera? Si el contexto no alcanza para lo que hay que enseñarle, la respuesta será parcial y no habrá forma de saber qué se quedó fuera.
• ¿Cuesta poco? Va tercero, no primero. Pero va, y sin disimulo: quien paga la consulta somos nosotros, no el cliente.

Lo que este orden evita es la trampa habitual: empezar por el precio y descubrir a los dos meses que el modelo barato no sabe llamar herramientas, que era el requisito del que colgaba todo.

Para saber lo que cuesta una consulta hay que tener escritos los precios por millón de tokens. Están en el código y no en la base de datos, porque son una constante del proveedor y no un dato del negocio. Si se quedan viejos, lo que falla es la contabilidad interna, no el producto.

La decisión interesante es otra: ¿qué se cobra por un modelo que no está en la tabla?

Lo intuitivo es cero, o no anotar nada. Nosotros lo cobramos al precio del más caro que conocemos, y es deliberado. El abanico entre modelos es enorme —hay más de un orden de magnitud entre los baratos y los caros— así que adivinar bajo no es un error pequeño.

Es la misma lógica de los fusibles: cuando no sabes, falla del lado que se nota enseguida y no del lado que se nota tarde.

Esta es la decisión más importante del archivo y no es técnica.

El catálogo de nuestro proveedor declara retención cero: lo que se le manda no se guarda ni se usa para entrenar. Sus modelos gratuitos y de prueba están excluidos de esa promesa, justamente porque el precio es ese.

Mandar la bandeja de un cliente por un modelo que entrena con lo que recibe es regalar los datos de un tercero que nunca lo autorizó: no son datos nuestros, son los de la gente que le escribe a ese negocio.

Así que la lista de modelos prohibidos está escrita en el código y se comprueba en cada llamada, no en una variable de entorno que alguien pueda cambiar con buena intención una noche de ahorro.

Y cuando se topa con uno, falla ruidosamente: no cae al modelo por defecto. Si alguien lo puso ahí queriendo ahorrar, tiene que enterarse, no salirse con la suya en silencio. Un mecanismo de seguridad que se arregla solo enseña que se puede intentar.

• Cuenta cuántos archivos tuyos saben el nombre del proveedor.Si son más de uno, cambiar de proveedor ya es un proyecto.
• Antes de instalar el paquete oficial, mira cuántas llamadas necesitas. Si son dos, el paquete te cuesta más de lo que te ahorra.
• Ordena tus criterios antes de comparar precios. Herramientas y contexto primero; el precio decide entre los que ya sirven.
• Lee la política de retención del modelo concreto, no la del proveedor. Los gratuitos casi siempre están fuera de la promesa, y eso se cuenta en una nota al pie.
• Pon la lista de lo prohibido en el código. Lo que se puede cambiar con una variable de entorno se va a cambiar con una variable de entorno.