A small team can spend weeks choosing a language model while treating the documents behind it as a solved problem. Yet an answer can go wrong before retrieval begins: a heading disappears, a table loses its column labels, or an old policy is mixed with its replacement. Converting a document is only the first step toward useful context.
Start with a small, representative set of files
Choose a handful of documents that reflect the material your product actually uses: a short policy, a longer guide, and a table-heavy report. Keep the original files next to the converted output. This makes it possible to distinguish extraction problems from retrieval or answer-generation problems.
Give each document a stable name and record its source and revision date. If two files describe different versions of the same policy, preserve that distinction instead of combining them into one undated text file. A support assistant needs to know which instructions still apply.
Check meaning, not just whether conversion succeeded
Markdown is useful because it represents headings, lists, tables and links in readable text. A successful conversion response, however, does not prove that every relationship survived. Read a section with nested headings. Compare a table row against the original. Open a source link. These small checks can expose problems that a simple character count misses.
For example, a price table may contain a plan name, an amount and a billing interval. If the amount survives but the interval disappears, a downstream answer may describe an annual price as a monthly one. Keep the labels with the values, and rewrite an ambiguous fragment before it enters the knowledge base.
Choose the conversion path that fits the team
Microsoft maintains the open-source MarkItDown Python project for converting files into Markdown. Its documentation explains supported formats and optional dependencies, and distinguishes text extraction from high-fidelity document reproduction.
For a hosted workflow, MarkItDown.store provides an independent browser interface and API around that open-source project. It offers limited free usage and paid plans. It is a separate hosted product, not the official Microsoft project. The practical choice is whether the team wants to manage its own conversion environment or use a hosted interface, taking its documents and operating requirements into account.
Make a correction possible
Retain the original document and its converted version so an incorrect answer can be traced back to the source text. When a conversion needs a manual correction, keep that change visible in your content workflow. Do not silently fix a production answer while leaving the underlying source ambiguous.
Finally, test a few questions whose answers you already know. Include one that depends on a table, one that depends on a heading and one whose answer is absent from the documents. This gives a startup a concrete way to evaluate its source material before adding more files or changing models.
Product disclosure: this contribution is shared on behalf of MarkItDown.store.
