BatchFeature.to() supports non-tensor keys

[Rocketknight1]

This PR fixes a bug in the preprocessing for several pipelines. The pipelines were calling .to() on a BatchFeature which had a string feature, which caused an error. This update was also requested internally in Slack!

cc @ydshieh

[ydshieh]

Thank you @Rocketknight1 .

2 questions:

• Is this the only one to change? I see 3 failed tests (in torch pipeline CI reports).
• Do you think it makes sense to have this implemented directly in BatchFeature instead of outside it?

[Rocketknight1]

@ydshieh good spot, I fixed it for all three! We could consider rewriting BatchFeature.to() like you suggested though, let me ask people

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[Rocketknight1]

cc @ydshieh I changed the PR to update BatchFeature.to() instead, which means the individual pipeline fixes aren't needed anymore

[Rocketknight1]

cc @ArthurZucker for core maintainer review! This PR is simple: It patches BatchFeature.to() to check that its keys are tensors before it calls .to() on them. This means that BatchFeature.to() works even with string keys now, which used to throw an error.

[LysandreJik]

Thanks @Rocketknight1!

[LysandreJik]

Are there other areas that should be updated? Arthur tells me about Pixtral as an example

[Rocketknight1]

@LysandreJik I checked the codebase for methods overriding to(). Mostly this was in modeling code to create objects like NestedTensor - these are safe because their contents should always be torch.Tensor.

The exceptions were:

• Pixtral
• BatchEncoding (the tokenizer output class)

In both cases, I updated their methods to make sure they only call to() on torch.Tensor!

[LysandreJik]

perfect, thanks!