Desenvolvedor alcança 73–86% de concordância com especialista ao preencher questionários de engenharia

Um engenheiro precisa preencher uma folha de dados para o fornecedor de um instrumento industrial: informar pressão, materiais, adequação climática e proteção contra explosões. As respostas estão espalhadas por centenas de páginas da especificação técnica. Parece uma tarefa sob medida para um LLM: encontrar o trecho certo e transferir o valor para uma tabela. No projeto descrito no Habr, a primeira versão preenchia corretamente cerca de um terço das células.

Em dois meses, o autor levou o sistema a 73–86% de concordância com um engenheiro em três projetos, considerando apenas as linhas respondidas pelo profissional. Mas a análise dos erros é mais útil do que o número final. O sistema confundia parâmetros próximos, tentava adivinhar decisões internas do departamento e tratava como perguntas linhas que não exigiam resposta do engenheiro.

A citação é autêntica, a resposta está errada

A primeira versão seguia uma abordagem comum: para cada célula, a busca retornava doze trechos da especificação técnica, e o modelo produzia um valor e uma citação. O código verificava se a citação realmente existia. Isso não foi suficiente.

Um exemplo simples: o sistema escreve “Garantia: 30 anos”. O número está de fato no documento, mas se refere à vida útil do equipamento. A garantia real, de 36 meses, aparece logo perto. A verificação da fonte passa, e o engenheiro recebe uma resposta errada.

O autor transferiu o preenchimento para regras e uma base de referência, deixando ao modelo a extração de fatos. Nos casos em que as regras se aplicavam, 86–92% das respostas estavam corretas. Considerando todas as células de outros dois projetos, o resultado foi de 58%. As regras também transportavam particularidades de um projeto para outro.

Melhorar a busca, por si só, não garantia avanço. Após o treinamento adicional de um modelo pequeno, o item relevante passou a ocupar o primeiro lugar em 63% das linhas, contra 52% antes, mas o número de valores corretos não aumentou. A etapa seguinte continuava pegando o primeiro trecho do qual conseguia extrair alguma coisa. Condições adicionais ajudaram: verificar uma palavra-chave do parâmetro e a unidade de medida do prazo.

Para uma equipe que desenvolve busca em documentos corporativos, essa é uma lição importante: é preciso medir toda a cadeia até a resposta final. Resultados de busca melhores são inúteis se a etapa seguinte os utiliza de forma incorreta.

Parte do conhecimento está no departamento

A revisão de um engenheiro revelou um problema mais profundo. Entre as linhas não padronizadas dos primeiros quatro projetos, o autor não encontrou respostas nos documentos em 65–83% dos casos. Em uma revisão manual de vinte dessas linhas, cerca de metade correspondia a decisões do departamento que vinham sendo copiadas de uma folha de dados para outra havia anos.

O modelo não conseguia extrair essas informações da especificação técnica. Elas não estavam lá. Por isso, o sistema passou a incluir folhas anteriores e padrões do departamento. Respostas coincidentes em dois projetos davam uma base mais sólida para sugerir uma resposta semelhante do que um único exemplo. Ainda assim, parâmetros de um ambiente operacional específico exigem cautela: um valor de outro projeto pode ser inadequado.

Na interface de trabalho, cada resposta traz um link para o item do documento, uma citação e uma página com o trecho destacado. Se não houver embasamento, a linha fica vazia e entra na lista de perguntas para o cliente. O sistema apresenta separadamente as conclusões derivadas de normas, com uma explicação, para revisão do engenheiro.

Um produto assim ajuda a reunir e verificar informações. Seu valor prático também depende da facilidade com que o especialista consegue confirmar um valor, corrigi-lo e salvar a decisão para o próximo projeto.

Percentuais atraentes precisam ser conferidos

O autor encontrou vários erros na própria avaliação. As caixas de seleção dos formulários eram lidas incorretamente. Respostas do projeto avaliado entravam na base por meio de padrões antigos: o resultado parecia ser de 71%, em vez dos 61% reais. A comparação aproximada aceitava IP54 como IP65, embora sejam designações de proteção diferentes.

Por fim, mais da metade das linhas do formulário eram requisitos, listas e campos de assinatura. Depois de excluí-las, o preenchimento subiu de 45 para 81%. Nenhuma resposta correta foi acrescentada: o denominador foi corrigido.

Os 73–86% finais também têm uma limitação. Embora o sistema não tivesse visto as respostas dos três projetos de avaliação, o autor ajustou as regras com base nos erros deles. Em dois projetos, as tabelas dos documentos digitalizados foram transferidas manualmente para o Excel. É um resultado de bancada; a avaliação em um projeto novo ainda está por vir.

A conclusão prática para desenvolvedores: antes de trocar o LLM, vale verificar a estrutura do formulário, as fontes de conhecimento, a busca e o método de avaliação. Para quem gerencia o produto, a próxima pergunta é quanto tempo o engenheiro gasta revisando e corrigindo respostas. É isso que mostrará quanto o sistema ajuda no trabalho.