Preprint of

ALENCAR, Leonel Figueiredo de. Aelius: uma ferramenta para anotação automática de corpora usando o NLTK. In:
IBAÑOS, Ana Maria T.; MOTTIN, Lívia Pretto; SARMENTO, Simone; BERBER SARDINHA, Tony (Orgs.). Pesquisas e
Perspectivas em Linguística de Corpus. Campinas: Mercado de Letras, 2015. p. 233-282.

Aelius: uma ferramenta para anotação automática de corpora usando o NLTK

Leonel Figueiredo de Alencar (Universidade Federal do Ceará)

Resumo:

Implementada em Python, uma linguagem de programação que se distingue por

suas qualidades didático-pedagógicas, o Natural Language Toolkit (NLTK) tem a
maior abrangência e é a mais amigável biblioteca de código aberto para a análise
automática de textos. O NLTK, contudo, carece no momento de recursos suficientes
de língua portuguesa. No que tange à variedade brasileira, disponibiliza apenas um
corpus morfossintaticamente anotado, restrito a textos jornalísticos. A biblioteca
provê ferramentas para treinar um etiquetador a partir de um corpus previamente
anotado, mas isso é uma tarefa não trivial na medida em que se almeja um alto grau
de acurácia, pressupondo habilidades de programação além do nível de iniciante.
Este artigo descreve o Aelius, um pacote em Python que, recorrendo ao NLTK e
empregando algoritmos adicionais próprios, oferece a não-programadores uma
interface mais acessível para treinamento de etiquetadores de diferentes
arquiteturas e anotação de corpora em vários formatos, com um tratamento mais
eficiente das palavras com inicial maiúscula do que pelo NLTK sozinho. O pacote
inclui etiquetadores morfossintáticos que foram treinados no Corpus Histórico do
Português Tycho Brahe e alcançaram 95% de acurácia em textos literários que não
integram esse corpus, nos quais etiquetadores do português livremente disponíveis
apresentaram um desempenho inferior. O Aelius pode, então, contribuir em prover
usuários do NLTK de um modo geral, e a comunidade de lingüística de corpus em
particular, de uma variedade maior de materiais em língua portuguesa.

Palavras-chave: etiquetagem morfossintática, anotação de corpus, aprendizado de

máquina, NLTK, Python

Abstract:

Implemented in Python, a programming language distinguished by its pedagogical

qualities, the Natural Language Toolkit (NLTK) has the widest coverage and is the
user-friendliest open source library for automatic text analysis. NLTK, however,
presently lacks sufficient resources in Portuguese. As far as the Brazilian variety is
concerned, it only offers one POS tagged corpus, which is restricted to newspaper
texts. The library does provide tools for training a tagger from a previously annotated
corpus, but this is a non-trivial task inasmuch as a high tagging accuracy is strived
for, implying Python programming skills beyond the beginner's level. This paper
describes Aelius, a Python package which, drawing on the NLTK, and employing
some own algorithms, offers non-programmers a more accessible interface for
training taggers in different architectures and annotating corpora in various formats
with a more efficient handling of capitalized words than by NLTK alone. The package
includes POS taggers that were trained on the Tycho Brahe Parsed Corpus of
Historical Portuguese and attain 95% accuracy on 19th century literary texts that are
not covered by this corpus. It is shown that other freely available taggers for
Portuguese have a poorer performance on the same data. Aelius can therefore
contribute to providing NLTK users in general, and the corpus linguistics community
in particular, with a wider variety of Portuguese language materials.

Keywords: part-of-speech tagging, corpus annotation, machine learning, NLTK,

Python

1. Introdução

Este trabalho descreve aspectos do Aelius, pacote em Python que, utilizando

a biblioteca Natural Language Toolkit (NLTK) (Bird, Klein e Loper, 2009, 2011), torna
acessível a não programadores a construção, a partir de um corpus anotado, de
etiquetadores morfossintáticos de diversos tipos bem como a sua avaliação e
aplicação na anotação de corpora em diversos formatos. O Aelius não se limita a
oferecer uma interface simplificada para algumas dessas funcionalidades do NLTK,
mas o complementa de várias formas, com destaque para o aumento da eficácia da
etiquetagem morfossintática por meio da utilização de um algoritmo próprio para
lidar com palavras de inicial maiúscula. O pacote, a ser distribuído sob a mesma
licença livre do NLTK, inclui alguns etiquetadores do português em várias
arquiteturas, alguns dos quais apresentam acurácia superior a 95% em textos
literários históricos. Esse desempenho é equiparável aos relatados na literatura
para outros etiquetadores do português livremente disponíveis, alguns dos quais
apresentam índices de acurácia superiores, porém com conjuntos de etiquetas mais
simples aplicados a textos jornalísticos menos elaborados.
 A construção e a avaliação de etiquetadores bem como a anotação
morfossintática de corpora por meio do Aelius são exemplificadas no contexto de
sua aplicação, no âmbito do projeto CORPTEXLIT (Alencar, 2011), a textos de
literatura brasileira do século XIX e início do século XX ainda não contemplados pelo
Corpus Histórico do Português Tycho Brahe (CHPTB). Nesses textos, o Aelius teve
melhor desempenho que outras ferramentas de livre acesso.

O Aelius permite preencher, portanto, lacunas na lingüística de corpus do

português de orientação diacrônica, ao mesmo tempo em que contribui para sanar a
escassez de corpora e modelos do português no NLTK e acrescenta a essa
biblioteca algumas funções bastante úteis para o desenvolvimento de etiquetadores
mais eficazes e anotação de corpora de língua portuguesa.

O trabalho está estruturado da forma seguinte. Na próxima seção, delineamos

o cenário que permite avaliar a contribuição do presente trabalho para a lingüística
de corpus. Apresentamos as vantagens do NLTK para o processamento de corpora,
ressaltando, contudo, a escassez de recursos dessa biblioteca específicos para a
língua portuguesa. Enfatizamos a necessidade de integrar nessa biblioteca dados
representativos da heterogeneidade do português. Por outro lado, chamamos a
atenção para o fato de que a utilização não trivial do NLTK pressupõe a capacidade
de programar em Python.

A seção 3 trata do aspecto do processamento de corpora que constitui o

nosso foco: a etiquetagem morfossintática e morfológica automática. Inicialmente,
caracterizamos computacionalmente a classificação de palavras, que remonta à
antiguidade greco-latina, como problema de resolução da ambigüidade,
apresentando as principais abordagens de como resolvê-lo. Em seguida, resumimos
algumas abordagens mais recentes voltadas para o português.

A seção 4 apresenta, inicialmente, as principais técnicas de etiquetagem do

NLTK, mostrando como customizar os recursos dessa biblioteca para uma aplicação
específica. Em seguida, apresentam-se os resultados de estudos sobre a construção
de etiquetadores para várias línguas usando a biblioteca.

Na seção 5, expomos os objetivos do trabalho, que culminou no

desenvolvimento do Aelius. A metodologia e os resultados alcançados são expostos
nas subseções 6.1 e 6.2. A subseção 6.3 compara o desempenho do Aelius com o
de outras ferramentas livremente disponíveis.

Finalmente, na seção 7, apresentamos nossas conclusões.

2. Contextualização

Pela abrangência e qualidades didático-pedagógicas, o NLTK constitui o

principal projeto de software livre para a análise automática de textos da atualidade,
reunindo ferramentas para uma vasta gama de tarefas. A facilidade de uso por
iniciantes em programação deve-se tanto a Python quanto à ampla e acessível
documentação on-line, o que, aliado ao caráter multiplataforma e multiparadigma
dessa linguagem, reflete-se na ampla difusão da biblioteca em cursos de
processamento da linguagem natural, lingüística computacional e lingüística de
corpus.

Uma outra abrangente biblioteca de processamento da linguagem natural

(PLN), também implementada em software livre, e que dispõe de recursos para o
português, é a suite de analisadores lingüísticos FreeLing (Garcia e Gamallo, 2010;
Padró et al. 2010; FreeLing, 2011). Do ponto de vista de pesquisadores e estudantes
de Letras e Lingüística com pouco ou nenhum conhecimento de programação,
contudo, essa biblioteca, implementada em C++, tem a desvantagem de focar não o
usuário final de aplicativos de PLN, mas desenvolvedores dessas ferramentas.

A julgar pelas informações veiculadas em Bird, Klein e Loper (2011) e pelas

publicações mais recentes na área de lingüística de corpus no Brasil (por exemplo,
Tagnin e Vale, 2008), aparentemente a comunidade de pesquisadores da área,
entre nós, ainda não atentou como deveria para as facilidades proporcionadas pelo
NLTK para a codificação, anotação automática e exploração de corpora, embora o
projeto tenha iniciado há quase dez anos.1

Comparado a outros sistemas gratuitos especializados (nem todos de código

aberto ou multiplataforma) para a realização de algumas dessas tarefas, o NLTK
sobressai-se não só pela muito maior facilidade de uso, como também pela maior
quantidade de recursos e pela integração do processamento de corpora a outras
tarefas de processamento da linguagem natural.

O NLTK é também mais flexível porque o usuário com conhecimentos mesmo

básicos de programação pode facilmente desenvolver seus próprios programas em
Python, e, graças ao caráter “plugável” dessa linguagem (Chun, 2006), usá-los
concomitantemente ou em substituição a determinados recursos do NLTK.

Outro ponto forte do NLTK é a disponibilização de dados e modelos

(language models) de várias línguas, com os quais se podem experimentar as
diferentes ferramentas.

Usuários de língua portuguesa, porém, ainda estão longe de dispor da

mesma quantidade de recursos que o NLTK disponibiliza para o processamento do
inglês. De fato, no momento, a biblioteca não oferece etiquetadores pré-treinados
de língua portuguesa. Além disso, integram-na apenas dois corpora anotados do
português, o Mac-Morpho e o Floresta. 2 O primeiro, com mais de um milhão de
tokens anotados morfossintaticamente, tem a desvantagem de se restringir a textos
do jornal Folha de São Paulo do ano de 1994. O segundo, apesar de ter como
vantagem a anotação também sintática, por conter apenas 211852 tokens, é muito
pequeno para os padrões atuais. Esse corpus é também diacrônica, diatópica e
diafasicamente limitado, uma vez que inclui apenas textos de dois jornais, a saber o
brasileiro Folha de São Paulo e o português O Público.
 Acreditamos que, para uma mais ampla utilização do NLTK no Brasil,
especialmente nos cursos de Letras e Lingüística, é necessário, por um lado,
integrar a essa biblioteca mais corpora anotados que sejam representativos tanto
das diferentes regiões do país, quanto dos diferentes registros e estágios de
evolução da língua. Por outro lado, muitos recursos do NLTK exigem conhecimentos
de programação em Python que vão além do básico, tornando necessário o
desenvolvimento de interfaces ainda mais acessíveis para não programadores.

3. A etiquetagem morfossintática automática

3.1. O problema da ambigüidade e as principais propostas de solução

Ao gramático alexandrino Dionísio Thrax (século II a.C.) atribui-se a primeira

classificação das palavras em categorias, que, quase sem alterações, ingressaram,
por intermédio do gramático romano Aelius Donatus (século IV), na tradição escolar
ocidental como as oito partes orationis ‘partes do discurso’: nome, pronome, verbo,
advérbio, particípio, conjunção, preposição e interjeição (Jungen; Lohnstein, 2006, p.
42).3

O termo partes orationis forneceu a base para duas das mais centrais noções
da lingüística computacional: parts-of-speech ‘classes de palavras’, objeto da
etiquetagem morfossintática (POS tagging em inglês) e parsing (anglicização do
termo latino pars ‘parte’), a análise automática da sentença em constituintes
menores (sintagmas).

Computacionalmente, do ponto de vista do NLTK, a etiquetagem automática

consiste em atribuir a cada um dos tokens em que se segmentou uma sentença, i.e.
a cada cadeia de uma lista L, um elemento de um conjunto de etiquetas previamente
definido. O output desse procedimento é uma lista de tuplas (w,t), onde w representa
o token e t, a etiqueta (Figura 1).
Figura 1: Toquenizacão e etiquetagem de uma sentença do romance Luzia-Homem
em Python por meio do Aelius.

A etiquetagem acima contempla dois níveis de representação lingüística: o

nível morfossintático (a POS tagging propriamente dita, i.e. a atribuição dos tokens a
classes de palavras) e o nível morfológico (Feldman e Hana, 2010, p. 5), que
consiste na classificação de um token dentro do respectivo paradigma lexical, por
meio de suas propriedades morfológicas. Numa língua como a portuguesa, essas
propriedades são tipicamente expressas por meio de terminações. O CHPTB utiliza
um sistema de etiquetas do tipo estruturado e compacto (Feldman e Hana, 2010, p.
60), em que a etiqueta designativa da classe de palavra (por exemplo, N para
substantivo) é separada por um hífen da etiqueta que classifica um vocábulo no
paradigma de um determinado lexema (por exemplo P para plural no caso de
substantivos e adjetivos).4

Se não houvesse o fenômeno da ambigüidade, em que uma mesma cadeia

representa palavras de categorias diferentes, a etiquetagem seria um procedimento
relativamente trivial, dado um amplo dicionário que listasse todas as palavras e suas
respectivas categorias. No entanto, como o exemplo acima evidencia, mesmo
tomando como sistema de classificação um conjunto pequeno de etiquetas como as
oito partes orationis de Dionísio Thrax ou de Aelius Donatus, uma língua como a
portuguesa apresenta muitos e freqüentes casos de ambigüidade. O vocábulo a, por
exemplo, pode ser determinante feminino (etiqueta D-F) além de preposição (P) ou
pronome clítico (CL). Outra fonte de ambigüidade é a distinção entre particípio,
nome e adjetivo, devido, sobretudo, ao caráter produtivo da formação de novos
substantivos a partir de adjetivos e vice-versa ou de neologismos de ambas as
classes a partir de particípios. Essa dificuldade é aumentada no sistema de
anotação do CHPTB, que subdivide os particípios em VB-PP e VB-AN, distinção
inexistente em corpora como o Mac-Morpho.

Segundo Feldman e Hana (2010), conjuntos de etiquetas que refletem as

propriedades morfológicas dos tokens (como, por exemplo, o do CHPTB), quando
aplicados na etiquetagem de línguas flexionadas, tornam a tarefa especialmente
difícil, devido à extensão do conjunto de etiquetas 5 e ao problema da ambigüidade.
Entre as línguas mais difíceis de etiquetar do que o inglês, esses autores incluem,
por esses motivos, exatamente o português.

A ambigüidade compromete seriamente a eficácia de uma técnica de

etiquetagem que leve em conta apenas o dicionário (ou a estrutura da palavra, no
caso de palavras desconhecidas). Os estudos sobre a etiquetagem automática
demonstram que taxas bem maiores de sucesso só podem ser obtidas pela
exploração, em conjunto com as propriedades da própria palavra a ser etiquetada,
de fatores contextuais como, por exemplo, as etiquetas das n-1 palavras
precedentes (no caso da etiquetagem por meio de n-gramas) ou as etiquetas e
afixos de palavras precedentes (no caso de etiquetadores classificadores).

Segundo Lemnitzer e Zinsmeister (2006), os diferentes modelos de

etiquetadores automáticos podem ser classificados conforme a maneira como
resolvem o problema da ambigüidade. Eles distinguem as seguintes arquiteturas:

a) Etiquetadores simbólicos utilizam regras elaboradas manualmente.

b) Etiquetadores estocásticos extraem, tipicamente a partir de corpora de

treino previamente anotados, probabilidades lexicais (a etiqueta mais freqüente para
cada token) e probabilidades contextuais, i.e. “a etiqueta mais provável de um token
em um determinado contexto” (Lemnitzer e Zinsmeister, 2006, p.73), sob a forma de
uma seqüência de etiquetas e palavras precedentes ou subseqüentes.
 c) Etiquetadores híbridos, como, por exemplo, o modelo de Brill, procuram
extrair de corpora pré-anotados, probabilisticamente, regras simbólicas cuja
aplicação produza os melhores resultados na etiquetagem de um novo corpus.

Essa classificação está longe de ser exaustiva. Em primeiro lugar, os modelos

puramente estocásticos comportam várias subdivisões, segundo se baseiem em
abordagens que utilizam Modelos Ocultos de Markov (HMM) ou modelos de Entropia
Máxima (MaxEnt) (Jurafsky e Martin, 2009; Güngör, 2010; Feldman e Hana, 2010).
Por outro lado, no âmbito da vasta literatura sobre aprendizado de máquina
(machine learning), modelos alternativos às arquiteturas clássicas de etiquetagem
automática têm sido propostos, recorrendo a support vector machines, redes
neurais, algoritmos genéticos, transdutores de estados finitos, fuzzy set theory, entre
outras abordagens (Güngör, 2010; Feldman e Hana, 2010).

3.2. Aplicações recentes ao português

Kepler (2005) relata sobre o desenvolvimento de uma ferramenta,

implementada em C++ e disponível on-line sob licença livre, que constrói,
recorrendo a Cadeias de Markov de Tamanho Variável (VLMCs), um etiquetador
morfossintático a partir de um corpus de treino anotado. Ele compara os resultados
obtidos por essa abordagem aos de outra abordagem probabilística, baseada em
Cadeias Ocultas de Markov (HMMs). Utilizando 2/3 do CHPTB como treino e 1/3
como teste, ele relata uma acurácia de 95.77% para um etiquetador baseado em
VLMCs, contra 93.49% para outro que utiliza HMMs. No corpus Mac-Morpho,
contudo, a acurácia do primeiro tipo de etiquetador caiu para 93.20%.

Gamallo (2005) disponibiliza um TreeTagger pré-treinado para o português,

que pode ser tanto utilizado on-line quanto instalado no computador do usuário. Não
se informam índices de acurácia da etiquetagem, que utiliza apenas 11 etiquetas
simples de POS, algumas das quais se combinam (como PREP+DET para
combinação de preposição e artigo), sem informação morfológica adicional.
 Milidiú, Santos e Duarte (2008) comparam a eficácia de diferentes estratégias
de aprendizagem mecânica na etiquetagem morfossintática, utilizando o corpus
Mac-Morpho e o CHPTB. Eles obtêm os índices mais altos de acurácia com a
estratégia Entropy Guided Transformation Learning (ETL), que atinge, nos dois
corpora, 96.75% e 96.64%, respectivamente.

Domingues, Favero e Medeiros (2008), almejando alcançar um índice de

acurácia de 99%, adotam uma estratégia híbrida, construindo vários etiquetadores
que combinam a etiquetagem probabilística à realizada por meio de regras. O
corpus utilizado foi o Bosque CF 7.4, que compreende 80.078 palavras extraídas do
jornal Folha de São Paulo. O corpus foi dividido em 20 subconjuntos, sendo
destinados 95% para treino e 5% para teste. Com um conjunto de 152 etiquetas, os
autores relatam ter alcançado, após 20 repetições do procedimento de avaliação,
uma acurácia média de 99.72%, obtida pela combinação do TreeTagger com regras
produzidas pelo mTBL.

Contier, Padovani e José Neto (2010) descrevem o Linguístico, um

reconhecedor gramatical implementado em Python que utiliza Tecnologia
Adaptativa. Um dos módulos desse software, o Identificador Morfológico, atribui,
recorrendo ao corpus Bosque "como biblioteca de apoio" (p. 39), uma etiqueta de
POS, de um conjunto de 21 etiquetas, ao output do módulo Toquenizador,
fornecendo o input para o Agrupador, responsável pela "montagem" dos sintagmas.
Não são fornecidas informações sobre a avaliação da ferramenta. Eles se limitam a
exemplificar a aplicação do programa na análise de uma única sentença de 32
palavras.

Garcia e Gamallo (2010) descrevem aspectos da adaptação, para o

português europeu e o galego, de vários módulos da suíte FreeLing, focando os
componentes envolvidos na análise morfossintática. Motivam-nos lacuna na área de
processamento automático dessas variedades, que, segundo eles, carece de
ferramentas de etiquetagem de POS com licença livre. Objetivando alcançar o
estado da arte de 97% de acurácia, eles adotaram uma abordagem puramente
probabilística, utilizando Modelos Ocultos de Markov (HMM).

Para Garcia e Gamallo (2010), a acurácia de um etiquetador não depende só

do corpus de treino, mas também do conjunto de etiquetas utilizado, cuja
complexidade reflete-se de forma inversamente proporcional na precisão da
etiquetagem. Por outro lado, eles ressaltam que um conjunto de etiquetas mais
complexo é mais informativo. Desse modo, utilizam, para o português europeu, um
conjunto com 255 etiquetas. Como corpus de desenvolvimento, eles recorreram a
uma adaptação, ao formato de etiquetagem do FreeLing, da parte lusitana do
Bosque 8.0, que perfaz cerca de 140000 tokens. Separando 90000 tokens para
treino e o restante para teste e recorrendo ao procedimento de quíntupla validação
cruzada, eles alcançaram uma acurácia de 94.324% para o conjunto de etiquetas
completo e 95.537% para um conjunto simplificado com apenas 28 elementos.
Esses resultados referem-se à avaliação pelo método que denominam OnlyTag, em
que se contabilizam tantos os acertos quanto os erros dos elementos individuais de
itens multipalavras. Pelos métodos NoTok, Tok e NoLoc, que utilizaram apenas
10000 tokens para teste, o máximo alcançado para o conjunto de etiquetas completo
foi 95.044% e para o simplificado, 96.263%.

Lácio-Web (s.d.) disponibiliza on-line, gratuitamente, três etiquetadores do

português, que etiquetam, conforme o sistema de anotação do corpus Mac-Morpho,
os textos enviados pelos usuários. Os etiquetadores foram treinados em textos do
jornal Folha de São Paulo e tiveram seu o desempenho avaliado em textos de
diversas seções desse jornal. O melhor desempenho é atribuído ao etiquetador
MXPOST, que, utilizando o modelo probabilístico de Entropia Máxima (ME), atinge
96.98% no caderno Agrofolha, "bastante padronizado e com vocabulário restrito".
Esse índice cai para 94.39% no caderno MAIS!, devido à natureza mais literária e ao
vocabulário mais diversificado dos textos. O segundo melhor etiquetador é o
TreeTagger, que obtém, nos referidos cadernos, respectivamente 92.80% e 95.56%.
 Feldman e Hana (2010) desenvolvem e aplicam ao português uma nova
proposta de etiquetagem, que consiste em adaptar algoritmicamente etiquetadores
de uma língua-fonte, rica em recursos para o processamento computacional, a uma
língua-alvo de estrutura parecida, mas que dispõe de menos recursos. Empregando
vários métodos de transferência de conhecimentos morfossintáticos do espanhol
para o português, eles alcançaram o máximo de 83.8% de acurácia.

O LX-Center do NLX-Grupo de Fala e Linguagem Natural da Universidade de

Lisboa disponibiliza várias ferramentas de processamento do português, incluindo o
LX-Tagger, um etiquetador morfossintático treinado com o MXPOST em 600000
tokens anotados manualmente (NLX-Grupo [s.d.], Silva e Branco 2004), do qual se
relata acurácia de 96.24%, por décupla validação cruzada. Esse sistema utiliza um
conjunto de 58 etiquetas de POS que se combinam com traços morfológicos.

4. Etiquetagem morfossintática no NLTK

4.1. Arquiteturas

O NLTK oferece implementações de algumas das principais técnicas de

etiquetagem automática, num leque que compreende desde modelos relativamente
simples baseados em n-gramas, afixos ou expressões regulares a abordagens mais
complexas como Brill, HMM, TnT etc.

Seguindo o paradigma da Programação Orientada a Objetos, o NLTK modela

diferentes arquiteturas de etiquetagem automática em classes que se estruturam
numa complexa rede de relações de herança. Esta estratégia de programação é
bastante interessante para os programadores que queiram criar versões
customizadas das classes do NLTK ou elaborar classes completamente novas que
utilizem métodos de classes do NLTK. Para tanto, basta estabelecer (possivelmente
múltiplas) relações de herança entre a classe criada e as classes do NLTK, como
sugere Perkins (2010). A nova classe pode ter atributos e métodos novos além dos
herdados ou atributos e métodos que suplantam os da classe-mãe.
 Outra possibilidade de customização do NLTK é simplesmente criar módulos
com funções que recebem os argumentos necessários para instanciar as diferentes
classes do NLTK ou realizam determinadas computações que produzem esses
argumentos.

Vejamos um exemplo trivial de cada uma dessas duas estratégias, utilizando

as duas classes mais básicas de etiquetadores do NLTK: o DefaultTagger e o
UnigramTagger. Para tanto, abrimos uma sessão do IDLE, uma interface amigável
para o interpretador de Python (Figura 2).

Figura 2: Construção de uma nova classe de etiquetadores.

Na Figura 2, primeiramente criamos um minicorpus de treino. Em seguida,

construímos uma subclasse BackoffUnigramTagger da classe UnigramTagger.
Diferentemente da última classe, uma instanciação da primeira inclui um
DefaultTagger que atribui a etiqueta N a toda palavra desconhecida. Essa subclasse
explora uma das técnicas mais interessantes do NLTK para construção de
etiquetadores: o procedimento de backoff, pelo qual um etiquetador recorre a outro
quando o seu método de etiquetagem não retorna nenhuma etiqueta para um
determinado token. No NLTK, podemos combinar etiquetadores em cadeias da
forma [t1, t2,...,tn], em que tn faz backoff para tn-1, este para tn-2 e assim por diante.
Criada a classe, construímos uma instância e verificamos que compartilha métodos
e atributos da classe-mãe, como o método tag, aplicado na etiquetagem de uma
sentença.

A Figura 3 exemplifica a segunda estratégia de customização do NLTK.

Primeiro criamos uma função que toma como argumento um corpus de treino e
retorna um objeto da classe UnigramTagger com backoff para o mesmo
DefaultTagger do exemplo anterior. A aplicação dessa função ao mesmo corpus de
treino da Figura 2 produz etiquetador com características semelhantes às do
anterior.

Figura 3: Construção de um etiquetador por meio de uma função e comparação

entre etiquetadores.

Este segundo etiquetador comete o mesmo erro que o anterior, etiquetando o

artigo a como preposição. De fato, podemos constatar que a função acima cria
instância de UnigramTagger com o mesmo modelo contextual que o objeto que
criamos da classe BackoffUnigramTagger. A acurácia, consequentemente, é a
mesma, uma vez que ambos recorrem ao mesmo DefaultTagger para etiquetar as
palavras desconhecidas.

No NLTK, o DefaultTagger e o UnigramTagger são dois tipos de

etiquetadores seqüenciais, que se caracterizam pela etiquetagem de um token por
vez. A segunda classe é uma subclasse de NgramTagger, que, por sua vez, é uma
subclasse da classe abstrata ContextTagger. Essa última classe possui um método
context(tokens,i,history) que, dada uma lista de tokens, o índice do token a ser
etiquetado e a lista de etiquetas previamente atribuídas, retorna o contexto desse
token. Esse contexto é utilizado, então, para extrair de uma tabela, construída
manual ou automaticamente (a partir de corpus de treino), a etiqueta do token na
posição i. No caso dos NgramTaggers, esse contexto é constituído pelo token e as
n-1 etiquetas precedentes, onde n é a ordem do n-grama. Por exemplo, num
TrigramTagger, o contexto de poupam na sentença-treino da Figura 2 é a tupla
("NEG","CL","poupam").6

A Figura 4 mostra como treinar um BigramTagger, i.e. um NgramTagger com

n=2, em algumas sentenças (ligeiramente adaptadas) de Luzia-Homem, que
convertemos no formato apropriado para treino de um UnigramTagger com backoff
para um DefaultTagger. Em seguida, examinamos a tabela de contextos desse
etiquetador.
Figura 4: Construção de um BigramTagger no NLTK.

No corpus de treino, há exatamente duas ocorrências de a/D-F, a/CL e a/P.

Como a freqüência é a mesma para cada um desses três casos, o algoritmo do
NLTK só pode incluir um deles no dicionário que modela a tabela de contextos, pois
um dicionário de Python não pode ter duas chaves idênticas. 7 De forma não
surpreendente, esse etiquetador erra a etiquetagem da primeira e da última
ocorrência de a na sentença-teste, como podemos ver na Figura 4. A palavra
menina, embora não conste da tabela de contextos, é corretamente etiquetada
graças ao DefaultTagger.

Em seguida, construímos um BigramTagger utilizando o UnigramTagger

como backoff e o aplicamos na mesma sentença-teste. Para entender por que o
primeiro erro na etiquetagem do token a foi corrigido, ao contrário do segundo erro,
verificamos a tabela de contextos e aplicamos o método context(tokens,i, history).
Pela tabela, o token a, no início de sentença, recebe a etiqueta D-F. Precedido de
verbo no presente (VP-P), recebe a etiqueta P. Na sentença em questão, porém, o
token a é precedido de verbo no pretérito-mais-que-perfeito (VB-RA). Não há na
tabela de bigramas o contexto (('VB-RA',), 'a'). Dessa forma, o BigramTagger recorre
ao seu etiquetador backoff, que é o UnigramTagger, o qual, como vimos, atribui
sempre a etiqueta CL ao token ª

Esse erro deixa de ocorrer quando eliminamos a distinção entre VP-RA e VP-
P, o que pode ser facilmente verificado reexecutando os comandos apropriados
acima com as modificações necessárias. Esse exemplo evidencia que uma maior
granularidade das distinções modeladas pelo conjunto de etiquetas pode levar a
uma menor acurácia desse tipo de arquitetura de etiquetadores baseados em n-
gramas. Para compensar a maior granularidade, é necessário aumentar
significativamente o corpus de treino. 8

Uma variante do UnigramTagger é o AffixTagger, em cujo modelo contextual

não são armazenados pares do tipo 'passara': 'VB-RA' (i.e. palavra e etiqueta), mas
do tipo ‘ara': 'VB-RA' (afixo e etiqueta). Uma outra variante é o RegexTagger, com a
diferença de que um etiquetador desse tipo não é construído a partir de um modelo
contextual, mas de uma lista de tuplas do tipo (r"\w+[aei]ra","VB-RA"), onde o
primeiro elemento é uma expressão regular e o segundo, uma etiqueta. Essa lista
não é depreendida de um corpus, mas deve ser construída manualmente.
Diferentemente dos NgramTaggers e do AffixTagger, portanto, que são abordagens
estocásticas, o RegexpTagger se insere no paradigma simbólico.

A última classe de etiquetadores da família de etiquetadores seqüenciais do

NLTK é o ClassifierBasedTagger, que tem como subclasse o
ClassifierBasedPOSTagger. Esse tipo de etiquetador caracteriza-se por tratar a
etiquetagem como problema de classificação (Bird, Klein e Loper, 2009, p. 221).
Dado um conjunto de rótulos (labels) e um conjunto de propriedades ou traços
(features) de um objeto, um classificador procura atribuir o rótulo mais provável a
esse objeto.

O ClassifierBasedPOSTagger é uma versão customizada, pronta para uso, da

classe ClassifierBasedTagger, em que o único parâmetro a ser fornecido pelo
usuário, para a instanciação da classe, é o corpus de treino. Esse etiquetador
classificador recorre, conjuntamente, ao mesmo tipo de informações sobre o token a
ser etiquetado e/ou o seu contexto utilizadas pelo NgramTagger, AffixTagger e
RegexpTagger, com a diferença de que essas informações são modeladas em
termos de conjuntos de traços (feature sets). Esses conjuntos de traços alimentam
um classificador ingênuo de Bayes, que constrói um modelo dos traços de maior
probabilidade, usado para determinar a etiqueta de cada token individualmente.

A Figura 5 mostra que um ClassifierBasedPOSTagger treinado com o mesmo

conjunto de sentenças anotadas que o BigramTagger acima tem a mesma acurácia
em relação ao padrão-ouro, mas comete erro oposto. Em vez de um falso clítico,
esse etiquetador produz uma falsa preposição. Os demais comandos do exemplo
mostram o funcionamento desse tipo de etiquetador. Observe a altíssima
probabilidade da etiqueta D-F para um token a no início da sentença.
Figura 5: Construção de um ClassifierBasedPOSTagger no NLTK.

Além da família dos etiquetadores seqüenciais, o NLTK inclui a classe

FastBrillTaggerTrainer, implementação do conhecido algoritmo de aprendizagem
baseada em transformações inicialmente proposto por Brill. 9 Para instanciação da
classe FastBrillTaggerTrainer, um outro etiquetador do NLTK deve ser fornecido
como parâmetro. Esse etiquetador realiza a etiquetagem inicial do corpus de treino
que constitui a base para a aprendizagem das regras de etiquetagem mais eficazes.

Outras implementações de abordagens estocásticas bastantes conhecidas

são o HiddenMarkovModelTrainer e o TnT. O primeiro tipo distingue-se dos
etiquetadores seqüenciais pela etiquetagem não de tokens individualmente, mas de
seqüências de tokens. O último é uma implementação do etiquetador estatístico de
Brants (2000), baseado em modelos de Markov de segunda ordem.

Finalmente, o NLTK disponibiliza interfaces em Python para dois

etiquetadores externos, implementados noutras linguagens: o Hunpos e Stanford
POS-Tagger.

4.2. Desempenho em línguas diversas de etiquetadores construídos por meio

do NLTK
 Hasan, Uzzaman e Khan (2006) constroem, com base no NLTK, vários tipos
de etiquetadores para o inglês e para o bengali, uma das principais línguas do
Sudeste asiático. No caso do inglês, eles obtiveram um índice de acurácia de 90.3%
com um etiquetador baseado em HMM, treinado em pouco mais de um milhão de
tokens extraídos do Corpus Brown e aplicado em 1000 tokens. Um etiquetador de
Brill treinado em 400017 tokens obteve, na etiquetagem de 1000 tokens, apenas
88.5% de acurácia, contra 89.7% de um etiquetador baseado em HMM construído e
testado nas mesmas condições. A Tabela 1 resume os dados mais relevantes sobre
a etiquetagem do bengali, obtidos pela aplicação em 1000 tokens de etiquetadores
treinados em 4484 tokens. Ressalte-se, por outro lado, o efeito da redução do
conjunto de etiquetadas sobre o desempenho de todas as três abordagens
comparadas. Apesar do número pequeno de tokens do corpus de treinamento,
esses dados sugerem que a abordagem de Brill é mais adequada para essa língua.
Esse resultado é confirmado em outro estudo com um corpus de desenvolvimento
seis vezes maior, envolvendo também as línguas hindi e telegu, em que o modelo de
Brill alcança acurácia de cerca de 70% para o hindi e o bengali (Hasan, Uzzaman e
Khan, 2007).

Quantidade de HMM Unigramas Brill

etiquetas
12 45.6 71.2 71.3
41 46.9 42.2 54.9

Tabela 1: Desempenho de três técnicas de etiquetagem automática em bengali

conforme Hasan, Uzzaman e Khan (2006).

Bird, Klein e Loper (2009) realizam diversos experimentos de construção de

etiquetadores morfossintáticos do inglês com base nos textos da categoria “notícias”
do corpus Brown, que totalizam 4623 sentenças, perfazendo 100554 tokens
anotados, alcançando 84.72% com a a cadeia de backoff [DefaultTagger(‘NN’),
UnigramTagger, BigramTagger].

Graças à técnica do backoff e à possibilidade de usar qualquer etiquetador

como etiquetador inicial de um FastBrillTaggerTrainer, o NLTK oferece uma gama
praticamente ilimitada de combinações de etiquetadores. Essas combinações
podem apresentar variações extremas de acurácia, tempo de treinamento ou de
etiquetagem e espaço ocupado em disco. Encontrar a combinação de melhor
desempenho na etiquetagem de um determinado corpus de uma dada língua,
levando em conta as necessidades de uma determinada aplicação em termos de
rapidez ou memória, constitui um desafio não trivial ao qual nos lançamos mais
adiante.

Perkins (2008) testa a acurácia de várias combinações de etiquetadores do

NLTK, verificando, também, o tempo que consomem e a quantidade de espaço que
demandam. Inicialmente, ele compara os índices de acurácia alcançados em
extratos de três corpora do NLTK por cada uma das 6 combinações logicamente
possíveis de NgramTaggers para 1 <= n <= 3. Nesse experimento, a acurácia
máxima foi alcançada por um etiquetador que denomina UTB em razão da cadeia de
backoff [UnigramTagger, BigramTagger, TrigramTagger] subjacente. Esse
etiquetador obteve um índice em torno de 83% de acertos na etiquetagem do
conjunto de teste, que perfez 50% do fragmento de 8000 sentenças extraído do
corpus CONLL2000.10

Num segundo experimento com os mesmos conjuntos de treino e de teste,

Perkins construiu, inicialmente, um AffixTagger e o inseriu em várias posições na
cadeia [UnigramTagger, BigramTagger, TrigramTagger]. A maior acurácia que relata
foi obtida com a cadeia [AffixTagger, UnigramTagger, BigramTagger,
TrigramTagger], em etiquetador denominado AUBT. Em seguida, ele verificou a
acurácia de dois etiquetadores com um RegexpTagger inserido, respectivamente, no
início e no final dessa cadeia, obtendo os melhores resultados com a seqüência
[RegexpTagger, AffixTagger, UnigramTagger, BigramTagger, TrigramTagger] em
etiquetador nomeado RAUBT, que atingiu perto de 90% de acurácia no conjunto de
teste do CONLL2000.

Num terceiro experimento, Perkins construiu um FastBrillTaggerTrainer dando

o último etiquetador RAUBT acima como etiquetador inicial, obtendo, relativamente a
esse etiquetador, um incremento de acurácia em torno de 5%. Embora o etiquetador
de Brill (designado BRAUBT) seja mais preciso, Perkins chama a atenção para o
tempo maior que consome no treinamento, sobretudo quando é configurado para
usar um número muito grande de regras.

Finalmente, Perkins constrói um ClassifierBasedPOSTagger (CPOS) e

compara seu desempenho ao de um FastBrillTaggerTrainer que o tem como
etiquetador inicial (denominado BCPOS), relatando um ligeiro ganho (entre 1% e
2%) na acurácia deste último em relação ao primeiro em dois dos corpora
investigados.

Perkins conclui que os etiquetadores classificadores são ligeiramente mais

precisos que o BRAUPT, mas ressalta que essa vantagem pode não compensar
devido aos tempos significativamente maiores que consomem tanto no treino quanto
na etiquetagem. A etiquetagem pelo BRAUPT, que ocupa apenas 273 KB, é mais de
246 vezes mais rápida do que pelo CPOS, que ocupa 13 vezes mais espaço.

Perkins (2010) retoma a comparação entre diferentes arquiteturas de

etiquetadores do NLTK, agora usando um conjunto de treino de 3000 sentenças e
um conjunto de teste de 914 sentenças do corpus Treebank. Destacamos,
inicialmente, a acurácia de 35.92% de um etiquetador que combina, numa cadeia de
backoff, 4 AffixTaggers, que se diferenciam pela extensão do afixo e pelo tipo
(prefixo ou sufixo). Esse etiquetador é 12% mais preciso do que um AffixTagger
treinado apenas com sufixos de três letras. Segundo o autor, a combinação que
obteve esse resultado “não é a melhor nem a pior” (Perkins, 2010, p. 97), sugerindo
que melhores resultados podem ser obtidos só pelo reordenamento desses
etiquetadores na cadeia.

Com a cadeia [DefaultTagger('NN'), UnigramTagger, BigramTagger,

TrigramTagger], Perkins obtém 88.16% de acurácia. Sobre esse valor, usando esse
etiquetador como o inicial de um FastBrillTaggerTrainer, ele obtém um acréscimo de
apenas 0.16%, bem menos do que alcança com um TnT, que atingiu 89.27% com
DefaultTagger(‘NN’) para palavras desconhecidas. Ele deixa entrever que melhores
resultados podem ser obtidos substituindo esse DefaultTagger por um
RegexpTagger ou um AffixTagger.

O maior índice de acurácia, 93.11%, Perkins obtém com um

ClassifierBasedPOSTagger que recorre (por backoff) a um DefaultTagger(‘NN’)
quando a probabilidade de uma etiqueta for menor que 30%. Um outro etiquetador
usando um classificador de Entropia Máxima (classe MaxentClassifier) obteve
apenas 93.09%.

Sobre o etiquetador TnT e os classificadores, Perkins observa que o primeiro

consume pouco tempo para ser treinado, mas é de aplicação muito lenta, ao passo
que os últimos consomem muito tempo tanto no treino quanto na etiquetagem (e o
MaxentClassifier leva ainda mais tempo para treinar que o NaiveBayesClassifier).

5. Objetivos

Inicialmente, visamos a aproximar da lingüística computacional, valendo-se

da amigabilidade do NLTK, a comunidade brasileira de Letras e Lingüística. Isso
pressupõe a disponibilização de interfaces ainda mais acessíveis a iniciantes em
Python, modelos da língua (como listas de n-gramas), etiquetadores e mais corpora
anotados representativos da diversidade do português.

Por outro lado, a lingüística histórica do português, apesar da cobertura do

CHPTB para o período de 1500 a 1800, ainda não dispõe, para a variedade
brasileira, de uma quantidade suficiente de textos morfossintaticamente anotados
representativos da língua do século XIX.

Com este trabalho, pretendemos contribuir para preencher essas lacunas.

Para tanto, desenvolvemos o Aelius, pacote em Python que, recorrendo não apenas
ao NLTK, mas a algoritmos próprios, complementa essa biblioteca de várias formas,
na execução das seguintes tarefas:
 (i) Construção e avaliação de etiquetadores de diversas arquiteturas a
partir de corpora anotados

(ii) Aplicação de um etiquetador na anotação de um corpus em diversos

formatos, inclusive em xml num formato compatível com as especificações da TEI 5

O impulso inicial para construção do Aelius foi dado pela necessidade de

dispor de etiquetadores morfossintáticos de alta acurácia e grande informatividade
na etiquetagem, capazes de anotar textos literários brasileiros, de gêneros diversos,
do século XIX e início do século XX. A escolha, para os etiquetadores pré-treinados
a serem distribuídos juntamente com os módulos em Python que constituem o
pacote Aelius, do complexo conjunto de etiquetas do CHPTB foi determinada pelo
intuito de não só produzir uma etiquetagem altamente informativa, mas também de
permitir que textos anotados pelo Aelius possam ser comparados, em estudos
diacrônicos, com os textos do CHPTB.

Objetivamos um índice inicial de 95% na anotação de textos dos gêneros

narrativa e ensaio do referido período, pois isso já permite simplificar imensamente a
revisão humana, base, por sua vez, para versões mais robustas dos diferentes
etiquetadores do pacote (Naumann, 2004; Ule e Hinrichs, 2004; Domingues, Favero
e Medeiros, 2008), de modo a que se possa atingir o estado da arte de 96% - 97%
(Güngör, 2010, p. 207).

Não obstante essa motivação na lingüística histórica, pretendemos que

alguns desses etiquetadores possam ser utilizados também na anotação
morfossintática de textos do português brasileiro contemporâneo.

6. O pacote Aelius

6.1. Aspectos metodológicos da construção de etiquetadores de alta acurácia

para o português usando o NLTK
 Em 4.2, fizemos um levantamento de experimentos com o NLTK na
etiquetagem no inglês e de línguas do Sudeste asiático. Os etiquetadores referidos,
porém, não passam de protótipos, seja pela baixa acurácia alcançada em relação ao
estado da arte de 96% – 97%, seja pela limitação do conjunto de etiquetas, seja pelo
caráter restrito do conjunto de teste.

Dado o nosso objetivo de construir, por meio do NLTK, a partir do CHPTB, um

etiquetador de ampla cobertura (tanto pela diversidade dos textos quanto pela
complexidade do conjunto de etiquetas) e alta acurácia para a anotação
morfossintática de textos literários do português do século XIX e início do século XX,
as seguintes alternativas se ofereciam inicialmente, pelo que se expôs da literatura:

a) pela rapidez e pouco espaço ocupado em disco, uma combinação de

NgramTaggers, RegexpTagger e AffixTaggers

b) um etiquetador de Brill tendo esse etiquetador como inicial

c) um TnT

d) pela acurácia e facilidade de construção, um ClassifierBasedPOSTagger

ou um etiquetador HMM

As opções a) e b), apesar de econômicas, têm uma série de desvantagens.

Primeiro, é necessário muita experimentação para formular as expressões regulares
mais diagnósticas e descobrir o seu ordenamento ótimo, face à complexidade do
conjunto de etiquetas do CHPTB. Segundo, há a dificuldade de descobrir a
configuração ideal dos AffixTaggers em termos de extensão de palavras e afixos e
qual cadeia de backoff é mais eficaz. A opção c) implica descobrir qual o etiquetador
ideal para palavras desconhecidas, herdando, portanto, os problemas da opção a). A
opção c) tem também a desvantagem da relação custo-benefício desfavorável,
desvantagem compartilhada pelo ClassifierBasedPOSTagger.
 De todas as opções acima, a mais promissora parecia ser, então, construir
um HMM e verificar se atingia o nível mínimo de 95% de acurácia que nos
propusemos alcançar e apresentava uma relação custo-benefício favorável em
termos de recursos exigidos do computador.

Para verificar se essa arquitetura atendia aos nossos objetivos, preparamos,

inicialmente, uma versão do CHPTB sem as etiquetas xml nem palavras
estrangeiras. Entre outras intervenções, corrigimos também alguns erros de
ortografia e inconsistências na anotação.

A partir da versão modificada do CHPTB, a qual doravante designamos como

CHPTB-M, compilamos uma lista de todas as sentenças e dividimo-la em 1000
blocos que embaralhamos aleatoriamente (Jurafsky e Martin, 2009, p. 126). Em
seguida, construímos etiquetadores de várias arquiteturas utilizando diferentes
extratos do CHPTB-M e comparamos as suas vantagens e desvantagens.

A Tabela 2 traz a quantidade de sentenças e tokens de cada um desses

extratos. Cada extrato constitui um conjunto de desenvolvimento, do qual se
separaram 75% como conjunto de treino e o restante como conjunto de teste de
desenvolvimento (Bird, Klein e Loper, 2009, p. 226; Jurafsky e Martin, 2009, p. 187).

Proporção Conjunto de treino Conjunto de teste

sentenças tokens sentenças tokens
do
CHPTB-M

10% 5035 114077 1679 36549

30% 15106 324634 5036 107470
50% 25177 545749 8393 176366
70% 35248 761125 11750 229712
100% 50355 1066932 16786 364543

Tabela 2: Quantidade de sentenças e tokens dos conjuntos de treino e de teste de

diferentes extratos do CHPTB-M.
 Como vimos, apenas uma pequena parte dos textos morfossintaticamente
anotados do CHPTB, que abrange principalmente obras de autores nascidos antes
de 1850, refere-se ao português do Brasil do século XIX. Sendo nosso objetivo a
construção de etiquetadores para anotar textos do período de 1840 a 1910,
construímos um outro conjunto de teste de desenvolvimento (doravante DEV-TEST-
SET) a partir dos oito primeiros capítulos do romance Luzia- Homem (1903), de
Domingos Olímpio (1850-1906). A análise dos erros cometidos por etiquetadores de
diferentes arquiteturas na anotação desse conjunto também foi levada em conta na
construção de versões mais robustas.

Capítulos Parágrafos Sentenças Tokens

1-8 371 944 17931

Tabela 3: DEV-TEST-SET compilado a partir do romance Luzia-Homem.

Finalmente, para verificar em que medida os índices de acurácia obtidos por

esses etiquetadores em Luzia-Homem se transferiam para a anotação de outras
obras do período que focamos, construímos o conjunto de teste (doravante TEST-
SET) da Tabela 4, com relação ao qual testamos a eficácia das versões finais dos
etiquetadores.

Nome do Nasciment Obra Data de Quantidade

autor o
publicação de tokens
Joaquim 1820 A Moreninha 1844 624
Manoel de
Macedo

Álvares de 1831 Bertran (de A Noite 1855 547

Azevedo na Taverna)

Joaquim 1849 Minha Formação 1900 697

Nabuco

Coelho Neto 1864 Firmo, o Vaqueiro 1896 607

(de Sertão)

Euclides da 1866 Anchieta (de 1907 532

Cunha Contrastes e
 Confrontos)

Afonso 1868 Assombramento (de 1898 573

Arinos Pelo Sertão)

Lima Barreto 1881 Recordações do 1909 493

Escrivão Isaías
Caminha

Tabela 4: TEST-SET constituído de excertos de obras literárias publicadas entre

1844 e 1909.

A Tabela 5 traz os resultados dos experimentos realizados com a arquitetura

HMM. O índice de acurácia alcançado pela versão mais robusta do etiquetador é
respeitável, sobretudo quando não demanda muito esforço da parte do lingüista-
programador. O espaço ocupado em disco, porém, torna essa arquitetura
completamente inadequada para uso em dispositivos de computação móveis de
baixo custo.

Proporção Tempo de Tempo de Acurácia Tamanho

treino teste (em MB)
10% 56 177 90.78 43.9
30% 565 732 92.63 95.9
50% 1470 1479 93.28 145.1
70% 2598 2178 93.81 183.4
100% 4695 4153 94.26 234.4

Tabela 5: Comparação entre vários etiquetadores HMM treinados em diferentes

fatias do CHPTB-M com o parâmetro estimator=WittenBellProbDist.11

A Tabela 6 traz os valores dos experimentos realizados com a arquitetura

RUBT, na terminologia de Perkins (2008). O RegexpTagger, que ocupa o início da
cadeia de backoff, foi compilado a partir de expressões regulares que formulamos
com base nos afixos do português que nos pareceram mais diagnósticos. Como se
pode constatar comparando a Tabela 5 com a Tabela 6, a versão mais robusta do
RUBT é só 0.03% menos precisa que a versão mais potente do HMM, mas, em
compensação, é extremamente mais rápida, uma vez que consome menos de 12
minutos para treinar e testar, contra as quase duas horas e meia que leva o HMM
correspondente. A maior vantagem do RUBT, porém, é o pouco espaço ocupado na
memória. Uma versão treinada em 100% das sentenças do CHPTB-M ocupa apenas
1.7 MB, contra 240 MB de versão análoga na arquitetura HMM.

Proporção Tempo de Tempo de Acurácia

treino teste
10% 39 3 92.39
30% 105 20 93.47
50% 177 69 93.65
70% 244 150 93.91
100% 340 359 94.23

Tabela 6: Comparação entre vários etiquetadores RUBT treinados em diferentes

fatias do CHPTB-M.

Na Tabela 7 resumimos os resultados dos experimentos com a construção de

ClassifierBasedPOSTaggers, onde podemos verificar que esse tipo de arquitetura
consome pouco tempo no treinamento, mas oferece a pior relação custo-benefício
no que tange à aplicação dos etiquetadores na anotação de textos. A lentidão
desses etiquetadores já havia sido ressaltada por Perkins (2008, 2010). O que
surpreende nessa tabela, quando a compramos com os resultados dos
experimentos desse autor, é a acurácia inferior dos nossos etiquetadores
classificadores à obtida pela arquitetura RUBT (Tabela 6). Cremos que o alto grau
de complexidade do conjunto de etiquetas que utilizamos, aliado ao maior grau de
elaboração da linguagem literária, pode ser o fator responsável por essa
discrepância.
Proporção Tempo de Tempo de Acurácia
treino teste
10% 13 513 89.96
30% 57 1710 91.26
50% 68 3081 91.95
70% 98 4255 92.15
100% 396 7305 92.57

Tabela 7: Comparação entre vários ClassifierBasedPOSTaggers treinados em

diferentes fatias do CHPTB-M.

Na avaliação dos diferentes etiquetadores desta seção, não recorremos ao

procedimento de múltipla validação cruzada, comumente utilizado nesse tipo de
experimento, porque nosso interesse maior não era aferir o desempenho dos
etiquetadores no CHPTB-M, mas no DEV-TEST-SET e no TEST-SET. Cremos que
esse procedimento só se faz imprescindível quando não se dispõe de um corpus
suficientemente vasto para treinamento nem de um conjunto de teste independente
desse corpus (cf. Jurafsky e Martin, 2009, p. 188-189). 12

Na próxima seção, em que explicamos aspectos do funcionamento do Aelius,

mostramos como etiquetar automaticamente textos literários brasileiros
novecentistas com índice médio de acurácia de 95%.

6.2. Aspectos do funcionamento do Aelius

A construção de etiquetadores como os da seção anterior é facilitada

enormemente pelo NLTK. Mesmo assim, são necessários conhecimentos de
programação em Python pelo menos de nível intermediário. Para quem trabalha com
a língua portuguesa, em comparação com uma língua como a inglesa, a tarefa de
compilar um etiquetador e avaliá-lo ou utilizá-lo na anotação de um texto torna-se
mais complicada pela necessidade de codificar, numa determinada codificação do
Unicode (no caso do CHPTB, utf-8), tanto as sentenças do conjunto de treinamento
quanto as do conjunto de teste bem como o output do etiquetador a ser salvo em
arquivo. Isso o NLTK não faz pelo usuário. Do mesmo modo, o output de um
etiquetador do NLTK é uma lista de tuplas (no caso do método tag aplicado a uma
sentença) ou uma lista de listas de tuplas (no caso do método batch_tag aplicado a
um conjunto de sentenças). Um etiquetador do NLTK não possui um método para
etiquetagem de um texto dividido em parágrafos, que constitui uma lista de listas de
sentenças. Certamente não é difícil elaborar uma função que itere o método
batch_tag sobre os parágrafos de um texto. A dificuldade maior, porém, está em que
não há nenhum método ou função que transforme uma lista de parágrafos
etiquetados em um corpus anotado em um dos formatos convencionais e salve esse
corpus em arquivo. Como veremos nesta seção, essas são dificuldades inexistentes
para o usuário do Aelius, que, para realizar todas essas tarefas, precisa apenas de
conhecimentos elementares de Python.

Comecemos pela construção de um etiquetador RUBT (Figura 6).

Primeiramente, importamos a função load do módulo data do NLTK. Essa função
permite extrair o etiquetador armazenado no arquivo binário
AeliusRegexpTagger.pickle, que é aplicado, com sucesso, na etiquetagem de uma
sentença non-sense. Em seguida, importamos dois módulos do Aelius. O primeiro
contém funções para manipulações diversas de textos; o segundo, funções para
construção de etiquetadores de arquiteturas variadas. Pressupondo que o diretório
de trabalho é onde se encontram os arquivos do CHPTB-M, extraímos todas as
sentenças anotadas desse corpus por meio de um único comando. As sentenças
extraídas bem como o RegexpTagger são dados como parâmetro para a função
TreinaRUBT, que retorna uma instância da classe TrigramTagger. Essa instância é
atribuída à variável rubt.
Figura 6: Construção de etiquetador RUBT por meio do Aelius utilizando a interface
IDLE de Python

O etiquetador resultante é aplicado, então, na anotação da versão

toquenizada da primeira sentença do excerto de Recordações do Escrivão Isaías
Caminha (Figura 7).

Figura 7: Aplicação do etiquetador RUBT na análise de sentença de Lima Barreto.

O seguinte comando mostra como anotar todo um arquivo de texto em xml

em conformidade com as orientações da TEI 5. Pressupõe-se que o arquivo em
questão encontra-se no subdiretório amostra do diretório de trabalho. Uma parte do
arquivo resultante é apresentada na Figura 8.

>>> ProcessaCorpus.AnotaTexto(rubt,"isaias.txt","amostra",formato="xml")

Exemplo 1
Figura 8: Anotação em xml do Aelius visualizada no programa Syntex Serna

Vejamos a acurácia do etiquetador RUBT no TEST-SET e no DEV-TEST-

SET:
Figura 9: Avaliação do etiquetador RUBT.

Na Figura 9, utilizamos inicialmente a função TestaEtiquetador do Aelius em

vez do método evaluate do NLTK, pois, quando utilizamos esse método diretamente,
a acurácia não é medida de forma correta. Para comprovar isso, primeiramente
construímos uma instância da classe TaggedCorpusReader do NLTK a partir dos
textos da Tabela 3. Dessa instância extraímos as sentenças anotadas, que damos
como parâmetro para o método evaluate. Em seguida fixamos um padrão-ouro, com
relação ao qual avaliamos o etiquetador RUBT, obtendo acurácia de 90.91%.
Finalmente, verificamos que erros foram cometidos pelo etiquetador, aplicando-o no
padrão-ouro, só que sem as etiquetas. Constatamos que o erro cometido consistiu
na atribuição da etiqueta N à palavra não (etiqueta NEG).

Dada a altíssima freqüência da palavra não, esse erro, à primeira vista, é

surpreendente. Na verdade, o erro não decorreu do etiquetador, mas do fato de que
a cadeia Unicode u'n\xe3o' não foi codificada em utf-8. Ao realizar essa codificação,
o erro desaparece (Figura 10). O Aelius faz essa codificação automaticamente para
o usuário, recorrendo à função CodificaSentencasAnotadas().
Figura 10: O problema da codificação de Unicode na etiquetagem do NLTK.

Com a codificação apropriada, o índice sobe, mas, mesmo assim, é ainda

quase meio ponto percentual inferior. Essa diferença se deve a um módulo do Aelius
que processa nomes próprios de forma mais eficiente que os etiquetadores do
NLTK. Por meio de algoritmo que desenvolvemos, os nomes próprios que ocorrem
no texto em posição não inicial de sentença são armazenados num dicionário. Na
etiquetagem, todas as palavras em posição inicial que não constam nesse dicionário
são minusculizadas. Após a etiquetagem, essas palavras são remaiusculizadas.
Esse algoritmo permite contornar deficiência dos RegexpTaggers do NLTK, que não
têm acesso ao contexto dos tokens. Nesses etiquetadores, se especificamos que
toda palavra com inicial maiúscula é nome próprio, cometemos erros de comissão
toda vez que uma sentença não se inicia por nome próprio (Exemplo 2).

[(u'Escorchado', 'NPR'), (u',', ','), (u'indigente', 'ADJ-G'), (u'de', 'P'), (u'arvoredo',

'N') ...]
[(u'Bateram', 'NPR'), (u'-', '+'), (u'se', 'SE'), (u'os', 'D-P'), (u'vastos', 'ADJ-P'),
(u'currais', 'N-P'), (u',', ',') ...]

Exemplo 2: Erros de comissão na etiquetagem de nomes próprios. A etiqueta NPR é

atribuída indiscriminadamente a toda palavra no início de sentença.

Por outro lado, se minusculizamos de forma indiscriminada todas as palavras

em início de sentença, cometemos erros de omissão toda vez que uma sentença se
inicia por nome próprio (Exemplo 3). O módulo ProcessaNomesPróprios do Aelius
resolve esse dilema.

[('luzia', 'VB-D'), ('encontrara', 'VB-RA'), ('em', 'P'), ('Sobral', 'NPR'), ('abrigo', 'N'),
('e', 'CONJ'), ('f\xc3\xa1ceis', 'ADJ-G-P'), ('meios', 'N-P'), ('de', 'P'), ('subsist\xc3\
xaancia', 'N')]
Exemplo 3: Erro de omissão na etiquetagem de nomes próprios. A palavra Luzia,
minusculizado, deixa de ser reconhecido como nome próprio, sendo falsamente
etiquetado como verbo.

Luzia/NPR encontrara/VB-RA em/P Sobral/NPR abrigo/N e/CONJ fáceis/ADJ-G-P meios/N-P de/P

subsistência/N

Exemplo 4: Correção do Exemplo 3.

Como vimos, o Aelius leva a acurácia do RUBT a 95.28% no DEV-TEST-SET,

acima, portanto, da nossa meta inicial. No caso do TEST-SET, porém, a acurácia de
94.70% fica abaixo dessa meta. De todas as arquiteturas de etiquetagem do NLTK
que exploramos e levando em conta os experimentos com o NLTK relatados na
literatura, o modelo de Brill foi o que nos pareceu mais apto a atingir esse patamar
no TEST-SET, sendo, ao mesmo tempo, compacto.
Vejamos como é fácil, no Aelius, construir e testar um etiquetador de Brill a
partir do conjunto de treino e do RUBT da Figura 6:

Figura 11: Construção e avaliação de um BRUBT no Aelius.

A Figura 11 evidencia que o BRUBT, embora não apresente desempenho

substancialmente melhor no DEV-TEST-SET que o RUBT, ultrapassa no TEST-SET
ligeiramente o patamar de 95%, que estabelecemos como mínimo. Como
constatado por Perkins (2008), o modelo de Brill, no NLTK, consome, na
etiquetagem, mais tempo do que uma arquitetura baseada em NgramTaggers,
RegexpTagger e AffixTaggers. Pelo que testamos, o BRUBT é 1.7 mais lento do que
o RUBT. No entanto, diferentemente do que constataram Hasan, Uzzaman e Khan
(2006), o primeiro, que ocupa 1.6 MB em disco, é só 0.1 MB menor que o último
(Tabela 8). A grande desvantagem do BRUBT é o tempo de treino: quase 11 horas e
meia, contra apenas 7 minutos e meio do RUBT.

6.3. O Aelius comparado a etiquetadores do português livremente disponíveis

Abstraindo dos etiquetadores não livremente disponíveis, os melhores índices

de acurácia relatados na seção 3.2 situam-se na faixa de 94% a 97%, variando em
função do tipo de texto e da complexidade do conjunto de etiquetas. Os melhores
resultados foram obtidos com conjuntos de etiquetas não tão complexos em textos
jornalísticos contemporâneos. Parece que, quando passamos para o registro mais
elaborado da linguagem literária, o que podemos considerar estado da arte é de um
a dois pontos abaixo dos 96% a 97% normalmente considerados como tal. Os
resultados do nosso BRUBT no DEV-TEST-SET e no TEST-SET, um pouco acima
de 95%, são, portanto, excelentes, hajam vista as características dos textos e do
conjunto de etiquetas. Como mostra a Tabela 8, tanto o BRUBT quanto o RUBT do
Aelius superam, em acurácia e economia, etiquetador análogo construído com a
ferramenta de Kepler (2005). O AeliusHMM, além de antieconômico, teve fraco
desempenho.

Etiquetador Tamanho DEV-TEST- Tempo TEST- Tempo

( MB) SET SET
VLMMTagger 6.7 94.56% 8 94.62% 5
treinado em 100%
do CHPTB-M
AeliusHMM 240 91.32% 252.20 92.29% 96.94
AeliusRUBT 1.7 95.28% 5.27 94.70% 1.75
AeliusBRUBT 1.6 95.30% 9.07 95.09% 2.22

Tabela 8: Desempenho do Aelius comparado ao do VLMMTagger.

Figura 12: Exemplo de etiquetagem pelo etiquetador RUBT do Aelius. Os erros
estão destacados em vermelho (Alencar, 2011).

Figura 13: Exemplo de etiquetagem pelo etiquetador TreeTagger (Lácio-Web, s.d.).

As correções manuais dos erros estão precedidas de @ e destacadas em vermelho
(Alencar, 2011).

Dadas as diferenças profundas entre o conjunto de etiquetas do CHPTB e o

do corpus Mac-Morpho, base para os etiquetadores on-line do Lácio-Web, uma
comparação entre estes e os etiquetadores do Aelius é uma tarefa não trivial. Como
primeiro passo na comparação entre o Aelius e o TreeTagger desse projeto,
extraímos, inicialmente, dez sentenças de Luzia-Homem aleatoriamente e contamos
os erros cometidos pelos dois etiquetadores. Como evidencia a Figura 15, a
acurácia do Aelius superou a do TreeTagger em quase 8%. Ressalte-se que o
sistema de anotação do CHPTB estabelece mais distinções que o do Lácio-Web
(Figura 16).
 A Tabela 9 realiza outra comparação entre o desempenho do Aelius e de
outros etiquetadores, agora na anotação dos dois primeiros parágrafos de Luzia-
Homem. Como evidenciam a Figura 12 e a Figura 13, o Aelius comete menos "erros
duros" (harte Fehler, conforme Naumann, 2004, p. 155, n. 1) do que TreeTagger do
Lácio-Web.13 De fato, as categorias N, ADJ e VB-AN, envolvidas nos erros
cometidos pelo Aelius nos tokens 36, 98 e 126, são muito próximas. Apenas os erros
nos tokens 90 e 110 envolvem categorias completamente díspares. O etiquetador
LX (LX-Grupo, [s.d.]; Branco e Silva, 2004) tem um bom desempenho só
aparentemente: cometeu quase o triplo dos erros do Aelius, a alta acurácia
alcançada devendo-se ao excessivo número de tokens. Constata-se que o Aelius só
não supera o TreeTagger que utiliza os parâmetros de Gamallo (2005) (Figura 14).
No entanto, é importante ressaltar que esse etiquetador utiliza um conjunto de
etiquetas extremamente simplificado (e bem menos informativo, conforme
Voutilainen, 2004), que não leva em conta categoriais flexionais nem faz muitas das
distinções do conjunto de etiquetas do CHPTB (por exemplo, distinção entre nomes
comuns e próprios, entre verbos, particípios e gerúndios etc.). Como mostra a Figura
16, o conjunto de etiquetas do Aelius, em Luzia-Homem, é quase 6 vezes maior do
que o desse etiquetador.
Figura 14: Etiquetagem de trecho de Luzia-Homem pelo TreeTagger de Gamallo
(2005). Observe os erros em indigente, urubutingas e camirangas.
Figura 15: Comparação entre o Aelius e o TreeTagger do Lácio-Web na anotação de
10 sentenças aleatórias do romance Luzia-Homem.

Etiquetador Erros Tokens Acurácia

TreeTagger com parâmetros de Gamallo 3 156 98.08%

(2005)
Aelius RUBT 5 158 96.82%
VLMMTagger treinado em 100% do 8 158 94.94%
CHPTB-M
Etiquetador LX 13 247 94.74%
TreeTagger Lácio-Web 25 164 84.76%
Brill Lácio-Web 26 164 84.15%

Tabela 9: Acurácia de seis etiquetadores nos dois primeiros parágrafos de Luzia-

Homem.

Figura 16: Complexidade dos conjuntos de etiquetas do TreeTagger de Gamallo

(2005), do TreeTagger do Lácio-Web e do Aelius na anotação de Luzia-Homem.

7. Conclusão

Neste trabalho, apresentamos o Aelius, pacote em Python que torna ainda

mais acessível para não-programadores a construção e manipulação de
etiquetadores morfossintáticos do NLTK, ao mesmo tempo em que acrescenta
várias funcionalidades a essa biblioteca.

As propriedades de etiquetadores de várias arquiteturas que integram o

pacote foram discutidas, no contexto da anotação de textos literários históricos
utilizando o abrangente conjunto de etiquetas do CHPTB. Nos testes realizados em
textos que não integram o CHPTB, o BRUBT (um BrillTagger com um RUBT inicial),
seguido do RUBT (um NgramTagger com backoff para um RegexpTagger),
apresentou os melhores resultados. A acurácia acima de 95% obtida pelo primeiro é
equiparável à relatada para os melhores etiquetadores livremente disponíveis,
quando se leva em conta a maior complexidade da anotação de textos literários
históricos utilizando um sistema de anotação bastante detalhado. Além disso, em
testes comparativos que realizamos, o AeliusBRUBT superou a acurácia tanto de
um VLMMTagger treinado nas mesmas condições quanto o TreeTagger e o Brill do
Lácio-Web. Com isso, o Aelius parece constituir a mais precisa ferramenta
livremente disponível de anotação, com um conjunto de etiquetas rico, de textos
literários brasileiros novecentistas. Parte desse resultado se deve ao tratamento
mais eficiente de nomes próprios na etiquetagem do Aelius em relação ao próprio
NLTK.

Acreditamos que o Aelius, cuja acurácia na etiquetagem morfossintática

almejamos elevar a mais de 97% num futuro próximo, muito contribuirá para a
difusão do NLTK nos países de língua portuguesa, ao permitir ampliar
consideravelmente o acervo de dados nessa língua distribuídos com a biblioteca.
Por ser ainda mais acessível que o NLTK, também permitirá estreitar o fosso que
ainda separa, entre nós, as comunidades de lingüistas de corpus e lingüistas
computacionais. Por outro lado, aplicado por outros pesquisadores sem muitas
noções de programação na anotação de textos de gêneros e épocas diversas,
poderá fornecer novos materiais para estudos diacrônicos, dialetológicos ou
literários baseados em corpora.

Referências bibliográficas
ALENCAR, L. F. de. CORPTEXLIT – Corpus de Língua Portuguesa de Textos
Literários do Século XIX. Fortaleza: [s.n.], 2011. Disponível em:<
http://www.leonel.profusehost.net/corptext.html> Acesso em: 30. set. 2010.

BERBER SARDINHA, T. Lingüística de corpus. Barueri, SP: Manole, 2004.

BIRD, S.; KLEIN, E.; LOPER, E. Natural language processing with Python: analyzing
text with the Natural Language Toolkit. Sebastopol, CA: O’Reilly, 2009.

______. Natural Language Toolkit. [s.l]: [s.n.], 2011. Disponível em:

<http://www.nltk.org> Acesso em: 24 jan. 2011.

BRANCO, A.; SILVA, J. 2004. Evaluating Solutions for the Rapid Development of
State-of-the-Art POS Taggers for Portuguese. In: LINO, M. T. et al. (Eds.). Paris:
ELRA, 2004, p. 507-510.

BRANDTS, T. TnT – A Statistical Part-of-Speech Tagger. Disponível

em:<http://acl.ldc.upenn.edu/A/A00/A00-1031.pdf> Acesso em: 2. fev. 2011.

CHUN, W. J. Core Python programming. 2. ed. Upper Saddle River, NJ: Prentice
Hall, 2006.

CONTIER, A.; PADOVANI, D.; JOSÉ NETO, J. Tecnologia Adaptativa Aplicada ao

Processamento da Linguagem Natural. WORKSHOP DE TECNOLOGIA
ADAPTATIVA, n. 4, 2010, São Paulo. Memórias... São Paulo: EPUSP, 2010. p.
35-42.

CORPUS Histórico do Português Tycho Brahe. Campinas: Universidade Estadual de

Campinas, 2010. Disponível em:<http://www.tycho.iel.unicamp.br/~tycho/corpus/>
Acesso em 30. set. 2010.

DOMINGUES, M. L.; FAVERO, E. L.; MEDEIROS, I. P. de. O desenvolvimento de

um etiquetador morfossintático com alta acurácia para o português. In: TAGNIN, S.
E. O.; VALE, O. A. (Eds.). Avanços da Linguística de Corpus no Brasil. São Paulo:
Humanitas, 2008. p. 267-286.

FELDMAN, A.; HANA, J. A resource-light approach to morpho-syntactic tagging.

Amsterdam; New York: Rodopi, 2010.

FLORESTA Sintá(c)tica. [s.l.]: [s.n], 2010. Disponível em:<

http://www.linguateca.pt/Floresta/> Acesso em: 1. fev. 2011.

FREELING 2.2: An open source suite of language analyzers. Barcelona: TALP

Research Center, Universitat Politècnica de Catalunya, 2011. Disponível
em:<http://nlp.lsi.upc.edu/freeling/> Acesso em: 2 de fev. 2011.

GAMALLO, P. Tree-Tagger para português. Santiago de Compostela: Universidade

de Santiago de Compostela, 2005. Disponível em:
<http://gramatica.usc.es/~gamallo/> Acesso em: 21 jul. 2010.
GARCIA, M.; GAMALLO, P. Análise morfossintática para português europeu e
galego: problemas, soluções e avaliação. LinguaMÁTICA, Braga, v. 2, n. 2, p. 59-67,
jun. 2010.

NLX-GRUPO de Fala e Linguagem Natural. LX-Tagger. Lisboa: Universidade de

Lisboa, Departamento de Informática,[s.d.]. Disponível em:<http://lxcenter.di.fc.ul.pt
/tools/en/LXTaggerEN.html> Acesso em: 15 fev. 2011.

GÜNGÖR, T. Part-of-Speech Tagging. In: INDURKHYA, N.; DAMERAU, F. J.

Handbook of Natural Language Processing. 2. ed. Boca Raton, FL: Chapman & Hall/
CRC, 2010. pp. 205-235.

HASAN, F. M.; UZZAMAN, N.; KHAN, M. Comparison of different POS Tagging

Techniques (N-Gram, HMM and Brill’s tagger) for Bangla. Dhaka, Bangladesh:
Center for Research on Bangla Language Processing, BRAC University, 2006.
Disponível em: < http://www.bracu.ac.bd/research/crblp/papers/BAN08.pdf > Acesso
em: 16 out. 2010.

______; ______; ______. Comparison of Unigram, Bigram, HMM and Brill’s POS
Tagging Approaches for some South Asian Languages. Dhaka, Bangladesh: Center
for Research on Bangla Language Processing, BRAC University, 2007. Disponível
em: < http://www.bracu.ac.bd/research/crblp/papers/POS_south_asian_clt07.pdf >
Acesso em: 24 nov. 2011.

JUNGEN, O.; LOHNSTEIN, H. Einführung in die Grammatiktheorie. München:

Wilhelm Fink, 2006.

JURAFSKY, D.; MARTIN, J.H. Speech and language processing: an introduction to

natural language processing, computational linguistics, and speech recognition. 2.
ed. London: Pearson International, 2009.

KEPLER, F. N. Um etiquetador morfo-sintático baseado em cadeias de Markov de

tamanho variável. 2005. 70p. Dissertação (Mestrado) – Programa de Pós-Graduação
em Ciência da Computação, Universidade de São Paulo, São Paulo, 2005.
Disponível em:<http://www.ime.usp.br/~kepler/msc/kepler2005MSc.pdf> Acesso em:
15 abr. 2010.

LÁCIO-WEB: Ferramentas. São Paulo; São Carlos: Universidade de São Paulo,

[s.d.]. Disponível em:<http://www.nilc.icmc.usp.br/lacioweb/ferramentas.htm> Acesso
em: 30 set. 2010.

LEMNITZER, L.; ZINSMEISTER, H. Korpuslinguistik: eine Einführung. Tübingen:

Narr, 2006.

MILIDIÚ, R. L.; SANTOS, C. N. dos; DUARTE, J. C. Portuguese Corpus-Based

Learning Using ETL. Journal of the Brazilian Computer Society, Campinas, v. 14, n.
4, p. 17-27, 2008.

NAUMANN, S. XML-basierte Tools zur Entwicklung und Pflege syntaktisch

annotierter Korpora. In: MEHLER, A.; LOBIN, H. (Eds.). Automatische Textanalyse:
Systeme und Methoden zur Annotation und Analyse natürlichsprachlicer Texte.
Wiesbaden: VS Verlag für Sozialwissenschaften, 2004. p. 153-166.

PADRÓ, L. et al. FreeLing 2.1: Five Years of Open-Source Language Processing

Tools. LANGUAGE RESOURCES AND EVALUATION CONFERENCE, n. 7, 2010,
La Valletta, Malta. Proceedings... [s.l.]: [s.n], 2010. Disponível em: <
http://www.lsi.upc.edu/~nlp/papers/padro10b.pdf> Acesso em: 1. fev. 2011.

PERKINS, J. Part of Speech Tagging with NLTK. [s.l.]: [s.n], 2008. Disponível em:<
http://streamhacker.com/2008/11/03/> Acesso em: 2 out. 2010.

______. Python Text Processing with NLTK 2.0 Cookbook. Birmingham, UK: Packt,
2010.

TAGNIN, S. E. O.; VALE, O. A. (Eds.). Avanços da Linguística de Corpus no Brasil.

São Paulo: Humanitas, 2008.

TEI CONSORTIUM. P5: Guidelines for Electronic Text Encoding and Interchange.
[s.l.]: [s.n], 2010. Disponível em: <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/
index-toc.html> Acesso em: 12 fe. 2011.

ULE, T.; HINRICHS, E. Linguistische Annotation. In: LOBIN, H.; LEMNITZER, L.

(Eds.). Texttechnologie: Perspektiven und Anwendungen. Tübingen: Stauffenburg,
2004. p. 217-243.

VOUTILAINEN, A. Part-of-speech tagging. In: MITKOV, R. (Ed.). The Oxford

handbook of computational linguistics. Oxford, Oxford University Press, 2004. p. 219-
232.
1
Contier, Padovani e José Neto (2010) é uma das poucas menções ao NLTK que
conseguimos garimpar em textos em português na WWW por meio do Google, mas em
contextos que não se referem à utilização dessa biblioteca na anotação automática de
textos em português.
2
Na versão disponibilizada no NLTK, informa-se apenas que se trata do corpus Floresta
Sintá(c)tica, sem que seja especificado de que material se trata. Aparentemente, apenas
o componente Bosque foi disponibilizado, pois o número de sentenças (9266) aproxima-
se do divulgado no site do projeto (Floresta, 2010).
3
Dionísio Thrax propôs a categoria artigo em vez de interjeição (Jungen; Lohnstein, 2006,
p. 38), talvez pelo fato de a língua grega, diferentemente da latina, possuir artigos.
4
O sistema do CHPTB utiliza alguns defaults. Por exemplo, a ausência de etiqueta nos
substantivos é indicativa do singular e, nos adjetivos biformes, de singular e masculino.
Somente formas de adjetivos com grau morfologicamente marcado recebem as etiquetas
R e S (comparativo e superlativo, respectivamente). Por outro lado, nesse sistema, a
etiquetagem morfológica não se aplica a todas as classes de palavras flexionáveis em
português. Pronomes pessoais e clíticos não são etiquetados quanto a gênero, número e
caso.
5
V. nota 8.
6
Na literatura, etiquetadores baseados em modelos de Markov costumam ser chamados
de etiquetadores baseados em n-gramas (ver, por exemplo, Feldman e Hana, 2010, p. 6).
É preciso ressaltar, porém, que a classe NgramTagger do NLTK não recorre a modelos
de Markov para computar a etiqueta de um token. Em vez disso, faz um simples
mapeamento de um contexto sobre a etiqueta mais freqüente para aquele contexto no
corpus de treino.
7
Aparentemente, o algoritmo decidiu-se por a/CL pelo ordenamento alfabético.
8
Feldman e Hana (2010, p. 71-79) chamam a atenção para o fato de que o problema da
"esparsidade" (sparsity) é muito maior em português e noutras línguas flexionadas como
espanhol e russo do que em inglês, quando se utiliza um conjunto de etiquetas amplo o
suficiente para modelar as propriedades morfológicas dos tokens. Para esses autores,
não está claro que tamanho deveria ter um corpus para cobrir todo o conjunto de
etiquetas.
9
Sobre essa arquitetura, ver, por exemplo, em português, Berber Sardinha (2004) e
Domingues, Favero e Medeiros (2008).
10
Pela nossa própria medição, reexecutando os comandos de Perkins (2008), esse
etiquetador obteve um índice de 87.21%.
11
Salvo especificação contrária, o consumo de tempo, neste trabalho, é dado em
segundos, medido num computador com processador Intel Core 2 Duo de 2.16 GHz e 2
GB de RAM, rodando o sistema operacional MAC OS 10.4.11.
12
É preciso ressaltar que, para a compilação dos conjuntos de treino e de teste, foi
utilizada uma versão do CHPTB com as sentenças aleatoriamente embaralhadas, o que
evita um enviesamento da avaliação.
13
Ver os demais trechos anotados em Alencar (2011).