top of page

Les modèles ouverts de Flo Health sont devenus plus sûrs et plus utiles, mais 47 % réussissent encore les deux tests

il y a 2 heures
15 min de lecture

Les modèles ouverts de Flo Health se sont améliorés sur deux benchmarks internes exigeants, mais seulement 47 % des réponses évaluées satisfaisaient à la fois aux critères de sûreté médicale et d’utilité. L’entreprise spécialisée dans la santé des femmes affirme que son système de post-entraînement a fait passer la sûreté médicale de 34 % à environ 61 %. L’utilité est passée de 42 % à 76 %.

Ces progrès proviennent d’un pipeline fondé sur des questions synthétiques, des juges IA spécialisés et des règles d’évaluation définies par des cliniciens. Flo a ensuite utilisé le fine-tuning supervisé et l’optimisation directe des préférences, ou DPO, afin d’intégrer les comportements privilégiés dans les poids d’un modèle ouvert.

Ce travail est important parce que Flo compte 81 millions d’utilisateurs actifs mensuels, selon une étude de cas Databricks publiée le 12 octobre 2026. À cette échelle, même un faible taux d’erreur peut exposer de nombreuses personnes à des informations de santé incomplètes, excessivement rassurantes ou déroutantes.

Le résultat remet également en question l’approche la plus simple de l’IA générative axée sur la santé : envoyer chaque demande à un fournisseur de modèles de pointe et s’appuyer sur sa couche générale de sûreté. Flo parie que des modèles plus petits et adaptés peuvent offrir davantage de contrôle et des coûts d’inférence plus faibles. La question plus difficile est de savoir si un benchmark conçu en interne peut établir la sûreté au-delà de l’environnement qui l’a créé.

Flo a reconstruit le système d’évaluation avant d’entraîner le modèle

Le changement central n’était pas un nouveau chatbot ni un modèle de fondation. Flo a d’abord transformé le jugement clinique en un système reproductible d’évaluation et d’entraînement.

Les équipes médicales, produit et ingénierie de Flo ont réparti la qualité des réponses selon deux objectifs principaux. La sûreté médicale constituait le fondement, tandis que l’utilité mesurait si une réponse apportait à l’utilisatrice une aide pertinente et compréhensible.

Cette distinction paraît évidente jusqu’à ce qu’un modèle soit confronté à une question de santé ambiguë. Prenons le cas d’une personne qui demande pourquoi ses règles sont en retard. Une réponse qui conseille uniquement de consulter un professionnel de santé peut éviter une affirmation dangereuse, mais elle apporte peu de contexte immédiat.

La réponse inverse peut également échouer. Un modèle peut citer le stress, les voyages, les variations de poids ou l’exercice physique, tout en omettant une grossesse ou une affection nécessitant une évaluation professionnelle. Cette réponse semble plus utile, mais ses omissions peuvent créer un faux sentiment de sécurité.

Flo a donc traité la sûreté et l’utilité comme des dimensions distinctes qui doivent être satisfaites simultanément. Son cadre final comprenait 26 juges IA, c’est-à-dire des évaluateurs automatisés disposant d’instructions de notation et de cas de référence définis.

Douze juges appliquaient des contraintes de sûreté médicale. Six micro-juges examinaient des comportements plus ciblés, tels que l’ancrage factuel, le cadrage, le ton et la sûreté fine. Huit critères d’utilité évaluaient l’exhaustivité, la pertinence, la cohérence et le ton.

L’entreprise a également créé des règles pour les schémas d’échec récurrents. Une règle sur les « causes équilibrées » exigeait que les réponses couvrent des explications bénignes et potentiellement graves lorsque les deux étaient pertinentes. Elle visait la tendance des modèles conversationnels à produire une réponse rassurante qui paraît complète.

Flo affirme avoir validé ces juges à l’aide de cas synthétiques et d’exemples anonymisés provenant d’expériences avec des utilisateurs. Lorsqu’un juge automatisé était en désaccord avec une évaluation humaine initiale, des cliniciens évaluateurs en aveugle tranchaient le cas.

Certains cas examinés ont permis d’affiner les juges. Flo a réservé les autres pour des mesures ultérieures, réduisant le risque d’évaluer uniquement les exemples utilisés lors de l’étalonnage.

Cette stratégie centrée sur l’évaluation est le fondement des résultats de benchmark rapportés. Elle explique aussi pourquoi le projet est plus significatif qu’un exercice courant de fine-tuning.

Une équipe ne peut pas améliorer de manière fiable la « sûreté » si ce mot demeure une aspiration vague. Flo a dû traduire cette aspiration en comportements individuels et testables avant de pouvoir les utiliser comme signaux d’entraînement.

Le même principe s’applique au-delà de la santé. Les équipes d’entreprise possèdent souvent une connaissance métier approfondie, mais celle-ci est dispersée entre politiques, décisions d’experts, recherches et exceptions opérationnelles. Les systèmes qui prennent en charge le knowledge blending peuvent aider à organiser ce type de contenu, même si l’évaluation des modèles nécessite toujours des tests spécifiques à la tâche et des évaluateurs responsables.

La conception de Flo crée un actif réutilisable. Un modèle de fondation peut devenir obsolète, changer de licence ou perdre son avantage de coût. Les grilles cliniques et les cas d’évaluation peuvent être transférés vers le modèle suivant.

Cette portabilité établit la tension principale de l’article. Flo gagne en contrôle en remplaçant les hypothèses de sûreté d’un fournisseur généraliste par ses propres normes. Elle accepte également la responsabilité de prouver que ces normes sont fiables pour une population d’utilisateurs vaste et diverse.

Pourquoi les modèles ouverts de Flo Health sont devenus un pari économique

Les modèles ouverts de Flo Health ne sont pas seulement un projet de sûreté. Ils constituent une tentative de réduire la dépendance à des API de modèles coûteuses et contrôlées de l’extérieur.

Flo utilisait auparavant le machine learning traditionnel et a commencé à explorer l’IA générative pour proposer des expériences plus flexibles et personnalisées. Un seul modèle généraliste offrait une voie directe vers ces capacités, mais il introduisait trois contraintes.

La première était le coût d’inférence à grande échelle. Chaque réponse générée peut nécessiter une requête payante auprès d’un fournisseur externe. Une différence modeste par requête devient significative lorsqu’un produit dessert des dizaines de millions d’utilisateurs mensuels.

Flo estime que des modèles adaptés et fine-tunés peuvent réduire les coûts d’inférence d’un ordre de grandeur par rapport aux API de modèles de pointe. Ce chiffre est une estimation de l’entreprise, et non une analyse divulguée des coûts de production.

La deuxième contrainte était la dépendance au cycle de vie du modèle. Un fournisseur d’API peut retirer un modèle, modifier son comportement, réviser ses règles d’utilisation ou en introduire un remplaçant. Chaque changement peut contraindre une application de santé à répéter son travail d’évaluation.

La troisième concernait le contrôle limité du comportement propre au domaine. Le réglage de sûreté d’un modèle généraliste doit couvrir de nombreux sujets, cultures, produits et cas d’usage. Il ne peut pas encoder automatiquement chaque distinction que les cliniciens de Flo jugent importante.

La réponse à long terme de Flo est un système d’IA composite, qui combine plusieurs modèles et composants de support au lieu de confier chaque tâche à un seul modèle. Un tel système peut orienter les tâches simples vers des modèles plus petits et réserver les modèles plus grands aux demandes difficiles.

Cette voie met sous pression la stratégie par défaut fondée sur les API de modèles de pointe. Le choix ne se résume pas à une technologie ouverte ou fermée. Il oppose une sûreté générale fournie par un éditeur de modèles à des contrôles spécifiques au domaine maintenus par le développeur de l’application.

Les modèles généralistes conservent des avantages évidents. Leurs fournisseurs peuvent investir massivement dans le pré-entraînement, les évaluations étendues, les exercices de red teaming et l’infrastructure. Ils peuvent aussi mettre à jour leurs capacités sans obliger chaque client à exploiter une infrastructure d’entraînement.

Ces avantages s’accompagnent toutefois d’une distance par rapport au cas d’usage final. Un fournisseur ne possède pas la politique de réponse exacte de Flo concernant les symptômes menstruels, les questions liées à la grossesse ou d’autres sujets sensibles de santé féminine.

Flo cherche à combler cet écart en transformant son expertise métier en infrastructure d’évaluation portable. Si le modèle sous-jacent change, l’entreprise peut réexécuter ses juges, régénérer les paires de préférences et répéter le post-entraînement.

Ce processus déplace la ressource rare. Le modèle de base devient plus remplaçable, tandis que le cadre d’évaluation gagne en valeur.

Flo a déjà identifié Gemma, Qwen et Kimi comme de possibles futurs candidats à poids ouverts. Les modèles à poids ouverts exposent des paramètres que les développeurs peuvent exécuter et modifier, même si leurs licences ne répondent pas toujours à toutes les définitions du logiciel open source.

L’entreprise n’a pas affirmé qu’une seule famille de modèles traiterait toutes les applications. Sa stratégie traite plutôt les modèles comme des composants en concurrence face à un ensemble cohérent d’exigences médicales et produit.

Cela rend l’affirmation économique indissociable de la sûreté. Une inférence moins coûteuse a une valeur limitée si un modèle produit de moins bonnes informations de santé. De même, un modèle plus sûr peut rester impraticable si son exploitation coûte trop cher.

L’approche de Flo cherche un modèle qui franchit ces deux seuils. Les premiers chiffres montrent des progrès, mais ils n’établissent pas que l’équilibre est atteint.

Les juges IA ont transformé les règles cliniques en données d’entraînement

Flo a mis à l’échelle le jugement des experts en apprenant à des juges automatisés à classer des réponses candidates, puis en utilisant ces classements pour modifier le modèle lui-même.

Le pipeline a débuté avec plus de 15 000 questions synthétiques. Flo affirme avoir dérivé les entrées de signaux générés par des modèles ou agrégés anonymement, plutôt que de texte libre rédigé par les utilisateurs ou d’informations identifiables.

Cette distinction compte dans une application de santé. Entraîner directement un modèle sur des conversations sensibles d’utilisateurs peut introduire des risques pour la vie privée, des questions de consentement et des risques de mémorisation. Les prompts synthétiques réduisent ces risques, bien qu’ils introduisent un problème différent : celui de savoir si les questions générées reflètent fidèlement les utilisateurs réels.

Pour chaque question, le système produisait plusieurs réponses candidates. Les 26 juges ont ensuite noté ces réponses selon la sûreté, l’utilité et des critères comportementaux plus ciblés.

Flo a sélectionné les sorties les plus solides et les a organisées en paires de préférences. Chaque paire montrait au modèle laquelle de deux réponses correspondait le mieux au comportement souhaité.

L’équipe a d’abord appliqué un fine-tuning supervisé, qui entraîne un modèle à reproduire des exemples sélectionnés. Elle a ensuite utilisé DPO, une méthode qui augmente la probabilité des réponses privilégiées par rapport à celles rejetées.

L’article original sur DPO décrit une voie d’optimisation plus simple que l’apprentissage par renforcement conventionnel à partir de retours humains. Elle évite d’entraîner un modèle de récompense distinct lors de l’étape d’optimisation des préférences.

Flo décrit son flux de travail plus large comme du fine-tuning par renforcement. Le système génère des candidats, les note, sélectionne les meilleures réponses, entraîne le modèle, puis relance l’évaluation.

La distinction entre évaluation et entraînement est cruciale. Un juge IA ne se contente pas de noter le modèle final. Son score influence les sorties qui deviennent des exemples positifs ; toute faiblesse du juge peut donc se propager au comportement entraîné.

Flo a rencontré ce problème lors de sa première tentative. L’utilité s’est améliorée, mais la sûreté médicale est restée relativement stable. Les paires de préférences ne distinguaient pas suffisamment finement les différents niveaux de qualité médicale.

Un signal binaire de réussite ou d’échec avait écarté des informations utiles. Deux réponses pouvaient toutes deux éviter une affirmation explicitement dangereuse, alors que l’une offrait un contexte de sûreté bien meilleur.

Flo a ajouté un score de sûreté gradué après le filtre binaire. Les réponses qui réussissaient le test de sûreté de base étaient classées selon la mesure dans laquelle elles satisfaisaient pleinement aux critères médicaux applicables.

Ce changement a créé des paires de préférences plus précises. Le modèle pouvait apprendre non seulement à éviter une réponse interdite, mais aussi à privilégier une réponse offrant une meilleure couverture et davantage de garde-fous.

C’est le résultat technique le plus instructif du projet. L’optimisation des préférences ne peut pas réparer un signal de récompense vague. Si le système d’évaluation considère qu’une prudence superficielle et un cadrage clinique rigoureux sont équivalents, le modèle n’a aucune raison d’apprendre la différence.

Les cliniciens sont restés responsables de la définition et de la validation de la norme. Ils n’ont pas eu besoin de rédiger ou d’annoter manuellement chaque paire d’entraînement, ce qui a permis à leur travail d’influencer davantage d’exemples.

Toutefois, l’automatisation n’a pas supprimé le goulet d’étranglement humain. Elle a déplacé l’effort des experts vers l’amont, de l’annotation répétée vers la conception des grilles, l’arbitrage des cas difficiles et l’étalonnage des évaluateurs.

Cette redistribution peut rendre l’ajustement par domaine plus évolutif. Elle peut aussi dissimuler des erreurs derrière un score automatisé si les équipes cessent d’examiner les désaccords ou les cas rares.

La méthode dépend donc d’une maintenance continue des juges. Les recommandations médicales évoluent, le langage des utilisateurs change et de nouvelles familles de modèles révèlent d’autres faiblesses. Une suite de juges fixe peut devenir obsolète même si elle a donné de bons résultats lors de sa validation initiale.

Databricks AI Runtime a rendu la boucle reproductible

L’infrastructure était importante, car Flo devait relancer la génération, la notation, l’entraînement et l’évaluation dans une boucle contrôlée unique.

Flo a entraîné son modèle avec 32 GPU NVIDIA H100 en utilisant PyTorch et Fully Sharded Data Parallel. FSDP répartit les paramètres du modèle, les gradients et l’état de l’optimiseur entre les GPU afin de prendre en charge des charges d’entraînement plus importantes.

Sa pile combinait Databricks AI Runtime, LLM Foundry, Compose-RL et MLflow. LLM Foundry assurait l’entraînement distribué, tandis que Compose-RL fournissait la couche d’optimisation des préférences. MLflow suivait les expériences et les points de contrôle.

La documentation AI Runtime décrit un environnement GPU serverless destiné aux charges de travail d’apprentissage profond. Dans le projet de Flo, cela signifiait que les ingénieurs pouvaient demander des ressources de calcul distribuées sans configurer un nouveau cluster pour chaque expérience.

L’avantage ne se limitait pas à l’accès aux accélérateurs H100. Flo a conservé les opérations sur les données, le suivi des expériences, l’entraînement des modèles et l’évaluation dans un même environnement global.

Cette organisation réduit la friction entre la découverte d’une défaillance et le test d’une correction. Une équipe peut ajuster une grille d’évaluation, régénérer les préférences, réentraîner le modèle et comparer le résultat au point de contrôle précédent.

Le premier résultat de Flo en matière de sécurité montre pourquoi la vitesse d’itération importe. La conception initiale des préférences améliorait un objectif tout en laissant l’autre presque inchangé. L’équipe avait besoin d’une nouvelle boucle complète pour tester une notation graduée de la sécurité.

Une pile fragmentée peut rendre cette boucle plus lente et plus difficile à auditer. Les données d’entraînement peuvent transiter par des systèmes distincts, tandis que les points de contrôle du modèle, les versions de notation et les rapports d’évaluation restent déconnectés.

Un flux de travail unifié peut préserver le lien entre une question, ses réponses candidates, les scores des juges, la paire de préférences, l’exécution d’entraînement et l’évaluation finale. Cette traçabilité devient importante lorsqu’un modèle produit une réponse dangereuse et que les enquêteurs doivent comprendre pourquoi.

Cette conception soutient aussi le projet de Flo de tester de nouveaux modèles à poids ouverts. Les ingénieurs peuvent remplacer le modèle de base tout en conservant une grande partie du processus de génération, de notation, d’entraînement et de suivi.

Cette portabilité est l’argument le plus solide pour qualifier le pipeline d’actif. La capacité de calcul est louée et les modèles fondamentaux évoluent rapidement. Une méthode validée pour transformer des normes sectorielles en comportement de modèle peut durer plus longtemps.

Pour autant, la commodité de la plateforme ne résout pas la question centrale de la qualité. Des expériences plus rapides peuvent produire davantage de preuves, mais aussi permettre une optimisation rapide face à un benchmark incomplet.

Le risque ressemble à l’apprentissage pour un examen. Un modèle peut devenir très performant pour satisfaire les préférences visibles de l’évaluateur sans devenir aussi sûr face à des questions inattendues.

L’utilisation par Flo de cas réservés et d’une adjudication clinique contribue à répondre à cette préoccupation. L’étude de cas publique ne révèle toutefois pas assez de détails pour déterminer l’étendue de ces cas ni l’évolution des performances selon les groupes d’utilisateurs.

L’infrastructure doit donc être comprise comme un accélérateur d’un processus de gouvernance. Elle ne peut pas remplacer ce processus de gouvernance lui-même.

Le score combiné de 47 % constitue un progrès, pas une preuve

Flo a amélioré les deux métriques rapportées, mais le taux de défaillance restant empêche les résultats de constituer une garantie générale de sécurité.

Le modèle initial a obtenu 34 % sur le benchmark de sécurité médicale de Flo et 42 % en utilité. Seules 16 % des réponses satisfaisaient simultanément les deux dimensions.

Après l’ajustement fin, le score de sécurité a atteint environ 61 %. L’utilité est montée à 76 %, tandis que le score combiné a progressé à 47 %.

Le résultat combiné a presque triplé, mais cela signifie aussi que 53 % des réponses évaluées ne satisfaisaient pas les deux normes. Certaines pouvaient être sûres mais peu utiles. D’autres pouvaient être utiles tout en omettant une mesure de protection médicale.

Cette distinction influence les décisions de déploiement. Un modèle peut encore prendre en charge des fonctionnalités encadrées sans être qualifié pour fournir des conseils de santé sans restriction. Les contrôles produit peuvent limiter les sujets, récupérer des informations approuvées, demander des précisions ou faire remonter les cas sensibles.

Flo n’a pas publiquement communiqué la taille du benchmark, les intervalles de confiance, les résultats par sous-groupe ni la gravité des défaillances dans l’étude de cas. L’entreprise n’identifie pas non plus le modèle ouvert initial utilisé pour ces scores rapportés.

Sans ces détails, les chercheurs externes ne peuvent pas déterminer si un petit ensemble de cas récurrents a généré une grande part de l’amélioration. Ils ne peuvent pas non plus comparer directement le modèle de Flo aux API de pointe ou aux modèles de santé spécialisés.

Les 26 juges ont été calibrés avec la participation de cliniciens, mais les scores qui en résultent restent des mesures internes. Une réplication indépendante donnerait davantage de poids à ces affirmations.

L’évaluation externe importe, car les questions synthétiques peuvent différer des conversations réelles. Les utilisateurs font des fautes d’orthographe dans les symptômes, omettent du contexte, changent de sujet, expriment leur peur ou posent des questions façonnées par des présupposés culturels.

Un benchmark peut également sous-représenter des pathologies rares mais graves. Les performances moyennes peuvent s’améliorer alors qu’un modèle continue d’échouer sur les cas présentant le plus grand risque de préjudice.

Les orientations de l’Organisation mondiale de la Santé sur l’IA en santé placent la responsabilité, la transparence et l’autonomie humaine aux côtés des performances techniques. Ces principes restent pertinents même lorsqu’une fonctionnalité d’IA fournit des informations plutôt qu’un diagnostic.

Flo doit également opérer au regard de ses propres antécédents en matière de confidentialité. En 2021, la Federal Trade Commission a finalisé une ordonnance réglant des allégations selon lesquelles Flo avait partagé des informations de santé sensibles avec des fournisseurs d’analytique après avoir promis de les garder privées.

Le dossier de règlement de la FTC concerne des pratiques antérieures de traitement des données, et non le nouveau pipeline d’entraînement. Il demeure pertinent, car la confiance des utilisateurs dans une application de santé couvre à la fois ce que dit le modèle et la manière dont le système traite les informations sensibles.

Flo indique que son processus de données synthétiques a évité les textes libres rédigés par les utilisateurs et les informations identifiables. L’entreprise propose également un Anonymous Mode, qui, selon elle, peut dissocier les données de santé de l’identité d’un utilisateur.

Ces mesures répondent à une partie du risque, mais plusieurs questions demeurent. Des signaux agrégés peuvent encore encoder des déséquilibres démographiques. Les données synthétiques peuvent reproduire les hypothèses du modèle qui les a générées. Les juges automatisés peuvent récompenser un langage assuré qui ressemble à de l’expertise.

L’expression « privacy-first » devrait donc décrire une orientation de conception, et non une certification externe achevée de ce pipeline. De même, « safer » est un résultat de benchmark comparatif, et non la preuve que chaque réponse générée est médicalement sûre.

Aucune de ces limites n’efface les progrès. Elles précisent ce que les chiffres permettent d’affirmer.

Flo a montré que son système interne peut rapprocher un modèle ouvert d’un comportement défini par des cliniciens sur son jeu d’évaluation. Il n’a pas démontré que le modèle peut remplacer les soins cliniques ou répondre en toute sécurité à toutes les questions de santé du monde réel.

Trois signaux montreront si la stratégie tient

La prochaine étape devrait être évaluée au moyen d’une réplication entre modèles, d’un suivi en conditions réelles et d’une évaluation indépendante, et non par un autre gain isolé sur un benchmark.

Le premier signal sera de savoir si Flo reproduit l’amélioration avec Gemma, Qwen ou Kimi. L’entreprise a cité ces familles de modèles comme candidats futurs pour son pipeline.

Des gains comparables sur différents modèles de base étayeraient l’affirmation de Flo selon laquelle le système d’évaluation et d’entraînement constitue l’actif durable. Une forte baisse avec un autre modèle suggérerait que le résultat actuel dépend largement d’un modèle de base non divulgué.

La comparaison devrait préserver le même jeu d’évaluation réservé tout en ajoutant des tests conçus pour les faiblesses propres à chaque modèle. Sans cela, les équipes risquent de sélectionner le modèle qui s’adapte le mieux à un test familier.

Le deuxième signal est le suivi en production. Flo devrait indiquer à quelle fréquence les systèmes déployés refusent, font remonter un cas, récupèrent des informations approuvées ou reçoivent des retours négatifs sur la qualité.

Les scores agrégés des benchmarks ne peuvent pas révéler si les défaillances se concentrent autour de la grossesse, de la contraception, de la douleur, de la ménopause ou de symptômes urgents. Un reporting par catégorie montrerait où le modèle reste peu fiable.

Le suivi devrait aussi distinguer les réponses de faible valeur de celles qui sont potentiellement préjudiciables. Une réponse répétitive et une réponse dangereusement rassurante ne devraient pas avoir le même poids opérationnel.

Le troisième signal est la validation indépendante. Des cliniciens externes et des chercheurs en sécurité devraient tester le système avec des cas que le processus d’entraînement de Flo n’a ni générés ni sélectionnés.

Des évaluateurs indépendants peuvent sonder les changements de distribution, les variations démographiques, les formulations adversariales, l’utilisation multilingue et les scénarios médicaux rares. Ils peuvent aussi déterminer si les juges automatisés favorisent un style de communication particulier au détriment du fond clinique.

Les preuves issues de ces trois signaux renforceraient les arguments en faveur des modèles ouverts de Flo Health. L’absence de publication de résultats plus étendus laisserait les affirmations actuelles dépendre d’une étude de cas rédigée par le fournisseur et de mesures conçues par l’entreprise.

Pour les développeurs, la leçon immédiate n’est pas de copier la pile exacte de Flo. Elle consiste à considérer la conception de l’évaluation comme une partie du produit, plutôt que comme un test effectué après l’entraînement.

Pour les acheteurs en entreprise, la question clé évolue également. L’acquisition de modèles devrait examiner qui définit les comportements acceptables, comment ces règles deviennent des tests et si le système préserve les preuves à chaque exécution d’entraînement.

Les travailleurs du savoir et les utilisateurs d’applications de santé devraient rechercher des limites plus claires. Un produit digne de confiance devrait expliquer quand une sortie générative est informative, quand elle récupère du contenu révisé et quand elle oriente quelqu’un vers des soins professionnels.

Les gains rapportés par Flo rendent son approche digne d’attention. Les 53 % non résolus rendent un examen critique tout aussi nécessaire.

La prochaine mise à jour décisive ne sera pas une exécution sur GPU plus importante. Ce sera la preuve que les mêmes gains de sécurité résistent à un nouveau modèle de base, à des questions imprévisibles des utilisateurs et à un examen clinique indépendant. D’ici là, les lecteurs devraient considérer le système comme une méthode de post-entraînement prometteuse, et non comme un substitut vérifié au jugement médical.

 
 

Commencez pour Gratuit

Un premier assistant IA local avec gestion des connaissances personnelles

Pour une meilleure expérience IA,

remio ne supporte que Windows 10+ (x64) et M-Chip Macs actuellement.

Votre partenaire IA au travail
Faites-en plus avec remio

Planifiez. Créez. Livrez.
Tout au même endroit.

bottom of page