Un embedding da 330 MB, una GPU consumer e un archivio di screenshot: è la combinazione che ha permesso a un utente di testare la ricerca semantica di testo dentro le immagini senza passare da servizi cloud. Il modello è EmbeddingGemma2, eseguito via llama.cpp su una RX 7900GRE tramite Vulkan; la dimensione quantizzata Q8_0 è di circa 330 MB e il vettore prodotto ha 768 dimensioni. Su un set di 3.003 screenshot della visual novel Hanasaki Workspring, l'indicizzazione ha richiesto 510 secondi, circa 5,9 immagini al secondo con batch di 8 e ridimensionamento a 1.280 pixel.
L'esperimento, condotto su poche migliaia di immagini e dichiaratamente non scientifico, mostra però un comportamento utile per chi valuta un retrieval self-hosted. Una query con la frase coreana '삼각건이 머리에 얹어졌다' ha restituito il candidato corretto con similarità coseno 0,71156 e un margine di 0,00810 sul successivo; la stessa richiesta in inglese, 'triangular cloth hat was place on top of head', si ferma a 0,62414, segno che il modello riconosce il significato tra lingue ma con similarità più bassa.
Il punto critico non è la velocità, ma la sensibilità alla formulazione. L'autore nota differenze tra 'blond' e 'blonde', un dettaglio che può sembrare marginale ma che in un archivio omogeneo cambia il ranking. Sugli screenshot usati, il 90% delle immagini contiene una ragazza bionda: un attributo visivo generico non aiuta a discriminare e, in alcuni casi, aggiungerlo alla query peggiora la similarità. In coreano, invece, la presenza di una parola rara domina sull'intera frase: '삼각건' compare solo in 2 immagini su 3.003 e produce un salto netto nel margine rispetto ai candidati successivi. Questo sposta l'attenzione dal modello al corpus e alla strategia di query: non basta indicizzare, serve capire quali termini hanno potere discriminatorio nel proprio dataset.
Dal punto di vista strutturale, il test segnala che l'embedding multimodale on-premise è entrato in una fase pratica. Un modello da 330 MB con 768 dimensioni e contesto 4.096 token gira su una singola GPU consumer e può indicizzare migliaia di screenshot in minuti. Non servono API esterne, né upload di immagini potenzialmente sensibili. Per archivi aziendali, documentazione tecnica o dataset con più lingue, questo abbassa la barriera del self-hosted e mantiene il controllo dei dati. Ma introduce un costo operativo diverso: la qualità del retrieval dipende da quanto si conosce il contenuto e da come si scrivono le query. I team che adottano questo approccio devono prevedere iterazioni sulle descrizioni, eventuali dizionari interni e test sul proprio corpus, non solo la scelta del modello.
Chi perde, nel breve periodo, è l'idea che un modello piccolo sia intercambiabile con un servizio cloud di embedding multimodale. Qui la differenza non sta nell'architettura ma nella prevedibilità: il modello locale funziona, ma i suoi limiti (dominanza testuale, debolezza dei tratti visivi, sensibilità alle varianti ortografiche) emergono proprio quando il dataset è visivamente omogeneo. Non è un difetto da correggere in astratto, è un vincolo da mappare sul caso d'uso. Per chi valuta deployment on-premise, questo tipo di test sul proprio corpus è più informativo di qualunque benchmark generico. AI-RADAR esplora questi trade-off nella sezione /llm-onpremise.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!