Chiacchierare secondo le tue esigenze Il mio percorso nell’applicazione di Generative AI (LLM) alle specifiche del software

Generative AI (LLM) per le specifiche del software secondo le tue esigenze

Nell’era digitale, le grandi aziende sono afflitte dalla mancanza di comprensione dei loro sistemi e processi legacy. La conoscenza diventa isolata in silos, dispersa tra vari team e esperti del settore. Questa frammentazione contribuisce significativamente alla crescita del debito tecnico, un assassino silenzioso che ostacola gradualmente l’agilità e la produttività dell’organizzazione. Presso Curiosity Software, abbiamo trascorso gli ultimi cinque anni creando requisiti strutturati (attraverso modelli visivi) e collegandoci a centinaia di strumenti DevOps. Crediamo che ciò ci ponga in una posizione incredibilmente vantaggiosa quando si implementa l’Intelligenza Artificiale Generativa. I modelli e gli artefatti DevOps possono fungere da hub centrale di accesso ai dati che fluiscono attraverso il paesaggio di sviluppo software di un’organizzazione.

Come parte della nostra missione per contrastare le sfide prevalenti del debito tecnico e della mancanza di conoscenza, ci siamo imbarcati in un viaggio per applicare i Modelli di Linguaggio Grandi (LLM) ai requisiti software e alla logica aziendale. Il nostro obiettivo era quello di creare un hub di conoscenza per i requisiti software di un’organizzazione, che può essere interrogato per scoprire conoscenze e ripagare il debito tecnico.

Comprendere il Territorio dei Modelli di Linguaggio Grandi (LLMs)

Prima di discutere delle nostre esperienze e intuizioni, impostiamo la scena fornendo una breve panoramica dei Modelli di Linguaggio Grandi. I LLM, come il GPT-4 di OpenAI, sono in grado di comprendere e generare il linguaggio umano. Imparano da un vasto corpus di dati, che comprende una vasta gamma di argomenti e stili di linguaggio.

Questi LLM lavorano su un modello di apprendimento profondo noto come Transformer, che utilizza strati di meccanismi di auto-attenzione (reti neurali) per analizzare e comprendere il contesto all’interno dei dati. Durante l’addestramento, leggono innumerevoli frasi e paragrafi e fanno previsioni su ciò che seguirà in una frase. Queste previsioni si basano su ciò che hanno letto finora:

• Creazione di abilità personalizzate per i chatbot con i plugin
• Addestramento basato sulla popolazione (PBT) per la taratura degli iperparametri
• Costruzione di un motore di raccomandazione di prodotti con Apache Cassandra e Apache Pulsar

La cosa sorprendente di un LLM è la sua capacità di generare testo simile a quello umano. Questo accade quando viene addestrato su un ampio corpus di dati e ha un elevato numero di parametri o pesi nel modello (GPT-4 ne ha centinaia di miliardi):

Questa straordinaria capacità di rispondere come un essere umano è attribuibile non solo all’intelligenza intrinseca nell’algoritmo, ma anche alla scoperta che il linguaggio umano potrebbe non essere così intricato come si credeva inizialmente.

Esporre una rete neurale a un numero sufficiente di istanze di linguaggio umano consente a un LLM di individuare modelli e rispondere adeguatamente alle richieste. Con l’aumentare delle dimensioni e della qualità dei dati su cui viene addestrato un LLM, la sua potenza cresce in modo esponenziale.

I Dati Strutturati Sono Essenziali per il Successo dei LLM

Per le organizzazioni software di oggi, la capacità di sfruttare i LLM sembra essere più vicina che mai. Ci sono modelli incredibilmente compatti e specializzati che possono essere eseguiti su un PC locale e che raggiungono il livello di prestazioni di GPT-3.5.

Tuttavia, la parte più importante di un LLM non è lo strumento disponibile; sono i dati su cui un LLM è stato addestrato. Questo è quindi anche l’ostacolo principale all’uso efficace dei LLM, poiché le organizzazioni di oggi mancano di dati strutturati nel dominio del software.

I requisiti software sono tipicamente memorizzati in un formato testuale non strutturato e, peggio ancora, spesso sono incompleti, ambigui e mancano di informazioni. Lo stesso vale per i casi di test, che spesso sono memorizzati come elenchi di passi di test basati su testo.

Superare questo problema dei dati non strutturati richiede innovazione e attenta considerazione. Tecniche come l’estrazione di informazioni, la comprensione del linguaggio naturale e l’apprendimento automatico possono essere impiegate per trasformare dati non strutturati in dati strutturati. Questo processo spesso richiede l’intervento manuale dell’essere umano.

Una soluzione alternativa per addestrare un LLM non consiste nel cercare di addestrarlo su dati testuali non strutturati. Si propone di creare requisiti strutturati fin dall’inizio o di convertire dati non strutturati in requisiti strutturati come intermediario.

È qui che i requisiti modellati possono permettere la creazione di requisiti pronti all’uso per l’addestramento di modelli di linguaggio. Possiamo utilizzare i modelli per strutturare e migliorare i dati esistenti, integrando gli artefatti esistenti del ciclo di sviluppo del software con i modelli in un hub di conoscenza centrale.

Cosa è il Modellare per i Requisiti Software?

Il testing basato su modelli utilizza un modello della funzionalità in considerazione per generare casi di test. Questi modelli sono solitamente rappresentati come diagrammi di flusso visivi, che definiscono chiaramente i requisiti software rappresentando il comportamento, le funzioni o le operazioni del sistema.

Utilizzando tali modelli, è possibile ridurre l’ambiguità, facilitando la comprensione dei requisiti sia per gli sviluppatori che per i tester. Inoltre, la modellazione facilita la generazione automatica di casi di test, dati e automazione. Eventuali modifiche ai requisiti software possono essere riflesse modificando i modelli, portando a risorse di test dinamiche e aggiornate.

I diagrammi di flusso offrono un metodo visuale per presentare processi complessi in modo semplice e comprensibile. Mostrano ogni passo come una casella o un simbolo, con frecce tra di loro che mostrano il flusso degli utenti e dei dati attraverso il processo. Questo fornisce una rappresentazione chiara e facile da seguire del processo, evidenziando la sequenza delle operazioni e i punti di presa di decisione:

Tipicamente, un’organizzazione che sfrutta il testing basato su modelli creerà una libreria di modelli riutilizzabili, che possono poi essere collegati per creare scenari end-to-end molto più ricchi e veloci. Il processo di componentizzazione consente al team di procedere molto più velocemente nella creazione dei propri asset di test, ma anche di reagire ai cambiamenti in modo più efficiente:

I diagrammi di flusso sono strutturati per LLM

I diagrammi di flusso sono intrinsecamente strutturati di natura. Quando si tratta di addestrare Large Language Models, i dati strutturati sotto forma di diagrammi di flusso possono produrre risultati estremamente potenti.

Inoltre, i diagrammi di flusso sono ideali per le interrogazioni perché sono intuitivi e semplici da interpretare. Il flusso di controllo e il processo decisionale sono chiaramente rappresentati, rendendo facile per il modello prevedere i passaggi successivi del processo.

La capacità di inferire le relazioni tra i vari passaggi rende i diagrammi di flusso particolarmente preziosi sia per l’interrogazione che per l’addestramento di LLM. Ecco un esempio di utilizzo di un LLM per interrogare un modello semplice. Il modello sottostante rappresenta il processo di richiesta di un conto corrente per studenti:

Prompt: Quanti anni deve avere uno studente per ottenere l’approvazione per un conto corrente per studenti?

Risposta: Deve avere 18 anni o più.

Prompt: Come può uno studente ottenere l’approvazione per un conto corrente per studenti?

Risposta: Per ottenere l’approvazione per un conto corrente per studenti, uno studente dovrebbe prima inserire i propri dati personali. Questo sarebbe seguito dalla verifica dell’età per assicurarsi che abbia almeno 18 anni. Una volta confermata l’età di 18 anni o più, lo studente deve quindi inserire una prova di iscrizione per dimostrare il suo status di studente. Se tutti questi criteri vengono soddisfatti e la richiesta viene accettata, lo studente otterrà l’approvazione per un conto corrente per studenti.

Conversare con i requisiti software

Dato l’evidente capacità dei LLM di interrogare e ragionare sui diagrammi di flusso (modelli) e la gamma di connettori che Curiosity ha integrato negli strumenti DevOps, abbiamo cercato di applicare i LLM ai diagrammi di flusso e agli artefatti DevOps. Abbiamo cercato di combinare modelli con dati provenienti da diversi artefatti DevOps, creando un hub centrale di conoscenza per i LLM.

Abbiamo applicato e addestrato i LLM su una serie di requisiti software (acquisiti da JIRA) e modelli archiviati nello spazio di lavoro di Test Modeller di un’organizzazione. Per questo progetto, abbiamo un progetto JIRA con una serie di attività per un’applicazione bancaria, insieme a modelli creati per problemi basati su testo. Questi modelli sovrappongono una struttura aggiuntiva e completano i requisiti, creando i dati necessari per un LLM:

Ecco un esempio di ticket:

Se confronti la storia dell’utente “muro di testo” sopra con il requisito visivo di seguito, vedrai quanto sia più facile capire la logica dell’applicazione per una carta di credito utilizzando il diagramma di flusso. Questo grazie alla struttura intrinseca e alla natura visiva di un diagramma di flusso.

La raccolta di diagrammi di flusso e ticket Jira sincronizzati nello spazio di lavoro di Test Modeller fornisce un hub di conoscenza per i LLM. Quando interrogato, il LLM può quindi sfruttare e ragionare sulle informazioni archiviate in diversi artefatti SDLC altrimenti separati, ad esempio dati archiviati in più ticket Jira.

Analizziamo alcuni esempi di interrogazioni di questo hub di conoscenza utilizzando un LLM addestrato sui requisiti software e modelli bancari di esempio.

Esempio 1: Domanda semplice

Iniziamo con una domanda semplice su cui ci aspettiamo che il LLM si comporti bene. Dammi i dettagli di un ticket JIRA, dato il suo identificatore.

Prompt: Qual è il ticket JIRA CB-13?

Vediamo se torna con un riepilogo del ticket:

Esempio 2: Ragionamento implicito con un modello

In questo esempio, andremo un po’ più in profondità e faremo una domanda che si aspetta che il LLM comprenda un diagramma di flusso e deduca una risposta da esso. In particolare riguardo al processo di richiesta di una carta di credito.

Prompt: Quale punteggio di credito è richiesto per completare una richiesta di carta di credito?

Il LLM ha catturato il diagramma di flusso per il processo di richiesta di una carta di credito e ha interpretato il modello. Ha quindi utilizzato questa interpretazione per calcolare il punteggio di credito richiesto di 700 o superiore.

Esempio 3: Ragionamento implicito con modelli e requisiti

Questa richiesta richiede che il LLM interrompa più fonti di informazione per rispondere alla domanda. Cerca un modello e anche il requisito corrispondente.

Prompt: Quando un cliente può richiedere una carta di credito?

Esempio 4: Ragionamento con più requisiti

Questa richiesta richiede di comprendere e ragionare su più requisiti per rispondere a una query di cross-requisito. Vedremo nella risposta che tre storie degli utenti vengono citate per rispondere che i prodotti sono disponibili solo se un individuo ha un buon punteggio di credito.

Prompt: A quali prodotti posso applicare se ho un buon credito?

Demo: Utilizzo di LLM per interrogare dati strutturati del diagramma di flusso

Osservami sincronizzare le informazioni dalle storie degli utenti di Jira in un hub di conoscenza centrale ed eseguire le query utilizzate durante la scrittura di questo articolo:

Adotta LLM per una migliore consegna del software

Curiosity Software sta sfruttando i Large Language Models (LLMs) come il GPT-4 di OpenAI per comprendere e gestire meglio i requisiti software e la logica aziendale, con particolare attenzione alla lotta al debito tecnico.

Dato che i LLM si basano su dati strutturati, il testing basato sui modelli è lo strumento perfetto per completare ed eliminare l’ambiguità nei dati non strutturati. I modelli forniscono una fonte di flussi di lavoro aziendali strutturati, utilizzando diagrammi di flusso visivi per rappresentare i requisiti software, che a loro volta forniscono chiarezza. Allo stesso tempo, possiamo sincronizzare le informazioni dagli strumenti e dagli artefatti di DevOps in un hub di conoscenza centrale.

Questo approccio consente anche la generazione automatica di casi di test, dati e automazione. Utilizzando questi metodi, Curiosity Software sta lavorando attivamente per addestrare i LLM su un ampio spettro di requisiti software catturati da vari strumenti DevOps, che vengono modellati nello spazio di lavoro di Test Modeller di un’organizzazione. Questo crea un co-pilota e dashboard che forniscono spiegazioni dell’intero SDLC quando viene interrogato, fornendo informazioni decisionali su rischi, rilasci, copertura dei test, conformità e altro ancora:

Possiamo persino generare modelli utilizzando l’AI generativa, come descritto nel mio ultimo articolo. Questo chiude il ciclo di feedback. Un essere umano può lavorare con un’AI generativa per creare e migliorare iterativamente modelli basati su dati nei diagrammi di flusso e negli artefatti SDLC più ampi. I flussi, a loro volta, forniscono specifiche accurate per gli sviluppatori, generando test per verificare il codice che creano.

I dati risultanti da questa progettazione, testing e sviluppo assistiti dall’AI vengono alimentati nel nostro hub di conoscenza centrale. Questo aggiorna il LLM, informa le future iterazioni ed evita il debito tecnico.

Questa applicazione dell’IA ai requisiti software può contribuire a migliorare l’efficienza e l’efficacia dei processi di sviluppo software, agire come un hub di conoscenza per i processi aziendali di un’organizzazione e infine combattere il debito tecnico.