Chatbot documentale con RAG su SAP Business Technology Platform

Demo di chatbot documentale su SAP BTP: backend SAP CAP in Node.js che interroga SAP AI Core e GPT-4o mini in Retrieval-Augmented Generation, citando in ogni risposta i documenti di origine. Interfaccia SAPUI5 freestyle su OData V4.

JavaScriptNode.jsCDS / CDLSAP AI CoreB.T.P.SAP Business Application Studio+7

Descrizione

Applicazione di chat che risponde a domande in linguaggio naturale usando come unica fonte un insieme di documenti aziendali indicizzati su SAP AI Core, e che chiude ogni risposta citando i documenti da cui l'ha ricavata. È nata in azienda come dimostratore per un cliente, per mostrare su documenti concreti cosa si può fare con la Retrieval-Augmented Generation restando dentro SAP Business Technology Platform. Il mock è stato costruito in cinque giorni lavorativi da un team di tre sviluppatori seguiti dal delivery manager: un collega ha curato l'integrazione che porta i documenti da un server SFTP dentro il grounding di AI Core, io e un altro sviluppatore abbiamo lavorato sulla parte AI — indicizzazione, classificazione e recupero dei passaggi, costruzione della risposta — e ho realizzato da solo il backend SAP Cloud Application Programming Model (CAP) in Node.js e l'applicazione di chat SAPUI5 che lo interroga.

Il problema

Le informazioni operative di un'azienda vivono dentro documenti che nessuno legge per intero. Quando serve un dato preciso, chi lo cerca apre i file uno per uno e scorre le pagine: la ricerca full-text trova la parola ma non risponde alla domanda, e chi non conosce già il nome del documento giusto non sa da dove partire. Il risultato è tempo perso e risposte che cambiano a seconda di chi le cerca. Il progetto nasce come dimostratore commerciale: serviva far vedere a un cliente, su documenti concreti e non su un esempio da slide, che si può porre la domanda in linguaggio naturale e ricevere una risposta costruita sui suoi documenti, con file e pagina di provenienza.

Vincoli

Cinque giorni lavorativi dall'inizio alla demo davanti al cliente: ogni scelta doveva essere quella che funziona subito, non quella che si difende meglio in una code review. Tutto doveva restare dentro SAP Business Technology Platform: nessuna chiave API di provider esterni, accesso al modello solo attraverso SAP AI Core, raggiunto via destination configurata sul subaccount e vincolato a un resource group e a un deployment ID dedicati. I cinquanta documenti caricati erano di tipo e formato eterogeneo, senza preparazione specifica: il retrieval doveva reggere su tutti senza tuning documento per documento. L'interfaccia conversazionale non è coperta dai template Fiori Elements, quindi la UI è SAPUI5 freestyle. L'autenticazione passa per XSUAA e l'app è servita dall'HTML5 Application Repository: backend, database e frontend vanno rilasciati insieme in un unico archivio MTA.

Architettura

documenti su SFTP ──► integrazione di ingestion ──► grounding SAP AI Core
                                                        (repository vettoriali)

SAPUI5 freestyle  ──►  Approuter (XSUAA)  ──►  servizio CAP
                                                   │
                                          SAP AI Core (destination)
                                          ├─ 1. retrieval sul grounding
                                          └─ 2. GPT-4o mini, chat completions

Ingestion: i documenti aziendali risiedono su un server SFTP; un flusso di integrazione li preleva e li carica nel document grounding di SAP AI Core, dove vengono suddivisi, indicizzati e classificati per essere recuperabili.
Frontend: applicazione SAPUI5 freestyle, bolle di chat costruite a runtime; invia il messaggio con un'azione OData V4 unbound sendMessage(text).
Backend: servizio SAP Cloud Application Programming Model (CAP) in Node.js. Il flusso è in due chiamate: prima il retrieval sui repository vettoriali di SAP AI Core (fino a 30 chunk), poi l'inference sul deployment di GPT-4o mini.
Grounding: i chunk vengono normalizzati in righe [documento - pag.N]: testo e inseriti nel system prompt, che vincola il modello a quel materiale. Ogni risposta si chiude con l'elenco dei documenti da cui il contenuto proviene: era una richiesta esplicita del cliente, ed è ciò che rende verificabile quello che il chatbot dice.
Quando la risposta non c'è: se il retrieval non restituisce materiale pertinente, l'utente riceve un messaggio esplicito — nessuna informazione trovata nelle fonti disponibili — invece di una risposta inventata dal modello.
Dati: SAP HANA Cloud via HDI container; il modello CDS contiene un'entità DocumentChunks con colonna Vector(1536), predisposta per gli embedding.
Deploy: archivio MTA con quattro moduli — servizio Node.js, db-deployer HDI, approuter, applicazione HTML5.

Risultato

Cinque giorni, dal foglio bianco alla demo#

Il mock è stato costruito in cinque giorni lavorativi, rilasciato sul Cloud Foundry runtime e provato su cinquanta documenti aziendali di tipo e formato diverso, caricati senza preparazione. In quel tempo il vincolo non era fare la cosa migliore possibile, ma fare quella che funziona davanti al cliente: catena completa dalla domanda scritta in chat alla risposta costruita sui documenti, tutto dentro SAP BTP e senza una sola chiave API verso l'esterno.

La parte che conta: la risposta è verificabile#

Un chatbot che risponde bene ma non dice da dove ha preso l'informazione, in un'azienda, non serve: nessuno può firmare una decisione presa su una frase di cui non conosce la fonte. Per questo ogni risposta si chiude con l'elenco dei documenti da cui il contenuto proviene — richiesta esplicita del cliente — e quando nelle fonti l'informazione non c'è il sistema lo dichiara invece di riempire il vuoto. È la differenza fra un dimostratore che si può portare in una sala riunioni e una demo che regge finché nessuno fa la domanda sbagliata.

Cosa ho fatto io#

Ho realizzato il backend CAP e l'applicazione di chat che lo interroga: l'azione OData che riceve la domanda, la chiamata al retrieval, la costruzione del contesto per il modello, la gestione degli errori e dei casi senza risposta, e l'interfaccia che mostra il risultato. Sulla parte AI ho lavorato con un altro sviluppatore all'indicizzazione dei documenti e alla costruzione della risposta; un terzo collega ha curato l'integrazione che porta i file dall'SFTP dentro il grounding di AI Core.

Dove sta adesso#

È rimasto un dimostratore, con il perimetro che questo comporta: nessuna misura sistematica di accuratezza su un set di domande di riferimento, nessuna pipeline di rilascio automatica. Non erano l'obiettivo di cinque giorni. Il cliente sta valutando se dare seguito al progetto.