JOYN GROUP

Escrito por: Eduardo Poças

Algoritmos para gestão do trabalho dos revisores!

Definition, Algorithm: Word used by programmers when they do not want to explain what they did.

Após um período inicial de testes sobre a V2, foi decidido implementar alguns algoritmos que decidam quais as perguntas que devem ser apresentadas aos revisores. Este algoritmo, para já bastante simples, será a base que permitirá vir a ter algoritmos mais complexos de machine learning para apoiar a revisão humana. Vamos tentar explicar em traços gerais a aproximação efetuada e lançar as bases para partilhar a visão de onde pretendemos chegar.

O problema com que nos deparámos nos testes à V2 manifestava-se na quantidade de trabalho redundante que estava a ser apresentado aos revisores e consequente redução na produtividade dos mesmos. A mesma pergunta era respondida por vários revisores mesmo quando o sistema já deveria ter chegado a uma conclusão.

Para resolver estas situações desenvolvemos um conjunto de algoritmos que têm por base as seguintes premissas:
equiparar conceptualmente uma resposta dada pelo motor de machine learning a resposta dada por um revisor;
as perguntas que são abertas para resolver uma questão deverão ter em conta o tempo médio que um revisor demora a responder, dito de outra forma, o sistema deverá prioritizar perguntas de “sim/não" em detrimento de perguntas de “input" sempre que tal seja possível;
as decisões de abrir e fechar perguntas ou avançar no processo deverão ser ancoradas em sistemas de pontuação que sejam facilmente configuráveis, auditáveis e alteráveis no futuro – este ponto é o que permitirá futuramente levantar os algoritmos mais complexos de gestão do trabalho dos revisores;

O algoritmo que implementámos pode ser descrito da seguinte forma:
Cada tarefa que tem de ser feita terá de ultrapassar uma pontuação de 100 valores num de três vetores: positivo, negativo ou rejeição; podemos ver estes vetores como frascos que se vão enchendo consoante o machine learning ou os revisores vão entregando as suas respostas;

Quando aparece um campo do qual pretendemos extrair o valor (por exemplo o nome de um cartão de cidadão) o sistema vai arrancar com todos os frascos vazios e depois pedir sugestões ao motor de machine learning;

Cada sugestão vai gerar mais um par de frascos (positivo / negativo) que serão geridos autonomamente e que se iniciam com um valor base por terem sido criados pelo motor de machine learning, a partir daí começam a aparecer perguntas de sim/não aos revisores para eles confirmarem ou desmentirem a sugestão dada pelo machine learning;
Uma de duas coisas poderá acontecer, ou as respostas dos revisores e respetiva pontuação “enchem o frasco" positivo, nesse caso a sugestão é dada como sendo a resposta correta e o valor é promovido a anotação; ou as respostas dos revisores “enchem o frasco" negativo, nesse caso a sugestão é descartada;

Se o sistema ficar sem sugestões para o campo irá usar a sua arma mais poderosa – mas também mais dispendiosa : a pergunta de
input; uma resposta dada a esta pergunta irá entrar no sistema como sendo uma sugestão – tal e qual as sugestões do machine learning – mas com uma pontuação base muito superior – ou seja, “enche" muito mais o “frasco" positivo do que as sugestões do machine learning;

É neste ponto também que um campo pode ser rejeitado – por exemplo se tiver o valor ilegível – isto acontece quando os revisores respondem “don’t know" o que faz encher o terceiro frasco, o da rejeição;

Além disto, para garantir que reduzimos respostas desnecessárias e até duplicadas, implementámos também uma fila de trabalho dinâmica com entregas geridas por “semáforos" que garantem que a mesma pergunta não pode ser respondida ao mesmo tempo por dois revisores diferentes.

Para entender melhor este conceito, imaginem que os revisores estão no centro de um estádio e que num raio de 10 metros à volta deles existem várias cabines de voto individuais; cada um deles irá dirigir-se a uma cabine e responder à questão que lá estiver – sim/não, input, picking, etc. – e sair da cabine, dirigindo-se à próxima; quando um revisor sai de uma cabine a porta muda de cor e fica trancada para indicar que está suja e que enquanto o sistema não a limpar nenhum outro revisor pode usar aquela cabine, além disso a resposta dele vai contribuir para encher um dos frascos que indiquei anteriormente; ao mesmo tempo o sistema está continuamente a olhar para as várias cabines e a perceber se precisa de fazer aparecer mais cabines – quando entram novos documentos; se pode fazer desaparecer outras cabines – porque as respostas dadas já fizeram encher um dos frascos positivos, negativos ou de rejeição; ou se tem de limpar e destrancar a porta de outras cabines para obter mais votos. Quando já não há cabines de voto é quando alcançamos o tão desejado “No work to do“!

É este bailado dos revisores que vai fechando as cabines de voto e alimentando o sistema com revisões para devolver resultados aos nossos clientes.

Mas como sabemos se os revisores estão a acertar ou a falhar as respostas?

Para responder a isto implementámos uma ligeira nuance nas pontuações dos revisores – o valor para o qual um revisor contribui para encher um frasco – e decidimos que, de vez em quando, em vez de atribuir a pontuação completa, vamos dar apenas uma parcela da revisão; isto vai causar a que sejam necessárias mais respostas de diferentes revisores para encher os frascos.
No final, vamos comparar as questões dadas pelos revisores com as conclusões a que o sistema chegou e vamos considerar que uma resposta foi correta quando idêntica à conclusão e incorrecta caso contrário.

Futuramente iremos alterar de forma dinâmica a pontuação com que cada revisor irá contribuir para as respostas, iremos ter em conta o histórico e a evolução do próprio revisor para fazer subir ou descer a respetiva contribuição; com isto até podemos ter revisores “especialistas" em dados campos cujas respostas são tidas como certas. De notar que a atribuição das cabines de voto aos revisores também poderá ter em conta o seu nível de especialização, dando primazia ao aparecimento de questões de sim/não aos revisores especialistas ou que raramente falhem num dado campo em alternativa a revisores mais genéricos.
Com estes modelo, também poderemos vir a medir a evolução da taxa de acerto de um revisor em janelas temporais e adequar as questões que vamos colocando ao mesmo de acordo com a evolução do mesmo; o sistema poderá, por exemplo, decidir que o revisor A consegue responder a 30 perguntas de sim/não do nome do cartão de cidadão seguidas mas que o revisor B apenas deverá responder a 10.

O nome do jogo passará a ser a escolha da próxima “cabine de voto" na qual o revisor terá de entrar para entregarmos as anotações com o menor esforço humano possível e com a maior qualidade desejada.

São desafios emocionantes que nos esperam mas para os quais temos a equipa ideal para lhes dar resposta!