Selecció de model per cas d’ús

• Capacitats del model
• Capacitats d’execució i desplegament
• Requisits per cas d’ús
• Com avaluar un model nou
• Perfils de model
• Estratègies generals de selecció
  • Identificar les capacitats crítiques primer
  • API vs. model local
  • Mida del model
  • Raonament estès
  • Cost: on actuar
  • Per cas d’ús: punts de partida
• La matriu aplicada: un exemple

Els casos d’ús descrits a Arquitectures per cas d’ús requereixen subconjunts de capacitats diferents. No tots els models les suporten, i els que ho fan les implementen amb qualitat i cost variables.

Aquest document estructura les capacitats rellevants i els seus requisits per cas d’ús. Aquesta matriu és un marc d’avaluació: serveix tant per seleccionar models existents com per avaluar qualsevol model nou. Deliberadament no conté una llista de models concrets, perquè aquesta llista queda obsoleta en mesos, mentre que les capacitats que cal verificar i el criteri per triar-les es mantenen.

Com llegir la matriu: primer mira les capacitats del model per descartar opcions, i després les capacitats d’execució i desplegament per validar que la solució encaixa amb la infraestructura. A la taula de casos d’ús, ✓ indica que una capacitat és necessària, ○ que és recomanable o parcialment útil, i — que no cal.

Capacitats del model

Capacitats d’execució i desplegament

¹ Open weights: el fabricant publica els pesos entrenats del model perquè qualsevol els pugui descarregar i executar. Diferent de open source en sentit estricte: els pesos poden tenir llicències que restringeixen l’ús comercial.

Requisits per cas d’ús

✓ requerit · ○ recomanat · — no necessari

Les cinc primeres columnes són capacitats funcionals del model. Les quatre últimes descriuen requisits d’execució, lliurament i manteniment que poden condicionar la selecció final encara que el model sigui tècnicament capaç de resoldre la tasca.

Notes sobre els requisits:

• Sortida estructurada és necessària sempre que el backend ha de parsejar la sortida del model programàticament. En els casos conversacionals purs (2), la sortida és text lliure.
• Raonament estès aporta valor clar en els casos 5, 8 i 9, on la planificació i el raonament multi-pas són el coll d’ampolla. En els altres casos afegeix latència i cost sense benefici proporcional.
• Context llarg és imprescindible quan l’historial de conversa creix molt (cas 2) o quan el context recuperat per RAG és voluminós (casos 3, 8). Per a la majoria de documents habituals, 128K és suficient.
• Prompt caching és una optimització de cost, no una capacitat funcional. Val especialment la pena en casos on el system prompt és llarg i estàtic i hi ha moltes peticions (casos 4 i 6).
• Fine-tuning és una optimització tardana: prova primer amb prompting i few-shot. Té sentit per als casos 1 i 6 quan hi ha milers d’exemples etiquetats i el prompting no arriba a la qualitat requerida.

Com avaluar un model nou

Per aplicar la matriu a qualsevol model (nou, propi, open source o comercial) cal verificar cada capacitat de forma independent:

¹ Needle-in-a-haystack: benchmark que amaga un fet concret en un document llarg i comprova si el model el recupera. Mesura si el model realment usa tot el context o perd atenció al mig de la finestra.

La verificació no ha de ser exhaustiva per a totes les capacitats, només per a les marcades amb ✓ o ○ en la matriu del cas d’ús concret.

Perfils de model

Els noms concrets canvien cada pocs mesos; els perfils són estables. Qualsevol model que avaluïs encaixarà aproximadament en un d’aquests quatre, i el perfil et diu quines capacitats pots donar per fetes i quines has de verificar.

✓ habitual · ○ variable, cal verificar · — poc habitual

Notes sobre els perfils:

• Sortida estructurada als models autoallotjats requereix guided_json (vLLM) o Outlines, que imposa l’esquema directament a la mostra de tokens. Sense aquesta infraestructura, la fiabilitat és variable. Als models d’API sol ser nativa i fiable.
• Raonament estès és sovint configurable: es pot desactivar, o regular amb un paràmetre d’esforç. Activar-lo incrementa latència i cost, i converteix funcionalment qualsevol model en un model de raonament. En alguns models ve activat per defecte i en d’altres no: comprova-ho abans d’assumir res sobre el cost per crida.
• Prompt caching als models autoallotjats no és natiu del model: depèn del servidor d’inferència (prefix caching a vLLM). La columna reflecteix la disponibilitat de la infraestructura, no del model en si.
• Fine-tuning no és universal ni tan sols entre models d’API: alguns proveïdors no l’ofereixen públicament i el reserven a acords empresarials. Verifica-ho abans de dissenyar-hi al voltant.
• La qualitat de tool use varia molt més que la resta de capacitats. Els models autoallotjats requereixen validació amb evals pròpies per a cada cas d’ús, especialment en agents amb moltes eines o condicions d’error.
• Visió és nativa en la majoria de models frontier i mitjos recents. En models autoallotjats depèn de la variant concreta: dins d’una mateixa família sovint conviuen versions multimodals i només-text.
• El context creix a cada generació i els ordres de magnitud actuals van de centenars de milers a milions de tokens. El que importa per a la decisió no és la xifra anunciada sinó l’efectiva (vegeu la nota sobre needle-in-a-haystack més amunt).

Estratègies generals de selecció

Identificar les capacitats crítiques primer

Abans de triar un model, identificar quines capacitats de la matriu estan marcades com ✓ per al cas d’ús concret. Qualsevol model candidat ha de superar la verificació d’aquelles capacitats; les marcades amb ○ s’avaluen si hi ha empat.

API vs. model local

La tria entre API comercial i model local no és principalment de qualitat, sinó de privacitat, cost i control:

Les llicències de models open weights van des d’Apache 2.0 (ús comercial lliure) fins a llicències comunitàries pròpies de cada fabricant, que poden requerir acceptació explícita, obligar a atribució o limitar l’ús per sobre d’un llindar d’usuaris. Open weights no implica open source: desplegar un model autoallotjat en producció sense revisar-ne la llicència és un risc legal.

Punt de partida: avalua primer si hi ha restriccions que descartin una de les dues opcions: la privacitat de dades, la regulació sectorial (RGPD, HIPAA, etc.) o la política interna poden fer inviable l’API comercial des del principi; el cost d’operació o la manca de capacitat tècnica per mantenir infraestructura poden fer inviable el model local. Si cap restricció ho determina, l’API comercial sol ser el camí més ràpid per validar. En qualsevol cas, si s’opta per model local, verificar la llicència dels pesos abans de desplegar.

Mida del model

Els models grans costen més per crida però solen requerir menys reintents, produeixen menys errors d’esquema i gestionen millor els casos límit. Per a la majoria de casos d’ús, el cost marginal d’un model mig és acceptable.

Quan usar un model petit: la tasca és simple i ben definida (classificació binària, extracció de camps fixes), el volum és molt alt, o s’usa com a worker dins d’un sistema multi-agent on el supervisor és el model gran.

No escalar per sota del que els evals demostren que funciona. Canviar de model gran a petit per estalviar cost sense mesurar l’impacte en la qualitat és un dels errors més habituals en sistemes LLM en producció.

Raonament estès

El raonament estès (thinking tokens) millora la qualitat en tasques on el nombre de passos o la complexitat de la planificació és el coll d’ampolla. No millora tasques simples, on només afegeix latència i cost:

Cost: on actuar

Tres mecanismes redueixen el cost sense canviar de model:

1. Prompt caching: per a system prompts llargs i estàtics (> 1K tokens) amb moltes peticions, el caching redueix substancialment el cost d’entrada (vegeu Control de costos). Imprescindible per als casos 4 i 6.
2. Batch API: els proveïdors comercials processen batches asíncronament a cost per token reduït. Adequat quan no hi ha restriccions de temps (vegeu el cas 6 d’Arquitectures per cas d’ús).
3. Model mínim suficient: mesurar la qualitat per tasca senzilla amb el model petit abans d’assumir que cal el gran. En classificació i extracció, models petits sovint arriben al 95% de la qualitat del model gran.

Per cas d’ús: punts de partida

La columna “primera opció” reflecteix models que cobreixen les capacitats crítiques amb bona qualitat sense verificació addicional. La columna “alternativa econòmica” pot requerir validació amb evals pròpies.

Regla general: comença amb el model mig del proveïdor actual, que és un bon equilibri cost/qualitat per a la majoria de casos. Escala al model frontier si els evals mostren insuficiència en raonament. Mou a un model open weights autoallotjat si la privacitat o el cost en producció ho requereix, i verifica les capacitats crítiques amb evals pròpies.

La matriu de verificació de la secció Com avaluar un model nou és l’eina per situar qualsevol model dins d’aquests perfils quan aparegui.

La matriu aplicada: un exemple

Aquestes taules són d’ús seqüencial, i val la pena veure-les funcionar una vegada. Suposem el cas 5, un agent amb eines, per a un servei intern que consulta la base de dades de comandes i pot iniciar devolucions.

1. Quines capacitats són obligatòries. A la fila del cas 5 de la matriu, tool use i sortida estructurada porten ✓ i no són negociables: sense la primera l’agent no pot actuar, i sense la segona el backend no pot llegir el que retorna. El raonament estès i el context llarg hi surten amb ○, o sigui que ajudaran si el flux acaba tenint molts passos, però no descarten cap candidat.

2. Quines restriccions imposa l’entorn. Les comandes porten dades de clients i la política interna diu que no poden sortir de la xarxa de l’organització. Aquesta restricció resol la taula d’API contra model local abans de mirar cap capacitat: cal un model open weights autoallotjat.

3. Quin perfil encaixa. A la taula de perfils, la fila open weights dona el tool use com a habitual, però la sortida estructurada com a ○, i les notes adverteixen que la qualitat del tool use és precisament la que varia més entre models d’aquest perfil. Encara no has provat res i ja saps què hauràs de comprovar.

4. Què verifiques. De la taula Com avaluar un model nou, només les dues files que t’han sortit ✓. Per a la sortida estructurada: el servidor admet guided_json, i de 100 crides quantes tornen un esquema invàlid. Per al tool use: si emet tool_calls en format compatible, i quin percentatge de crides tria l’eina correcta amb el teu catàleg real, no amb un d’exemple.

5. Què fas si no hi arriba. Si el model més gran que et cap a la GPU falla el tool use amb les dotze eines del catàleg, encara tens dues palanques abans de replantejar la restricció de privacitat: reduir el catàleg que veu el model a cada ruta, o partir la feina en agents especialitzats (cas 9) perquè cadascun en vegi menys. Si ni així, tens un requisit de privacitat i un requisit de capacitat que no es poden satisfer alhora, i això ja és una conversa de producte i no una decisió tècnica.

📝 Per als patrons de prompting, sortida estructurada i tool use, vegeu Prompts i integració. Per als requisits de maquinari dels models locals i les opcions de desplegament, vegeu Arquitectura de sistemes LLM.