Qu’est-ce qu’Umaguedo Search ?
Umaguedo Search est un assistant de recherche indépendant, assisté par IA, pour l’univers
d’Umamusume Pretty Derby. Il repose sur le RAG, c’est-à-dire la génération augmentée par
récupération d’informations : le système recherche dans des données de personnages stockées,
récupère les éléments pertinents, puis utilise le modèle pour produire une réponse fondée sur
ces éléments plutôt que sur sa mémoire seule. Il permet d’identifier des personnages à partir
d’indices, de poser des questions sur leur profil, leur apparence, leurs relations, leurs
apparitions média et leurs attributs de gameplay, ainsi que de comparer des personnages lorsque
les informations disponibles le permettent.
Pourquoi construire ce projet ?
Umaguedo Search a d’abord été un terrain d’expérimentation pour apprendre le RAG en pratique :
tester différentes stratégies de recherche, travailler avec des données structurées et non
structurées, expérimenter l’usage d’outils et d’orchestration, et comprendre où un système RAG
atteint ses limites. Avec le temps, le projet est devenu un assistant de recherche utilisable
pour les fans d’Umamusume, tout en imposant des choix plus proches d’un vrai projet en production :
déploiement, usage d’API, contrôle des coûts, limites de débit, maintenance de la base de données
et protection contre les abus.
Pourquoi utiliser Umamusume comme domaine ?
L’idée est partie d’une expérimentation assez informelle autour d’un domaine de fan, mais elle est
rapidement devenue intéressante sur le plan technique. Un univers fictif de jeu vidéo est un bon
environnement pour apprendre le RAG : il est motivant à manipuler, évite les documents privés,
médicaux, financiers ou internes à une entreprise, tout en offrant assez de complexité pour tester
de vrais problèmes de recherche d’information. Umamusume est particulièrement adapté, car la franchise
est très développée et extrêmement riche en personnages : elle contient beaucoup de personnages, chacun
avec des faits de profil détaillés, des traits visuels, des relations, des apparitions média, des
attributs de gameplay, des variantes et des noms alternatifs. Même si le domaine reste relativement
niche, il possède une communauté active et des ressources bien maintenues, comme des wikis et des pages
de fans. Cela rend possible la construction d’un vrai système de recherche à partir de données publiques.
En même temps, le domaine est assez spécifique pour qu’il n’existe pas de tutoriel évident ou de dataset
standard à copier : il a donc fallu réaliser un vrai travail de modélisation, d’ingestion, de
normalisation, de recherche et d’ancrage dans les sources.
Quelles sources sont utilisées ?
La version actuelle utilise principalement des ressources publiques créées par la communauté Umamusume,
en particulier Gametora et umamusu.wiki. Ces sources fournissent des informations structurées et
semi-structurées : données de personnages, faits de profil, relations, images et ressources associées,
attributs de gameplay, apparitions média et textes descriptifs. Le projet ingère ces informations dans
PostgreSQL, les normalise en enregistrements recherchables et construit des unités de recherche pour
les outils SQL et la recherche sémantique. Lorsque c’est possible, les réponses et les cartes personnages
renvoient vers les pages sources originales au lieu de présenter ces données comme appartenant au projet.
Comment les attributs dérivés sont-ils utilisés ?
Le système ne stocke pas seulement les données sources telles quelles. Il construit aussi des attributs
dérivés à partir des données ingérées, par exemple des mesures normalisées, des percentiles et des
catégories recherchables. Cela permet de relier des valeurs exactes présentes dans les sources à des
requêtes plus naturelles : un utilisateur peut chercher un personnage “petit”, “grand” ou visuellement
distinctif sans connaître les chiffres exacts du profil. Ces attributs dérivés sont reconstruits à
partir des données sources et utilisés par les outils SQL et les unités de recherche comme preuves
structurées supplémentaires.
D’autres sources seront-elles ajoutées ?
Peut-être. Une future version pourrait ajouter d’autres sources publiques afin d’améliorer la couverture
des apparitions média, des événements liés aux anime, des informations issues des mangas, du contexte
narratif ou des nouveaux contenus Umamusume. L’objectif serait d’étendre les éléments recherchables tout
en conservant l’attribution, les liens vers les sources et une séparation claire entre les faits récupérés
et les inférences du modèle.
Quel est le périmètre de l’assistant ?
L’assistant est limité au domaine Umamusume Pretty Derby. Le rejet des requêtes hors sujet a été testé
afin que les demandes sans lien avec Umamusume soient refusées au lieu d’être traitées à partir des
connaissances générales du modèle. Dans le périmètre Umamusume, le système a été testé sur des types
de requêtes représentatifs : identification, faits, relations, filtres de gameplay, apparitions média
et comparaisons prudentes. En revanche, il n’a pas été testé de manière exhaustive sur toutes les
questions possibles liées à l’univers.
Comment tester la démo ?
Les bonnes requêtes de test incluent des questions directes sur un personnage, des descriptions visuelles
vagues, des questions de relation, des filtres de gameplay, des questions sur les apparitions média et
des demandes de comparaison prudente. Les tests les plus intéressants sont les requêtes mixtes, car elles
forcent le système à combiner normalisation, recherche structurée, recherche sémantique et génération
de réponse fondée sur des sources, au lieu de répondre à partir d’une simple correspondance de mots-clés.
Peut-il gérer des requêtes mal formulées ou multilingues ?
Oui, dans certaines limites. Les utilisateurs n’ont pas besoin d’écrire des requêtes parfaitement
formatées : le système peut traiter des entrées multilingues grâce à une étape de normalisation basée
sur un LLM. Avant la recherche, le normaliseur essaie de préserver les noms de personnages, de nettoyer
les formulations imprécises, de clarifier l’intention de l’utilisateur et de reformuler la requête pour
les outils de recherche. L’assistant essaie ensuite de répondre dans la même langue que l’utilisateur
lorsque c’est possible. Cela améliore la robustesse face aux langues mélangées, aux indices vagues,
aux variantes de noms et aux formulations imparfaites, mais ne garantit pas une gestion parfaite de
chaque faute, indice ambigu ou langue non supportée.
Comment une requête est-elle traitée ?
Une requête utilisateur passe d’abord par une étape de normalisation, puis le système choisit le chemin
de recherche le plus pertinent. Selon la demande, il peut utiliser des outils SQL structurés pour les
faits, le gameplay, les images et les relations, de la recherche sémantique pour les indices descriptifs
ou visuels, et une étape d’ancrage des candidats pour garder la réponse liée aux éléments récupérés.
La réponse finale est générée à partir de ces éléments plutôt qu’à partir des seules connaissances
préalables du modèle.
À quel point la qualité des réponses dépend-elle des sources ?
Une grande partie de la qualité du système dépend de la qualité, de la structure et de la couverture
des données sources, en particulier des ressources riches en contenu comme umamusu.wiki. Les couches
de recherche et d’ancrage dans les sources peuvent aider à organiser, retrouver et combiner les éléments
disponibles, mais elles ne peuvent pas créer des faits fiables lorsque ceux-ci sont absents, incomplets,
ambigus ou incorrects dans les sources. Quand les données sources sont solides, l’assistant est beaucoup
plus utile ; quand la couverture est faible, le système doit rester plus prudent.
Qu’est-ce qu’une inférence fondée ?
Certaines questions n’ont pas de réponse directement écrite dans une source. Par exemple, une comparaison
ou une question de type “le plus probable” peut nécessiter un raisonnement à partir des éléments
disponibles. Dans ces cas-là, l’assistant doit distinguer les faits explicites d’une estimation prudente,
et éviter de présenter une inférence comme canonique ou comme directement affirmée par une source. Si les
éléments récupérés sont trop faibles, l’assistant doit le signaler.
Comment fonctionne la maintenance des données ?
Le projet inclut un processus de maintenance quotidien pour garder la base de données exploitable dans
le temps. Dans le cas normal, il vérifie l’état de la base, cherche les personnages nouvellement
disponibles, synchronise uniquement les enregistrements concernés et met à jour les unités de recherche
ainsi que les embeddings pertinents. Si le contrôle détecte des données de recherche manquantes ou
corrompues, le système peut basculer vers une reconstruction plus lourde qui régénère les attributs
dérivés, les unités d’apparence et les unités de recherche RAG.
Comment les coûts et les abus sont-ils contrôlés ?
Comme les endpoints LLM publics peuvent être abusés ou devenir coûteux, l’API inclut des garde-fous côté
serveur : limites de taille de requête, limites de longueur de message, protection contre les prompts
dupliqués, limites de concurrence par IP et globales, limites de débit, plafonds journaliers et accès
restreint au debug. Ces vérifications sont appliquées par le backend : elles restent donc actives même
si quelqu’un contourne l’interface web et appelle directement l’API.
Quelle est la stack technique ?
Le backend est construit avec FastAPI, PostgreSQL et SQLAlchemy. Le pipeline RAG utilise LangChain et
LangGraph pour orchestrer les outils, orienter les requêtes, combiner les étapes de recherche et générer
des réponses fondées sur des sources. La recherche combine des outils SQL structurés et de la recherche
sémantique par embeddings. L’inférence LLM et la génération d’embeddings sont effectuées via des appels
API compatibles OpenAI, utilisés pour la normalisation, la préparation de la recherche, les embeddings
et la génération finale de réponse. L’interface web est en HTML/CSS/JavaScript statique, avec un
déploiement orienté Docker et des scripts de maintenance planifiés pour la synchronisation, les contrôles
de santé et les reconstructions.
Quelles sont les limites ?
Umaguedo Search est un projet portfolio et un assistant de recherche créé par un fan, pas une encyclopédie
officielle. Il peut échouer si les données sources sont incomplètes, si la recherche manque une preuve
pertinente ou si le modèle interprète mal le contexte récupéré. Les questions ambiguës, spéculatives
ou trop peu précises peuvent produire des estimations prudentes plutôt que des réponses définitives.
Le système est conçu pour être fondé sur des sources, mais il n’est pas garanti exhaustif ni exempt
d’erreurs.
Est-ce officiel ?
Non. Umaguedo Search est un projet technique indépendant créé par un fan. Il n’est pas affilié,
approuvé, sponsorisé ni connecté aux ayants droit officiels d’Umamusume Pretty Derby. Les liens vers
les sources sont fournis pour l’attribution et la vérification, et le projet ne doit pas être considéré
comme une encyclopédie officielle ou une ressource officielle du jeu.
Qui l’a construit ?
Umaguedo Search a été construit par Alexandre Aguedo, ingénieur en intelligence artificielle et machine
learning. Je l’ai créé comme projet pratique pour apprendre l’ingénierie RAG en profondeur et démontrer
comment la recherche d’informations, l’orchestration d’outils, le déploiement backend, la maintenance
de base de données et les garde-fous d’API s’articulent dans une application réelle.