Fonder les LLM avec de nouvelles données Web pour réduire les hallucinations

On suppose de plus en plus que si vous connectez un grand modèle de langage (LLM) à votre système ou application de production, il « saura » simplement comment répondre à vos questions. Malheureusement, ce n’est pas ainsi que cela fonctionne. Aussi impressionnants que puissent être les LLM, ils ont besoin d’accéder aux données comme n’importe quel autre modèle. La plupart des LLM ont un seuil de connaissances inhérent, le moment où se terminent leurs données de formation. Lorsque les utilisateurs posent des questions sur des informations après cette date, le modèle peut toujours produire des réponses, mais pas des réponses correctes.

Nous appelons ces mauvaises réponses des hallucinations LLM, mais elles sont en réalité le résultat attendu d’une inadéquation des informations. Les LLM s’entraînent sur des instantanés statiques d’Internet, mais les clients interagissant avec des robots de support, les managers tirant parti des assistants internes d’IA et les équipes commerciales dépendant des copilotes de produits attendent des connaissances en temps réel et des données à jour. Votre LLM n’est pas nativement informé des dernières nouvelles, des mises à jour des politiques, des changements de prix des concurrents ou des modifications apportées à la documentation de l’API. Vous devez le fonder sur de nouvelles données externes pour vous assurer que ses réponses (fournies avec une confiance inébranlable) sont réellement correctes.

Qu’est-ce que la mise à la terre LLM ?

La mise à la terre LLM signifie l’ajout d’informations externes et à jour au moment de la génération. Les LLM prêts à l’emploi et non fondés reposent principalement sur leurs données de formation et l’invite de l’utilisateur. Cela fonctionne dans de nombreux scénarios, mais pas lorsque la question nécessite de nouvelles informations telles que les dernières réglementations fiscales ou les exigences en matière de reporting financier. Les systèmes LLM de production ancrés ont accès aux sources de connaissances actuelles. Ils hallucinent moins et produisent des résultats plus fiables.

Considérez-le comme un moteur de raisonnement sans accès à Internet (un LLM non fondé) par rapport à un moteur capable de rechercher des informations en temps réel (un LLM fondé). Pour y parvenir, un LLM ancré peut utiliser des sources de données dynamiques externes, des systèmes de récupération ou même des données Web en direct. La manière la plus courante de mettre en œuvre cela aujourd’hui consiste à utiliser la génération augmentée par récupération (RAG), mais comme vous le verrez bientôt, même RAG a ses limites.

Pourquoi RAG ne parvient pas à produire

La génération augmentée de récupération, ou RAG, fonctionne généralement en sélectionnant le contexte pertinent dans des magasins de vecteurs précalculés (souvent implémentés sous forme de bases de données vectorielles) et en le fournissant au LLM au moment de la requête. Cela améliore la réponse du LLM en l’appuyant sur des sources de connaissances externes telles que les documents internes d’une entreprise ou les spécifications de produits. Bien que très efficaces pour des bases de connaissances stables, les systèmes RAG sont aussi récents que les données qu’ils récupèrent. Vous devrez constamment mettre à jour vos magasins de vecteurs pour vous assurer que RAG a accès à des données à jour. Tout retard dans l’ingestion conduit à nouveau à des hallucinations sous forme de réponses dépassées.

Les données Web en direct changent complètement la donne. Avec les magasins vectoriels RAG, votre LLM obtient un instantané du temps ; avec des informations Web en direct, votre LLM reçoit une vue continuellement mise à jour de la réalité. Les données en temps réel provenant du Web aident à résoudre le problème de la fraîcheur, mais elles fournissent également à votre LLM une couverture supplémentaire pour les informations à longue traîne ou non indexées. RAG n’a peut-être pas de vecteur pour la formulation exacte dont vous avez besoin, mais si vous donnez à votre LLM accès aux résultats de recherche en temps réel, il peut fournir une réponse précise. Les données Web en direct semblent être un excellent ajout, mais la configuration et la maintenance du cadre nécessaire pour les associer à votre LLM deviennent rapidement compliquées. C’est là qu’intervient l’infrastructure de recherche gérée.

À quoi ressemble l’infrastructure de recherche gérée pour les LLM

L’infrastructure de recherche gérée offre un moyen d’extraire des résultats de recherche en direct sans avoir à créer vos propres scrapers. Ces services éliminent la récupération des données de recherche, vous permettant de vous concentrer sur vos systèmes LLM de production. En pratique, ils facilitent grandement la mise en place de votre LLM avec des données en temps réel provenant du Web, que ce soit seul ou avec un système RAG.

La plupart des outils de recherche gérés appartiennent à l’une des catégories suivantes : API de recherche traditionnelles, API de page de résultats de moteur de recherche (SERP), plates-formes de recherche natives LLM et outils de recherche Web LLM intégrés. Les API de recherche traditionnelles offrent un moyen simple d’obtenir un sous-ensemble de résultats de recherche. Les API SERP offrent un accès plus complet et structuré aux SERP. Par exemple, SerpApi est une API de recherche Web les développeurs peuvent utiliser pour combiner facilement les résultats de recherche en direct de plus d’une centaine d’API avec n’importe quelle application. Les nouveaux outils natifs LLM tels que Tavily et Exa se concentrent sur la simplification de l’intégration LLM en renvoyant des résultats reclassés ou résumés. Les outils de recherche contenus dans les LLM permettent une intégration transparente mais vous donnent généralement des résultats condensés avec un contrôle limité sur les sources de données.

Chacune de ces approches offre un équilibre entre contrôle, transparence et facilité d’intégration, mais elles visent toutes le même objectif : ancrer les LLM sur des données Web en temps réel. Une fois cette couche en place, l’étape suivante consiste à intégrer les résultats de recherche dans votre pipeline LLM.

Modèles d’intégration de la recherche Web en direct dans les pipelines LLM

Lorsque vous ajoutez des données de recherche en direct à votre pipeline LLM, vous devez prendre en compte le degré de contrôle que vous accordez au LLM, le degré de latence que vous pouvez tolérer et le niveau de complexité que vous êtes à l’aise de gérer. Il existe trois modèles d’architecture principaux pour incorporer des données externes en direct dans les systèmes LLM de production, chacun avec des compromis différents dans ces dimensions.

Pipelines axés sur la recherche

Les pipelines de recherche en premier font exactement ce à quoi ils ressemblent : ils recherchent en premier. Lorsqu’un utilisateur soumet une requête, le système appelle immédiatement une API de recherche et injecte les résultats dans l’invite, donnant ainsi au LLM le contexte en temps réel pour générer sa réponse. Cette configuration reflète étroitement RAG, sauf que le contexte supplémentaire provient de données Web en direct au lieu d’un magasin de vecteurs statiques.

Ce modèle fonctionne bien lorsque vous avez constamment besoin de résultats de recherche, surtout si vous disposez déjà d’un pipeline de style RAG. Il est simple à mettre en œuvre, déterministe et à latence relativement faible, puisque chaque requête suit la même étape de recherche. Cependant, il est également rigide : il effectue toujours une requête de recherche, que cela soit nécessaire ou non, et il n’y a aucune possibilité d’affiner les requêtes ou d’ajuster la récupération en fonction de résultats intermédiaires.

Utilisation des outils

Dans une configuration utilisant un outil, le LLM appelle dynamiquement une API de recherche uniquement lorsque le LLM détermine qu’il a besoin d’informations externes. Un utilisateur pose une question ; le LLM décide s’il a suffisamment de contexte ; et sinon, cela déclenche un appel d’API de recherche. Les résultats sont ensuite renvoyés au modèle, qui les utilise pour générer une réponse finale. Dans certains systèmes, le LLM est autorisé à effectuer plusieurs appels d’outils pour affiner ou étendre sa requête.

Considérez ce modèle pour votre pipeline LLM lorsque seulement quelques les invites nécessitent des données Web en direct. Les systèmes d’utilisation d’outils sont plus flexibles et efficaces que les pipelines de recherche d’abord, car ils évitent les appels de recherche inutiles. Cependant, ils introduisent une complexité supplémentaire et peuvent être plus difficiles à déboguer puisque le LLM a plus de contrôle sur le moment et la manière dont la récupération a lieu.

Par rapport aux pipelines axés sur la recherche, cette approche transfère le contrôle du système vers le modèle, mais il s’agit toujours généralement d’un processus de décision en une seule étape plutôt que d’un processus itératif.

Boucles agents

Les boucles agentiques sont des systèmes LLM dans lesquels le modèle raisonne de manière itérative, appelle des outils et affine son approche jusqu’à ce qu’il termine une tâche. Ces systèmes sont généralement destinés à des tâches plus complexes comme les analyses concurrentielles ou le dépannage de produits, pour lesquelles une seule recherche ne suffit pas. L’agent LLM peut effectuer plusieurs recherches sur le Web selon les besoins, explorant, validant et affinant progressivement sa réponse.

Cette configuration convient mieux aux tâches qui nécessitent une planification et une stratégie, où le modèle fonctionne davantage comme un agent de recherche que comme un chatbot. Contrairement aux deux modèles précédents, la récupération n’est pas une décision unique mais une boucle itérative continue de raisonnement et de recherche. Cependant, cette flexibilité n’est pas gratuite. Plusieurs appels d’outils augmentent la latence et le coût de l’utilisation supplémentaire de l’API, et ces systèmes sont également généralement plus complexes à créer, déboguer et contrôler.

Exemple de code : mise à la terre d’un LLM avec des données de recherche en direct

Voici un exemple Python simple d’un pipeline axé sur la recherche qui fonde un LLM avec des données Web en direct via SerpApi :

import serpapi
import openai

# Live web search (SerpApi)
def get_search_results(query):
    client = serpapi.Client(api_key="YOUR_SERPAPI_API_KEY")
    results = client.search({"q": query})

    # Extract top snippets
    snippets = []
    for r in results.get("organic_results", [])[:5]:
        snippets.append({
            "title": r.get("title"),
            "snippet": r.get("snippet"),
            "link": r.get("link")
        })

    return snippets

# Build LLM prompt, grounded with live context
def build_prompt(user_question, search_results):
    context = "\n\n".join(
        f"{r['title']}\n{r['snippet']}"
        for r in search_results
    )

    return f"""
You are a helpful assistant grounded in live web data.

Use the context below to answer the question.

Context:
{context}

Question:
{user_question}

Answer:
"""

# Call LLM (example with OpenAI)
def ask_llm(prompt):
    client = openai.OpenAI(api_key="YOUR_OPENAI_KEY_HERE")

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )

    return response.choices[0].message.content

# Full pipeline
def answer_question(question):
    search_results = get_search_results(question)
    prompt = build_prompt(question, search_results)
    return ask_llm(prompt)

# Example usage
print(answer_question("What are the latest trends in LLM grounding?"))

# Example of expected output, which will naturally change over 
# time:
#
# The latest trends in LLM grounding include:
# 1. **Pre-training on Publicly Available Data**: Developers are 
# focusing on utilizing publicly accessible datasets to enhance the 
# foundational knowledge of LLMs.
# 2. **Retrieval-Augmented Generation (RAG)**: This technique 
# combines retrieval of relevant information with generative 
# capabilities, allowing models to produce more accurate and 
# contextually grounded responses by accessing external data.
# 3. **Fine-tuning on Domain-Specific Data**: Tailoring models to 
# specific fields ensures that they better understand the nuances 
# and requirements of particular applications, leading to improved 
# performance. These trends aim to mitigate issues such as 
# hallucination and enhance the accuracy and relevance of responses 
# generated by LLMs.

Vous n’êtes pas un utilisateur de Python ? Aucun problème. SerpApi fonctionne avec de nombreux autres langages, notamment JavaScript, Ruby, Rust et même Google Sheets.

Notez que vous devrez installer le client SerpApi Google Search (pip install serpapi) et le client OpenAI (pip install openai) pour accéder à ces bibliothèques. Vous aurez également besoin de clés API pour votre fournisseur LLM (par exemple OpenAItarification basée sur l’utilisation) et votre infrastructure de recherche gérée (par exemple SerpApiniveau gratuit disponible). SerpApi fournit également des tutoriels et guides d’intégration pour commencer rapidement à créer des applications LLM basées sur la recherche.

Conclusion

Pour éviter les hallucinations sur les événements, les prix ou les politiques récents, vous devez étayer votre LLM avec des informations à jour. RAG fournit un contexte utile pour les requêtes des utilisateurs, mais ses magasins de vecteurs préexistants peuvent rapidement devenir obsolètes. L’intégration de données de recherche Web en direct permet de combler ce manque de fraîcheur et d’améliorer la fiabilité dans des domaines en évolution rapide.

L’infrastructure de recherche gérée permet d’éliminer les complexités liées à l’obtention de données Web en temps réel, et une fois disponibles, vous pouvez intégrer ces données dans vos pipelines LLM via l’une des trois architectures principales : recherche d’abord, utilisation d’outils ou boucles agentiques. Chaque approche comporte des compromis en termes de contrôle, de latence et de complexité.

Parmi ceux-ci, les pipelines axés sur la recherche constituent le moyen le plus simple d’ancrer votre LLM avec des données en direct. Ils déclenchent toujours un appel d’API de recherche avant la génération LLM. L’exemple de code ci-dessus illustre ce modèle en utilisant SerpApi comme couche de recherche gérée.

Si vous souhaitez approfondir vos recherches, le Terrain de jeu SerpApi est un point de départ utile pour expérimenter des données de recherche réelles. Il donne accès à un large éventail d’API de recherche, notamment la recherche Google et les aperçus de l’IA.