Pourquoi les LLM savent décrire un lieu, pas le localiser

Les modèles de langage sont devenus suffisamment bons dans suffisamment de domaines pour qu'on soit tenté de les croire bons partout. Ils écrivent du code qui fonctionne, lisent des contrats, résument des travaux de recherche, tiennent une conversation cohérente sur presque n'importe quel sujet. Alors quand des équipes conçoivent des assistants destinés aux clients, elles étendent cette même hypothèse au monde physique, parce que le modèle donne vraiment l'impression de le comprendre.

Mais interrogez un modèle de langage sur des positions, des distances, des itinéraires ou des relations spatiales, et il échoue d'une manière assez subtile pour passer la relecture, et assez grave pour avoir des conséquences, comme un client planté devant le mauvais bâtiment.

La cause n'est pas un manque de données d'entraînement. C'est ce pour quoi ces systèmes sont faits. Un modèle de langage prédit le token suivant dans une séquence. Il ne mesure rien.

Quatre requêtes et ce qu'elles exigent vraiment

« Lequel de vos magasins est le plus proche de moi ? »

Le modèle traite la localisation du client comme une chaîne de caractères, et les fiches magasins comme des chaînes elles aussi. Il apparie sur la similarité textuelle et renvoie une réponse assurée, le plus souvent le magasin dont le nom contient le quartier du client, plutôt que celui qui est réellement le plus proche, parce que le recouvrement de noms est le signal le plus fort dont il dispose.

Vérifiez la réponse sur une carte : ce n'est fréquemment pas le magasin le plus proche. Ce n'est parfois même pas dans la bonne direction. Ce qu'exige une réponse correcte :

• Convertir la position du client en coordonnées
• Récupérer les magasins candidats dans un rayon plausible
• Mesurer la distance jusqu'à chacun sur le réseau routier, pas à vol d'oiseau
• Classer selon celui qui est réellement accessible, et renvoyer le plus proche

Quatre étapes, aucune n'est linguistique. C'est du calcul sur des données géographiques. Le modèle, lui, fait de la prédiction de texte en espérant que la forme de la réponse corresponde.

« Comment aller de la gare à votre magasin de Shoreditch ? »

Demandez un itinéraire et le modèle vous en donnera un. Tournez à gauche, continuez sur 200 mètres, à droite au carrefour. Le format est bon, le ton est assuré, et l'itinéraire, souvent, n'existe pas. Confronté au réseau routier réel, l'itinéraire généré coupe à travers des îlots sans voie de passage, rate complètement la route évidente, envoie les gens à contresens dans des rues à sens unique, et annonce des distances qui ne correspondent pas au trajet décrit.

Ce n'est pas de la négligence. Le calcul d'itinéraire est un parcours de plus court chemin dans un graphe de millions de segments connectés, chacun porteur de ses propres attributs : sens de circulation, vitesse, restrictions de virage, règles d'accès. La réponse vient du parcours de ce graphe. Il n'y a aucun moyen d'y parvenir en prédisant une suite de phrases, parce que les phrases sont le résultat du calcul, pas un substitut à celui-ci.

« Trouve-moi un point click and collect sur mon trajet de retour. »

Celle-ci a l'air de la plus simple, et c'est la plus révélatrice. « Sur le trajet » sonne comme une formule anodine, alors le modèle la traite comme une préférence et renvoie un endroit central et connu.

Mais « sur le trajet » est en réalité une contrainte spatiale dotée d'une vraie structure. Cela signifie que le lieu se situe dans un détour acceptable par rapport à un itinéraire entre deux points précis. Y répondre suppose de géocoder les deux extrémités, de calculer l'itinéraire entre elles, de tracer un corridor autour de cet itinéraire, et d'y confronter les candidats. Qu'un endroit soit ou non sur votre trajet dépend entièrement de la géométrie, et la formule, elle, n'en contient aucune.

Il en va de même pour toutes les contraintes de ce type. À proximité. Entre. À distance de marche. Assez près pour justifier le détour. Ce sont toutes des quantités, formulées comme des adjectifs.

« Est-ce que ça peut arriver aujourd'hui, vu le trafic ? »

Ici, le modèle a un problème supplémentaire. Même un itinéraire parfaitement calculé peut être périmé cinq minutes plus tard. Le temps de trajet réel dépend du flux en cours, des incidents, des travaux, des restrictions temporaires et des fermetures. Un modèle reflète les conditions typiques qu'il a vues décrites, une moyenne historique déguisée en réponse actuelle.

Donnez-lui un outil de recherche et il pourra récupérer un bulletin de trafic. Il ne pourra toujours pas recalculer l'itinéraire dans ces conditions, ni confirmer que le trajet est possible avant l'heure limite. Récupérer un bulletin de trafic n'est pas la même chose que recalculer le chemin à travers lui.

Ce n'est pas un problème d'obsolescence

Le correctif habituel consiste à ajouter de la recherche documentaire. Laissez le modèle chercher, laissez-le lire les pages à jour, et les erreurs embarrassantes disparaissent. Il cesse de recommander des magasins fermés depuis dix-huit mois.

C'est une vraie amélioration, et elle résout un problème réellement différent. La recherche corrige l'obsolescence. Elle indique au modèle ce qui est vrai aujourd'hui.

Ce qu'elle ne fait pas, c'est établir la pertinence spatiale. Qu'un lieu soit réellement proche du client, qu'il se situe de façon pertinente entre deux points, qu'il soit atteignable dans une fenêtre de livraison : ce sont toutes des questions de structure, pas de faits. Aucun texte frais n'y répond, parce que la réponse n'a jamais été écrite nulle part pour être retrouvée.

Vous pourriez lire tous les articles, avis et billets de blog jamais publiés sur une rue commerçante et n'avoir toujours aucune idée du nombre de mètres qui séparent deux devantures. Personne ne l'écrit. La distance vit dans les coordonnées et dans les réseaux. Elle ne survit pas à sa description en prose, ce qui veut dire qu'on ne peut pas la reconstituer à partir de la prose.

Pourquoi on a l'impression que le modèle sait

L'illusion fonctionne parce que le modèle détient bel et bien de vraies informations sur les lieux. Il sait nommer les villes d'une région, reconnaître des points de repère, décrire le caractère d'un quartier, se rappeler à peu près la distance entre deux capitales, et suggérer les endroits dont les gens parlent le plus.

Tout cela vient de l'association statistique entre les mots. Le modèle a appris que certains noms de lieux apparaissent constamment ensemble, et d'autres jamais. Cette association porte un vrai signal sur le monde, suffisant pour générer des réponses qui se lisent comme géographiquement informées.

En dessous, il n'y a pas de carte. Pas de coordonnées, pas de topologie, pas de réseau routier, aucune notion de quel côté de la rivière se trouve quoi que ce soit. Le modèle peut vous dire qu'un point de repère est proche d'un quartier, parce que ces mots apparaissent partout ensemble. Il ne peut pas vous dire la position du point de repère, ce qui y est relié, ni comment vous y rendre, parce que rien de tout cela n'est stocké comme structure.

Le modèle a donc une image fidèle de ce que les gens disent des lieux, et aucune image de l'endroit où ces lieux se trouvent réellement. Les deux paraissent identiques, jusqu'au moment précis où vous avez besoin d'un chiffre.

Information contre structure

On est tenté de ranger cela à côté de la faiblesse connue du modèle en arithmétique. Les modèles de langage approchent les calculs à partir de motifs plutôt que de les effectuer réellement, d'où leurs erreurs de comptage et d'addition, et d'où le correctif : confier l'opération à une calculatrice.

Le raisonnement spatial, c'est ce problème avec deux couches supplémentaires.

D'abord, la structure. Une addition n'a besoin que des nombres qu'elle a devant elle. Un itinéraire a besoin d'un graphe : nœuds, arêtes, poids, restrictions, connectivité. La réponse est une propriété de la façon dont le réseau est câblé, et ce câblage n'est pas quelque chose qu'un modèle peut déduire du simple fait d'avoir lu des textes sur les lieux que le réseau relie.

Ensuite, le temps. Une addition a une seule réponse correcte pour toujours. Un trajet a une réponse correcte à huit heures du matin et une autre à deux heures de l'après-midi, et une autre encore dès qu'une route est fermée. Toute approche fondée sur des motifs appris répond à une question sur un monde qui a déjà changé.

C'est pourquoi « le modèle va s'améliorer là-dessus » est le mauvais pari. Un modèle plus gros avec plus de texte a toujours des tokens et des probabilités là où il lui faudrait des graphes spatiaux, des données en temps réel et des algorithmes déterministes. Ce n'est pas une capacité qui advient à force d'échelle. C'est une autre sorte de machine.

Être honnête sur le partage des rôles

Rien de tout cela n'est un argument contre les modèles de langage dans les fonctionnalités de localisation. C'est un argument sur la couche qui doit prendre en charge quelle tâche, et le partage est d'une netteté inhabituelle.

Les modèles sont forts précisément sur la partie qui était autrefois la plus difficile à construire. Ils interprètent une demande confuse et ambiguë et déterminent ce que le client veut vraiment. Ils gèrent le client qui dit « quelque part près du bureau, mais pas le grand » et posent une question de suivi sensée quand la demande est sous-spécifiée. Ils transforment un résultat structuré en une phrase claire. Construire cela avec des règles était autrefois quasi impossible. C'est aujourd'hui simple.

Les modèles sont faibles partout où la réponse doit être calculée plutôt que composée : géométrie, distance réseau, temps de trajet, validité d'adresse, horaires d'ouverture du moment, tout ce qui change plus vite qu'un cycle d'entraînement. Ce sont les parties où être presque juste revient exactement à se tromper.

Ce que cela implique si vous construisez un agent sensible à la localisation

Tracée le long de cette ligne, l'architecture n'a rien de compliqué :

• Le modèle lit la demande et décide de ce qu'il faut savoir
• Un appel de géocodage transforme du texte en coordonnées, au niveau du bâtiment plutôt qu'au centroïde du code postal
• Un appel de distance ou de temps de trajet mesure le réseau réel dans les conditions du moment
• Un appel de recherche de lieux renvoie des candidats qui satisfont la contrainte spatiale
• Des données magasins en temps réel indiquent si un lieu est ouvert, doté de personnel et accessible
• Le modèle compose la réponse à partir des résultats qu'on lui a fournis, pas de chiffres qu'il a produits

La règle qui sous-tend tout cela : le modèle n'est jamais autorisé à générer une quantité. Il la demande.

Cela compte d'autant plus que ces systèmes passent de répondre à agir. Un assistant qui décrit un magasin présente peu de risque. Un assistant qui réserve le créneau de retrait, envoie le coursier ou annonce à un client que sa commande arrive avant dix-huit heures a pris un engagement en votre nom. Chacune de ces actions dépend de l'exactitude d'un calcul spatial, et un modèle qui produit un texte assuré sans avoir rien calculé est à peu près le pire composant possible à placer à ce point de la chaîne.

Il en va de même partout où un agent touche au monde physique : planifier une tournée multi-arrêts, coordonner un réseau de coursiers, affecter une mission au chauffeur disponible le plus proche, annoncer une fenêtre de livraison au moment du paiement. Chacune de ces tâches est un problème de contrainte spatiale, avec les attentes d'un client suspendues à la réponse.

La couche qu'on néglige

L'essentiel de l'effort dans les projets d'agents va au prompting, à la définition des outils et à l'orchestration. Comparativement, peu va à la question de savoir si les données de localisation sous-jacentes sont réellement exactes, ce qui reste sans intérêt jusqu'à l'instant où cela devient tout le problème.

Si votre assistant doit dire à un client où aller, l'adresse doit se résoudre au bon bâtiment, la distance doit refléter la route et non une ligne tracée en travers, et la fiche magasin doit être à jour.

C'est la partie sur laquelle travaille Woosmap : autocomplétion d'adresses, géocodage, distance et temps de trajet, recherche de lieux. Tout cela renvoie une réponse calculée plutôt que probable, une distinction qui a l'air ennuyeuse jusqu'au moment où c'est elle qui décide si votre client arrive vraiment.

Si vous construisez un agent, le serveur MCP Woosmap met ces services directement à disposition du modèle sous forme d'outils qu'il peut appeler, pour qu'il demande le chiffre au lieu de l'inventer. Il est documenté sur developers.woosmap.com/products/mcp-server/overview/ (EN).

Vos requêtes restent aussi les vôtres. Elles ne servent pas à alimenter de la publicité ni aucun autre produit, une question d'autant plus vive maintenant que les clients s'adressent à un assistant au lieu de taper dans une barre de recherche.

Laissez le modèle parler. Laissez ce qui est conçu pour ça faire les mesures.

Par où commencer

Si vous construisez cela en ce moment, l'exercice utile prend un après-midi. Passez ces quatre requêtes dans votre propre assistant, puis confrontez chaque réponse à une réponse calculée. L'écart est généralement plus large que l'équipe ne l'imagine, et il vous montre exactement quelles parties de votre stack ont besoin d'une recherche plutôt que d'un meilleur prompt.

Les API Woosmap, ainsi que le serveur MCP qui les expose sous forme d'outils, sont documentées sur developers.woosmap.com et developers.woosmap.com/products/mcp-server/overview/ (EN). Un compte développeur gratuit vous donne assez d'appels pour mener cette comparaison correctement.

Créez un compte développeur gratuit →