Lesson 4 of 6
Chunking SAP content and designing metadata
8 min
Listen to this lesson
Retrieval can only return what chunking created. If a chunk cuts a configuration step in half, or merges two unrelated runbook tasks, the best embedding model in the world will retrieve the wrong thing. Chunking is where SAP knowledge pays off, because SAP documents have structure you can use: spec sections, configuration paths, test steps, cutover tasks.
Three forces to balance
Managed pipelines chunk for you. When you control chunking (with the Vector API or your own HANA tables), split on the document's own structure first and only then on length. Keep the heading path, such as FS-O2C-014 > 3 Business rules > 3.2 Credit block, at the top of each chunk's text. That one line often decides whether retrieval finds it.
Patterns by SAP document type
| Document type | Chunk on | Keep together | Metadata to attach |
|---|---|---|---|
| Functional spec | Numbered sections and business rules | A rule with its exceptions and example | Spec ID, process (O2C, P2P), version, owner, status (draft or approved) |
| Configuration guide | One configuration activity or IMG path per chunk | The path, the values and the reason | Company code, plant, release, transport |
| Test case and evidence | One test case, with steps and expected results | Preconditions, data and expected result | Test case ID, process, cycle (SIT, UAT), result, date |
| Cutover runbook | One task or one go/no-go checkpoint per chunk | Task, owner, predecessor, duration, rollback note | Mock (Mock 1, Mock 2, dress rehearsal), task ID, owner |
| Decision log | One decision per chunk | Decision, rationale, date and approver | Decision ID, area, approver, date |
Chunking SAP program documents by type.
Metadata does two jobs
Metadata improves retrieval and makes answers usable. In document grounding you can attach metadata at the repository, document and chunk level, filter on it at query time, and return fields such as webUrl with each chunk so the answer can link to its source. SAP's limits are generous but finite: up to 500 metadata entries per collection, document or chunk, and up to 15 filters per query, at the time of writing.
Things that quietly break retrieval
- Tables flattened to text. A configuration table exported as a run-on paragraph loses which value belongs to which field. Convert tables to "field: value" lines or one row per chunk.
- Superseded versions. If v1 and v3 of FS-O2C-014 are both indexed, retrieval may return v1. Index approved versions only, or store a status field and filter on it.
- Scanned images. Pipelines accept image formats, but check that the text was extracted. A screenshot of a configuration screen with no text layer is invisible to retrieval.
- Boilerplate. Cover pages, revision tables and legal footers repeated in every document crowd out real content. Strip them before chunking.
- Acronyms. Your teams say "PR release" and "CR30"; documents say "purchase requisition release strategy" and "payment term 0004". Add a glossary chunk or a synonym line so both phrasings match.
What would you do?
Theo indexes 600 test evidence documents. Testers complain that "Did the credit block test pass in UAT cycle 2?" returns SIT results from cycle 1. What is the most effective fix?
- Chunk on the document's own structure first, then on length, and keep the heading path in each chunk.
- Match chunk types to SAP documents: one rule, one configuration activity, one test case, one runbook task.
- Metadata lets you filter (process, cycle, status) and cite (document URL) at query time.
- Index approved versions only, extract text from images, and strip boilerplate.
Check your understanding · not graded
Lesson check
1. What should every chunk of a functional spec carry at the top of its text?
2. Two versions of the same spec are indexed and answers quote the old one. What is the best control?
3. Why convert configuration tables into "field: value" lines before chunking?
4. Which metadata best helps a tester ask about a specific test cycle?