Retrieval-augmented generation systems are often described as if a PDF can move directly from an upload box into a vector database. In practice, the quality of extraction and document structure strongly affects what can be retrieved. A model cannot recover a missing table column or repair a paragraph whose two columns were interleaved during ingestion.
Markdown is a useful intermediate format because it is readable, diffable, and capable of preserving headings, lists, links, and code without a heavy binary container. It is not automatically correct. Treat conversion as a data-preparation stage with explicit validation.
Classify documents before extraction
Separate text PDFs from scans. If a sentence can be selected and copied correctly, a text-layer parser may be sufficient. Image-only pages need OCR. Mixed collections should record the extraction method per file because OCR confidence and text parsing have different failure patterns.
Next classify layout complexity. Ordinary reports and exported documentation usually work with coordinate heuristics. Scientific papers, brochures, forms, and financial statements may require a layout-aware model. Do not use one pipeline merely because it accepts every file extension.
Record language, page count, source version, and sensitivity. Language determines OCR and tokenization choices. Version prevents an outdated policy from silently outranking its replacement. Sensitivity determines whether cloud processing is permitted.
Preserve hierarchy before chunking
Headings are valuable retrieval metadata. They tell the system that a paragraph belongs to “Cancellation,” “Data retention,” or “Installation,” even if the query uses only the section concept. Review heading levels after conversion instead of trusting font-size inference.
Add stable document and section identifiers. A chunk should be traceable back to the source file, page or page range, heading path, version, and extraction date. Store these fields as metadata rather than injecting a long provenance header into every chunk.
Remove running headers, footers, and repeated navigation before chunking. Otherwise, common boilerplate can dominate similarity search and create many nearly identical results. Preserve legal notices when they change meaning, but do not repeat them in every section if the source uses them only as page furniture.
Clean content before embeddings
Join visual line wraps into paragraphs and repair line-end hyphenation. An embedding for docu- ment retention is less useful than one for document retention. Check character encoding, particularly names, symbols, and non-English text.
Lists should remain lists because each item may be independently relevant. Keep the introductory sentence with the list when it defines the scope. Code blocks, formulas, and tables need deliberate handling: a flattened table can create false relationships between headers and values.
Remove content that is definitely non-semantic, such as isolated page numbers. Do not remove uncertainty by guessing. If a table cannot be reconstructed, mark it as omitted and route the page for a specialized extractor rather than feeding incorrect prose to the index.
Choose chunks around meaning
Fixed token windows are simple but can split a definition from its conditions. Heading-aware chunking is usually a better starting point: group paragraphs under their section path, then split oversized sections with controlled overlap.
The useful chunk size depends on the task and model. A troubleshooting assistant may benefit from compact steps, while policy questions need enough surrounding clauses to preserve exceptions. Measure retrieval on representative questions rather than copying a universal token count.
Overlap should preserve continuity, not duplicate the entire corpus. Repeated text can crowd results with several versions of the same passage. Keep a chunk identifier and deduplicate neighboring hits during retrieval.
Handle tables and structured data separately
Tables frequently contain the answer users need, but Markdown conversion can obscure row relationships. Validate headers, empty cells, totals, and wrapped rows. For stable rectangular data, store CSV or normalized records and retrieve them through a structured path.
If a table remains in Markdown, repeat necessary header context in chunk metadata or a concise textual summary. A chunk containing only 42 | 17 | 9 is not retrievable without labels. Do not generate a summary that claims more certainty than the source table.
Figures and diagrams may be absent from text extraction. Preserve captions and an omission marker. If the system needs visual evidence, add a separate image-processing workflow with its own provenance.
Evaluate retrieval before generation
Build a small question set from real document tasks. Include direct lookups, paraphrases, questions requiring an exception clause, and questions whose answer is not present. For each question, inspect whether the correct source passage appears in the top results.
Separate extraction failures from retrieval failures. If the relevant sentence never entered the Markdown, changing the embedding model will not fix it. If the text is present but not retrieved, examine chunk boundaries, metadata filters, query wording, and embedding choice.
Also test conflict handling. When two versions of a document disagree, the system should prefer the current authoritative version or present both with dates. Version metadata is more reliable than asking the language model to infer which file is newer from prose.
Protect sensitive documents
Client-side PDF parsing can keep source files on the device during conversion, but the later RAG pipeline may still send Markdown to an embedding service, vector store, or model provider. Map the full data path rather than calling the workflow private because the first step was local.
Strip secrets and personal data only under an explicit policy; careless redaction can remove essential meaning. Control access at retrieval time, not merely during ingestion. A user who cannot open the source should not receive its chunks through the assistant.
Log document identifiers and processing outcomes without logging raw confidential text. Retention and deletion should cover the original, Markdown derivative, embeddings, caches, and backups.
Create a reproducible ingestion manifest
For every file, record checksum, source version, extraction method, warnings, Markdown checksum, chunking configuration, and index destination. Failed files should remain failed rather than becoming empty successful records. Reprocessing should be idempotent and should retire prior chunks when content changes.
Start with the browser PDF parsing guide to understand extraction boundaries, then apply the Markdown cleanup checklist. A reliable RAG system begins with trustworthy source preparation, not with the final prompt.
