Si el teu model canvia “sense motiu”, sovint no és el codi: és el dataset. El control de versions de datasets posa ordre a les dades d’entrenament i t’ajuda a repetir resultats, auditar decisions i fer desplegaments amb confiança.
Contacte directe: info@bastelia.com (sense formularis).
Què és el control de versions de datasets
El control de versions de datasets és el conjunt de processos i eines que permeten guardar, etiquetar i recuperar versions concretes de les dades utilitzades per entrenar, validar i avaluar models.
A la pràctica, significa poder respondre (sempre) preguntes com:
- Quines dades exactes van entrenar aquest model?
- Quina transformació (neteja, filtratge, feature engineering) es va aplicar?
- Quins canvis de schema hi ha hagut i quan?
- Podem reproduir el resultat i comparar-lo amb una versió anterior?
Idea clau: a MLOps no n’hi ha prou amb versionar el codi. Si les dades canvien sense control, els resultats també (i la confiança baixa).
Per què és imprescindible a MLOps
Quan industrialitzes models, el problema no és “entrenar” una vegada: és operar versions de dades, features i models al llarg del temps, amb equips diferents i amb requisits de qualitat.
Què ha d’incloure una “versió” de dataset (perquè sigui útil)
Una versió útil no és només “un fitxer”. Per reduir incidències i retraball, és recomanable versionar també el context:
- Identificador i etiqueta (ex.: dataset:fraud-v3.2) amb descripció humana.
- Fonts i criteris d’extracció (dates, filtres, join keys, exclusions).
- Transformacions (neteja, imputacions, normalitzacions) i la seva versió.
- Schema i contracte: columnes, tipus, unitats, valors permesos, nullability.
- Qualitat: proves, llindars, i resultats (ex.: duplicats, outliers, distribucions).
- Permisos i classificació (dades sensibles, PII, retenció, xifrat).
- Traçabilitat: enllaç a l’experiment/execució que va consumir aquella versió.
Consell pràctic: si només versioneu “l’output final”, perdreu temps quan calgui entendre el “per què”. Versionar metadades i proves és el que fa que el sistema sigui operable.
Enfocaments i eines: quin encaixa millor (sense complicar-te)
No hi ha una única manera correcta. L’elecció depèn del volum de dades, de si treballeu amb data lake, de quants equips/pipelines comparteixen datasets i de la necessitat d’auditoria.
Útil si els datasets són petits i el repositori no s’infla. Limitat quan hi ha fitxers grans, moltes versions o molts usuaris.
Bona opció quan vols versionar dades i experiments de manera propera al flux de Git, i desar les dades en un storage extern (S3/GCS/Azure, NAS, etc.) amb referències i metadades al repositori.
Pensat per entorns amb data lake i equips/pipelines múltiples. Aporta branques, commits i punts de recuperació sobre storage central, i facilita aïllar canvis de dades abans de “promoure’ls”.
Quan el teu dataset viu com a taules (no només fitxers), aquests formats ajuden a gestionar canvis i versions a nivell de taula i particions. Pot ser ideal si el teu cas és analític/warehouse-first.
Molt útil per enllaçar dataset version ↔ run ↔ model. Sovint funciona millor combinat amb una capa de versionat de dades (DVC/lakeFS/taules).
Si vols que t’ajudem a triar (i sobretot a deixar-ho operable amb proves i governança), mira també: Serveis d’IA, Consultoria i Roadmap d’IA i Paquets i preus.
Arquitectura recomanada (simple i escalable)
L’objectiu és que cada entrenament i cada desplegament pugui referenciar una combinació estable de: dades + transformacions + paràmetres + model.
Flux mínim viable (que evita problemes típics)
- Fonts → Ingesta Definiu com entra el dato (batch/stream), amb validacions bàsiques i logs.
- Storage central (data lake/warehouse) Manteniu dades en brut i dades curades, separades, amb polítiques d’accés.
- Capa de versionat + metadades Etiquetes, branques i commits (o snapshots/time travel) + metadades (schema, proves, propietari, etc.).
- Pipelines d’entrenament i validació Cada execució ha de “pin” la versió de dataset i deixar rastre de proves i mètriques.
- Registre de models Relaciona model ↔ versió de dades ↔ codi ↔ paràmetres. Això és el que et salva quan cal investigar.
- Producció + observabilitat Monitoratge de rendiment i drift, i capacitat de rollback (dades i model).
Implementació pas a pas (la manera ràpida de fer-ho bé)
Un desplegament útil no és “instal·lar una eina”. És definir un mètode perquè l’equip pugui operar versions sense fricció. Aquí tens una seqüència típica que funciona bé en empreses.
- Pas 1 — Delimita què és un dataset (i posa-li nom) Defineix fronteres (quin granulat, quina finestra temporal, quines fonts) i un esquema de noms/etiquetes que tothom entengui.
- Pas 2 — Defineix el “contracte” del dataset Schema, unitats, valors permesos, columnes obligatòries, i com es gestionen canvis (compatibilitat cap enrere quan sigui possible).
- Pas 3 — Tria l’enfocament de versionat segons el volum Projecte petit: flux Git-like (ex.: DVC). Data lake compartit: control de versions sobre storage (ex.: lakeFS) o time travel a taules.
- Pas 4 — Afegeix “quality gates” abans de promoure una versió Proves de schema, duplicats, rangs, distribucions i checks de PII. Si falla, la versió no es promou.
- Pas 5 — Enllaça dataset version ↔ experiment ↔ model Cada run ha de registrar: versió de dades, codi, paràmetres, mètriques i artefactes.
- Pas 6 — Defineix estratègia de branques i entorns Exemple simple: dev (proves) → staging (validació) → prod (versions aprovades). Evita canvis directes a “prod”.
- Pas 7 — Seguretat i governança (sense bloquejar el progrés) Permisos per rol, xifrat, retenció, auditories i un responsable del dataset. El govern “mínim viable” evita caos.
- Pas 8 — Operació: monitoratge i rollback Defineix què vigiles (drift, qualitat d’entrada, mètriques de negoci) i com tornes a una versió estable en minuts, no en dies.
Truc per accelerar: comença amb un dataset crític i un pipeline. Quan el flux funciona i l’equip l’adopta, escales a la resta.
Errors comuns i com evitar-los
- Versionar només l’output final i perdre les transformacions → versiona també metadades i pipeline.
- Duplicar dades enormes a cada canvi → usa storage extern i versionat per referències/commits/time travel.
- No definir schema i contracte → els canvis “petits” trenquen entrenaments i dashboards.
- Fer “prod” editable → separa entorns i promou versions amb proves.
- No enllaçar dades amb models → quan hi ha una incidència, ningú sap què va passar.
- Oblidar privacitat i permisos → classifica dades, limita accés i registra ús.
Si el teu repte és que tot això encaixi amb el teu ERP/CRM/helpdesk, pipelines i equip, això és exactament el que fem a Integració i Implementació d’IA (amb governança i observabilitat).
Costos: què es paga realment (i què acostuma a sortir car si no ho fas)
El cost no és només l’eina. El cost gran sol ser el retrabat: repetir entrenaments, investigar incidències, discutir “quin dataset és el bo” i arreglar regressions tard.
- Storage: versions, retenció i rèpliques (optimitzable amb estratègies de branching i policies).
- Computació: reprocessar dades i entrenar (optimitzable amb pipelines incrementals i caché).
- Operació: proves de qualitat, monitoratge, permisos i auditories.
- Adopció: guies, convencions i disciplina (sense això, el sistema es degrada).
Si vols una estimació realista segons volum, fonts i stack, envia’ns context i et proposem un pla per fases: info@bastelia.com.
Vols implantar-ho amb garanties (i que l’equip ho faci servir)?
Podem ajudar-te a dissenyar l’arquitectura, escollir l’enfocament adequat i deixar un flux operatiu amb proves, traçabilitat i governança. Segons el teu punt de partida, acostuma a funcionar bé començar per una fulla de ruta curta i un pilot real.
FAQs sobre control de versions de datasets i MLOps
Quina diferència hi ha entre versionar dades i versionar codi?
El codi és petit i textual; les dades solen ser grans, binàries i canviants. Per això, el versionat de dades acostuma a guardar les dades en un storage optimitzat (object storage, data lake, taules) i versionar metadades, referències i “fotos” lògiques per poder recuperar una versió sense copiar-ho tot.
Com puc evitar duplicar terabytes de dades cada vegada?
Amb enfocaments que fan branching/commits o time travel i que treballen per referències o canvis incrementals. Això et permet aïllar canvis, validar-los i promoure’ls sense duplicacions massives.
Quines eines són habituals per versionar datasets en MLOps?
Depèn del context. Per fluxos Git-like en projectes de ML, s’usen eines com DVC. En entorns de data lake amb equips i pipelines múltiples, són habituals capes de control de versions sobre storage (com lakeFS). Si treballes amb taules analítiques, els formats amb historial (Delta/Iceberg/Hudi) poden encaixar millor.
Com relaciono una versió de dataset amb el model en producció?
La bona pràctica és registrar sempre dataset version + codi + paràmetres a cada entrenament, i després enllaçar el model publicat amb aquell run. Això fa que qualsevol incidència es pugui investigar i reproduir.
Què hauria de validar abans de “promoure” una versió de dades?
Com a mínim: schema, valors nuls, rangs, duplicats, distribucions, i checks de dades sensibles. Si el dataset alimenta decisions crítiques, afegeix proves específiques del domini (per exemple, coherència temporal, claus de negoci, outliers).
Quant temps triga a implantar un flux operable de versionat de datasets?
Si comences per un dataset crític, és habitual tenir un primer flux funcional en poques setmanes (definició, eina, proves mínimes i integració amb entrenament). L’escalat a més datasets i equips ve després, amb governança i automatització.
Puc començar sense canviar tot el meu data lake o BI?
Sí. El més efectiu és començar per un “mínim viable”: un dataset, una convenció d’etiquetes, un conjunt de proves, i l’enllaç amb el registre d’experiments/models. Quan el flux demostra valor, s’estén a la resta.