Ormai apro LinkedIn e scopro che nel tempo in cui io preparo il caffè qualcuno ha sviluppato un gestionale, sostituito un reparto IT e lanciato una startup. Tutto dal bagno. Evidentemente noi abbiamo sbagliato arredamento in ufficio 🤣.
Poi però una domanda mi viene: ma avete mai provato a farlo usare davvero a un’azienda?
Sai, intendo con i suoi dati. I documenti scritti in vent’anni e dodici formati diversi. Gli utenti con permessi differenti. Le informazioni riservate. Le procedure che «sì, normalmente funzionano così, tranne quando…» e qualcuno che, quando il sistema sbaglia, ti chiama. Perché lì la faccenda diventa interessante.
In Brokenice stiamo integrando seriamente l’intelligenza artificiale nei nostri software. È potentissima. Ci permette di costruire funzionalità che fino a poco tempo fa avrebbero richiesto investimenti enormi, oppure sarebbero rimaste nel cassetto. La usiamo, ci investiamo e stiamo cambiando il modo in cui sviluppiamo e facciamo interagire le persone con i nostri applicativi.
Proprio per questo, la favola del software finito in cinque minuti comincia a essere abbastanza stucchevole.
Una schermata convincente si può ottenere molto velocemente. Poi comincia il lavoro che nel video viene tagliato.
Partiamo dai dati. Quelli veri.
Quali informazioni possiamo passare al modello? Quali devono restare nell’infrastruttura aziendale? Come separiamo i dati utili da quelli personali o riservati? Ci siamo messi a lavorare anche sull’offuscamento dei dati attraverso modelli locali, prima di inviare contenuti ai modelli esterni. E già qui bisogna capire cosa individuare, cosa mascherare e come mantenere abbastanza contesto perché il risultato continui ad avere senso.
Poi arriva la RAG, il recupero delle informazioni da dare al modello per rispondere.
«Basta collegargli i documenti.»
Certo. Come per costruire un gestionale basta collegargli il database. 🤣
Devi estrarre i contenuti, dividerli in parti sensate, indicizzarli, cercare quelli pertinenti e gestire aggiornamenti, duplicati e versioni. Devi capire se il sistema ha recuperato il passaggio giusto o qualcosa che gli assomiglia abbastanza da produrre una risposta convincente e sbagliata. E devi rispettare i permessi anche durante il recupero delle informazioni.
Perché se il gestionale impedisce a un utente di vedere un documento, ma la chat glielo riassume gentilmente, hai costruito una fuga di informazioni con un’ottima interfaccia.
Da questo lavoro è nato Ragy, il nostro sistema RAG locale, cresciuto fino a diventare un software vero e proprio. Perché dietro al «fagli leggere due documenti» c’era abbastanza lavoro da costruirci un prodotto.
E prima ancora della RAG, qualcuno deve riuscire a leggere quei benedetti documenti.
Chi ha lavorato con i PDF lo sa: estensione uguale, contenuti completamente diversi. Testo, scansioni, tabelle, colonne, intestazioni ripetute e ordine di lettura che sembra deciso tramite sorteggio. Mandare tutto direttamente all’LLM può funzionare in una prova. Quando i documenti diventano un flusso operativo, devi ragionare su qualità dell’estrazione, tempi, token e costi.
Per questo abbiamo sviluppato Paperbind, un altro software dedicato al parsing e all’estrazione del testo dai PDF prima del passaggio all’LLM. Abbiamo lavorato anche su elaborazione e sintesi locale, per evitare di sovraccaricare il modello di contenuti inutili.
Insomma, per fare bene la funzionalità «carica il PDF e chiedi» ci siamo ritrovati a sviluppare anche ciò che serve prima che l’AI riceva la domanda.
Probabilmente nel frattempo il guru era già al secondo round di finanziamento. 🚀
Poi c’è il problema di far diventare tutto questo un metodo di lavoro.
Come software house sviluppiamo applicativi custom. Non possiamo ricominciare ogni mattina da zero, incollando integrazioni diverse e sperando che si comportino tutte allo stesso modo.
Per questo stiamo standardizzando l’integrazione dell’AI nel nostro framework Nitrogen: costruire una base comune per collegare dati, strumenti e funzionalità ai processi dei nostri software, senza reinventare ogni volta gli stessi meccanismi.
Quando colleghi un modello alle funzioni operative, anche attraverso MCP, le domande diventano molto concrete: quali strumenti può usare? Con i permessi di chi? Quali parametri deve fornire? Quando serve una conferma? Se un’operazione fallisce a metà, cosa succede? Se viene ripetuta, rischia di creare un doppione?
Il prompt «sei un assistente molto bravo e preciso» a un certo punto finisce gli argomenti.
Abbiamo sviluppato anche Frosty, il nostro chatbot proprietario, per avere il controllo sul prodotto e poterlo adattare alle esigenze dei clienti, perché usare strumenti e componenti esterni è normale. Il punto è conoscere e governare ciò che stai vendendo.
Perché quando fai software su misura non puoi scoprire, alla prima richiesta particolare, che la tua competenza finisce nel pannello delle impostazioni di un prodotto white label.
«Questo non possiamo farlo perché il prodotto che abbiamo rimarchiato non lo prevede, e noi non sappiamo dove mettere le mani» è una risposta un po’ difficile da conciliare con «realizziamo soluzioni personalizzate».
E poi arriva il test più temuto: una persona che usa il software senza aver visto il vostro video.
La segretaria l’ha provato?
Ha caricato il PDF storto, fatto una domanda incompleta, cambiato idea a metà e cliccato due volte perché sembrava bloccato?
È rimasto tutto in piedi?
Perché chi usa un software non segue il copione della demo. Fa il proprio lavoro. E il software deve reggere anche quando quel lavoro non assomiglia al percorso perfetto che avevamo immaginato. A quel punto scopri quanto contano la gestione delle conversazioni, il contesto, le risposte verificabili, i log, i backup, il ripristino, i tempi di attesa e i costi per singola operazione.
Tutte cose poco virali. Finché non mancano.
La parte bella è dove stiamo arrivando: poter parlare e ragionare con i nostri software in maniera professionale.
Interrogare i dati aziendali in linguaggio naturale, mettere in relazione informazioni, farsi aiutare a interpretarle e guidare operazioni attraverso le funzioni del gestionale.
Una conversazione che entra nel lavoro quotidiano, con il contesto dell’azienda, i permessi dell’utente e strumenti collegati alle attività da svolgere.
Vederlo funzionare dà una soddisfazione enorme. Ed è proprio perché ne vediamo il potenziale che ci interessa parlarne seriamente, compresa tutta la fatica che serve per arrivarci.
L’AI ci fa andare più veloci e ci permette di fare di più. Qualcuno deve comunque progettare il sistema, conoscere i processi, verificare i risultati e rispondere al telefono quando qualcosa si rompe.
Quindi la domanda ai venditori di miracoli è questa:
Quanto avete spinto la vostra demo oltre quei cinque minuti necessari per fare il video?
L’avete messa davanti a utenti veri? Con dati veri? Per settimane? Avete controllato gli errori e quanto costa farla funzionare?
Raccontateci anche quello. È la parte più interessante.
E a chi ci sta lavorando davvero: qual è stata la prima cosa che un utente ha fatto per rompere la vostra bellissima demo?Ormai apro LinkedIn e scopro che nel tempo in cui io preparo il caffè qualcuno ha sviluppato un gestionale, sostituito un reparto IT e lanciato una startup. Tutto dal bagno. Evidentemente noi abbiamo sbagliato arredamento in ufficio 🤣.
Poi però una domanda mi viene: ma avete mai provato a farlo usare davvero a un’azienda?
Sai, intendo con i suoi dati. I documenti scritti in vent’anni e dodici formati diversi. Gli utenti con permessi differenti. Le informazioni riservate. Le procedure che «sì, normalmente funzionano così, tranne quando…» e qualcuno che, quando il sistema sbaglia, ti chiama. Perché lì la faccenda diventa interessante.
In Brokenice stiamo integrando seriamente l’intelligenza artificiale nei nostri software. È potentissima. Ci permette di costruire funzionalità che fino a poco tempo fa avrebbero richiesto investimenti enormi, oppure sarebbero rimaste nel cassetto. La usiamo, ci investiamo e stiamo cambiando il modo in cui sviluppiamo e facciamo interagire le persone con i nostri applicativi.
Proprio per questo, la favola del software finito in cinque minuti comincia a essere abbastanza stucchevole.
Una schermata convincente si può ottenere molto velocemente. Poi comincia il lavoro che nel video viene tagliato.
Partiamo dai dati. Quelli veri.
Quali informazioni possiamo passare al modello? Quali devono restare nell’infrastruttura aziendale? Come separiamo i dati utili da quelli personali o riservati? Ci siamo messi a lavorare anche sull’offuscamento dei dati attraverso modelli locali, prima di inviare contenuti ai modelli esterni. E già qui bisogna capire cosa individuare, cosa mascherare e come mantenere abbastanza contesto perché il risultato continui ad avere senso.
Poi arriva la RAG, il recupero delle informazioni da dare al modello per rispondere.
«Basta collegargli i documenti.»
Certo. Come per costruire un gestionale basta collegargli il database. 🤣
Devi estrarre i contenuti, dividerli in parti sensate, indicizzarli, cercare quelli pertinenti e gestire aggiornamenti, duplicati e versioni. Devi capire se il sistema ha recuperato il passaggio giusto o qualcosa che gli assomiglia abbastanza da produrre una risposta convincente e sbagliata. E devi rispettare i permessi anche durante il recupero delle informazioni.
Perché se il gestionale impedisce a un utente di vedere un documento, ma la chat glielo riassume gentilmente, hai costruito una fuga di informazioni con un’ottima interfaccia.
Da questo lavoro è nato Ragy, il nostro sistema RAG locale, cresciuto fino a diventare un software vero e proprio. Perché dietro al «fagli leggere due documenti» c’era abbastanza lavoro da costruirci un prodotto.
E prima ancora della RAG, qualcuno deve riuscire a leggere quei benedetti documenti.
Chi ha lavorato con i PDF lo sa: estensione uguale, contenuti completamente diversi. Testo, scansioni, tabelle, colonne, intestazioni ripetute e ordine di lettura che sembra deciso tramite sorteggio. Mandare tutto direttamente all’LLM può funzionare in una prova. Quando i documenti diventano un flusso operativo, devi ragionare su qualità dell’estrazione, tempi, token e costi.
Per questo abbiamo sviluppato Paperbind, un altro software dedicato al parsing e all’estrazione del testo dai PDF prima del passaggio all’LLM. Abbiamo lavorato anche su elaborazione e sintesi locale, per evitare di sovraccaricare il modello di contenuti inutili.
Insomma, per fare bene la funzionalità «carica il PDF e chiedi» ci siamo ritrovati a sviluppare anche ciò che serve prima che l’AI riceva la domanda.
Probabilmente nel frattempo il guru era già al secondo round di finanziamento. 🚀
Poi c’è il problema di far diventare tutto questo un metodo di lavoro.
Come software house sviluppiamo applicativi custom. Non possiamo ricominciare ogni mattina da zero, incollando integrazioni diverse e sperando che si comportino tutte allo stesso modo.
Per questo stiamo standardizzando l’integrazione dell’AI nel nostro framework Nitrogen: costruire una base comune per collegare dati, strumenti e funzionalità ai processi dei nostri software, senza reinventare ogni volta gli stessi meccanismi.
Quando colleghi un modello alle funzioni operative, anche attraverso MCP, le domande diventano molto concrete: quali strumenti può usare? Con i permessi di chi? Quali parametri deve fornire? Quando serve una conferma? Se un’operazione fallisce a metà, cosa succede? Se viene ripetuta, rischia di creare un doppione?
Il prompt «sei un assistente molto bravo e preciso» a un certo punto finisce gli argomenti.
Abbiamo sviluppato anche Frosty, il nostro chatbot proprietario, per avere il controllo sul prodotto e poterlo adattare alle esigenze dei clienti, perché usare strumenti e componenti esterni è normale. Il punto è conoscere e governare ciò che stai vendendo.
Perché quando fai software su misura non puoi scoprire, alla prima richiesta particolare, che la tua competenza finisce nel pannello delle impostazioni di un prodotto white label.
«Questo non possiamo farlo perché il prodotto che abbiamo rimarchiato non lo prevede, e noi non sappiamo dove mettere le mani» è una risposta un po’ difficile da conciliare con «realizziamo soluzioni personalizzate».
E poi arriva il test più temuto: una persona che usa il software senza aver visto il vostro video.
La segretaria l’ha provato?
Ha caricato il PDF storto, fatto una domanda incompleta, cambiato idea a metà e cliccato due volte perché sembrava bloccato?
È rimasto tutto in piedi?
Perché chi usa un software non segue il copione della demo. Fa il proprio lavoro. E il software deve reggere anche quando quel lavoro non assomiglia al percorso perfetto che avevamo immaginato. A quel punto scopri quanto contano la gestione delle conversazioni, il contesto, le risposte verificabili, i log, i backup, il ripristino, i tempi di attesa e i costi per singola operazione.
Tutte cose poco virali. Finché non mancano.
La parte bella è dove stiamo arrivando: poter parlare e ragionare con i nostri software in maniera professionale.
Interrogare i dati aziendali in linguaggio naturale, mettere in relazione informazioni, farsi aiutare a interpretarle e guidare operazioni attraverso le funzioni del gestionale.
Una conversazione che entra nel lavoro quotidiano, con il contesto dell’azienda, i permessi dell’utente e strumenti collegati alle attività da svolgere.
Vederlo funzionare dà una soddisfazione enorme. Ed è proprio perché ne vediamo il potenziale che ci interessa parlarne seriamente, compresa tutta la fatica che serve per arrivarci.
L’AI ci fa andare più veloci e ci permette di fare di più. Qualcuno deve comunque progettare il sistema, conoscere i processi, verificare i risultati e rispondere al telefono quando qualcosa si rompe.
Quindi la domanda ai venditori di miracoli è questa:
Quanto avete spinto la vostra demo oltre quei cinque minuti necessari per fare il video?
L’avete messa davanti a utenti veri? Con dati veri? Per settimane? Avete controllato gli errori e quanto costa farla funzionare?
Raccontateci anche quello. È la parte più interessante.
E a chi ci sta lavorando davvero: qual è stata la prima cosa che un utente ha fatto per rompere la vostra bellissima demo?
