Habr AI mostrou como preparar entrada estruturada para um agente de AI em vez de uma especificação técnica bruta

O Habr AI publicou uma análise detalhada sobre o que exatamente precisa ser alimentado a um agente de IA quando a tarefa é verificar requisitos técnicos em vez de simplesmente parafraseá-los. A ideia principal: em vez de o agente receber um documento de especificação inteiro, ele recebe um conjunto de requisitos atômicos na forma de passaportes JSON.

Por que uma única especificação não é suficiente

O autor do artigo começa com um problema familiar para quase todos que já tentaram fornecer um grande documento a uma rede neural por completo. Quando um modelo recebe uma especificação com várias páginas sem preparação prévia, ele perde o foco, mistura requisitos de diferentes seções e fornece observações muito genéricas. Como resultado, o sistema pode notar imprecisões individuais, mas tem dificuldade em explicar qual ponto específico é problemático, por que é problemático e o que precisa ser corrigido.

Por isso, o documento é primeiro dividido em requisitos separados: uma ação, uma regra ou uma restrição por fragmento. Para não perder o contexto durante essa fragmentação, cada elemento recebe campos como `parent_section` e `parent_object`, e pontos logicamente relacionados são marcados como `linked`. Isso importa quando vários requisitos devem ser verificados juntos: por exemplo, quando o sistema deve enviar uma notificação tanto por e-mail quanto por Telegram, não apenas por um canal.

Passaporte de requisito

O próximo passo é converter a linguagem humana em um conjunto de características com as quais um classificador pode trabalhar. Nesse esquema, o LLM não serve como juiz final e não tenta "entender tudo." Seu papel é muito mais estreito: extrai sinais estruturados do texto e os coleta em JSON. Essa abordagem oferece controle: as características podem ser verificadas, comparadas e corrigidas em pós-processamento, se necessário. Como o autor coloca:

"o agente trabalha não com texto, mas com essas estruturas."

O artigo descreve seis características básicas que formam a base desse passaporte. Em vez de uma avaliação de qualidade abstrata, o modelo procura sinais específicos: números, palavras vagas, exceções, limites e participantes explícitos do cenário. Na prática, esse passaporte transforma uma frase como "o usuário deve configurar o relatório com flexibilidade" em um conjunto compreensível de sinalizadores que imediatamente mostram o que falta ao requisito. Essa interpretabilidade é precisamente o que distingue o esquema de simplesmente pedir a um modelo para avaliar o texto como um todo.

• `has_numbers` — se o requisito contém números, limites, datas e outros parâmetros específicos
• `stopword_score` — quão vaga é a formulação devido a palavras como "flexível," "conveniente" ou "rápido"
• `has_negative_keywords` — se exceções e erros são descritos
• `boundary_conditions_mentioned` — se valores vazios, máximos, mínimos ou outros limites são especificados
• `actor_count` — quantos participantes são explicitamente mencionados no requisito

As características em si são extraídas através do modo JSON e exemplos few-shot para manter o modelo dentro do formato. Se o LLM ainda perder algo óbvio, como números no texto, isso é reforçado no pós-processamento através de expressões regulares. Em seguida, vem uma árvore de decisão: ela recebe características numéricas e atribui ao requisito um rótulo como `ok`, `unverifiable`, `no_negative`, `no_boundary` ou `ambiguity`. Para treinamento, o autor rotulou 90 especificações, dividiu-as em 270 requisitos e alcançou aproximadamente 82% de precisão no conjunto de testes.

Crítico e escala

O pipeline não termina aí. Até mesmo um bom classificador vê apenas um requisito por vez, o que significa que pode facilmente perder contradições entre seções. Para tais casos, é usado um agente crítico separado, que recebe o texto completo da especificação, a lista de passaportes JSON e os rótulos preditos.

Sua tarefa não é reavaliar cada frase do zero, mas ver o documento de cima e procurar conflitos, lacunas nos direitos de acesso e erros no mapeamento de integrações. Esse crítico pode, por exemplo, notar que em um lugar o campo "Depósito" é obrigatório, enquanto em outro um valor vazio é permitido. Para fazer o esquema funcionar não apenas em exemplos curtos, os requisitos são processados em paralelo através de `ThreadPoolExecutor`, e modelos locais são executados no Ollama.

O autor observa que em um PC de jogos típico, o sistema lida confortavelmente com 4–6 requisições paralelas sem degradação notável, e em um lote de cem requisitos, isso oferece uma aceleração de aproximadamente 3–4 vezes. Os requisitos relacionados permanecem em um único thread para manter a ordem e o contexto geral de verificação.

O que isso significa

A análise no Habr AI mostra claramente para onde está se movimentando o desenvolvimento prático de agentes de IA: de tentativas de "alimentar o modelo com tudo de uma vez" para pipelines estreitos e controlados com características explícitas, modelos locais e uma camada separada de arbitragem. Se uma equipe quer construir um agente prático para análise, QA ou trabalho com documentação, ela precisará pensar não apenas na escolha de um modelo, mas também em como os dados de entrada, a rotulagem e a verificação final dos resultados são estruturados.