Os modelos abertos da Flo Health ficaram mais seguros e úteis, mas 47% ainda passaram nos dois testes

Os modelos abertos da Flo Health melhoraram em dois benchmarks internos exigentes, mas apenas 47% das respostas avaliadas atenderam simultaneamente aos critérios de segurança médica e utilidade. A empresa de saúde feminina afirma que seu sistema de pós-treinamento elevou a segurança médica de 34% para cerca de 61%. A utilidade aumentou de 42% para 76%.

Esses ganhos vieram de um pipeline baseado em perguntas sintéticas, avaliadores de IA especializados e regras de avaliação definidas por clínicos. A Flo então usou ajuste fino supervisionado e Direct Preference Optimization, ou DPO, para incorporar o comportamento preferido aos pesos de um modelo aberto.

O trabalho é relevante porque a Flo atende 81 milhões de usuários ativos mensais, segundo um estudo de caso da Databricks publicado em 12 de outubro de 2026. Nessa escala, até mesmo uma baixa taxa de erro pode expor muitas pessoas a informações de saúde incompletas, excessivamente tranquilizadoras ou confusas.

O resultado também desafia a abordagem mais simples para IA generativa voltada à saúde: enviar todas as solicitações a um provedor de modelos de fronteira e depender de sua camada geral de segurança. A Flo aposta que modelos menores e personalizados podem oferecer mais controle e menores custos de inferência. A questão mais difícil é se um benchmark concebido internamente consegue comprovar segurança além do ambiente que o criou.

A Flo reconstruiu o sistema de avaliação antes de treinar o modelo

A mudança central não foi um novo chatbot nem um modelo de base. A Flo primeiro transformou o julgamento clínico em um sistema repetível de avaliação e treinamento.

As equipes médicas, de produto e de engenharia da Flo dividiram a qualidade das respostas em dois objetivos principais. A segurança médica formava a base, enquanto a utilidade media se uma resposta oferecia ao usuário ajuda relevante e compreensível.

Essa distinção parece óbvia até que um modelo enfrente uma pergunta de saúde ambígua. Considere alguém perguntando por que a menstruação está atrasada. Uma resposta que apenas recomenda buscar atendimento médico pode evitar uma afirmação perigosa, mas oferece pouco contexto imediato.

A resposta oposta também pode falhar. Um modelo pode listar estresse, viagens, mudanças de peso ou exercícios, deixando de mencionar gravidez ou uma condição que exija avaliação profissional. Essa resposta parece mais útil, mas suas omissões podem criar uma falsa sensação de segurança.

Por isso, a Flo tratou segurança e utilidade como dimensões separadas que devem ser aprovadas em conjunto. Seu framework final incluiu 26 avaliadores de IA, ou seja, avaliadores automatizados com instruções de pontuação e casos de referência definidos.

Doze avaliadores aplicavam restrições de segurança médica. Seis microavaliadores examinavam comportamentos mais específicos, como fundamentação, enquadramento, voz e segurança detalhada. Oito critérios de utilidade avaliavam completude, relevância, coerência e tom.

A empresa também criou regras para padrões recorrentes de falha. Uma regra de “causas equilibradas” exigia que as respostas abordassem explicações benignas e potencialmente graves quando ambas fossem relevantes. Isso visava a tendência dos modelos conversacionais de produzir uma resposta tranquilizadora que soa completa.

A Flo afirma ter validado esses avaliadores com casos sintéticos e exemplos anonimizados de experimentos com usuários. Quando um avaliador automatizado discordava de uma avaliação humana inicial, revisores clínicos às cegas julgavam o caso.

Alguns casos revisados ajudaram a refinar os avaliadores. A Flo reservou os demais para medições posteriores, reduzindo o risco de avaliar exclusivamente os exemplos usados durante a calibração.

Essa estratégia de avaliação em primeiro lugar é a base dos resultados de benchmark divulgados. Ela também explica por que o projeto é mais significativo do que um exercício rotineiro de ajuste fino.

Uma equipe não consegue melhorar “segurança” de forma confiável se essa palavra continuar sendo uma aspiração ampla. A Flo precisou expressar essa aspiração como comportamentos individuais e testáveis antes de poder usá-los como sinais de treinamento.

O mesmo princípio se aplica além da área da saúde. Equipes corporativas frequentemente possuem amplo conhecimento de domínio, mas esse conhecimento está disperso entre políticas, decisões de especialistas, pesquisas e exceções operacionais. Sistemas que apoiam a combinação de conhecimento podem ajudar a organizar esse material, embora a avaliação de modelos ainda exija testes específicos para cada tarefa e revisores responsáveis.

O design da Flo cria um ativo reutilizável. Um modelo de base pode se tornar obsoleto, mudar de licença ou perder sua vantagem de custo. As rubricas clínicas e os casos de avaliação podem migrar para o próximo modelo.

Essa portabilidade estabelece a principal tensão do artigo. A Flo ganha controle ao substituir as premissas de segurança de um provedor geral por seus próprios padrões. Ela também assume a responsabilidade de comprovar que esses padrões são confiáveis em uma população de usuários ampla e diversa.

Por que os modelos abertos da Flo Health se tornaram uma aposta econômica

Os modelos abertos da Flo Health não são apenas um projeto de segurança. Eles representam uma tentativa de reduzir a dependência de APIs de modelos caros e controlados externamente.

A Flo já usava aprendizado de máquina tradicional e começou a explorar IA generativa para experiências mais flexíveis e personalizadas. Um único modelo de uso geral oferecia um caminho direto para essas capacidades, mas introduzia três limitações.

A primeira era o custo de inferência em escala. Cada resposta gerada pode exigir uma solicitação paga a um provedor externo. Uma pequena diferença por solicitação se torna relevante quando um produto atende dezenas de milhões de usuários mensais.

A Flo estima que modelos personalizados e ajustados podem reduzir os custos de inferência em uma ordem de magnitude em comparação com APIs de modelos de fronteira. Esse número é uma estimativa da empresa, não uma análise divulgada de custos de produção.

A segunda limitação era a dependência do ciclo de vida do modelo. Um provedor de API pode retirar um modelo, alterar seu comportamento, revisar regras de uso ou apresentar um substituto. Cada mudança pode obrigar um aplicativo de saúde a repetir o trabalho de avaliação.

A terceira era o controle limitado sobre o comportamento de domínio. O ajuste de segurança de um modelo geral precisa abranger muitos temas, culturas, produtos e casos de uso. Ele não consegue codificar automaticamente cada distinção que os clínicos da Flo consideram importante.

A resposta de longo prazo da Flo é um sistema de IA composto, que combina múltiplos modelos e componentes de apoio em vez de atribuir todas as tarefas a um único modelo. Esse sistema pode direcionar tarefas simples para modelos menores e reservar modelos maiores para solicitações difíceis.

Essa rota pressiona a estratégia padrão de APIs de fronteira. A escolha não é simplesmente entre tecnologia aberta e fechada. Trata-se de segurança geral fornecida por um fornecedor de modelos versus controles específicos de domínio mantidos pelo desenvolvedor da aplicação.

Os modelos gerais mantêm vantagens claras. Seus provedores podem investir pesadamente em pré-treinamento, avaliações amplas, exercícios de red team e infraestrutura. Eles também podem atualizar capacidades sem exigir que cada cliente opere uma pilha de treinamento.

Ainda assim, essas vantagens vêm acompanhadas de distância em relação ao caso de uso final. Um provedor não é responsável pela política exata de respostas da Flo para sintomas menstruais, dúvidas sobre gravidez ou outros temas sensíveis de saúde feminina.

A Flo tenta reduzir essa lacuna transformando sua expertise de domínio em infraestrutura portátil de avaliação. Se o modelo subjacente mudar, a empresa pode executar novamente seus avaliadores, regenerar pares de preferência e repetir o pós-treinamento.

Esse processo desloca o recurso escasso. O modelo base se torna mais substituível, enquanto o framework de avaliação se torna mais valioso.

A Flo já identificou Gemma, Qwen e Kimi como possíveis candidatos futuros de pesos abertos. Modelos de pesos abertos expõem parâmetros que os desenvolvedores podem executar e modificar, embora suas licenças nem sempre atendam a todas as definições de software de código aberto.

A empresa não disse que uma única família de modelos assumirá todas as aplicações. Em vez disso, sua estratégia trata os modelos como componentes que competem sob um conjunto consistente de requisitos médicos e de produto.

Isso torna a alegação econômica inseparável da segurança. Uma inferência de menor custo tem valor limitado se um modelo produzir informações de saúde piores. Da mesma forma, um modelo mais seguro pode continuar impraticável se seu atendimento custar caro demais.

A abordagem da Flo busca um modelo que ultrapasse ambos os limiares. Os primeiros números mostram progresso, mas não estabelecem que o equilíbrio esteja completo.

Avaliadores de IA transformaram regras clínicas em dados de treinamento

A Flo ampliou o julgamento de especialistas ao ensinar avaliadores automatizados a classificar respostas candidatas e, em seguida, usar essas classificações para alterar o próprio modelo.

O pipeline começou com mais de 15.000 perguntas sintéticas. A Flo afirma que derivou as entradas de sinais gerados por modelos ou agregados anonimamente, em vez de texto livre escrito por usuários ou informações identificáveis.

Essa distinção é importante em uma aplicação de saúde. Treinar diretamente com conversas sensíveis de usuários pode introduzir exposição de privacidade, questões de consentimento e riscos de memorização. Prompts sintéticos reduzem esses riscos, embora introduzam outro problema: se as perguntas geradas refletem os usuários reais com precisão.

Para cada pergunta, o sistema produziu várias respostas candidatas. Os 26 avaliadores então pontuaram essas respostas segundo critérios de segurança, utilidade e comportamentos mais específicos.

A Flo selecionou as saídas mais fortes e as organizou em pares de preferência. Cada par mostrava ao modelo qual de duas respostas correspondia melhor ao comportamento desejado.

A equipe primeiro aplicou ajuste fino supervisionado, que treina um modelo para reproduzir exemplos selecionados. Em seguida, usou DPO, um método que aumenta a probabilidade de respostas preferidas em relação às rejeitadas.

O artigo original sobre DPO descreve uma rota de otimização mais simples do que o aprendizado por reforço convencional com feedback humano. Ele evita treinar um modelo de recompensa separado durante a etapa de otimização por preferências.

A Flo descreve seu fluxo de trabalho mais amplo como ajuste fino por reforço. O sistema gera candidatos, pontua-os, seleciona respostas melhores, treina o modelo e executa novamente a avaliação.

A distinção entre avaliação e treinamento é crucial. Um avaliador de IA não apenas classifica o modelo final. Sua pontuação influencia quais saídas se tornam exemplos positivos; portanto, qualquer fraqueza no avaliador pode se propagar para o comportamento treinado.

A Flo encontrou esse problema em sua primeira tentativa. A utilidade melhorou, mas a segurança médica permaneceu relativamente estável. Os pares de preferência não faziam distinções suficientemente precisas entre níveis de qualidade médica.

Um sinal binário de aprovação ou reprovação havia descartado informações úteis. Duas respostas podem evitar uma afirmação explicitamente insegura, enquanto uma delas oferece um contexto de segurança muito melhor.

A Flo adicionou uma pontuação graduada de segurança após a barreira binária. As respostas que passavam no teste básico de segurança eram classificadas conforme o grau em que atendiam integralmente aos critérios médicos aplicáveis.

Essa mudança criou pares de preferência mais precisos. O modelo poderia aprender não apenas a evitar uma resposta proibida, mas também a favorecer uma resposta com melhor cobertura e salvaguardas de segurança.

Este é o resultado técnico mais instrutivo do projeto. A otimização por preferências não pode reparar um sinal de recompensa vago. Se o sistema de avaliação trata cautela superficial e enquadramento clínico cuidadoso como equivalentes, o modelo não tem motivo para aprender a diferença.

Os clínicos continuaram responsáveis por definir e validar o padrão. Eles não precisaram escrever ou rotular manualmente cada par de treinamento, o que permitiu que seu trabalho influenciasse mais exemplos.

No entanto, a automação não eliminou o gargalo humano. Ela deslocou o esforço especializado para etapas anteriores, da anotação repetida para o design de rubricas, a adjudicação de casos difíceis e a calibração de avaliadores.

Essa redistribuição pode tornar o ajuste por domínio mais escalável. Também pode ocultar erros por trás de uma pontuação automatizada se as equipes deixarem de revisar divergências ou casos raros.

Portanto, o método depende da manutenção contínua dos avaliadores. As orientações médicas mudam, a linguagem dos usuários evolui e novas famílias de modelos expõem diferentes fragilidades. Um conjunto fixo de avaliadores pode ficar desatualizado mesmo que tenha apresentado bom desempenho durante sua validação original.

Databricks AI Runtime Tornou o Ciclo Repetível

A infraestrutura foi importante porque a Flo precisava executar novamente geração, pontuação, treinamento e avaliação como um único ciclo controlado.

A Flo treinou com 32 GPUs NVIDIA H100 usando PyTorch e Fully Sharded Data Parallel. O FSDP distribui parâmetros do modelo, gradientes e estado do otimizador entre as GPUs para suportar cargas de trabalho de treinamento maiores.

Sua stack combinou Databricks AI Runtime, LLM Foundry, Compose-RL e MLflow. O LLM Foundry gerenciou o treinamento distribuído, enquanto o Compose-RL forneceu a camada de otimização por preferências. O MLflow acompanhou experimentos e checkpoints.

A documentação do AI Runtime descreve um ambiente de GPU sem servidor para cargas de trabalho de deep learning. No projeto da Flo, isso significava que os engenheiros podiam solicitar computação distribuída sem configurar um novo cluster para cada experimento.

O benefício não foi simplesmente o acesso aos aceleradores H100. A Flo manteve operações de dados, acompanhamento de experimentos, treinamento de modelos e avaliação dentro de um mesmo ambiente.

Esse arranjo reduz o atrito entre identificar uma falha e testar uma correção. Uma equipe pode ajustar uma rubrica, regenerar preferências, retreinar o modelo e comparar o resultado com o checkpoint anterior.

O primeiro resultado de segurança da Flo mostra por que a velocidade de iteração importa. O desenho inicial de preferências melhorou um objetivo, enquanto deixou o outro praticamente inalterado. A equipe precisou de outro ciclo completo para testar a pontuação graduada de segurança.

Uma stack fragmentada pode tornar esse ciclo mais lento e mais difícil de auditar. Os dados de treinamento podem passar por sistemas separados, enquanto checkpoints de modelos, versões de pontuação e relatórios de avaliação permanecem desconectados.

Um fluxo de trabalho unificado pode preservar a relação entre uma pergunta, suas respostas candidatas, pontuações dos avaliadores, o par de preferências, a execução de treinamento e a avaliação final. Essa rastreabilidade se torna importante quando um modelo produz uma resposta insegura e os investigadores precisam entender o motivo.

O desenho também apoia o plano da Flo de testar modelos open-weight mais recentes. Os engenheiros podem substituir o modelo-base enquanto preservam grande parte do processo de geração, pontuação, treinamento e acompanhamento.

Essa portabilidade é o argumento mais forte para chamar o pipeline de um ativo. A capacidade computacional é alugada, e os modelos fundacionais mudam rapidamente. Um método validado para converter padrões de domínio em comportamento de modelo pode durar mais.

Ainda assim, a conveniência da plataforma não resolve a questão central de qualidade. Experimentos mais rápidos podem produzir mais evidências, mas também podem levar a uma otimização rápida contra um benchmark incompleto.

O risco se assemelha a ensinar para uma prova. Um modelo pode se tornar muito bom em satisfazer as preferências visíveis do avaliador sem se tornar igualmente seguro diante de perguntas inesperadas.

O uso, pela Flo, de casos reservados e adjudicação clínica ajuda a lidar com essa preocupação. O estudo de caso público não divulga detalhes suficientes para determinar quão amplos eram esses casos ou como o desempenho variou entre grupos de usuários.

Portanto, a infraestrutura deve ser entendida como um acelerador para um processo de governança. Ela não pode substituir o próprio processo de governança.

A Pontuação Combinada de 47% É Progresso, Não Prova

A Flo melhorou as duas métricas reportadas, mas a taxa de falha restante impede que os resultados funcionem como uma garantia ampla de segurança.

O modelo original obteve 34% no benchmark de segurança médica da Flo e 42% em utilidade. Apenas 16% das respostas atenderam simultaneamente às duas dimensões.

Após o fine-tuning, a pontuação de segurança chegou a aproximadamente 61%. A utilidade subiu para 76%, enquanto a pontuação combinada aumentou para 47%.

O resultado combinado quase triplicou, mas também significa que 53% das respostas avaliadas não atenderam aos dois padrões. Algumas podem ter sido seguras, mas pouco úteis. Outras podem ter sido úteis, mas deixaram de incluir uma salvaguarda médica.

Essa distinção afeta as decisões de implantação. Um modelo ainda pode apoiar recursos restritos quando não está qualificado para oferecer aconselhamento de saúde sem limitações. Controles de produto podem limitar temas, recuperar informações aprovadas, solicitar esclarecimentos ou encaminhar casos sensíveis.

A Flo não divulgou publicamente, no estudo de caso, o tamanho do benchmark, os intervalos de confiança, os resultados por subgrupo ou a gravidade das falhas. Também não identifica o modelo aberto original usado para essas pontuações reportadas.

Sem esses detalhes, pesquisadores externos não conseguem determinar se um pequeno conjunto de casos recorrentes impulsionou grande parte da melhora. Tampouco conseguem comparar diretamente o modelo da Flo com APIs de ponta ou modelos especializados em saúde.

Os 26 avaliadores foram calibrados com envolvimento de clínicos, mas as pontuações resultantes continuam sendo medições internas. A replicação independente daria mais peso às alegações.

A avaliação externa importa porque perguntas sintéticas podem diferir de conversas reais. Os usuários escrevem sintomas com erros, omitem contexto, mudam de assunto, expressam medo ou fazem perguntas moldadas por pressupostos culturais.

Um benchmark também pode sub-representar condições raras, mas graves. O desempenho médio pode melhorar enquanto um modelo continua falhando nos casos com maior potencial de dano.

As diretrizes da Organização Mundial da Saúde sobre IA em saúde colocam responsabilidade, transparência e autonomia humana ao lado do desempenho técnico. Esses princípios são relevantes mesmo quando um recurso de IA fornece informações em vez de diagnóstico.

A Flo também precisa operar diante de seu próprio histórico de privacidade. Em 2021, a Federal Trade Commission finalizou uma ordem que resolveu alegações de que a Flo compartilhou informações sensíveis de saúde com provedores de análise após prometer mantê-las privadas.

O registro do acordo da FTC trata de práticas anteriores de dados, não do novo pipeline de treinamento. Ele continua relevante porque a confiança dos usuários em um aplicativo de saúde abrange tanto o que o modelo diz quanto a forma como o sistema lida com informações sensíveis.

A Flo afirma que seu processo de dados sintéticos evitou texto livre escrito por usuários e informações identificáveis. A empresa também oferece o Anonymous Mode, que, segundo ela, pode separar dados de saúde da identidade de um usuário.

Essas medidas abordam parte do risco, mas várias questões permanecem. Sinais agregados ainda podem codificar desequilíbrios demográficos. Dados sintéticos podem reproduzir pressupostos do modelo que os gerou. Avaliadores automatizados podem recompensar uma linguagem confiante que se assemelha a expertise.

A expressão “privacy-first” deve, portanto, descrever uma direção de design, e não uma certificação externa concluída desse pipeline. Da mesma forma, “mais seguro” é um resultado comparativo de benchmark, não uma prova de que toda resposta gerada seja medicamente segura.

Nenhuma dessas limitações elimina os ganhos. Elas esclarecem o que os números sustentam.

A Flo mostrou que seu sistema interno pode aproximar um modelo aberto de um comportamento definido por clínicos em seu conjunto de avaliação. Ela não mostrou que o modelo pode substituir o atendimento clínico ou responder com segurança a todas as perguntas de saúde do mundo real.

Três Sinais Mostrarão se a Estratégia se Sustenta

A próxima etapa deve ser julgada por replicação entre modelos, monitoramento no mundo real e avaliação independente, e não por mais um ganho isolado de benchmark.

O primeiro sinal é se a Flo reproduz a melhora em Gemma, Qwen ou Kimi. A empresa nomeou essas famílias de modelos como futuras candidatas para seu pipeline.

Ganhos comparáveis em diferentes modelos-base apoiariam a alegação da Flo de que o sistema de avaliação e treinamento é o ativo duradouro. Uma queda acentuada com outro modelo sugeriria que o resultado atual depende fortemente de um modelo-base não divulgado.

A comparação deve preservar o mesmo conjunto de avaliação reservado, ao mesmo tempo que adiciona testes elaborados para as fragilidades distintas de cada modelo. Caso contrário, as equipes correm o risco de selecionar o modelo que melhor se encaixa em um teste já conhecido.

O segundo sinal é o monitoramento em produção. A Flo deve informar com que frequência os sistemas implantados recusam, encaminham, recuperam informações aprovadas ou recebem feedback negativo de qualidade.

Pontuações agregadas de benchmark não conseguem revelar se as falhas se concentram em gravidez, contracepção, dor, menopausa ou sintomas urgentes. Relatórios por categoria mostrariam onde o modelo continua pouco confiável.

O monitoramento também deve distinguir respostas de baixo valor de respostas potencialmente prejudiciais. Uma resposta repetitiva e uma resposta perigosamente tranquilizadora não devem ter o mesmo peso operacional.

O terceiro sinal é a validação independente. Clínicos externos e pesquisadores de segurança devem testar o sistema com casos que o processo de treinamento da Flo não gerou nem selecionou.

Revisores independentes podem investigar mudanças de distribuição, variação demográfica, formulações adversariais, uso multilíngue e cenários médicos raros. Também podem avaliar se os avaliadores automatizados favorecem um estilo específico de comunicação em detrimento da substância clínica.

Evidências desses três sinais fortaleceriam o argumento em favor dos modelos abertos da Flo Health. A falta de publicação de resultados mais amplos deixaria as alegações atuais dependentes de um estudo de caso escrito pelo fornecedor e de medições concebidas pela empresa.

Para desenvolvedores, a lição imediata não é copiar a stack exata da Flo. É tratar o design da avaliação como parte do produto, em vez de um teste realizado após o treinamento.

Para compradores empresariais, a questão principal também está mudando. A aquisição de modelos deve examinar quem define o comportamento aceitável, como essas regras se tornam testes e se o sistema preserva evidências em cada execução de treinamento.

Trabalhadores do conhecimento e usuários de aplicativos de saúde devem buscar limites mais claros. Um produto confiável deve explicar quando a saída generativa é informativa, quando recupera material revisado e quando direciona alguém a cuidados profissionais.

Os ganhos reportados pela Flo tornam sua abordagem digna de acompanhamento. Os 53% ainda não resolvidos tornam o escrutínio igualmente necessário.

A próxima atualização decisiva não será uma execução maior em GPUs. Será a evidência de que os mesmos ganhos de segurança sobrevivem a um novo modelo-base, perguntas imprevisíveis de usuários e revisão clínica independente. Até lá, os leitores devem tratar o sistema como um método promissor de pós-treinamento, e não como um substituto verificado para o julgamento médico.