How do you build data extraction with RAG?

Key facts

Retrieval	POST /v1/embeddings with plugsky-embed over documents and their sections
Extraction	POST /v1/chat/completions with retrieved passages and a JSON schema
Provenance	Store passage ids with each extracted field for review and audit
Best fit	Long contracts, annual reports, filings and mixed-document packages
Pricing model	Flat monthly self-serve plans with unlimited fair-use usage
RAG status	RAG is live; embeddings plus chat completions are the building blocks
Models	30+ models; stronger aliases help on ambiguous legal and financial text
Roadmap	Batch ingestion is coming soon; build initial indexes with rate-limited jobs

TL;DR

• Retrieve the sections that matter, then extract — do not truncate long documents.
• Keep passage-level provenance so every value is reviewable.
• Ask for per-field confidence and abstain instead of guessing.
• Separate the index by document family so retrieval stays precise.
• Measure per-field accuracy and evidence precision together.

How it works, step by step

1. Define the extraction schema per document family, with field definitions and expected locations.
2. Chunk documents by clause, section or statement, preserving page and heading metadata.
3. Embed chunks with plugsky-embed and store vectors with document id and location.
4. For each field group, retrieve candidate passages and assemble a focused extraction prompt.
5. Extract with JSON mode, requiring value plus passage id and confidence per field.
6. Validate values and route unexplained or low-confidence fields to review, then store values with provenance.

Original data

Try it yourself

Open the function calling schema generator →

Why retrieval for extraction

Three extraction problems are retrieval problems in disguise:

• Long documents: a 200-page filing cannot fit in a prompt, and truncation loses exactly the annex where the field lives.
• Field locations vary: the same value appears in different sections across document families, so fixed templates fail.
• Provenance requirements: reviewers and auditors need to see the passage behind a number, which retrieval provides naturally.

Retrieval also reduces cost by sending only relevant passages rather than the full document on every call.

Building the extraction pipeline

The pipeline indexes once and extracts many times:

1. Chunk: split by clause, section or statement, keeping headings, page numbers and table structure.
2. Index: embed with plugsky-embed and store document id, family and location with each vector.
3. Retrieve: for each field group, query with a description of the field, not the field name alone.
4. Extract: JSON mode returns value, passage id and confidence for each field.
5. Verify: confirm the value appears in the cited passage; reject unsupported claims.
6. Store: keep the value with its provenance and the model version used.

Implementation and evaluation

Measurement must distinguish retrieval failure from extraction failure:

• Per-field accuracy: exact match for formatted values, normalized comparison for text.
• Evidence precision: share of extracted values whose cited passage actually contains them.
• Abstention rate: fields returned null or flagged, which should align with genuinely absent data.
• Retrieval hit rate: did the correct passage appear among the candidates per field group?
• Straight-through rate: documents processed end to end without human review.

If retrieval hit rate is high but accuracy is low, the extraction prompt or schema needs work. If hit rate is low, improve chunking or the retrieval query before touching the model.

Limitations

Retrieval narrows the problem but does not solve document quality:

• Tables and multi-column layouts often need dedicated parsing; plain text extraction loses the relationships that give numbers meaning.
• Contradictory passages across documents require conflict resolution rules, not just extraction.
• Field descriptions drive retrieval quality, so vague definitions produce vague results.
• Scanned documents need OCR before indexing, and Arabic or mixed-language corpora should use plugsky-embed-multilingual.
• Batch ingestion is coming soon, so large initial indexes need rate-limited jobs you operate yourself.

Honest comparison

Capability	Retrieval-based extraction	Full-document prompting	Manual review
Long documents	Handles them by section	Truncation or context limit	Unlimited but slow
Provenance	Passage id per value	Page reference at best	Reviewer notes
Cost	Proportional to relevant passages	Full document per call	Analyst hours
Abstention	Explicit null with confidence	Often guesses	Not applicable
Evaluation	Per-field plus retrieval metrics	Aggregate accuracy	Sampled audits

Frequently asked questions

When should extraction use retrieval?

When documents are long, layouts vary across a family, or every value must cite a passage. For short, uniform documents a single JSON-mode call is simpler.

How should I chunk contracts and filings?

By clause, section or statement, keeping headings and page numbers with the text. Avoid fixed character splits that separate a number from its label.

How do I make values auditable?

Require a passage id with every extracted field, verify the value appears in the cited passage, and store both with the model version.

What if the value appears in several places?

Return all candidate values with their passage ids and let a conflict rule or a reviewer decide. Silently picking one hides contradictions.

How do I handle tables?

Parse tables separately and index rows with their headers. Models extract from tables more reliably when the header context accompanies each row.

Which model should extract legal text?

Stronger aliases generally handle ambiguity better, but benchmark on your own documents. Retrieval quality often matters more than the model tier.

Can I build the index on the free plan?

Yes. Embeddings are live, two free models are available with no card, and the 14-day full-access trial lets you evaluate extraction quality on paid aliases.