if your corpus has tables in it, how did you build the eval set

Everyone here evaluates retrieval. Almost every eval set I've seen described is built from documents: pick passages, write questions, check what comes back. When the corpus is mixed and part of it is tables, I have not seen anyone say how they built the table half of the eval, and I suspect the answer is mostly that they didn't and table performance is hiding inside an average.

The specific difficulty. To write a question against a table you have to know what the table means. If you knew what all your tables meant you would not have most of the problem you're trying to evaluate. So the eval set gets written against the tables somebody understood, which are the well-named, well-documented ones, which are exactly the ones retrieval already handles.

That leaves the ugly half of the corpus untested, and the ugly half is where the failures are: system exports with columns called V1 through V57, four-character codes from something decommissioned years ago, two tables with near-identical headers and totally unrelated contents.

So, honestly:

Happy to describe what we do and where it stops working. It stops working in a place I can name.