Organizzazioni sanitarie, legali e del settore pubblico stanno adottando l'AI per gestire grandi volumi di documenti. Tuttavia, molti di questi dati sono troppo sensibili per strumenti AI consumeristici. Hathr.AI, leader nell'AI sicura per settori regolamentati, risponde a questa esigenza con il suo strumento allineato a HIPAA, che si integra con Amazon Bedrock in AWS GovCloud (US), una regione AWS isolata con autorizzazione FedRAMP High.

Migliaia di organizzazioni, dai singoli professionisti al governo federale degli Stati Uniti, utilizzano lo strumento di Hathr.AI per revisioni di cartelle cliniche, cronologie mediche legali, informazioni non classificate controllate e codifica, fatturazione e richieste mediche. Hathr.AI non addestra mai i modelli sui dati dei clienti, mantiene le informazioni segmentate all'interno del proprio ambiente AWS GovCloud (US) e consente ai clienti di decidere per quanto tempo conservare i loro file.

Un tipico utente, come un'infermiera di un hospice, potrebbe caricare una cartella di 400 pagine, ottenere un riepilogo di idoneità e cancellare il file prima di pranzo. Per rendere ogni caricamento ricercabile, Hathr.AI divide il documento in frammenti, converte ogni frammento in un embedding vettoriale e scrive questi embedding nell'indice vettoriale del cliente. Quando il cliente cancella il file, Hathr.AI cancella immediatamente quei vettori. Questo crea un carico di lavoro vettoriale in cui i dati vengono costantemente creati e cancellati.

La sfida: Ricerca vettoriale ad alto turnover su un cluster di database

Hathr.AI ha lanciato il RAG su Amazon DocumentDB vector search perché il testo dei documenti già risiedeva lì, e un cluster che conteneva frammenti, metadati e embedding serviva bene il team a basso volume. Tuttavia, gli utenti di Hathr.AI creano e rimuovono vettori tutto il giorno. Un caricamento scrive centinaia o migliaia di embedding, e una cancellazione li rimuove pochi minuti o ore dopo.

Un impegno contrattuale di non ritenzione significa che una cancellazione deve avere effetto immediato, quindi il team non può spingere le cancellazioni in un lavoro di pulizia notturno. Il carico di lavoro vettoriale ad alto turnover di Hathr.AI competeva con il set di lavoro transazionale per la memoria delle istanze, quindi il team continuava a dimensionare fino a quando non aveva quadruplicato le dimensioni del cluster.

Ogni cliente condivideva la stessa capacità del cluster. Un'ondata di ingestione di grandi dimensioni da parte di un cliente poteva rallentare la chat per gli altri, e ogni aumento di scala aumentava il costo dell'intero database per acquistare headroom per un carico di lavoro. Hathr.AI aveva bisogno di un archivio vettoriale adatto a un alto turnover che mantenesse i vettori di ogni cliente separati, funzionasse in AWS GovCloud (US) e lasciasse il team senza cluster da gestire.

Perché Hathr.AI ha scelto Amazon S3 Vectors

Amazon S3 Vectors memorizza e interroga gli embedding vettoriali tramite un set dedicato di API, senza infrastruttura da provisionare. Hathr.AI lo ha scelto per quattro motivi:

    • Isolamento dell'indice per cliente – Un bucket vettoriale contiene fino a 10.000 indici vettoriali, e ogni indice ha il proprio Amazon Resource Name (ARN). Hathr.AI fornisce a ogni cliente il proprio indice e delimita le politiche AWS Identity and Access Management (IAM) a quell'ARN.
    • Nessun cluster da gestire – Hathr.AI non ha istanze da dimensionare e nessun ricostruzione dell'indice da programmare.
    • Supporto per AWS GovCloud (US) – S3 Vectors è diventato disponibile in AWS GovCloud (US-East) e AWS GovCloud (US-West) a luglio 2026, quindi i vettori di Hathr.AI rimangono all'interno dello stesso confine del resto dell'applicazione.
    • Prestazioni costanti sotto turnover – AWS riporta latenze fino a 100 millisecondi per query più frequenti e latenze inferiori al secondo per query infrequenti. I numeri di produzione di Hathr.AI corrispondono, e il suo volume di cancellazione non ha effetti visibili su di essi.

Panoramica della soluzione

La figura seguente mostra l'architettura di recupero dello strumento Hathr.AI. L'ingestione dei documenti avviene lungo la parte superiore, e il recupero agentico avviene lungo la parte inferiore. Entrambi i percorsi condividono uno strato di dati per tenant: S3 Vectors contiene embedding in un indice per cliente, e Amazon DocumentDB contiene i frammenti di testo a cui puntano questi embedding. L'ingestione avviene su AWS Step Functions, e ogni fase del flusso di lavoro è una funzione AWS Lambda.

Ogni documento ottiene la propria esecuzione con una cronologia duratura, e ogni fase ha la propria politica di riavvio, quindi una chiamata Amazon Bedrock limitata riavvia senza riavviare il documento. Step Functions fa anche superare al pipeline il timeout di 15 minuti di Lambda. L'embedding di un documento grande può richiedere più di un'ora, quindi uno stato Map divide i frammenti in batch e esegue ogni batch nella propria invocazione Lambda.

Un utente carica un documento, e l'applicazione Hathr.AI avvia un flusso di lavoro Step Functions per quel file. Le funzioni Lambda analizzano e dividono in frammenti il documento e chiamano un modello di embedding in Amazon Bedrock. Lambda scrive ogni frammento di testo in Amazon DocumentDB e il suo embedding nell'indice S3 Vectors per quel cliente, utilizzando l'ID del frammento come chiave del vettore.

Un utente fa una domanda, e la richiesta raggiunge un servizio Strands Agents su Amazon ECS con AWS Fargate. L'agente utilizza Amazon Bedrock per analizzare la conversazione e determinare se cercare e cosa cercare. Lo strumento di ricerca dell'agente interroga l'indice del cliente in S3 Vectors, carica il testo del frammento corrispondente da Amazon DocumentDB e lo restituisce al modello. Il modello può riformulare e cercare di nuovo prima di rispondere.

Quando un utente cancella un documento, l'applicazione Hathr.AI chiama DeleteVectors su quell'indice del cliente e poi rimuove i suoi frammenti di testo da Amazon DocumentDB. La cancellazione di tutti i documenti di un utente, o la chiusura dell'account, cancella l'intero indice con DeleteIndex. Amazon CloudWatch raccoglie metriche da ogni fase e segnala errori, latenza e tempo di ingestione.

Decisioni architettoniche

Hathr.AI ha costruito questo pattern intorno a quattro decisioni architettoniche.

Decisione 1: Ingestire documenti con Step Functions e Lambda

Ogni caricamento avvia un'esecuzione Step Functions che esegue funzioni Lambda per estrarre il testo, dividerlo in frammenti e generare embedding in Amazon Bedrock.

Decisione 2: Scrivere vettori nell'indice del cliente

Lambda scrive ogni frammento in Amazon DocumentDB per primo, poi scrive l'embedding in S3 Vectors con l'ID del frammento come chiave del vettore. Hathr.AI memorizza document_id come metadati filtrabili in modo che una query possa mirare ai file selezionati dall'utente. La pre-filtraggio dei metadati S3 Vectors è ora disponibile in AWS GovCloud (US). Gli indici nei nuovi bucket vettoriali lo utilizzano per impostazione predefinita, il che può migliorare il richiamo per query selettive come il filtraggio dei file selezionati dall'utente.

Decisione 3: Cancellare vettori con il documento

Il percorso di cancellazione di Hathr.AI legge gli ID dei frammenti per un documento da Amazon DocumentDB, chiama DeleteVectors sull'indice del cliente in batch di 500 e poi rimuove i frammenti. Ogni cancellazione interessa un solo indice del cliente, quindi una giornata di cancellazione pesante per un cliente lascia inalterate le prestazioni di query per gli altri.

Decisione 4: Migrare dietro una feature flag

Hathr.AI ha costruito i percorsi di lettura e scrittura S3 Vectors dietro una feature flag, in modo da poterli abilitare per i clienti uno alla volta. Questo ha permesso al team di monitorare le metriche e risolvere i problemi prima di abilitare la nuova funzionalità per tutti i clienti.