Du RAG aux agents, les choix GenAI de Doctolib

La documentation des applications, un grand chantier pour Doctolib ?

Les projets GenAI donnent en tout cas de l'importance à cet aspect. Plus précisément lorsqu'ils touchent aux frameworks agentiques. Une piste que l'entreprise a fini par explorer dans le cadre de l'assistance aux professionnels de santé, après avoir constaté les limites d'une approche fondée exclusivement sur du RAG.

Cette approche a été mise en oeuvre dans le cadre d'un pilote, sur la FAQ de Doctolib. Les professionnels de santé peuvent l'interroger en langage naturel, par l'intermédiaire d'un chatbot (UI React).

Un projet multicloud

Le système sous-jacent ne s'enclenche pas directement. La requête passe d'abord par un modèle de classification qui détermine la probabilité d'obtenir une réponse pertinente. Cela diminue le reach de l'outil, mais le rend plus précis.

Doctolib utilise un modèle d'embedding d'OpenAI (Ada-002) et GPT-4o (sur Azure OpenAI) pour produire les réponses. Les représentations vectorielles de la FAQ sont stockées dans OpenSearch. Un pipeline les met à jour quotidiennement. Il exploite S3 et AWS Step Functions.

L'évaluation des performances passe par un outil basé sur Ragas. Pour optimiser la latence (passée d'une minute à quelques secondes), Doctolib a notamment essayé d'utiliser de plus petits modèles, de diffuser les réponses et de recourir à des PTU (unités de débit approvisionnées).

LangGraph, porte d'entrée sur les agents

Quoique assez réactif, le système ne permettait pas une conversation fluide. Il ne livrait en outre que des réponses descriptives. Tout en ayant du mal à traiter les requêtes complexes et à aller au-delà de la FAQ. D'où la décision d'explorer les agents. Les frameworks autogen et crew.ai ont été envisagés, mais Doctolib s'est arrêté sur LangGraph. Entre autres pour sa flexiblité, la clarté de sa documentation et l'intégration facile avec l'écosystème LangChain.

LangGraph modélise les interactions sous forme de graphes cycliques. L'environnement développé sur sa base implique un assistant principal (dit root) qui interagit avec l'utilisateur, un agent de routage - actuellement un modèle ML - qui classe les requêtes, et des agents spécialisés.

Ces agents spécialisés peuvent exploiter divers outils. L'un est destiné à récupérer des informations à propos de l'utilisateur ou du contexte. Il est instancié avec la documentation des API qui permettent d'accéder aux bases de données de Doctolib.
Parmi les autres outils, certains sont dits "sensibles" en ce qu'ils automatisent les actions nécessaires à la résolution des cas dans le périmètre de chaque assistant spécialisé. Eux aussi sont instanciés avec de la doc. En l'occurrence, celle des API des applications en back-end.

La nature non déterministe des agents est un obstacle : ils n'invoquent pas toujours les bons outils aux bons moments et ne les exécutent pas systématiquement avec les bons paramètres. Le phénomène s'amplifie avec des prompts longs. Ils ont tendance à l'être d'autant plus dans ce type d'architecture, puisque les agents ont besoin de nombreuses informations sur les outils à leur disposition.

Vu le nombre de briques, l'évaluation est complexe. Doctolib lorgne des frameworks tels que Literal et Langsmith. Il reste par ailleurs vigilant quant à l'évolution de LangGraph, qui porte peu de use cases en production pour le moment.

Illustration © maylim - Adobe Stock