LLM vs. ML tradicional

• Quatre idees clau
• No és una elecció binària
• Tres casos típics
• Quan un LLM guanya clarament
  • Entrades no estructurades sense esquema fix
  • Taxonomia canviant o poc volum d’etiquetes
  • Flux de treball end-to-end
  • Comportament open-set i long-tail
  • Tasques que requereixen accions
• Quan el ML clàssic guanya clarament
  • Dades tabulars estructurades
  • Classificació textual estable amb dades etiquetades
  • Alta freqüència d’inferència
  • Latència, reproducibilitat i privacitat
• L’escala pràctica
  • Embeddings + classificador clàssic
  • Prompting primer, fine-tuning després
  • Model petit fine-tunejat (LoRA / QLoRA)
  • Destil·lació: el LLM com a professor
  • Encaminament híbrid (ML + LLM)
  • LLM com a extractor de features
• Riscos específics que s’infravaloren
  • Deriva de model silenciosa
  • Complexitat amagada
  • Cost real a escala
  • Compliance i privacitat de dades
• Mesura abans de decidir
• Checklist de decisió
• Arbre de decisió curt

Cada vegada més equips usen LLMs per a tasques que podrien resoldre’s amb un model supervisat entrenat. De vegades és la millor decisió; de vegades és un error car. Aquest document ofereix un marc pràctic per decidir-ho.

L’objectiu no és memoritzar noms de models: és aprendre a fer-se la pregunta correcta. No es tracta de “quin model està de moda?”, sinó de quina és l’opció més simple que resol bé la tasca amb el cost, la latència i el nivell de control que necessites.

És un document de decisió, no un catàleg de models.

Quatre idees clau

Abans d’entrar en detalls, queda’t amb aquestes regles:

Si només recordes una regla d’or, que sigui aquesta: comença pel punt més simple del continu que pugui resoldre el problema i només puja de nivell si les dades demostren que cal.

No és una elecció binària

El marc “LLM o ML” és fals. Hi ha una escala de complexitat i cost creixents:

Regles deterministes
    → Embeddings + classificador clàssic
        → Model petit fine-tunejat (1B–7B)
            → LLM local (Ollama, vLLM)
                → API LLM frontier (GPT-4o, Claude, Gemini)

El problema real és que molts equips salten directament al final de l’escala per comoditat o per pressió de temps, i paguen un cost d’inferència que no es justifica. La pregunta correcta no és “usem LLM?”, sinó “fins on de l’escala hem de pujar per resoldre aquest problema?”

Tres casos típics

Abans de veure els arguments tècnics, mira tres exemples típics:

La lliçó és que el format de l’entrada, l’estabilitat de la tasca i el volum d’ús pesen més que la “potència” nominal del model.

Quan un LLM guanya clarament

Entrades no estructurades sense esquema fix

El ML supervisat tradicional funciona bé quan les features són estables i conegudes. Quan l’entrada és text lliure heterogeni (tickets de suport, correus, logs, contractes) el cost de feature engineering és tan alt que un LLM en mode zero-shot o few-shot és directament millor.

Exemple real: extreure camps estructurats (proveïdor, import, data, IVA, línies) de factures de formats arbitraris. Un model tradicional necessitaria un pipeline de parsing per cada format; un LLM amb sortida estructurada ho resol en una crida.

Taxonomia canviant o poc volum d’etiquetes

Re-entrenar un classificador cada vegada que canvia la llista de categories té un cost de cicle (etiquetatge → entrenament → validació → desplegament) que pot trigar dies o setmanes. Un LLM permet actualitzar el comportament canviant el prompt en minuts.

Regla pràctica: si la taxonomia canvia més d’una vegada al mes, o si tens menys de centenars d’exemples etiquetats per classe, el prompting guanya en velocitat i cost total.

Flux de treball end-to-end

El valor dels LLMs no és només la predicció: és que el mateix model que classifica pot generar l’artefacte resultant (resposta al client, query SQL, patch de codi, resum). Aquesta capacitat end-to-end no té equivalent directe en ML tradicional i és la justificació més sòlida per usar un LLM en contextos de producció.

Comportament open-set i long-tail

Els models supervisats fallen quan arriben categories noves o entrades fora de la distribució d’entrenament: retornen una predicció confident però equivocada, sense saber que no saben. Un LLM pot respondre “no ho sé” o “cap de les categories anteriors” si el prompt i les restriccions ho permeten, cosa que és operativament molt útil.

Tasques que requereixen accions

Quan la tasca no és classificar sinó actuar —consultar una API, escriure codi i executar-lo, encadenar diverses decisions— el marc canvia. Un model clàssic no pot planificar una seqüència d’accions ni adaptar-se a resultats intermedis.

El patró bàsic (ReAct):

Raona → Acció (crida eina) → Observació → Raona → ... → Resposta final

Exemple: un agent rep una queixa de client, consulta l’ordre a la base de dades, comprova l’estat de l’enviament i redacta una resposta personalitzada. Cap d’aquests passos és possible amb un classificador estàtic.

Quan té sentit un agent:

• La tasca requereix més d’una crida a eines o fonts de dades externes
• El nombre de passos no és fix: depèn dels resultats intermedis
• Cal raonament iteratiu on el resultat d’un pas condiciona el següent

Advertència: els agents amplifiquen els errors. Un model que s’equivoca el 5% de les vegades per pas acumula un error del ~23% en cinc passos encadenats (0.95^5 ≈ 0.77). Cal dissenyar fallbacks, límits de passos i validació dels resultats intermedis.

Quan el ML clàssic guanya clarament

Dades tabulars estructurades

Gradient boosting (XGBoost, LightGBM) supera els LLMs entre 5–15% en benchmarks reals de dades tabulars i ho fa a una fracció del cost d’inferència. En dominis com la detecció de frau, el credit scoring o la predicció de churn, les features numèriques i categòriques estructurades no necessiten comprensió de llenguatge.

Classificació textual estable amb dades etiquetades

Quan tens milers d’exemples etiquetats i la taxonomia és estable, embeddings semàntics + classificador clàssic (SVM, regressió logística) sovint superen el prompting directe en classificació multiclasse, amb millor calibratge de probabilitats i latència molt inferior.

El patró és: text → embedding (text-embedding-3, nomic-embed) → SVM / regressió logística. Comprensió semàntica en producció sense cap crida a un LLM.

Alta freqüència d’inferència

El cost real d’un LLM no és el que anuncia la taula de preus. El token de sortida costa entre 3 i 10 vegades més que el d’entrada, i per a una càrrega de treball típica (ratio sortida/entrada de 2x), el cost efectiu és ~9x el preu anunciat.

A escala, la diferència és dràstica: classificar 10 milions de documents al dia amb un model frontier API pot costar molt més que una alternativa local o petita. La diferència de preu entre models frontier i alternatives obertes és d’ordres de magnitud: els preus concrets canvien, però la proporció estructural es manté.

Latència, reproducibilitat i privacitat

• Latència: una inferència LLM sol ser d’ordre de centisegons; un model clàssic, microsegons.
• Reproducibilitat: els LLMs amb temperatura > 0 no són deterministes; un classificador tradicional sí.
• Dades sensibles: enviar dades a una API externa té implicacions de compliance (GDPR, HIPAA) que un model local no té.

L’escala pràctica

Molts equips no consideren les opcions intermèdies perquè requereixen més feina de setup que cridar una API. Sovint són la millor decisió.

Aquest és un punt important: en molts problemes reals, la millor resposta no és “LLM sí” o “LLM no”, sinó una opció intermèdia de l’escala.

Embeddings + classificador clàssic

from openai import OpenAI
from sklearn.linear_model import LogisticRegression

client = OpenAI()

def embedding(text: str) -> list[float]:
    return client.embeddings.create(
        model="text-embedding-3-small", input=text
    ).data[0].embedding

# Entrenament (una vegada)
X_train = [embedding(t) for t in textos_entrenament]
clf = LogisticRegression().fit(X_train, etiquetes)

# Inferència (sense LLM)
def classificar(text: str) -> str:
    return clf.predict([embedding(text)])[0]

Els embeddings es calculen una vegada per document i es poden pre-computar per a corpus estàtics. La inferència del classificador és trivial.

Prompting primer, fine-tuning després

Un error freqüent és recórrer al fine-tuning massa aviat. Té un cost de cicle significatiu (dades → entrenament → validació → desplegament) i afegeix una dependència de manteniment que el prompting no té. Abans de considerar-lo, s’han d’haver esgotat les tècniques de prompting en ordre creixent de complexitat:

El fine-tuning té sentit quan les evals mostren que el prompting ha assolit un plateau, quan el prompt creix tant que el cost d’inferència s’acumula, o quan la tasca requereix estil o coneixement de domini molt específic que el model base no té.

Model petit fine-tunejat (LoRA / QLoRA)

Un model de 1B–7B paràmetres fine-tunejat en unes poques hores sobre dades de la tasca concreta sol superar el prompting d’un model frontier en tasques especialitzades, amb una velocitat d’inferència 2–8 vegades superior i sense cost per crida. El fine-tuning eficient via LoRA o QLoRA és avui accessible amb una sola GPU consumer.

Quan té sentit: tasca molt específica del domini, milers d’exemples etiquetats, inferència contínua a gran escala.

Destil·lació: el LLM com a professor

El patró de destil·lació permet combinar la qualitat d’un LLM frontier amb el cost d’un model petit:

1. Defineix la tasca i recull les entrades (no cal etiquetes manuals)
2. Usa un LLM frontier per generar les etiquetes (teacher)
3. Valida manualment una mostra (10–20%) per mesurar la qualitat del teacher
4. Entrena un model petit sobre les etiquetes generades (student)
5. Desplega el model petit en producció

En aquest patró, el LLM no forma part del camí d’inferència de producció: serveix per generar dades d’entrenament. La limitació principal és que els termes d’ús de la majoria de proveïdors prohibeixen usar les sortides per entrenar models competidors directes, per la qual cosa cal revisar-ho cas per cas.

Encaminament híbrid (ML + LLM)

L’escala no implica triar un sol graó: el patró de millor cost/qualitat en la majoria de casos és combinar-ne dos. Un model ràpid gestiona els casos d’alta confiança; el LLM només rep els ambigus. En sistemes reals, aquest patró pot assolir estalvis de cost del 60–80% mantenint la qualitat en els casos difícils.

def classificar_amb_routing(text: str) -> str:
    confiança, etiqueta = model_rapid.predict(text)
    if confiança > 0.92:
        return etiqueta
    return classificar_amb_llm(text)

[Classificador ràpid] → confiança alta → resultat directe
                      → confiança baixa → [LLM]

La implementació del routing es cobreix a Patrons de programació amb LLMs.

LLM com a extractor de features

El LLM normalitza l’entrada desordenada en features estructurades; un model simple (o regles) pren la decisió final:

Text lliure → LLM (extreu: entitat, urgència, categoria) → JSON → Classificador / Regles → Acció

Es guanya en auditabilitat (la decisió final és traçable) i en cost (el model pesant fa la part lingüística; el classificador lleuger, la decisió).

Riscos específics que s’infravaloren

Deriva de model silenciosa

Els models clàssics deriven quan canvien les dades. Els LLMs deriven també quan el proveïdor actualitza el model sota el mateix nom d’API: sense versioning explícit, el comportament del sistema canvia sense que ningú hagi tocat el codi. gpt-4o d’avui no és el gpt-4o de fa sis mesos.

Mitigació: fixar versions explícites del model (gpt-4o-2024-08-06, no gpt-4o) i executar les evals en cada actualització planificada del proveïdor.

Complexitat amagada

Un LLM pot semblar que funciona sense que entenguis per què. En ML clàssic, les feature importances, les matrius de confusió i els errors de validació creuada expliquen els errors. En un LLM, el debugging és opac: canvies el prompt, pots millorar o empitjorar casos imprevisibles, i la relació causa-efecte no és transparent.

Aquest risc és especialment alt quan no hi ha evals sistemàtiques: l’equip opera amb confiança subjectiva, no amb mètriques.

Cost real a escala

La taula de preus dels proveïdors anuncia el preu del token d’entrada. El cost efectiu és molt superior perquè s’acumulen diversos factors:

• Tokens de sortida costen entre 3 i 10 vegades més que els d’entrada. Per a un ratio sortida/entrada de 2×, el cost ja és ~5× el preu anunciat.
• Prompt de sistema repetit en cada crida: s’acumula com a cost d’entrada en cada inferència.
• Reintents per errors de format: +10–30% de crides addicionals.
• Context llarg (historial, RAG): els tokens d’entrada creixen amb cada torn de conversa.

Quantificar el cost per cas d’ús real (no per token) és el primer pas per decidir si el LLM és viable a escala.

Compliance i privacitat de dades

Enviar dades a una API externa implica: transferència fora del perímetre corporatiu, possibilitat d’ús en entrenament futur (cal revisar els termes d’ús), i jurisdicció del proveïdor sobre les dades. Un model local (Ollama, vLLM) elimina aquestes implicacions però afegeix cost d’infraestructura.

Mesura abans de decidir

En ML clàssic, aquest procés s’anomena simplement avaluació del model: conjunt de test, validació creuada, mètriques de classificació. En el món LLM s’anomena evals, però el principi és idèntic: cal un criteri d’èxit objectiu i mesurable abans de triar cap tècnica.

Cap de les decisions anteriors és defensable sense un gold set mesurable: un conjunt petit de casos curats manualment amb la sortida esperada. L’anti-patró dominant (i el que genera més feina extra) és triar una tècnica “a ull”, declarar que funciona i descobrir els errors en producció.

Estudis de Hamel Husain i Shreya Shankar (2024–2025) sobre equips que usen LLMs en producció mostren que ~75% dels equips que fan fine-tuning podrien obtenir resultats equivalents amb prompting o workflows més senzills si haguessin mesurat primer.

La seqüència correcta és sempre:

Definir la tasca i els criteris d'èxit
    → Construir un gold set mínim (20–50 casos)
        → Mesurar la baseline (regles / embedding / LLM zero-shot)
            → Decidir si cal pujar per l'escala

Vegeu Avaluació de sistemes LLM per a la metodologia completa.

Checklist de decisió

Si has llegit tot el document, aquesta és la versió resum. Respon les sis preguntes. Si la majoria de respostes apunten cap a una opció, aquella és el punt d’entrada a l’escala.

Arbre de decisió curt

Quan dubtis, recorre aquest flux abans d’anar a una API frontier:

1. L'entrada és tabular o molt estructurada?
    → Sí: prova ML clàssic primer.
    → No: continua.

2. Tens text lliure i poques etiquetes?
    → Sí: prova LLM zero-shot/few-shot o embeddings + classificador.
    → No: continua.

3. La tasca és estable i tens moltes dades etiquetades?
    → Sí: prova embeddings + classificador o un model petit fine-tunejat.
    → No: continua.

4. Necessites generar text, executar accions seqüencials o encadenar eines?
    → Sí: un LLM probablement té sentit. Si calen accions múltiples, considera un agent.
    → No: potser no cal pujar tant al continu.

Regla d’or: comença sempre pel graó més baix de l’escala que pugui resoldre el problema. Puja un graó quan les evals demostrin que el graó anterior és insuficient, no abans.