ryukinix/language-requirements.md

## language-requirements.md

      
    Raw
  

              language-requirements.md
            
          
    Language Requirements TC

Esse é documento de orientação para a implementação de novas linguagens no repositório nexusedge/ai-nlp-tc
PreProcessing

Durante o pré-processamento é feito, na seguinte ordem, os seguintes procedimentos:


identificação de entidades e extração

risadas²
url¹
hashtag¹
email¹
entidades capitalizadas¹
dinheiro¹
data¹
telefone¹³


segmentação e procedimentos por tokens:²

limpeza de caracteres ruidosos, como simbolos soltos (e.g: <>)¹³
remoção de caracteres repetidos em tokens (e.g: muuiiito)²
tradução de slangs/gírias²


¹independente de linguagem


²dependente de linguagem


³subjetivo (precisa revisar)


Tunning


O tunning é a procedimento de limpeza de dados para facilitar a tokenização e a clusterização de palavras que possuem variações, mas são a mesma coisa. Isto incluem palavras que possuem dialetos constantemente usados com variações de erros ortográficos e potencializadores via repetição de caracteres. O uso de gírias é também feito via tradução e também é muito importante
(1): independente de linguagem
(2): dependente de linguagem
(3): subjetivo (precisa revisar)
Nesta seção, precisamos definir a cunho de linguagem:

entidades (como risadas e entidades capitalizadas)
gírias
regras de normalização para repetição de caracteres (muito importante)

Os arquivos que impactam essas modificações são:


tc/normalization.py

normalize_string(string)
\_remove_duplicate_chars(string)
\_remove_noise_chars(string)


data/slangs_abbr.yml


É recomendado que seja prefixado os arquivos de dados dependente de linguagem como é o caso de slangs_abbr.yml, onde seja preferivelmente escrito como: pt_br-slangs_abbr.yml, ou melhor, pt_br-slangs.yml
Segmentation


Durante o processo de segmentação, que segue por quebra de sentenças e tokenização, essas duas atividades são feitas baseadas por linguages. Sendo assim é necessário um tokenizador e sentence splitter por linguagem.
Os arquivos que necessitam de atenção especial são:

tc/segmentation.py

tokenize(string)
sentences(string)


Abstraction by Word2Vec


Como era de esperar, o modelo de abstração/vetorização é dependente de linguagem no sentido de treinamento — embora o algoritmo em si seja agnóstico a linguagem. É possível inclusive, com grande probabilidade, o algoritmo ser usado com os mesmos parâmetros de inicialização em relação ao que já foi feito previamente na primeira linguagem de implementação (brazillian-portuguese).
Os atuais parâmetros de treinamento são:

size=200 
window=5
min_count=30

Na qual o parâmetro size é o tamanho do vetor de saída que possui relação direta ao tamanho do corpora treinado (para corporas maiores, um vetor de saída maior é preferível), window é a quantidade de vezes que o corpora é iterado no treinamento (impacta diretamente na precisão) da rede neural e min_count é o count global mínimo de uma palavra para ela ser inserida no modelo — alto demais reduz o vocabulário, pequeno demais incluí muitos ruídos inúteis que prejudicam na similaridade de vetorização (escolha um número com sabedoria).
Documents


A quantidade de documentos que foi usado durante o treinamento atual foi de 1,629,645 (um milhão seiscentos vinte nove mil e seiscentos quarenta cinco) documentos — dos quais 6591 foram posts e 1623054 comentários (alvo de classificação). A estratégia ao incluir posts foi feito na pretensão de enriquecer o vocabulário do modelo, que é fator crucial para uma classificação possível nas seguintes etapas. É estimado no mínimo um corpora dessa magnitude para fazer o treinamento, de preferência maior possível.
Esta etapa é crucialmente dependente do PreProcessing, que é definido por linguagem.
Os arquivos de impacto estão definidos no sub-repositório:

tc/models/training/

trainer.py

queries no banco de dados para treinamento
chamadas de normalização e configuração do modelo


word2vec.py

principal ativador de treinamento
define o corpora a ser treinado, previamente configurado em trainer.py


Além disso, é realmente recomendado que a partir desse momento os arquivos salvos tenham seu nome no modelo ideal, que necessariamente é:
filename_pattern: lang_locale-media_platform-brand_or_segment-content_type.model_name```

Ex.:

pt_br-facebook-food_segment-posts.word2vec
en_us-twitter-espn-all.tensorflow

Classification By TensorFlow


A classificação do TensorFlow é dependente de todos os módulos acima, incluindo: PreProcessing & Word2Vec devidamente configurado para linguagem. No entanto, o classificador por si mesmo não faz dependência mais de linguagem nesse momento — com exceção de um fator. É necessário que seja definido um dataset inicial para treinamento com no mínimo 150 documentos na linguagem de preferência (estimado a partir do modelo atual em funcionamento) para classificação da classe desejada — as ideias (ou a classe que for desejado) pode ser em qualquer linguagem, mas o conteúdo da mensagem DEVE ser na linguagem desejada. Um modelo de tabela proposto para ser universal, incluindo uma possível persistência no banco de dados, seria:
	language | brand | segment| message | idea | sentiment |
	--------------------------------------------------------
	|  pt-br | seara  | food  |  ....   |  .   |   ....    |

Vale lembrar que a classificação de sentiment neste ponto é diretamente ligado a classificação de idea. É possível, se desejar, classificar com mais outras clsases, mas se for independente de idea, tem-se que treinar um classificador a parte.
O classificador atualmente implementado é projetado para realizar a predição de uma label de n classes (ideas). Embora seja definido 'idea' por padrão, é possível treinar em relação ao outro tipo de classe, como sentimento binário (pos/neg) ou outras mais.
Coding Design


Para implementação de todas essas variáveis de linguagem existem duas abordagens:

definir uma variável global em tc/constants.py chamada LANGUAGE e fazer uso dessa variável para todas as funções que dependem de linguagem fazer sua decisão de adaptação. Quando for necessário o repositório ser usado para outra linguagem, bastaria ser setado essa variável no cabeçalho do script, algo como tc.LANGUAGE='en-us'.
para toda função e classe que depender de linguagem, passar um parâmetro chamado language para tal.

Pela simplicidade de implementação e uso, acredito que a opção (1) seja mais acessível e escalável, mesmo que fere os regulamentos do paradigma funcional que foi pensado durante a criação do repositório.