Habr AI a montré comment préparer une entrée structurée pour un agent AI plutôt qu’un cahier des charges brut

Habr AI a publié une analyse détaillée sur ce qui doit exactement être fourni à un agent IA lorsque la tâche consiste à vérifier les exigences techniques plutôt que simplement de les paraphraser. L'idée principale : au lieu que l'agent reçoive un document de spécification entier, il reçoit un ensemble d'exigences atomiques sous la forme de passeports JSON.

Pourquoi une seule spécification ne suffit pas

L'auteur de l'article commence par un problème familier à presque tous ceux qui ont tenté de fournir un gros document à un réseau de neurones en entier. Lorsqu'un modèle reçoit une spécification de plusieurs pages sans préparation préalable, il perd sa concentration, mélange les exigences provenant de différentes sections et fournit des observations trop générales. En conséquence, le système peut remarquer des inexactitudes individuelles, mais il a du mal à expliquer quel point spécifique est problématique, pourquoi il l'est et ce qui doit être corrigé.

C'est pourquoi le document est d'abord divisé en exigences séparées : une action, une règle ou une contrainte par fragment. Pour ne pas perdre le contexte lors de cette fragmentation, chaque élément est augmenté avec des champs comme `parent_section` et `parent_object`, et les points logiquement liés sont marqués comme `linked`. Cela importe quand plusieurs exigences doivent être vérifiées ensemble : par exemple, quand le système doit envoyer une notification à la fois par e-mail et par Telegram, pas seulement par un seul canal.

Passeport d'exigence

L'étape suivante consiste à convertir le langage humain en un ensemble de caractéristiques avec lequel un classificateur peut travailler. Dans ce schéma, le LLM ne joue pas le rôle de juge final et ne tente pas de « tout comprendre ». Son rôle est beaucoup plus étroit : il extrait des signaux structurés du texte et les rassemble en JSON. Cette approche offre un contrôle : les caractéristiques peuvent être vérifiées, comparées et corrigées en post-traitement si nécessaire. Comme le formule l'auteur :

« l'agent travaille non pas avec du texte, mais avec de telles structures. »

L'article décrit six caractéristiques fondamentales sur lesquelles repose ce passeport. Au lieu d'une évaluation qualitative abstraite, le modèle cherche des signaux spécifiques : des chiffres, des mots vagues, des exceptions, des limites et des participants explicites du scénario. En pratique, un tel passeport transforme une phrase comme « l'utilisateur doit configurer le rapport de manière flexible » en un ensemble compréhensible de drapeaux qui montre immédiatement ce qui manque à l'exigence. Cette interprétabilité est précisément ce qui distingue ce schéma de la simple demande à un modèle d'évaluer un texte dans son intégralité.

• `has_numbers` — si l'exigence contient des nombres, des limites, des dates et d'autres paramètres spécifiques
• `stopword_score` — à quel point la formulation est vague en raison de mots comme « flexible, » « pratique » ou « rapide »
• `has_negative_keywords` — si les exceptions et les erreurs sont décrites
• `boundary_conditions_mentioned` — si les valeurs vides, les maximums, les minimums ou autres limites sont spécifiés
• `actor_count` — combien de participants sont explicitement mentionnés dans l'exigence

Les caractéristiques elles-mêmes sont extraites via le mode JSON et des exemples few-shot pour garder le modèle dans le format. Si le LLM rate tout de même quelque chose d'évident, comme les chiffres dans le texte, cela est appliqué en post-traitement via des expressions régulières. Vient ensuite un arbre de décision : il reçoit des caractéristiques numériques et attribue à l'exigence une étiquette telle que `ok`, `unverifiable`, `no_negative`, `no_boundary` ou `ambiguity`. Pour l'entraînement, l'auteur a étiqueté 90 spécifications, les a divisées en 270 exigences et a obtenu environ 82 % de précision sur l'ensemble de test.

Critique et échelle

Le pipeline ne s'arrête pas là. Même un bon classificateur ne voit qu'une exigence à la fois, ce qui signifie qu'il peut facilement manquer les contradictions entre les sections. Pour de tels cas, un agent critique séparé est utilisé, qui reçoit le texte complet de la spécification, la liste des passeports JSON et les étiquettes prédites.

Sa tâche n'est pas de réévaluer chaque phrase à partir de zéro, mais de regarder le document d'en haut et de rechercher des conflits, des lacunes dans les droits d'accès et des erreurs dans le mappage des intégrations. Un tel critique peut, par exemple, remarquer que dans un endroit, le champ « Entrepôt » est obligatoire, tandis que dans un autre, une valeur vide est autorisée. Pour que le schéma fonctionne non seulement sur de courts exemples, les exigences sont traitées en parallèle via `ThreadPoolExecutor`, et les modèles locaux sont exécutés dans Ollama.

L'auteur note que sur un PC de jeu typique, le système gère confortablement 4–6 requêtes parallèles sans dégradation notable, et sur un lot de cent exigences, cela offre une accélération d'environ 3–4 fois. Les exigences liées restent dans un seul fil pour maintenir l'ordre et le contexte global de vérification.

Qu'est-ce que cela signifie

L'analyse sur Habr AI montre clairement vers où va le développement pratique des agents IA : des tentatives « d'alimenter le modèle avec tout à la fois » aux pipelines étroits et contrôlés avec des caractéristiques explicites, des modèles locaux et une couche d'arbitrage séparée. Si une équipe souhaite construire un agent pratique pour l'analyse, l'assurance qualité ou le travail avec la documentation, elle devra réfléchir non seulement au choix d'un modèle, mais aussi à la façon dont les données d'entrée, l'étiquetage et la vérification finale des résultats sont structurés.