For a corpus made of one repeated document type (renewal notices, purchase orders, statements), the right approach is to interview the people who handle the documents to derive a small set of columns (6-10 fields), rather than running expensive LLM extraction to discover a schema. Two signals validate a real column: it's named instantly without hesitation, and two separate handlers name it the same way with the same meaning. Fields that fail these tests are subtypes, judgments, or ambiguous terms. The resulting index acts like a table of contents, pointing to candidate documents rather than storing answers, and it grows incrementally as new filterable questions arise. Ingestion cost is paid once per document while querying cost is paid once per question, so the prepared approach pays off once questions outnumber documents — roughly fifty queries a day for a claims handler.
Table of contents
1. One document type, and the columns that came with it2. The interview that gets you the columns3. The index is a table of contents for the collection4. Paid once, or paid on every question5. Conclusion6. Further reading and sourcesQuestions this post answers
How do I decide which fields to extract into a structured index for a RAG system over thousands of similar documents, like insurance policies?
Interview the people who actually handle the documents (not their manager) and ask what they filter on. A real column is named instantly with an example, and two separate handlers describe it the same way. Fields that need thought, are empty on many documents, or represent a judgment call rather than a printed fact should be excluded from the schema. Developers designing extraction schemas for RAG pipelines track approaches like this on daily.dev.
When does it make sense to pre-extract structured fields from documents versus just running retrieval over raw text for every query?
It pays off once the number of questions asked over a document collection's lifetime approaches the number of documents in it, since ingestion cost is paid once per document while retrieval-without-an-index cost is paid on every question. At roughly fifty questions per day per person, a team of six generates over seventy thousand questions a year, which quickly outpaces a five-thousand-document corpus and justifies building the structured index. Teams weighing indexing versus raw retrieval for RAG cost trade-offs can follow this reasoning on daily.dev.
What is a common mistake when defining a date or status field for a document extraction schema, and how do I avoid it?
A frequent failure is a field name that two handlers answer quickly but mean differently, such as 'date' meaning contract signature date to one person and cover start date to another, producing a column with two different quantities mixed together that silently corrupts filters like 'policies in force in March.' Avoiding it requires interviewing at least two handlers separately and checking that their meanings, not just their wording, match. Engineers building filterable document indexes can revisit schema pitfalls like this via daily.dev.