Quan un sistema d'intel·ligència artificial sembla brillant en un entorn controlat i després s'esfondra en producció, la temptació és culpar l'arquitectura o les dades. La causa real sovint és més subtil: es va demanar al model que aprengués l'estructura equivocada. En el desenvolupament de programari seriós, sabem que un model no té qualitat en abstracte; té qualitat per a una tasca concreta. Aquesta tasca defineix un conjunt reduït de coordenades predictives —el que podem anomenar el seu closure— i l'objectiu d'entrenament decideix quantes d'aquestes coordenades s'acaben instal·lant en la representació interna. Aquesta idea, que en l'aprenentatge automàtic rep el nom d'equivalència de valor, té una conseqüència pràctica enorme per a les empreses que volen adoptar IA amb criteri.
Durant anys, l'avaluació de models s'ha recolzat en dues crosses: reconstruir les observacions o predir una recompensa. Totes dues són útils, però no expliquen tota la història. En una aplicació empresarial, a un model no li importa reproduir cada píxel d'un dashboard ni maximitzar una mètrica aïllada. Li importa respondre correctament a les consultes que l'operació li farà. Si aquestes consultes depenen de cinc variables, el model necessita cinc direccions predictives. Un únic número, per ben dissenyat que estigui, només pot instal·lar un subespai de rang u. És el racó de rang u de l'equivalència de valor: la forma més pobra, i tanmateix la més comuna, de guiar un sistema d'IA.
A Q2BSTUDIO, empresa de desenvolupament de programari i tecnologia, veiem aquest fenomen cada vegada que un client porta un model entrenat contra un KPI global que no explica els comportaments que realment importen. El problema no és la falta de potència de càlcul ni el volum de dades. És que es va triar un objectiu massa estret. Per això, quan desenvolupem aplicacions a mida, el primer pas no és triar algorisme, sinó formalitzar el closure de la tasca. Preguntem: quines decisions es prendran amb aquest model? Quines variables necessitem veure representades al seu interior? Quins enllaços causals són imprescindibles? A partir d'aquí, dissenyem un senyal d'entrenament amb la dimensionalitat adequada.
Un exemple val més que molts arguments. Pensem en un sistema de predicció d'abandonament per a una empresa SaaS. Si l'entrenem només amb ingressos recurrents, aprendrà una projecció unidimensional: detectarà quan un client deixa d'aportar diners, però no entendrà el patró complet d'ús, fricció, suport, feature adoption o competència. El resultat és un model que funciona en l'històric d'ingressos però no anticipa l'abandonament real. Si ampliem l'objectiu a un vector amb quatre o cinc mètriques, el model instal·la exactament aquestes direccions. Mesurat amb una sonda lineal, l'estructura recuperable puja de manera notable. La capacitat del model no va canviar; va canviar alguna cosa més profunda: la dimensionalitat de l'objectiu.
I si el model ja té un cap de valor sofisticat? L'evidència experimental indica que la dissociació és dimensional, no un artefacte de la forma del cap. Si compares arquitectures de la mateixa capacitat, amb les mateixes dades i només varies l'objectiu, el resultat és el mateix: un objectiu escalar instal·la una única direcció; un objectiu vectorial instal·la tantes direccions com components tingui. Això no vol dir que la reconstrucció sigui inútil. Vol dir que la seva utilitat depèn de la tasca. En un entorn de bucle tancat on l'estructura rellevant és observable fotograma a fotograma, la reconstrucció pot instal·lar aquesta estructura per si sola i un objectiu escalar pot ser suficient. En canvi, quan l'estructura és abstracta, l'objectiu ha de ser tan ric com el closure.
En projectes reals, aquesta distinció apareix constantment. Un sistema de control d'inventari té l'estoc en cada transacció; la reconstrucció captura la dinàmica. Un sistema de detecció de frau, en canvi, necessita combinar variables que no són totes visibles en una sola observació: import, velocitat, geolocalització, comportament històric del dispositiu. Si l'objectiu és un sol score de risc, el model es converteix en un predictor de rang u. Si l'objectiu inclou les dimensions rellevants del frau, el model pot representar el patró complet. Per això a Q2BSTUDIO no separem l'estratègia d'IA de l'enginyeria de dades. La definició de l'objectiu forma part del disseny tècnic.
A més, cal considerar la pila tecnològica. Un model amb closure ric necessita infraestructura per servir prediccions amb baixa latència i per entrenar de manera contínua. Treballem amb núvol AWS/Azure per desplegar aquests sistemes, apliquem ciberseguretat des del disseny per protegir les dades sensibles que alimenten l'aprenentatge, i utilitzem agents d'IA per automatitzar els fluxos de decisió que abans depenien d'un humà. El núvol no és un detall; és la capa que permet escalar l'objectiu multidimensional sense degradar el rendiment. I la seguretat no és un afegit; és la condició perquè el closure no filtri informació indeguda a través de les representacions internes.
Un altre punt de contacte és el Business Intelligence. Quan un model alimenta un quadre de comandament, el problema es trasllada a la visualització. Un dashboard que mostra un únic indicador és l'equivalent empresarial del racó de rang u: amaga l'estructura en lloc de revelar-la. Si utilitzem un sistema de BI com Power BI, les mesures han de ser multidimensionals, permetre segmentació, jerarquies i anàlisi de causa. Aquesta exigència condiciona el disseny del model. No es tracta d'afegir quadres per estètica; es tracta que l'objectiu d'entrenament i l'objectiu de negoci comparteixin la mateixa dimensionalitat. Sense això, l'organització prendrà decisions amb una representació empobrida de la seva pròpia operació.
Llavors, com s'aplica això en un projecte? Primer, identifica el closure: enumera les preguntes que el sistema ha de respondre i les variables que afecten aquestes respostes. Segon, defineix l'objectiu amb aquesta dimensionalitat: si el closure té quatre eixos, l'objectiu no pot ser un escalar. Tercer, comprova amb sondes si la representació interna conté cada eix; si una dimensió no apareix, no és un problema de capacitat, és un problema de senyal. Quart, revisa la frontera: si l'estructura és visible en cada observació, la reconstrucció pot fer la feina pesada; si és abstracta, necessites un objectiu explícit. I cinquè, fes proves de pressió en producció: observa si el model falla en les mateixes consultes que l'operació considera crítiques.
El resultat d'aquest enfocament és un model més alineat i, sobretot, més útil. Un model no és bo perquè reconstrueix tot; és bo perquè representa el que la seva tasca necessita. L'equivalència de valor no és binària: una única recompensa és només el racó de rang u. A mesura que l'objectiu creix en dimensionalitat, el model creix en capacitat de representar el problema. Al fons, és una lliçó d'enginyeria: no pots demanar a un sistema que resolgui un problema si no li dones l'estructura d'aquest problema. La bona notícia és que el diagnòstic és senzill. N'hi ha prou de comparar el que demanem al model i el que la tasca realment exigeix. Si hi ha diferència, la fallada no està en l'algorisme; està en l'objectiu.
A Q2BSTUDIO apliquem aquest principi en cada projecte d'IA i desenvolupament de programari. Sabem que les solucions més robustes combinen una bona arquitectura tècnica amb un objectiu d'entrenament ben definit. Per això ajudem les empreses a sortir del racó de rang u, dotant els seus models de la dimensionalitat que l'operació necessita. El resultat no és només un sistema que prediu millor; és un sistema que es pot explicar, auditar i alinear amb l'estratègia de negoci.
