Si estàs construint (o ja tens en producció) un model de llenguatge (LLM), un sistema RAG o un agent conversacional, el risc no és només “que s’equivoqui”: és no saber què ha passat, què ha canviat i com demostrar-ho quan apareix una incidència. La combinació que evita sorpreses és clara: documentació viva + avaluacions contínues.
En aquesta guia trobaràs un enfocament pràctic per definir què documentar, com avaluar i com monitoritzar els teus sistemes amb LLM perquè siguin robustos, auditables i escalables (sense frenar els equips).
Què vol dir “desenvolupament responsable” en un LLM
Parlar de desenvolupament responsable de models de llenguatge no és un eslògan: és una manera de treballar perquè el sistema sigui traçable, explicable i millorable amb el pas del temps. En la pràctica, vol dir que cada decisió rellevant (dades, prompts, versions de model, filtres, regles, canvis d’arquitectura, etc.) queda registrada i que el rendiment no es dona per fet, sinó que es valida de manera recurrent.
Transparència operativa
Saber què fa el sistema, en quines condicions i amb quines limitacions.
Un LLM pot ser brillant en un context i inadequat en un altre. Documentar l’ús previst i els casos fora d’abast evita mals usos i falses expectatives.
Control del canvi
Cada canvi (model, prompt, fonts, regles) té impacte mesurat i possibilitat de rollback.
Un canvi petit de prompt o de retrieval pot alterar la qualitat, el to, el cost i fins i tot els riscos (p. ex., exposició de dades).
Millora contínua basada en dades
L’avaluació deixa de ser un “test final” i passa a ser un cicle: avaluar → monitoritzar → corregir.
L’objectiu no és perseguir la perfecció: és detectar regressions ràpid, reduir el risc i mantenir la qualitat quan canvia la realitat.
Què s’ha de documentar en un projecte amb LLM (sense paperassa)
La millor documentació és la que es pot mantenir. Per això, funciona molt bé pensar-la com un conjunt de “peces petites” (curtes i actualitzables) en lloc d’un PDF interminable. A continuació tens els blocs que normalment generen més valor (i més tranquil·litat).
1) Fitxa d’ús (què fa, per a qui i amb quines línies vermelles)
- ✓Objectiu del sistema i criteris d’èxit (qualitat, cost, temps, risc).
- ✓Usuaris i context d’ús (intern/extern, nivell d’expertesa, canals).
- ✓Fora d’abast (què NO ha de respondre, decidir o recomanar).
- ✓Requisits de seguretat i privacitat (dades sensibles, retenció, permisos).
2) Dades i coneixement (origen, permisos i qualitat)
En RAG o assistents amb base de coneixement, el “model” no és l’únic responsable: les fonts i la indexació decideixen gran part del resultat.
- ✓Inventari de fonts (CRM, ERP, Drive, Confluence, web, PDFs) i propietaris.
- ✓Permisos i accés (qui pot veure què) i estratègia d’anonimització si cal.
- ✓Qualitat: duplicats, informació obsoleta, contradiccions, versions, “single source of truth”.
- ✓Caducitat i refresc (quan i com es reindexa; què passa amb documents nous).
3) Prompting i configuració (per reproduir i millorar)
- ✓System prompt i instruccions clau (to, limitacions, format de sortida).
- ✓Plantilles de prompts (variables, exemples, llenguatge, restriccions).
- ✓Paràmetres (temperatura, top-p, límit de tokens) i justificació.
- ✓Polítiques de citació i “dir no ho sé” quan falta evidència.
4) Arquitectura i traçabilitat (què passa a cada pas)
- ✓Diagrama simple: entrada → retrieval → reranking → LLM → postprocessat → resposta.
- ✓Tracing (traça per request): prompt final, docs recuperats, latència, cost i versió.
- ✓Guardrails: filtres, validacions, detecció d’injecció de prompt, bloquejos per dades sensibles.
- ✓Fallback humà o flux alternatiu quan el sistema no és fiable.
Checklist ràpida (copiar i aplicar avui)
Si només poguessis fer una cosa aquesta setmana: crea una fitxa curta per versió i fes que cada canvi important (model / prompt / fonts) passi per una revisió mínima. Aquí tens una plantilla compacta, pensada per enganxar-la a Confluence/Notion/Jira.
# Fitxa de versió (LLM / RAG / Agent) - Nom del sistema: - Propòsit i casos d’ús: - Fora d’abast (què NO fem): - Usuaris i canals: - Dades / Fonts (i propietaris): - Permisos / dades sensibles: - Model base i versió: - Prompt(s) i configuració: - Arquitectura (resum del flux): - Guardrails i controls: - Avaluació (suite + resultat): - Monitorització (mètriques + alertes): - Canvis respecte l’última versió: - Riscos coneguts i mitigacions: - Pla de rollback: - Responsable i data:
Consell pràctic: si el teu equip canvia sovint prompts o fonts, separa la documentació en “Prompt Card” i “Data Card”. Així no has de reescriure-ho tot cada vegada.
Com muntar una avaluació contínua (offline + online) sense frenar els equips
En LLM, els tests “exact match” fallen perquè les respostes són no deterministes. Per això, la millor pràctica és combinar: avaluació automatitzada (ràpida i repetible) + revisió humana (en punts crítics) + monitorització (quan ja és en ús real).
A) Offline: suite de proves abans de desplegar canvis
L’objectiu és detectar regressions abans que arribin a l’usuari. Funciona molt bé tenir una “suite petita” per cada canvi i una “suite gran” programada (p. ex. diària o setmanal).
- ✓Golden set de preguntes reals (anonimitzades) i casos límit.
- ✓Qualitat: utilitat, completitud, format, to i coherència.
- ✓Factualitat: resposta suportada per evidència (citacions, fragments recuperats, fonts).
- ✓Seguretat: intents de jailbreak, prompt injection i extracció de dades.
- ✓Equitat: detectar biaixos en respostes quan hi ha col·lectius afectats.
B) Online: avaluació amb ús real (sense “trencar” l’experiència)
- ✓Feedback simple (útil/no útil) i motius predefinits (incomplet, incorrecte, to, etc.).
- ✓Mostreig per revisió humana en rutes crítiques (legal, finances, salut, decisions).
- ✓A/B controlat quan canvies prompt o model (comparar versions amb criteris clars).
- ✓Política de no-resposta quan falta evidència (millor “no ho sé” que inventar).
C) “LLM-as-a-judge” (amb criteri)
És útil per escalar l’avaluació (especialment en qualitat semàntica), però cal definir bé rubriques, exemples i criteris. En tasques sensibles, convé combinar-ho amb revisió humana.
- ✓Defineix una rúbrica (0–5) amb descripcions i exemples.
- ✓Mesura consistència (mateixa rúbrica, mateix criteri) abans de confiar-hi.
- ✓Fixa llindars per bloquejar desplegaments (gates) i per alertar regressions.
Monitorització en producció: mètriques, alertes i regressions
La monitorització en LLM no és només latència i errors d’API. El que diferencia un sistema “pilot” d’un sistema “operable” és poder contestar: quan baixa la qualitat, per què baixa i què hem de canviar (fonts, prompts, guardrails o model).
Mètriques que realment ajuden
- ✓Qualitat percebuda: % útil/no útil, motius, temes amb més fricció.
- ✓Factualitat: % respostes amb evidència / citació / “no ho sé” correcte.
- ✓RAG: recall de recuperació, documents buits, duplicats, contradiccions, “top sources”.
- ✓Cost: tokens per conversa, cost per resolució, desviacions sobtades.
- ✓Risc: intents d’injecció, contingut bloquejat, PII detectada, incidències.
- ✓Operació: latència, errors, timeouts, saturació, degradació per hores/pics.
Alertes i “gates” per evitar regressions
Una bona regla: si no ho pots detectar, no ho pots governar. Defineix llindars per bloquejar canvis quan hi ha regressions clares.
- ✓Gate de qualitat: si baixa X punts en la suite offline, no es desplega.
- ✓Gate de seguretat: si hi ha “escapades” de guardrails, revisió obligatòria.
- ✓Gate de cost: si el cost per conversa supera un llindar, s’atura el rollout.
- ✓Gate de dades: si les fonts canvien (nou repositori, reindexació gran), suite completa.
Governança, riscos i auditories: com arribar-hi amb calma
La governança no ha de ser un fre. Quan hi ha documentació modular + tracing + avaluació contínua, les converses amb seguretat, legal i direcció deixen de ser opinions i passen a ser evidència.
El “pack mínim” que facilita auditories
- ✓Historial de versions (model/prompt/fonts) i decisions associades.
- ✓Evidència d’avaluació (suites, resultats, llindars, incidències i correccions).
- ✓Controls de seguretat i privacitat (accés, redacció, retenció, proveïdors).
- ✓Procediment d’incidents i escalat (qui actua, en quin temps, amb quina informació).
Quan convé fer “red teaming” (i quan no cal dramatitzar)
Si el sistema pot impactar drets, diners, reputació o dades sensibles, cal provar-lo contra casos adversaris (jailbreaks, injecció de prompt, extracció d’informació, etc.). Si és un copilot intern acotat, potser n’hi ha prou amb una suite de seguretat pragmàtica i monitorització.
Com ho fem a Bastelia (i en què et podem ajudar)
Si vols passar de “prototip que funciona” a “sistema amb LLM que aguanta producció”, el camí acostuma a ser: definir estàndards, automatitzar proves, instrumentar tracing i tancar el loop amb millores iteratives. T’hi podem acompanyar des de la fase de diagnòstic fins a l’operació.
Aterrem prioritats, riscos, govern i un pla 30/60/90 dies perquè la documentació i l’avaluació no siguin teoria.
Instrumentem el sistema (traces, logs, mètriques), integrem dades i despleguem amb control del canvi i gates de qualitat.
Dissenyem assistents amb RAG, guardrails i fallback humà perquè siguin útils, segurs i consistents en escenaris reals.
Estructures de documentació, evidències i processos perquè el projecte sigui defensable davant auditories i controls interns.
Automatitzem pipelines d’avaluació, reportings i alertes perquè la millora contínua no depengui d’anar “a mà”.
Vols un pla executable (sense fum) per documentar i avaluar el teu LLM?
Ens expliques el teu cas i et proposem un enfocament clar: què documentar primer, quines proves automatitzar, quines mètriques monitoritzar i quins llindars posar perquè el sistema no faci passos enrere.
Nota: aquesta guia és informativa i no substitueix assessorament legal. Treballem amb el teu equip per adaptar controls i documentació al teu context.
Preguntes freqüents
Quina diferència hi ha entre documentar un LLM i documentar una aplicació amb LLM (RAG o agents)?
Un LLM “nu” és només una peça. En una aplicació real, el comportament depèn del retrieval, les fonts, el prompting, els guardrails i la integració amb sistemes (CRM/ERP). Per això cal documentar el flux complet, no només el model.
Cada quant s’ha de reavaluar un sistema amb LLM?
Depèn del risc i del ritme de canvi. Com a norma: avaluació lleugera en cada canvi rellevant (prompt/model/fonts) i avaluació completa de manera periòdica (setmanal o mensual). Si el coneixement canvia sovint (RAG), afegeix reavaluació després de reindexacions grans.
Quines mètriques són més útils per detectar “al·lucinacions” i errors factuals?
En RAG, és clau mesurar la cobertura d’evidència (respostes amb citacions o suport en documents recuperats), els casos amb confiança baixa i les categories d’error. En prompts sense fonts, convé usar verificació per regles, rúbriques i revisió humana en temes crítics.
Com evito regressions quan el meu equip canvia prompts sovint?
Amb un registre de prompts (versions), una suite de proves amb gates (llindars) i un procés de canvi: proposta → prova offline → rollout controlat → monitorització → ajust. Això permet innovar ràpid sense perdre estabilitat.
Com gestiono dades sensibles i privacitat en projectes amb LLM?
Defineix per defecte el principi de mínim accés, redacció/anonimització quan cal, registres amb retenció limitada, i controls per evitar que el model “repeteixi” informació sensible. També és important documentar proveïdors, ubicació de dades i polítiques d’emmagatzematge.
Necessito LLMOps encara que el meu projecte sigui petit?
No cal un stack enorme. Però sí convé tenir el mínim: tracing, una suite de proves i un parell de mètriques de qualitat/cost. Amb això, el sistema ja es pot governar i millorar sense anar a cegues.