Resumo Técnico: DKSE – Extração Automatizada de Ontologias de Domínio Estruturadas

1. Declaração do Problema

Documentos de requisitos de software servem como os artefatos centrais de conhecimento no desenvolvimento de software empresarial, definindo entidades do sistema, regras, processos e interfaces. No entanto, esses documentos existem como linguagem natural não estruturada, tornando-os inacessíveis para cadeias de ferramentas de engenharia automatizadas. Consequentemente, tarefas subsequentes, como geração de testes, scaffolding de código, verificação de conformidade e desenvolvimento assistido por IA, não podem processar diretamente o conhecimento específico do sistema contido nesses documentos densos em prosa.

As abordagens de automação existentes, que variam de heurísticas iniciais de correspondência de padrões a pipelines recentes de PLN, tipicamente produzem extrações superficiais (ex: listas simples de entidades) e lutam com a complexidade de requisitos do mundo real, incluindo tabelas de múltiplas páginas, regras de referência cruzada, lógica de negócio incorporada e restrições implícitas distribuídas entre seções. Embora os Grandes Modelos de Linguagem (LLMs) ofereçam a capacidade de compreender e sintetizar tais documentos complexos, há uma carência de ferramentas que convertam esse entendimento em ontologias estruturadas abrangentes e legíveis por máquina, adequadas para a automação da engenharia de software.

2. Metodologia: O Pipeline DKSE

O autor apresenta o DKSE (Domain Knowledge Structuring Engine), uma ferramenta projetada para converter automaticamente documentos de requisitos de múltiplos formatos em ontologias de domínio estruturadas. O sistema é implementado em Rust (~8.000 linhas de código) e opera como um pipeline de três estágios:

2.1 Entrada e Parsing (Estágio 1)

O DKSE aceita entradas nos formatos DOCX, PDF, HTML e Markdown.

• DOCX: Processado via extração ZIP/XML para preservar tabelas, cabeçalhos e estruturas de seção.
• PDF: Processado através de extração de texto sensível ao layout.
• HTML: Processado via travessia de DOM.
  A saída deste estágio é um texto estruturado normalizado.

2.2 Análise Semântica Guiada por LLM (Estágio 2)

O texto normalizado é processado por um LLM (via endpoint compatível com OpenAI) utilizando prompts de extração específicos do domínio. Crucialmente, a extração é guiada por esquema: os prompts incluem o esquema YAML alvo para garantir que a saída esteja em estrita conformidade com a estrutura da ontologia. O LLM identifica e estrutura:

• Definições de entidades e esquemas de atributos.
• Regras de negócio com condições formalizadas (triplas de campo + operador + valor).
• Sequências de etapas de processo com papéis associados.
• Definições de endpoints de API.
• Enumerações de dicionário.

2.3 Montagem e Validação da Ontologia (Estágio 3)

Os ativos extraídos são montados em um diretório de seis tipos de ontologia. O DKSE realiza quatro verificações específicas de validação de referência cruzada:

1. Verificação de Tipo de Atributo: Garante que as condições das regras referenciem campos com tipos compatíveis nos esquemas das entidades.
2. Validação de Cardinalidade de Relação: Verifica se as relações (ex: ONE_TO_MANY) ligam entidades extraídas válidas.
3. Completude de Dicionário: Confirma se os códigos de dicionário referenciados pelas regras existem.
4. Detecção de Duplicatas: Sinaliza ativos com nomes idênticos dentro de um domínio.
   Falhas são registradas para revisão humana em vez de serem descartadas silenciosamente, mantendo uma trilha de auditoria completa.

2.4 Esquema da Ontologia

A ontologia resultante é codificada em YAML e compreende seis tipos distintos de ativos:

1. Entidades: Nome, descrição e atributos (nome, tipo, obrigatório).
2. Relações: Entidades de origem/destino e cardinalidade.
3. Regras: Nome, descrição, prioridade e condições formalizadas.
4. Processos: Nome e etapas ordenadas com papéis.
5. APIs: Caminho, método, requisição e definições de resposta.
6. Dicionários: Nome e entradas de código-rótulo.
   Todo ativo inclui um campo source_requirement apontando para a seção do documento de origem para rastreamento de procedência.

2.5 Garantia de Qualidade e Ferramental

O DKSE inclui uma CLI e uma interface web com comandos específicos:

• dkse validate: Verifica a integridade da ontologia (tipos, cardinalidade, referências).
• dkse diff: Compara versões da ontologia para destacar mudanças incrementais (ativos adicionados, modificados, removidos).
• dkse probe: Gera probes de avaliação graduados por máquina (valor exato, campo exato, conjunto, ordenado) a partir da ontologia.
• dkse serve: Uma interface web para navegar, pesquisar e comparar ontologias.

3. Estudo de Caso e Resultados

O autor avaliou o DKSE em seis documentos de requisitos (aprox. 800.000 caracteres chineses) abrangendo quatro subdomínios bancários: Gestão de Desembolso, Gestão de Clientes, Gestão de Contratos de Crédito e Transações com Partes Relacionadas.

3.1 Estatísticas de Extração

O DKSE extraiu com sucesso 3.439 ativos estruturados:

• Entidades: 215
• Regras: 1.227
• Relações: 739
• Processos: 182
• APIs: 594 (cross-domain)
• Dicionários: 482

3.2 Métricas de Qualidade

• Cobertura: O DKSE alcançou 100% de cobertura de módulos funcionais, extraindo pelo menos uma entidade, regra e processo para cada módulo declarado nos sumários dos documentos.
• Precisão: Um especialista de domínio (engenheiro de requisitos bancários sênior) revisou uma amostra estratificada de 100 ativos.
  • 96% foram classificados como totalmente precisos.
  • 3 exibiram variações menores de nomenclatura (semanticamente equivalentes), mas eram utilizáveis.
  • 1 apresentou uma omissão de condição capturada em uma passagem de refinamento.
  • 0 ativos alucinados foram encontrados.
• Procedência: Todos os 100 ativos amostrados possuíam ponteiros de origem corretos para as seções dos documentos originais.

4. Aplicações Subsequentes

O artigo demonstra três casos de uso específicos habilitados pela ontologia extraída:

1. Geração Automatizada de Benchmarks: O comando dkse probe gerou 1.214 probes de avaliação graduados por máquina para um benchmark institucional (FinBench) e 200 probes para avaliação de pré-treinamento contínuo através de quatro domínios.
2. Construção de Corpus de Treinamento de LLM: A ontologia e o texto de requisitos foram combinados para criar um corpus de texto estruturado de aproximadamente 2 milhões de tokens, adequado para ajuste fino supervisionado (SFT) e pré-treinamento contínuo.
3. Ingestão em Grafos de Conhecimento: A ontologia foi ingerida em um sistema GraphRAG, resultando em 5.803 nós e 6.261 arestas. Isso forneceu uma fonte de recuperação para consultas de valores precisos, oferecendo uma vantagem de segurança sobre o treinamento com injeção de pesos ao evitar a fabricação de valores irrecuperáveis.

5. Significância e Alegações

O autor posiciona este trabalho como uma prova de conceito dentro de um único setor (bancário chinês), em vez de uma validação de propósito geral.

• Contribuição Central: O DKSE demonstra que documentos de requisitos podem ser transformados em conhecimento estruturado acionável por máquina (ontologias) que vão além de simples grafos de entidade-relação para incluir regras tipadas, processos ordenados e esquemas de API.
• Valor Prático: A ferramenta preenche a lacção entre requisitos legíveis por humanos e automação de engenharia de software, permitindo tarefas como benchmarking automatizado, criação de corpus de treinamento e geração de código baseada em conhecimento.
• Limitações e Escopo: O autor afirma explicitamente que a avaliação quantitativa em domínios, idiomas adicionais e contra métodos de extração de linha de base é deixada para trabalhos futuros. Eles reconhecem que, embora a extração por LLM alcance alta precisão (96%), a revisão por especialistas continua sendo necessária para erros residuais, e o sistema depende das capacidades do LLM subjacente (ex: modelos treinados em chinês para terminologia chinesa).
• Evolução: O artigo destaca a transição da estruturação manual (levando semanas para um domínio) para a extração automatizada (minutos por domínio), observando que tabelas permanecem um formato desafiador que exige parsing especializado.

O trabalho conclui que, embora alegações mais amplas aguardem avaliações adicionais, o DKSE valida com sucesso a viabilidade do uso de pipelines guiados por LLM para estruturar o conhecimento de domínio para a automação da engenharia de software.