Por que o homem que falava javanes mudou minha abordagem com línguas de baixo recurso
A primeira vez que precisei processar texto em javanês, achei que seria apenas mais um caso de multilinguismo. O problema é que javanês não tem corpus público significante. Não há Wikipedia, não há Common Crawl limpo, e os conjuntos de dados que existem são dispersos entre arquivos académicos de 2017 até uma base da NUS que precisa de autenticação institucional. Eu estava num projeto de NLP para uma editora brasileira que queria localizar material técnico para comunidades imigrantes, e a pedido foi simplesmente: "traduza isto para javanês". Eu não sabia nem que javanês tem três registos de formalidade que mudam completamente a morfologia.
O homem que falava javanes como problema técnico
O que eu chamo de "o homem que falava javanes" não é uma ferramenta — é um framework conceptual que desenvolvi depois de seis meses tentando fazer pipelines tradicionais funcionarem com javanês. A ideia central é que modelos treinados em línguas de alto recurso (inglês, português, mandarim) falham de maneiras sistemáticas e previsíveis quando aplicados a javanês, e o padrão de falha segue uma topografia que você pode mapear se estiver disposto a medir cada módulo separadamente. O pipeline básico que eu tentei primeiro era vanilla: tokenizer BPE treiado em textos latinizados, embeddings multilingues do XLM-R, fine-tuning com dados paralelos indonésio-javanês que encontrei no ACL Anthology. O resultado foi 12% de BLEU. Não é um typo. 12% com hardware de produção e 48 horas de treino. O problema raiz não era o modelo — era que o BPE segmentava palavras javanesas em morfemas que não têm correspondência cognitiva no indonésio, e o XLM-R tinha apenas 37 tokens javaneses no vocabulário de 250 mil unidades. Três vírgula setenta por cento de cobertura lexica. O resto era UNK.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A solução que funcionou exigiu três mudanças que ninguém recomenda em tutoriais porque nenhuma delas é elegante. A primeira foi abandonar o BPE e usar um morphological analyzer baseado em regras para javanês moderno (a versão latinizada, não o hanacaraka — este projeto não precisa de script javanês tradicional, o que já corta a complexidade pela metade). A segunda foi treinar um embedding específico para javanês usando skip-gram em um corpus de 400 mil linhas de notícias locais que escavei de archives do Detik e Java Pos entre 2019 e 2023. A terceira, e a mais importante, foi aceitar que a tradução automática para javanês não funciona bem com o register krama inggil — o nível mais formal — porque os dados disponíveis são 89% ngoko (informal) e saya nunca vi um par paralelo krama-inggil/ngoko sufficientemente grande para fazer transferència de registó sem alucinação morfológica. Na prática, o fluxo que eu uso agora é: (1) normalização ortográfica com regras de alternância vrbais javanesas — existe uma padronização controversa do KBBI para escrita javanesa que não é universalmente aceite, mas é o melhor padrão disponível; (2) chunking por frase com um segmentador treinado em corpus javanês de 200 mil sentenças do Bible Gateway em versão Terjemahan Lama; (3) tradução EN-ID com um modelo NLLB-200 fine-tuned em dados paralelos indonésio-javanês do sets MTX-INDO-JV do HuggingFace; (4) pós-processamento morfológico para ajustar concordância verbal e seleção de lexical de acordo com o register desejado.
O ganho real veio no passo quatro. O NLLB traduz para indonésio padrão, que é morfologicamente muito mais simples que javanês. A transição de "saya makan" para "kula nedha" (ngoko para krama) não é lexical — é sistemática. Existem listas de substituição morfológica que cobrem cerca de 60% do vocabulário de uso frequente. Eu construí uma tabela de 2300 entradas manualmente, validada por um falante nativo de Yogyakarta que contratei por três meses. O BLEU subiu de 12 para 34. Ainda é baixo, mas é usable para documentação técnica onde a precisão semântica conta mais que a fluência estilística. O que ninguém te diz sobre trabalhar com javanês é que o problema não é tecnologia — é que não existe comunidade de desenvolvedores. Você está essencialmente sozinho. Não há stackoverflow, não há issues no GitHub respondidos em menos de duas semanas, não há fóruns. Cada decisão errada é aprendida na marra, com paper academics de 2015 que usam datasets privados. Eu gastei três semanas tentando fazer funcionar um transformer attention mask customizado para as variações dialetais entre javanês oriental (Surabaya) e ocidental (Cirebon) até perceber que a variação dialetal era mais relevante que o architecture choice. Aquele modelo customizado que eu havia implementado — bom, não ajudou em nada. A variável que importava era a diversidade do corpus de treino, não a profundidade da arquitetura.
Se você está começando com javanês hoje, aqui estão as coisas que eu faria diferente se pudesse voltar no tempo. Primeiro, não tente construir seu próprio tokenizer. Use o stanza com o modelo javanês que eles lançaram em 2023, mesmo que ele tenha bugs com nomes próprios — pelo menos você parte de uma baseline que outras pessoas estão usando. Segundo, se precisar de dados paralelos, esqueça os datasets públicos e faça scraping ético de sites de notícias com permissão dos editores. A diferença entre 400 mil e 4 milhões de linhas é enorme em qualidade de embeddeds. Terceiro, aceite que a tradução para krama inggil vai ter erro morfológico em cerca de 15% dos casos mesmo com o melhor pipeline. Não existe solução perfeita para isso porque o problema é que não há falantes nativos fluentes em krama inggil escrevendo texto técnico — o registro morreu como variedade escrita ativa. O framework do homem que falava javanes, no fim das contas, é apenas um lembrete de que língua é problema humano primeiro e computacional segundo. A tecnologia resolve os problemas que a tecnologia consegue ver. O resto depende de quem sabe falar, escrever e escolher as palavras certas para cada situação — e isso ninguém consegue automatizar ainda.
