Un moteur de recherche privé pour le modèle, sans compte chez des intermédiaires
Un modèle de langage connaît le monde jusqu'au jour où son entraînement s'est achevé. Pour répondre à des questions d'aujourd'hui, il doit savoir chercher. Nous avons construit pour cela notre propre moteur de recherche, sur la même machine — et mesuré au passage le travail qu'il faut pour obtenir des résultats dans sa propre langue.
Comment le modèle cherche, au juste
Contrairement aux apparences, le modèle n’a pas accès à Internet. Cela fonctionne autrement, et il vaut la peine de le comprendre, car cela conditionne la confidentialité de toute la solution.
Au départ, le modèle est informé qu’il existe deux outils : l’un renvoie une liste de résultats de recherche, l’autre récupère le contenu d’une page indiquée. Quand il juge que la question exige des données fraîches, il n’exécute rien lui-même — il écrit une demande : « lance une recherche avec la phrase X ». Le programme côté utilisateur exécute cette demande, interroge notre moteur et recolle les résultats dans la conversation. Le modèle les lit comme du texte ordinaire et formule sa réponse.
Tout le trafic passe donc par notre machine. Aucun fournisseur de modèle ne voit ni la question, ni ce qui a été fait de la réponse.
Ce qu’il y a dessous
La couche de recherche est SearXNG — un métamoteur ouvert que nous hébergeons chez nous. Il interroge une source externe (chez nous, l’API officielle du moteur Brave, avec une clé) et renvoie une liste de résultats unifiée. Le fournisseur externe voit la requête, mais ne voit ni qui demande, ni pourquoi, ni ce qui s’est dit plus tôt dans la conversation. Pas de compte utilisateur, pas d’historique, pas de profilage.
Un piège de configuration mérite d’être noté, car il nous a coûté un peu de temps : nous avons choisi un moteur qui passe par l’API officielle, et non par la lecture automatique de la page de résultats. Cette seconde méthode est parfois le réglage par défaut d’installations semblables — et se fait bloquer au bout d’une quinzaine de requêtes.
Des résultats dans votre langue exigent deux réglages, pas un
Par défaut, une telle installation répond avec des résultats en anglais, même à une question en polonais. Nous l’avons mesuré sur une phrase technique, en comptant les résultats polonais parmi les vingt premiers :
| Réglage de langue | Résultats polonais sur 20 |
|---|---|
| aucun / « toutes » | 0 |
| code de langue seul (« pl ») | 10 |
| locale complète (« pl-PL ») | 17 |
La différence entre « pl » et « pl-PL » n’est pas cosmétique : sept résultats sur vingt. La même mécanique vaut pour votre langue — « fr » contre « fr-FR ». Et il faut régler deux couches : la valeur par défaut du serveur et les paramètres transmis au moteur lui-même. En changer une seule ne suffit pas, car l’autre est écrasée par le client.
Le modèle peut passer outre pour une requête donnée — et il le fait à bon escient, en basculant vers l’anglais quand il cherche de la documentation technique.
Le résultat par défaut était trop maigre — nous avons corrigé le moteur
La version standard du moteur ne retient de chaque résultat qu’une courte description — deux phrases, souvent coupées au milieu de la phrase décisive. Or le fournisseur renvoie au passage des fragments supplémentaires du contenu de la page, que personne n’avait demandés et qui étaient tout simplement jetés.
Nous avons remplacé ce morceau par notre propre version, qui recolle ces fragments et les joint au résultat. Effet : environ 4,7 fois plus de texte par résultat. Le modèle reçoit du vrai contenu au lieu d’une accroche, et répond donc plus souvent du premier coup, sans télécharger des pages entières.
La seconde modification est mineure mais règle un problème fréquent : devant chaque résultat, nous accolons la date de publication. Sans elle, le modèle n’a aucun moyen de distinguer un tutoriel vieux de cinq ans d’un tutoriel de cette année — et il confondait régulièrement les versions de logiciels.
Quand le modèle descend plus profond
Notre instruction système contient une règle : si les fragments sont tronqués, contradictoires ou ne contiennent pas le détail recherché — récupère la page entière. Cela règle les situations où la liste de résultats fait mine de répondre sans contenir la réponse.
Un détail qui mérite d’être imité : nous décrivons la règle par le rôle de l’outil, pas par son nom (« il prend une adresse, il renvoie le contenu »). Chaque programme nomme cet outil autrement, et une instruction accrochée au nom cesse de fonctionner au changement de client.
Ce que cela coûte en contexte
Les données fraîches ne sont pas gratuites — elles prennent de la place dans la mémoire de la conversation :
- une recherche avec fragments complets : environ 4 000 tokens,
- la récupération d’une page entière : jusqu’à une bonne dizaine de milliers.
Avec un contexte de 262 000 tokens, la situation est confortable : une quinzaine de recherches dans une même conversation passe inaperçue. Sur une machine au petit contexte, c’est exactement ici que la partie s’arrêterait — et c’est l’une des raisons pour lesquelles il valait la peine de se battre pour la capacité de contexte.
Ce que cela apporte en pratique
Trois choses, par ordre d’importance pour l’utilisateur à domicile :
L’actualité. Le modèle cesse d’inventer sur les sujets récents, parce qu’il a de quoi vérifier.
La confidentialité. Les requêtes ne bâtissent ni profil publicitaire ni historique rattaché à un compte. Seul le terme de recherche sort de la maison, sans le contexte de la conversation.
L’indépendance. Le moteur est interchangeable — la source peut être remplacée sans toucher aux modèles et sans attendre qu’un fournisseur change d’avis sur ses tarifs ou ses conditions.
Configuration maison, sur la même machine que les modèles. Les mesures de langue des résultats ont été réalisées sur notre instance.