skip to content

In RAGFlow, how do the Table and Q&A chunk methods treat a spreadsheet differently?

level: middleimportance: should knowfreq 48%

answer

  1. both make a row the unit
  2. first row is the header, for one of them
  3. one is asymmetric: query side vs payload
  4. tab separates the pair in text files
  5. descriptive column names get embedded

basics

~20 s

Table treats the first row as field names and turns every data row into one chunk carrying those field names with its values. Q&A expects a question column followed by an answer column and turns each pair into one chunk whose question is what a user query matches.

solid answer

~50 s

Both templates make a row the unit of retrieval, but they assume different semantics. **Table** is for tabular data: the header row supplies the field names, and each subsequent row becomes a chunk in which the values are carried together with their column names, so a retrieved chunk reads as a self-describing record rather than a bare tuple. Descriptive, human-readable column headers therefore matter a lot — they are part of what gets embedded. **Q&A** is for curated FAQ content: the sheet has a question column preceding an answer column, and each row becomes one chunk where the question side is the retrieval surface and the answer is the payload the model grounds on. In delimited text files, the question and answer are separated by a tab. Choosing Q&A for arbitrary tabular data is the common mistake: the first column is not a question, so retrieval matches against something that was never meant to be a query.

code

python · 10 lines
python
import csv

rows = [
    ("How do I reset my password?", "Open Settings, choose Security, then Reset password."),
    ("What is the refund window?", "Refunds are accepted within 30 days of purchase."),
]

with open("faq.txt", "w", newline="", encoding="utf-8") as fh:
    writer = csv.writer(fh, delimiter="\t")
    writer.writerows(rows)

go deeper

for a junior

Know that both templates make one row into one chunk, that Table uses the first row as field names, and that Q&A expects a question column before an answer column.

for a middle

Explain the asymmetry: in Q&A the question side is what a user query matches and the answer is the payload, while in Table the whole labelled record is the retrieval surface.

for a senior

Bring the file-hygiene and tuning consequences: one header row, descriptive column names, thousands of tiny near-identical chunks changing how top-N and thresholds behave.

for a principal

Be ready to say when retrieval is the wrong tool at all — aggregate and filtered queries over structured data belong in a query engine, not in a row-per-chunk vector index.

## Why RAGFlow has two row-oriented templates A spreadsheet is not one kind of content. Sometimes it is *data* — a price list, an inventory, a parts catalogue — where each row is a record and the columns are attributes. Sometimes it is *curated knowledge* — an FAQ export, a support macro library, a policy Q&A — where each row is already a question paired with its answer. RAGFlow gives these different chunk methods because the right retrieval surface differs: for data, the whole record should be matchable; for an FAQ, the question is the thing a user's query resembles and the answer is what should be returned. ## The Table method With `Table`, the first row of the file is interpreted as the header, and each data row becomes one chunk. Crucially, the chunk is not just the values — the field names travel with them, so the chunk reads as "field: value" pairs rather than a comma-separated tuple. That is what makes a retrieved row interpretable by the LLM without also retrieving the header row separately. The operational consequences: - **Header quality is content quality.** Columns named `col1`, `q3_r`, or `amt` produce chunks that embed badly and read badly. Rename them to descriptive phrases before ingestion — `Quarterly revenue in USD` embeds meaningfully, `q3_r` does not. - **One row per chunk means small chunks.** A 5,000-row sheet yields 5,000 tiny chunks. Similarity search over very short, near-identical texts is weak because rows differ in only a few tokens, so top-N and thresholds usually need adjusting for this kind of knowledge base. - **Aggregate questions are out of scope.** "What was total revenue?" cannot be answered by retrieving rows, because no row contains the total. Row-per-chunk indexing supports lookup and filtering, not arithmetic over the corpus. If aggregation is the requirement, a database query is the right tool and RAG is the wrong one. ## The Q&A method With `Q&A`, the file supplies question-answer pairs and each pair becomes a chunk. In a spreadsheet, the question column comes first and the answer column second. In a delimited text file, a tab separates the question from its answer on the line. The asymmetry is the point: the question text is what a user query is compared against, and the answer text is what the assistant grounds its response on. This is unusually effective when it fits, because it removes the hardest part of retrieval quality — the mismatch between how users phrase questions and how documentation phrases statements. An FAQ corpus already contains the query-shaped text. It is correspondingly brittle when misapplied: feed it a data table and the "question" side is a product code or a name, so semantic matching degrades to string similarity on identifiers. ## Choosing between them, and the third option Ask what a user will type. If the query will look like one of the rows' first column, `Q&A` is right. If the query will describe attributes of a record — "which parts are rated above 200V" — `Table` is right. If the spreadsheet is really a document that happens to be in a grid (long prose in cells, merged headers, multiple logical tables on one sheet), neither row-oriented template fits well and `General` with layout recognition may produce better chunks, or the data should be reshaped before upload. ## Preparing the file Row-oriented templates put the burden on file hygiene, and this is where most real deployments lose quality: - Exactly one header row, at the top, with no title banner above it and no merged cells. - One logical table per sheet; a second table starting halfway down will be read as data rows of the first. - Descriptive headers, spelled as words. - For Q&A files, no stray blank rows and no multi-line answers that break the tab-separated structure in text files. ## Verifying After parsing, open the document's chunk list and read a handful of chunks. For `Table`, each chunk should read as a labelled record; if you see values without their field names, the header row was not where RAGFlow expected it. For `Q&A`, each chunk should pair a plausible question with its answer; if questions and answers are swapped or concatenated, the column order or the tab delimiter is wrong. Fixing the source file and re-parsing is nearly always cheaper than editing chunks by hand, because these errors are systematic across every row.

  • Your Table-parsed knowledge base retrieves poorly. What do you check in the source spreadsheet first?
    The header row: RAGFlow takes the first row as field names, so a title banner, a merged cell, or a second logical table further down will shift what it thinks the columns are. Then check that the headers are descriptive words rather than codes, since they are embedded with every row. Fix the file and re-parse — the error is systematic, so editing chunks by hand does not scale.
  • Why can't a Table-chunked spreadsheet answer "what was total revenue across all regions"?
    Because each chunk is one row and no row contains the total. Retrieval can only return rows it matched; the model would have to sum whatever subset came back, which is unreliable and silently wrong when top-N cuts off rows. Aggregation over structured data belongs in a query against the data source, not in a retrieval pipeline over row-level chunks.
  • What makes a Q&A-chunked FAQ retrieve better than the same content parsed as General?
    The embedded text is already query-shaped. A user's question is compared against a curated question rather than against declarative documentation prose, which removes most of the phrasing mismatch that hurts retrieval. Each chunk is also exactly one self-contained answer, so there is no risk of a splitter cutting an answer in half or merging two unrelated ones.

saying these in an interview costs you the question

  • Uses Q&A for arbitrary tabular data with no question column
  • Leaves column headers as codes like col1 or amt
  • Expects row-per-chunk indexing to answer aggregate questions
  • Puts a title banner above the header row of the sheet
  • Thinks Table and Q&A differ only in file extension support

context

resolving links…