Questione di privacy: un equilibrio tra potenza e riservatezza
Nel nostro progetto abbiamo adottato un’architettura che combina efficienza e attenzione alla riservatezza dei dati. La componente centrale del sistema è un database vettoriale privato, ospitato su Pinecone, che cresce on demand, sia in termini di capacità di archiviazione che di performance computazionale. Questa scalabilità automatica rappresenta un vantaggio importante: si paga solo per le risorse effettivamente utilizzate, evitando sovradimensionamenti inutili e mantenendo bassi i costi operativi.
Accanto a questo, il sistema interroga un modello linguistico esterno, erogato tramite le API di OpenAI, secondo un contratto a consumo. La chiave del nostro approccio alla sicurezza sta nella separazione dei ruoli: i dati completi (documenti, testi, contenuti multimediali) non vengono mai inviati a OpenAI. L’interrogazione avviene prima privatamente, sul database vettoriale, da cui si ricavano solo i frammenti più rilevanti. Questi frammenti vengono poi passati al modello generativo come context, minimizzando così il rischio di esposizione di dati sensibili.
Questa strategia comporta vantaggi concreti su due fronti:
Maggiore sicurezza, perché nessun dato completo viene trasmesso verso sistemi esterni;
Riduzione dei costi, poiché il numero di token (e quindi le chiamate API a pagamento) viene contenuto al minimo necessario.
Memoria Persistente con LangChain: Superare i Limiti delle API di OpenAI
Le API di OpenAI, come ChatGPT, operano in modalità stateless, ovvero non mantengono una memoria persistente delle interazioni precedenti. Ciò implica che ogni richiesta è indipendente dalle altre, e informazioni fornite in una sessione non vengono automaticamente ricordate in quelle successive. Ad esempio, se in una conversazione si comunica che il Sig. X riceve dal lunedì al venerdì dalle 8 alle 12, questa informazione non verrà conservata per future interazioni a meno che non venga esplicitamente reinclusa nel prompt. Per mantenere un contesto continuo, è necessario implementare soluzioni esterne, come l’utilizzo di database o sistemi di gestione dello stato, che raccolgano e gestiscano questi dati per reintegrarli nelle query future. Questo è lo scopo delle interrogazioni su un modello LLM personale inserire nelle conversazioni elementi personali e individuali presenti nelle risrse interne del processo.
Oltre a ciò LangChain affronta questa sfida offrendo moduli di memoria che consentono di persistere lo stato tra diverse chiamate, permettendo al modello di “ricordare” le interazioni passate e utilizzare tali informazioni per fornire risposte più contestuali e pertinenti. Uno di questi moduli è il ConversationBufferMemory, che memorizza i messaggi della conversazione in un buffer, rendendoli disponibili per le interazioni successive.
“Una giornata da dimenticare: avventure e disavventure tra codice e container”
Durante l’integrazione tra l’activity qbotica.langchainv2.activities.IngestKnowledgeSource di UiPath e un backend Python in esecuzione su Docker (basato sul framework LangChain), ci siamo trovati davanti a una serie di ostacoli tecnici che vale la pena documentare.
in primis abbiamo configurato un container Docker con la versione di langchain: (clicca qui)
e scaricato dal marketplace le activity LLM di Uipath (clicca qui)
Ma il tutto non funzionava forse perchè il progetto non è stato più mantenuto .
Ecco i principali passaggi e le soluzioni adottate:
🧩 1. Disassemblaggio dell’Activity
Non potendo modificare direttamente il comportamento dell’activity fornita da Qbotica, è stato necessario analizzare il codice C# disassemblato con strumenti NuGet. Abbiamo verificato che l’endpoint APIEndpoint passato all’activity non veniva alterato internamente, ma che l’errore avveniva lato backend (Docker).
🌍 2. Endpoint Pinecone errato
L’activity generava chiamate verso controller.<env>.pinecone.io, ma Pinecone ora fornisce endpoint personalizzati (es. pippo-xxxxx.svc.gcp-europe-west4-xxxx.pinecone.io). Il backend Python nel container usava ancora l’approccio obsoleto basato su environment. Abbiamo quindi modificato manualmente il codice nel file pinecone_store.py sostituendo environment=env con host=env.
🐳 3. Verifica della Risoluzione DNS in Docker
Nonostante la modifica, le chiamate continuavano a fallire. Con ping e nslookup abbiamo scoperto che l’ambiente Docker non risolveva correttamente gli hostname Pinecone. Abbiamo configurato il DNS a 8.8.8.8 all’interno del container per risolvere correttamente i nomi di dominio esterni.
🧪 4. Compatibilità SDK Pinecone Un ulteriore errore è emerso dall’uso del vecchio SDK pinecone-client. Questo generava eccezioni all’avvio. Abbiamo disinstallato la vecchia versione (pip uninstall pinecone-client) e installato il nuovo SDK (pip install pinecone), aggiornando anche il codice a usare la nuova sintassi basata sulla classe Pinecone.
Dopo questi passaggi, l’intero flusso ha iniziato a funzionare correttamente, permettendo di interrogare vettorialmente documenti attraverso Pinecone, orchestrando tutto con UiPath.
Ma questa non è una soluzione friendly. Per cui non la descrivo. Doqo questa giornata di follia intendo proporre un altro approccio pronto all’uso. Quindi mi ripropongo di scrivere una terza parte di questa nostra avventura per la realizzazione di una Ai conversazionale.
