En bref

  • Problème : les articles sur les agents deviennent vite flous quand les mots techniques servent de décor.
  • Ce que j’ai lu : LLM Field Notes, surtout comme garde-fou de vocabulaire.
  • Résultat : utile pour clarifier des termes, insuffisant pour prouver une conclusion technique.
  • À retenir : un terme comme harness, eval ou memory doit changer quelque chose dans l’outil décrit, sinon il ajoute seulement du bruit.

Source

Cette note commente LLM Field Notes. La source n’est pas la mienne : elle appartient à son auteur. Je l’utilise comme point de lecture pour Project Pezzos, pas comme un glossaire à recopier ou à traduire massivement.

Le dépôt tomerjann/llm-field-notes présente un glossaire LLM orienté ingénierie, avec un fichier GLOSSARY.md qui sert de base au contenu. Pour les termes qui portent une vraie conclusion technique, je veux quand même revenir à des sources primaires, par exemple les bonnes pratiques de prompt engineering OpenAI quand une note parle de prompts.

Pourquoi je garde cette lecture

Dans les articles Project Pezzos autour de Codex, des skills, de la mémoire agent, des evals ou du MCP, le risque n’est pas seulement de se tromper techniquement. Le risque est aussi d’utiliser des mots flous. “Harness”, “mémoire”, “contexte”, “eval” ou “agentic loop” peuvent vite devenir des étiquettes qui donnent l’impression d’expliquer quelque chose alors qu’elles cachent les détails.

LLM Field Notes est utile comme point d’appui parce qu’il force une question simple : qu’est-ce que ce terme change quand on construit vraiment un outil ?

Je ne veux pas en faire une autorité finale. Je veux l’utiliser comme référence de lecture, puis vérifier les termes importants avec des sources primaires quand ils portent une conclusion technique.

Où ça m’aide

Les sujets en cours tournent beaucoup autour de surfaces d’instruction : AGENTS.md, skills, harness, mémoire Markdown, MCP, validation, traces et labs. Avoir un vocabulaire stable aide à éviter les articles qui mélangent architecture, préférence personnelle et hype.

Par exemple, harness ne devrait pas seulement dire “l’environnement autour de l’agent”. Dans une note Project Pezzos, le mot doit pointer vers quelque chose de vérifiable : isolation, commandes lancées, preuves capturées, ou conditions de reprise.

Même chose pour eval. Si je n’ai pas de critère, de données, de répétition ou de score à comparer, je devrais probablement écrire “test manuel” au lieu d’utiliser un mot plus propre.

Un exemple avec un rapport SEO

L’exemple le plus simple dans Project Pezzos est un agent chargé de produire un rapport SEO à partir d’exports Google Analytics et Search Console.

Dans ce cas, context désigne les fichiers réellement disponibles pendant le run : README-data.md, exports CSV, instructions du repo, article en cours, et pages du site ouvertes pour comprendre les recommandations. Si le rapport parle d’une requête absente des exports, ce n’est plus du contexte, c’est une hypothèse.

Un harness serait l’enveloppe qui rend les variantes comparables : même data pack, mêmes prompts, worktrees isolés, traces de run, diffs sauvegardés, puis scoring anonymisé des rapports. Sans ça, on ne sait pas si un meilleur rapport vient d’une meilleure instruction, d’un fichier lu par hasard, ou d’une relance plus précise.

L’eval est le moment où le rapport est jugé. Pas seulement “est-ce que ça a l’air bon”, mais : est-ce que les quick wins citent des pages, requêtes, impressions, CTR ou positions ? Est-ce que deux lecteurs peuvent classer les rapports A/B/C/D sans connaître la variante ?

Une skill, enfin, n’est pas “un meilleur agent”. C’est une instruction réutilisable, chargée quand elle devient utile. Dans ce test, elle devrait encapsuler la méthode de rapport SEO : utiliser les bons fichiers, relier chaque levier à une donnée, expliciter les limites, ne pas modifier le site pendant la génération du rapport.

Ce que je ne sais pas encore

Je ne sais pas si un glossaire public Project Pezzos serait utile. Un glossaire peut vite devenir scolaire. Le format le plus lisible est probablement d’expliquer les termes au moment où ils deviennent nécessaires dans un exemple concret.

Je garde aussi une prudence simple sur la réutilisation : tant que je n’ai pas vérifié précisément la licence et le cadre d’usage de la source, le bon comportement public est de citer, pointer vers elle et paraphraser.

Conclusion prudente

LLM Field Notes est une bonne référence de lecture pour nettoyer le vocabulaire avant d’écrire sur les agents. Ce n’est pas une preuve suffisante pour des conclusions techniques, ni une raison de publier un glossaire complet. Son intérêt principal est plus simple : obliger chaque mot technique à porter une différence observable dans la construction d’un outil.

Sources et liens utiles