Triar el model d'IA: tres preguntes que pesen més que el rànquing

Les comparatives entre GPT, Claude, Gemini i Llama canvien cada pocs mesos i cap no respon la pregunta que importa dins d'una empresa: quin model funciona amb els seus documents, el seu volum i les seves restriccions de dades. La tria es decideix amb tres preguntes concretes. I l'arquitectura ha de permetre canviar la resposta sense refer el sistema.

El rànquing públic respon una pregunta diferent de la que té l'empresa

Els benchmarks que publiquen proveïdors i laboratoris mesuren capacitats generals: raonament, programació, comprensió de textos llargs. Serveixen per saber quina família de models està al dia. Diuen poc sobre si un model classifica bé les incidències d'un servei tècnic escrites de pressa, amb abreviatures pròpies i adjunts escanejats a mitges.

Per això el primer pas és construir un conjunt d'avaluació propi. N'hi ha prou amb entre 50 i 100 exemples reals del procés, amb la resposta correcta anotada per algú del negoci: correus que cal classificar, factures de les quals cal extreure camps, preguntes que rep l'atenció al client. Amb aquest conjunt es proven dos o tres models en una tarda. El resultat és un número que sí que es pot comparar.

A la pràctica, aquest conjunt esdevé la prova de regressió del sistema. Cada canvi de prompt, de model o de proveïdor es valida contra el conjunt abans d'arribar a producció, igual que es valida un canvi de codi.

On poden anar les dades decideix la meitat de la tria

La segona pregunta és de governança. Hi ha processos les dades dels quals poden viatjar a l'API d'un proveïdor i processos en què la informació s'ha de quedar a la infraestructura de l'empresa: dades financeres, historials de clients, documentació subjecta a contracte.

Per al primer cas, els models comercials via API (Anthropic, OpenAI, Google) són l'opció més ràpida i la de millor qualitat per euro. Per al segon hi ha dos camins. Azure i AWS ofereixen aquests mateixos models dins del compte i la regió del client, a través d'Azure OpenAI Service o Amazon Bedrock, de manera que les dades no surten de l'entorn que l'empresa ja administra. I els models de pesos oberts, com Llama o Mistral, es poden desplegar en servidors propis quan el requisit és encara més estricte.

El que canvia amb un model propi és el cost operatiu. Algú ha de dimensionar la GPU, actualitzar versions i vigilar la latència. Convé assumir-ho només quan el requisit de dades ho exigeix o el volum ho compensa.

El volum converteix el preu per token en una decisió d'arquitectura

Amb uns centenars de peticions al dia, el preu del model gairebé no es nota a la factura i el raonable és fer servir el millor que hi hagi. Amb desenes de milers de peticions diàries, la diferència entre un model petit i un de gran separa un cost assumible d'un que obliga a aturar el projecte.

La resposta habitual és encaminar. Un model petit i ràpid classifica i resol els casos senzills. Els casos que fallen una validació o superen un llindar de complexitat passen a un model gran. El que cap dels dos no resol amb prou confiança arriba a una persona. El mateix esquema serveix per a l'atenció al client, per extreure dades de documents o per revisar contractes.

A canvi, cal mesurar. L'encaminament només funciona si existeix el conjunt d'avaluació de la primera pregunta, perquè és el que diu quina part dels casos es pot quedar al model barat sense perdre qualitat. Dues palanques més abaixen la factura sense tocar la qualitat: la memòria cau de prompts que ofereixen els proveïdors per als prefixos que es repeteixen a cada petició, i el processament per lots per a tot allò que no necessita resposta immediata.

L'arquitectura ha de permetre canviar de model sense reescriure el sistema

Els models que avui encapçalen les comparatives seran substituïts en qüestió de mesos. Per això cap procés no hauria de cridar el proveïdor directament des de la lògica de negoci. Als sistemes que construïm, una capa intermèdia rep la petició, tria proveïdor i model segons el tipus de feina, registra el cost i retorna la resposta amb el mateix format sigui quin sigui el model que hi ha al darrere.

Aquesta capa fa tres coses per l'empresa. Permet provar un model nou contra el conjunt d'avaluació i activar-lo amb un canvi de configuració. Permet tenir un proveïdor de reserva quan el principal falla o retira un model, cosa que passa més sovint del que sembla. I dona una visió del cost per procés que la factura del proveïdor no dona mai.

Dit d'una altra manera, la decisió important és reversible. Triar avui Claude, GPT o un Llama desplegat a Azure importa menys que poder canviar-lo en una setmana quan el conjunt d'avaluació digui que un altre model ho fa millor o més barat.

Per on començar aquesta setmana

• Triar un únic procés amb volum mesurable i un responsable de negoci que pugui anotar respostes correctes.
• Reunir 50 exemples reals amb la resposta esperada i desar-los com a conjunt d'avaluació.
• Classificar les dades d'aquest procés en tres grups: poden sortir cap a una API, s'han de quedar al núvol propi, o no poden sortir de l'empresa.
• Provar dos models de proveïdors diferents contra el conjunt i anotar qualitat, latència i cost per mil peticions.
• Dissenyar la integració amb una capa intermèdia des del primer dia, encara que només hi hagi un model al darrere.

Si el cas encaixa, a LakeTab el revisem en una primera trucada de 60 minuts.