Confronto tra un sistema Knowledge Base AI ed uno Help Desk AI

Dialogo con Gemini.

Un sistema Knowledge Base (KB) AI e un sistema Help Desk AI sono due pilastri fondamentali della gestione del supporto e della conoscenza, ma rispondono a esigenze, flussi di lavoro e utenti target diversi.

Per dirla in modo semplice: la KB AI è il “cervello” (dove la conoscenza risiede ed viene elaborata), mentre l’Help Desk AI è il “braccio operativo” (che gestisce le interazioni, le pratiche e le risoluzioni).

Ecco un confronto dettagliato per punti chiave:

📊 Confronto Diretto

Caratteristica	Knowledge Base (KB) AI	Help Desk AI
Focus Principale	Gestione, organizzazione e reperimento del sapere aziendale.	Gestione dei flussi di supporto, ticket e risoluzione problemi.
Utente Finale	Interno (dipendenti, tecnici, team) e Esterno (self-service per clienti).	Operatori di supporto (agenti) e Utenti finali con problemi specifici.
Input Tipico	Documenti, procedure, FAQ, manuali, note tecniche, codici.	Ticket di supporto, chat, email, segnalazioni di bug, richieste di servizio.
Output / Azione	Risposte sintetiche, riassunti, riferimenti a documenti fonte.	Automazione di azioni (es. reset password), instradamento ticket, risposte dirette.
Interazione	Conversazionale / Ricerca semantica (“Come si configura X?”).	Transazionale / Sequenziale (“Apri un ticket per Y”, “Aggiorna lo stato di Z”).

🧠 1. Knowledge Base (KB) AI

Un sistema KB potenziato dall’IA non si limita a cercare parole chiave, ma comprende il contesto e il significato delle domande (tramite tecniche come RAG – Retrieval-Augmented Generation).

Scopo: Trasformare grandi volumi di dati non strutturati (PDF, wiki, documenti Word, manuali) in una fonte unica e interrogabile di verità.
Caratteristiche principali:
- Ricerca semantica: Trova informazioni anche se l’utente usa termini diversi da quelli presenti nei documenti.
- Sintesi automatica: Estrae e riassume la risposta esatta anziché restituire semplicemente un link a un file di 50 pagine.
- Manutenzione predittiva del sapere: Segnala contenuti obsoleti, contraddizioni tra documenti o lacune nelle informazioni.

🛠️ 2. Help Desk AI

Un Help Desk AI gestisce l’intero ciclo di vita di una richiesta di assistenza, integrando spesso automazione dei processi (workflow automation) e agenti conversazionali.

Scopo: Ottimizzare, velocizzare e (ove possibile) automatizzare la risoluzione di problemi o richieste degli utenti.
Caratteristiche principali:
- Triage e instradamento automatico: Classifica i ticket in arrivo per priorità/categoria e li assegna all’operatore o team più adatto.
- Copilota per l’operatore: Suggerisce agli agenti le risposte da dare o le azioni da intraprendere per chiudere più velocemente la segnalazione.
- Automazione operativa: Esegue azioni pratiche sui sistemi aziendali (integrazione via API con CRM, ERP, gestionali).

🔗 Come Lavorano Insieme (La Sinergia)

In un’architettura moderna, questi due sistemi non si escludono, ma si completano:

L’utente invia una richiesta all’Help Desk AI.
L’Help Desk AI interroga la Knowledge Base AI sottostante per verificare se esiste già una soluzione documentata.
Se la KB AI ha la risposta, l’Help Desk risolve la richiesta in autonomia (Self-Service / Deflection).
Se la richiesta richiede un intervento umano o un’azione sui sistemi, l’Help Desk crea il ticket, lo arricchisce con il contesto recuperato dalla KB e lo assegna al tecnico competente.

Ma un utente non può interrogare direttamente un sistema PG Vector con AI?

Certamente, tecnicamente è assolutamente possibile: un utente può interrogare direttamente un database vettoriale (come PostgreSQL con l’estensione pgvector) abbinato a un modello di linguaggio (LLM) tramite un’architettura RAG (Retrieval-Augmented Generation).

Anzi, se stai realizzando un’applicazione custom o un microservizio, questo è proprio l’impianto architetturale di base.

Tuttavia, la differenza tra interrogare direttamente un’infrastruttura RAG (PG Vector + LLM) e usare un sistema Knowledge Base AI o Help Desk AI completo risiede in tutto ciò che sta intorno alla semplice ricerca vettoriale: il cosiddetto “strato applicativo” ed enterprise.

Ecco un confronto su cosa cambia tra le due opzioni:

🛠️ PG Vector + AI (L’Infrastruttura / Il “Motore”)

Quando un utente interroga direttamente un pipeline RAG basato su PG Vector, il flusso è puramente matematico/linguistico:

La query dell’utente viene trasformata in un embedding.
Si esegue una ricerca di similarità (es. cosine distance o L2) su PG Vector.
I k chunk più rilevanti vengono passati nel contesto dell’LLM.
L’LLM genera la risposta.

Vantaggi:

Controllo totale: Decidi tu le strategie di chunking, i modelli di embedding, le metriche di distanza, la gestione dei prompt.
Nessun lock-in di terze parti: La conoscenza resta nel tuo database relazionale/vettoriale (es. PostgreSQL).
Costi e Privacy: Può girare completamente on-premise o su infrastruttura proprietaria.

🏢 KB AI o Help Desk AI (L’Applicazione Completa)

Un sistema KB o Help Desk SaaS/Enterprise spesso usa proprio un database vettoriale come PG Vector sotto il cofano, ma vi costruisce sopra un’intera suite di funzionalità gestionali necessarie in produzione:

Funzionalità	Solo PG Vector + AI (Custom)	Sistema KB AI / Help Desk AI completo
ACL & Permessi	Devi implementare a mano il filtro dei vettori in base ai ruoli utente.	Gestione nativa dei permessi (es. l’utente X non deve vedere i documenti riservati a Y).
Ingestion & Sync	Devi scrivere script/ETL per convertire PDF, file Office o pagine web in vettori.	Connettori automatici pronti all’uso (Drive, Notion, SharePoint, Zendesk, ecc.) e sync periodico.
Valutazione e Feedback	Devi creare tabelle per tracciare i “thumbs up/down” e le allucinazioni.	Dashboard di analytics su query senza risposta, gradimento degli utenti e lacune nella documentazione.
Gestione dello Stato	È una chat / API “stateless” o limitata al contesto.	Gestione di ticket, cicli di vita dell’assistenza, SLA, escalation a un operatore umano, audit log.
Hybrid Search / Re-ranking	Devi implementarlo manualmente (es. combinare `pg_trgm` / FTS di Postgres con `pgvector` e un modello di Cross-Encoder).	Algoritmi di ricerca ibrida e re-ranking spesso già ottimizzati out-of-the-box.

💡 In Sintesi

PG Vector + AI è l’edificio grezzo: perfetto se stai sviluppando una soluzione personalizzata, vuoi integrare la ricerca semantica in un software esistente o hai requisiti stringenti di privacy e controllo tecnico.
KB AI / Help Desk AI è l’appartamento chiavi in mano: include l’interfaccia utente, la gestione degli accessi, le integrazioni con i canali di comunicazione (email, WhatsApp, webchat) e i flussi operativi di supporto.

Puoi fare una stima della differenza di costi?

Fare una stima dei costi richiede di dividere lo scenario in due grandi famiglie: Soluzioni SaaS commerciali “chiavi in mano” (Zendesk, Intercom, Freshdesk) e la soluzione Custom On-Premise/Cloud proprietario (PG Vector + LLM + RAG).

Le dinamiche economiche, le voci di spesa e la scalabilità dei due approcci cambiano radicalmente.

1. Soluzioni SaaS (Help Desk AI / KB Enterprise)

Le piattaforme SaaS applicano generalmente un modello di costo basato sulle licenze per utente/agente al mese a cui si aggiungono i consumi per le risoluzioni/interazioni AI.

Voci di Costo Tipiche:

Licenza base: Da 19€ a 115€+ al mese per ogni agente di supporto.
Add-on AI / Copilot: Circa 29€ – 50€ al mese per agente. Zendesk
Consumo AI Agents (per risoluzione): Spesso pacchetti extra (es. ~49$ ogni 100 sessioni/risoluzioni riuscite via bot). Pluno AI

Stima Economica (Azienda Media – 10 Agenti di Supporto):

Tipologia	Costo Mensile Medio
Piattaforma Base (10 utenti)	~500€ – 1.150€ / mese
Add-on AI Copilot (10 utenti)	~300€ – 500€ / mese
Volume query AI (es. 2.000 risoluzioni/mo)	~500€ – 1.000€ / mese
TOTALE STIMATO	~1.300€ – 2.650€ / mese

Pro: Nessun costo iniziale di sviluppo, setup rapido, manutenzione a carico del vendor.
Contro: Il costo cresce in modo lineare con il numero di dipendenti e il volume di ticket.

2. Soluzione Custom (PG Vector + LLM + Pipeline RAG)

Con una soluzione custom, il modello economico si sposta dal pagamento “per licenza utente” a costi di infrastruttura, chiamate API e sviluppo/manutenzione.

Voci di Costo Tipiche:

Database & Compute: PostgreSQL con pgvector su un server dedicato/cloud (es. AWS RDS, Hetzner, VPS dedicato): da 20€ a 200€/mese a seconda delle dimensioni degli indici e dei vettori. OMC Cloud
Modelli di Embedding: (es. OpenAI text-embedding-3 o modelli locali): Trascurabile (< 10€ – 50€/mese per milioni di token). AlphaCorp AI
Inference LLM: OMC Cloud
- Con API esterne (OpenAI/Anthropic): Da pochi centesimi a ~0.002€ per risposta. Per 10.000 query/mese si parla di 50€ – 200€/mese.
- Con LLM Locale (Ollama / VLLM on-premise): Il costo dell’hardware GPU (es. server con RTX 4090 / A10G o server dedicato con GPU): ~150€ – 400€/mese fissi, indipendentemente dal numero di query.
Costo di Sviluppo (Una tantum): Creazione dell’architettura RAG, API, gestione permessi e UI: tipicamente da 5.000€ a 15.000€+ (se esternalizzato).

Stima Economica (Manutenzione & Esercizio Eseguiti In-House):

Tipologia	Costo Mensile Medio
Infrastruttura (Postgres + Cloud Compute)	~50€ – 150€ / mese
Inference LLM (API o Server GPU)	~100€ – 300€ / mese
Manutenzione e Monitoraggio	Quota di lavoro/tempo interno
TOTALE RECORRENTE (OPEX)	~150€ – 450€ / mese

📊 Sintesi e Confronto Strategico

Paramentro	SaaS Help Desk AI	Custom (PG Vector + AI)
Costo iniziale (CapEx)	Basso / Nullo	Medio-Alto (tempo di sviluppo o dev esterna).
Costo ricorrente (OpEx)	Alto e scalabile sui numeri (costo per utente/ticket).	Molto Basso e quasi indipendente dal numero di utenti.
Flessibilità e Controllo	Limitata alle integrazioni previste dal vendor.	Assoluta (scelta modelli, sovranità dei dati, RAG custom).
Break-Even Point	Conveniente per piccoli team o brevi periodi.	Diventa nettamente più conveniente se si hanno molti utenti/interrogazioni o competenze interne per la gestione.

In sintesi: Se l’obiettivo è avere un sistema operativo in 48 ore senza gestire codice o infrastruttura, il SaaS vince, ma si paga un “premio” mensile significativo. Se si hanno competenze di sviluppo interne e l’esigenza di interrogare la base di conoscenza da parte di decine o centinaia di utenti (senza voler pagare licenze per-head), un’architettura basata su PostgreSQL + pgvector e RAG riduce i costi operativi ricorrenti anche dell’80-90%.

Come si possono costruire le GUI utente con PG RAV ?

I modelli AI o i database vettoriali non espongono alcuna GUI (interfaccia grafica).

Se con “PG RAG” intendi un’architettura RAG (Retrieval-Augmented Generation) basata su PostgreSQL + pgvector e modelli di intelligenza artificiale, né la base dati né il modello LLM/Embedding forniscono interfacce utente.

Ecco esattamente come si dividono i ruoli e chi fa cosa in un’architettura di questo tipo:

1. Cosa espongono i singoli componenti

PostgreSQL + pgvector (Il Database): Espone solo la classica porta TCP (5432) per le connessioni SQL standard e la gestione delle query vettoriali (es. distanza coseno <-> o L2).
Il Modello AI / LLM (es. Ollama, VLLM, OpenAI API): Espone esclusivamente un’API di backend (solitamente endpoint REST / HTTP o gRPC).
- Riceve JSON con il prompt e restituisce JSON con il testo generato.
- Non sa cosa sia un bottone, un form o una finestra di chat.

2. Chi si occupa della GUI? (Lo “Strato Applicativo”)

La GUI deve essere costruita o integrata da parte a parte mediante un middleware o un framework dedicato.

Ci sono tre modi principali per gestire la GUI in questo scenario:

A. Soluzioni No-Code / Orchestratori con GUI Nativa

Se usi strumenti di orchestrazione AI, questi mettono a disposizione interfacce grafiche già pronti sia per la gestione del flusso che per la chat con l’utente finale:

Flowise / Langflow: Permettono di collegare visivamente i blocchi (Postgres pgvector + LLM) e offrono un widget chat integrabile via iframe o JavaScript.
Open WebUI: Un’interfaccia stile ChatGPT che si collega direttamente alle API dell’LLM (es. Ollama) o a backend RAG custom.
Dify / AnythingLLM: Piattaforme complete che gestiscono l’ingestione su PG Vector e la UI finale per l’utente.

B. Sviluppo di una GUI Custom (Full-Stack)

Se stai sviluppando un’applicazione proprietaria:

Backend: Un’applicazione (in Python con FastAPI/LangChain, Node.js, Go, ecc.) riceve l’input dalla UI, esegue la query vettoriale su Postgres, invia il contesto all’LLM e recupera il risultato. Red Hat
Frontend: Una UI moderna (React, Vue, Svelte, Tailwind) gestisce la schermata di chat, l’invio dei file, la gestione dei ruoli e gli eventuali feedback (thumbs up/down).

⚙️ In Sintesi: La Struttura dell’Architettura

Plaintext

[ Utente Finale ]
       │
       ▼ (Interfaccia Grafica - Web / App / Chatbot)
[ GUI / Frontend ] 
       │
       ▼ (API REST / WebSocket)
[ Backend Middleware ]  ───► (Calcola Embedding) ───► [ Modello Embedding ]
       │
       ├────────────────► (Ricerca Vettoriale SQL) ───► [ Postgres (pgvector) ]
       │
       └────────────────► (Prompt + Contesto) ───────► [ LLM (es. Ollama / API) ]

Senza lo strato di Frontend + Backend (Middleware), i modelli AI e PostgreSQL restano semplici servizi di calcolo ed esecuzione da riga di comando o via codice.

Ma potrebbe andar bene una GUI come questa tua per l’utente. Come realizzarla?

Certamente! L’interfaccia tipo ChatGPT / Claude / Gemini è diventata lo standard de facto per l’interazione conversazionale: è pulita, familiare per gli utenti e ideale per visualizzare risposte strutturate (testo, elenchi, tabelle, blocchi di codice).

Per realizzare un’interfaccia di questo tipo collegata al tuo backend Postgres (pgvector) + LLM, hai due strade principali: usare progetti open-source pronti all’uso oppure crearla su misura (Custom).

1. Soluzione Veloce: Usare GUI Open-Source Pronte

Se vuoi evitare di programmare da zero la parte di frontend, esistono ottimi progetti open-source con un’estetica identica a questa e già predisposti per connettersi ad architetture RAG:

Open WebUI: Nativamente modellata sul layout di ChatGPT. Supporta la gestione utenti, lo storico chat, il caricamento di documenti e si integra direttamente con Ollama, API compatibili OpenAI e sistemi RAG.
AnythingLLM: Un’applicazione completa (disponibile sia web che desktop) con un’interfaccia molto pulita che gestisce nativamente la connessione a PostgreSQL / pgvector e a diversi provider LLM.
Lobe Chat: Un’interfaccia utente visivamente eccellente e moderna, estendibile tramite plugin e con supporto nativo per agenti e fonti dati.

2. Soluzione Custom: Sviluppare la UI da Zero

Se vuoi integrare la chat all’interno di un software esistente o avere un controllo totale sull’esperienza utente, lo stack di riferimento oggi si basa su componenti web moderni.

Lo Stack Tecnologico Consigliato:

Frontend Framework: React, Next.js o SvelteKit.
Libreria Componenti: shadcn/ui o Tailwind CSS (forniscono componenti per la chat, bolle di testo e sidebar già stilizzati).
Gestione dello Streaming: Vercel AI SDK (fondamentale per mostrare il testo in tempo reale mentre l’LLM genera la risposta, esattamente come accade qui).
Rendering del Testo: Librerie di gestione Markdown (es. react-markdown + remark-math per le formule LaTeX o prismjs per il syntax highlighting del codice).

📐 Come Funziona il Flusso Tecnico

Per ottenere l’effetto di digitazione in tempo reale (“streaming”) tipico di queste GUI, la comunicazione tra la UI e il tuo backend non usa semplici richieste HTTP tradizionali, ma Server-Sent Events (SSE) o WebSockets.

Plaintext

[ GUI React/Next.js ]
       │
       │ 1. Invio messaggio (POST /api/chat)
       ▼
[ Backend (Node.js / Python) ]
       │
       ├─► 2. Calcola embedding & Interroga Postgres (`pgvector`)
       │
       ├─► 3. Invia Prompt + Contesto RAG all'LLM
       │
       │ 4. Risposta in Streaming (SSE) punto per punto
       ▼
[ GUI renderizza il testo in tempo reale ]

Esempio Pratico (Con Vercel AI SDK su Frontend React)

Se utilizzi Next.js/React, librerie come la ai/react di Vercel gestiscono l’intero stato della conversazione con poche righe di codice:

TypeScript

'use client';
import { useChat } from 'ai/react';

export default function Chat() {
  // useChat gestisce automaticamente input, messaggi, invio e streaming
  const { messages, input, handleInputChange, handleSubmit } = useChat({
    api: '/api/chat', // Il tuo endpoint backend
  });

  return (
    <div className="flex flex-col h-screen max-w-2xl mx-auto p-4">
      {/* Area dei Messaggi */}
      <div className="flex-1 overflow-y-auto space-y-4 mb-4">
        {messages.map(m => (
          <div key={m.id} className={`p-4 rounded-lg ${m.role === 'user' ? 'bg-blue-100 ml-auto' : 'bg-gray-100'}`}>
            <span className="font-bold">{m.role === 'user' ? 'Tu: ' : 'AI: '}</span>
            {m.content}
          </div>
        ))}
      </div>

      {/* Form di Input */}
      <form onSubmit={handleSubmit} className="flex gap-2">
        <input
          value={input}
          onChange={handleInputChange}
          placeholder="Fai una domanda alla Knowledge Base..."
          className="flex-1 p-2 border border-gray-300 rounded-md"
        />
        <button type="submit" className="px-4 py-2 bg-blue-600 text-white rounded-md">
          Invia
        </button>
      </form>
    </div>
  );
}

🎯 Elementi Chiave per un’Ottima UX Conversazionale

Se decidi di realizzarla, ci sono 4 dettagli che fanno la differenza per l’utente finale:

Indicatore di Sorgente (Citations): Quando la risposta proviene da un documento recuperato tramite pgvector, mostra dei badge cliccabili in fondo alla risposta con i riferimenti (es. [Documento_A.pdf - Pagina 3]).
Streaming fluido: Evita di far attendere l’utente con uno spinner per 5 secondi; mostra la risposta parola per parola non appena l’LLM inizia a generare.
Gestione del Contesto: Permetti all’utente di creare nuove sessioni (“Nuova Chat”) per azzerare la memoria a breve termine.
Feedback dell’Utente: Inserisci i bottoni 👍 / 👎 per raccogliere dati utili a migliorare il sistema RAG e identificare eventuali allucinazioni del modello.

E come permettere all’utente lo scambio file nei due versi?

Lo scambio di file bidirezionale (Upload dall’utente al sistema e Download/Visualizzazione dal sistema all’utente) è uno degli elementi chiave per un’interfaccia RAG avanzata.

Ecco come implementare tecnicamente entrambi i flussi all’interno dell’architettura GUI + Backend + Postgres (pgvector).

📥 1. Flusso UTENTE ➔ SISTEMA (Upload & Ingestion)

L’utente trascina o seleziona un file nella chat (es. PDF, DOCX, CSV) per aggiungerlo alla Knowledge Base o per fare domande su quel file specifico.

A. Lato Frontend (GUI)

Si inserisce un bottone “Graffetta” 📎 o un’area di Drag & Drop.
Quando l’utente seleziona il file, il frontend invia una richiesta POST /api/upload (usando FormData / multipart/form-data).
La GUI mostra una barra di avanzamento o uno stato “Elaborazione documento in corso…”.

B. Lato Backend (Pipeline di Ingestion)

Quando il server riceve il file, esegue una pipeline automatica:

Parsing: Estrae il testo grezzo dal file (es. usa pypdf per i PDF, python-docx per Word, pandas per i CSV).
Chunking: Divide il testo in blocchi più piccoli (es. 500-1000 caratteri).
Embedding: Invia i chunk al modello di embedding per generare i vettori.
Salvataggio in Postgres (pgvector): Inserisce i vettori e il testo nel database insieme ai metadati:
- file_id e file_name
- user_id (per isolare i documenti tra utenti diversi)
- page_number o offset del testo

📤 2. Flusso SISTEMA ➔ UTENTE (Download & Citazioni)

Quando l’AI risponde citando un documento, l’utente deve poter fare clic sulla fonte per scaricarla, visualizzarla o aprire la pagina esatta.

A. Memorizzazione dei File Originali

Non salvare mai i file interi direttamente dentro PostgreSQL come BLOB. La scelta migliore è usare uno Storage ad Oggetti:

Cloud: AWS S3, Google Cloud Storage, Azure Blob Storage.
On-Premise / Self-Hosted: MinIO (un server S3-compatibile open source).

In Postgres salverai solo il percorso o l’URL del file salvato su MinIO/S3.

B. Come il Backend invia il File / Link alla GUI

Quando l’LLM genera la risposta basandosi su pgvector, il backend associa alla risposta i metadati dei chunk utilizzati.
Il backend genera un URL sicuro temporaneo (es. S3 Presigned URL con scadenza a 15 minuti) o un endpoint API dedicato (es. /api/files/download/123).
Nella risposta JSON inviata alla GUI, il backend include la citazione con il relativo link:

JSON

{
  "role": "assistant",
  "content": "La procedura di rimborso prevede un preavviso di 5 giorni lavorativi.",
  "sources": [
    {
      "document_name": "Regolamento_Interno_2026.pdf",
      "page": 12,
      "download_url": "https://api.tuadominio.com/api/files/download/abc-123"
    }
  ]
}

C. Visualizzazione nella GUI

Nel frontend, rendi le fonti interattive:

Badge o Carte Scaricabili: Sotto la risposta dell’AI, mostra dei chip o box cliccabili con icona PDF.
Anteprima Integrata (PDF Viewer): Se l’utente clicca sulla citazione, anziché scaricare subito il file, puoi aprire un pannello laterale (es. usando react-pdf o un iframe) che mostra il PDF evidenziando direttamente la pagina o il testo citato.

🏗️ Architettura Globale dello Scambio File

Plaintext

                               ┌─────────────────────────────────────────┐
                               │             STORAGE OGGETTI             │
                               │          (AWS S3 / MinIO Local)         │
                               └────────────────────┬────────────────────┘
                                                    │
                                     (Salva file)   │   (Genera Link Download)
                                     ┌──────────────┴──────────────┐
                                     │                             ▼
[ UTENTE ] ──(Upload File)──► [ BACKEND API ] ──(Estrae & Vettorizza)──► [ Postgres + pgvector ]
    ▲                                │                                           │
    │                                │ (Invia Prompt + Contesto RAG)              │
    │                                ▼                                           │
    └──────────(Risposta + Link)── [ LLM ] ◄─────────────────────────────────────┘

🔒 Sicurezza e Best Practices per la Gestione File

Autenticazione e Permessi (ACL): Assicurati che ogni riga inserita su Postgres con pgvector abbia una colonna user_id o team_id. Quando si fa la ricerca vettoriale, applica sempre un filtro SQL (WHERE user_id = current_user) per evitare che un utente possa interrogar o scaricare i file di qualcun altro.
Validazione dei File: Filtra le estensioni consentite in fase di upload per evitare rischi di sicurezza e imposta un limite massimo di dimensione (es. max 25MB per file).
Pulizia e Asincronia: Il processo di parsing e vettorizzazione di file di grandi dimensioni può richiedere diversi secondi. È consigliabile gestirlo in background tramite code di lavoro (es. Celery in Python o BullMQ in Node.js) inviando una notifica alla GUI al termine del caricamento.