Proudly debugging the system since 1981

Tag: ollama

Ho costruito un selezionatore AI per scegliere le foto migliori da PhotoPrism

Tornare da un viaggio significa quasi sempre ritrovarsi con una quantità ingestibile di foto. Nel caso di Lisbona, il problema non era tanto archiviare gli scatti, quanto riuscire a estrarne una ventina davvero condivisibile: belle, sì, ma anche varie e capaci di raccontare l’esperienza nel suo insieme. PhotoPrism offriva già un’ottima base grazie a geolocalizzazione, riconoscimento facciale, label e strumenti di organizzazione, ma non aveva ancora un modo per comporre automaticamente un album con “le foto più belle” e soprattutto con sufficiente varietà.

Da qui è nata l’idea di un selezionatore AI: una piccola applicazione Java che usa PhotoPrism per recuperare le miniature delle immagini e Ollama per far lavorare due modelli AI, uno multimodale per assegnare un punteggio estetico e produrre una descrizione oggettiva, e un secondo modello testuale per raggruppare semanticamente le foto e selezionarle con più equilibrio.

Il problema vero non era la qualità

Il primo prototipo faceva una cosa molto semplice: prendere le foto da PhotoPrism, inviarle a un modello multimodale su Ollama e chiedere un voto estetico da 1 a 100 insieme a una breve descrizione. Sulla carta sembrava sufficiente, ma in pratica produceva una selezione monotona: immagini molto belle singolarmente, ma spesso troppo simili tra loro.

Era il classico caso in cui un ranking puro ottimizza la qualità locale ma non la copertura narrativa. Se cinque foto dello stesso scorcio o dello stesso momento ricevono voti alti, un algoritmo ingenuo tende a sceglierle tutte. Per costruire un album da condividere, invece, non basta premiare le immagini migliori: bisogna anche evitare la ripetizione.

Continua a leggere

OpenHuman: promesse grandi, prova sul campo deludente

Ho provato OpenHuman con l’idea di testare un progetto che, sulla carta, sembra voler portare gli agenti AI locali un passo più in là. Il risultato, però, è stato molto meno entusiasmante del racconto che accompagna il repository: installazione rapida, avvio instabile, integrazioni confuse e, alla fine, nessuna esperienza davvero solida da portare a casa.

La prova più interessante non è stata nemmeno il primo avvio fallito su Fedora in VM, ma il confronto tra ambienti diversi. Su una macchina fisica Windows con GPU, OpenHuman parte; appena si entra nel flusso di configurazione, però, emergono subito domande poco rassicuranti: login cloud richiesto, collegamento Gmail mediato da un servizio terzo, e una catena di dipendenze che rende il concetto di “locale” molto più sfumato di quanto il marketing lasci intendere.

Un progetto che promette molto

OpenHuman si presenta come un assistente personale AI locale, capace di integrarsi con servizi esterni, gestire memoria e collegarsi a modelli LLM sia in locale sia in cloud. Il pitch è forte: un agente “human-centric”, pronto a conoscersi in pochi minuti e a diventare parte del flusso di lavoro quotidiano.

Ed è proprio qui che nasce il problema. Più la promessa è ambiziosa, più ci si aspetta che il setup sia semplice, trasparente e affidabile. Invece la mia esperienza è stata l’opposto: ogni passo sembrava introdurre un nuovo livello di complessità, spesso non spiegato bene all’utente.

Fedora in VM: crash, errori e packaging fragile

Il primo test è stato su Fedora in macchina virtuale. Qui OpenHuman ha mostrato subito il suo lato più fragile. L’installazione è partita velocemente, ma all’avvio il programma non è riuscito a completare il bootstrap in modo stabile. I log hanno iniziato a restituire errori diversi a ogni tentativo, e questo è già di per sé un pessimo segnale.

Tra i messaggi più significativi c’erano:

textVMware: No 3D enabled

e soprattutto:

textError initializing NSS with a persistent database
version `NSSUTIL_3.108' not found
FATAL: nss_error=-5925

In pratica, il pacchetto distribuiva librerie incompatibili con quelle presenti sul sistema. Il risultato non era solo un crash, ma un crash dovuto a un conflitto abbastanza banale da sembrare quasi un errore di packaging elementare. Ho provato anche a forzare l’esecuzione con estrazione manuale dell’AppImage, variabili ambientali diverse e disabilitazione della GPU, ma senza successo.

A quel punto il problema non era più il singolo workaround: era il fatto che il software, su una configurazione abbastanza comune come Fedora in VM, falliva in modo ripetuto e poco affidabile.

Windows con GPU: parte, ma non convince

Su una macchina fisica Windows con GPU, OpenHuman si installa e si avvia. Questo però non ha risolto il mio giudizio, anzi lo ha reso più netto. La prima sorpresa è stata la richiesta di un login cloud già al primo avvio, cosa che stride parecchio con l’immagine di applicazione locale e privacy-oriented.

Poi è arrivata la richiesta di collegare Gmail attraverso un target chiamato Composio. Il problema non è solo tecnico, ma concettuale: non viene spiegato chiaramente perché un software che si presenta come locale debba passare da una terza parte esterna per accedere alle mail. Per me questa è una soglia di fiducia importante, e senza una spiegazione trasparente il risultato è un semplice “no”.

Skip sì, utilità poca

C’è un pulsante tipo “skip for now”, quindi in teoria si può andare avanti anche senza concedere tutto subito. In pratica bisogna insistere un po’, ma alla fine si entra davvero nell’app.

Il punto è un altro: se rifiuti di dare accesso a terze parti, OpenHuman resta davvero utile? Questa è la domanda centrale. Perché le funzioni più interessanti sembrano vivere proprio nel punto di incontro tra app locale, account cloud e servizi esterni. Se togli quella parte, resta un guscio molto meno significativo rispetto a quanto il progetto promette.

Ollama, Open WebUI e OpenRouter: altre prove fallite

A questo punto ho provato a portare il tutto sul terreno più favorevole possibile: accesso LLM locale via Ollama, poi Open WebUI come eventuale router/proxy, e infine OpenRouter per testare anche una strada cloud.

Il risultato è stato sempre negativo. Con Ollama non arrivava nessuna risposta in chat e ollama ps non mostrava modelli caricati. Con Open WebUI, usando impostazioni che con altre applicazioni funzionano correttamente, il backend restava silenzioso. Con OpenRouter non è cambiato nulla: le richieste non apparivano neppure nei log.

Questo è stato probabilmente il segnale più chiaro di tutti. Non si tratta di un singolo provider da sistemare o di una configurazione da rifinire. Il problema sembra stare nel modo in cui OpenHuman orchestra il tutto: integrazione, routing, backend, richieste. Se la pipeline non produce neppure tracce nei log, la sensazione è che la superficie sia più avanzata della sostanza.

Perché tante stelline?

La domanda, a questo punto, viene naturale: come fa un software così approssimativo a ottenere tante stelline su GitHub?

La risposta probabilmente non è misteriosa: oggi molti progetti AI vendono prima l’idea e solo dopo il prodotto. Bastano un README convincente, una roadmap ambiziosa, qualche schermata accattivante e un paio di video ben fatti per generare entusiasmo. In molti casi il pubblico non prova davvero il software in scenari normali, oppure lo fa per pochi minuti in condizioni ideali.

OpenHuman mi sembra rientrare proprio in questa categoria: molto forte sul piano narrativo, molto più debole nella prova concreta. E quando il marketing corre parecchio avanti rispetto alla maturità reale del codice, le stelline diventano un indicatore meno affidabile di quanto sembri.

Verdetto attuale

Per ora la valutazione è negativa. Non perché il progetto sia “senza idea”, ma perché l’idea è venduta come se fosse già matura, mentre nella pratica l’esperienza è fragile, poco trasparente e inadatta a un uso sereno.

Il test su Fedora in VM è fallito. Il test su Windows è partito ma ha introdotto dubbi sostanziali sulla privacy e sulle dipendenze cloud. I tentativi con Ollama, Open WebUI e OpenRouter non hanno migliorato il quadro. Il risultato complessivo è un software che promette molto, ma che al momento convince poco.

Disinstallerò OpenHuman e disconnetterò l’account. Per ora, almeno nel mio uso, resta un progetto interessante da osservare, ma non ancora uno strumento davvero affidabile.

Claude Code + Ollama/Qwen3.5

È possibile usare Claude Code con un modello locale — decisamente migliorato rispetto alle versioni precedenti — come Qwen3.5 per realizzare una piccola app Android senza scrivere una riga di codice?

L’impressione è che sì, si possa fare. Il modello configura tutto, scarica i framework, e dietro mio suggerimento si costruisce una lista di task da completare uno alla volta. Gli chiedo poi di riverificare il lavoro svolto, e in circa un quarto d’ora l’applicazione è pronta. In teoria.

Gli chiedo di riverificare tutto…

Il problema? Ha usato una versione del framework non ancora compatibile con Expo Go per i test diretti sul telefono. Da lì è partita una serie infinita di prompt di debug per abbassare la versione e aggiornare tutte le API interne, apparentemente diverse tra una release e l’altra.

Il risultato rimane comunque notevole, soprattutto considerando che tutto è generato da un modello da soli 9 miliardi di parametri, che gira su una scheda video nata per i videogiochi e tutt’altro che all’ultimo grido. Forse se non lo avessi forzato a passare dalla versione 55 alla 54 di React Native me la sarei cavata con meno litigi. Ma il limite vero sembra essere sempre lo stesso: la rifinitura del codice generato. O funziona subito, oppure ci vuole dieci volte il tempo che si impiegherebbe a scriverlo a mano.

Come piccolo aiuto ho agganciato Context7 come MCP server, per evitargli di allucinare le API dei framework — ma con successo solo parziale.

AI, N8N, Workflow, Agentic AI e LLM: Un’Introduzione al Futuro della Tecnologia

In questo articolo, esploreremo il ruolo chiave dell’intelligenza artificiale, N8N, i workflow, l’agentic AI e i modelli linguistici di grandi dimensioni (LLM) nel contesto tecnologico moderno. Questi argomenti rappresentano una combinazione potente che sta rivoluzionando il modo in cui sviluppiamo e utilizziamo le applicazioni.

Introduzione all’Intelligenza Artificiale e n8n

L’intelligenza artificiale (AI) sta trasformando il modo in cui creiamo e gestiamo i flussi di lavoro, e uno strumento che sta guadagnando attenzione è n8n. Questo strumento permette di costruire workflow complessi in modo visivo e intuitivo, integrando facilmente API e servizi esterni. Con l’avvento dell’Agentic AI, i workflow possono diventare autonomi, prendendo decisioni basate su dati e feedback in tempo reale. L’uso di LLM (Large Language Models) all’interno di questi workflow apre nuove possibilità, come l’analisi del testo, la generazione di contenuti e l’automazione intelligente. Questa combinazione di tecnologie promette di semplificare processi complessi, aumentando l’efficienza e riducendo il carico umano.

Intelligenza Artificiale e Workflow Dinamici

L’intelligenza artificiale (AI) sta rivoluzionando il modo in cui creiamo e gestiamo i workflow, grazie ad strumenti come n8n, una piattaforma open source che permette di costruire e automatizzare processi complessi. Con l’introduzione di agentic AI, i workflow non sono più semplici sequenze di istruzioni, ma diventano dinamici e adattivi, grazie all’uso di LLM (Large Language Models) che possono prendere decisioni autonome. Questo approccio consente di creare soluzioni personalizzate, scalabili e in grado di evolversi nel tempo.

L’intelligenza artificiale (AI) rappresenta una delle tecnologie più promettenti del nostro tempo

L’intelligenza artificiale (AI) rappresenta una delle tecnologie più promettenti del nostro tempo, con applicazioni che vanno dall’automazione al riconoscimento delle immagini. Uno strumento chiave per sfruttare al massimo le potenzialità dell’AI è n8n, una piattaforma open source che permette di creare workflow complessi senza la necessità di codificare. Questo strumento è particolarmente utile quando si lavora con l’AI agente, dove un modello linguistico di grandi dimensioni (LLM) esegue compiti autonomi e interagisce con altri sistemi. Il potere di n8n risiede nella sua capacità di integrare diversi strumenti e API, rendendo il processo di sviluppo più fluido e accessibile.

L’intelligenza artificiale (AI) sta trasformando il modo in cui creiamo e gestiamo i workflow

grazie a strumenti come n8n, una piattaforma open source che permette di collegare diversi servizi e applicazioni in modo semplice e intuitivo. In combinazione con l’AI, n8n permette di automatizzare compiti complessi, riducendo il tempo e gli errori umani. L’agente AI, un sistema autonomo in grado di prendere decisioni, può essere integrato nei workflow per eseguire compiti specifici, come l’analisi dei dati o la generazione di testi, grazie all’uso di modelli linguistici di grandi dimensioni (LLM). Questa sinergia tra AI, n8n, workflow e agente AI rappresenta un passo avanti significativo nell’automazione intelligente.

Conclusioni

L’AI, N8N, i workflow, l’agentic AI e i LLM stanno aprendo nuove possibilità nel mondo della tecnologia. Questi strumenti, quando utilizzati insieme, possono portare a un’evoluzione significativa in molti settori, rendendo il software più intelligente, personalizzato e adattabile.

Questo articolo, fin qua, e’ stato interamente scritto tramite AI e un workflow N8N, che a partire da un elenco di keyword ha generato il testo e pubblicato (in bozza) sul sito. Mi sono ispirato ad un workflow reso disponibile pubblicamente e modificato, come al solito, per usare ollama e per scrivere in italiano. L’idea e’ di adattarlo ulteriormente per partire da un testo o ancora meglio da una pagina web che mi ha interessato per generare un post, invece che dalle keyword. Se ne esce qualcosa di interessante pubblicherò il risultato.

AI Workflow 2.5

Modifiche:

  • Correzioni di bug vari
  • Gestito l’invio di messaggi multipli di telegram invece che fare un riassunto nel caso si eccedessero i 2000chr come nelle versioni precedenti, cosa che ha necessitato un po di programmazione
  • Aggiunto un riassunto delle informazioni dedotte della conversazioni su un documento su google drive
  • Corretto un bug che impediva al RAG di funzionare correttamente: lo step e’ stato diviso, prima con il reperimento delle informazioni, e poi con la generazione delle risposta
  • Integrato l’utilizzo delle API di Groq per una migliore velocità di esecuzione. Al momento non esegue tutto in locale, ma alcune task sono effettuate remotamente da Groq. L’utilizzo rientra ampiamente nel piano free, quindi senza costi. E’ comunque facilmente modificabile … sia per usare Groq per tutto (ma consiglio un piano developer per via dei limiti della dimensione del contesto del piano free) sia per usare solo un llm offerto localmente da Ollama

Coding agent con Ollama + Qwen3 + Continue – Parte 2

Alla fine l’ho provato, ottenendo sicuramente risultati migliori che i semplici completamenti di testo offerti da altri plugin.

Rispetto alla configurazione proposta ho utilizzato Qwen3:14b invece del MOE, anche per limiti di memoria a disposizione. Inoltre ho utilizzato Intellij IDEA in una macchina diversa da quella su cui risiede ollama. Cioè in realtà fisicamente sono la stessa ma una è una VM e l’altra è il ferro vero. Per rendere tutto piu divertente ho fatto passare le richiesta dal proxy di OpenWebUI, che è esposto su rete pubblica e che quindi richiede un token di autenticazione.

Rimaneggiata un po la configurazione:

Chiedo all’agente di generarmi una nuova semplice applicazione Spring Boot.

E lui parte a generarmi tutto perfettamente integrato con la IDE e scrivendo direttamente i file.

Dopodiché chiedo di cambiare il sistema di build da Maven a Gradle e di aggiungermi Swagger.

E dopo un paio di altri prompt per sistemare le cose ecco online il backend di una applicazione avendo scritto solo prompt e accettato il risultato:

Si tratta ovviamente di una micro applicazione, senza business logic rilevante e senza, al momento una UI. Farò altre prove in contesti un po più sfidanti ma per ora sono comunque abbastanza impressionato.

Coding agent con Ollama + Qwen3 + Continue – Parte 1

Quanto segue e’ la traduzione di Build a LOCAL AI Coding Assistant: Qwen3 + Ollama + Continue.dev (Blazing Fast & Fully Private!) … non ho ancora provato il setup ma son molto curioso e lo faro’ a breve.

Volevo condividere il mio percorso nell’utilizzare diversi assistenti AI per la programmazione — da GitHub Copilot a Cursor e ora a Windsurf — e come infine ho trovato il punto ideale passando a una soluzione completamente locale, senza compromettere velocità o qualità 🔥.
Vediamo insieme come ci sono arrivato:

💡 L’evoluzione del mio stack AI per la programmazione

  1. GitHub Copilot : Buon inizio, ma contesto limitato e non molto profondo.
  2. Cursor : Un notevole balzo in termini di potenza e flessibilità, specialmente grazie a Cursor Composer.
  3. Windsurf : Wow, questa mi ha impressionato! La sua capacità di indiciare e comprendere le basi di codice è eccezionale. Non è necessario dargli a conoscere i file da analizzare — semplicemente sa . Dai un’occhiata a lukalibre.org — interamente costruito con Windsurf 🤯Ma… c’è sempre un problema.

🛑 Il problema: Costo, velocità e limiti 😤

  • Windsurf costa 20 dollari al mese — prezzo equo per ciò che offre.
  • MA… ti limita a 500 crediti al mese, e la modalità di pensiero di Claude 3.7 utilizza 1,5 volte per ogni chiamata .
  • Anche pagando, a volte è lento ⏳.
  • Stessa storia con Cursor e Copilot.
  • E non iniziamo nemmeno a parlare delle preoccupazioni per la privacy dei dati — se la tua azienda non permette strumenti esterni, sei bloccato.

🚨 L’ingresso: Ollama + Continue.dev

Avevo pensato:

“Cosa succederebbe se potessi eseguire modelli potenti in locale?”
Così ho provato:

  • Ollama : Ospita LLM in locale (idea fantastica).
  • Continue.dev : Offre un’esperienza simile a quella di Cursor/Windsurf.

MA…

  • Modelli come Llama3 o Mistral non erano proprio all’altezza.
  • Sono pesanti e lenti sui laptop 💻➡️🐢

✨ Poi arrivò Qwen3: Alert di cambiamento di gioco 🎯💥

Ecco dove le cose si fecero veramente interessanti.
Qwen3 (soprattutto la variante 30b-a3b) mi ha lasciato a bocca aperta!

  • Utilizza distillazione + Mixture-of-Experts (MoE) → inferenza estremamente veloce.
  • Nonostante sia un modello da 30B, vengono utilizzati solo 3B di parametri per ogni prompt 🚀.
  • Le prestazioni? Strabiliantemente vicine a quelle di giganti come Claude 3.7 Sonnet e GPT-4o.
  • Funziona senza problemi su un laptop decente — testato su: i7 + RTX 2070Mac M4 Max

E il meglio di tutto: Nessuna perdita di dati, nessuna chiave API, nessuna attesa.

📌 Passo passo: Come impostare Qwen3 localmente con Continue.dev (Mac & Windows) 🖥️🛠️

Facciamolo insieme:

✅ Passo 1: Installare Ollama

Mac :

brew install ollama

Windows : Scaricare da: ollama.com/download

Avviare Ollama dopo l’installazione.

✅ Passo 2: Scaricare Qwen3 e modello di embedding

Nel terminale o in PowerShell:

ollama pull qwen3:30b-a3b

ollama pull nomic-embed-text

Perché questi modelli?

  • qwen3:30b-a3b: Il cervello principale AI 🧠 (gestisce chat, completamento automatico, modifiche).
  • nomic-embed-text: Aiuta l’AI a comprendere l’intera base di codice (spiegato di seguito ⬇️).

✅ Passo 3: Installare l’estensione Continue.dev in VS Code

  1. Apri VS Code.
  2. Vai alle Estensioni (icona 🔍 nel lato sinistro).
  3. Cerca “Continue”.
  4. Clicca su Installa.

✅ Passo 4: Configurare Continue per utilizzare Qwen3

  1. In VS Code, vai alla scheda Continue (icona 🧠).
  2. Clicca sull’icona ingranaggio ⚙️ > Apri Configurazione.
  3. Sostituisci la configurazione predefinita con questa:
name: Local Assistant  
version: 1.0.0
schema: v1
models:
- name: Qwen3-30b
provider: ollama
model: qwen3:30b-a3b
roles:
- chat
- edit
- autocomplete
- apply
- summarize
- name: embeddingsProvider
provider: ollama
model: nomic-embed-text
roles:
- embed
context:
- provider: code
- provider: docs
- provider: diff
- provider: terminal
- provider: problems
- provider: folder
- provider: codebase

🔍 Cosa fa ogni parte del YAML

models:

Definisce i “cervelli” del tuo assistente.

  • Qwen3–30b
  • embeddingsProvider

context:

Dichiara a cosa può accedere l’AI quando risolve problemi:

  • codice: File corrente.
  • docs: Documentazione (come i README).
  • diff: Cambiamenti Git.
  • terminal: Output del terminale (per il debug).
  • problems: Errori del linter.
  • folder: Cartella intera del progetto.
  • codebase: Indice completo della base di codice (grazie al modello di embedding!).

Senza questo, il tuo assistente vedrebbe solo il file che stai modificando — come cercare di riparare un motore di un’auto senza vedere l’intera auto 🚗.

✅ Passo 5: Finito! 🎉

Ora hai un assistente AI per la programmazione locale che è:

  • 🔒 Privato (nessuna perdita di dati)
  • ⚡ Veloce (eseguito sul tuo computer)
  • 💪 Potente (si confronta con GPT-4o/Claude 3.7)
  • 🌐 Pronto per l’offline

📌 Pensieri finali

Se sei stanco di pagare per token limitati, risposte lente o vuoi il pieno controllo sul tuo codice e i tuoi dati, prova Qwen3 + Ollama + Continue.dev.
È stato un cambiamento di gioco per me 🧠✨, e spero che ti aiuti anche tu.

Workflow AI, un altro caso d’uso

Credo che sta cosa mi stia sfuggendo di mano. Ho messo insieme un po’ tutto. Riconoscimento vocale, chatbot potenziato con rag, embedding, sintesi della risposta e sintesi vocale in uscita.

Risultato: una assistente personale a portata di messaggistica istantanea con due tipi di memoria, una a breve termine per sostenere efficacemente una conversazione, e una a lungo termine supportata dal RAG. L’embedding si attiva inserendo nel messaggio di input una parola chiave. Il sistema inoltre risponde (anche) a voce se l’interazione iniziale avviene mediante voce o solo scritto se l’interazione e’ stata iniziata in forma testuale.

Lo utilzzero’ davvero? Non lo so, ma potrebbe essere che si … specie per via della memoria a lungo termine, in modo che posso di fatto prendere appunti velocemente e poi poterci accedere in modo altrettanto facile e veloce.

Intanto il trascrittore di vocali, nato per provare, l’ho usato varie volte.

Il tutto, come negli esempi precedenti, e’ selfhosted. Utilizzo:

© 2026 b0sh.net

Tema di Anders NorenSu ↑