Inspect retrieved evidence before tuning a RAG system

A wrong answer can originate in conversion, chunking, retrieval or generation. Inspect the source PDF and retrieved passages to find which boundary lost the needed information.

Tables can lose associations

A number without its row label, column header or unit can support the wrong answer. Inspect table-heavy chunks for those relationships. Keep simple GFM intact; handle complex HTML spans deliberately.

Headings can supply missing context

Two passages may contain the same terms while serving different purposes. Carry source section headings into chunks so readers and downstream models can distinguish setup instructions from troubleshooting advice.

Reading order can change meaning

Columns, sidebars and captions can interleave. Compare suspected passages with the rendered source rather than inferring correctness from nonempty text.

Measure the impact

Sample chunks and classify defects. Build questions with known evidence, then record whether the correct passage appears among retrieved results. Repeat with repaired input while holding downstream settings fixed. This measures your corpus; universal percentage-loss claims are not supported.

Fix the failing stage

If conversion lost text, improve extraction. If chunks split a table, revise chunking. If correct evidence is retrieved but ignored, examine answer generation. Use the RAG pipeline guide to keep these checks separate.

Convert a document

Use the tested Python, JavaScript or curl workflow. Choose one input: a public PDF URL, Base64 bytes, or a raw PDF upload. Raw uploads avoid Base64 expansion; all three send the document to an external processor.

The public demo converts page 1 with a watermark, at 3 requests per minute per IP. New accounts receive 20 trial pages once. Further account conversions use paid credits: monthly pages expire, top-ups do not. The API reference owns authentication, limits, replay and retention.