Architecture de l'assistant IA : LLM, Mémoire, Outils, Routage, Observabilité

Un assistant IA de production n’est pas « un LLM avec un prompt ». C’est un système qui accepte l’intention, maintient un état, décide quand récupérer ou agir, et expose suffisamment de détails d’exécution pour déboguer les échecs.

Cette vision au niveau système est ce que le [cluster AI Systems](https://www.glukhov.org/fr/ai-systems/ « Construisez des systèmes IA auto-hébergés avec OpenClaw, Hermes, RAG et une infrastructure LLM locale. Apprenez à orchestrer des assistants avec mémoire, récupération, routage et observabilité. ») explore lorsque les assistants dépassent une simple invocation de modèle.

OpenAI décrit les agents comme des applications qui planifient, appellent des outils, collaborent et conservent suffisamment d’état pour un travail en plusieurs étapes, tandis qu’Anthropic aborde le même problème comme un harnais géré qui peut exécuter des fichiers, des commandes, des accès web et du code en toute sécurité.

L’architecture la plus claire divise les responsabilités en cinq couches : LLM, Mémoire, Outils, Routage et Observabilité. Cette division correspond aux capacités exposées par les API des grands fournisseurs, par MCP, par les temps d’exécution auto-hébergés tels que vLLM et llama.cpp, et par les systèmes d’assistants réels tels qu’[OpenClaw](https://www.glukhov.org/fr/ai-systems/openclaw/ « Une exploration par étude de cas d’OpenClaw — un système d’assistant IA auto-hébergé qui intègre des LLM locaux, la récupération, la mémoire, le routage et l’observabilité dans une infrastructure locale cohésive. ») et Hermes.

La mémoire doit être considérée comme plus que « un contexte plus long ». Les systèmes de récupération transforment les connaissances externes en mémoire explicite non paramétrique — le même espace de conception couvert en profondeur par la [Générative Améliorée par Récupération (RAG)](https://www.glukhov.org/fr/rag/ « Tutoriel RAG étape par étape : construisez des systèmes de génération améliorée par récupération avec des bases de données vectorielles, recherche hybride, réordonnancement et recherche web. Architecture, implémentation et meilleures pratiques de production. ») — et les directives de contexte d’Anthropic ainsi que le papier « Lost in the Middle » mettent en garde contre le simple fait d’encombrer plus de jetons dans le contexte, ce qui ne garantit pas une récupération fiable.

L’utilisation d’outils est une frontière de contrat, pas de la magie. L’appel de fonctions d’OpenAI, l’utilisation d’outils d’Anthropic et MCP reposent tous sur le même motif : le modèle émet une demande structurée, un certain temps d’exécution l’exécute, et le résultat revient dans la conversation. Si cette frontière est négligée, l’assistant devient négligent.

Mon biais est simple : commencez par l’ennui. Un orchestrateur, un chemin de mémoire durable, une trace par requête et une politique explicite d’exécution des outils. Les graphes multi-agents sont utiles, mais seulement après que vous puissiez expliquer vos cas d’échec d’agent unique sans deviner.

Ce qu’est un système d’assistant IA

Une définition pratique est la suivante : un système d’assistant IA est un temps d’exécution qui transforme l’intention de l’utilisateur en une réponse ou en une action en combinant une interface de modèle, l’assemblage du contexte, l’exécution d’outils, la gestion d’état et la télémétrie. C’est pourquoi les documents utiles ne sont pas juste des fiches de modèles. Les documents utiles sont des références d’API, des contrats d’outils, des guides de récupération, des documents de routage et des documents de traçabilité. L’API Responses d’OpenAI expose des interactions étatiques, des outils intégrés et l’appel de fonctions. L’API Claude d’Anthropic expose un accès direct aux Messages ainsi que des Agents Gérés. OpenClaw et Hermes vont un pas plus loin et montrent ce qui se passe lorsque vous placez ces capacités derrière des passerelles persistantes, des canaux, des sessions et de la mémoire.

En d’autres termes, un système d’assistant a un contrat plus large qu’une complétion de chat. Un bon contrat interne ressemble à ceci :

AssistantRequest  = intention utilisateur + identité + session + pièces jointes + politique
AssistantResponse = réponse + actions + citations + modifications d'état + identifiant de trace

Ce contrat est important car chaque désaccord de production se réduit éventuellement à l’une de ces questions : quel contexte était visible, quel outil a exécuté, quel modèle a répondu, quelle mémoire a été lue ou écrite, et où la trace indique que le système a passé du temps. OpenTelemetry définit les traces comme le chemin d’une requête à travers une application, ce qui est exactement l’abstraction dont ont besoin les assistants sérieux. LangSmith et OpenLIT spécialisent ensuite cette idée pour les LLM, les outils, les bases de données vectorielles et les flux de travail d’agents.

Composants et interfaces principaux

La division des composants ci-dessous est celle que je trouve la plus durable. C’est aussi la division qui correspond le mieux aux API officielles et aux temps d’exécution open source que les gens exploitent réellement.

Le tableau ci-dessus est dérivé des interfaces officielles des fournisseurs, MCP, des documents des bases de données vectorielles et des documents de runtime pour vLLM, llama.cpp, OpenClaw et Hermes.

La couche LLM devrait bien faire trois choses : consommer un contexte de travail actuel, émettre soit une réponse finale soit une demande d’action structurée, et renvoyer suffisamment de métadonnées pour soutenir les tentatives et la traçabilité. L’API Responses d’OpenAI est explicitement conçue pour les interactions étatiques en plus des outils intégrés et de l’appel de fonctions. L’API Messages d’Anthropic expose la même boucle de base à travers les blocs tool_use et les retours tool_result, tandis que Managed Agents vous donne un harnais hébergé si vous ne souhaitez pas construire la boucle vous-même. Les temps d’exécution auto-hébergés tels que vLLM et llama.cpp sont importants car ils préservent des interfaces de style fournisseur familières tout en vous permettant de placer l’inférence dans votre propre environnement.

La couche Mémoire devrait être divisée mentalement en trois compartiments : mémoire de travail, mémoire symbolique durable et mémoire sémantique recherchable. Les embeddings d’OpenAI retournent des vecteurs qui peuvent être indexés et recherchés ; OpenAI Retrieval et File Search superposent ensuite la recherche sémantique et par mots-clés sur les bases de données vectorielles. Pinecone, Weaviate, pgvector et Milvus représentent quatre formes de stockage courantes : entièrement gérée, vectorielle open source, native Postgres et base de données vectorielle distribuée. Hermes et OpenClaw ajoutent un rappel utile que toute mémoire n’appartient pas dans une base vectorielle : les notes adossées à des fichiers, les promotions examinées et les instantanés limités à la session sont souvent le plus honnête des conceptions. [Systèmes de Mémoire dans les Assistants IA](https://www.glukhov.org/fr/ai-systems/memory/memory-systems-in-ai-assistants/ « Comment concevoir une mémoire à court terme, à long terme et structurée pour les assistants IA, avec les mécaniques de récupération, les compromis, les modes d’échec et les motifs réels. ») cartographie le modèle inter-cadre ; le [Système de Mémoire de l’Agent Hermes](https://www.glukhov.org/fr/ai-systems/hermes/hermes-agent-memory-system/ « Un guide technique approfondi de l’architecture mémoire de l’Agent Hermes — de la mémoire centrale limitée à 2 fichiers aux 8 fournisseurs externes extensibles. ») détaille la mémoire centrale limitée et les instantanés de session gelés dans un produit.

La couche Outils est là qu’un assistant cesse d’être un résumateur pour devenir un logiciel. L’appel de fonctions d’OpenAI traite les outils comme des fonctionnalités définies par schéma que le modèle peut décider d’invoquer. Anthropic dit la même chose plus explicitement : l’utilisation d’outils est un contrat entre votre application et le modèle, et le modèle n’exécute jamais rien seul. MCP généralise ce contrat en un protocole client-serveur où les hôtes se connectent à un ou plusieurs serveurs qui exposent des outils, des prompts et des ressources — la même frontière décrite étape par étape dans [Serveur MCP en Go](https://www.glukhov.org/fr/ai-systems/mcp/mcp-server-in-go/ « Le Protocole de Contexte de Modèle (MCP), comment implémenter un serveur MCP en Go, y compris la structure des messages, les spécifications du protocole, les bibliothèques et une implémentation d’exemple. »). LangChain et LlamaIndex se positionnent confortablement ici en tant que bibliothèques d’orchestration : LangChain se concentre sur une architecture d’agent préconstruite et les intégrations, tandis que LlamaIndex se concentre sur l’accès aux données augmentées par contexte, les moteurs de requête et les flux de travail.

La couche Routage existe parce que « quel modèle ? » n’est jamais la seule question. Vous avez aussi besoin de « quel chemin de fournisseur, quel locataire, quel budget, quelle classe de latence et quel repli ? ». LiteLLM est utile car ses documents officiels sont rafraîchissamment concrets : le choix pondéré, le moins occupé, le routage basé sur la latence, le routage basé sur le coût et les bascules bornées sont tous des motifs de premier ordre. OpenClaw étend le routage vers le haut dans l’isolation des canaux et des agents, tandis que Hermes l’étend vers le bas dans les emplacements de modèles pour le travail principal et auxiliaire tel que la résumée, la compression de contexte et le routage d’outils MCP. C’est le bon modèle mental : le routeur choisit plus qu’un modèle, il choisit une voie d’exécution.

La couche Observabilité est ce qui empêche l’architecture de se transformer en folklore. OpenTelemetry vous donne l’abstraction de trace. LangSmith vous donne une visibilité de bout en bout sur les étapes des applications LLM et prend en charge les formes de déploiement cloud, hybride et auto-hébergées. OpenLIT vous donne une observabilité IA native OpenTelemetry avec des options d’instrumentation sans code et manuelle, y compris le support pour les LLM, les cadres d’agents, les bases de données vectorielles et les GPU. Pour les métriques, traces et motifs SLO de production à travers les flux de travail d’inférence et d’agents, voir [Observabilité pour les Systèmes LLM](https://www.glukhov.org/fr/observability/observability-for-llm-systems/ « Un guide approfondi et axé production sur l’observabilité des systèmes LLM, couvrant les métriques LLM, le traçage distribué, les journaux, le profilage, les tests synthétiques, les SLO et une comparaison des outils d’observabilité LLM. »). Si votre assistant n’a pas de trace par requête, de span par appel de modèle et d’historique d’événements pour l’exécution d’outils, vous n’avez pas vraiment d’architecture encore. Vous avez des intuitions.

Capturer, enrichir, répondre

La séquence qui ne cesse de se manifester dans les systèmes réels est capturer -> enrichir -> répondre -> enregistrer. Différents cadres l’encapsulent différemment, mais le flux est assez stable pour être traité comme la colonne vertébrale.

L’étape de capture est souvent plus importante qu’elle n’en a l’air. OpenClaw et Hermes placent tous deux une passerelle persistante devant l’assistant parce que l’entrée n’est pas juste la saisie de texte. Elle inclut les métadonnées de canal, les identités, l’autorisation, les limites de session, les messages directs, les groupes, les tics cron et les sémantiques de livraison. Si vous sautez cette couche et vous fiez à une abstraction de widget de chat brut, vous finirez par la rajouter comme middleware ad hoc de toute façon.

L’étape d’enrichissement est là que les systèmes matures divergent des démos de jouet. OpenAI Retrieval et File Search rendent la récupération explicite à travers les bases de données vectorielles et les appels de recherche. LlamaIndex formalise le même motif à travers les connecteurs de données, les index, les moteurs de requête et les flux de travail. Hermes va plus loin en divisant le parc de modèles en emplacements principaux et auxiliaires, déléguant des travaux tels que la compression, la résumée et le routage à des modèles plus petits ou plus spécialisés. C’est un motif de conception qu’il vaut la peine de voler : ne dépensez pas vos jetons de modèle les plus chers sur des corvées.

L’étape de réponse n’est pas « générer du texte ». C’est « fermer la boucle actuelle ». Si le modèle peut répondre directement, il le fait. S’il a besoin d’un outil, il émet une demande structurée. Le contrat d’utilisation d’outils d’Anthropic et le guide d’appel de fonctions d’OpenAI le rendent tous deux explicite. La raison pour laquelle cela importe architecturalement est que les sorties incluent désormais à la fois le langage et le flux de contrôle. Votre objet de réponse est en partie prose et en partie plan d’exécution.

L’étape d’enregistrement est là que les sémantiques de cohérence apparaissent. Pinecone sépare les chemins d’écriture et de lecture et traite les écritures après confirmation durable. La mémoire de Hermes est injectée en tant qu’instantané gelé par session afin de pouvoir préserver les performances du cache de préfixe, ce qui signifie que les nouvelles écritures n’apparaissent pas automatiquement dans le prompt de la session actuelle. Le système de Rêverie d’OpenClaw ne promeut que les candidats examinés et fondés dans MEMORY.md, et il est facultatif plutôt que toujours actif. La leçon pratique est que la mémoire est rarement véritablement « lecture-après-écriture » à travers toutes les couches. Vous devez concevoir pour une visibilité par étapes.

OpenClaw et Hermes comme systèmes de référence

OpenClaw et Hermes sont de bons cas de référence car ils ne sont pas juste des enveloppes autour d’une API de fournisseur. Les deux présentent un assistant comme un système à long terme avec des passerelles, des sessions, des outils, de la mémoire et de multiples arrière-plans de modèles.

Ce mapping est fondé sur les documents et dépôts officiels d’OpenClaw et Hermes. OpenClaw documente une architecture de passerelle, le routage multi-agent, le support de fournisseurs personnalisés et auto-hébergés y compris vLLM et Ollama, la mémoire active optionnelle et la promotion basée sur la Rêverie. Hermes documente une passerelle de messagerie, une boucle centrale AIAgent, des emplacements de modèles principaux et auxiliaires, la mémoire intégrée et l’intégration MCP native.

Ma lecture légèrement opinée est que les deux systèmes font le même argument architectural dans des accents différents. OpenClaw est fortement centré sur la passerelle. Hermes est fortement centré sur la boucle d’agent. Mais les deux rejettent l’idée superficielle qu’un assistant est juste « prompt plus modèle ». Ils modélisent les canaux, les identités, les sémantiques de mémoire, les surfaces d’outils et l’hétérogénéité de l’arrière-plan comme des préoccupations de premier ordre. C’est exactement ce qu’une architecture de production devrait faire.

Une pile hybride pratique inspirée des deux systèmes ressemble à ceci :

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

Cette pile est un motif de déploiement raisonné plutôt qu’un plan de déploiement prescrit par un fournisseur. Elle fonctionne parce que les interfaces officielles s’alignent : OpenAI et Anthropic exposent des API orientées outils, vLLM et llama.cpp émulent des endpoints de style fournisseur, Ollama gère les modèles et embeddings locaux, MCP standardise les outils externes, LiteLLM gère le routage et le basculement, et les plateformes compatibles OpenTelemetry peuvent tracer le chemin complet.

Motifs, tableaux et compromis

Il y a quelques motifs d’assistant répétables qu’il vaut la peine de nommer. Un assistant géré conserve la majeure partie du temps d’exécution dans les API du fournisseur. Un assistant de récupération prioritaire traite la mémoire et la recherche comme le principal différenciateur. Un assistant d’outils prioritaire se comporte plus comme un opérateur qu’un chatbot. Un assistant de passerelle priorise l’accès permanent à travers les surfaces de messagerie. Un maillage de spécialistes décompose le travail en plusieurs agents ou routes. Les documents officiels d’OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw et Hermes soutiennent tous des versions de ces motifs, même s’ils les nomment différemment.

Le motif de maillage de spécialistes grandit pour devenir une discipline d’ingénierie distincte lorsque le nombre d’agents augmente. Pour les six motifs de coordination canoniques — orchestrateur-travailleur, pipeline séquentiel, diffusion, hiérarchique, essaim et maillage — avec des modes d’échec spécifiques et un cadre de décision de production, voir [Motifs d’Orchestration Multi-Agent](https://www.glukhov.org/fr/ai-systems/architecture/multi-agent-orchestration-patterns/ « Six motifs d’orchestration multi-agents éprouvés pour les systèmes IA de production : orchestrateur-travailleur, pipeline séquentiel, diffusion, hiérarchique, essaim et maillage. »).

Ce tableau des motifs est une synthèse des documents des fournisseurs, des documents des cadres et des systèmes de référence plutôt qu’une affirmation d’un seul fournisseur.

Notes du tableau : OpenAI hosted File Search est un outil géré, Anthropic offre un harnais géré, Pinecone est un service vectoriel géré, tandis que vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith auto-hébergé et OpenLIT prennent tous en charge le fonctionnement auto-géré ou hybride dans des degrés variés.

Notes du tableau : Pinecone documente un plan de contrôle géré et des plans de données régionaux. Weaviate documente les index vectoriels et inversés avec plusieurs types d’index vectoriels. pgvector ajoute la recherche de plus proche voisin exacte et approximative à Postgres. Milvus se positionne comme une base de données vectorielle open source haute performance et scalable, avec Zilliz Cloud comme option gérée.

Notes du tableau : OpenAI documente Responses comme son interface avancée pour les réponses étatiques et les outils intégrés. Anthropic documente l’API Messages et le contrat d’utilisation d’outils séparément de Managed Agents. vLLM expose un serveur compatible OpenAI plus le support de l’API Messages d’Anthropic. Ollama documente les flux de travail d’embeddings et de modèles locaux. llama.cpp documente les routes de chat, de réponses et d’embeddings compatibles OpenAI, plus les complétions de chat compatibles Anthropic.

Cette matrice de compromis est une inférence architecturale des documents officiels, pas un banc d’essai du fournisseur. La ligne de cohérence importe plus que beaucoup d’articles de blog ne l’admettent : Pinecone sépare les chemins d’écriture et de lecture, Hermes gèle la mémoire dans les prompts de début de session, et OpenClaw promeut la mémoire durable par examen par étapes. Cela signifie que « mémoire mise à jour » et « mémoire visible pour la réponse actuelle » sont souvent des vérités différentes.

Modes d’échec et atténuations

La plupart des assistants n’échouent pas parce que le modèle de base est « mauvais ». Ils échouent parce que le système environnant ment au modèle, le prive du bon contexte, laisse les outils dériver ou rend le débogage impossible.

La base d’évidence pour ce tableau est large mais cohérente. Les documents d’outils d’Anthropic font clairement que l’utilisation d’outils est une frontière de contrat. OpenAI Guardrails inclut la détection d’hallucination contre une base de connaissances de référence via File Search. SelfCheckGPT montre que l’auto-cohérence à travers les échantillons peut aider à détecter les affirmations non soutenues. Les résultats de « Lost in the Middle » et les directives de contexte d’Anthropic renforcent tous deux la même leçon opérationnelle : plus de jetons ne suppriment pas le besoin de curation du contexte.

La pile d’atténuation préférée pourrait être ennuyeuse et répétitive : tracer chaque requête, versionner les prompts, évaluer la récupération indépendamment, garder les outils idempotents et exécuter des évaluations de régression avant de changer les routes ou la politique de mémoire. Les documents et le dépôt d’évaluations d’OpenAI sont francs sur pourquoi : sans évaluations, il est difficile et chronophage de comprendre comment les modifications de modèle ou de prompt affectent votre cas d’usage. Cela s’applique autant aux routeurs et à la récupération qu’aux prompts.

Lecture supplémentaire

Si vous voulez aller plus loin, voici les sources primaires les plus utiles à garder ouvertes pendant que vous concevez ou révisez une architecture d’assistant.

• OpenAI : Aperçu des Responses, Appel de Fonctions, Utilisation d’Outils, Récupération, File Search, Évaluations et MCP pour les serveurs d’outils distants.

• Anthropic : Aperçu de l’API, Utilisation d’Outils, le contrat d’utilisation d’outils, Agents Gérés, Fenêtres de Contexte et le connecteur MCP.

• MCP lui-même : l’Aperçu de l’Architecture et la Spécification valent la peine d’être lus directement, parce qu’ils expliquent les hôtes, les clients, les serveurs, les outils, les prompts, les ressources, les transports et la négociation de capacités proprement. Pour une comparaison pratique de MCP avec le protocole Agent2Agent et quand un système multi-agent a besoin des deux couches, voir [A2A vs MCP : Les Agents IA ont-ils vraiment besoin des deux protocoles ?](https://www.glukhov.org/fr/ai-systems/mcp/a2a-vs-mcp-ai-agent-protocols/ « Une comparaison pratique de A2A et MCP pour les systèmes d’agents IA, couvrant les outils, les agents, les motifs d’architecture, le chevauchement, la sécurité et quand utiliser les deux. ») et pour les concepts de A2A eux-mêmes — Cartes d’Agent, cycle de vie des tâches, messages, parties et artefacts — voir [Qu’est-ce que le Protocole A2A ? Cartes d’Agent et Tâches Expliquées](https://www.glukhov.org/fr/ai-systems/architecture/a2a-protocol-explained/ « Un guide pratique du Protocole A2A pour les agents IA, expliquant les Cartes d’Agent, les tâches, les messages, les parties, les artefacts, la découverte et les compromis d’architecture. »).

• Assistants de fond et proactifs : la couche d’outils n’est qu’une partie de la façon dont les assistants agissent. Pour comment faire en sorte qu’un assistant surveille, décide et agisse de son propre chef — planificateurs, travailleurs basés sur files d’attente, protocoles de revendication, flux de travail durables et interrogation sémantique — voir [Agents d’Interrogation dans les Assistants IA : 11 Motifs d’Implémentation](https://www.glukhov.org/fr/ai-systems/architecture/polling-agents-ai-assistants-implementation-patterns/ « Un guide pratique des motifs d’agents d’interrogation dans les assistants IA — planificateurs, files d’attente, webhooks, flux de travail durables, gestion d’état et compromis pour les systèmes de production. »).

• Autorité de décision : pour les décisions qu’un modèle devrait faire, recommander ou seulement informer — les cinq rôles de décision, le routage basé sur la confiance vers le plus petit étage compétent et les portes d’approbation dimensionnées au rayon de dégât — voir [LLM de Décision : Quand un Modèle Devrait Décider — et Quand Il Ne Le Devrait Pas](https://www.glukhov.org/fr/ai-systems/architecture/decision-llms-when-models-should-decide/ « Cinq rôles de décision, le routage basé sur la confiance vers le plus petit modèle compétent et la machinerie de vérification qui rend l’appel d’un modèle auditable. »).

• Protocole A2A et adoption : une fois que les agents sont déployés indépendamment et ont besoin de collaborer à travers les limites de propriété, A2A devient pertinent. Pour une vue pratique de 2026 de l’endroit où A2A a réellement de la traction, les questions de sécurité qu’il soulève et un cadre de décision pour quand l’adopter, voir [Protocole A2A de Google en 2026 : Adoption, Buzz et Réalité](https://www.glukhov.org/fr/ai-systems/comparisons/a2a-protocol-2026-adoption/ « Le protocole A2A de Google est-il réellement utile en 2026 ? Un examen pratique de l’adoption de A2A, du chevauchement de MCP, des préoccupations de sécurité et de quand utiliser les protocoles agent-à-agent en production. »). Lorsque ces agents échangent des tâches de longue durée plutôt que des tours de chat simples, le [Streaming A2A et Tâches Asynchrones pour les Flux de Travail d’Agents de Longue Durée](https://www.glukhov.org/fr/ai-systems/architecture/a2a-streaming-async-task-lifecycle/ « Comment concevoir le streaming du protocole A2A, les tâches asynchrones, les notifications push et les flux de travail d’agents de longue durée. ») couvre SSE, push et la conception de input_required à la frontière du protocole.

• Cadres et routage : LangChain Overview, documents d’augmentation de contexte de LlamaIndex, documents de routage de LiteLLM, documents d’observabilité de LangSmith.

• Temps d’exécution auto-hébergés et systèmes d’assistants : vLLM, serveur llama.cpp, embeddings Ollama, documents et dépôt d’OpenClaw, documents et dépôt de Hermes.

• Stockage et observabilité : Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Papiers de recherche : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle, et SelfCheckGPT.