Fins ara hem vist el que la IA generativa pot fer i com avaluar els models disponibles. Aquesta lliçó completa el mòdul amb la part que cap desenvolupador professional no es pot saltar: el que pot sortir malament. Els LLMs inventen informació amb total seguretat, tenen una memòria de treball limitada, ignoren tot el que és posterior al seu entrenament, no responen dues vegades igual, arrosseguen biaixos i costen diners a cada crida. Res d'això no els fa inservibles — però cada limitació ha d'influir en el disseny de la teva aplicació des del primer dia. Farem servir DocuBot i Nubelia com a banc de proves mental per a cada risc: entendre'ls ara és el que ens permetrà, als mòduls següents, construir les mitigacions amb coneixement de causa.

1. Al·lucinacions: quan el model inventa amb seguretat
2. La finestra de context i les seves implicacions
3. El tall de coneixement (knowledge cutoff)
4. No determinisme: el mateix prompt, respostes diferents
5. Biaixos en les dades i en les respostes
6. Costos i consum com a restricció de disseny
7. Privadesa: què passa amb les dades que envies

Una al·lucinació és una resposta falsa o inventada que el model presenta amb la mateixa fluïdesa i aparent seguretat que una resposta correcta. És la limitació més important dels LLMs i la primera que has d'interioritzar.

Recorda el mecanisme de la lliçó 01-02: un LLM genera el text estadísticament més plausible a continuació del que ha rebut. Enlloc d'aquest procés no hi ha cap verificació de fets. S'hi combinen tres factors:

1. El model optimitza plausibilitat, no veritat. Una xifra inventada però raonable és un text perfectament plausible.
2. No té un mecanisme intern fiable de "no ho sé". Davant una pregunta el contingut de la qual no és a les seves dades, la continuació més plausible continua sent una resposta, no un silenci.
3. L'entrenament amb feedback humà (RLHF) premia respostes que sonen útils i segures, cosa que pot accentuar la tendència a respondre amb confiança en lloc d'admetre ignorància.

Imagina el DocuBot "ingenu" de la lliçó 01-01: un LLM genèric connectat al xat de Nubelia, sense accés a la documentació. Exemples del tipus de diàleg que hi veuríem (ficticis, és clar, com tot el de Nubelia):

Resposta fluida, concreta, amb rutes de menú... i completament inventada. El model no sap res de Nubelia; ha generat el que sol ser veritat en productes SaaS semblants. Potser Nubelia exporta a PDF, potser no — el model no ho sap, però respon com si ho sabés. Encara pitjor:

Un endpoint amb un aspecte impecable... d'una funcionalitat que potser no existeix. Un desenvolupador confiat perdria una hora abans de descobrir l'engany. Aquest és el patró perillós: les al·lucinacions són més convincents com més plausible és el domini.

És important entendre que les al·lucinacions no es limiten a dades privades: els models també inventen sobre coneixement públic (cites, funcions de llibreries, referències bibliogràfiques), especialment en els detalls fins i en temes poc representats a les seves dades.

No existeix (avui) cap solució que elimini les al·lucinacions del tot, però sí un conjunt de mitigacions que les redueixen dràsticament. Les presentem ara i les construirem durant el curs:

Fixa't que la primera mitigació és exactament la raó de ser de RAG: la diferència entre el DocuBot ingenu i el DocuBot final del curs serà que el segon respon amb la documentació real de Nubelia al davant — i citant-la.

La finestra de context és la quantitat màxima de tokens que el model pot gestionar en una crida: instruccions + historial + documents + la mateixa resposta generada, tot suma. És, literalment, tot el que el model "veu" en respondre; fora d'ella, no existeix res.

Implicacions de disseny:

• No pots passar-ho tot. La documentació completa de Nubelia excedeix qualsevol finestra raonable (i encara que hi cabés, pagaries tots aquests tokens a cada crida). Cal seleccionar què hi entra: és el problema que resol la recuperació de RAG (mòdul 4).
• Les converses no hi caben per sempre. En un xat, cada torn s'acumula. Tard o d'hora cal truncar, resumir o descartar historial — les estratègies es veuen a la lliçó 03-03.
• El model no "recorda" entre crides. No hi ha memòria persistent: si vols que DocuBot recordi la conversa, la teva aplicació ha de reenviar l'historial a cada crida. La "memòria" d'un chatbot és enginyeria teva, no una capacitat del model.
• Finestra gran ≠ atenció perfecta. Amb contextos molt llargs, els models poden aprofitar pitjor la informació situada al mig del text (fenomen conegut com a lost in the middle). Més context també implica més cost i latència. La qualitat del que poses al context importa més que la quantitat.

Com vam veure a la lliçó 01-02, el coneixement del model procedeix del seu pre-entrenament i queda congelat en una data: el knowledge cutoff o tall de coneixement. Tot el que és posterior — versions noves de llibreries, esdeveniments, canvis d'APIs públiques — simplement no hi és.

Conseqüències pràctiques:

• Preguntes sobre "l'últim" de qualsevol tecnologia poden rebre respostes desactualitzades sense cap senyal d'avís: el model descriu amb seguretat la versió antiga.
• Combinat amb les al·lucinacions, és traïdor: preguntat per alguna cosa posterior al seu tall, el model pot barrejar el que sabia amb extrapolacions inventades.
• Per a DocuBot hi ha un matís essencial: fins i tot si re-entrenéssim el model amb la documentació de Nubelia, quedaria obsoleta a cada release. La documentació canvia cada setmana; els models s'entrenen cada molts mesos. Per això l'estratègia correcta no és "posar el coneixement dins del model" sinó passar-li la informació vigent al context a cada crida — un altre cop, el patró RAG del mòdul 4.

Regla de disseny: per a qualsevol dada que canviï amb el temps, tracta el coneixement intern del model com a potencialment caducat i subministra la versió actual al context.

Un LLM no és una funció pura: la mateixa entrada pot produir sortides diferents en crides diferents. Ho vam veure a la lliçó 01-02: el mostreig introdueix atzar deliberadament, i ni tan sols amb temperature = 0 hi ha garantia absoluta de reproducibilitat (entre altres coses, per detalls de l'aritmètica en paral·lel de les GPUs i per canvis de versió del model al proveïdor).

Què implica per a tu com a desenvolupador:

• Testing: no pots assertar resposta == "text esperat". Els tests d'aplicacions amb LLM verifiquen propietats (conté la cita correcta?, és un JSON vàlid?, esmenta la funcionalitat X?) o fan servir avaluadors — ho veurem a la lliçó 06-03.
• Depuració: una fallada pot no reproduir-se a la primera. Registrar entrades i sortides de cada crida (observabilitat, lliçó 06-04) deixa de ser opcional.
• Experiència d'usuari: dos empleats de Nubelia que facin la mateixa pregunta a DocuBot rebran redaccions diferents. Acceptable en general — però si la substància varia (a l'un li diu que sí i a l'altre que no), tens un problema de fiabilitat que s'ha de detectar amb avaluació.
• Canvis silenciosos de model: els proveïdors actualitzen i deprequen models. La versió que has avaluat avui es pot comportar diferent després d'una actualització: fixa versions quan sigui possible i re-avalua en canviar.

Els LLMs aprenen de textos escrits per persones, amb tots els seus biaixos: culturals, de gènere, geogràfics, lingüístics. El model els absorbeix i pot reproduir-los o amplificar-los.

Manifestacions rellevants en aplicacions reals:

• Biaixos socials: associacions estereotipades en generar descripcions, exemples o avaluacions que involucrin persones o col·lectius.
• Biaix lingüístic: rendiment superior en anglès (majoritari a les dades d'entrenament); en català o castellà, el mateix model pot raonar una mica pitjor o produir calcs de l'anglès.
• Biaix de disponibilitat: el més freqüent a les dades es converteix en la resposta "per defecte" — solucions tècniques populars recomanades encara que no siguin les adequades per al teu cas.
• Sycophancy (complaença): tendència a donar la raó a l'usuari i adaptar-se a les seves expectatives, en lloc de contradir-lo quan toca.

Fins i tot en un assistent "purament tècnic" com DocuBot cal vigilar-ho: si l'equip de suport li demana redactar respostes a clients, els biaixos de to i les suposicions sobre l'usuari acaben en comunicacions reals. Mitigació a alt nivell: instruccions explícites sobre to i suposicions (mòdul 2), revisió humana de textos que surtin de l'empresa i avaluació amb casos diversos (mòdul 6).

Cada crida a un LLM costa diners (tokens d'entrada + sortida, com vam veure a la lliçó 01-03) i consumeix temps i energia. El tractem aquí com a risc de disseny — la gestió operativa detallada (caching, optimització, monitoratge de despesa) arriba a la lliçó 03-04.

El risc té una forma concreta: el cost de les aplicacions LLM escala amb l'ús de maneres que el programari tradicional no. Un endpoint REST clàssic costa pràcticament el mateix amb 10 que amb 10.000 peticions diàries; amb un LLM, 1.000× més peticions són (aproximadament) 1.000× més cost. Errors de disseny típics que el disparen:

• Context inflat: reenviar a cada crida documentació o historial innecessaris. Recorda: pagues tots els tokens d'entrada a cada crida.
• Crides evitables: fer servir l'LLM per al que resoldria una consulta a base de dades o una regla simple.
• Bucles i reintents sense control: una fallada mal gestionada que reintenta en bucle són diners sortint per una aixeta oberta (ho gestionarem a la lliçó 03-02).
• Sobredimensionar el model: fer servir l'esglaó gran per a tasques del petit (lliçó 01-03).

Estimació de tovalló per a DocuBot, per desenvolupar el reflex:

La xifra exacta importa poc (els preus canvien); l'hàbit sí: fes aquest càlcul en la fase de disseny de qualsevol funcionalitat amb LLM, no quan arribi la factura.

Última limitació, sovint la primera que et preguntarà la teva empresa: en fer servir un model via API, el contingut de cada crida viatja al proveïdor. Prompts, documents inclosos al context, preguntes dels usuaris — tot.

Punts clau a alt nivell (el detall normatiu — RGPD, acords de tractament, residència de dades — es tracta a la lliçó 06-02):

• Llegeix els termes de dades del proveïdor: fa servir les teves crides per entrenar models? (els plans d'API empresarials dels proveïdors seriosos, per regla general, no ho fan, a diferència d'alguns productes gratuïts de consum); quant de temps reté les dades?; on es processen?
• Minimitza el que envies: no incloguis al context dades personals o confidencials que la tasca no necessiti. Si un tiquet de suport conté dades d'un client i l'LLM només l'ha de classificar, anonimitza o elimina aquestes dades abans de la crida.
• Compte amb el "shadow AI": empleats enganxant informació confidencial a xats d'IA de consum, fora de tot control corporatiu. Part del valor de construir un DocuBot oficial és precisament oferir un canal aprovat i controlat.
• Per a Nubelia: la documentació interna és confidencial però no conté dades personals de clients, així que una API amb bones garanties contractuals és acceptable (com vam decidir a la lliçó 01-03). Si DocuBot algun dia processés tiquets amb dades de clients, l'anàlisi de privadesa s'hauria de refer — i això és una decisió de compliance, no només tècnica.

Queda deliberadament fora d'aquesta lliçó l'altre gran front de seguretat — usuaris manipulant el model mitjançant prompt injection i atacs relacionats — que té lliçó pròpia (06-01).

• Confiar en una resposta perquè sona segura. La fluïdesa del text no correlaciona amb la seva veracitat; la seguretat del to, tampoc. Verifica tota dada accionable (endpoints, comandes, xifres) contra la font abans de fer-la servir.
• Intentar arreglar les al·lucinacions només amb el prompt. Instruccions com "no inventis" ajuden, però no basten: sense donar-li la informació correcta al context, el model no té alternativa al seu coneixement congelat. La mitigació de fons és arquitectònica (RAG), no cosmètica.
• Dissenyar com si el model recordés. "L'hi vaig dir fa tres missatges" no existeix per al model si la teva aplicació no ha reenviat aquests missatges. La gestió de l'historial és responsabilitat del teu codi.
• Descobrir els costos a la factura. Estima cost per crida × volum en la fase de disseny, posa límits de despesa i alertes des del primer dia.
• Enviar dades sensibles "perquè és més còmode". Pregunta't davant cada crida: necessita el model aquesta dada per a la tasca? Si no, fora. La minimització és la regla més barata de la privadesa.
• Pensar que aquestes limitacions desapareixeran el mes que ve. Els models milloren, però al·lucinacions, context finit, tall de coneixement i cost per token són característiques estructurals de la tecnologia actual. Dissenya amb elles, no contra elles.
• Consell: converteix aquesta lliçó en una checklist de disseny. Davant cada nova funcionalitat amb LLM: què passa si al·lucina? hi cap el context? les dades estan vigents? tolero variabilitat? hi ha biaixos amb impacte? quant costa al meu volum? quines dades surten i han de sortir?

Per a cada incident de DocuBot, identifica quina limitació de la lliçó l'explica i una mitigació raonable:

1. DocuBot explica amb detall com activar la "integració amb calendari" de Nubelia. Aquesta integració no existeix; n'hi ha una de similar amb un altre nom.
2. Després de 40 minuts de conversa, DocuBot comença a contradir coses que ell mateix havia dit al principi del xat.
3. Un empleat pregunta per la política de desplegaments aprovada el mes passat i DocuBot descriu la política de fa dos anys que apareixia en un web públic.
4. L'equip de QA executa el mateix test dues vegades i la resposta esmenta la font correcta la primera vegada, però no la segona.

L'equip de producte de Nubelia proposa que DocuBot, a més de respondre, resumeixi automàticament cada tiquet de suport en crear-se (uns 3.000 tiquets/mes, entrada mitjana 2.000 tokens, sortida 200). Amb els preus il·lustratius de la lliçó (3 €/M entrada, 15 €/M sortida): calcula el cost mensual afegit, i esmenta una decisió de disseny que el reduiria sense eliminar la funcionalitat.

Escriu el text breu (2–4 frases) que DocuBot hauria de mostrar de manera permanent a la seva interfície per posar les expectatives correctes als empleats de Nubelia, cobrint com a mínim: possibilitat d'error, necessitat de verificar informació crítica i què no s'ha d'enganxar al xat.

Solució 1:

1. Al·lucinació (agreujada per la plausibilitat del domini: "integració amb calendari" és típic d'un SaaS de projectes). Mitigació: respondre només a partir de fragments de la documentació real recuperats per a la pregunta (RAG, mòdul 4) i instruir el model perquè admeti quan la documentació no esmenta alguna cosa, citant fonts.
2. Finestra de context: la conversa llarga excedeix la finestra (o l'historial es va truncar) i el model ja no "veu" les seves primeres respostes. Mitigació: estratègia de gestió d'historial — truncament intel·ligent o resum de la conversa prèvia (lliçó 03-03).
3. Tall de coneixement: la política nova és posterior a l'entrenament (i a més és interna); el model recorre al que va veure a les seves dades. Mitigació: subministrar la versió vigent del document al context a cada crida, en lloc de confiar en el coneixement del model.
4. No determinisme: el mostreig produeix variacions entre execucions, i aquí la variació afecta la substància (la cita). Mitigació: temperature baixa per a aquest cas d'ús i, sobretot, tests que verifiquin propietats (inclou la font?) executats sobre diverses mostres, amb llindars d'aprovació (lliçó 06-03).

Solució 2:

• Cost per tiquet ≈ 2.000/1M × 3 € + 200/1M × 15 € = 0,006 € + 0,003 € = 0,009 €.
• Cost mensual ≈ 0,009 € × 3.000 = 27 €/mes. Perfectament assumible — el càlcul ràpid evita tant ensurts com vetos infundats: aquí els números avalen la funcionalitat.
• Decisions de disseny que el reduirien (qualsevol val): fer servir un model petit per resumir (tasca simple, no necessita l'esglaó mitjà); resumir només tiquets que superin una certa longitud (els curts ja són el seu propi resum); o retallar l'entrada a les parts rellevants del tiquet abans de la crida.

Solució 3 (exemple):

"DocuBot genera les seves respostes amb intel·ligència artificial a partir de la documentació interna de Nubelia i pot cometre errors o ometre informació. Verifica sempre contra la documentació enllaçada qualsevol dada que hagis de fer servir en producció o comunicar a un client. No enganxis al xat dades personals de clients ni credencials. Si detectes una resposta incorrecta, reporta-la: ens ajuda a millorar l'assistent."

(L'essencial: fal·libilitat admesa, verificació del que és crític, restricció sobre dades sensibles; el canal de feedback és un extra valuós.)

Amb aquesta lliçó tanques el mòdul de fonaments amb una visió completa i honesta de la tecnologia. Ja coneixes les set limitacions que condicionen qualsevol disseny amb LLMs: les al·lucinacions (el model optimitza plausibilitat, no veritat — com el DocuBot ingenu inventant endpoints de Nubelia), la finestra de context finita i sense memòria entre crides, el tall de coneixement que congela el que s'ha après, el no determinisme que obliga a testejar propietats en lloc de textos exactes, els biaixos heretats de les dades, els costos que escalen amb cada token i cada crida, i la privadesa de tot el que viatja al proveïdor. I coneixes la resposta de fons del curs: donar al model el context correcte a cada crida — el patró que desenvoluparem com a RAG al mòdul 4 — juntament amb avaluació sistemàtica (mòdul 6) i decisions de disseny conscients. Cap d'aquestes limitacions no invalida els LLMs; totes exigeixen que el desenvolupador — tu — dissenyi amb elles sobre la taula. Al pròxim mòdul passem d'entendre a actuar: el prompt engineering és la primera eina concreta per dirigir el comportament del model, i començarem per l'anatomia d'un prompt — rols, instruccions i context — escrivint ja les primeres instruccions reals de DocuBot.