Dans le choix de l’outil par le LLM, il apparait que le nom de la fonction (= le nom de l’outil) est totalement prioritaire, que la la Docstring vient ensuite, elle-même prioritaire sur la métadonnée ’description’ [1] . De toute évidence, ni la Docstring ni la description ne peuvent compléter un nom de fonction ambigu, elle ne serviront qu’en cas de deuxième intention du LLM, après avoir constaté une erreur.

Exemple d’ambiguïté

Considérons un outil qui convertit une date lisible par un humain (human-readable date) en timestamp. Initialement nommé ’convert_date_to_timestamp’. On peut constater que l’usage de l’outil est mal compris par le LLM qui, notamment, peut tenter de l’utiliser à l’envers.

Le mot "date" est trop générique, et dans un contexte LLM, il peut désigner aussi bien une date lisible qu’un timestamp.

Pour éviter toute ambiguïté, il faut que le nom de l’outil encode clairement :

• le type d’entrée attendu (ex. : texte lisible par un humain),
• le type de sortie produit (ex. : timestamp numérique),
• et idéalement, la direction de la conversion : l’entrée en tête, la sortie en queue.

Un meilleur choix serait : readable_date_to_timestamp

• readable_date désambiguïse immédiatement : ce n’est pas un timestamp.
• to_timestamp indique clairement la direction.
• C’est court, typiquement LLM-friendly, et sans ambiguïté.

Ce qu’il faut éviter :

• Des noms ambigus comme convert_dates ou parse_date (trop flous)
• Des noms au singulier pour des fonctions vectorisées (ex. date_to_timestamp qui prend une liste)
• Des noms inverses (timestamp_to_date) qui risquent d’être utilisés à contresens si mal nommés

Distinction entre fonction unitaire et vectorisée

L’outil readable_date_to_timestamp est ’unitaire’ dans le sens où il n’effectue qu’une seule conversion.

Prenons le cas d’un outil qui transformerait une liste de dates humainement lisibles en la liste des timestamps correspondants. Comment nommer un tel outil ? Un nom comme readable_dates_to_timestamps sera bien interprété par un LLM comme une opération vectorisée (liste → liste), surtout si :

• le nom est au pluriel (dates, timestamps),
• il suit une convention claire et régulière dans l’ensemble des outils,
• la Docstring ou l’intension associé confirme ce comportement,
• on évite (faut-il le préciser ?) de créer des outils d’intention différente avec un nom similaire.

Pourquoi ce nom est bien compris :

• readable_dates → explicite que l’entrée est une liste de dates lisibles.
• to_timestamps → suggère une transformation vers une liste de timestamps.
• Le pluriel des deux côtés induit une correspondance élément par élément.

Mais il y a quelques subtilités à garder en tête pour éviter toute confusion. C’est une convention que les LLM comprennent bien, surtout si :

• on l’applique systématiquement (ex. : texts_to_embeddings, urls_to_titles, etc.),
• il existe (comme dans notre exemple) la version unitaire.
• l’outil expose une Docstring explicite et non contradictoire :

  """
  Converts a list of human-readable date strings into a list of UNIX timestamps in milliseconds.
  """

• on expose aussi une version unitaire : readable_date_to_timestamp → pour une seule date readable_dates_to_timestamps → pour une liste
• on évite les inversions en exposant les outils inverses : timestamp_to_readable_date → pour une seule date timestamp_to_readable_date → pour une liste

Encore un défaut !

Cependant, notre exemple présente encore un défaut : la Docstring fait apparaître le timestamp comme étant un ’UNIX timestamps in milliseconds’. Or, fin 1990-début 2000 sont apparus les timestamp en microsecondes puis, dans les années 2010, en nanosecondes.

Le LLM risque de découvrir trop tard (en reprenant le raisonnement après avoir constaté l’erreur) que l’outil ne fonctionne qu’avec des timestamps en millisecondes !

Prenant modèle sur Python, il faut renommer nos fonctions avec timestamp_ms ou timestamp_ns. Voici donc le jeu complet (pour un format millisecondes) : readable_date_to_timestamp_ms readable_dates_to_timestamps_ms timestamp_ms_to_readable_date timestamp_ms_to_readable_date

Sur ce sujet, voir également : ReAct : la carte des intentions : Intent Map