Assistente vocale e knowledge base

Case study · Voice · RAG

Assistente vocale con knowledge base aziendale

STT, orchestrazione agenti e vector store su PostgreSQL: pipeline end-to-end con SDK audio intercambiabili.

Consulenza AI

In sintesi

  • PostgresVectorStore<TDocument> con EF Core, pgvector, IEmbeddingGenerator.
  • Worker news/RSS, enrichment, embedding in background.
  • Agenti Microsoft Agents AI (Conversation, Memory, Orchestrator, …).
  • Moduli Purple.Sdk.AI.Audio.* (Whisper, DeepGram, ElevenLabs, Windows Speech).

Architettura

[Mic] → STT → Orchestrator → VectorStore (pgvector) + Tool → TTS → Output

Snippet (concetto)

if (document.Embedding == null || document.Embedding.Length == 0)
    document.Embedding = await GenerateEmbeddingAsync(document.Content, ct);
if (_options.NormalizeVectors)
    document.Embedding = NormalizeVector(document.Embedding);

FAQ

On-prem possibile?

Sì per componenti (Ollama, Whisper locale) in base a vincoli di rete e licenze.

Cosa serve sul DB?

PostgreSQL con vector e indici adeguati al carico.

Fonti

Agent Framework .NET · Embeddings & pgvector

Pipeline vocale end-to-end

L’audio entra in STT, il testo alimenta orchestratori e tool (API, database, knowledge store), la risposta esce in TTS. Latenza percepita, barge-in e conferme vocali sono parte del prodotto, non optional. In ambienti industriali servono test con rumore reale e microfoni adeguati.

Contesto operativo e tracciabilità

Ogni sessione può generare log testuali e metadati (durata, intent, esito tool). Definite retention e accessi come per altri sistemi aziendali. Le conversazioni possono contenere comandi operativi: segregate ambienti di test da produzione per evitare azioni accidentali su sistemi reali.

Chunking e sovrapposizione

La segmentazione del testo influenza recall e precisione: chunk troppo grandi diluiscono il segnale semantico; troppo piccoli perdono contesto. Spesso si usa sovrapposizione controllata tra chunk adiacenti e metadati (numero articolo, rubrica, data di pubblicazione) per filtri SQL pre-vector.

Enrichment controllato

Gli worker di enrichment possono estrarre entità o riassunti con LLM. Va definito cosa resta persistito e cosa è volatile, per costi e privacy. Separare job di enrich da job di embed consente di ricalcolare vettori senza ripagare arricchimenti già validati.

Indici e prestazioni

Con volumi elevati, IVFFlat o HNSW su pgvector richiedono tuning di liste e parametri di costruzione. Monitorate tempi di build indice durante finestre di manutenzione. Query ibride (filtro relazionale + top-k vettoriale) devono usare piani verificati con dati realistici.

Orchestrazione agenti

Gli agenti possono scomporre domande complesse in sotto-query su sotto-corpus. Serve limite di passi, timeout e budget token per evitare loop costosi. I tool esposti agli agenti devono essere idempotenti dove possibile e loggati.

Allucinazioni e mitigazione

Anche con buon retrieval, il modello può sintetizzare oltre il testo recuperato. Tecniche includono citazioni obbligate, temperature basse, refusal templates e validazione post-gen su presenza di span nei chunk. Il business deve accettare che “non so” sia risposta legittima.

Costi operativi

Embed in batch ammortizzano chiamate rispetto a embed on-the-fly su ogni aggiornamento minore. Cache di query ripetute e deduplica documenti identici riducono storage. Confrontate costo storage vettoriale vs costo re-indicizzazione frequente.

Sicurezza e segregazione

Database dedicati o schema separati per ambienti dev/staging/prod. Ruoli PostgreSQL limitati ai soli comandi necessari per worker e API. Backup crittografati e test di restore periodici.

Test e qualità

Set di domande golden con risposta attesa e fonti attese. Regressioni dopo cambio modello embedding o LLM. Valutazione umana campionata su nuovi tipi di domanda prima di ampliare utenza.

Estensibilità

Nuove fonti documentali richiedono mapping schema e policy di aggiornamento. Prevedete adapter per formati (HTML, PDF testo, DOCX) e normalizzazione Unicode.

Handover

Documentate come rilanciare worker, come verificare lunghezza code, come invalidare cache semantica. Il cliente deve poter operare in emergenza anche senza il fornitore in videochiamata.

Multi-tenant e isolamento

Se più clienti condividono piattaforma, isolamento logico per schema o database è preferibile a semplice filtro applicativo. Ogni tenant ha quote storage e rate limit distinti per evitare effetto noisy neighbor su indici vettoriali.

Localizzazione contenuti

Documenti bilingui richiedono strategia di lingua nel retrieval: stesso embedding multilingue o modelli separati per lingua con routing esplicito nella domanda.

Disaster recovery

Backup PostgreSQL includono estensione pgvector. Testate restore in ambiente isolato e tempo di ricostruzione indici grandi. Pianificate finestra di manutenzione per rebuild dopo disaster.

Osservabilità e operatività

Metriche su latenza p50/p95, tasso errore, profondità code e costo stimato per richiesta dovrebbero essere visibili in dashboard dedicate prima che il business se ne accorga per telefono. Alert su soglie anomale devono avere runbook: chi guarda, cosa riavviare, quando escalation. Includete exporter compatibili con lo stack già usato dal cliente (Prometheus, Azure Monitor, altro).

Gestione segreti e rotazione

Chiavi API, stringhe di database e certificati restano in vault o variabili d’ambiente gestite, mai in repository. Pianificate rotazione periodica e procedure d’emergenza in caso di leak. Documentate quali servizi terzi ricevono quali segreti e con quali scope minimi.

Test di carico e caos controllato

Prima del go-live, simulare picchi di richieste e timeout di dipendenze esterne. Verificate degradazione controllata: code, circuit breaker, messaggi utente comprensibili. Il caos in produzione arriva da sé; meglio provarlo in staging.

Conformità e dati personali

Mappate flussi PII attraverso embedding, log e backup. Allineate retention a policy aziendale e GDPR. Se usate fornitori extra-UE, verificate SCC e trasferimenti. Il reparto legale del cliente deve ricevere diagramma semplificato dei flussi.

Documentazione e formazione handover

Consegnate architettura logica, istruzioni di deploy, checklist incident e contatti escalation. Una sessione di training registrata (se consentita) riduce dipendenza da singole persone. Aggiornate documentazione quando cambiate versione modello o schema DB.

Evolutività

Prevedete punti di estensione: nuovi template, nuovi corpus, nuovi tool per agenti. Evitate fork non mergeabili del codice core. Usate feature flag per abilitare gradualmente capacità a sottoinsiemi di utenti.

Collaborazione con il cliente

Coinvolgete early il team operations del cliente: conoscono finestre di deploy, blackout e vincoli di change management. Una roadmap condivisa evita sorprese quando il fornitore LLM annuncia deprecation o quando il cliente deve congelare rilasci per audit.

Chiusura e lesson learned

Dopo go-live, tenete retrospettiva su cosa ha funzionato in discovery e cosa no. Documentate debiti tecnici accettati e pianificate paydown. Questo materiale alimenta miglioramento continuo e proposte commerciali successive credibili.

Integrazione con toolchain esistente

CI/CD, code review e policy di branch del cliente vanno rispettate: consegnate pipeline coerenti con repository interni, evitando “isole” che solo il fornitore può buildare. Automatizzate test funzionali minimi su componenti AI così un refactor non rompe silenziosamente il retrieval o i template SQL.

Formazione e handover

Prevedete sessioni di handover con documentazione operativa: runbook, contatti escalation, metriche da monitorare e procedure di rollback. Così il team interno può gestire incidenti di routine senza dipendere dal fornitore per ogni piccolo aggiustamento.