Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Novo Ranking de Conteúdos e Score de forma Persistente #655

Closed
filipedeschamps opened this issue Aug 18, 2022 · 7 comments
Closed

Novo Ranking de Conteúdos e Score de forma Persistente #655

filipedeschamps opened this issue Aug 18, 2022 · 7 comments
Labels
back Envolve modificações no backend front Envolve modificações no frontend

Comments

@filipedeschamps
Copy link
Owner

filipedeschamps commented Aug 18, 2022

Contexto

Hoje o algoritmo que define a ordem das publicações e comentários é calculado de forma dinâmica a cada requisição e usa uma regra inspirada no algoritmo do Hacker News e Reddit. Não é uma regra difícil de entender, mas é uma regra dinâmica que acaba ficando difícil de prever o comportamento, fora que hoje não estamos salvando um score de forma permanente no objeto de content e isso traz algumas dificuldades de ordenação na hora de considerar publicações que ultrapassam a paginação.

Com isso, o @aprendendofelipe sugeriu uma nova mecânica que inclusive leva em consideração um histórico do usuário. Ontem tive uma conversa fantástica com ele e que ficou visível todos os benefícios de se usar uma mecânica assim e para várias situações, até para quando o que acontece se a pessoa deletar publicações que estavam positivadas ou negativadas, pois isso já aconteceu no passado, aconteceu recentemente e vai continuar acontecendo.

Execução


[Deprecated]

Sugiro dividir a execução disso em duas Fases:

Primeira fase

Dado a uma condição complexa, eu sempre acho mais proveitoso separar em passos, e para esse primeiro passo, sugiro que duas coisas sejam feitas:

  1. Utilizar uma versão inicial* do algoritmo do @aprendendofelipe e persistir um score dentro do content.
  2. Criar nova strategy chamada relevant que ordena as publicações por esse score.
  3. Nessa nova estratégia, é importante ter uma nota de corte de inicialmente 1 tabcoin.

*O que seria uma versão inicial? Eu não sei, minha única preocupação é entender como e quando vamos atualizar esse score no banco de dados e o quão pesado é calcular ele e persistir isso. Então talvez sugiro não analisar o histórico ou definir uma reputação do usuário se isso pesar muito e só levar em consideração as tabcoins e tempo, como no algoritmo atual, mas usando a estratégia do @aprendendofelipe com steps que fica muito mais previsível.

Nessa primeira fase, o mais importante na verdade é ter um score persistente e ter uma nota de corte, pois é isso que mais precisaremos para estarmos prontos para o ruído de conteúdos que o lançamento possa trazer. Passando essa lombada inicial, podemos nos focar em ficar lapidando o algoritmo com estratégias mais complexas e essa parte quanto mais tempo e mais bem feita for, maior será a capacidade do TabNews de se tornar um ecossistema saudável e conseguir atender a regra de "tudo que você ler dentro do TabNews, vai ter valido a pena". Chegar nesse ponto e se manter nisso é algo fundamental para o TabNews funcionar em alta escala.

Segunda fase

Então para conseguir se manter nesse ponto, com a infraestrutura anterior rodando em produção, podemos ficar iterando infinitamente em algoritmos mais complexos, inclusive usando estratégias de cache para que, independente do custo de calcular um score, o retorno da lista de conteúdos seja instantânea. Ou até separar onde é feito o cálculo e persistência, do retorno da lista.

Em paralelo, isso envolve um ponto que o @aprendendofelipe falou na conversa que tivemos, que é o usuário, dado o seu histórico de contribuição, saber qual a sua reputação, porque isso vai ser usado como multiplicador nas publicações seguintes. Antecipei que morro de medo de ter mais um ativo na economia, assim como lutei o máximo que pude contra o TabCash, mas continuei pensando no que ele falou e de fato, para uma UX boa, a pessoa precisa ver a reputação dela em um único número fácil de entender.

De qualquer forma, sugiro continuarmos as conversas antes de implementar qualquer coisa sobre isso, por isso sugeri separar em duas fases 🤝

@filipedeschamps filipedeschamps added front Envolve modificações no frontend back Envolve modificações no backend labels Aug 18, 2022
@filipedeschamps
Copy link
Owner Author

Fechado por #748

@filipedeschamps
Copy link
Owner Author

@aprendendofelipe vou puxar para cá a conversa sobre o algoritmo para não correr o risco da conversa ser fragmentada por múltiplos PRs.

Queria puxar principalmente a minha preocupação apontada nesse comentário sobre conteúdo stale na Home. O print abaixo é da última versão publicada pelo PR #750, onde o primeiro item teoricamente já estaria na primeira posição por 4 dias:

image

Não sei se isso é saudável, dado que um conteúdo assim, mesmo não recebendo novas qualificações positivas, continuará ocupando o primeiro lugar caso algum outro conteúdo não ocupe. Então eu especulo que para alguém que acessa diariamente o TabNews, ter a probabilidade de um mesmo item nessa posição por 7 dias ficará cansativo.

Por isso da minha sugestão das primeiras janelas serem mais dinâmicas 🤝

@filipedeschamps
Copy link
Owner Author

Trazendo um pouco mais de contexto, print de agora:

image

Para quem acessa diariamente o TabNews, os itens 1, 2 e 3 são menos relevantes que os itens 4, 5, 6 e 7 👍

@aprendendofelipe
Copy link
Collaborator

Concordo sobre o stale.... Na equação anterior também tem esse efeito, mas provavelmente teria que ter um número absurdo de TabCoins para isso acontecer. A vantagem é que agora nós escolhemos os números.

Vamos ajustar...

@filipedeschamps
Copy link
Owner Author

Na equação anterior também tem esse efeito, mas provavelmente teria que ter um número absurdo de TabCoins para isso acontecer.

Correto! Um detalhe é que para o stale acontecer, a cada momento que se passasse, o item precisaria ganhar mais qualificações positivas para conseguir vencer a batalha da gravidade 🤝

@aprendendofelipe
Copy link
Collaborator

Pode parecer, mas não era a gravidade que retirava da primeira página os conteúdos antigos bem pontuados. Era o fato de só aparecer na primeira página os 30 conteúdos mais recentes, independentemente da pontuação.

Correto! Um detalhe é que para o stale acontecer, a cada momento que se passasse, o item precisaria ganhar mais qualificações positivas para conseguir vencer a batalha da gravidade 🤝

Sim e isso de fato já estaria acontecendo se não fosse o que citei acima, pois a influência do tempo diminui exponencialmente, então bastaria esse conteúdo que chegou no topo continuar recebendo poucas qualificações positivas que ele ficaria para sempre no topo. Lembra que lhe alertei sobre isso? Esse é um dos problemas de utilizar puramente aquela equação. Também não tinha limite de conteúdos que poderiam ficar stale. Que teria que dar um boost inicial cada vez maior, etc...

Agora estamos bem melhor... Está nas nossas mãos controlar o que deve ocorrer com os conteúdos que fugirem da curva normal. Só precisamos escolher bem:

  1. Quantos conteúdos daremos destaque;
  2. Qual é a quantidade mínima de TabCoins (ou Score) que ele precisa para ser considerado um destaque;
  3. Qual é a idade máxima do conteúdo para poder aparecer como destaque;
  4. Em que posição colocaremos esses destaques na lista de conteúdos.

Tentei responder essas questões para reproduzir um efeito parecido com o que a equação já fazia. Mas já temos melhorias, pois agora, mesmo numa semana de vários conteúdos top, só um ficará no topo. E nos últimos 2 dias, só 2 ou 3 ficarão por lá. E nunca que um conteúdo de mais de uma semana ficará no topo. Mas, por outro lado, não temos o limite de 30 conteúdos mais recentes, então fica mais claro que a equação estava longe do ideal.

@filipedeschamps
Copy link
Owner Author

filipedeschamps commented Oct 2, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
back Envolve modificações no backend front Envolve modificações no frontend
Projects
None yet
Development

No branches or pull requests

2 participants