
Essayez la démo interactive et voyez comment votre site apparaît dans LLM SERP.
Depuis RAG, la tendance a été d'utiliser les LLM pour améliorer la recherche. De Perplexity à DeepSearch et DeepResearch, l'idée d'injecter des résultats de moteur de recherche dans le processus de génération est devenue une pratique courante. De nombreux utilisateurs affirment également qu'ils n'utilisent plus Google aussi souvent qu'avant, trouvant son design classique de pagination démodé, écrasant ou fastidieux. Au lieu de cela, ils se sont habitués à la haute précision et au rappel des résultats de type QA depuis une interface de recherche de type chat, suggérant que cette philosophie de design pourrait être la voie à suivre.
Mais que se passerait-il si le LLM lui-même était le moteur de recherche ?
Et si vous pouviez explorer les connaissances intégrées dans les LLM comme si vous utilisiez Google ? Pagination, liens et tout le reste - comme au bon vieux temps que vous connaissez bien. Si vous ne voyez pas ce que je veux dire, regardez d'abord la démo ci-dessous.
Les liens, titres et extraits sont entièrement générés par un LLM. Vous pouvez visiter https://jina.ai/llm-serp-demo et essayer quelques requêtes vous-même !
Avant de soulever des inquiétudes concernant les hallucinations, expliquons d'abord pourquoi cette idée a un certain mérite : les LLM sont entraînés sur de vastes dépôts de connaissances web. Des modèles comme DeepSeek-R1, GPT-4, Claude-3.7 et Gemini-2.0 ont été entraînés sur des billions de tokens provenant de l'internet public. Une estimation approximative indique que <1% à ~5% du texte web public de haute qualité a été utilisé pour entraîner les modèles leaders.
Si vous pensez que ce chiffre semble trop petit, considérez cette comparaison : si nous utilisons l'index de Google comme référence (représentant 100% des données accessibles aux utilisateurs dans le monde), alors l'index de Bing représente environ 30-50% de celui de Google. Baidu couvre environ 5-10%, et Yandex couvre 3-5%. Brave Search indexe moins de 1%. Donc si un LLM est entraîné sur 1-5% des données publiques de haute qualité, cela équivaut potentiellement à la même quantité de données qu'un petit moteur de recherche décent peut fournir.
Puisque ces modèles ont effectivement "mémorisé" ces données web, nous devons simplement les inciter d'une manière qui "active" leur mémoire, leur permettant de fonctionner comme des moteurs de recherche et de générer des résultats similaires à une page de résultats de moteur de recherche (SERP).
Donc oui, l'hallucination est un défi, mais à mesure que les capacités des modèles s'améliorent à chaque itération, nous pouvons raisonnablement nous attendre à ce que ce problème s'atténue. Sur X, les gens sont souvent obsédés par la génération de SVG à partir de zéro chaque fois qu'un nouveau modèle est publié, espérant que chaque version produise de meilleures illustrations que la précédente. Cette idée de moteur de recherche suit le même espoir d'amélioration progressive de la compréhension du monde numérique par le LLM.

qwen-2.5-max
à dessiner un cochon en SVG en une seule fois.Les dates limites de connaissances présentent une autre limitation. Les moteurs de recherche devraient renvoyer des informations quasi en temps réel, mais comme les poids des LLM sont figés après l'entraînement, ils ne peuvent pas fournir d'informations précises au-delà de leur date limite. Généralement, plus une requête est proche de cette date limite, plus les hallucinations deviennent probables. Puisque les informations plus anciennes ont probablement été citées et reformulées plus fréquemment, augmentant potentiellement leurs poids dans les données d'entraînement. (Cela suppose que l'information est pondérée uniformément ; les actualités peuvent recevoir une attention disproportionnée indépendamment de leur récence.) Cependant, cette limitation définit précisément où cette approche pourrait être la plus utile—pour les informations bien comprises dans la période de connaissance du modèle.
tagOù LLM-as-SERP peut-il être utile ?
Dans DeepSearch/RAG ou tout système de recherche avec ancrage, un défi central est de déterminer si une question nécessite des informations externes ou peut être répondue à partir des connaissances du modèle. Les systèmes actuels utilisent généralement un routage basé sur des prompts avec des instructions comme :
- For greetings, casual conversation, or general knowledge questions, answer directly without references.
- For all other questions, provide a verified answer with external knowledge. Each reference must include exactQuote and url.
Cette approche échoue dans les deux sens - déclenchant parfois des recherches inutiles, d'autres fois manquant des besoins critiques d'information. Particulièrement avec les nouveaux modèles de raisonnement, il n'est souvent pas évident jusqu'au milieu de la génération si des données externes sont nécessaires.
Et si nous lancions simplement la recherche de toute façon ? Nous pourrions faire un appel à une véritable API de recherche et un autre à un système LLM-as-search. Cela élimine la décision de routage initiale et la déplace en aval où nous avons des résultats réels à comparer - des données récentes de la recherche réelle, des connaissances dans la limite de formation du modèle, et potentiellement certaines informations incorrectes.
L'étape finale de raisonnement peut alors identifier les incohérences et pondérer les sources en fonction de leur actualité, leur fiabilité et le consensus entre les résultats, ce que nous n'avons pas besoin de coder explicitement — c'est déjà ce en quoi les LLM excellent. On peut également visiter chaque URL dans les résultats de recherche (par exemple, avec Jina Reader) pour valider davantage les sources. Dans les implémentations pratiques, cette étape de vérification est de toute façon toujours nécessaire ; vous ne devriez jamais vous fier uniquement aux extraits des moteurs de recherche, qu'ils soient réels ou fictifs.
tagConclusion
En utilisant LLM-as-SERP, nous transformons la question binaire "est-ce dans les connaissances du modèle ou non ?" en un processus plus robuste de pondération des preuves.
Nous proposons un playground ainsi qu'un point de terminaison API hébergé par nos soins que vous pouvez expérimenter. N'hésitez pas à l'intégrer dans vos propres implémentations DeepSearch/DeepResearch pour constater les améliorations par vous-même.
L'API imite un point de terminaison SERP complet où vous pouvez définir le nombre de résultats, la pagination, le pays, la langue, etc. Vous pouvez trouver son implémentation sur GitHub. Nous sommes impatients d'avoir vos retours sur cette approche intéressante.