Add custom labels to get topic tree

[clfkenny]

What does this PR do?

get_topic_tree function currently does not accept custom_labels as a parameter whereas the other visualization methods do. Therefore this change aims to fix that issue so custom labels can be accepted and make the visualization more intuitive.

I really enjoyed looking through the codebase here. My first PR here so still learning the project structure, would appreciate any feedback. Thanks!

Fixes # #2123

Before submitting

• This PR fixes a typo or improves the docs (if yes, ignore all other checks!).
• Did you read the contributor guideline?
• Was this discussed/approved via a Github issue? Please add a link to it if that's the case.
• Did you make sure to update the documentation with your changes (if applicable)?
• Did you write any new necessary tests?

[MaartenGr]

Thanks for the PR! The code looks solid and I left minor comments.

One other thing, would you mind expanding the tests at tests/test_variations/test_hierarchy (test_tree) a bit to include the custom_labels=True?

[MaartenGr]

Should we add a check for when a user attempts to use a specific aspect but it is not found in self.topic_aspects_? I can imagine that a user (myself included) would mistype the name and the resulting error might not be entirely clear.

[clfkenny]

This makes sense, I can add a check here. One thing I noticed when looking through how custom labels were handled in the plotting functions is that they all follow a pretty similar pattern:

BERTopic/bertopic/plotting/_topics.py

Line 67 in 510c15e

if isinstance(custom_labels, str):

BERTopic/bertopic/plotting/_heatmap.py

Line 99 in 510c15e

if isinstance(custom_labels, str):

BERTopic/bertopic/plotting/_datamap.py

Line 123 in 510c15e

if isinstance(custom_labels, str):

BERTopic/bertopic/plotting/_distribution.py

Line 62 in 510c15e

if isinstance(custom_labels, str):

BERTopic/bertopic/plotting/_documents.py

Line 139 in 510c15e

if isinstance(custom_labels, str):

Maybe a more generic and reusable function can be created for this, which would check if the user specified aspect exists in self.topic_aspects_

[MaartenGr]

You're right, it makes no sense to do that check here but not at all of those other instances. For now, I'm alright either way. I can imagine wanting to stick with what I already use everywhere else for consistency as this might be a bit out of the scope of this particular PR. So it's up to you.

[MaartenGr]

I just wanted to mention that I am going to steal that enumerate trick. That is so much nicer coding than how I have approached it thus far.

[MaartenGr]

Note that some topic aspects might not have 5 keywords but actually a single label. In those cases, the kws_info[0] is likely to be filled with a label (or even a summary) and each instance in kws_info[1:] will be an empty string. As a result, you might get the following label: "artificial intelligence____".