Xgboost: [Roteiro] Roteiro do XGBoost 1.0.0

Criado em 18 jul. 2019  ·  52Comentários  ·  Fonte: dmlc/xgboost

@ dmlc / xgboost-committer adicione seus itens aqui editando esta postagem. Vamos garantir que

  • cada item deve ser associado a um tíquete

  • design / refatoração principal são associados a um RFC antes de comprometer o código

  • problema de bloqueio deve ser marcado como bloqueio

  • alteração de interrupção deve ser marcada como interrupção

para outros contribuidores que não têm permissão para editar a postagem, por favor, comente aqui sobre o que você acha que deveria estar na versão 1.0.0

Eu criei três novos tipos de rótulos, 1.0.0, Blocking, Breaking

  • [x] Melhorar a experiência de instalação no Mac OSX (# 4477)
  • [x] Remova os objetivos antigos da GPU.
  • [x] Remover atualizador gpu_exact (obsoleto) # 4527
  • [x] Remover suporte multi gpu multiencadeado (obsoleto) # 4531
  • [x] Memória externa para gpu e refatoração dmatrix associada # 4357 # 4354
  • [] Melhoria de desempenho do Spark Checkpoint (https://github.com/dmlc/xgboost/issues/3946)
  • [x] [BLOQUEANDO] o mecanismo de sincronização no método hist no branch master é quebrado devido à forma inconsistente da árvore em diferentes workers (https://github.com/dmlc/xgboost/pull/4716, https: // github. com / dmlc / xgboost / issues / 4679)
  • [x] A sincronização por nó retarda o treinamento distribuído com 'hist' (# 4679)
  • [x] Testes de regressão incluindo compatibilidade binária de E / S, estabilidade de saída, regressões de desempenho.
roadmap

Comentários muito úteis

Não é um committer, mas podemos direcionar a API do PySpark para 1.0?
Problema: # 3370
PR atual: # 4656

Todos 52 comentários

Não é um committer, mas podemos direcionar a API do PySpark para 1.0?
Problema: # 3370
PR atual: # 4656

para outros contribuidores que não têm permissão para editar a postagem, por favor, comente aqui sobre o que você acha que deveria estar na versão 1.0.0

Além disso, devemos direcionar a mudança exclusivamente para o rastreador Rabit baseado em Scala (para Spark) em 1.0?

Eu também não sou um committer, mas eu e a empresa em que trabalho estamos muito interessados ​​em corrigir o problema de desempenho com pontos de verificação (ou pelo menos mitigá-lo) # 3946

@trams @thesuperzapper Acho que esta é uma visão geral para que todos tenham uma ideia do que está por vir. Seria difícil listar tudo o que vem, já que o XGBoost é um projeto conduzido pela comunidade. Basta abrir um PR quando estiver pronto.

Não é um committer, mas podemos direcionar a API do PySpark para 1.0?

@thesuperzapper Vamos acompanhar o progresso. Certamente espero poder começar a testá-lo. :-)

Há também a consideração secundária, que podemos não estar prontos para 1.0, e a API garante que vem com isso, por exemplo, poderíamos fazer 0.10.0 em seguida?

@thesuperzapper 1.0 não será uma versão final. Estamos apenas tentando fazer versões semânticas.

Adicionados alguns itens relacionados ao gpu.

gostaria de obter a correção xgb nativa incluída.
https://github.com/dmlc/xgboost/issues/4753

JSON é removido da lista. Consulte https://github.com/dmlc/xgboost/pull/4683#issuecomment -520485615

Eu levantei um problema para minha sugestão acima: # 4781 (para remover o rastreador Rabit python)

FeatureImportance na versão Spark também será ótimo (ou seja, facilmente terá o recurso Importance)
https://github.com/dmlc/xgboost/pull/988

Adicionado teste de regressão.

@chenqin , gostaria de ouvir de você sobre os testes de regressão, já que você tem experiência com gerenciamento de ML na produção. Alguma sugestão?

@chenqin , gostaria de ouvir de você sobre os testes de regressão, já que você tem experiência com gerenciamento de ML na produção. Alguma sugestão?

Acho que devemos cobrir o teste de regressão em várias cargas de trabalho e benchmark contra a precisão e estabilidade de predição (igual ou melhor) do que a versão anterior dentro do mesmo tempo aproximado. Dois candidatos em cima da minha cabeça são

https://archive.ics.uci.edu/ml/datasets/HIGGS

Dmatrix esparso
https://www.kaggle.com/c/ClaimPredictionChallenge

Podemos tentar vários métodos e configurações de árvore para garantir uma boa cobertura

tree_method, configurações / dataset / autônomo ou cluster

declamador:
Acho que vale a pena esclarecer um pouco.

  • A regressão de liberação não é algo que já fizemos na empresa em que trabalhei.
  • Os conjuntos de dados que propus são arbitrários e não podem ser usados ​​como referência para reivindicar uma estrutura melhor do que outra. (isso é muito preocupante quando eu vi benchmarks tendenciosos de vez em quando)

  • Na verdade, a essência de ajustar e descobrir recursos / configurações adequados sempre foi mais importante. Infelizmente, não podemos cobrir isso em testes de regressão.

O plano pode ser mais organizado é construir uma ferramenta de automação onde o usuário pode pegar e comparar várias configurações com seu conjunto de dados privado e modelo em seu próprio data center.

Devemos adicionar a fixação # 4779 como um requisito para enviar 1.0

Eu adicionei # 4899 como uma etapa de limpeza.

@ dmlc / xgboost-committer Visto que ainda temos algumas tarefas para a 1.0, talvez devêssemos fazer uma versão provisória 0.91?

@ hcho3 Ou talvez 0.10.0

@thesuperzapper Isso confundirá o sistema de versões. Não me importo com uma versão 0,91, mas ainda quero ver os procedimentos adequados para testes de regressão.

@trivialfis Se o mestre tem alterações de API, não deveríamos colidir com uma versão principal, que eu acho que seria igual a 0.100.0

@thesuperzapper A versão 1.0.0 é a primeira versão que adotaríamos o esquema de versão semântica, então não, a versão semântica não se aplicará ao lançamento provisório. É um pouco complicado, já que temos muito a fazer até o lançamento do 1.0.0.

Se quisermos um 0,91, devemos revisar todas as alterações e garantir que 0,91 seja um
atualização incremental com base em 0,90 e, como tal, não prejudicamos nosso roteiro de
1.0.0 mudando vários recursos para 0.9x ou qualquer outra versão

Minha sugestão seria o lançamento 1.0.0.preview.1, algum outro projeto também
faz isso antes de um grande lançamento

No sábado, 5 de outubro de 2019 às 10:19 Philip Hyunsu Cho [email protected]
escreveu:

@thesuperzapper https://github.com/thesuperzapper A versão 1.0.0 é
a primeira versão adotaríamos o esquema de controle de versão semântico, portanto, não,
o controle de versão semântico não se aplica ao lançamento provisório.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6GBEQSXJKFW6QDPN53QNDEALA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANXH7Q#issuecomment-538670078 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAFFQ6BYMDES3537PDMGE5DQNDEALANCNFSM4IE5CQGA
.

@CodingCat 1.0.0.preview.1 é uma sugestão interessante. O Maven aceita esta versão?

sim, você pode ter letras não numéricas no número da versão

No sábado, 5 de outubro de 2019 às 11h11 Philip Hyunsu Cho [email protected]
escreveu:

@CodingCat https://github.com/CodingCat 1.0.0.preview.1 é um
sugestão interessante. O Maven aceita esta versão?

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6H64Y75JBSSDRVYIS3QNDKFNA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANYPSQ#issuecomment-538675146 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAFFQ6BHKVVMQIDMRPY4DSTQNDKFNANCNFSM4IE5CQGA
.

Uma versão provisória é uma boa ideia, há muitas melhorias desde a 0.9.

Entendi, vou fazer algumas canalizações no sistema de CI nos próximos dias e, em seguida, preparar a versão 1.0.0.preview.1.

@CodingCat Que tal 0,100 ou 0,95? "Preview" parece que a versão 1.0.0 está chegando, mas temos alguns recursos principais (PySpark) em jogo.

Suporta peso xgboost?

Não estou preocupado com a impressão de 1.0.0 para os usuários

A prévia do Spark 3.0 será lançada neste mês, mas o lançamento formal é o próximo
Abril (próximo ao cume da centelha), talvez

Na terça, 8 de outubro de 2019 às 11h41 Philip Hyunsu Cho [email protected]
escreveu:

@CodingCat https://github.com/CodingCat Que tal 0,100 ou 0,95?
"Preview" parece que a versão 1.0.0 está chegando, mas nós
tem alguns recursos principais (PySpark) na linha.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6AOGIWIB6W6TW3R5W3QNTH6TA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAVF7MA#issuecomment-539647920 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAFFQ6HF52HBR7ZNSKLIY3TQNTH6TANCNFSM4IE5CQGA
.

@CodingCat, pelo menos do ponto de vista do xgboost4j-spark, essa visualização 1.0.0 não será útil para a maioria das pessoas, já que quase ninguém está executando o Spark no 2.12. Além disso, você não pode obter facilmente um binário compilado, pois https://spark.apache.org/downloads.html não distribui versões compiladas do Spark para 2.12 com os binários do Hadoop incluídos.

Então não devemos liberar nada?

Na quinta-feira, 10 de outubro de 2019 às 22h05 Mathew Wicks [email protected]
escreveu:

@CodingCat https://github.com/CodingCat pelo menos do ponto de vista
de xgboost4j-spark, essa visualização 1.0.0 não será útil para a maioria das pessoas, pois
quase ninguém está executando o Spark no 2.12. Além disso, você não pode obter facilmente
um binário compilado como https://spark.apache.org/downloads.html não
distribuir versões compiladas do Spark para 2.12 com os binários do Hadoop
incluído.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6AN3FJQ7ZE7EOTXLW3QOACSFA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA6ZM2Q#issuecomment-540907114 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAFFQ6EJRRMTNY7R7JVALTDQOACSFANCNFSM4IE5CQGA
.

@CodingCat @thesuperzapper Achei que o nº 4574 permitiria a compilação do XGBoost com Scala 2.11 e 2.12. Nesse caso, devemos compilar o XGBoost com 2.11 e fazer o upload do JAR para o Maven.

Removido:

  • [] Libere a memória Gpu após o treinamento # 4668

Não acho que possamos chegar lá agora.

@thesuperzapper Será mais fácil desenvolver no branch master do Apache Spark (3.0) e no Scala 2.12 depois que o Spark lançar uma prévia do 3.0 (disponível em breve). Eu esperaria uma mudança muito maior para Scala 2.12 na comunidade Spark após a versão 3.0 final (prevista para o início de 2020), mas você está certo de que não há uma tonelada de uso de 2.12 agora. Criei https://github.com/dmlc/xgboost/issues/4926 para solicitar uma discussão sobre o próximo lançamento do Spark.

@CodingCat @thesuperzapper Achei que o nº 4574 permitiria a compilação do XGBoost com Scala 2.11 e 2.12. Nesse caso, devemos compilar o XGBoost com 2.11 e fazer o upload do JAR para o Maven.

4574 não permite a compilação cruzada.

O que permite é que alguém verifique o código, substitua manualmente a versão do scala e recompile

Então, alguém pode compilar um jar com 2.11 e fazer o upload para o Maven
Eu tinha uma solicitação de pull com migração para SBT que permitiria a compilação cruzada
Eu também sei o truque para suportar uma compilação cruzada no Maven (nós o usamos em nossa empresa). Eu posso compartilhar se você estiver interessado

@ hcho3 É possível usar o CPack para facilitar a instalação para OSX? Ignore este comentário se não for possível.

Suporta aprendizagem multi-objetivo?

@douglasren Infelizmente não. Você poderia começar um novo problema para que possamos discuti-lo? O termo "multi-objetivo" pode variar dependendo dos contextos, como uma função objetivo para vários resultados, vários objetivos com um único produto ou vários objetivos com vários produtos.

Eu gostaria de lançar meu voto para uma versão provisória também.

5146 corrige # 4477.

Removido:

  • [] Suporte à API PySpark (https://github.com/dmlc/xgboost/issues/3370) (https://github.com/dmlc/xgboost/pull/4656).

Uma versão provisória seria ótimo, pois a instalação do macOS ainda é uma dor no momento

Podemos obter suporte documentado para aprender a classificar (em pares) com o XGBoost4J-Spark? Atualmente, não existe uma solução concreta para especificar os dados de treinamento. Há alguma confusão em torno do particionamento por groupID e dos dados de treinamento que precisam seguir a mesma estratégia de partição, mas é muito vago.
Um exemplo ou documentação clara seria realmente útil!

Também gostaria de votar em uma versão provisória. Estamos ansiosos para a próxima versão principalmente para a correção do valor ausente por @cpfarrell (consulte https://github.com/dmlc/xgboost/pull/4805).

Existe uma estimativa de tempo relacionada ao próximo lançamento (principal ou provisório)?

PS: @thesuperzapper estamos usando 2.11 e 2.12 e uma versão provisória seria extremamente útil para nós

@ hcho3 Podemos criar um branch de lançamento e ter uma semana ou mais para testes?

Sim!

@ hcho3 Além de um branch, também podemos fazer um candidato a lançamento oficial nos lançamentos do GitHub para que a comunidade possa ter mais confiança para testá-lo também.

Isso parece incrível! Estou realmente ansioso para o próximo lançamento. Deixe-me saber se podemos ajudar. Definitivamente vamos testá-lo no Yelp.

Cortarei um novo branch release_1.0.0 depois que https://github.com/dmlc/xgboost/pull/5248 for mesclado. Obrigado a todos pela paciência.

O candidato a lançamento já está disponível para Python: https://github.com/dmlc/xgboost/issues/5253. Você pode experimentar hoje executando

pip3 install xgboost==1.0.0rc1

1.0.0 foi lançado:

pip3 install xgboost==1.0.0
Esta página foi útil?
0 / 5 - 0 avaliações