A la lliçó anterior vam tractar l'LLM com una caixa negra que rep text i retorna text. En aquesta lliçó obrirem aquesta caixa just el que cal perquè hi puguis treballar de manera eficaç. No necessites dominar el càlcul matricial que passa dins d'un transformer, de la mateixa manera que no necessites conèixer els arbres B+ per fer servir PostgreSQL; però sí que necessites entendre els tokens (perquè determinen límits i costos de cada crida), els embeddings (perquè són la base de la cerca semàntica que farà servir DocuBot), la idea d'atenció (perquè explica per què el model gestiona bé el context) i el fet que tot es redueix a predir el token següent (perquè explica tant les capacitats com les fallades del model). Aquesta visió pràctica et permetrà raonar sobre el comportament del model en lloc de tractar-lo com a màgia.

1. La idea central: predir el token següent
2. Tokenització: com veu el text un LLM
3. Embeddings: representar el significat amb números
4. L'arquitectura transformer i el mecanisme d'atenció
5. De la predicció a la resposta: mostreig, temperature i top_p
6. Com s'entrena un LLM: pre-entrenament, fine-tuning i RLHF

Encara que sembli sorprenent, tot el que fa un LLM es redueix a una única operació repetida moltes vegades:

Donat un text d'entrada, calcular quin fragment de text (token) és més probable que vingui a continuació.

Quan preguntes a DocuBot "Què és Nubelia?", el model no busca la resposta en una base de dades ni executa un raonament simbòlic. Genera la resposta token a token: prediu el primer token de la resposta, l'afegeix al text, prediu el següent tenint en compte tot l'anterior, i així successivament fins que prediu un token especial de "fi".

En pseudocodi:

Fixa't en dues conseqüències directes d'aquest disseny, que reapareixeran durant tot el curs:

• El model sempre genera alguna cosa. No hi ha cap mecanisme intern de "no ho sé"; si el text més probable a continuació d'una pregunta és una resposta amb aparença de certa, això és el que produeix, sigui veritat o no. Aquí hi ha la llavor de les al·lucinacions que analitzarem a la lliçó 01-04.
• El text d'entrada ho és tot. L'única manera d'influir en la predicció és canviar el que el model rep. Per això el prompting (mòdul 2) i la gestió del context (mòduls 3 i 4) són tan importants.

Que un mecanisme tan simple produeixi traduccions, codi funcional o raonaments es deu a l'escala: per predir bé el token següent de qualsevol text, el model es veu obligat a aprendre gramàtica, fets, estils i patrons de raonament presents a les seves dades d'entrenament.

Hem dit "token" unes quantes vegades. Definim-lo bé, perquè és el concepte més pràctic de tota la lliçó.

Un LLM no processa caràcters ni paraules: processa tokens, fragments de text de longitud variable que surten de trossejar l'entrada amb un diccionari fix (el vocabulari, típicament de 50.000 a 200.000 tokens). El procés de trossejar el text s'anomena tokenització, i el duu a terme un component determinista anomenat tokenitzador abans que el text arribi a la xarxa neuronal.

• Les paraules freqüents solen ser un únic token: " the", " de", " project".
• Les paraules rares o llargues es parteixen en diversos: "Nubelia" es podria tokenitzar com ["Nub", "elia"].
• Els espais i els signes de puntuació formen part dels tokens (sovint l'espai inicial va enganxat a la paraula).
• El codi també es tokenitza: def, parèntesis, indentació... tot consumeix tokens.

Un exemple il·lustratiu (els talls exactes depenen de cada tokenitzador):

Com a regla mental ràpida per estimar: en anglès, 1 token ≈ 4 caràcters ≈ 0,75 paraules. En català o castellà la proporció sol ser una mica pitjor (més tokens per paraula), perquè els vocabularis de la majoria de models es van construir amb predomini de text en anglès.

Un exemple clàssic: si un model falla en comptar les lletres "r" d'una paraula, no és perquè "no sàpiga comptar"; és perquè mai no veu les lletres individuals — veu un o dos tokens opacs que representen la paraula sencera.

Per a DocuBot això té una conseqüència directa que reprendrem al mòdul 4: la documentació de Nubelia ocupa moltíssims més tokens dels que caben en una crida, així que no podrem "passar-li tota la wiki" al model; caldrà seleccionar els fragments rellevants per a cada pregunta.

Una xarxa neuronal només opera amb números, així que el primer pas després de tokenitzar és convertir cada token en un vector: una llista de centenars o milers de números decimals. Aquest vector és l'embedding del token.

El que és fascinant dels embeddings és que no són codis arbitraris: capturen significat. Durant l'entrenament, el model aprèn a col·locar en posicions properes de l'espai vectorial els tokens (i, per extensió, les frases) que apareixen en contextos similars. El resultat és una mena de "mapa del significat":

La "proximitat" es mesura amb operacions geomètriques senzilles (com la similitud cosinus, l'angle entre dos vectors). I el concepte escala més enllà de tokens solts: hi ha models especialitzats que produeixen l'embedding d'una frase o d'un document sencer, de manera que "com reinicio el servei d'informes?" i "reinici del mòdul de reporting" acaben amb vectors molt pròxims encara que no comparteixin gairebé cap paraula.

Veus cap on apunta això per a DocuBot? Si podem convertir cada fragment de la documentació de Nubelia en un vector, i també la pregunta de l'usuari, aleshores trobar la documentació rellevant es converteix en buscar els vectors més propers. Això és la cerca semàntica, la peça central de RAG, i la desenvoluparem a la lliçó 04-01. Per ara, queda't amb la idea: embedding = significat convertit en coordenades.

Dins del mateix LLM, els embeddings dels tokens d'entrada són el punt de partida: la primera capa de la xarxa els pren i, capa a capa, els va refinant amb la informació del seu context. El que fa aquest refinament és, precisament, l'atenció.

Com vam veure a la lliçó anterior, l'arquitectura transformer (2017) és la fita que va fer possibles els LLMs. La seva innovació central és el mecanisme d'atenció (attention). Vegem-lo conceptualment, sense matemàtiques.

El problema que resol: el significat d'una paraula depèn del seu context, i aquest context pot ser lluny. Observa:

"L'equip de suport va revisar el banc de proves abans del desplegament." "Es va asseure al banc del parc a llegir la documentació."

Per representar bé "banc", el model necessita mirar altres paraules de la frase — i decidir quines importen. Això és exactament l'atenció: un mecanisme pel qual cada token calcula quanta importància ha de donar a cadascun dels altres tokens del context, i actualitza la seva representació (el seu embedding) barrejant informació dels tokens rellevants.

Una analogia útil per a desenvolupadors: l'atenció funciona com una consulta ponderada. Cada token llança una "query" a la resta de tokens ("qui de vosaltres és rellevant per a mi?"), cada token respon amb el que ofereix, i el resultat és una mitjana ponderada on els tokens rellevants pesen més.

Sobre aquesta idea, l'arquitectura completa s'organitza així:

• Un transformer apila desenes de capes, cadascuna amb múltiples "caps" d'atenció en paral·lel (cada cap aprèn a fixar-se en tipus diferents de relacions: sintaxi, correferències, patrons de codi...), alternades amb petites xarxes neuronals que transformen cada posició.
• Capa rere capa, la representació de cada token s'enriqueix amb més i més context: de "quin token soc" a "què signifiquem exactament en aquesta frase, aquest paràgraf i aquest document".
• A la sortida de l'última capa, la representació de l'últim token es fa servir per calcular la probabilitat de cada possible token següent — i tornem a la idea central de la lliçó.

Dos avantatges del transformer que expliquen el seu èxit davant les xarxes recurrents anteriors:

1. Paral·lelisme: l'atenció processa tots els tokens alhora (no l'un rere l'altre), cosa que permet entrenar amb volums de dades gegantins.
2. Abast: qualsevol token pot atendre directament qualsevol altre, per lluny que sigui, així que les dependències a llarga distància no es "dilueixen".

Els famosos paràmetres d'un model (quan es parla de models "de milers de milions de paràmetres") són justament els números apresos que governen aquestes capes: els pesos de l'atenció i de les transformacions. Més paràmetres sol significar més capacitat de capturar patrons — i més cost d'execució.

Amb això tens el nivell de detall adequat: suficient per raonar sobre el model, sense perdre't en la mecànica interna.

El model produeix una distribució de probabilitat sobre el token següent. Però quin es tria? Aquí entra el mostreig (sampling), i amb ell els dos paràmetres que veuràs a totes les APIs de LLMs: temperature i top_p.

L'opció més òbvia seria triar sempre el token més probable (mostreig greedy). Funciona, però produeix text repetitiu i predictible, i davant preguntes creatives dona sempre la mateixa sortida. Per això, a la pràctica es tria el token a l'atzar, ponderat per la seva probabilitat — i els paràmetres de mostreig controlen quant atzar.

• temperature (típicament entre 0 i 1, de vegades fins a 2): reescala la distribució de probabilitats.
  • A prop de 0: accentua les diferències — els tokens probables esdevenen gairebé segurs. Sortides més deterministes, conservadores i repetibles.
  • A prop d'1: respecta la distribució original — més varietat i "creativitat", però també més risc de desviacions.
• top_p (mostreig nucleus): en lloc de considerar tots els tokens, considera només el conjunt més petit de tokens la probabilitat acumulada dels quals arriba a p (per exemple, 0.9), i mostreja només entre ells. És una retallada de la "cua" de tokens improbables.

Guia pràctica inicial (l'afinarem quan integrem l'API al mòdul 3):

Un avís important que reprendrem a la lliçó 01-04: ni tan sols amb temperature = 0 la sortida està garantida al 100% idèntica entre crides. Tracta els LLMs com a components no deterministes per disseny.

Última peça del trencaclosques: com arriba el model a predir tan bé? L'entrenament d'un LLM modern té tres fases principals. No entrenaràs cap model en aquest curs, però conèixer les fases explica comportaments que veuràs cada dia.

El model s'entrena amb quantitats enormes de text (webs, llibres, codi públic...) en una tasca única: predir el token següent. Bilions de tokens, setmanes o mesos de còmput en milers de GPUs. D'aquí surt el coneixement general del model: idiomes, fets, estils, llenguatges de programació.

Dues conseqüències pràctiques:

• El coneixement del model queda congelat en la data de les seves dades (el knowledge cutoff o tall de coneixement, que analitzarem a la lliçó 01-04).
• El model només sap el que hi havia en aquestes dades. La wiki interna de Nubelia, òbviament, no hi era.

El resultat d'aquesta fase (el model base) és un completador de text molt potent, però no un assistent: si li escrius una pregunta, pot perfectament continuar-la amb més preguntes semblants, perquè això és un text estadísticament plausible.

Per convertir el completador en assistent, es reentrena el model amb un dataset molt més petit i acurat d'exemples de converses: instrucció de l'usuari → resposta desitjada. El model aprèn el format de comportar-se com un assistent: respondre al que es pregunta, seguir instruccions, mantenir un diàleg.

Per acabar, s'afina la qualitat i l'estil de les respostes: persones avaluen i comparen respostes del model ("aquesta és millor que aquesta altra"), amb aquestes preferències s'entrena un model de recompensa, i l'LLM s'ajusta mitjançant aprenentatge per reforç per produir respostes més ben valorades: més útils, més segures, més ben explicades.

Una conseqüència subtil de l'RLHF que convé conèixer: en optimitzar per a respostes que "agraden", els models desenvolupen una certa tendència a sonar segurs i complaents, fins i tot quan no ho haurien de fer. Una altra peça més del trencaclosques de les al·lucinacions que muntarem a la lliçó 01-04.

• Confondre paraules amb tokens. Els límits i preus dels models s'expressen en tokens. Si estimes "aquest document té 2.000 paraules, hi caben de sobres", et pots endur una sorpresa: en català poden ser fàcilment 3.000–4.000 tokens. Fes servir sempre el tokenitzador (o el comptador de tokens) del model concret per estimar.
• Creure que el model "consulta" informació en respondre. Un LLM pur no busca en cap base de dades en temps de resposta: genera a partir dels seus paràmetres i del text que li has passat. Si necessites dades actuals o privades, les hi hauràs de posar tu al context (mòduls 3 i 4).
• Atribuir a "manca d'intel·ligència" errors que són de tokenització. Comptar lletres, invertir cadenes o operar amb números molt llargs són tasques on la representació en tokens juga en contra del model. Per a aquestes tasques, fes servir codi, no un LLM.
• Apujar la temperature per "millorar" respostes factuals. És a l'inrevés: per a tasques tipus DocuBot (respostes basades en documentació) vols una temperature baixa. La temperature alta és per a tasques on la varietat aporta valor.
• Esperar determinisme absolut. Dissenya la teva aplicació assumint que dues crides idèntiques poden retornar textos diferents. Valida les sortides en lloc de comparar-les amb una cadena exacta (això serà clau en testejar, al mòdul 6).
• Consell: quan el comportament d'un model et desconcerti, repassa mentalment el pipeline d'aquesta lliçó — quins tokens està veient? què hi havia al seu context? quin text seria estadísticament plausible a continuació? — i la majoria de "misteris" es dissolen.

L'equip de Nubelia vol passar a DocuBot, a cada crida, un fragment de documentació d'unes 1.200 paraules en català juntament amb la pregunta de l'usuari (unes 30 paraules). Fent servir la regla orientativa que en català 1 paraula ≈ 1,5 tokens:

1. Estima quants tokens d'entrada tindrà cada crida (ignora instruccions addicionals).
2. Si el model triat tingués una finestra de context de 8.000 tokens, quin percentatge de la finestra consumiria l'entrada?
3. Per què aquesta estimació és només orientativa i què faries per obtenir la xifra real?

Per a cadascun d'aquests tres usos de l'LLM a Nubelia, indica si faries servir una temperature baixa (≈0–0.3), mitjana (≈0.5–0.7) o alta (≈0.8–1.0), i justifica-ho:

1. DocuBot responent "quins ports fa servir el servei d'informes?" a partir d'un fragment de documentació.
2. Generar 10 propostes variades de nom per a una nova funcionalitat de la plataforma.
3. Resumir en un paràgraf les notes d'una reunió tècnica.

Un company et pregunta: "Per què diuen que l'atenció va ser la clau dels LLMs? Què fa exactament?". Escriu una explicació de 4–6 línies, sense matemàtiques, fent servir la frase "El banc de proves va fallar" davant de "Es va asseure al banc" com a exemple.

Solució 1:

1. Document: 1.200 × 1,5 = 1.800 tokens. Pregunta: 30 × 1,5 = 45 tokens. Total ≈ 1.845 tokens d'entrada.
2. 1.845 / 8.000 ≈ 23% de la finestra. Queda marge, però recorda que la finestra també ha d'allotjar les instruccions del sistema, l'historial de conversa i la resposta generada.
3. És orientativa perquè la proporció paraules/tokens depèn del tokenitzador de cada model i del tipus de text (el text tècnic amb noms propis com "Nubelia" o identificadors de codi sol fragmentar-se en més tokens). Per a la xifra real, tokenitzaria el text amb l'eina o l'endpoint de recompte de tokens del model concret.

Solució 2:

1. Baixa. És una resposta factual basada en documentació: volem precisió i consistència; la creativitat aquí és un defecte.
2. Alta. L'objectiu és varietat: amb temperature baixa les 10 propostes s'assemblarien massa entre elles (i entre execucions).
3. Baixa o mitjana-baixa. Un resum ha de ser fidel al contingut; una mica de flexibilitat de redacció és acceptable, però no volem que "adorni" o introdueixi idees que no eren a les notes.

Solució 3 (exemple de resposta):

"Abans dels transformers, els models processaven el text paraula a paraula i els costava relacionar paraules llunyanes. L'atenció permet que, en processar cada paraula, el model miri totes les altres paraules del text i decideixi quines són rellevants per interpretar-la. Per exemple, 'banc' no significa res de concret per si sol: a 'el banc de proves va fallar', l'atenció dona pes a 'proves' i 'va fallar' i el model l'interpreta com a infraestructura tècnica; a 'es va asseure al banc', el pes va a 'asseure' i l'interpreta com a mobiliari. Com que a més això es calcula per a totes les paraules en paral·lel, es va poder entrenar amb volums de dades enormes — i d'aquesta escala en van sortir els LLMs."

Ja saps què hi ha dins de la caixa: un LLM tokenitza el text (i per això els límits i els costos es mesuren en tokens), representa cada token com un embedding que captura significat (idea que serà la base de la cerca semàntica de DocuBot al mòdul 4), refina aquestes representacions amb capes d'atenció que decideixen quines parts del context importen, i amb tot això prediu el token següent, un cop i un altre, amb un grau d'atzar controlat per temperature i top_p. També coneixes les tres fases d'entrenament — pre-entrenament, fine-tuning i RLHF — i les seves conseqüències: coneixement ampli però congelat en el temps, comportament d'assistent, i una certa tendència a sonar més segur del que hauria de sonar.

Amb aquest model mental ja pots avaluar críticament el que ofereix el mercat. A la lliçó següent, "Panorama de models i proveïdors", veurem quines famílies de models existeixen, quins criteris fer servir per comparar-los (capacitat, context, cost, latència, modalitats) i com decidir entre models propietaris via API i models oberts autoallotjats — decisions que Nubelia haurà de prendre abans d'escriure la primera línia de DocuBot.