🔧Step necessari e utensili da utilizzare





Dopo aver sperimentato sul campo l’integrazione con il framework LangChain tramite l’activity di UiPath, ci siamo scontrati con alcune limitazioni nella gestione avanzata dei documenti e nella personalizzazione delle logiche di parsing.
Abbiamo quindi scelto una via più flessibile: riscrivere alcune funzioni critiche in Python e confezionarle all’interno di un container Docker, da esporre come servizio HTTP. In questo modo possiamo ricevere file da automatismi UiPath o da altre fonti e prepararli per la successiva fase di segmentazione e embedding.
Questa scelta ci ha aperto la strada a un’architettura più modulare, scalabile e aderente alle nostre esigenze reali costruita con uipath studio.
📁 Environment e sicurezza
Un punto chiave del sistema è la gestione dell’environment, ovvero del contesto in cui il modello deve operare. Nel nostro caso, stiamo costruendo una soluzione per uno studio legale e questo comporta una distinzione netta tra:
Informazioni pubbliche o consultabili da utenti esterni
Informazioni legali riservate, ad uso esclusivo degli avvocati dello studio.
Questa compartimentazione sarà alla base della pipeline di elaborazione: i documenti in ingresso verranno identificati, categorizzati e processati in ambienti separati, così da garantire riservatezza, tracciabilità e controllo.
⚙️ Componenti principali
Fase | Utensile |
Ricezione file | Api Flask in Docker Integrata con UiPath+ Orchestrator |
Parsing e normalizzazione | Python personalizzato |
Segmentazione in chunk | LangChain ( RecursiveCharacterTextSplitter ) |
Filtraggio per environment | Logica custom (per public vs private ) |
Embedding | Con servizi privati diversi da openAi (per rafforzamento privacy) |
Invio a Vector DB | Pinecone, gestito tramite SDK/API |
Con questo approccio, possiamo smarcare una delle esigenze più concrete per le organizzazioni che lavorano su documenti sensibili: un sistema intelligente ma controllabile, costruito in modo incrementale, testabile e — soprattutto — sicuro in cui le informazioni non escono mai al di fuori della propria organizzazione nemmeno per la fase di embedding.
Embedding e vettorizzazione
Il nostro obiettivo è costruire un sistema per la ricezione dei documenti provenienti da varie fonti nel nostro studio legale, distinguendo chiaramente tra le informazioni destinate al pubblico e agli utenti esterni e quelle legali private da proteggere per l’uso esclusivo degli avvocati.
Fase di Embedding: Considerazioni sulla Sicurezza
Nella fase di embedding, ovvero la rappresentazione dei testi attraverso vettori multidimensionali, è comune utilizzare motori di decodifica come OpenAI o HuggingFace. Tuttavia, l’uso di OpenAI potrebbe rappresentare una vulnerabilità nella sicurezza dei nostri dati. Vettorializzare un documento implica inviare il suo contenuto ai motori di vettorializzazione. Sebbene OpenAI offra un certo grado di sicurezza per i servizi a pagamento, il funzionamento interno rimane poco trasparente.
HuggingFace, d’altra parte, implementa misure di sicurezza come la scansione malware, la scansione dei file pickle e la scansione dei segreti. Tuttavia, sono stati segnalati casi di modelli malevoli presenti sulla piattaforma, evidenziando la necessità di una vigilanza costante nell’uso di modelli pre-addestrati.
Utilizzo del Motore di Embedding di Pinecone
Abbiamo scelto di utilizzare il motore di embedding di Pinecone per tre motivi principali:
Costi Ridotti: I costi per kilobyte di file inviati sono significativamente inferiori rispetto a OpenAI.
Sicurezza e Conformità: Pinecone offre crittografia sia a riposo che in transito, chiavi di crittografia gerarchiche e networking privato, garantendo che i dati siano sicuri. Inoltre, Pinecone è conforme a certificazioni come SOC 2, GDPR, ISO 27001 e HIPAA.
Inoltre, la trasportabilità del database vettoriale di Pinecone facilita la migrazione in ambienti locali, offrendo flessibilità nella gestione dei dati.
Conclusione
La scelta del motore di embedding è cruciale per garantire la sicurezza e l’efficienza nel trattamento dei documenti legali. Optando per Pinecone, beneficiamo di costi ridotti, maggiore sicurezza e conformità alle normative europee, assicurando che le informazioni sensibili del nostro studio legale siano protette adeguatamente.
Costi di questo step
Nella progettazione di un sistema di intelligenza artificiale per la gestione documentale di uno studio legale, è fondamentale valutare attentamente i costi associati alle diverse componenti tecnologiche. In particolare, confrontiamo i costi dei servizi di embedding offerti da OpenAI e Pinecone, due soluzioni leader nel settore.
OpenAI
OpenAI offre diversi modelli per l’elaborazione del linguaggio naturale, ciascuno con una struttura di prezzi specifica. Ad esempio, il modello GPT-4 prevede un costo di $0.03 per 1.000 token in input e $0.06 per 1.000 token in output . Considerando che un documento medio può contenere circa 1.000 token, il costo per l’elaborazione di un singolo documento sarebbe approssimativamente di $0.03 per l’input e $0.06 per l’output, totalizzando $0.09 per documento.
Pinecone
Pinecone adotta un modello di pricing basato sull’uso effettivo. Il piano Standard prevede una tariffa di $0.33 per GB al mese per lo storage, $4 per milione di operazioni di scrittura (Write Units) e $16 per milione di operazioni di lettura (Read Units) . Per un utilizzo tipico, i costi possono variare significativamente in base al volume di dati e al numero di operazioni eseguite.
l’embedding è inccluso nella scrittura percui avremmo significativi risparmi rispetto a OpenAi
Confronto dei Costi
Supponendo di dover elaborare 10.000 documenti al mese, ciascuno di 1.000 token:
OpenAI: Il costo mensile sarebbe di circa $900 (10.000 documenti x $0.09 per documento).
Pinecone: I costi dipenderebbero dalla dimensione totale dei dati memorizzati e dal numero di operazioni di lettura/scrittura. Se assumiamo che ogni documento occupi 50 KB, 10.000 documenti equivarrebbero a circa 0.5 GB. Il costo di storage sarebbe quindi $0.165 al mese (0.5 GB x $0.33). Le operazioni di scrittura e lettura dipenderebbero dall’architettura specifica del sistema e dal numero di accessi ai dati.
in ogni caso solo l’embdiing costa $4 per milione di vettori veramente di ordini inferiori rispetto a OpenAi
Costi Aggiuntivi
Oltre ai costi dei servizi di embedding e storage, è importante considerare le spese relative allo sviluppo e all’implementazione del sistema. La progettazione e l’analisi dell’architettura richiedono un impegno significativo da parte di analisti e architetti, stimabile in circa 10-15 giornate lavorative. Lo sviluppo effettivo del sistema potrebbe richiedere ulteriori 20-25 giornate lavorative, a seconda della complessità del progetto e delle risorse disponibili.

E nel prossimo articolo…

Nel prossimo capitolo del nostro percorso, ci concentreremo sulla creazione di un altro piccolo (4,9 Gb circa) modello LLM locale, appositamente addestrato per la classificazione delle informazioni del nostro studio. L’obiettivo principale sarà la classificazione delle informazioni provenienti da diverse fonti, organizzandole in cinque classificazioni cross delle categorie che riflettono le dimensioni operative dello studio. Questo approccio ci consentirà di gestire in modo strutturato sia i documenti pubblici sia quelli riservati, ponendo le basi per un’architettura solida e sicura.
All’interno dei chunk, abbiamo già inserito una categoria denominata “Attività iniziali”, che ci ha permesso di apprendere come integrare le categorie nel sistema. La categorizzazione è fondamentale: un numero adeguato di categorie contribuisce a prevenire le cosiddette “allucinazioni” nei modelli di linguaggio, come discusso nel primo articolo riguardo alla tecnica RAG. Affidarsi a servizi esterni per la categorizzazione, come chiedere a ChatGPT di suggerire le categorie più plausibili per un documento, potrebbe rappresentare una significativa falla nella sicurezza dei dati. Pertanto, è essenziale che la categorizzazione avvenga internamente.
Fortunatamente, per la sola categorizzazione, esistono modelli leggeri e facilmente implementabili in locale. Nel nostro caso, ne sceglieremo uno e lo installeremo (in locale), garantendo che l’intero processo avvenga all’interno dell’infrastruttura dello studio, senza esporre dati sensibili a servizi esterni.
le 5 diverse dimensioni di categorizzazione estratte verranno poi inserite nei chunk prima dell’embedding, rendendo il contesto semantico ancora più preciso per le successive fasi di interrogazione. Testeremo l’intero flusso, dalla ricezione all’analisi, passando per l’inserimento e l’interazione. Infine, metteremo alla prova il sistema realizzando una chat friendly per simulare una conversazione con i dati legali, osservando dal vivo il comportamento del nostro LLM locale.
Sarà il primo vero banco di prova della nostra architettura . a cui in un altro capitolo affiancheremo un sistema di doppia interrogazione (locale + rimbalzo su chatgpt) con le metodiche RAG. Così facendo personalizzeremo e costruiremo su misura i flussi informativi di uno studio legale moderno.