Ricerca & laboratorio

Questa pagina descrive in forma aggregata le linee di ricerca e sviluppo interne che alimentano proposte commerciali di Purple AI (Purple AI S.r.l., parte di Purple Holding S.r.l.). Salvo diversa autorizzazione, gli esempi non costituiscono case study cliente nominativi: servono a dimostrare maturità tecnica, ridurre rischio nelle stime e allineare aspettative prima di impegni di budget.

Linee principali

• Voice & edge: pipeline STT → orchestrazione agenti → TTS, sessioni dispositivo, integrazione con knowledge store.
• NL2SQL / copilot dati: template SQL, ruoli, audit, export verso strumenti office e BI.
• RAG su testi strutturati e normativi: ingest, embedding batch, similarità su PostgreSQL/pgvector, orchestrazione cost-aware.
• Forecasting e ML su serie temporali: training, backtest, API — ambito ingegneristico e operativo reale, non consulenza finanziaria retail.

Come nasce un proof of concept

Un POC in laboratorio parte da ipotesi misurabile: riduzione tempo per ottenere una risposta, copertura di un sottoinsieme di documenti, accuratezza su un benchmark interno. Limitiamo volutamente perimetro e dati per isolare rischi. Se il POC non supera soglie concordate, documentiamo perché e cosa servirebbe (dati, infrastruttura, cambio modello) prima di scalare.

Stack e disciplina di versionamento

Usiamo toolchain .NET, PostgreSQL, servizi cloud Microsoft e provider LLM secondo progetto. Le dipendenze sono versionate in repository privati; dove possibile allineiamo le versioni alle linee guida ufficiali dei vendor per ricevere patch di sicurezza. Sperimentazioni “bleeding edge” restano branch separati finché non sono ripetibili.

Collaborazioni esterne

Possiamo collaborare con università, centri di ricerca o partner industriali su temi compatibili con la strategia del gruppo. Ogni collaborazione regola IP, riservatezza e pubblicabilità dei risultati in contratto. Non assumiamo impegni di pubblicazione accademica senza valutazione commerciale e legale.

Proprietà intellettuale e segretezza

Il codice e le configurazioni sviluppate per un cliente restano di proprietà o licenza secondo contratto. Il know-how generico (pattern di locking su batch embedding, schemi di deployment) resta nel gruppo. In call commerciali evitiamo di rivelare dettagli identificativi di architetture cliente senza permesso.

Trasferimento in produzione

Il laboratorio non è “isola”: quando un esperimento è promosso, lo portiamo in pipeline di integrazione continua, osservabilità e backup come qualsiasi altro servizio. Questo passaggio include hardening, test di carico realistico e documentazione runbook per il vostro IT.

Costi interni e sostenibilità

Monitoriamo costo token, ore GPU se presenti, storage vettoriale. Esperimenti costosi senza ROI probabile vengono chiusi o ripianificati. Questa disciplina interna si riflette nelle stime che vi presentiamo.

Allineamento con purplesoft.io

Il laboratorio AI beneficia di competenze trasversali del gruppo su integrazione gestionali, web e dati descritte su purplesoft.io. Viceversa, soluzioni nate sul .ai possono essere riutilizzate come componenti in progetti più ampi gestiti dal .io, con confini contrattuali chiari.

Pubblicazioni e blog

Articoli e case tecnici pubblicati su blog e casi studio derivano spesso da attività di laboratorio depurate di elementi sensibili. Se notate un errore materiale, segnalatecelo da Contatti: correggiamo con rettifica visibile.

Accesso per clienti

In alcuni progetti offriamo accesso a dashboard interne di metriche o repository documentati per il cliente. Non è uno spazio “aperto a tutti”: si attiva su base contrattuale e con ruoli definiti.

Responsabilità e limiti

Il laboratorio non produce pareri legali, medici o finanziari regolamentati in modo semplice o automatico. I modelli sperimentali possono essere instabili: non usarli in produzione senza gate di qualità concordato.

Come proporre un tema di ricerca congiunto

Scrivete da Contatti con sintesi del tema, stato dell’arte che conoscete, risorse che potete apportare (dati anonimizzati, finanziamento, personale). Valutiamo fattibilità e conflitto di interessi prima di impegnarci.

Sicurezza del laboratorio

Ambienti isolati, segreti in vault, rotazione chiavi API, policy di accesso least privilege. I dataset sensibili dei clienti non vengono mescolati con esperimenti generici senza consenso scritto.

Metriche di qualità interna

Usiamo checklist su grounding, jailbreak resistance base, latenza p95, costo per 1000 richieste. Non tutte le metriche sono rilevanti per ogni caso: selezioniamo in base al rischio del dominio.

Formazione del personale

Il team laboratorio partecipa a formazione continua su sicurezza AI, novità normative e aggiornamenti dei framework. Incoraggiamo certificazioni dove utili ma non le sostituiamo con esperienza su progetti reali.

Contatti operativi

Per collaborazioni o POC: Contatti. Per contesto organizzativo: Chi siamo. Per domande generiche: FAQ.

Visione a medio termine

Intendiamo continuare a investire in strumenti che rendano l’AI osservabile, spegnibile e spiegabile ai reparti che la usano. La moda passa; la necessità di controllo operativo resta.

Dataset sintetici e anonimizzazione

Quando servono dataset per stress test senza esporre dati reali, generiamo dati sintetici o anonimizzati con tecniche documentate. Valutiamo limiti di utilità: un sintetico troppo semplice può illudere su performance reali. Comunichiamo esplicitamente quando i numeri provengono da benchmark interni non rappresentativi del cliente.

Reproducibilità degli esperimenti

Fissiamo seed, versioni modello e snapshot di configurazione quando l’esperimento lo richiede. Questo facilita confronti A/B e difese delle scelte in audit interni. In produzione con modelli che cambiano, documentiamo invece procedure di regressione funzionale dopo aggiornamenti.

Green computing e costi ambientali

Ottimizzare batch e caching non serve solo al budget: riduce energia e impatto. Non facciamo greenwashing: dove possibile quantifichiamo trade-off tra accuratezza e consumo per decisioni consapevoli.

Open source e contributi

Valutiamo contributi upstream a librerie che usiamo (fix, documentazione) quando non confliggono con obblighi di riservatezza cliente. Non pubblichiamo codice proprietario del committente come open source senza licenza esplicita.

Allineamento con roadmap vendor

Seguiamo note di deprecazione di API e modelli dei fornitori cloud per anticipare migrazioni. Quando un modello viene ritirato, pianifichiamo con voi test di regressione e — se necessario — fallback su modello alternativo con impatto stimato su qualità e costo.

Laboratorio e conformità

Per settori regolati, il laboratorio può produrre evidenze richieste in audit (log estratti, descrizione flussi dati). Non sostituisce controlli interni del cliente ma fornisce artefatti tecnici verificabili.

Handover al reparto operations

Chiude il laboratorio e apre operations solo dopo checklist condivisa: runbook, contatti escalation, soglie di allarme, piano di aggiornamento corpus o modelli. Evitiamo muri tra “chi sperimenta” e “chi tiene acceso di notte”. Il passaggio include sessioni di knowledge transfer registrate dove il cliente lo consente e le policy interne lo permettono.