How to Design Metadata That Makes RAG Retrieval Better

Good metadata is not a decorative list of tags. Each field should help the system include evidence, exclude it, rank it, group it, or explain it. If a field does none of those jobs, it probably does not belong in the retrieval index.

A practical minimum has five parts. Give every document and chunk a stable identity. Record source and derivation. Capture time and version. Describe scope with controlled values such as product, jurisdiction, type, and language. Preserve location such as section path, page, table, or speaker turn. Keep access attributes beside the retrieval unit, while the source system remains authoritative.

Separate authoritative metadata from generated metadata. A policy number from the policy system, an effective date from the issued document, and an owner from the repository are facts with a known source. An LLM-generated topic, summary, or entity list is a useful hypothesis. Store how it was produced and its confidence; never let it silently override the authoritative fields.

Document metadata describes the source as a whole: document ID, owner, type, version, effective interval, jurisdiction, language, security scope, canonical URL, and checksum. Chunk metadata describes the retrieval unit: chunk ID, parent ID, section path, page range, content type, and offsets. Do not duplicate every field into mutable free text if the index can inherit it safely.

The distinction matters because search failures occur at both levels. A question about a 2026 underwriting manual first needs the correct document and version. A question about a particular exclusion then needs the correct section or clause within it. Document fields disambiguate nearly identical files; chunk fields restore the local context that splitting removed.

A 2026 paper, Utilizing Metadata for Better Retrieval-Augmented Generation, compared plain chunk embeddings with several ways of adding metadata on a corpus of SEC filings. In that study, prefixing metadata and unified content-plus-metadata embeddings improved retrieval over plain text. Company and year were stronger disambiguators than section titles. The result is useful but bounded: the corpus was repetitive 10-K filings, the ground truth was partly generated, and the authors did not test every domain or end-to-end answer quality.

The broader lesson is to test fields, not merely collect them. A year may separate filings but add little to a timeless handbook. A section title may be essential in a contract. Run field ablations and remove values that add index cost, maintenance work, or misleading similarity without improving evidence recall.

A retrieved chunk should answer four questions: what source did this come from, which version was used, how was it produced, and where can a reviewer inspect the original? Store the canonical locator and stable parent ID on every chunk. Keep extraction time separate from publication and effective time.

The W3C PROV-O recommendation offers a useful mental model even if the implementation uses ordinary JSON. It distinguishes entities, activities, and agents, and defines relations such as wasDerivedFrom, wasGeneratedBy, wasAttributedTo, and wasRevisionOf. In a RAG pipeline, the PDF is an entity, OCR is an activity, the extracted text is a derived entity, and the parser or person responsible is an agent.

This prevents a common mistake: treating ingestion metadata as source metadata. The day a file entered the vector store is not its effective date. The model that generated a summary is not the document author. A cleaned passage is not the primary source. Keeping those distinctions visible makes later corrections, deletions, re-indexing, and citation review much easier.

Version status should be machine-readable. Mark a version as current, superseded, future, expired, or draft according to a documented rule. Link revisions instead of overwriting old records. The default retrieval path can exclude superseded material, while comparison questions can deliberately include it.

Free-form tags decay quickly. One team writes “United Kingdom”, another “UK”, and a third “GB”. Product names change. Acronyms collide. A filter works only when the stored value and the query interpretation agree.

Start with a small data dictionary. For every field, define meaning, type, allowed values, cardinality, source, update rule, and whether null means unknown or not applicable. The Dublin Core Metadata Terms specification includes identifiers, creators, language, source, access rights, spatial and temporal coverage, relations, and version links. Its terms can inform JSON or relational schemas; RDF is not required.

For domain concepts, assign stable concept IDs and keep human labels separate. The W3C SKOS reference distinguishes preferred, alternative, and hidden labels, and supports direct broader and narrower relationships. That pattern lets “professional indemnity”, “PI”, and a local product label point to one concept without losing the language people actually use.

Do not build an enterprise ontology before the first useful search. Begin with the concepts that repeatedly affect retrieval: product, region, document type, authority, and lifecycle state. Add hierarchy only when users need broader queries such as all liability products or every European jurisdiction. Record vocabulary versions so reclassification can be reproduced.

The system should declare which role each field plays. Hard filters define eligibility. A user permission, tenant, explicit jurisdiction, or effective-date boundary can remove candidates before semantic search. Ranking signals express preference rather than certainty. Recency, authority, or a likely product match may boost a result while alternatives remain visible. Display fields help a reviewer but should not change ranking by accident.

Current retrieval APIs expose this distinction in concrete form. The OpenAI Retrieval guide documents comparison filters, date ranges, set membership, and compound AND or OR conditions over file attributes before semantic search. Other stores differ in syntax and execution. The portable idea is to define filter semantics in the application instead of scattering provider-specific rules throughout prompts.

Be conservative when deriving filters from natural-language questions. “Show the current cancellation rule for our Singapore product” supports filters for lifecycle status, jurisdiction, and product if those values resolve confidently. “How do cancellation practices differ?” should not be narrowed to one region just because a recent conversation mentioned Singapore. An uncertain extracted value can become a ranking hint or a clarification, rather than an invisible exclusion.

Multi-Meta-RAG used LLM-extracted metadata with database filtering for multi-hop questions and reported gains on the MultiHop-RAG benchmark. The authors also note the approach depends on a particular domain and question format. Treat it as evidence that query-derived filters can help, not proof that an LLM should control every retrieval boundary.

Generated metadata can fill gaps that source systems never captured: topics, named entities, likely questions, claim types, section summaries, or relationships between documents. It can improve recall when the source wording and user language differ. It can also create false precision.

Store generated values in a separate namespace with generator name, prompt or extraction rule, model version, timestamp, confidence, and source span. Allow several candidates rather than forcing one label when the text is ambiguous. Never use generated access levels, legal status, or effective dates as authoritative without a review rule.

Prefer deterministic extraction for values already present in headers, repository records, or structured APIs. Use a model where interpretation is required. Preserve human corrections so the next ingestion run does not replace them.

Embedding metadata into chunk text, keeping a separate metadata vector, and using database filters solve different problems. Text prefixes can help semantic disambiguation but require re-embedding when values change. Separate fields are easier to update and filter. A dual representation may work well, but it increases evaluation and serving complexity. Choose after measuring the corpus.

Validate required fields, types, allowed values, parent links, version chains, timestamps, and source locators during ingestion. Quarantine records that fail instead of indexing them with plausible defaults. Monitor null rates and cardinality drift. A field that is populated for only one department may distort retrieval more than it helps.

Build evaluation cases where metadata should change the result: two companies with similar filings, current and superseded policies, the same product across jurisdictions, multilingual copies, a restricted document beside a public one, and a table whose chunk needs its section heading. For each query, mark both relevant content and required metadata constraints.

Measure retrieval with and without each field. Track evidence recall, irrelevant candidates removed, false exclusions, version correctness, duplicate concentration, and citation completeness. Slice by document type and metadata coverage. Change the year, jurisdiction, or product in the query and confirm the evidence changes for the right reason.

Metadata will not repair a broken parser, a missing document, or a vague question. Too many filters can make the system confidently return nothing. Too many generated tags can make every chunk look specific while weakening trust. The useful schema is the smallest one that improves real retrieval decisions and stays accurate as the knowledge base changes.

If your RAG system retrieves the right words from the wrong document, version, or business context, share the real question and the metadata you currently have at sahil@granveo.com. That failure case is the right place to start.