Clarification on high rejection rates with large single-cell dataset (~200k cells)

[martina811]

Hi,
I’m working on a large single-cell RNA-seq dataset consisting of approximately 200,000 cells and four distinct batches. I’ve been using kBET to evaluate batch correction after integration, but I consistently observe very high rejection rates (close to 1) and p-values near zero, regardless of whether I use cell type annotations or integration-derived clusters as the label vector.

Given the size of my dataset, I suspect this may be related to the sensitivity of kBET to large sample sizes, as noted in [Issue #80]

I’d really appreciate your guidance on the following:

1. Are there recommended parameter settings (e.g., adjusting k0, or other options) for running kBET on very large datasets?
2. Would you recommend downsampling the dataset to a smaller subset of cells (e.g., 10k or 20k), and if so, is there an optimal sample size to maintain statistical power without inflating rejection?

Thanks in advance for any help or clarification you can provide!

[mbuttner]

Hi @martina811
thanks for sharing your concern. For a dataset with 200,000 cells with several cell types, I assume that the dataset encompasses different conditions - the latter might introduce a shift, which you actually aim to observe.

1. I suggest to run kBET per cell type (or cluster if you haven't done any cell type calling, yet) and fix a smaller neighborhood size k0. I had some good experience with max. 75 neighbors. Depending on the cell type abundance, the k0 could be even smaller. As for the potentially different conditions, it might help to subset to the (biological) replicates in addition (assuming that 2 batches are 2 replicates of the same condition). To obtain a final kBET result, you can average the rejection rates from all cell types.
2. If 1. does not help, I think that you can try to subsample, but in my experience, computing kBET by cell type worked well for datasets up to 1M cells. It should work well above that number, too, but I haven't tested. The only restriction that I am aware of is that the FNN package with the maximum number of edges in a graph (which is 2^31, so computing a fully connected graph with 65k cells is a bad idea).

I hope that helps!