In RAGFlow, a parsed chunk has cut a table in half — what do you do next?

## Why a review surface exists at all Most RAG stacks treat ingestion as a black box: you point a loader at files and hope. RAGFlow's position is that document understanding is imperfect and its errors are *silent* — a mis-parsed table produces a plausible chunk containing wrong numbers, not an exception — so the pipeline must be inspectable. The chunk list per document is that inspection point, and using it is a routine operational habit, not an emergency measure. ## What the chunk view tells you For each parsed document you get its chunks as they will be retrieved. For PDFs, a chunk can be traced back to the region of the page image it came from, which is the single most useful diagnostic available: it separates two failures that look identical in the text. - **A parsing failure.** DeepDoc's layout detection missed the table region, or table-structure recognition inferred the wrong grid. The chunk's source region will show the table but the text will be mangled — cells out of order, headers detached. Editing text here is treating a symptom. - **A segmentation failure.** DeepDoc extracted the table correctly, but the chunk method cut it across a boundary, so half the rows are in one chunk and half in the next. The source regions of the two chunks will show adjacent halves of the same table. The fix is the template, not the text. That distinction drives everything else, so make it before you touch anything. ## The local repairs Within the chunk view you can: - **Edit a chunk's content.** Paste the corrected table, rejoin split sentences, delete leaked headers or footers. The edited text is what gets embedded and what will be shown as the citation, so this genuinely fixes retrieval and grounding for that chunk. - **Add keywords to a chunk.** This gives the chunk extra matchable text beyond its body, which is how you rescue a chunk that is correct but phrased nothing like the queries users actually type. - **Enable or disable a chunk.** Disabling takes a chunk out of retrieval without deleting the document. This is the fastest mitigation for a chunk that is confidently wrong and keeps getting cited — you stop the bleeding immediately and fix the cause afterwards. - **Add or delete chunks.** For a small, high-value document, hand-authoring a chunk that states the fact cleanly is legitimate. All of these are per-chunk, manual work. They scale to dozens of fixes, not thousands. ## The systemic repair, and the trap When the same defect appears across many documents, the answer is upstream: a different chunk method (a genre template that respects the document's real boundaries), different settings within the method, or fixing the source file itself. Then re-parse. The trap that catches people: **re-parsing rebuilds a document's chunks from scratch**, so every manual edit, added keyword and disabled flag on that document disappears. Anyone who spends an afternoon hand-correcting chunks and then decides to try a different template loses the afternoon. The correct sequence is always template first, review second, hand-fixes last — and if you do need to change the template afterwards, expect to redo the manual work. ## Building it into a workflow A workable ingestion routine for a real corpus: 1. Upload a small representative sample per document genre. 2. Parse with the candidate chunk method. 3. Review chunks: are they self-contained, are tables and their captions intact, is reading order sane, is page furniture gone? 4. Iterate on the template until the sample is clean. 5. Bulk-parse the rest. 6. Spot-check, and use the local repairs for the remaining one-off defects. The review pass also produces information you cannot get any other way: it tells you which document genres your pipeline genuinely handles and which ones need a different template or a preprocessing step. That is a far better basis for a rollout decision than an end-to-end answer quality impression. ## Related but distinct Chunk review answers "is the indexed content correct". It does not answer "does retrieval find the right chunk for a query" — that is a separate tuning surface. Keep the two diagnoses apart: if the chunk is wrong, no amount of retrieval tuning helps; if the chunk is right and never surfaces, editing it will not help either.