better

# LLMs i IA Generativa

Models de llenguatge grans: arquitectura, ús aplicat i desplegament de sistemes basats en LLMs. Els documents segueixen una progressió: primer els fonaments, després la construcció de sistemes i, finalment, l'avaluació, l'aplicació a casos concrets i l'operació en producció.

Models de llenguatge grans: arquitectura, ús aplicat i desplegament de sistemes basats en LLMs. Els documents segueixen una progressió: primer els fonaments, després la construcció de sistemes i, finalment, l'aplicació a casos concrets i l'operació en producció.

## Com llegir aquests documents

Construir un sistema amb LLMs és, sobretot, respondre tres preguntes en aquest ordre. Cada pregunta té el seu document, i val la pena tenir-les presents perquè els materials estan escrits al voltant d'aquest fil:

1. **Cal un LLM?** Moltes tasques es resolen millor amb un model clàssic, amb embeddings o directament amb regles. La resposta és a [LLM vs. ML tradicional](./llms/llm_vs_ml.md).

2. **Quin patró?** Si el flux el controla el codi tens un workflow; si el decideix el model, un agent. La tria i els seus híbrids són a [Orquestració amb workflows i agents](./llms/llm_patterns.md).

3. **Quin model?** Només al final, i a partir de les capacitats que el cas d'ús exigeix de veritat: [Selecció de model per cas d'ús](./llms/llm_model_selection.md).

Les tres respostes comparteixen un mateix requisit previ: **mesurar**. Per això [Avaluació de sistemes LLM](./llms/llm_evals.md) no és una etapa que arribi al final sinó un document transversal, referenciat des de gairebé tots els altres.

```mermaid

flowchart TD

    T["Transformers i models de llenguatge"] --> V["LLM vs. ML tradicional"]

    T --> A["Arquitectura de sistemes LLM"]

    A --> S["Prompts i integració"]

    S --> P["Orquestració: workflows i agents"]

    P --> U["Arquitectures per cas d'ús"]

    U --> M["Selecció de model per cas d'ús"]

    U --> O["Sistemes LLM en producció"]

    E["Avaluació de sistemes LLM"]

    E -.-> V

    E -.-> P

    E -.-> U

    E -.-> O

```

## Fonaments

## Construcció de sistemes

- [Arquitectura de sistemes LLM](./llms/llm_architecture.md): el LLM com a component de programari, el servei d'inferència (Ollama, vLLM), l'API estàndard i els requisits de maquinari

- [Arquitectura de sistemes LLM](./llms/llm_architecture.md): el LLM com a component de programari, el servei d'inferència (vLLM, Ollama), l'API estàndard i els requisits de maquinari

- [Prompts i integració](./llms/llm_systems.md): dissenyar prompts com a artefactes de programari i cridar el model des del codi, amb sortida estructurada, memòria, resiliència i seguretat

- [Orquestració amb workflows i agents](./llms/llm_patterns.md): compondre les crides en sistemes: workflows deterministes, RAG, agents amb eines, MCP i sistemes multi-agent

## Avaluació

## Avaluació (transversal)

- [Avaluació de sistemes LLM](./llms/llm_evals.md): golden set, anàlisi d'errors, LLM-as-judge i el cicle de millora dirigit per evals

Aquest document es llegeix millor aviat, encara que la seva pràctica arribi més tard: la resta de documents hi remeten cada vegada que cal decidir alguna cosa amb dades en comptes de fer-ho a ull.

## Aplicació

- [Arquitectures per cas d'ús](./llms/llm_use_cases.md): nou casos d'ús concrets, amb les capes actives, les decisions de disseny i un exemple de codi per a cadascun

## Operació

- [Sistemes LLM en producció](./llms/llm_production.md): observabilitat, control de costos, desplegament i cicle de vida del sistema

## Itinerari curt

Si no pots llegir-ho tot, aquests quatre documents en ordre donen una base completa per construir un primer sistema:

[Transformers i Models de Llenguatge](./llms/ml_transformers.md) → [Arquitectura de sistemes LLM](./llms/llm_architecture.md) → [Prompts i integració](./llms/llm_systems.md) → [Avaluació de sistemes LLM](./llms/llm_evals.md)

Les evals compleixen el mateix rol que els tests unitaris en el programari convencional, però adaptats a les propietats dels LLMs: sortida no determinista, qualitat graduada (una resposta pot ser parcialment correcta), i fluxos multi-pas.

La distinció fonamental que s'aplica aquí és la mateixa que per a qualsevol sistema ML: el **codi determinista** (parsing de la sortida, validació d'esquemes, routing, eines) es testa amb pytest convencional; el **comportament del model** (qualitat de la resposta, correcció de la tasca) es valida amb evals. Consulta [Validació i qualitat](../ba2/02_model_quality_and_testing.md) per als patrons generals de testing i CI/CD en sistemes ML.

La distinció fonamental que s'aplica aquí és la mateixa que per a qualsevol sistema ML: el **codi determinista** (parsing de la sortida, validació d'esquemes, routing, eines) es testa amb pytest convencional; el **comportament del model** (qualitat de la resposta, correcció de la tasca) es valida amb evals. Vegeu [Validació i qualitat](../ba2/02_model_quality_and_testing.md) per als patrons generals de testing i CI/CD en sistemes ML.

## Anatomia d'una eval

    └── Casos sintètics     ← confiança baixa; amplien cobertura però no bloquegen desplegament

```

## Qui defineix la qualitat

Un cop decidit que el golden set és la referència, queda la pregunta de qui hi posa les etiquetes. Una eval només és tan bona com el criteri que codifica, i aquest criteri ha de tenir un propietari únic. El patró recomanat és designar **una sola persona experta del domini** (el clínic per a salut mental, l'advocat per a documents legals, l'agent de suport sènior per a atenció al client) com la veu definitiva de què és una resposta acceptable: és qui etiqueta els casos i contra qui es calibren després els [avaluadors automàtics](#tipus-davaluadors). Repartir aquesta autoritat entre diversos anotadors introdueix desacords sobre on cau el llindar i acaba en paràlisi; només es justifica quan el domini ho exigeix (per exemple, contextos multilingües o multijurisdiccionals). Aquesta persona no cal que ho etiqueti tot, una mostra representativa n'hi ha prou, però el criteri ha de ser seu.

## Anàlisi d'errors

Les evals **mesuren** si una fallada coneguda torna a aparèixer; no et diuen quines fallades existeixen. Aquest segon problema (descobrir *com* falla realment el sistema) no el resol cap mètrica automàtica: el resol llegir la sortida real, una traça a una. Aquesta pràctica té nom propi, **anàlisi d'errors**, i és la baula que alimenta tota la resta de la suite.

L'anàlisi d'errors és un procediment manual i deliberat, no una eina que s'executa. Tampoc s'externalitza ni es delega a un LLM en aquesta fase: el valor no és la llista de categories sinó el coneixement tàcit del producte que s'adquireix llegint, i això es perd si ho fa una altra persona o un model en lloc teu.

1. **Recull una mostra de traces reals.** El millor material són les traces de producció amb puntuació baixa o errors (vegeu [evals online](#offline-i-online) i [observabilitat](llm_production.md#traces-la-unitat-dobservacio)); a falta de producció, executa el sistema sobre els casos inicials escrits a mà (el *seed set*, vegeu [Fonts de casos](#fonts-de-casos)) i mira les sortides. 30–50 traces són suficients per començar a veure patrons; com a criteri de parada, segueix llegint fins que unes ~20 traces seguides no aportin cap categoria de fallada nova (saturació).

1. **Recull una mostra de traces reals.** El millor material són les traces de producció amb puntuació baixa o errors (vegeu [evals online](#offline-i-online) i [observabilitat](llm_production.md#traces-la-unitat-dobservació)); a falta de producció, executa el sistema sobre els casos inicials escrits a mà (el *seed set*, vegeu [Fonts de casos](#fonts-de-casos)) i mira les sortides. 30–50 traces són suficients per començar a veure patrons; com a criteri de parada, segueix llegint fins que unes ~20 traces seguides no aportin cap categoria de fallada nova (saturació).

2. **Etiqueta què ha fallat a cada traça.** Per a cada cas defectuós, escriu en una frase *quin* error ha comès, no una categoria predefinida, sinó el que realment veus ("ha inventat una política de devolució", "ha respost en castellà tot i la instrucció", "ha citat un fragment irrellevant"). Aquesta etiqueta lliure és l'observació crua. En traces multi-pas, etiqueta la *primera* fallada de la cadena: els errors posteriors solen ser cascada d'aquest primer, i corregir-lo sovint els fa desaparèixer tots de cop.

3. **Agrupa les etiquetes en categories i compta-les.** Un cop tens 30–50 etiquetes, modes de fallada similars es col·lapsen en poques categories. Comptar quantes traces cau a cada categoria converteix una pila d'anècdotes en una distribució.

4. **Corregeix primer la categoria més freqüent.** La fallada que apareix més vegades és la que, un cop resolta, millora més el comportament global del sistema. Quan l'hagis corregida, torna a comptar: la distribució de fallades haurà canviat.

> 📝 El binari és el valor per defecte recomanat aquí, no una regla absoluta. Hi ha contextos on una puntuació graduada és legítima: els models de recompensa de l'RLHF donen un escalar per resposta, i una rúbrica amb nivells ancorats a exemples concrets pot evitar el problema del «3 vs 4». El criteri pràctic: si pots ancorar cada nivell amb un exemple i diferents persones hi coincideixen, una escala pot servir; si no, el binari t'estalvia una falsa precisió.

## Qui defineix la qualitat

Una eval només és tan bona com el criteri que codifica, i aquest criteri ha de tenir un propietari únic. El patró recomanat és designar **una sola persona experta del domini** (el clínic per a salut mental, l'advocat per a documents legals, l'agent de suport sènior per a atenció al client) com la veu definitiva de què és una resposta acceptable: és qui etiqueta el [golden set](#el-conjunt-de-referència-golden-set) i contra qui es calibra el jutge automàtic. Repartir aquesta autoritat entre diversos anotadors introdueix desacords sobre on cau el llindar i acaba en paràlisi; només es justifica quan el domini ho exigeix (per exemple, contextos multilingües o multijurisdiccionals). Aquesta persona no cal que ho etiqueti tot, una mostra representativa n'hi ha prou, però el criteri ha de ser seu.

## Biaixos i fiabilitat del LLM-as-judge

El LLM-as-judge és un avaluador potent, però introdueix biaixos sistemàtics que cal conèixer per no confiar-hi cegament.