[WIP] [Draft] Autologging functionality for scikit-learn integration with XGBoost and LightGBM #4885

jwyyy · 2021-10-12T04:46:18Z

Signed-off-by: Junwen Yao, jwyiao@gmail.com.

What changes are proposed in this pull request?

This PR will enable autologging for XGBoost and LightGBM sklearn estimators. Resolves #4296.

(Part 1) autologging for XGBoost sklearn estimators.
(Part 2) working on autologging for LightGBM sklearn estimators.

How is this patch tested?

A short example is provided. Tests will be added later.

Release Notes

Is this a user-facing change?

No. You can skip the rest of this section.
Yes. Give a description of this change to be included in the release notes for MLflow users.

This PR will enable autologging for XGBoost (LightGBM) sklearn estimators using mlflow.xgboost.autolog() (mlflow.lightgbm.autolog()).

What component(s), interfaces, languages, and integrations does this PR affect?

Components

Interface

area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server
area/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Models
area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
area/windows: Windows support

Language

language/r: R APIs and clients
language/java: Java APIs and clients
language/new: Proposals for new client languages

Integrations

integrations/azure: Azure and Azure ML integrations
integrations/sagemaker: SageMaker integrations
integrations/databricks: Databricks integrations

How should the PR be classified in the release notes? Choose one:

rn/breaking-change - The PR will be mentioned in the "Breaking Changes" section
rn/none - No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" section
rn/feature - A new user-facing feature worth mentioning in the release notes
rn/bug-fix - A user-facing bug fix worth mentioning in the release notes
rn/documentation - A user-facing documentation change worth mentioning in the release notes

harupy · 2021-10-12T05:40:14Z

mlflow/sklearn/__init__.py

+        # copied from mlflow.xgboost
+        # link: https://github.com/mlflow/mlflow/blob/master/mlflow/xgboost.py#L392
+        # avoid cyclic import
+        def record_eval_results(eval_results, metrics_logger):


I think we should reorganize helper functions in xgboost.py to make it easier to reuse them from other modules.

I agree. It is better to move record_eval_results and log_feature_importance_plot into a new file but not in mlflow.xgboost. Otherwise, there would be a cyclic import issue. Do you have any idea where we should put them? Maybe a file in mlflow.utils?

Regarding the feature importance plot, XGBoost sklearn estimators provide normalized feature importance via property feature_importances_. The feature importance obtained from Booster.get_score() isn't normalized.

harupy · 2021-10-12T05:40:35Z

mlflow/sklearn/__init__.py

@@ -827,6 +839,8 @@ def autolog(
    silent=False,
    max_tuning_runs=5,
    log_post_training_metrics=True,
+    xgboost_estimator=False,
+    lightgbm_estimator=False,


Suggested change

lightgbm_estimator=False,

Can we address LightGBM in a separate PR?

That's no problem!

Rather than exposing xgboost_estimator in the top-level sklearn API, can we define a separate internal _autolog() API that contains this parameter and can be called by mlflow.sklearn.autolog() and mlflow.xboost.autolog()? This way, mlflow.sklearn.autolog() only has one behavior: enable autologging for scikit-learn estimators, and mlflow.xgboost.autolog() has one behavior: enable autologging for XGBoost estimators (and other types of XGBoost models).

Sure. This plan sounds good to me. I will revise the implementation accordingly. Thanks!

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy · 2021-10-12T18:28:47Z

Hi @dbczumar @harupy, thank you for your feedback! I have revised the implementation.

LightGBM placeholders are removed from this PR. Will make another one for it separately.
record_eval_results and log_feature_importance_plot are moved to mlflow.utils._xgboost_utils.
_autolog is added to mlflow.sklearn to separate autologging behaviors for xgboost and sklearn.
Add xgboost pip requirements to sklearn autologging when the estimator is from xgboost.sklearn.
Tested the autologging for sklearn and xgboost examples.
(sorry for messy commit history 😓 )

I'd like to hear your feedback on this new version. Thanks! 🙏

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

dbczumar · 2021-10-15T18:14:16Z

mlflow/xgboost.py

+    # save xgboost.sklearn estimators
+    if xgb_model.__module__ == "xgboost.sklearn":
+        import mlflow.sklearn
+        extra_xgboost_pip_requirements = get_default_pip_requirements()
+        if extra_pip_requirements:
+            extra_xgboost_pip_requirements += extra_pip_requirements
+        mlflow.sklearn.save_model(
+            sk_model=xgb_model,
+            path=path,
+            conda_env=conda_env,
+            mlflow_model=mlflow_model,
+            serialization_format=serialization_format,
+            signature=signature,
+            input_example=input_example,
+            pip_requirements=pip_requirements,
+            extra_pip_requirements=extra_xgboost_pip_requirements,
+        )
+        return


Fortunately, I don't think we need this logic since XGBoostRegressor and other XGBoost scikit-learn models have a save_model() method. We should be able to use the existing mlflow.xgboost.save_model() to save XGBoost scikit-learn estimators.

dbczumar · 2021-10-15T18:15:00Z

mlflow/xgboost.py

@@ -99,6 +101,7 @@ def save_model(
    conda_env=None,
    mlflow_model=None,
    signature: ModelSignature = None,
+    serialization_format: str = SERIALIZATION_FORMAT_CLOUDPICKLE,


I think we can drop this argument since XGBoost scikit-learn models can be saved using the same <xgboost_model>.save_model() API as other XGBoost models. (See https://github.com/mlflow/mlflow/pull/4885/files#r730028775). Instead, we should make some changes that allow XGBoost sklearn models to be loaded using mlfllow.xgboost.load_model() and used for inference via the pyfunc representation. See https://github.com/mlflow/mlflow/pull/4885/files#r730036638.

dbczumar · 2021-10-15T18:28:24Z

mlflow/xgboost.py

@@ -107,7 +110,7 @@ def save_model(
    Save an XGBoost model to a path on the local file system.

    :param xgb_model: XGBoost model (an instance of `xgboost.Booster`_) to be saved.
-                      Note that models that implement the `scikit-learn API`_  are not supported.


I think the reason we said this before is that we don't currently handle loading of XGBoost scikit-learn models correctly.

For example:

from pprint import pprint import pandas as pd import xgboost as xgb from sklearn.datasets import load_boston from sklearn.model_selection import train_test_split from sklearn.metrics import mean_squared_error import numpy as np import mlflow import mlflow.xgboost boston = load_boston() X = pd.DataFrame(boston.data, columns=boston.feature_names) y = pd.Series(boston.target) X_train, X_test, y_train, y_test = train_test_split(X, y) regressor = xgb.XGBRegressor( n_estimators=100, reg_lambda=1, gamma=0, max_depth=3 ) regressor.fit(X_train, y_train) print(type(regressor)) with mlflow.start_run(): x = mlflow.xgboost.log_model(regressor, "foo") uri = "runs:/" + mlflow.active_run().info.run_id + "/foo" loaded_model = mlflow.xgboost.load_model(uri) print(type(loaded_model))

This prints:

<class 'xgboost.sklearn.XGBRegressor'> <class 'xgboost.core.Booster'>

Which indicates that the XGBRegressor model is correctly saved in MLflow format but is incorrectly related as an xgboost.core.Booster object due to hardcoded logic here:

mlflow/mlflow/xgboost.py

Line 260 in 706758e

model = xgb.Booster()

.

Can we update the model flavor specification to include the model class name and then, when the model is loaded, instantiate an instance of the model class and call load_model(). This should provide full support for saving / loading XGBoost scikit-learn models.

The other part that we need to address is the pyfunc inference format for XGBoost models. Currently, pyfunc inference assumes that booster classes are being used and converts the input into an xgb.DMatrix object. Instead, for scikit-learn XGBoost models, we should pass the input directly through to the model without converting it to a DMatrix.

For this purpose, it may be useful to record an additional piece of flavor state indicating the model type: "xgboost" or "xgboost-sklearn".

This sounds good to me! We can address this issue in a separate PR. If necessary, I'd be happy to help.

For this purpose, it may be useful to record an additional piece of flavor state indicating the model type: "xgboost" or "xgboost-sklearn".

Can we just inspect the model type?

class _NewXGBModelWrapper: def __init__(self, xgb_model): self.xgb_model = xgb_model def predict(self, dataframe): import xgboost as xgb if isinstance(self.xgb_model, xgb.Booster): dataframe = xgb.DMatrix(dataframe) return self.xgb_model.predict(xgb.DMatrix(dataframe))

Can we patch log_model, save_model, load_model, and _load_pyfunc directly to loaded mlflow.sklearn in mlflow.xgboost? Then saving / loading model can be also handled by mlflow.xgboost without using sklearn functions.

dbczumar

@jwyyy Awesome work! I left some initial feedback about saving / loading / performing inference via pyfunc with XGBoost scikit-learn models. Mainly, I think we should expand mlflow.xgboost.save_model() to support XGBoost + scikit-learn without having to call mlflow.sklearn.save_model(), as proposed here: https://github.com/mlflow/mlflow/pull/4885/files#r730036638.

For modularity, it may be easier to break this part into a separate PR. Thank you so much for your contributions so far!

jwyyy · 2021-10-15T20:02:15Z

@dbczumar Thank you for your review and detailed feedback! I will address them in the next round of revision. Will comment more if I have questions.

For modularity, it may be easier to break this part into a separate PR. Thank you so much for your contributions so far!

Can you explain a little bit what is this part in the sentence above? Are you referring to xgboost flavor vs xgboost-sklearn flavor?

jwyyy · 2021-10-18T17:06:34Z

Hi @dbczumar, I studied your suggestions more over the weekend and have more thoughts to share.

I think we agreed that mlflow.sklearn autologging routine is used for logging XGBoost sklearn estimators. This logs model during training using mlflow.sklearn flavor (e.g. fit_mlflow() patched to the originalfit()). In particular, in _log_posttraining_metadata() , it is the mlflow.sklearn.log_model() that is called (L1285). When XGBoost sklearn estimator's fit() is patched, the estimator will be saved/logged as a sklearn estimator in mlflow.

This means that when we load it back, it should be loaded using mlflow.sklearn API to make everything consistent with what has been logged during the training. It also avoids DMatrix in inference, b/c predict() can take inputs without conversion (a xgboost.sklearn implementation).

However, this behavior is different from mlflow.xgboost.log_model() and .save_model() as you have shown in this example.

That is, mlflow.sklearn saves/logs models in mlflow.sklearn flavor, but mlflow.xgboost saves/logs models as Boosters. (This also explains why serialization_format was added.) Inconsistency can happen if users try to load model that was previously saved using mlflow.sklearn by xgboost.sklearn API.

Originally, the issue (the boston.txt example in #4296) was when XGBooost sklearn estimator is called with fit(), the training isn't autologged. (The official sklearn autologging example logs model automatically.) Explicitly calling mlflow.xgboost.log_model() not only logs model as Boosters but also is inconsistent with our proposal: using mlflow.sklearn to handle autologging. (Plus, it requires users to manually log training, and there can be early stopping parameters. They need to be checked and logged at each iteration.)

To make it uniform across all cases, we should decide whether

saving/loading models are all in mlflow.sklearn flavor in both mlflow.sklearn and mlflow.xgboost for XGBoost sklearn estimators; or
all in mlflow.xgboost flavor, i.e., using the provided load_model() and save_model() method in xgboost.sklearn.

For (1), we could update mlflow.xgboost.load_model() by adding new model flavor xgboost-sklearn as you suggested. But I think essentially we still need to utilize functions defined in mlflow.sklearn.

Thanks again for your feedback! Looking forward to hearing more discussions from you and @harupy .

dbczumar · 2021-10-19T21:30:22Z

Hi @dbczumar, I studied your suggestions more over the weekend and have more thoughts to share.

I think we agreed that mlflow.sklearn autologging routine is used for logging XGBoost sklearn estimators. This logs model during training using mlflow.sklearn flavor (e.g. fit_mlflow() patched to the originalfit()). In particular, in _log_posttraining_metadata() , it is the mlflow.sklearn.log_model() that is called (L1285). When XGBoost sklearn estimator's fit() is patched, the estimator will be saved/logged as a sklearn estimator in mlflow.

This means that when we load it back, it should be loaded using mlflow.sklearn API to make everything consistent with what has been logged during the training. It also avoids DMatrix in inference, b/c predict() can take inputs without conversion (a xgboost.sklearn implementation).

However, this behavior is different from mlflow.xgboost.log_model() and .save_model() as you have shown in this example.

That is, mlflow.sklearn saves/logs models in mlflow.sklearn flavor, but mlflow.xgboost saves/logs models as Boosters. (This also explains why serialization_format was added.) Inconsistency can happen if users try to load model that was previously saved using mlflow.sklearn by xgboost.sklearn API.

Originally, the issue (the boston.txt example in #4296) was when XGBooost sklearn estimator is called with fit(), the training isn't autologged. (The official sklearn autologging example logs model automatically.) Explicitly calling mlflow.xgboost.log_model() not only logs model as Boosters but also is inconsistent with our proposal: using mlflow.sklearn to handle autologging. (Plus, it requires users to manually log training, and there can be early stopping parameters. They need to be checked and logged at each iteration.)

To make it uniform across all cases, we should decide whether

saving/loading models are all in mlflow.sklearn flavor in both mlflow.sklearn and mlflow.xgboost for XGBoost sklearn estimators; or

all in mlflow.xgboost flavor, i.e., using the provided load_model() and save_model() method in xgboost.sklearn.

For (1), we could update mlflow.xgboost.load_model() by adding new model flavor xgboost-sklearn as you suggested. But I think essentially we still need to utilize functions defined in mlflow.sklearn.

Thanks again for your feedback! Looking forward to hearing more discussions from you and @harupy .

Hi @jwyyy, the mlflow.xgboost.autolog() routine should be used to trigger autologging for XGBoost scikit-learn estimators, but this should be handled by an internal method within the mlflow.sklearn module called mlflow.sklearn._autolog(). When mlflow.sklearn._autolog() sees that the model class comes from xgboost, it should call mlflow.xgboost.log_model() instead of mlflow.sklearn.log_model(), and mlflow.xgboost.load_model() / the XGBoost pyfunc representation should be extended to support XGBoost scikit-learn models, as described in https://github.com/mlflow/mlflow/pull/4885/files#r730036638.

Let me know if you have any questions here. Thank you for your contributions!

jwyyy · 2021-10-20T00:33:00Z

When mlflow.sklearn._autolog() sees that the model class comes from xgboost, it should call mlflow.xgboost.log_model() instead of mlflow.sklearn.log_model(), and mlflow.xgboost.load_model() / the XGBoost pyfunc representation should be extended to support XGBoost scikit-learn models.

Hi @dbczumar, thank you for your clarification! Now this internal behavior is clearer to me, and it makes a lot more sense. I will revise the implementation soon. Will let you know if other issues come up.

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy · 2021-10-20T18:15:53Z

Hi @dbczumar @harupy, I revised the implementation as per our discussion and made a new commit. Here is a summary of what have been changed:

mlflow.sklearn saving / loading are now dropped and directly patched by corresponding saving / loading functions in mlflow.xgboost. I didn't use safe_patch() since inside sklearn autologging routine, safe_patch() will be used to patch fit() anyway. Plus, the input arguments are not the same. This resolves the first issue: using mlflow.xgboost for both Booster and XGBoost sklearn estimators.
Regarding the model class specification, I chose to add a new module level variable MODEL_CLASS to mlflow.xgboost. This also avoids adding new model specific flavors. An extra flavor key-value, specifying what XGBoost slearn model is used, will be logged in MLmodel: (an example of new MLmodel file)

...
flavors:
  python_function:
    data: model.xgb
    env: conda.yaml
    loader_module: mlflow.xgboost
    python_version: 3.6.13
  xgboost:
    data: model.xgb
    model_class: XGBRegressor # new 
    xgb_version: 1.4.2
...

(When xgboost.train() is used, model_class is Booster.) When the model is loaded, MODEL_CLASS will be set to the model class it reads. It resolves the issue of hard saving / loading XGBoost models. Alternatively, we can ask users to specify model class. But I think it is better to have mlflow directly handle model class specification. For example, the user who uses a XGBoost model might not be the person who trained it. Manually setting model class requires end users to know which class was used before hand, making the process not very smart.

Since MODEL_CLASS is new, it should be correctly handled in mlflow.pyfunc.load_model(). A few lines were added to set MODEL_CLASS before calling module level _load_pyfunc(). The prediction part is implemented as @harupy suggested.
One drawback of this approach is once MODEL_CLASS is set, it should not be used to log other models. So if users want to log another XGBoost model, they need to create a new autologging routine. (I suppose this case is rare also.)

Please let me know if I missed anything. I'd like to hear more feedback and suggestions from you! Thanks!

jwyyy · 2021-10-21T01:52:39Z

mlflow/xgboost.py

+
+    # initialize autologging for XGBoost sklearn estimators
+    import mlflow.sklearn
+    _wrap_patch(mlflow.sklearn, "log_model", log_model)


Maybe we can use setattr() here?

dbczumar · 2021-10-22T05:38:00Z

Hi @jwyyy , apologies for the delay here. We're working to release MLflow 1.21.0. I'll make sure to provide thorough PR feedback within the next few days.

jwyyy · 2021-10-22T05:52:25Z

Hi @jwyyy , apologies for the delay here. We're working to release MLflow 1.21.0. I'll make sure to provide thorough PR feedback within the next few days.

Sure. That's no problem! Looking forward to the new release 👍 I will make changes accordingly once we have more discussion. Thanks in advance!

dbczumar · 2021-10-27T01:07:41Z

mlflow/xgboost.py

+    if MODEL_CLASS == "Booster":
+        model = xgb.Booster()
+    else:
+        model = getattr(xgb, MODEL_CLASS)()


Instead of using a global variable, which has the downside of limiting how many times users can load different models (like you mentioned), can we read the model_class attribute of the flavor specification from the MLflow Model?

I realize this is challenging for _load_pyfunc because the pyfunc model only gives us access to the XGBoost model path. This is because we pass the data keyword argument to pyfunc.add_to_model here:

mlflow/mlflow/xgboost.py

Line 159 in 40df337

data=model_data_subpath,

, which causes special logic to execute when loading a pyfunc model here:

mlflow/mlflow/pyfunc/__init__.py

Line 666 in 40df337

data_path = os.path.join(local_path, conf[DATA]) if (DATA in conf) else local_path

.

aa563fb demonstrates how we can safely stop adding the data keyword to mlflow.pyfunc.add_to_model while maintaining backwards compatibility with older models that were saved with the data field.

@jwyyy can we split this work into a separate PR?

dbczumar · 2021-10-27T01:10:19Z

mlflow/xgboost.py

+    _wrap_patch(mlflow.sklearn, "log_model", log_model)
+    _wrap_patch(mlflow.sklearn, "save_model", save_model)
+    _wrap_patch(mlflow.sklearn,
+                "get_default_pip_requirements",
+                get_default_pip_requirements)
+    _wrap_patch(mlflow.sklearn,
+                "get_default_conda_env",
+                get_default_conda_env)


Rather than patching methods from mlflow.sklearn, can we instead add logic inside of mlflow.sklearn._autolog() that checks the model class and calls mlflow.xgboost.log_model() if the model class comes from the XGBoost scikit-learn integration?

Perhaps we can work on this after addressing https://github.com/mlflow/mlflow/pull/4885/files#r737029226 as part of a separate PR.

One potential issue with this approach is cyclic import: To use sklearn autologging routine, we call import mlflow.sklearn inside mlflow.xgboost. To use mlflow.xgboost.log_model() inside mlflow.sklearn, we need to call import mlflow.xgboost insider mlflow.sklearn. It is not necessarily a problem, depending on how we implement it. But would it be a cleaner way to move mlflow.xgboost.log_model() and .save_model() to a util file?

I realized that cyclic import may not be a problem, since each import occurs only its enclosing function is called.

dbczumar · 2021-10-27T01:10:33Z

mlflow/xgboost.py

+        if isinstance(self.xgb_model, xgb.Booster):
+            return self.xgb_model.predict(xgb.DMatrix(dataframe))
+        else:
+            return self.xgb_model.predict(dataframe)


This looks awesome! Thanks @jwyyy!

dbczumar

@jwyyy Awesome progress! Thank you for your ongoing contribution! I've left a few more comments. Can we work on adding support for logging / loading XGBoost scikit-learn models via mlflow.xgboost in a separate PR for reviewability purposes?

jwyyy · 2021-10-27T01:42:10Z

@jwyyy Awesome progress! Thank you for your ongoing contribution! I've left a few more comments. Can we work on adding support for logging / loading XGBoost scikit-learn models via mlflow.xgboost in a separate PR for reviewability purposes?

@dbczumar Thanks for your feedback! I am working on the revision. Will let you know if there is any problem.

I can create separate PRs to address each small issue. But we can still leave this PR as a template / draft. Since adding sklearn autologging for LightGBM would be very similar, I think it is a good idea to keep this PR as roadmap.

jwyyy · 2022-01-14T23:25:51Z

Closing this PR, since #4296 is now resolved.

github-actions bot added area/examples Example code area/tracking Tracking service, tracking client APIs, autologging rn/feature Mention under Features in Changelogs. labels Oct 12, 2021

jwyyy marked this pull request as draft October 12, 2021 04:48

harupy reviewed Oct 12, 2021

View reviewed changes

jwyyy changed the title ~~[WIP] Autologging functionality for scikit-learn integration with XGBoost and LightGBM~~ [WIP] Autologging functionality for scikit-learn integration with XGBoost and LightGBM (Part 1) Oct 12, 2021

github-actions bot removed the rn/feature Mention under Features in Changelogs. label Oct 12, 2021

jwyyy added 7 commits October 12, 2021 09:50

init

a09cf92

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

xgboost sklearn

943f96c

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

xgboost sklearn

cb6de0a

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

sign-off

a3ff217

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

re sign-off

3bb5484

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

revise,xgboost only

cb7d288

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

pass args to sklearn _autolog

0a84115

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy force-pushed the autolog branch from bb90b43 to 0a84115 Compare October 12, 2021 16:51

jwyyy added 4 commits October 12, 2021 10:47

restore log imp, fix minor bugs

e851e36

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

update

7bbb1cd

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

update log_model with xgboost requirements

903c266

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

remove extra lightgbm arg

2c0c62e

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

github-actions bot added the rn/feature Mention under Features in Changelogs. label Oct 13, 2021

jwyyy added 2 commits October 13, 2021 08:53

update internal api names

cdb72ea

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

fix build_doc

d9a6d5d

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy requested review from harupy and dbczumar October 13, 2021 17:19

fix doc issues

050f5a5

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy marked this pull request as ready for review October 14, 2021 21:24

add doc for sklearn api

e697bba

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy mentioned this pull request Oct 15, 2021

[FR] Autologging functionality for scikit-learn integration with XGBoost (and LightGBM) #4296

Closed

dbczumar reviewed Oct 15, 2021

View reviewed changes

address review

c8e8e85

Signed-off-by: Junwen Yao <jwyiao@gmail.com>

jwyyy commented Oct 21, 2021

View reviewed changes

dbczumar reviewed Oct 27, 2021

View reviewed changes

jwyyy changed the title ~~[WIP] Autologging functionality for scikit-learn integration with XGBoost and LightGBM (Part 1)~~ [WIP] [Draft] Autologging functionality for scikit-learn integration with XGBoost and LightGBM Oct 27, 2021

jwyyy mentioned this pull request Oct 28, 2021

Autologging functionality for scikit-learn integration with XGBoost (Part 1) #4954

Merged

27 tasks

jwyyy mentioned this pull request Nov 12, 2021

Autologging functionality for scikit-learn integration with XGBoost (Part 2) #5055

Closed

29 tasks

jwyyy marked this pull request as draft November 12, 2021 02:00

jwyyy mentioned this pull request Nov 17, 2021

Autologging functionality for scikit-learn integration with XGBoost (Part 2) #5078

Merged

29 tasks

jwyyy mentioned this pull request Nov 30, 2021

Autologging functionality for scikit-learn integration with LightGBM (Part 1) #5130

Merged

28 tasks

jwyyy mentioned this pull request Dec 26, 2021

Autologging functionality for scikit-learn integration with LightGBM (Part 2) #5200

Merged

29 tasks

jwyyy closed this Jan 14, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] [Draft] Autologging functionality for scikit-learn integration with XGBoost and LightGBM #4885

[WIP] [Draft] Autologging functionality for scikit-learn integration with XGBoost and LightGBM #4885

jwyyy commented Oct 12, 2021 •

edited

harupy Oct 12, 2021

jwyyy Oct 12, 2021

harupy Oct 12, 2021 •

edited

jwyyy Oct 12, 2021

dbczumar Oct 12, 2021 •

edited

jwyyy Oct 12, 2021

jwyyy commented Oct 12, 2021 •

edited

dbczumar Oct 15, 2021

dbczumar Oct 15, 2021 •

edited

dbczumar Oct 15, 2021

dbczumar Oct 15, 2021 •

edited

harupy Oct 20, 2021 •

edited

harupy Oct 20, 2021

jwyyy Oct 20, 2021 •

edited

dbczumar left a comment

jwyyy commented Oct 15, 2021

jwyyy commented Oct 18, 2021

dbczumar commented Oct 19, 2021

jwyyy commented Oct 20, 2021

jwyyy commented Oct 20, 2021 •

edited

jwyyy Oct 21, 2021

dbczumar commented Oct 22, 2021

jwyyy commented Oct 22, 2021

dbczumar Oct 27, 2021 •

edited

dbczumar Oct 27, 2021

jwyyy Oct 27, 2021

jwyyy Oct 27, 2021

dbczumar Oct 27, 2021

dbczumar left a comment

jwyyy commented Oct 27, 2021

jwyyy commented Jan 14, 2022

[WIP] [Draft] Autologging functionality for scikit-learn integration with XGBoost and LightGBM #4885

[WIP] [Draft] Autologging functionality for scikit-learn integration with XGBoost and LightGBM #4885

Conversation

jwyyy commented Oct 12, 2021 • edited

What changes are proposed in this pull request?

How is this patch tested?

Release Notes

Is this a user-facing change?

What component(s), interfaces, languages, and integrations does this PR affect?

How should the PR be classified in the release notes? Choose one:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harupy Oct 12, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dbczumar Oct 12, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwyyy commented Oct 12, 2021 • edited

Choose a reason for hiding this comment

dbczumar Oct 15, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dbczumar Oct 15, 2021 • edited

Choose a reason for hiding this comment

harupy Oct 20, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwyyy Oct 20, 2021 • edited

Choose a reason for hiding this comment

dbczumar left a comment

Choose a reason for hiding this comment

jwyyy commented Oct 15, 2021

jwyyy commented Oct 18, 2021

dbczumar commented Oct 19, 2021

jwyyy commented Oct 20, 2021

jwyyy commented Oct 20, 2021 • edited

Choose a reason for hiding this comment

dbczumar commented Oct 22, 2021

jwyyy commented Oct 22, 2021

dbczumar Oct 27, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dbczumar left a comment

Choose a reason for hiding this comment

jwyyy commented Oct 27, 2021

jwyyy commented Jan 14, 2022

jwyyy commented Oct 12, 2021 •

edited

harupy Oct 12, 2021 •

edited

dbczumar Oct 12, 2021 •

edited

jwyyy commented Oct 12, 2021 •

edited

dbczumar Oct 15, 2021 •

edited

dbczumar Oct 15, 2021 •

edited

harupy Oct 20, 2021 •

edited

jwyyy Oct 20, 2021 •

edited

jwyyy commented Oct 20, 2021 •

edited

dbczumar Oct 27, 2021 •

edited