Building a Chinese Legal Retrieval Pipeline: ETL, Indexing, Citations

Most "add China coverage" projects die in the same place: a team licenses or scrapes a pile of Chinese judgments, drops them into a vector database, runs a demo, and watches it confidently return cases that look right and were decided the opposite way. The corpus was never the hard part. The hard part is the retrieval pipeline — the machinery that turns 170M+ heterogeneous documents into something a model can search, rank, and cite without lying.

This is a reference architecture for that pipeline, written for the ML, platform, and search engineers who have to build it. It assumes you already have, or can license, a structured corpus — if you are still deciding how to assemble one, start with how to structure PRC court data for AI and the license-vs-scrape tradeoff. Here we pick up after the corpus and walk the five stages: ETL, chunking and embedding, hybrid indexing, query-time retrieval, and the citation and eval layers that make the whole thing trustworthy.

The pipeline at a glance

Stage 1 — ETL: the layer most teams underestimate

Extract-transform-load over Chinese judgments is not a weekend script. The source documents are highly formatted but carry their metadata in prose, the same matter appears across instances and reposts, redaction is built in under Supreme People's Court rules, and format and encoding drift across thousands of courts and two decades of publication. A cleaning rule that holds for 99% of documents still fails on more than a million.

The ETL stage has to deliver, for every record:

• Normalized text — encoding repaired, boilerplate stripped, OCR artifacts cleaned, layout standardized.
• Extracted fields — case number (an-hao), court and court level, document type, date, cause of action (an-you), de-identified parties, statutes cited, operative outcome. These become your filters; without them you can only full-text search blindly.
• De-duplication and versioning — collapse reposts, link first instance to appeal to retrial, keep the authoritative version. Skip this and your "1,200 similar cases" might be 300 disputes counted four times, quietly skewing every statistic and training set.
• A stable record ID and source link — the anchor that makes citation possible three stages later.

This is the layer with the worst ratio of effort to product differentiation. Two teams with the same clean corpus compete on retrieval and UX, not on who cleaned the text better. It is also why many teams license the corpus-and-ETL layer rather than rebuild it — we break that decision down in the license-vs-scrape piece. Either way, treat ETL output as a contract: a typed, validated schema your indexing stage can rely on.

Stage 2 — Chunking and embedding, the legal way

Naive fixed-size chunking is where legal retrieval quietly degrades. A 512-token window that splits a holding from the reasoning that supports it, or fuses two unrelated parties' claims, produces passages that retrieve well and cite badly. Chinese judgments give you a better seam: they are written in recognizable sections — caption, procedural history, findings of fact, reasoning, holding. Chunk along those sections, not along arbitrary token counts.

Practical guidance:

• Segment by structure first, then size. Keep facts, reasoning, and holding as separable units so retrieval can return the right passage instead of the whole document.
• Carry metadata onto every chunk. Each passage inherits its parent's record ID, case number, court, date, and cause of action. This is what lets you filter at retrieval time and cite at answer time.
• Choose an embedding model that handles legal Chinese. A general multilingual model compresses domain terms — distinct causes of action or statute references collapse toward the same vector. Evaluate candidates on your own labeled legal pairs before committing; the right choice is the one that separates near-but-opposite cases, not the one that tops a generic benchmark.
• Decide your cross-lingual strategy here. English-native teams need to query and read in English over Chinese sources. Whether you embed bilingually, translate queries, or retrieve on Chinese and summarize in English, design it into the chunk and index now — retrofitting it later is painful. We cover why this matters in English-native Chinese legal research.

Stage 3 — Hybrid indexing: lexical and vector, not one or the other

The single most common mistake is going pure-vector. Dense embeddings are excellent at semantic similarity and disastrous at the exact tokens legal relevance often turns on: a case number, a specific statute article, a precise monetary threshold, a named cause of action. Vector search will happily return a factually similar case that was decided the opposite way while missing the on-point case that happened to use different phrasing.

The production answer is a hybrid index:

Build all three over the same records: a lexical index, a vector index, and structured fields you can pre-filter on. The fields are the cheapest, highest-leverage win — constraining to the right cause of action and court level before you rank shrinks the candidate set to cases that are actually comparable, which is exactly what a lawyer does first.

Stage 4 — Retrieval and reranking at query time

With the index in place, each query runs a four-step path:

1. Structured pre-filter. Lock the obvious constraints — cause of action, court level, time window, document type. This removes whole classes of non-comparable cases before ranking and is where the "decided the opposite way" failures are cheapest to kill.
2. Parallel recall. Run lexical and vector retrieval together and fuse the candidate lists (a rank-fusion method such as reciprocal rank fusion is a sound default). You want the on-point case whether it matched by wording or by meaning.
3. Rerank. Pass the fused top candidates through a cross-encoder reranker that scores query-passage pairs jointly. This is the step that most improves top-k precision — the difference between "ten plausible cases" and "the three that actually govern."
4. Ground. Return each surviving passage with its citation attached, ready for the model to cite and a lawyer to verify.

This is the same methodology, viewed from the data side, that we describe for similar-case retrieval generally. If you want the buyer-side framing of the whole stack rather than the pipeline internals, see Building China coverage into your legal AI.

Stage 5a — Citation grounding: a data property, not a prompt

For legal AI, the line between a usable system and a malpractice risk is whether every surfaced fact resolves to a real document. Grounding cannot be bolted on at the end with a clever prompt; it is something the pipeline either preserves or destroys. Three earlier decisions determine it:

• Stable IDs from ETL (Stage 1) — every record anchored to a case number and a source link.
• Metadata carried onto chunks (Stage 2) — so a retrieved passage still knows which judgment it came from.
• Citations returned with results (Stage 4) — case number, court, date, and a link back to the original judgment, surfaced alongside the text.

Get those right and a retrieval-augmented system can show its work: every passage opens to the judgment behind it. Drop the IDs anywhere in the chain and the answers become unverifiable, which in a legal product is the same as wrong. "We have the documents" and "our AI can cite from them" are different claims, and the gap between them is this pipeline.

Stage 5b — Evals: you cannot improve what you do not measure

Without an evaluation harness, every pipeline change is a guess. Build a labeled set of real legal queries with known-relevant judgments — a few hundred, spread across causes of action and court levels — and track three families of metric:

• Recall@k — does the on-point case make it into the candidate set at all? A retrieval failure here can never be fixed by reranking.
• Ranking quality (nDCG / MRR) — are the most relevant cases at the top, where the model and the lawyer will actually look?
• False-precedent rate — the legal-specific one. Of the top results, how many are superficially similar but decided the opposite way, or from a non-binding court, or superseded? This is the metric generic RAG evals miss and the one that gets legal products in trouble.

Re-run the harness on every change to embeddings, chunking, fusion weights, or reranker. The number that matters is not a leaderboard score on someone else's benchmark — it is performance on your queries against your corpus.

Build vs license, layer by layer

Not every layer deserves your engineers' time. A useful split:

The pattern that works for most legal AI vendors: license a structured, citation-linked, English-indexed corpus to remove the corpus-and-ETL burden, then build the indexing, retrieval, and evals that make the product yours. That is precisely the layer SinoVerdict is built to supply.

The bottom line

A Chinese legal retrieval pipeline is five stages, and four of them are where the demos go wrong: ETL that delivers clean, ID-anchored records; section-aware chunking with metadata carried through; a hybrid index that respects exact legal tokens; retrieval that pre-filters, fuses, reranks, and grounds; and an eval harness honest enough to catch a look-alike masquerading as precedent. SinoVerdict supplies the foundation those stages stand on: a structured, machine-readable corpus of more than 170 million Chinese judgments — normalized, de-duplicated, field-extracted, and citation-linked, with English query and summaries and links back to source — delivered as a bulk dataset to seed your index, a REST API to serve queries, and an MCP server for Claude, ChatGPT, and Cursor, with daily updates.