Building a retrieval-augmented generation (RAG) system for legal documents looks, on paper, like any other RAG project: chunk, embed, index, retrieve, generate. In practice, two constraints change the design from the start. The documents can't leave the network, and many of them carry information that should never be surfaced by a casual query. Get the order wrong and you build a very efficient way to leak client data.
The first design decision is boring but load-bearing: compress before you embed. A case file is mostly PDFs, scans, OFD documents, and audio or video records. Their raw size drives two costs. The obvious one is storage — every ingested page sits in your index and your vector store. The less obvious one is token cost at query time, and it's the bigger bill. Multimodal tokenizers price image content heavily, so if your retrieval pipeline feeds scanned pages or chart screenshots straight into a model, every call carries that weight. Compress the image-heavy content first, and the token spend drops sharply. In UglyPear Data's own testing, compressed images cut the token cost of feeding a model by 85.9 percent measured against GPT-4o. That's not a one-time storage saving; it compounds on every query, every day.
The second decision is the order of redaction relative to chunking. This is where most pipelines quietly fail. Document-level permissions get flattened the moment you slice a file into chunks — the vector store turns "only team X can open this" into "anyone whose query matches this paragraph can read it." If an ID number or account number is already in the index, a single well-phrased question pulls it out. So detection and redaction of sensitive fields have to run before chunking and embedding, not as a slow filter bolted on after. The redaction also has to run inside your own environment; sending raw files to an external redaction API just moves the leak one step earlier.
A complete private RAG base is usually described as a six-step pipeline with eight capability modules: splitting, vectorization, retrieval, and generation all happen on your own servers, and 13 categories of sensitive information — client IDs, bank accounts, undisclosed case details — are detected and scrubbed before anything enters the index. That shrinks the leak surface at the root rather than patching it later.
Compression is the other half, and it has to be local. A tool built on an in-house Rust engine that covers PDF, images, video, audio, Office, OFD, and scanned documents, and does all compression on the user's machine, fits this constraint naturally. The performance bar matters more than people expect: a 443-page OFD document processing end to end in about 124 seconds is the kind of number that makes bulk archival realistic rather than theoretical. If compression takes longer than that, nobody runs it on the back catalog, and the pipeline silently degrades.
There's a sequencing lesson worth stating plainly. Teams often treat preprocessing as polish — something to add once the shiny retrieval demo works. That's backwards for sensitive documents. Compression and redaction are prerequisites, not optimizations. Compress first to shrink what flows through every later stage; redact before chunking so the index can never surface what it shouldn't; then let retrieval run over cleaner, smaller, safer data.
Deployment shape matters too. For legal clients, a fully private deployment means the data never leaves the internal network and who governs it is unambiguous. Single machine, internal cluster, or a domestic-software (xin chuang) environment running Kylin or UnionTech — the pipeline should run in all of them. Teams that want compression inside their own case-management system have a compress SDK and a compress API to choose from, and an MCP service (stdio or HTTP) for letting an assistant trigger compression by sentence.
If you're evaluating such a setup, the procurement questions are mostly about order and boundaries: does data stay off external networks end to end, can sensitive information be redacted automatically and before indexing, is retrieval full-text only or does it include semantics, how wide is the compression ratio and format coverage, and does the deployment fit your domestic-software requirements. Notice none of those are "how fast is search." Speed follows from getting the pipeline order right; it isn't the starting point.
The engineering takeaway is simple to state and easy to get wrong: compression and redaction are not features you layer on after RAG works. They are the substrate RAG sits on when the documents are sensitive and the network boundary is non-negotiable.
Try it now
To see how private compression and retrieval are wired together, start at UglyPear Data's product page https://www.uglypear.com/en/products/ and the RAG data engineering base overview https://www.uglypear.com/en/ . The engineering blog at https://www.uglypear.com/en/blog/ carries more on redaction order and deployment shapes.
FAQ
Q: Why compress before embedding instead of after?
A: Compression shrinks the volume that flows through storage, retrieval, and every model call. Doing it first cuts token cost on each query, not just disk usage once.
Q: Can redaction run as a post-filter after indexing?
A: It shouldn't. Once a chunk is indexed, a query can surface sensitive fields directly. Detection and redaction must run before chunking and embedding.
Q: Does local compression mean we can't use a hosted model at all?
A: The documents and the index stay on your network. What you call for generation is a separate decision; the redaction boundary is what protects you either way.
Q: Is a 443-page OFD in 124 seconds fast enough for bulk work?
A: For archival batches it's practical. The point is that compression has to be fast enough that teams actually run it on the back catalog rather than skipping it.