I modelli open di Flo Health sono diventati più sicuri e utili, ma solo il 47% ha comunque superato entrambi i test

I modelli open di Flo Health sono migliorati in due rigorosi benchmark interni, ma solo il 47% delle risposte valutate ha soddisfatto sia i criteri di sicurezza medica sia quelli di utilità. L'azienda di salute femminile afferma che il suo sistema di post-addestramento ha portato la sicurezza medica dal 34% a circa il 61%. L'utilità è aumentata dal 42% al 76%.

Questi miglioramenti derivano da una pipeline basata su domande sintetiche, giudici AI specializzati e regole di valutazione definite dai clinici. Flo ha poi utilizzato il fine-tuning supervisionato e la Direct Preference Optimization, o DPO, per incorporare il comportamento preferito nei pesi di un modello open.

Il lavoro è rilevante perché Flo serve 81 milioni di utenti attivi mensili, secondo un case study di Databricks pubblicato il 12 ottobre 2026. A questa scala, anche un basso tasso di errore può esporre molte persone a informazioni sanitarie incomplete, eccessivamente rassicuranti o confuse.

Il risultato mette anche in discussione l'approccio più semplice all'AI generativa in ambito sanitario: inviare ogni richiesta a un provider di modelli frontier e affidarsi al suo livello generale di sicurezza. Flo punta sul fatto che modelli più piccoli e adattati possano offrire maggiore controllo e costi di inferenza inferiori. La domanda più difficile è se un benchmark progettato internamente possa dimostrare la sicurezza oltre l'ambiente che lo ha generato.

Flo ha ricostruito il sistema di valutazione prima di addestrare il modello

Il cambiamento centrale non è stato un nuovo chatbot o modello foundation. Flo ha prima trasformato il giudizio clinico in un sistema ripetibile di valutazione e addestramento.

I team medico, prodotto e ingegneristico di Flo hanno suddiviso la qualità delle risposte in due obiettivi principali. La sicurezza medica costituiva la base, mentre l'utilità misurava se una risposta offrisse all'utente un aiuto pertinente e comprensibile.

Questa distinzione sembra ovvia finché un modello non affronta una domanda sanitaria ambigua. Si pensi a qualcuno che chiede perché il ciclo mestruale sia in ritardo. Una risposta che consigli solo di consultare un medico potrebbe evitare un'affermazione pericolosa, ma offrirebbe poco contesto immediato.

Anche la risposta opposta può fallire. Un modello potrebbe elencare stress, viaggi, variazioni di peso o attività fisica, trascurando però una gravidanza o una condizione che richiede una valutazione professionale. Quella risposta sembra più utile, ma le sue omissioni possono creare una falsa rassicurazione.

Flo ha quindi trattato sicurezza e utilità come dimensioni separate che devono essere superate entrambe. Il suo framework finale comprendeva 26 giudici AI, ossia valutatori automatizzati con istruzioni di punteggio e casi di riferimento definiti.

Dodici giudici applicavano vincoli di sicurezza medica. Sei micro-giudici esaminavano comportamenti più circoscritti, come l'aderenza alle fonti, l'impostazione, la voce e aspetti granulari della sicurezza. Otto criteri di utilità valutavano completezza, pertinenza, coerenza e tono.

L'azienda ha inoltre creato regole per schemi ricorrenti di errore. Una regola sulle “cause bilanciate” richiedeva che le risposte includessero spiegazioni sia benigne sia potenzialmente gravi quando entrambe risultavano pertinenti. L'obiettivo era contrastare la tendenza dei modelli conversazionali a produrre una risposta rassicurante che sembri completa.

Flo afferma di aver validato questi giudici rispetto a casi sintetici ed esempi anonimizzati provenienti da esperimenti con gli utenti. Quando un giudice automatizzato non concordava con una valutazione umana iniziale, revisori clinici in cieco decidevano il caso.

Alcuni casi esaminati hanno contribuito a perfezionare i giudici. Flo ha riservato i restanti per misurazioni successive, riducendo il rischio di valutare esclusivamente sugli esempi utilizzati durante la calibrazione.

Questa strategia che pone la valutazione al primo posto è alla base dei risultati di benchmark riportati. Spiega anche perché il progetto sia più significativo di un normale esercizio di fine-tuning.

Un team non può migliorare in modo affidabile la “sicurezza” se questa parola rimane un'aspirazione generica. Flo ha dovuto tradurre l'aspirazione in comportamenti individuali e verificabili prima di poterli utilizzare come segnali di addestramento.

Lo stesso principio si applica oltre il settore sanitario. I team aziendali spesso possiedono un'ampia conoscenza di dominio, ma tale conoscenza è distribuita tra policy, decisioni degli esperti, ricerca ed eccezioni operative. I sistemi che supportano il knowledge blending possono aiutare a organizzare questo materiale, anche se la valutazione dei modelli richiede comunque test specifici per il compito e revisori responsabili.

Il design di Flo crea una risorsa riutilizzabile. Un modello foundation può diventare obsoleto, cambiare licenza o perdere il suo vantaggio di costo. Le rubriche cliniche e i casi di valutazione possono essere trasferiti al modello successivo.

Questa portabilità stabilisce la tensione principale dell'articolo. Flo ottiene controllo sostituendo le ipotesi di sicurezza di un provider generalista con i propri standard. Accetta anche la responsabilità di dimostrare che questi standard siano affidabili su una popolazione di utenti ampia e diversificata.

Perché i modelli open di Flo Health sono diventati una scommessa economica

I modelli open di Flo Health non sono solo un progetto di sicurezza. Sono un tentativo di ridurre la dipendenza da API di modelli costose e controllate dall'esterno.

Flo in precedenza utilizzava il machine learning tradizionale e ha iniziato a esplorare l'AI generativa per esperienze più flessibili e personalizzate. Un singolo modello general-purpose offriva una strada diretta verso queste capacità, ma introduceva tre vincoli.

Il primo era il costo di inferenza su larga scala. Ogni risposta generata può richiedere una richiesta a pagamento verso un provider esterno. Una modesta differenza per richiesta diventa rilevante quando un prodotto serve decine di milioni di utenti mensili.

Flo stima che modelli adattati e sottoposti a fine-tuning possano ridurre i costi di inferenza di un ordine di grandezza rispetto alle API dei modelli frontier. Questa cifra è una stima aziendale, non un'analisi divulgata dei costi di produzione.

Il secondo vincolo era la dipendenza dal ciclo di vita del modello. Un provider API può ritirare un modello, modificarne il comportamento, rivedere le regole di utilizzo o introdurne uno sostitutivo. Ogni cambiamento può costringere un'app sanitaria a ripetere il lavoro di valutazione.

Il terzo era il controllo limitato sul comportamento di dominio. Il fine-tuning della sicurezza di un modello generale deve coprire molti argomenti, culture, prodotti e casi d'uso. Non può codificare automaticamente ogni distinzione che i clinici di Flo considerano importante.

La risposta di lungo periodo di Flo è un sistema AI composto, che combina più modelli e componenti di supporto invece di assegnare ogni compito a un solo modello. Un tale sistema può instradare i compiti semplici verso modelli più piccoli e riservare quelli più grandi alle richieste difficili.

Questo approccio mette sotto pressione la strategia predefinita basata sulle API frontier. La scelta non è semplicemente tra tecnologia open e chiusa. Si tratta di sicurezza generale fornita da un vendor di modelli rispetto a controlli specifici di dominio mantenuti dallo sviluppatore dell'applicazione.

I modelli generali mantengono vantaggi evidenti. I loro provider possono investire ingenti risorse nel pre-addestramento, nelle valutazioni ampie, negli esercizi di red team e nell'infrastruttura. Possono inoltre aggiornare le capacità senza richiedere a ogni cliente di gestire uno stack di addestramento.

Tuttavia, questi vantaggi comportano una distanza dal caso d'uso finale. Un provider non gestisce l'esatta policy di risposta di Flo per sintomi mestruali, domande sulla gravidanza o altri temi sensibili legati alla salute femminile.

Flo sta cercando di colmare questo divario trasformando la propria competenza di dominio in un'infrastruttura di valutazione portabile. Se il modello sottostante cambia, l'azienda può rieseguire i propri giudici, rigenerare le coppie di preferenza e ripetere il post-addestramento.

Questo processo sposta la risorsa scarsa. Il modello di base diventa più sostituibile, mentre il framework di valutazione acquista maggiore valore.

Flo ha già identificato Gemma, Qwen e Kimi come possibili candidati open-weight futuri. I modelli open-weight espongono parametri che gli sviluppatori possono eseguire e modificare, anche se le loro licenze non soddisfano sempre ogni definizione di software open-source.

L'azienda non ha detto che una sola famiglia di modelli gestirà ogni applicazione. La sua strategia tratta invece i modelli come componenti in competizione rispetto a un insieme coerente di requisiti medici e di prodotto.

Questo rende la tesi economica inseparabile dalla sicurezza. Un'inferenza meno costosa ha un valore limitato se un modello produce informazioni sanitarie peggiori. Allo stesso modo, un modello più sicuro potrebbe restare impraticabile se il suo utilizzo costa troppo.

L'approccio di Flo cerca un modello che superi entrambe le soglie. I primi numeri mostrano progressi, ma non dimostrano che l'equilibrio sia completo.

I giudici AI hanno trasformato le regole cliniche in dati di addestramento

Flo ha scalato il giudizio degli esperti insegnando a giudici automatizzati a classificare le risposte candidate, quindi ha usato tali classifiche per modificare il modello stesso.

La pipeline è iniziata con oltre 15.000 domande sintetiche. Flo afferma di aver derivato gli input da segnali generati dal modello o aggregati in forma anonima, anziché da testo libero scritto dagli utenti o informazioni identificabili.

Questa distinzione è importante in un'applicazione sanitaria. Addestrare direttamente sulle conversazioni sensibili degli utenti può introdurre esposizione della privacy, interrogativi sul consenso e rischi di memorizzazione. I prompt sintetici riducono tali rischi, pur introducendo un problema diverso: se le domande generate riflettano accuratamente gli utenti reali.

Per ogni domanda, il sistema ha prodotto più risposte candidate. I 26 giudici hanno poi valutato tali risposte in base a sicurezza, utilità e criteri comportamentali più circoscritti.

Flo ha selezionato gli output migliori e li ha organizzati in coppie di preferenza. Ogni coppia mostrava al modello quale tra due risposte corrispondesse meglio al comportamento desiderato.

Il team ha prima applicato il fine-tuning supervisionato, che addestra un modello a riprodurre esempi selezionati. Ha poi utilizzato DPO, un metodo che aumenta la probabilità delle risposte preferite rispetto a quelle rifiutate.

L'articolo originale su DPO descrive un percorso di ottimizzazione più semplice rispetto al convenzionale reinforcement learning basato sul feedback umano. Evita di addestrare un modello di ricompensa separato durante la fase di ottimizzazione delle preferenze.

Flo descrive il proprio workflow più ampio come reinforcement fine-tuning. Il sistema genera candidati, li valuta, seleziona le risposte migliori, addestra il modello e ripete la valutazione.

La distinzione tra valutazione e addestramento è cruciale. Un giudice AI non si limita a valutare il modello finale. Il suo punteggio influenza quali output diventano esempi positivi, quindi qualsiasi debolezza del giudice può propagarsi nel comportamento addestrato.

Flo ha riscontrato questo problema nel suo primo tentativo. L'utilità è migliorata, ma la sicurezza medica è rimasta relativamente stabile. Le coppie di preferenza non distinguevano con sufficiente precisione tra diversi livelli di qualità medica.

Un segnale binario di superamento o fallimento aveva eliminato informazioni utili. Due risposte potevano entrambe evitare un'affermazione esplicitamente non sicura, mentre una delle due forniva un contesto di sicurezza molto migliore.

Flo ha aggiunto un punteggio di sicurezza graduato dopo il filtro binario. Le risposte che superavano il test di sicurezza di base venivano classificate in base alla completezza con cui soddisfacevano i criteri medici applicabili.

Questo cambiamento ha creato coppie di preferenza più nette. Il modello poteva imparare non solo a evitare una risposta proibita, ma anche a privilegiare una risposta con migliore copertura e maggiori salvaguardie di sicurezza.

Questo è il risultato tecnico più istruttivo del progetto. L'ottimizzazione delle preferenze non può correggere un segnale di ricompensa vago. Se il sistema di valutazione considera equivalenti una cautela superficiale e un'attenta impostazione clinica, il modello non ha motivo di imparare la differenza.

I clinici sono rimasti responsabili della definizione e della validazione dello standard. Non hanno dovuto scrivere o etichettare manualmente ogni coppia di addestramento, il che ha consentito al loro lavoro di influenzare più esempi.

Tuttavia, l'automazione non ha eliminato il collo di bottiglia umano. Ha spostato lo sforzo degli esperti a monte, dall'annotazione ripetuta alla progettazione delle rubriche, alla decisione sui casi difficili e alla calibrazione dei valutatori.

Quella ridistribuzione può rendere la calibrazione per dominio più scalabile. Può anche nascondere errori dietro un punteggio automatizzato se i team smettono di esaminare i disaccordi o i casi rari.

Il metodo dipende quindi da una manutenzione continua dei giudici. Le linee guida mediche cambiano, il linguaggio degli utenti evolve e le nuove famiglie di modelli rivelano debolezze diverse. Una suite di giudici fissa può diventare obsoleta anche se ha ottenuto buoni risultati nella validazione iniziale.

Databricks AI Runtime ha reso il ciclo ripetibile

L'infrastruttura era importante perché Flo doveva rieseguire generazione, valutazione, addestramento e verifica come un unico ciclo controllato.

Flo ha addestrato il modello con 32 GPU NVIDIA H100 usando PyTorch e Fully Sharded Data Parallel. FSDP distribuisce parametri del modello, gradienti e stato dell'ottimizzatore tra le GPU per supportare carichi di addestramento più grandi.

Il suo stack combinava Databricks AI Runtime, LLM Foundry, Compose-RL e MLflow. LLM Foundry gestiva l'addestramento distribuito, mentre Compose-RL forniva il livello di ottimizzazione delle preferenze. MLflow tracciava esperimenti e checkpoint.

La documentazione di AI Runtime descrive un ambiente GPU serverless per carichi di lavoro di deep learning. Nel progetto di Flo, ciò significava che gli ingegneri potevano richiedere risorse di calcolo distribuite senza configurare un nuovo cluster per ogni esperimento.

Il vantaggio non era semplicemente l'accesso agli acceleratori H100. Flo manteneva operazioni sui dati, tracciamento degli esperimenti, addestramento del modello e valutazione all'interno di un unico ambiente.

Questa configurazione riduce l'attrito tra l'individuazione di un errore e la verifica di una correzione. Un team può modificare una rubrica, rigenerare le preferenze, riaddestrare il modello e confrontare il risultato con il checkpoint precedente.

Il primo risultato di sicurezza di Flo mostra perché la velocità di iterazione conta. Il progetto iniziale delle preferenze ha migliorato un obiettivo lasciando l'altro quasi invariato. Il team ha avuto bisogno di un altro ciclo completo per testare una valutazione graduata della sicurezza.

Uno stack frammentato può rendere quel ciclo più lento e più difficile da verificare. I dati di addestramento potrebbero passare attraverso sistemi separati, mentre checkpoint del modello, versioni dei punteggi e report di valutazione restano disconnessi.

Un flusso di lavoro unificato può preservare la relazione tra una domanda, le sue risposte candidate, i punteggi dei giudici, la coppia di preferenze, l'esecuzione dell'addestramento e la valutazione finale. Questa tracciabilità diventa importante quando un modello produce una risposta non sicura e gli investigatori devono capire perché.

Il design supporta anche il piano di Flo di testare modelli open-weight più recenti. Gli ingegneri possono sostituire il modello di base mantenendo gran parte del processo di generazione, valutazione, addestramento e tracciamento.

Questa portabilità è l'argomento più forte per definire la pipeline un asset. La potenza di calcolo viene noleggiata e i modelli fondamentali cambiano rapidamente. Un metodo convalidato per trasformare gli standard di dominio in comportamento del modello può durare più a lungo.

Tuttavia, la comodità della piattaforma non risolve la questione centrale della qualità. Esperimenti più rapidi possono produrre più evidenze, ma possono anche portare a un'ottimizzazione rapida rispetto a un benchmark incompleto.

Il rischio ricorda l'insegnamento finalizzato al test. Un modello può diventare molto bravo a soddisfare le preferenze visibili del valutatore senza diventare altrettanto sicuro di fronte a domande inattese.

L'uso da parte di Flo di casi separati dall'addestramento e di giudizio clinico aiuta ad affrontare questa preoccupazione. Il caso di studio pubblico non divulga abbastanza dettagli per stabilire quanto fossero ampi tali casi o come le prestazioni cambiassero tra i gruppi di utenti.

L'infrastruttura dovrebbe quindi essere intesa come un acceleratore di un processo di governance. Non può sostituire il processo di governance stesso.

Il punteggio combinato del 47% è un progresso, non una prova

Flo ha migliorato entrambe le metriche riportate, ma il tasso di errore residuo impedisce che i risultati costituiscano un'ampia garanzia di sicurezza.

Il modello originale ha ottenuto il 34% nel benchmark di sicurezza medica di Flo e il 42% in utilità. Solo il 16% delle risposte ha superato contemporaneamente entrambe le dimensioni.

Dopo il fine-tuning, il punteggio di sicurezza ha raggiunto circa il 61%. L'utilità è salita al 76%, mentre il punteggio combinato è aumentato al 47%.

Il risultato combinato è quasi triplicato, ma significa anche che il 53% delle risposte valutate non ha soddisfatto entrambi gli standard. Alcune potrebbero essere state sicure ma poco utili. Altre potrebbero essere state utili pur omettendo una salvaguardia medica.

Questa distinzione influenza le decisioni di distribuzione. Un modello può comunque supportare funzionalità limitate quando non è idoneo a fornire consulenza sanitaria senza restrizioni. I controlli del prodotto possono limitare gli argomenti, recuperare informazioni approvate, richiedere chiarimenti o inoltrare i casi sensibili.

Flo non ha divulgato pubblicamente nel caso di studio le dimensioni del benchmark, gli intervalli di confidenza, i risultati per sottogruppi o la gravità degli errori. Inoltre, non identifica il modello open originale utilizzato per questi punteggi riportati.

Senza tali dettagli, i ricercatori esterni non possono stabilire se una piccola serie di casi ricorrenti abbia determinato gran parte del miglioramento. Non possono neppure confrontare direttamente il modello di Flo con API di frontiera o modelli sanitari specializzati.

I 26 giudici sono stati calibrati con il coinvolgimento di clinici, ma i punteggi risultanti restano misurazioni interne. Una replica indipendente darebbe maggiore peso alle affermazioni.

La valutazione esterna è importante perché le domande sintetiche possono differire dalle conversazioni reali. Gli utenti commettono errori di ortografia nei sintomi, omettono il contesto, cambiano argomento, esprimono paura o pongono domande modellate da presupposti culturali.

Un benchmark può anche sottorappresentare condizioni rare ma gravi. Le prestazioni medie potrebbero migliorare mentre un modello continua a fallire nei casi con il maggiore potenziale di danno.

Le linee guida dell'Organizzazione mondiale della sanità sull'IA sanitaria pongono responsabilità, trasparenza e autonomia umana accanto alle prestazioni tecniche. Questi principi sono rilevanti anche quando una funzionalità di IA fornisce informazioni anziché una diagnosi.

Flo deve inoltre operare alla luce della propria storia in materia di privacy. Nel 2021, la Federal Trade Commission ha finalizzato un'ordinanza che risolveva le accuse secondo cui Flo aveva condiviso informazioni sanitarie sensibili con fornitori di analisi dopo aver promesso di mantenerle private.

Il registro dell'accordo con la FTC riguarda pratiche precedenti relative ai dati, non la nuova pipeline di addestramento. Resta rilevante perché la fiducia degli utenti in un'app sanitaria riguarda sia ciò che dice il modello sia il modo in cui il sistema gestisce informazioni sensibili.

Flo afferma che il suo processo di dati sintetici ha evitato testo libero scritto dagli utenti e informazioni identificabili. L'azienda offre anche Anonymous Mode, che, secondo quanto dichiara, può separare i dati sanitari dall'identità dell'utente.

Queste misure affrontano una parte del rischio, ma rimangono diverse domande. I segnali aggregati possono comunque codificare squilibri demografici. I dati sintetici possono riprodurre le assunzioni del modello che li ha generati. I giudici automatizzati possono premiare un linguaggio sicuro di sé che assomiglia alla competenza.

L'espressione “privacy-first” dovrebbe quindi descrivere una direzione progettuale, non una certificazione esterna già completata di questa pipeline. Allo stesso modo, “più sicuro” è un risultato comparativo di benchmark, non la prova che ogni risposta generata sia medicalmente sicura.

Nessuno di questi limiti annulla i progressi. Chiariscono ciò che i numeri dimostrano.

Flo ha mostrato che il suo sistema interno può orientare un modello open verso un comportamento definito dai clinici nel proprio set di valutazione. Non ha dimostrato che il modello possa sostituire l'assistenza clinica o rispondere in sicurezza a ogni domanda sanitaria del mondo reale.

Tre segnali mostreranno se la strategia regge

La fase successiva dovrebbe essere valutata attraverso la replica tra modelli, il monitoraggio nel mondo reale e una valutazione indipendente, non con un altro aumento isolato del benchmark.

Il primo segnale è se Flo riproduce il miglioramento su Gemma, Qwen o Kimi. L'azienda ha indicato queste famiglie di modelli come candidati futuri per la propria pipeline.

Guadagni comparabili tra diversi modelli di base sosterrebbero l'affermazione di Flo secondo cui il sistema di valutazione e addestramento è l'asset durevole. Un forte calo con un altro modello suggerirebbe che il risultato attuale dipende in larga misura da un modello di base non divulgato.

Il confronto dovrebbe preservare lo stesso set di valutazione separato dall'addestramento, aggiungendo al contempo test progettati per le debolezze specifiche di ciascun modello. Altrimenti, i team rischiano di selezionare il modello che meglio si adatta a un test familiare.

Il secondo segnale è il monitoraggio in produzione. Flo dovrebbe riportare con quale frequenza i sistemi distribuiti rifiutano, inoltrano, recuperano informazioni approvate o ricevono feedback negativo sulla qualità.

I punteggi aggregati dei benchmark non possono rivelare se gli errori si concentrano su gravidanza, contraccezione, dolore, menopausa o sintomi urgenti. Una rendicontazione a livello di categoria mostrerebbe dove il modello resta inaffidabile.

Il monitoraggio dovrebbe inoltre distinguere le risposte di scarso valore da quelle potenzialmente dannose. Una risposta ripetitiva e una risposta pericolosamente rassicurante non dovrebbero avere lo stesso peso operativo.

Il terzo segnale è la validazione indipendente. Clinici esterni e ricercatori sulla sicurezza dovrebbero testare il sistema con casi che il processo di addestramento di Flo non ha generato né selezionato.

I revisori indipendenti possono sondare cambiamenti di distribuzione, variazioni demografiche, formulazioni avversarie, uso multilingue e scenari medici rari. Possono anche valutare se i giudici automatizzati favoriscano uno stile comunicativo particolare rispetto alla sostanza clinica.

Le evidenze provenienti da questi tre segnali rafforzerebbero il caso dei modelli open di Flo Health. La mancata pubblicazione di risultati più ampi lascerebbe le affermazioni attuali dipendenti da un caso di studio scritto dal fornitore e da misurazioni progettate dall'azienda.

Per gli sviluppatori, la lezione immediata non è copiare lo stack esatto di Flo. È trattare la progettazione della valutazione come parte del prodotto, anziché come un test svolto dopo l'addestramento.

Anche per gli acquirenti aziendali la domanda chiave sta cambiando. L'approvvigionamento dei modelli dovrebbe esaminare chi definisce il comportamento accettabile, come tali regole diventano test e se il sistema conserva evidenze per ogni esecuzione di addestramento.

I knowledge worker e gli utenti delle app sanitarie dovrebbero cercare confini più chiari. Un prodotto affidabile dovrebbe spiegare quando l'output generativo è informativo, quando recupera materiale revisionato e quando indirizza una persona verso cure professionali.

I miglioramenti riportati da Flo rendono il suo approccio degno di attenzione. L'irrisolto 53% rende lo scrutinio altrettanto necessario.

Il prossimo aggiornamento decisivo non sarà un'esecuzione su GPU più ampia. Sarà la prova che gli stessi miglioramenti di sicurezza resistono a un nuovo modello di base, a domande imprevedibili degli utenti e a una revisione clinica indipendente. Fino ad allora, i lettori dovrebbero considerare il sistema un promettente metodo di post-addestramento, non un sostituto verificato del giudizio medico.