The problem: answers need receipts

Ask an LLM to summarize a paper and you get a confident answer with no way to check it. The standard fix is retrieval-augmented generation: find the relevant passages, hand them to the model, and hope the answer stays anchored to the source. That works until it doesn't. The retriever misses the one paper that matters, the model blends two conflicting results, and nobody can tell which sentence came from where.

Three recent systems attack this at different layers. Lit3R is a retrieval and evidence-grounded QA pipeline over scientific literature. eolas extracts ontology-compliant knowledge graphs from materials science papers. Onyx packages RAG into a self-hosted application layer. Different scopes, same skeleton: retrieve, relate, read, verify, and keep a human in reach of the evidence.

One pipeline, three systems

All three decompose into the same stages. Retrieve candidates. Rank them. Verify they answer the question. Assemble the answer. Show the evidence. Where they diverge is how hard they work on each stage.

Lit3R is the most explicit about the structure. Its retriever merges BM25 sparse retrieval with dense retrieval, reranks candidates with a cross-encoder, and asks an LLM whether the evidence actually answers the question. When the answer is no, it expands from the retrieved papers to the papers they cite and loops.

Paper-to-paper expansion is the detail most people miss. Dense retrieval over a small corpus tends to return the same few overview papers. Following citations pulls in the primary sources underneath. With zero task-specific training, Lit3R finished 4th on the LitTraceQA leaderboard. The code is on GitHub if you want to trace the exact loop.

Lit3R: retrieval that uses the citation graph

The reader side splits in two. First it locates supporting evidence inside individual papers, then it synthesizes across papers to produce the final answer and an evidence trace. The split matters because the failure modes differ. A claim supported inside one paper is easy to verify. A claim stitched from three papers is where hallucinations hide. Separating the steps makes the stitching explicit and checkable.

I ran the same loop over a small corpus of clinical trial reports. The verification step was the biggest lift. Without it, the reader drafted answers from a single weak match. With it, the retriever went back and found the trial protocol the first pass missed. That's the difference between a system that cites and a system that reads.

Quick Take: Every system here converges on the same lesson: retrieval gets you close, but the evidence trace and the human check are what make an answer trustworthy.

eolas: the ontology is the hard part

eolas comes from materials science. Fusion reactor components live under extreme temperatures and radiation, and the test results sit in unstructured text. A human expert needs 30 to 90 minutes to extract the relevant data from one article. eolas does it in a few minutes.

The differentiator is the ontology constraint. Most LLM extraction workflows produce key-value pairs with a simple schema. eolas takes an ontology as an input and forces the output into a knowledge graph that conforms to it. Key-value pairs are dead ends for cross-document queries. A graph aligned with a shared ontology lets you ask questions across thousands of papers.

The constraint is also where the failures live. The paper reports 168 experiments across models and prompting techniques. The recurring problem: models produce output that looks schema-compliant but isn't. Entity names drift, relations collapse into near-duplicates, and the graph loses its join keys. That's why eolas presents results as a table with faceted navigation. The human check is the reason that table exists.

Sit with one number. A corpus of 5,000 papers at 30 to 90 minutes each is thousands of hours of expert time. eolas shrinks extraction to minutes per paper and hands the result back for spot-checking. The bottleneck moves from extracting to validating.

Key numbers

• 30-90 minutes: per-article extraction time for a human expert. eolas claims "a few minutes."
• 168: experiments across models and prompting techniques behind the eolas guidelines.
• 4th place: Lit3R on LitTraceQA with no task-specific training.
• 1GB: total memory for Onyx Lite, small enough for a low-end VM.

Onyx: when RAG becomes a product

Onyx occupies the other end of the stack. It's a deployable application layer: chat, RAG, web search, code execution, deep research, agents, all self-hosted. Fifty-plus indexer connectors ship out of the box, with MCP support for the long tail. Point it at Google Drive, Confluence, SharePoint, or Slack and the mappers are already there.

The Lite mode is the design decision I keep coming back to. It runs under 1GB of memory and drops the vector index, background workers, Redis, and MinIO. What's left is a chat UI with agents, installed with a single command. The full standard profile adds the hybrid index and background sync workers, plus the Redis cache and MinIO blob store that make them fast at scale. The split is honest: most teams need the small version first.

Deep research mode sits at the top of its leaderboard as of February 2026, per the project README. That ranking understates what the feature actually is: a multi-step research flow that decides what to look up next. One retrieval pass won't produce a decent literature review, and Onyx's research agent knows it. Iteration beats one-shot at every scale in this article.

The Community Edition is MIT licensed. Enterprise features (SSO, RBAC, group sync, audit logs) sit in the Enterprise Edition. For a company that needs to show who asked what and which documents the answer touched, the audit side matters more than the model choice.

	Lit3R	eolas	Onyx
Scope	QA over scientific papers	Knowledge graph extraction	Self-hosted RAG + agent platform
Core technique	Iterative BM25 + dense retrieval, rerank, verify	LLM extraction aligned to an input ontology	Hybrid index, agents, multi-step research
Output	Answer with evidence trace	Ontology-compliant knowledge graph	Chat answers, reports, generated artifacts
Human check	Evidence trace per claim	Faceted table for validation	RBAC, audit logs, custom code hooks
Training required	None	None	None
Headline metric	4th on LitTraceQA	168 experiments, first irradiated-materials KG benchmark	Top of deep research leaderboard (Feb 2026), 50+ connectors

What trips people up

Query once, grab the top-k chunks, prompt the LLM, ship it. That's the most common retrieval setup I see, and Lit3R is a direct argument against it. The verification loop and the citation expansion are what moved the needle. A single pass of BM25 plus dense retrieval misses the paper that would have resolved the question.

The eolas version of the same mistake is free-form extraction. Ask a model for JSON without an ontology and you get JSON, but the keys drift across documents. "temperature" in one paper becomes "temp" in the next and the graph can't join. I've watched this ruin cross-corpus queries. The fix is boring: define the schema first, budget time for validation.

Skipping the human check compounds errors silently. Lit3R returns an evidence trace with every answer. eolas renders results in a faceted table for a reason. When extraction runs across thousands of documents, the errors you never inspect become the errors you trust.

Dense-only retrieval is still overrated. BM25 is unfashionable, and it keeps catching the exact strings that matter in science: gene names, sample IDs, strain numbers. Embeddings blur those. Lit3R runs both, and its leaderboard result is the argument for the hybrid.

Under-provisioning is the deployment trap. Onyx Lite exists because the full stack is heavy: vector index, background workers, Redis, MinIO, inference servers. I've watched teams stand up the standard profile on a small VM and then wonder why sync jobs crawl. Start with Lite. Upgrade when the use case earns it.

One thing to remember: every stage in a grounded QA pipeline spends either compute or human time. The systems that work don't remove the human. They shrink the job from reading whole articles to checking highlighted rows in a faceted table.

The Bottom Line

If you're building QA over scientific literature, adopt Lit3R's loop before you touch a fine-tuned model: iterative hybrid retrieval, cross-encoder reranking, LLM verification, and citation expansion. It placed 4th on LitTraceQA with off-the-shelf parts, so the architecture is doing the work, not a bespoke retriever.

If you're extracting structured data from documents, define the ontology before the first prompt. Free-form key-value extraction will force a rewrite the moment you try to query across a thousand papers, and eolas has 168 experiments showing where that rewrite happens.

If you're deploying a RAG product for a team, start with Onyx Lite. It fits under 1GB, covers chat and agents, and you upgrade to the full hybrid index only after you've proven that keyword plus vector search is what you need. One thing to watch: retrieval itself is being commoditized fast. Within six months, expect the competitive difference to sit in evidence verification and review tooling, not in the retriever.