„Dar, invariabil, modelele simple și multe date bat modelele mai elaborate bazate pe mai puține date.”Alon Halevy, Peter Norvig, Fernando Pereira · The Unreasonable Effectiveness of Data · 2009 · The Unreasonable Effectiveness of Data, IEEE Intelligent Systems 24(2), 2009
O trăsătură se calculează «așa cum era la momentul evenimentului», nu «așa cum e acum».
Argumentul din 2009 a devenit doctrină: mai multe date bat un model mai deștept. Condiția nespusă e că datele sunt corecte în trei feluri pe care un depozit de raportare nu le cere. Întâi, corectitudinea în timp: o trăsătură (feature) se calculează „așa cum era la momentul evenimentului”, nu „așa cum e acum” — un client care azi e premium era, poate, gratuit când a făcut comanda din 2023; dimensiunile de tip 2 sunt exact ce trebuie aici. Apoi, scurgerea (leakage): o coloană care conține răspunsul, direct sau indirect — data anulării când prezici anularea; modelul pare excelent la antrenament și eșuează în producție. În fine, decalajul antrenament–servire (skew): trăsăturile calculate în batch pentru antrenament și cele calculate live pentru predicție trebuie să vină din același cod; feature store-ul există ca să garanteze asta. Restul e disciplină de depozit: împarți seturile pe timp, nu la întâmplare; documentezi definiția etichetei; versionezi setul de antrenament ca să-l poți reproduce peste un an; păstrezi echilibrul claselor în minte. Abia atunci „multe date” înseamnă mai mult decât „multe rânduri”.
De ce contează Un model antrenat pe trăsături „de azi” pentru evenimente „de atunci” învață viitorul și îl uită în producție. Depozitul trebuie să știe să răspundă „cum era la momentul acela”.