Content chunking

A retrieval system does not hand a model your whole product page. It hands it a few hundred tokens that scored well against the query. Everything outside that window is invisible to the answer.

That has an unintuitive consequence: a page can contain the right fact and still fail, because the chunk containing the fact carried no indication of which product it belonged to. A passage reading "Interrupting rating: 22 kAIC" is useless on retrieval if the part number sat three chunks earlier under a heading the splitter discarded.

Common strategies, roughly in order of how well they hold up on technical content:

• Fixed-size with overlap. Split every N tokens with an overlap window so facts near a boundary appear in two chunks. Crude, robust, still the default in many pipelines.
• Structural. Split on headings, list items, table rows, or DOM sections, so the boundary follows the document's own logic.
• Semantic. Split where the embedding similarity between adjacent sentences drops, on the theory that a topic changed there.

You do not control which one a third-party engine uses. You control whether your content has structure worth splitting on, which is the practical lever.

Write so that every block stands alone. Concretely, on a PDP:

• Repeat the manufacturer and part number inside spec tables and Q&A blocks rather than relying on the h1 two screens up.
• Keep each specification on its own row with its unit attached, so a table-row split yields a complete fact.
• Phrase application content as explicit question-and-answer pairs. "Does this replace a 400W metal halide?" followed by a self-contained answer survives any splitting strategy.
• Avoid facts that only exist as a rendered image or an unlabeled diagram. There is nothing to chunk.

This is also why JSON-LD earns its place. Structured data is pre-chunked by definition: each property is a discrete, labeled, self-describing fact that does not depend on a boundary decision going your way.

With 400,000 SKUs nobody hand-tunes passages. Chunk quality becomes a template and data-model question: does the PDP template emit spec values as table rows with units, does the Q&A module render server-side, does every block include enough identity to be self-describing.

The upstream half is enrichment. A spec sheet that lives as a PDF is chunked by whoever indexes the PDF, if anyone does, and typically badly: merged table cells across twelve part numbers produce passages that attribute the wrong value to the wrong SKU. Extracting those values into fields removes the guesswork from the boundary entirely.