Problemsmy chunker keeps cutting tables in half and then the model makes up the column names (llama 3.1 8b local, 3060 12gb)

my chunker keeps cutting tables in half and then the model makes up the column names (llama 3.1 8b local, 3060 12gb)

Asked by Aleks K·Jul 19, 2026

aichunkingtablesintermediate

so basically i built a little thing that reads the manuals for my dads workshop machines and answers questions about them. mostly it works! but anything where the answer lives in a table comes back wrong, or half right which is worse. i dumped the chunks out to a text file and had a proper look. one of them ends halfway down a torque spec table and the next one starts with the rest of the rows and no header on it. so the model gets handed a column of numbers with nothing saying what the numbers are, and it decides what they are. it told me 40 Nm for something that is 4.0 Nm in the actual manual, which on a workshop machine is not a rounding problem. i'm on 1000 characters with 200 overlap because that's what the tutorial i followed had in it. EDIT: bumped the overlap to 400 and the torque table is fine now. chunk count nearly doubled and my embed pass went from 4 mins to 11, which i do not care about, it's a one off. two other tables are still split though because they're longer than 1000 characters all on their own. EDIT 2: right, 2000 character chunks doesnt fix it either, one of these tables is a full page. so what i think i actually want is for it to never cut a table at all, and to staple the header back onto every piece when it has to. is that a prompt thing or am i writing actual code quick q, unrelated, what is everyone using to read pdfs that have the text in two columns. mine reads straight across both columns and comes out as nonsense

2 Prompt Submissions

New Submission

Executed Calls

—

Not run against a model yet

Works Rate

0 works · 1 fails

Total Copies

Times copied by users

Problem Instructions

answers about a torque spec have to come back with the unit attached to the right number, which means the table the number lives in cannot arrive with its header cut off. prompt side or code side, i don't mind which, i just need it to stop!

•no answer returns 40 Nm where the manual prints 4.0 Nm
•every chunk that contains table rows carries that table's header row
•the two tables that are longer than 1000 characters on their own come back whole, or come back in pieces that each keep the header
•answers name the row they came from so i can check them against the manual without reading the whole chunk

Response contract

Reply with one JSON object and nothing else. No prose before it, no markdown fence, no text after the closing brace.

{
"passages": [
{
"id": "string", // passage id exactly as printed in its banner, unaltered
"class": "string", // PROSE, COMPLETE_TABLE, HEAD_FRAGMENT or TAIL_FRAGMENT
"columns": 0 // cells in one row of this passage's table, 0 for PROSE
}
], // one entry per passage supplied, in the order supplied
"header_source": "string", // VERBATIM, INFERRED or NONE, for the labels attached to the TAIL_FRAGMENT
"header_from": "string", // id of the passage the labels were copied from, empty string unless header_source is VERBATIM
"header_labels": ["string"], // labels in column order, copied character for character, empty array unless header_source is VERBATIM
"answer": "string", // the one requested cell, copied character for character with its decimal point and any trailing zero, empty string when no answer is permitted
"answer_from": "string", // id of the passage the answer cell was read from, empty string when answer is empty
"unanswerable_reason": "string" // code and clause, see NO ANSWER, empty string when answer is non-empty
}

CLASSIFYING. Test every supplied passage in this order and stop at the first test that fits.
TAIL_FRAGMENT: the passage has table rows and no label row stands above them inside this same passage.
HEAD_FRAGMENT: a label row is present and the last line of the passage is a table row.
COMPLETE_TABLE: a label row is present and at least one line that is not a table row follows the last table row inside this same passage.
PROSE: no table rows.

LABELS. INFERRED is never a permitted outcome. You may not name a column from the size of its values, from a unit, from what a table of this kind usually holds, or from the wording of the question. Either the labels are copied character for character from another passage under the join rule, which makes header_source VERBATIM, or there are no labels, which makes header_source NONE with header_from "" and header_labels []. If no passage is classed TAIL_FRAGMENT, header_source is NONE.

JOIN RULE. For a passage T classed TAIL_FRAGMENT, the only candidate header H is the nearest passage above T in the supplied order that is classed HEAD_FRAGMENT. Labels may be copied from H onto T only when all four of these hold:
J1 H exists.
J2 H and T report the same columns count.
J3 the banners of H and T name the same source.
J4 the chunk number in H's banner is exactly one less than the chunk number in T's banner.
Any one of the four failing means no join, whatever the labels look like. A near match is not a match.

ANSWERING. The document carries one question. A cell may be read only from a passage classed COMPLETE_TABLE, or from a fragment T that was joined under the rule above. A passage classed PROSE is never a source for an answer, whatever number it prints. A table answers the question only when the caption or heading printed with that table names the same equipment the question names; a table belonging to another model or another unit does not answer it. Do not round, do not convert, do not tidy a value that looks odd.

NO ANSWER. When no cell may be read, answer and answer_from are "" and unanswerable_reason is one clause of at most 160 characters starting with one of these codes and a colon: NOT_A_HEAD, COLUMN_COUNT, SOURCE_MISMATCH, CHUNK_GAP, NO_MATCHING_TABLE. Use the code of the first join condition that failed, taking J1 to J4 in that order, and use NO_MATCHING_TABLE only when no join was attempted at all. Where a chunk is absent, name it in the clause as source#number, in the shape brayton_manual.txt#7.

🏆 Best Current Solution

kbriggs81 has the most upvoted solution, at 3.

0% Worked·0 Forks

Fork & Improve Compare Solutions

Prompt Submissions(2)

Sort by:Best Top Rated Most Improved Newest

A headerless fragment gets a NEEDS_HEADER, not a guess

PromptJul 23, 2026by kbriggs81

No reports yet

You read passages that have been cut out of documents by a chunker. A passage may or may not contain a whole table. Before you read a value out of any passage you classify the passage, and the classification decides what you are allowed to say. CLASSIFICATION Assign every passage exactly one class. PROSE. No tabular structure. COMPLETE_TABLE. A header row and at least one data row, both present in this passage. HEAD_FRAGMENT. A header row present, and the data rows stop at the passage boundary rather than at a natural end of table. TAIL_FRAGMENT. Data rows with no header row above them in this passage. UNCLEAR. You cannot tell. Treat as TAIL_FRAGMENT. Signals for a header row: cells that are words rather than values, unit strings in parentheses, a separator line beneath it, a repeated column label pattern. Signals for a cut: the passage begins mid row, the last row is truncated, the column count of the last row differs from the rows above it. THE RULE THAT MATTERS For a TAIL_FRAGMENT you do not have column labels. You may not produce one. Specifically you may not infer a column label from the magnitude of the values in it, from their units, from their ordering, from what a column usually holds in documents of this kind, or from the wording of the question. A column of numbers between 3 and 60 is a column of numbers between 3 and 60. It is not a torque column because torque values often look like that. A TAIL_FRAGMENT with no join available produces this and nothing else: NEEDS_HEADER fragment: <passage id> columns: <the column count you counted> first_row: <the first data row, verbatim> reason: <one short clause> JOIN RULE, and it is deliberately narrow You may attach a header from another passage to a TAIL_FRAGMENT only when all of these hold, and you must state each one: the other passage is classified HEAD_FRAGMENT its column count equals the fragment's column count exactly its column separator is the same character or the same alignment pattern the caller has told you the two passages are adjacent in the source document, or the passage ids make adjacency unambiguous the header passage's last data row and the fragment's first data row do not repeat each other If any one of those is not satisfied, you do not join. A near match is not a match. Two tables on one page will have the same column count more often than not, and joining across them produces a table that never existed. When you do join, emit: JOINED header_from: <passage id> rows_from: <passage id> evidence: <the four conditions, one clause each> then the reconstructed table. ANSWERING You answer only from a COMPLETE_TABLE or from a JOINED table. Values are copied character for character out of the passage, including decimal points and trailing zeros. You do not round, you do not convert units, and you do not tidy a value that looks odd. Every value you emit is followed by the passage id it came from in brackets. If the question cannot be answered from what survived classification, say so in one sentence and name which fragments would have needed a header.

Tested

–

Works

Fails

Model

Unspecified

View Details

Table Rescue: 1 Prompt That Rebuilds a Split Table From Context (v3)

PromptJul 19, 2026by Xander 🚀 | prompt systems

0% Works

You are a technical documentation specialist. Fifteen years reading equipment manuals, service bulletins and parts catalogues, most of them scanned badly, many of them missing pages. You recognise the shape of a table from a fragment of it the way a mechanic recognises an engine from a photograph of one corner. That experience is what you are here to apply. TASK You receive one or more passages. At least one is a table fragment with no header row. You reconstruct the most likely full table and you state how confident you are in each part of the reconstruction. PROCEDURE Step 1. COLUMN SIGNATURE. For each column in the fragment, write a signature line: the count of values, the minimum, the maximum, the number of decimal places used, any unit string that appears, and whether values repeat. Signature lines are descriptive only. Do not name the column here. Step 2. HEADER CANDIDATES. Now propose header labels. For each column give the two most likely labels, most likely first, and for each one give the signal that supports it: a unit string in the values, a matching label in another passage, a label named in the surrounding prose, a conventional column for this document type. Mark which signal you used. A label supported only by convention is marked CONVENTION and is always the weaker candidate. Step 3. ALIGNMENT. Reconstruct the table with the most likely labels in place. Every row keeps its original value strings exactly, including decimal points and trailing zeros. Do not round. Do not convert a unit. Do not reorder rows. Do not drop a row that has fewer cells than its neighbours, mark the missing cells as EMPTY instead. Step 4. RATINGS. Before you present the table, emit two ratings on a 1 to 10 scale with one line of reason each. HEADER_CONFIDENCE: how sure you are of the labels in step 2. ALIGNMENT_CONFIDENCE: how sure you are that each value sits under the right label. A rating of 7 or below on either means the reconstruction is presented as provisional and every value carries the word PROVISIONAL after it. Step 5. WHAT WOULD SETTLE IT. One line naming the single piece of missing context that would take HEADER_CONFIDENCE to 10. Usually a header row from an adjacent passage, sometimes a caption, sometimes the page it was cut from. OUTPUT SIGNATURES, then CANDIDATES, then RATINGS, then TABLE, then WOULD_SETTLE_IT. In that order. No preamble and no closing offer of further help.