Truncamento Sintático

O que é e como aplicar na prática

Truncamento sintático é basicamente a remoção de elementos gramaticais que podem ser inferidos pelo contexto, deixando apenas o núcleo necessário da frase. Na língua portuguesa isso aparece o tempo todo: "Eu comi arroz e ele feijão", onde o verbo "comer" é truncado na segunda coordenação. O processo é natural na fala, mas quando você precisa automatizar ou normalizar textos, vira um problema real de processamento. Eu já passei sufoco com isso em um projeto de normalização de dados jurídicos. O sistema precisava extrair trechos de atas e contratos onde os sujeitos variavam a cada cláusula. A primeira versão do parser simplesmente quebrava porque assumia que cada oração tinha estrutura completa. Eu tentei usar expressões regulares ingênuas baseadas em padrões fixos de sujeito-verbo-objeto, e o resultado era um horror de falsos positivos. A solução foi implementar um analisador baseado em dependências sintáticas usando o UDPipe, identificando vértices da árvore que eram elípticos e restaurando os elementos ausentes antes de processar. Levou duas semanas de ajuste, mas depois rodou limpo.

Truncamento sintático em pipelines de NLP

Se você está trabalhando com PLN e precisa lidar com textos que contêm coordenação elíptica, aqui vai o que realmente funciona. O ponto mais importante é entender que truncamento sintático não é o mesmo queellipsis genérica. Há diferenças finas que afetam como cada ferramenta lida com o fenômeno. Passo a passo prático:

Primeiro, tokenização e segmentação. Use um tokenizer que respeite as regras de contrações portuguesas (do, na, pro, pra). Uma tokenização ruim já estraga qualquer tentativa posterior. O Universal Dependencies 2.12 funciona bem para português brasileiro. Depois, o parsingencial. Aqui está a parte que ninguém conta direito: ferramentas como StanfordParser eUDPipe tratam elipses de formas diferentes. O UDParse tende a criar nós Empty (EMPTY) para os elementos truncados, enquanto o spaCy com modelos treinados em PDTB às vezes simplesmente ignora a coordenação elíptica e trata como orações independentes. Para truncamento sintático específico, o que eu recomendo é usar o UDPipe com o modelo udp-portuguese-ewt, e depois post-processar os nós de tipo nsubj e obl marcados como Empty.

O script de pós-processamento é o que faz a diferença. Você varre a árvore procurando coordenações (conjuntos ligados por cc) onde o verbo da segunda conjunção é idêntico ao da primeira, e os argumentos semânticos estão ausentes nos nós vacuos. Nesses casos, você pode either: (a) restaurar os elementos para normalização, ou (b) marcar o trecho como truncado e preservar a forma original, dependendo do seu objetivo. Aqui vai um exemplo concreto. Texto original: "Maria comprou pão e João manteiga." A árvore de dependências mostra "comprou" como head de "Maria", e "e" como coordination connector ligando as duas orações. O verbo na segunda oração está vazio (vform=EMPTY). Os nós "pão" e "manteiga" são objetos diretos de verbos diferentes. O truque é identificar que "manteiga" não pode ser objeto direto de "comprou" na segunda oração porque o verbo falta, e portanto há truncamento sintático aqui. A forma restaurada seria "Maria comprou pão e João comprou manteiga."

Um detalhe importante que os tutoriais não mencionam: truncamento sintático também aparece em subordinadas reduzidas. "Ao chegar em casa, ligou para a mãe." O sujeito de "ligou" está truncado e co-referencial com o sujeito implícito de "chegar". Isso quebra parsers mais simples que não lidam bem com subordinadas adjuntas sem explicitar o sujeito. Se o seu pipeline não trata isso, você vai ter erros de ancoragem de entidades corefereciais constantes. Pitfalls comuns:

O maior erro que vejo pessoas cometendo é tentar resolver truncamento sintático só com regex ou regras string-based. Isso funciona para casos muito simples, mas escala mal. A forma "o irmão mais velho do meu tio e sua esposa foram" cria ambiguidade real sobre quem é o sujeito da segunda coordenada. Regex não resolve isso. Use parsingencial sempre que possível. Outro problema: truncamento assimétrico. Às vezes só o sujeito é truncado, às vezes só o objeto, às vezes ambos. O tratamento precisa ser flexível o suficiente para lidar com todas essas combinações. Um parser que assume que apenas sujeito pode ser elíptico vai falhar em construções como "Eu li o livro e comprei" onde é o objeto que está faltando.

Quando não usar: Truncamento sintático não é solução universal. Se o seu texto alvo é linguagem formal muito estruturada (contratos, leis, estatutos), o parsingencial já lida bem com a maioria dos casos sem necessidade de restauração explícita. Gastar tempo implementando um módulo de truncamento nesses cenários é desperdício. O ganho real vem em textos jornalísticos, redes sociais, transcrições de fala e documentos administrativos informais, onde a elipse é frequente e o parsing padrão falha mais.

Para quem quer começar rápido, o pacote tokenizers-truncate no PyPI tem uma implementação básica de detecção de coordenação elíptica em português. Não é state-of-the-art, mas cobre 80% dos casos comuns. O repositorio do GitHub tem exemplos prontos que você adapta em menos de uma hora. Eu já testei vários pacotes similares e a maioria tem problemas com casos de ellipsis de verbo em contextos mistos (onde o segundo verbo é diferente mas o sentido é equivalente). Nesses casos, nenhuma ferramenta automática acerta — você precisa de intervenção manual ou de um modelo fine-tuned específico para o domínio.