We build retrieval-augmented generation systems that answer from your own documents with citations, respect the permissions of the person asking, and are measured against a real evaluation set rather than a demo that looked convincing.
Almost every failed RAG project fails in retrieval, not generation. The model was rarely the problem.
The answer is fluent, cited, and wrong, because the retrieved passage looked semantically similar without actually containing the answer.
The parser flattened a specification table into unusable text, so the number the user needs is no longer associated with what it describes.
Retrieval ignores document permissions, so the assistant happily quotes a document the asking user has no right to read.
A chunk size gets tweaked, an embedding model swapped, and quality shifts with no test set to say in which direction.
Source documents were updated but the index was not, so the assistant confidently quotes a superseded policy.
With no confidence threshold, an unanswerable question still produces a fluent answer assembled from whatever came back.
Each stage is measured separately, because a single end-to-end accuracy number tells you nothing about what to fix.
Preserve tables, headings, and layout at ingestion — most retrieval failures are created here, before anything is embedded.
Split on document structure rather than a fixed token count, so a chunk is a coherent unit with its context attached.
Embeddings plus lexical search plus metadata, because pure vector search misses exact identifiers and product codes.
Hybrid search with permission filters applied at query time, then reranking to put the genuinely relevant passage first.
Generate strictly from retrieved content with citations enforced, and abstain when confidence is below threshold.
These are the levers we tune against your corpus. There is no universally correct setting for any of them.
Dense vectors find meaning; lexical search finds exact part numbers, clause references, and error codes. Production systems need both, weighted for your corpus.
Structure-aware splitting with overlap and parent-document retrieval, so a matched fragment brings its surrounding context with it.
A second-pass model reorders candidates so the genuinely relevant passage reaches the context window, not merely a similar-looking one.
Document type, date, department, and version as first-class filters, so retrieval can be scoped before similarity is ever considered.
Rewriting, decomposition, and expansion so a vague or multi-part question becomes retrievable rather than returning noise.
Incremental updates as source documents change, so the index reflects current truth without a full rebuild each time.
This is the requirement that most often separates an internal demo from something legal will let you deploy.
The user's permissions constrain the candidate set before retrieval runs, rather than filtering results afterwards — which would still leak existence and content through the model.
Access rights are synced from SharePoint, Google Drive, or your identity provider, so the assistant inherits your existing model instead of maintaining a second one that drifts.
Every cited source resolves to a document the asking user can retrieve themselves, which is both a verification path and a permissions check.
Where documents cannot leave a network or jurisdiction, the retrieval layer and models run within it, including fully self-hosted configurations.
Without an evaluation set, every change to a RAG system is a guess. This is the part most projects skip and later regret.
We score whether the right passage was retrieved at all, independently of whether the answer read well. Conflating the two makes failures undiagnosable.
Questions your users actually ask, including the ambiguous and unanswerable ones, with expected sources identified. Built during the project and owned by you.
Chunking, embedding model, reranker, and prompt changes all run against the full set first, so an improvement on one question type cannot silently break another.
Saying "I do not know" on an unanswerable question is a correct answer, and we score it as one rather than treating coverage as the only goal.
Our open-source tooling exists because we needed these layers repeatedly — they are public and auditable rather than a black box.
Layout-preserving document parsing, including tables and multi-column content that standard parsers flatten. This is where LongParser came from.
Hybrid search with permission filters and a reranking pass, tuned against your corpus rather than a default configuration.
Generation constrained to retrieved content, with citation enforcement so an uncited claim does not reach the user.
Versioned test sets scoring retrieval and answer quality separately, run in CI. This is what LongProbe does.
Per-query traces covering retrieved chunks, scores, tokens, latency, and cost, with ungrounded-claim detection. This is what LongTracer does.
Incremental re-indexing as sources change, including supersession, so the index does not quietly drift away from current truth.
Connector quality and permission fidelity matter more than connector count.
Document Repositories
Business Systems
Databases & Warehouses
Identity
If something is already live, we review retrieval accuracy, grounding, latency, cost, and guardrails, and tell you what to fix first.
Real questions with expected sources, built before tuning begins, so every subsequent decision is measurable rather than felt.
We get the right passages surfacing reliably before spending time on answer phrasing, because the reverse order wastes the most time.
Deployed with per-query tracing, freshness pipeline, and the evaluation harness handed over so your team can keep changing it safely.
Vector store and model choices follow the corpus and the deployment constraints. Both sit behind abstractions so they stay swappable.
A reliability check reviews retrieval accuracy, grounding, permissions, latency, cost, and guardrails on a system you already have in production — and tells you which fix will move the needle first.