<\/figure>\n<\/div>\n\n\nNel nostro early-stage, puntavamo tutto sulla velocit\u00e0 di setup e sulla massima versatilit\u00e0. Quindi, abbiamo scelto la strada “tutto LLM”. Abbiamo costruito un ground truth<\/em> di 20 bollette (luce, gas, dual, PDF nativi e scansioni) e abbiamo messo alcuni modelli sul ring. <\/p>\n\n\n\nLLM Selection: vietato tirare a indovinare<\/h2>\n\n\n\n Scegliere un modello “a sensazione” non \u00e8 un’opzione accettabile in ingegneria. \u00c8 il metodo rigoroso basato sui dati che trasforma una scommessa in una decisione architetturale solida. Ecco il processo che abbiamo seguito:<\/p>\n\n\n\n
\nSet di validazione:<\/strong> Senza una verit\u00e0 di riferimento (ground truth<\/em>), non stai misurando assolutamente niente. Abbiamo usato le nostre 20 bollette eterogenee per coprire casistiche reali: provider diversi, versioni multiple della bolletta per lo stesso fornitore, mix di formati (immagine e PDF) e tipologie di fornitura (gas, luce, dual).<\/li>\n\n\n\nPrompt Engineering:<\/strong> Abbiamo scritto il prompt per fornire istruzioni chiare e inequivocabili al modello.<\/li>\n\n\n\nLa selezione dei contendenti:<\/strong> Abbiamo individuato un subset di 4 modelli generativi della stessa “portata”, ideali per il task. Nello specifico, abbiamo calato nell’arena di test Amazon Nova 2 Lite<\/strong>, Amazon Nova Pro<\/strong>, Claude 3 Haiku<\/strong> e Claude 4.5 Sonnet<\/strong>.<\/li>\n\n\n\nIl Benchmark spietato:<\/strong> Abbiamo fatto girare i modelli sul set di validazione per estrarre risultati oggettivi.<\/li>\n<\/ul>\n\n\n\nIl vincitore assoluto per rapporto qualit\u00e0\/prezzo? Claude 4.5 Sonnet<\/strong>, orchestrato ovviamente tramite Amazon Bedrock<\/strong>.<\/p>\n\n\n\nTutto molto bello. Ma quanto mi costa?<\/h2>\n\n\n\n Il PoC \u00e8 andato su in un attimo: disaccoppiamento con Amazon API Gateway<\/strong>, storage su Amazon S3<\/strong>, AWS Lambda<\/strong> a fare da collante e Bedrock a fare la magia. Il sistema estraeva i dati con una precisione spaventosa. Ma c’era un problema: usare un LLM di fascia alta per ogni singola bolletta<\/em>, specialmente su volumi di produzione, non \u00e8 finanziariamente sostenibile. \u00c8 come usare una Ferrari per andare a fare la spesa dietro l’angolo.<\/p>\n\n\n\nDovevamo ottimizzare. E per farlo, abbiamo guardato in faccia i nostri dati. Le bollette hanno due caratteristiche chiave:<\/p>\n\n\n\n
\nI formati di input sono pochi (PDF nativo o immagine).<\/li>\n\n\n\n I template sono ripetitivi: le bollette provenienti da stesso provider ragionevolmente avranno layout comune (a meno di un cambio di versione).<\/li>\n<\/ol>\n\n\n\nPerch\u00e9 pagare l’LLM per far fatica a capire una struttura che in realt\u00e0 abbiamo gi\u00e0 visto?<\/p>\n\n\n\n
Il pivot: Embeddings e il ritorno dell’OCR Classico<\/h2>\n\n\n\n Serviva un modo per capire istantaneamente se un documento apparteneva a un template noto. I modelli di computer vision puri sono veloci ma fragili, i modelli multimodali sono troppo pesanti. La soluzione? L’algoritmo di Embedding<\/strong>. Trasformiamo il template della bolletta in un vettore numerico (un’impronta digitale oggettiva). Per capire se una nuova bolletta corrisponde a un layout noto, basta calcolare la cosine similarity<\/em> tra vettori. Rapido, indolore ed economico.<\/p>\n\n\n\nAbbiamo cos\u00ec progettato un’architettura Versione 2.0<\/strong> a due velocit\u00e0:<\/p>\n\n\n\n\nRouting:<\/strong> Una AWS Lambda<\/strong> prende il file, lo valida e, se serve, fa pre-processing sulle immagini.<\/li>\n\n\n\nOrchestrazione:<\/strong> Qui entra in gioco AWS Step Functions Express<\/strong>, che gestisce la logica di confronto vettoriale cercando le “firme” dei template gi\u00e0 salvati su Amazon DynamoDB<\/strong>.<\/li>\n<\/ul>\n\n\n\nDa qui, il flusso si divide: <\/p>\n\n\n\n
\nLa Fast Track (Layout noto):<\/strong> Il template esiste gi\u00e0. Invece di svegliare l’LLM, deviamo il traffico su una Lambda self-contained<\/em> che usa il caro, vecchio OCR classico. Sapendo gi\u00e0 dove guardare (le coordinate spaziali sono salvate a DB), l’OCR estrae il dato in millisecondi a un costo ridicolo. <\/li>\n\n\n\nLa Discovery Track (Layout sconosciuto):<\/strong> Il template \u00e8 nuovo. Chiamiamo Amazon Bedrock<\/strong>. L’LLM estrae semanticamente le info, ma non fa solo quello: mappiamo i bounding boxes<\/em> (le coordinate delle chiavi) e calcoliamo l’embedding del nuovo documento. Salviamo questa “nuova firma” su DynamoDB. Dalla bolletta successiva, questo stesso layout andr\u00e0 in Fast Track!<\/li>\n<\/ul>\n\n\n\nIl risultato? Un ecosistema auto-apprendente. I costi crollano man mano che il sistema immagazzina nuovi template, e l’LLM lavora solo quando serve davvero materia grigia.<\/p>\n\n\n\n
Human-in-the-Loop: la fiducia \u00e8 bene, il controllo \u00e8 meglio<\/h2>\n\n\n\n Delegare tutto a un algoritmo in produzione \u00e8 il modo pi\u00f9 rapido per non dormire la notte. Per questo abbiamo inserito un pattern Human-in-the-Loop (HITL)<\/strong> come perno della governance:<\/p>\n\n\n\n\nTracciabilit\u00e0:<\/strong> Ogni dato estratto ha la sua impronta digitale spaziale e un rigoroso confidence score<\/em>.<\/li>\n\n\n\nBackoffice Serverless:<\/strong> Abbiamo tirato su una Single Page Application in React (hostata su S3<\/strong> e distribuita globalmente in CDN con CloudFront<\/strong>). Qui gli operatori possono validare visivamente i dati sovrapposti all’immagine originale della bolletta. Le API backend? Ovviamente Lambda.<\/li>\n\n\n\nAlerting Proattivo:<\/strong> Cosa succede se Eni cambia improvvisamente il layout delle fatture? Il confidence score medio crolla. Amazon CloudWatch<\/strong> se ne accorge, fa scattare un allarme e Amazon SNS<\/strong> inonda di email il team di ingegneria prima che il business se ne renda conto.<\/li>\n<\/ul>\n\n\n\nTakeaways<\/h2>\n\n\n\n L’AI generativa non \u00e8 la soluzione a tutto, \u00e8 uno strumento. La maturit\u00e0 architetturale nel Cloud non si dimostra sparando Foundation Models su ogni singolo task sperando che funzioni. La vera Ingegneria (con la I maiuscola) sta nell’orchestrazione: usate i Large Language Models<\/strong> solo per la pura capacit\u00e0 cognitiva, affidatevi all’OCR classico<\/strong> per spingere l’efficienza sui task deterministici, e usate gli Embeddings<\/strong> per il routing intelligente.<\/p>\n\n\n\nIn questo modo avrete un’architettura che non solo scala da paura, ma impara da sola, vi lascia il pieno controllo sui dati e fa sorridere il vostro FinOps.<\/p>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n Proud2beCloud<\/strong> is a blog by beSharp<\/a>, an Italian APN Premier Consulting Partner expert in designing, implementing, and managing complex Cloud infrastructures and advanced services on AWS. Before being writers, we are Cloud Experts working daily with AWS services since 2007. We are hungry readers, innovative builders, and gem-seekers. On Proud2beCloud, we regularly share our best AWS pro tips, configuration insights, in-depth news, tips&tricks, how-tos, and many other resources. Take part in the discussion!<\/p>\n","protected":false},"excerpt":{"rendered":"L’utilizzo dell’AI Generativa ormai sembra essere diventato un must, ma poi ci si scontra con la realt\u00e0: ogni azienda siede […]<\/p>\n","protected":false},"author":40,"featured_media":8770,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[474],"tags":[],"class_list":["post-8760","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-analytics"],"yoast_head":"\n
Dai Documenti ai Dati: estrarre valore con LLM, Embeddings e Human-in-the-Loop senza farsi prosciugare il portafoglio - Proud2beCloud Blog<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n\t \n\t \n\t \n