Comment Bayer a construit un assistant IA fiable pour ses chercheurs

Le vrai problème : des données éparses et du bruit

Bayer stocke ses recherches précliniques partout : bases structurées, PDFs historiques (certains scannés), rapports fragmentés. Un chercheur demande « quel composé a montré une toxicité hépatique en 2019 ? » → silence ou 10 000 résultats inutiles.

Les moteurs de recherche par mots-clés classiques ? Noyés par la variabilité du vocabulaire scientifique. Et la vraie connaissance se trouvait souvent dans les PDFs validés, pas dans les métadonnées incomplètes issues des migrations système.

La solution : 3 phases, pas du jour au lendemain

Phase 1 — Search : consolider les silos, exposer les métadonnées structurées sous un portail unique avec filtres avancés.

Phase 2 — Ask : RAG (Retrieval-Augmented Generation) sur les PDFs. Le chercheur pose une vraie question en français, le système cherche les passages pertinents, puis demande au LLM de répondre en s'appuyant sur ces extraits.

Phase 3 — Do : agents multiples. Pas juste répondre, mais orchestrer des flux de travail : rédiger des documents réglementaires, compiler des synthèses complexes en croisant plusieurs rapports, exécuter des recherches itératives.

L'architecture qui tient debout

Deux notions clés, que Bayer a découvertes empiriquement puis nommées rétroactivement :

Ingénierie du contexte : tu décides finement ce que chaque agent voit. Pas question de tout balancer dans le prompt. Tu fais passer l'information entre étapes spécialisées (recherche → relecture → rédaction) en contrôlant le flux. La donnée pertinente, au bon endroit, au bon moment.

Ingénierie de l'armature : la structure qui entoure le modèle. Rien de magique. Orchestration (LangGraph), limites des outils, persistance d'état (points de sauvegarde PostgreSQL), retries, fallbacks, validation avant réponse finale, boucles de relecture (l'agent se relit), observabilité (tu sais où ça casse), validation humaine en cours de route.

Concrètement :

• ▸Interface : UI conversationnelle (React)
• ▸Orchestration : LangGraph (moteur de flux qui gère les points de pause et les boucles de retour)
• ▸Données : entrepôt vectoriel (OpenSearch pour les PDFs), Athena (données structurées via SQL)
• ▸État : PostgreSQL (points de sauvegarde à chaque étape LangGraph), DynamoDB (état applicatif)
• ▸Serveur : FastAPI
• ▸Fallbacks : modèles LLM de secours en cas d'appel échoué

Pourquoi c'est fiable

Pas de boîte noire. Entre chaque étape majeure, on marque une pause. L'agent planifie, tu valides. Il cherche dans le RAG, tu consultes les sources. Il rédige, tu confirmes avant publication ou révision.

Les hallucinations diminuent parce que :

1. ▸Les données viennent de sources contrôlées (PDFs + base structurée)
2. ▸Boucles de relecture : l'agent vérifie sa logique
3. ▸Validation : pas de réponse sans double vérification

À retenir pour ton projet

Si tu penses « je vais lâcher un LLM sur mes données », oublie. Bayer a construit ça en phases. Ils ont commencé par la recherche simple, puis intégré le RAG, puis les agents multiples.

Ingénierie du contexte + ingénierie de l'armature, ce ne sont pas des mots creux. C'est l'art de dire : « je ne fais pas confiance à l'IA seule, je construis la confiance par l'architecture ».