179 questions
No questions match those filters.
Why does naively chunking a table for RAG corrupt it, a...
This is one of the questions in the full AI/ML interview bank. Pro unlocks all 1789 questions; Premium includes the same bank plus the highest daily Practice limit.
See plansA table’s meaning lives in a two-dimensional structure — a cell’s value is only interpretable together with its row header and column header — but a standard text chunker operates on one-dimensional token streams and has no notion of “row” or “column” at all. Splitting a table by character or token count cuts through row and column boundaries arbitrarily, and even a chunker that respects row boundaries still loses the header context for any chunk that doesn’t happen to include it, so a cell value retrieved on its own (“42%”) is unusable without the row and column labels that gave it meaning. Naive linearization — flattening a table into a sentence like “row 1: name is X, value is Y” — avoids that specific problem but is verbose and still doesn’t give the model any structural signal about which tokens are headers versus data versus a specific row’s values.
Table-aware encoders like TAPAS solve this by adding extra positional embeddings on top of the standard token embeddings, specifically a row index and a column index for every token, alongside the usual sequence position — so the model can attend to “same column, different row” or “same row, different column” relationships directly through these learned positional signals, rather than having to infer table structure purely from linearized text order. This matters in practice because it’s what lets a model correctly answer a question like “what was the value in Q3 for the row above the total,” which depends on structural position, not just proximity in the flattened text.
The known failure mode this introduces is order sensitivity: because row and column indices are literal positions, a naive implementation can give inconsistent answers if the same table’s rows are reordered, since the model may have implicitly learned patterns tied to specific positions rather than pure structural relationships. That’s exactly the bias later table encoders like TableFormer were built to correct, by making the representation invariant to row and column permutation rather than sensitive to it.