LLM contre agent IA : Suivre une question d’entretien à travers six questions complémentaires

Si l’on demande à un candidat pour un poste d’ingénieur en IA ce qui distingue un LLM d’un agent d’IA, la première réponse typique est qu’un LLM produit du texte tandis qu’un agent entreprend des actions. L’intervieweur hoche rarement la tête et passe à autre chose. Les questions suivantes permettent de savoir si le candidat a travaillé avec des systèmes réels ou s’il s’est contenté de mémoriser des définitions. Voici comment cette conversation se déroule généralement, question par question.

Ce qu’un LLM fait de lui-même

Un modèle de langage génère une sortie à partir du contexte qui lui est fourni. Il peut expliquer une erreur, résumer des journaux d’activité collés dans la demande ou retourner des données structurées. Il ne peut pas accéder à une base de données privée simplement parce que quelqu’un le demande. Ainsi, lorsque l’intervieweur demande comment un assistant d’assistance en IA pourrait vérifier une transaction en temps réel, la réponse est que cela nécessite des outils ainsi que du code d’application.

Comment un outil est utilisé

Imaginez un message d’un client : « Mon paiement a réussi, mais la commande n’a pas été créée. » Le backend expose quelques fonctions très spécifiques :

getPaymentStatus(transactionId)
getOrderStatus(transactionId)
createSupportTicket(details)

L’application envoie leurs noms et les schémas de paramètres accompagnés de la conversation, et le modèle peut répondre par quelque chose comme ceci :

{
  name: "getPaymentStatus",
  arguments: { transactionId: "txn_123" }
}

La question suivante du interviewer est un piège : le modèle a-t-il simplement appelé le service de paiement ? Non. Il a généré une demande structurée pour utiliser un outil. Rien n’a encore été exécuté.

Qui effectue réellement l’appel ?

C’est le backend. Le flux réel comporte six étapes :

1. L’application envoie la requête accompagnée des définitions des outils.
2. Le modèle renvoie le nom d’un outil ainsi que ses arguments.
3. Le backend vérifie les données entrantes et les permissions de l’appelant.
4. Il exécute la fonction approuvée.
5. Le résultat est renvoyé au modèle en tant que contexte actualisé.
6. Le modèle demande un autre outil ou donne sa réponse finale.

En bref, le LLM propose, tandis que l’application gère l’exécution, les identifiants et le contrôle d’accès. Cette phrase vaut la peine d’être mémorisée, car c’est le point que les intervieweurs expérimentés examinent en profondeur.

Qu’est-ce qui transforme cela en un agent ?

Au tableau blanc, l’équation est courte :

AI Agent = LLM + Instructions + Tools + State + Execution Loop

L’agent surveille son état, choisit une action, obtient le résultat et réévalue, ce qui crée la boucle :

Observe → Decide → Request Tool → Execute → Observe Result → Continue or Stop

La question qui se pose ensuite est de savoir qui l’arrête. Le modèle peut fournir une réponse finale, mais l’application doit imposer des limites. La boucle doit se terminer lorsqu’un plafond de tentatives est atteint, en cas de délai d’expiration, d’une erreur irréparable ou lorsqu’une approbation humaine est requise.

Exécution de plusieurs outils en même temps

Le fait que les appels puissent être exécutés simultanément dépend des dépendances de données. L’état du paiement et l’état de la commande n’ont besoin que de l’ID de transaction, ce qui permet de les récupérer en parallèle :

const [payment, order] = await Promise.all([
  getPaymentStatus(transactionId),
  getOrderStatus(transactionId)
]);

Supposons maintenant que la réponse de paiement contienne une référence de passerelle nécessaire pour l’appel suivant. La deuxième opération doit attendre la première :

const payment = await getPaymentStatus(transactionId);
const gateway = await getGatewayDetails(payment.gatewayRef);

Une réponse solide montre que le candidat vérifie si les appels sont indépendants avant de les paralléliser.

Permettre à l’agent d’émettre un remboursement

La réponse correcte est qu’une simple demande du modèle ne suffit pas. Le système backend doit vérifier l’identité du client, propriétaire de la transaction, déterminer si celle-ci est éligible et connaître les limites en vigueur. L’opération d’écriture nécessite une clé d’idempotence ainsi qu’un journal d’audit, et les remboursements importants peuvent nécessiter l’approbation d’un humain. Un prompt système indiquant "seulement des remboursements pour des transactions valides" sert de guide pour le modèle ; il ne constitue pas une autorisation.

Comment l’interrogateur évalue la réponse

La première réponse, « un LLM génère des réponses, un agent exécute des actions », était trop sommaire pour un poste de niveau senior. Elle ne précisait pas qui exécute les actions, qui possède les accréditations ni ce qui empêche les opérations dangereuses. Après des questions supplémentaires, le candidat a pu fournir une réponse plus solide, mais pour accéder dès le départ au niveau senior, la première réponse aurait dû mentionner immédiatement les limites de l’application ainsi que le cycle de l’agent.