LLMOps: el flux real per portar un sistema LLM a producció i mantenir-lo viu

La demo va funcionar. El sistema no. És el patró que més ens trobem quan entrem en un equip que ja té alguna cosa amb LLM davant d'usuaris reals: el prototip va convèncer el comitè en quinze minuts i sis mesos després ningú no sap dir si avui respon millor o pitjor que al març. No hi ha una mètrica que ho digui. Hi ha una sensació, i les sensacions no sostenen un sistema en producció.

LLMOps és la disciplina que tanca aquest buit: el conjunt de pràctiques per construir, desplegar, mesurar i mantenir sistemes el comportament dels quals no és escrit al teu codi. No és una plataforma que es compra ni un rol que es contracta. És un cicle amb etapes, portes de qualitat i responsables — i la majoria d'equips el té obert per algun punt sense saber-ho.

Aquest article és la versió operativa d'aquest cicle: què versiones de debò, quin és el flux etapa per etapa, on van les dues portes, quines mètriques decideixen i quines fallades només apareixen quan ja hi ha trànsit real. Si el que busques és la conversa de negoci —què mesura un Head of Product per decidir si una funcionalitat d'IA continua viva—, és a com mesurar si la IA del teu producte funciona. Això d'aquí és la capa d'enginyeria que hi ha a sota.

LLMOps no és MLOps amb un altre model

L'error de partida més car és tractar un sistema LLM com un projecte de machine learning clàssic. Comparteixen la intenció —operar programari el comportament del qual és estadístic, no determinista— però no comparteixen l'objecte sobre el qual s'opera. A MLOps l'artefacte central són els pesos, les features i el dataset d'entrenament; el model canvia quan tu decideixes reentrenar-lo. A LLMOps el model l'entrena un altre, canvia quan aquest altre vol, i el que tu controles és tota la resta.

Aquesta diferència no és filosòfica. Reordena el cicle sencer:

La conseqüència pràctica és incòmoda: pots tenir el sistema congelat, sense un sol commit en tres setmanes, i estar servint respostes pitjors que fa un mes. En programari tradicional això no passa. A LLMOps és l'escenari base contra el qual es dissenya.

Què versiones realment: el bundle de context

Abans de parlar de flux cal fixar la unitat de desplegament. Si preguntes a un equip què versiona del seu sistema LLM, la resposta sol ser «el prompt» — i el prompt és entre el 10% i el 20% del que determina el comportament. Aquests són els vuit elements que formen el bundle de context, i tots han de viure al repositori:

• Plantilles de prompt: system prompt, exemples few-shot, plantilles de tasca. Amb versió pròpia i changelog, no editades en calent des d'un panell.
• Definicions d'eines: nom, descripció i JSON Schema de cada paràmetre. La descripció d'una tool no és documentació: és prompt que s'envia a cada crida i que decideix si el model la fa servir bé o la ignora.
• Configuració de recuperació: model d'embeddings, estratègia de chunking i solapament, top-k, reranker, filtres de metadades, llindar de similitud.
• L'índex: versió, data d'ingesta i hash del corpus. Un índex reconstruït és un desplegament, encara que no hagi canviat ni una línia de codi.
• Política d'encaminament i pin de model: quin model atén quina tasca, amb identificador de versió explícit. claude-sonnet-5 és un pin; «l'últim Claude» no ho és.
• Paràmetres de mostreig: temperature, top_p, max_tokens, seqüències d'aturada.
• Guardrails: filtres d'entrada i sortida, política de PII, llistes de rebuig, límits de passos i de cost per tasca.
• El conjunt d'avaluació i els seus llindars: els casos, les rúbriques i el llistó que cal superar per promocionar.

La regla operativa és simple i bastant estricta: una release és la tupla completa. Si puges top-k de 5 a 8, no estàs afinant un paràmetre — estàs desplegant una versió nova del sistema, i li correspon el mateix cicle d'avaluació que a un canvi de prompt. Els equips que tracten la recuperació com a configuració i el prompt com a codi acaben amb la meitat del seu comportament fora de control de versions.

El flux: nou etapes, dues portes, un bucle que es tanca

Aquest és el cicle que instal·lem quan entrem en un equip amb sistemes LLM ja en producció. No hi ha res exòtic: la majoria de les peces existeixen en qualsevol pràctica d'enginyeria seriosa. El que gairebé mai no existeix és l'ordre i, sobretot, el tancament del bucle.

Etapa 0 · El contracte de tasca és el primer, no el prompt

Gairebé tots els sistemes LLM que auditem comencen pel prompt. És l'ordre equivocat. Abans d'escriure una línia cal fixar per escrit què compta com a resposta correcta, quin format és obligatori, quines fonts són admissibles i —això és el que gairebé ningú no escriu— què ha de fer el sistema quan no ho sap. Un sistema sense política d'abstenció definida sempre inventa, perquè generar és exactament el que sap fer.

El contracte el signa qui coneix el domini: el jurista si és contractació, el responsable de suport si és atenció al client, l'analista si és reporting. No l'equip d'IA. Si el contracte només existeix en converses, l'avaluació posterior mesurarà el que l'equip tècnic creu que és correcte, que rarament coincideix amb el que el negoci necessita.

Etapes 1 i 2 · El golden set i el baseline honest

El golden set és l'actiu més subestimat de tot el cicle. Un prompt bo el replica qualsevol en una tarda; un conjunt de 200 casos etiquetats amb criteri de domini són mesos de feina acumulada i no es pot copiar. Comença petit —30 a 50 casos per capacitat—, estratifica per dificultat i inclou tres tipus de cas adversari: entrades fora de domini, preguntes legítimament ambigües on la resposta correcta és reconèixer l'ambigüitat, i intents d'injecció d'instruccions amagades als documents que el sistema recupera.

El baseline honest és la contramesura contra l'optimisme. Mesura primer el sistema més simple que resol la tasca —sovint una sola crida amb bon context— i publica el número. Sense aquest punt de referència, qualsevol arquitectura posterior sembla una millora. Amb ell, molts equips descobreixen que el seu pipeline de set passos rendeix igual que la crida única i costa cinc vegades més.

Aquesta és l'etapa on més equips s'encallen, i per això té article propi: com es construeix el golden set — d'on surten els casos, per què s'estratifica per capacitat i no per volum, quant error d'etiquetatge arrossegues sense saber-ho i per què el conjunt retingut es gasta cada vegada que el mires.

Etapa 4 · Porta 1: l'avaluació offline decideix, no opina

La primera porta corre en CI, a cada pull request que toqui qualsevol element del bundle. I avalua quatre coses alhora, no una:

• Qualitat per capacitat, no agregada. Una mitjana que puja amagant que la capacitat crítica va caure vuit punts és pitjor que no mesurar.
• Regressió zero al subconjunt crític: els casos que no poden fallar mai —els que van costar una incidència— són un bloc a part amb llindar absolut.
• Cost per tasca útil comparat amb el baseline. El cost és criteri d'acceptació, no una conseqüència que es descobreix a la factura.
• Latència p95 end-to-end, incloent-hi eines i recuperació.

Perquè això sigui sostenible convé partir la suite en dues: una fast suite de pocs minuts que corre a cada PR, i una full suite nocturna amb el conjunt complet. Una suite única de 400 casos que triga quaranta minuts acaba desactivada en tres setmanes, i una porta desactivada és pitjor que cap porta perquè produeix falsa confiança.

Etapes 5 i 6 · Porta 2: el trànsit real és l'únic jutge definitiu

Cap conjunt d'avaluació no captura la distribució real d'entrades. Per això la promoció a producció és progressiva i no un interruptor: primer shadow (el sistema nou processa el trànsit real però la seva sortida no es serveix, només es compara), després canary al 5%, 25% i 100%, amb una finestra mínima a cada esglaó que depengui del volum —no de la impaciència.

La condició innegociable és que el criteri de rollback estigui escrit abans d'obrir trànsit: quina mètrica, quin llindar, quant temps i qui decideix. Un rollback discutit en calent a les onze de la nit sempre es retarda, perquè en aquell moment tothom té una hipòtesi de per què els números són soroll.

Etapa 7 · Observabilitat: la traça és la unitat, no el log

Un log de peticions i respostes no serveix per depurar un sistema agèntic. El que necessites és la traça completa de la tasca: cada pas com un span imbricat, amb el prompt renderitzat, els documents recuperats i les seves puntuacions, les eines invocades amb els seus arguments, els tokens d'entrada i sortida, la latència i el cost. Les convencions semàntiques gen_ai.* d'OpenTelemetry cobreixen la major part d'aquests atributs i eviten inventar un esquema propi que ningú més no entengui.

El criteri de qualitat de la instrumentació és concret: davant d'una queixa d'un usuari, pots reconstruir exactament quin context va veure el model quan va produir aquella resposta? Si la resposta és no, l'observabilitat és incompleta per molt bonics que siguin els dashboards de tokens. És el mateix buit que descrivim a el gap de qualitat que gairebé ningú no mesura en agents en producció: es monitora el consum, no el resultat.

Etapa 8 · La mineria de fallades és el que converteix el cicle en bucle

Aquí és on es trenca la majoria d'implementacions que hem vist. S'instrumenten traces, es munten dashboards, es recullen polzes avall… i ningú no té a la seva setmana la tasca de convertir aquestes fallades en casos d'avaluació. El resultat és un sistema que acumula telemetria i no aprèn: els mateixos errors reapareixen release rere release perquè mai no van entrar a la suite que els hauria detectat.

El ritual mínim que funciona: una sessió setmanal de 45 minuts on dues persones revisen una mostra de traces fallides, classifiquen la causa arrel —context insuficient, recuperació dolenta, instrucció ambigua, eina trencada, límit del model— i promouen a golden set els casos que representen un patró. És l'etapa més barata del cicle i la que decideix si d'aquí a sis mesos el sistema és millor o simplement més vell.

Mètriques: què decideix i què és només soroll bonic

La telemetria per defecte de qualsevol proveïdor et dona tokens, latència i errors. Les tres són necessàries i cap no diu si el sistema funciona. Aquestes són les quatre famílies que sí que decideixen:

• Qualitat: taxa d'encert per capacitat; groundedness (percentatge d'afirmacions recolzades per una cita que resol de debò); validesa de les crides a eines (schema correcte i arguments plausibles); taxa d'abstenció correcta quan no hi ha informació suficient.
• Fiabilitat operativa: latència p50 i p95 end-to-end; passos per tasca; taxa de bucles i de timeouts; taxa d'error d'eina.
• Cost: cost per tasca útil —crèdits consumits entre resultats correctes i realment fets servir—, ràtio de tokens d'entrada davant de sortida, i cost marginal del context arrossegat. El cost per token és una mètrica de proveïdor; el cost per tasca útil és una mètrica de negoci.
• Adopció: containment (tasques tancades sense intervenció humana), taxa d'escalada, i percentatge de sortides que l'humà edita abans d'acceptar — l'indicador més honest de qualitat percebuda que existeix.

De totes elles, la que més vegades canvia una decisió d'arquitectura és el cost per tasca útil. Un sistema amb un 92% d'encert a 0,40 € per tasca pot ser pitjor negoci que un altre amb un 86% a 0,04 € si el 8% restant l'absorbeix una cua humana que ja existeix. Aquesta comparació és impossible de fer si mesures tokens. Sobre per què aquesta xifra es dispara entre el pilot i l'escala, ho desenvolupem a el cost real de posar IA en producció.

Avaluar amb LLM: útil, però cal calibrar el jutge

Fer servir un model com a avaluador és el que fa viable mesurar qualitat a escala, i també la porta d'entrada de la majoria d'autoenganys. Un jutge basat en LLM és un classificador més: abans de confiar-hi cal mesurar-ne l'acord amb etiquetes humanes sobre una mostra. Com a regla de treball, per sota d'un acord substancial —un kappa entorn de 0,7— el jutge està mesurant el seu propi estil, no la teva qualitat.

Quatre regles que apliquem sempre: rúbrica escrita amb un únic criteri per crida (no demanis «puntua de l'1 al 10 la qualitat global»); model jutge diferent de l'avaluat, per no premiar l'estil propi; comparació per parells quan el criteri és preferència i puntuació absoluta només quan hi ha rúbrica objectiva; i un mostreig humà permanent d'entorn al 10% per detectar quan el jutge es desalinea. El jutge també deriva, i també necessita el seu propi golden set.

Com s'escriu aquesta rúbrica —i com es tria el baseline contra el qual comparar, que és l'altra meitat del problema— ho desenvolupem a què significa exactament que un agent «funciona millor», amb els treballs que han estudiat l'assumpte.

Les quatre fallades que només apareixen en producció

Cap d'aquestes no apareix en desenvolupament. Les quatre apareixen quan hi ha trànsit real i temps.

1. Drift del proveïdor. El model s'actualitza i el teu sistema canvia sense que ningú hagi fet un commit. La contramesura és doble: pin de versió explícit al bundle i una suite de regressió programada que corre contra producció setmanalment i publica la comparació amb el baseline. És el control més barat de tot el cicle i el que menys equips tenen.

2. Degradació silenciosa de la recuperació. El corpus creix, la densitat semàntica augmenta, el top-k que funcionava amb 2.000 documents deixa de portar el fragment correcte amb 50.000. El símptoma és traïdor: el model continua responent amb total seguretat, només que ara sobre context incomplet. Es detecta mesurant la recuperació per separat —precisió i recall del context— i no només la resposta final. És el punt on més s'hi juga un sistema RAG, i el tractem a fons a RAG per a aplicacions empresarials.

3. Regressió per edició de prompt. Algú arregla el cas que va reportar un client i en trenca tres que ningú no estava mirant. És exactament la fallada que la Porta 1 existeix per bloquejar; sense ella, cada arranjament és una aposta. I amb prompts editables en calent des d'un panell d'administració, sense release ni avaluació, és una aposta que es fa diverses vegades per setmana.

4. Explosió de cost per context. L'històric de conversa que s'arrossega sencer, el fitxer complet quan n'hi havia prou amb una secció, les descripcions de vint eines replicades a cada crida. El cost d'entrada sol superar el de sortida i gairebé ningú no ho separa en la seva anàlisi. La contramesura és una auditoria periòdica de la composició del context, que és enginyeria de context aplicada al pressupost.

Governança: qui signa cada porta

Un cicle sense responsables assignats es degrada en dos mesos. El repartiment mínim que funciona en equips de 10 a 100 persones assigna a producte o domini el contracte de tasca i el golden set; a enginyeria, el bundle, les portes i l'observabilitat; i a un responsable únic —normalment el Tech Lead— la decisió de promocionar i la de fer rollback. Tres rols, no un comitè.

A això s'hi afegeix la capa reguladora, que a Europa ja no és teòrica: per a sistemes classificats com d'alt risc, la traçabilitat i el registre d'esdeveniments deixen de ser bones pràctiques d'enginyeria i passen a ser requisit. La bona notícia és que el cicle que acabem de descriure produeix gairebé tota aquesta evidència com a subproducte —traces retingudes, versions signades, avaluacions arxivades— sempre que es dissenyi així des del principi. Fer-ho després, com a retrofit, és on el cost es multiplica: ho detallem a Compliance-First AI Design.

On és el teu equip: quatre nivells

Un model de maduresa serveix per a una sola cosa: decidir quin és el següent moviment, no per penjar-se una medalla.

• Nivell 0 · Demo. Funciona, no es mesura, el prompt viu fora del repositori. Següent moviment: el contracte de tasca.
• Nivell 1 · Reproduïble. Bundle complet versionat, model pinejat, índex amb snapshot. Pots reconstruir qualsevol release. Següent moviment: el golden set i la Porta 1.
• Nivell 2 · Avaluat. Avaluació offline en CI, desplegament progressiu, traces completes. Saps si un canvi millora o empitjora abans de servir-lo. Següent moviment: tancar el bucle amb mineria de fallades.
• Nivell 3 · Governat. Bucle tancat, cost per tasca com a criteri d'acceptació, responsables nomenats, evidència auditable. Aquí el sistema millora amb l'ús en lloc d'envellir-hi.

La majoria d'equips amb qui treballem entra al nivell 0 o 1 i creu estar al 2, perquè té dashboards. Els dashboards són nivell 1; el nivell 2 comença quan un número pot bloquejar un desplegament. Si vols situar aquesta capa dins del mapa complet de maduresa de l'empresa —i no només de l'equip d'enginyeria—, la peça d'enginyeria d'IA: del pilot a producció la ubica davant de les altres sis.

Les dues primeres setmanes

Si tens un sistema LLM en producció i res de l'anterior instal·lat, aquest és l'ordre que produeix més senyal per euro invertit. No requereix plataforma nova ni reescriure res.

Setmana 1. Escriu el contracte de tasca amb la persona de domini —dos folis, inclosa la política d'abstenció—. Instrumenta traces completes amb atributs gen_ai.* al flux principal. Congela el bundle: fica a git tot el de la llista de vuit elements i pineja la versió del model.

Setmana 2. Construeix 30 casos golden a partir de trànsit real, incloent-hi les cinc fallades que més t'han fet mal. Mesura el baseline i publica'l. Munta la fast suite en CI amb dos llindars: qualitat al subconjunt crític i cost per tasca. A partir d'aquí, cada canvi passa per la porta.

En dues setmanes no tens LLMOps madur, però tens l'única cosa que de debò cal per començar: la capacitat de respondre «sí» o «no» a la pregunta de si el canvi d'ahir va millorar el sistema. Tota la resta es construeix a sobre d'aquesta resposta.

La mateixa disciplina que ja apliques al codi

Res de l'anterior no és nou com a principi. Contracte abans que implementació, avaluació automàtica abans que promoció, desplegament progressiu, telemetria que tanca el bucle: és enginyeria de programari normal, aplicada a un component que no és determinista. Per això els equips que ja treballen amb Spec-Driven Development adopten LLMOps en setmanes i no en trimestres — ja tenen l'hàbit d'escriure l'especificació abans que l'artefacte, i el bundle de context no és més que una altra especificació versionada.

Als programes onext AI-Accelerated Development aquest cicle és part del harness que deixem instal·lat, no un afegit posterior. Els resultats que signem amb clients el 2026 —×7 velocitat de lliurament, 0 sprints perduts, −50% time-to-production— no surten d'escriure millors prompts: surten que els equips poden desplegar canvis en sistemes d'IA sense por, perquè hi ha una porta que diu si el canvi és bo abans que el vegi un usuari.

Preguntes freqüents

LLMOps i MLOps són el mateix?

Comparteixen la intenció —operar sistemes el comportament dels quals no és escrit al teu codi— però no l'objecte. A MLOps versiones pesos, features i datasets d'entrenament, i el model només canvia quan tu el reentrenes. A LLMOps versiones un bundle de context (prompts, eines, recuperació, polítiques d'encaminament, guardrails i llindars) sobre un model que no controles i que pot canviar sense que toquis res. Això escurça el cicle de canvi de setmanes a hores, converteix l'avaluació en l'artefacte crític i desplaça el cost de l'entrenament a la inferència.

Quants casos necessita un golden set per començar a avaluar?

Entre 30 i 50 per capacitat n'hi ha prou per detectar regressions grans, que és el 80% del valor. No comencis per 400: un conjunt gran que ningú no executa val menys que un de petit que corre a cada pull request. Estratifica per dificultat i inclou casos adversaris —entrades fora de domini, ambigüitat legítima on el correcte és reconèixer-la, i injecció d'instruccions en documents recuperats—. El golden set creix després, alimentat per les fallades reals de producció.

Puc fer servir el mateix model com a jutge del sistema que avaluo?

Pots, però abans cal calibrar-lo contra etiquetes humanes sobre una mostra. Com a regla de treball, per sota d'un acord substancial (kappa entorn de 0,7) el jutge mesura el seu propi estil, no la teva qualitat. Convé a més fer servir un model diferent de l'avaluat, una rúbrica escrita amb un sol criteri per crida i un mostreig humà permanent d'entorn al 10% per detectar quan el jutge es desalinea.

Cada quant cal reavaluar si no canvio res?

Setmanalment com a mínim, i sempre que el proveïdor anunciï actualització de model. Un sistema LLM es pot degradar sense un sol commit: el model canvia, el corpus indexat creix i el recall cau, o l'ús real s'allunya del que vas provar. Un cron que executa la suite de regressió contra producció i publica la comparació amb el baseline és el control més barat del cicle.

Necessito una plataforma específica d'LLMOps o em val el meu stack actual?

En la majoria de casos l'stack actual arriba més lluny del que es creu: git per al bundle, la CI que ja tens per a la Porta 1, feature flags per al desplegament progressiu i el teu backend de traces per a l'observabilitat amb convencions gen_ai.*. Una plataforma dedicada aporta sobretot ergonomia en anotació i comparació d'avaluacions. Comprar-la abans de tenir contracte de tasca i golden set no accelera res: afegeix una superfície més per mantenir.