@@ -139,7 +139,9 @@ Si el jutge no és fiable per a un criteri concret, cal redissenyar el prompt de
## No-determinisme: pass@k i pass^k
Com que el model pot donar respostes diferents per a la mateixa entrada, cal executar cada tasca múltiples vegades (*trials*) i agregar els resultats. Hi ha dues mètriques complementàries. **pass@k** és estàndard en benchmarks de codi (HumanEval, SWE-bench); **pass^k** és una extensió menys universal — útil com a eina conceptual per raonar sobre fiabilitat en producció, però no sempre trobada amb aquesta notació a la literatura:
Com que el model pot donar respostes diferents per a la mateixa entrada, cal executar cada tasca múltiples vegades (*trials*) i agregar els resultats. Hi ha dues mètriques complementàries. **pass@k** és estàndard en benchmarks de codi (HumanEval, SWE-bench); **pass^k** és una extensió menys universal — útil com a eina conceptual per raonar sobre fiabilitat en producció, però no sempre trobada amb aquesta notació a la literatura.
Imagina una tasca que el sistema supera 9 de cada 10 execucions. Si l'executes 10 vegades, gairebé segur que *alguna* passa (pass@10 ≈ 1,0), però que passin *totes deu* és tota una altra cosa: 0,9¹⁰ ≈ 0,35. El mateix sistema sembla excel·lent amb una mètrica i mediocre amb l'altra:
-**pass@k**: la probabilitat que *almenys un* dels *k* trials superi l'eval. Mesura el *potencial* del sistema — *pot* resoldre la tasca?
-**pass^k**: la probabilitat que *tots* els *k* trials la superin. Mesura la *fiabilitat* en producció — *sempre* la resol?
@@ -171,6 +172,6 @@ La columna "primera opció" reflecteix models que cobreixen les capacitats crít
**Regla general**: comença amb el model mig del proveïdor actual — bon equilibri cost/qualitat per a la majoria de casos. Escala al model gran si els evals mostren insuficiència en raonament. Mou a model local si la privacitat o el cost en producció ho requereix, i verifica les capacitats crítiques amb evals pròpies.
**Models de referència actuals (2026):** a tall d'il·lustració — Claude Sonnet 4.6 i GPT-5 com a models mitjos de referència; Claude Opus 4.7 i GPT-5 (amb raonament estès) com a models grans; Llama 4 i Mistral Large com a opcions locals. La matriu de verificació de la secció anterior és l'eina per avaluar nous models quan apareguin.
**Models de referència actuals (2026):** a tall d'il·lustració — Claude Sonnet 4.6 i GPT-5 com a models mitjos de referència; Claude Opus 4.8 i GPT-5 (amb raonament estès) com a models grans, i Claude Fable 5 com a model frontier per a les tasques més exigents; Llama 4 i Mistral Large com a opcions locals. La matriu de verificació de la secció anterior és l'eina per avaluar nous models quan apareguin.
> 📝 Per als patrons de prompting, sortida estructurada i tool use, consulta [Prompts i integració](llm_systems.md). Per als requisits de maquinari dels models locals i les opcions de desplegament, consulta [Arquitectura de sistemes LLM](llm_architecture.md).
@@ -11,9 +11,9 @@ El document s'estructura en dos blocs:
## Prompts i comportament
El terme *prompt* ha quedat petit per descriure el que realment rep un model en una crida real. En un sistema LLM, el model veu simultàniament les instruccions del sistema, el context recuperat del corpus, l'historial de la conversa, els resultats de les eines cridades fins ara, l'estat de la memòria persistent si n'hi ha, i les restriccions de format de sortida. Tot això, al mateix temps, en el mateix context. **Context engineering** és el terme emergent per a la disciplina de composar i gestionar aquest paquet complet de manera que el model pugui fer la feina correctament.
Mira què rep realment el model en una crida d'un assistent de suport: el system prompt amb les regles, tres fragments recuperats de la base de coneixement, els quatre torns anteriors de la conversa, i el resultat de l'eina `consultar_comanda` que s'ha cridat fa un torn. Tot junt, al mateix context, cada vegada. El *prompt* ja no és una frase: és aquest paquet, i sol créixer a cada interacció. Compondre'l i mantenir-lo net és el que s'anomena **context engineering**.
Les seccions que segueixen construeixen sobre aquesta idea: les instruccions del sistema, els exemples com a especificació i les tècniques de raonament configuren com el model rep les tasques. La composició del context complet (sortida estructurada, gestió de la memòria, integració de resultats d'eines) es tracta a [Integració i execució](#integració-i-execucio). Entendre cada peça per separat és necessari; construir sistemes robustos requereix entendre com interactuen.
Les peces que el formen es tracten per separat en aquest document: les instruccions del sistema, els exemples com a especificació i les tècniques de raonament (en aquest bloc), i la composició del context complet (sortida estructurada, gestió de la memòria, integració de resultats d'eines) a [Integració i execució](#integració-i-execucio). Entendre cada peça per separat és necessari; construir sistemes robustos requereix entendre com interactuen.
### Fine-tuning vs. prompting
@@ -35,7 +35,7 @@ Un prompt no és una instrucció informal adreçada a un assistent — és la **
Els models de l'API de chat reben una seqüència de missatges amb rols diferenciats (format introduït pel Chat Completions API d'OpenAI el març de 2023 i adoptat amb variacions per Anthropic, Google, Mistral i altres proveïdors):
-**`system`**: instruccions del desenvolupador. Defineix el rol, el context i les restriccions del model per a tota la conversa. Sempre és el primer missatge i apareix una sola vegada — no es repeteix a l'historial. L'usuari no el veu ni el pot modificar. Cada context o desplegament pot tenir un system prompt diferent. Els proveïdors principals usen terminologia pròpia per a aquest rol: OpenAI el nomena *developer message* o *developer instructions*; Anthropic parla d'*instruccions de prioritat*. La semàntica és la mateixa. Els models de raonament (o1/o3, DeepSeek-R1, Gemini Thinking) apliquen regles pròpies per al system prompt — vegeu [Models de raonament i prompting](#models-de-raonament-i-prompting).
-**`system`**: instruccions del desenvolupador. Defineix el rol, el context i les restriccions del model per a tota la conversa. Sempre és el primer missatge i apareix una sola vegada — no es repeteix a l'historial. L'usuari no el veu ni el pot modificar. Cada context o desplegament pot tenir un system prompt diferent. Els proveïdors principals usen terminologia pròpia per a aquest rol: OpenAI el nomena *developer message* o *developer instructions*; Anthropic parla d'*instruccions de prioritat*. La semàntica és la mateixa. Els models de raonament (GPT-5, DeepSeek-R1, Gemini Thinking) apliquen regles pròpies per al system prompt — vegeu [Models de raonament i prompting](#models-de-raonament-i-prompting).
-**`user`**: entrada de l'usuari o del sistema que genera la petició.
-**`assistant`**: resposta del model. En una conversa multi-torn, l'historial de missatges anteriors es passa explícitament a cada crida.
@@ -104,7 +104,7 @@ El zero-shot és suficient quan la sortida és inequívoca (classificar com a po
### Chain-of-thought per a models estàndard
> ⚠️ **Aquesta tècnica és per a models estàndard.** Els models de raonament (o1/o3, DeepSeek-R1, Gemini Thinking) generen el raonament internament sense que cal demanar-ho — afegir-hi instruccions CoT no millora el resultat i pot empitjorar-lo. Vegeu [Models de raonament i prompting](#models-de-raonament-i-prompting).
> ⚠️ **Aquesta tècnica és per a models estàndard.** Els models de raonament (GPT-5, DeepSeek-R1, Gemini Thinking) generen el raonament internament sense que cal demanar-ho — afegir-hi instruccions CoT no millora el resultat i pot empitjorar-lo. Vegeu [Models de raonament i prompting](#models-de-raonament-i-prompting).
La tècnica *chain-of-thought* (CoT) demana al model que raoni explícitament pas a pas abans de donar la resposta final. En lloc de produir directament l'answer, el model genera una cadena de raonament intermèdia que millora la qualitat en tasques que requereixen múltiples passos: matemàtiques, lògica, planificació, diagnosi.
Els models de raonament (o1/o3 d'OpenAI, DeepSeek-R1, Gemini Thinking, Claude amb *extended thinking*) representen una família diferent que no es pot tractar com un model estàndard de chat. La diferència fonamental: el model genera una cadena de pensament interna (*scratchpad*) abans de produir la resposta, consumint tokens d'entrada i sortida addicionals que no arriben a l'usuari. El raonament no és visible per defecte; alguns proveïdors l'exposen com a camp opcional per a monitoratge i depuració, però no és pensament per a l'usuari final.
Els models de raonament (la família GPT-5 d'OpenAI, DeepSeek-R1, Gemini Thinking, Claude amb raonament adaptatiu) representen una família diferent que no es pot tractar com un model estàndard de chat. La diferència fonamental: el model genera una cadena de pensament interna (*scratchpad*) abans de produir la resposta, consumint tokens d'entrada i sortida addicionals que no arriben a l'usuari. El raonament no és visible per defecte; alguns proveïdors l'exposen com a camp opcional per a monitoratge i depuració, però no és pensament per a l'usuari final.
**Regles de prompting per a models de raonament:**
@@ -218,7 +218,7 @@ Aquesta diferència és invisible quan s'usen abstraccions com LangChain o LiteL
### APIs i portabilitat
El format de Chat Completions continua sent el millor punt d'interoperabilitat entre proveïdors. OpenAI va introduir la **Responses API** (2025) com a interfície més moderna per a builds agentics: converses amb estat gestionat al servidor, eines integrades (cerca web, execució de codi) i un bucle d'execució d'agents natiu; l'Assistants API va quedar deprecada el 2026. La resta de proveïdors mantenen el format de Chat Completions i no han adoptat la Responses API.
El format de Chat Completions continua sent el millor punt d'interoperabilitat entre proveïdors. OpenAI va introduir la **Responses API** (2025) com a interfície més moderna per a builds agentics: converses amb estat gestionat al servidor, eines integrades (cerca web, execució de codi) i un bucle d'execució d'agents natiu; l'antiga Assistants API va quedar deprecada a principis de 2026. La resta de proveïdors mantenen el format de Chat Completions i no han adoptat la Responses API.
> ⚠️ **Tradeoff de la Responses API**: la Responses API és específica d'OpenAI — cap altre proveïdor la implementa de forma nativa. La gestió d'estat al servidor, que és el seu avantatge principal, també crea dependència del proveïdor: una aplicació que delega l'historial de conversa al servidor d'OpenAI no pot canviar de proveïdor sense reescriure la integració. LiteLLM ofereix un pont de compatibilitat (`litellm.responses()`), però les funcions avançades (estat persistent, eines natives) continuen requerint el SDK d'OpenAI. Si la portabilitat és un requisit present o futur, Chat Completions és la base més prudent; si el focus és construir sobre l'ecosistema d'OpenAI, Responses és la via recomanada.
@@ -491,7 +491,7 @@ Sense control, `messages` creix il·limitadament, i això genera dos problemes d
El primer és el **límit dur de la finestra de context**: quan els tokens acumulats superen el màxim del model, la crida falla.
El segon, més subtil, és el **context rot**: la degradació gradual de la qualitat de la resposta a mesura que la conversa acumula historial, instruccions estancades, resultats d'eines, intents fallits i context irrellevant. Apareix molt abans d'arribar al límit dur. Els símptomes són observables: el model ignora restriccions prèviament declarades, repeteix solucions que ja s'havien rebutjat, requereix que se li recordin instruccions, perd precisió en la sortida, o trenca cadenes de raonament multi-pas que abans seguia correctament. Un fenomen relacionat és el *lost in the middle*: els models presten menys atenció a la informació situada al mig de finestres llargues que a la del principi o el final, així que el context rellevant enterrat enmig de soroll efectivament desapareix encara que tècnicament hi sigui.
El segon, més subtil: deu torns enrere vas dir al model que respongués sempre en català i ara torna a contestar en castellà; li recordes una restricció que ja havies declarat i la torna a oblidar; reprèn una solució que la conversa ja havia descartat. Això és el **context rot**: la degradació gradual de la qualitat a mesura que la conversa acumula historial, instruccions estancades, resultats d'eines, intents fallits i context irrellevant. Apareix molt abans d'arribar al límit dur, i els símptomes són observables: el model ignora restriccions prèviament declarades, perd precisió en la sortida, o trenca cadenes de raonament multi-pas que abans seguia correctament. Un fenomen relacionat és el *lost in the middle*: els models presten menys atenció a la informació situada al mig de finestres llargues que a la del principi o el final, així que el context rellevant enterrat enmig de soroll efectivament desapareix encara que tècnicament hi sigui.
La conseqüència de disseny és que les estratègies següents no són només per evitar errors de límit, sinó per mantenir la qualitat de la resposta: cada token irrellevant a l'historial té un cost de senyal, no només de memòria.
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?"**
Apartir de 2024-2025, una nova categoria ha guanyat rellevància: els **models de raonament** (*reasoning models*). A diferència dels models estàndard, que generen directament la resposta final, aquests models produeixen primer una **cadena de pensament interna** — un esborrany extens de raonament pas a pas que el model usa per arribar a la resposta però que habitualment no es mostra a l'usuari.
Apareguts cap a 2024-2025, els **models de raonament** (*reasoning models*) s'han consolidat com una de les categories principals. A diferència dels models estàndard, que generen directament la resposta final, aquests models produeixen primer una **cadena de pensament interna** — un esborrany extens de raonament pas a pas que el model usa per arribar a la resposta però que habitualment no es mostra a l'usuari.
El referent OSS és **DeepSeek-R1** (pesos públics sota Apache 2.0), entrenat amb *GRPO* — una variant de reinforcement learning sense supervisió humana directa — que va assolir resultats comparables als millors models comercials en benchmarks de raonament matemàtic i de codi. **QwQ-32B** de Qwen és una altra opció de pesos oberts que pot córrer en hardware accessible. Tots dos es poden desplegar amb vLLM o Ollama com qualsevol altre model. En l'àmbit comercial, models com o1/o3 (OpenAI) o el mode *extended thinking* de Claude segueixen el mateix paradigma però sense accés als pesos.
El referent OSS és **DeepSeek-R1** (pesos públics sota Apache 2.0), entrenat amb *GRPO* — una variant de reinforcement learning sense supervisió humana directa — que va assolir resultats comparables als millors models comercials en benchmarks de raonament matemàtic i de codi. **QwQ-32B** de Qwen és una altra opció de pesos oberts que pot córrer en hardware accessible. Tots dos es poden desplegar amb vLLM o Ollama com qualsevol altre model. En l'àmbit comercial, la família GPT-5 (OpenAI), Gemini Thinking (Google) o el raonament adaptatiu de Claude segueixen el mateix paradigma però sense accés als pesos.
La idea subjacent a tots és la mateixa: dedicar còmput addicional a l'hora de la inferència (*test-time compute*) en lloc de requerir-lo tot durant l'entrenament.
@@ -418,6 +418,6 @@ DPO ha guanyat popularitat per la seva simplicitat, i variants com **IPO** o **K
Els LLMs moderns han evolucionat significativament més enllà del processament de text pur.
**Models multimodals:** arquitectures com GPT-4o, Claude o Gemini poden processar **text, imatges, àudio i vídeo** dins del mateix model. L'enfocament més comú és afegir *encoders* específics per a cada modalitat (p.ex. un Vision Transformer que divideix la imatge en *patches* i els tracta com a "tokens" visuals) que converteixen l'entrada en representacions vectorials compatibles amb el transformer de text, tot i que les arquitectures concretes varien força (encoders externs, adaptadors, fusió tardana...). Això permet tasques com descriure imatges, analitzar gràfics, o respondre preguntes sobre documents amb figures.
**Models multimodals:** arquitectures com GPT-5, Claude o Gemini poden processar **text, imatges, àudio i vídeo** dins del mateix model. L'enfocament més comú és afegir *encoders* específics per a cada modalitat (p.ex. un Vision Transformer que divideix la imatge en *patches* i els tracta com a "tokens" visuals) que converteixen l'entrada en representacions vectorials compatibles amb el transformer de text, tot i que les arquitectures concretes varien força (encoders externs, adaptadors, fusió tardana...). Això permet tasques com descriure imatges, analitzar gràfics, o respondre preguntes sobre documents amb figures.
**Ús d'eines (*tool use* / *function calling*):** una capacitat clau dels LLMs actuals és poder **invocar eines externes** — calculadores, APIs, bases de dades, intèrprets de codi — quan la tasca ho requereix. En lloc de respondre directament, el model genera una crida estructurada (p.ex. en JSON) que el sistema executa i retorna el resultat al model. Això compensa limitacions inherents dels LLMs (càlcul exacte, informació en temps real) i és la base dels **agents d'IA**, sistemes que combinen LLMs amb eines per resoldre tasques complexes de forma autònoma.
