A LanceDB egy táblába szervezi a multimodális adatok jellemzőit
A LanceDB új, Geneva nevű feature engineering csomagja egyetlen táblában kezeli a multimodális adatok nyers tartalmát, a belőlük számított jellemzőket és a vektorindexeket. A vállalat szerint ugyanaz a Python-alapú munkafolyamat futtatható helyben, laptopon vagy távoli GPU-klaszteren.
- A Geneva UDF-ekkel számít jellemzőket a LanceDB-táblák meglévő oszlopaiból.
- A nyers képek, a származtatott jellemzők és a vektorindexek egy táblában maradnak.
- A bemutatott folyamat 75 képet dolgoz fel fájlmérettel, képmérettel, embeddinggel és felirattal.
- A helyi és az Enterprise-futtatás ugyanazokat az UDF-eket, sémákat és vezénylési kódot használja.
- Az OpenCLIP-embeddingek külön export és vektoradatbázis nélkül kereshetők.
A szkriptekből kezelt adatfeldolgozás felé
A multimodális adatokkal dolgozó csapatok gyakran egy egyszerű szkripttel kezdenek: beolvasnak egy képeket tartalmazó mappát vagy adathalmazt, lefuttatnak rajta egy modellt, majd az eredményeket külön JSON-fájlba, második táblába vagy Parquet-fájlba írják. A LanceDB szerint ez addig működik jól, amíg nem változik a modell, nem nő meg jelentősen az adatmennyiség, vagy nem lesz szükség újabb jellemzőre.
A folyamat később újrapróbálkozási logikával, kötegelt feldolgozással, ellenőrzési pontokkal és ütemezéssel bővülhet. A Geneva ezt a fejlődő, nehezen karbantartható szkriptet váltja ki. A fejlesztő egy Python-függvényt, úgynevezett UDF-et, deklarál, amely egy vagy több meglévő oszlopból kiszámít egy jellemzőt. Ezt új oszlopként csatolja egy LanceDB-táblához, a rendszer pedig elosztja a munkát, kötegekben futtatja a számításokat, menti a haladást, majd az eredményeket a forrásadatok mellé írja.
75 kép, négy feldolgozási lépés
A LanceDB a Geneva működését a geneva-examples nevű, önállóan futtatható példatárban mutatja be. A tároló képekhez, videókhoz és PDF-ekhez kínál feldolgozási folyamatokat. A bemutatott képes folyamat négy parancsból áll: a képek betöltéséből, a fájlméret és a képméretek kiszámításából, az OpenCLIP-beágyazások létrehozásából, valamint a BLIP-feliratok előállításából.
Az alapértelmezett helyi módban a LanceDB egy lemezen tárolt adatbázishoz kapcsolódik, és helyi futtatókörnyezetben, CPU-val végzi a visszatöltést. A példák körülbelül 2 GB memóriára vannak hangolva. LanceDB Enterprise-hitelesítő adatokkal ugyanazok a parancsok távoli GPU-munkásokhoz küldik a feladatokat. A forrás szerint a két módban az UDF-ek, a sémák és a vezénylés kódja azonos.
A folyamat 75, a Hugging Face-ről betöltött állatfotót kezel. A létrejött táblában minden képhez tartozik egy bináris képoszlop, címke és azonosító, valamint a számított fájlméret, képméret, 512 elemű embedding és BLIP-felirat. A LanceDB szerint mind a 75 sorhoz elkészült az összes felsorolt jellemző.
A vektoros keresés külön export nélkül működik
A példában a képek JPEG bájtjai közvetlenül a táblába kerülnek. A nyers képek, a belőlük származó jellemzők és az ezekre épülő vektorindexek ugyanott kapnak helyet, ezért a vállalat szerint nincs szükség külön objektumtárolóra és az ahhoz kapcsolódó metaadattáblára.
Az OpenCLIP-feldolgozás után a rendszer a „great pyrenees” szöveges lekérdezést is beágyazza, majd rákeres az elkészült embedding-oszlopra. A 75 képes mintában a három Great Pyrenees került az első három találati helyre, utánuk egy Saint Bernard és egy Leonberger következett. A LanceDB kiemeli, hogy ehhez nem kellett külön vektoradatbázis vagy exportálási lépés, mivel az embeddingek közvetlenül a képeket tartalmazó táblában váltak kereshetővé.
Ugyanaz az API helyben és távoli környezetben
A LanceDB bemutatója szerint a munkafolyamat alapja három lépés: a jellemző deklarálása, az oszlophoz csatolása és a visszatöltés elindítása. A vállalat egy fájlméretet számító UDF-fel szemlélteti ezt. A függvény a képoszlop bájthosszát adja vissza, az add_columns regisztrálja az új oszlopot, a backfill pedig párhuzamos feladatokra bontva kiszámítja az értékeket és menti a feldolgozás állapotát.
Helyi használatkor a Geneva lemezen tárolt LanceDB-adatbázishoz kapcsolódik. Enterprise-környezetben egy távoli adatbázis-URI és hitelesítő adatok szükségesek, a további kód viszont a forrás szerint változatlan marad. Ez azt jelenti, hogy a fejlesztők ugyanazzal az API-val próbálhatják ki a folyamatot saját gépükön, majd a visszatöltést kezelt távoli GPU-klaszterre küldhetik.
