Nltk: Melhore a tokenização de expressões com várias palavras, incluindo "particionador python"

Criado em 11 dez. 2018  ·  9Comentários  ·  Fonte: nltk/nltk

Suspeito que @jakerylandwilliams & @andyreagan 's https://github.com/jakerylandwilliams/partitioner poderia melhorar significativamente a qualidade de tokenização do NLTK, especificamente quando se trata de MWEs (expressões de várias palavras).

@ NeelShah18 recentemente portou-o para Python 3:

https://github.com/jakerylandwilliams/partitioner/pull/7

Portanto, incluí-lo no NLTK deve parecer fácil o suficiente.

Para obter mais informações sobre a abordagem usada lá, veja aqui:

https://noisy-text.github.io/2017/pdf/WNUT01.pdf

E aqui:
https://arxiv.org/abs/1710.07729

É licenciado para Apache 2.0, então as licenças também parecem compatíveis.

enhancement nice idea tokenizer

Comentários muito úteis

@alvations e @ NeelShah18 , concordo que retirar e embalar novamente os dicionários geográficos e o recurso de segmentação MWE por estrutura NLTK e normas de codificação faria mais sentido para a integração. Existem alguns modelos e utilitários dentro de https://github.com/jakerylandwilliams/partitioner e aquele provavelmente mais adequado para NLTK foi mencionado no início do tópico por @ no-identd:

https://noisy-text.github.io/2017/pdf/WNUT01.pdf

Se for do seu interesse, certamente posso ajudar na execução de algumas das tarefas necessárias.

Todos 9 comentários

Uma pequena nota / adendo sobre / para isso, uma vez que:
a) Esqueci de mencioná-lo na postagem inicial; e
b) parece digno de menção:
O particionador Python já faz uso de NLTK.

Obrigado por sugerir particionador; Eu não tinha visto isso antes. Com base no artigo, parece que ele realiza a segmentação do MWE com base em probabilidades n-gram de dados de treinamento rotulados com MWE e grandes recursos lexicais (principalmente extraídos do Wikcionário / Wikipedia). Ao contrário da maioria das abordagens estatísticas, evita cálculos caros, essencialmente adiando a maior parte do trabalho para contagens de frequência e pesquisas de dicionário. A ferramenta suporta 18 idiomas PARSEME, incluindo inglês e uma variedade de idiomas europeus.

Se for adicionado ao NLTK, qual seria o tamanho necessário? O repositório do particionador é> 100 MB. Se houver arquivos de dados grandes, suponho que o usuário teria que usar nltk.download() para solicitá-los.

Deve levar algum tempo para carregar os grandes recursos de dados na memória para executar o sistema - são apenas alguns segundos ou mais?

Observe que isso vai muito além da "tokenização" padrão em termos de unidades lexicais ortográficas, portanto, não é um substituto para a tokenização ou lematização básica (# 1214).

Infelizmente, terei que passar essas questões devido a limitações de tempo e falta de experiência operacional com particionador, pelo menos no futuro previsível. Desculpe! Mas talvez @jakerylandwilliams ou @andyreagan possam responder a essas perguntas

Obrigado @ no-identd e @nschneid por contato ; Estou feliz que o módulo seja de interesse. No momento, estamos trabalhando em algumas melhorias de back-end, dados e modelo para Python 3. Se trazer a versão atual para o nltk, acho que seria bastante simples de implementar.

@nschneid , sua avaliação do modelo está correta. Arquivos de dados grandes podem levar alguns segundos; o único atraso no carregamento que vi é para o conjunto de dados EN Wikipedia, mas este recurso pode ser omitido a um custo relativamente pequeno de desempenho para essencialmente um carregamento instantâneo. Provavelmente faria sentido definir o carregamento EN padrão para apenas omitir a Wikipedia.

Estou feliz em levar adiante a discussão e responder a quaisquer outras perguntas.

@jakerylandwilliams @nschneid Se formos omitidos a Wikipedia e até mesmo usarmos o downloader padrão da nltk, então ele é compatível com python2 e python3. Posso ajudar na independência multiplataforma (python2 e python3) do código do particionador.

Na verdade, se https://github.com/jakerylandwilliams/partitioner já for um pacote funcional em Python, pode não haver necessidade de portar / reimplementar o código. Os usuários podem escolher facilmente usar o tokenizer diretamente do particionador.

Se quisermos as "coisas boas" como MWE, podemos pegar os dicionários geográficos do particionador e, de alguma forma, empacotar o recurso MWE em vez de portar todo o repositório do particionador para o NLTK. Se os mantenedores do particionador desejam manter o código em NLTK em vez de em seu pacote pypi, acho que vale a pena o esforço de portar o código de bibliotecas Python de terceiros.

@alvations Concordo com sua sugestão. Mas, vejo a implementação do NLTK que temos que reescrever de acordo com a estrutura e o teste do NLTK. Também precisamos de código para portável em python2 e python3 para torná-lo normas de codificação de biblioteca NLTK.

@alvations e @ NeelShah18 , concordo que retirar e embalar novamente os dicionários geográficos e o recurso de segmentação MWE por estrutura NLTK e normas de codificação faria mais sentido para a integração. Existem alguns modelos e utilitários dentro de https://github.com/jakerylandwilliams/partitioner e aquele provavelmente mais adequado para NLTK foi mencionado no início do tópico por @ no-identd:

https://noisy-text.github.io/2017/pdf/WNUT01.pdf

Se for do seu interesse, certamente posso ajudar na execução de algumas das tarefas necessárias.

🤔

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

DavidNemeskey picture DavidNemeskey  ·  4Comentários

zdog234 picture zdog234  ·  3Comentários

Chris00 picture Chris00  ·  3Comentários

goodmami picture goodmami  ·  4Comentários

alvations picture alvations  ·  4Comentários