The Retrieval System

MARCUS answers questions by retrieving project-scoped source material first and generating second. That order is one of the most important things to understand about the system.

If you remember only one idea from this page, remember this: MARCUS is designed to answer from your corpus, not merely about your topic.

Why Retrieval Comes First

Without retrieval, a language model answers from general training and pattern recall. That can be useful for broad explanation, but it is not enough for a product whose purpose is to work from your institution's documents and policies.

MARCUS changes that sequence:

1. it looks for relevant evidence in the indexed project corpus
2. it assembles that evidence into context
3. only then does it generate the answer

This is what makes citations, source grounding, and project-specific answers possible.

High-Level Flow

At a high level, the pipeline looks like this:

1. The user submits a query.
2. MARCUS analyzes the question and determines how to search for it.
3. The system embeds the query and searches indexed chunks.
4. Candidate passages are ranked and filtered.
5. Context is assembled from the strongest passages.
6. The answer is generated with citations back to those sources.

That sounds simple on paper, but each stage matters because weaknesses in any one stage can limit the final answer.

Stage 1: Query Analysis

When you type a question, MARCUS first tries to understand what kind of question it is asking.

Examples:

• Is this a threshold question?
• Is this a procedural question?
• Is this a comparison between sources?
• Is this asking for local policy, general background, or both?

This stage matters because the system needs to know what to search for before it can search well.

Stage 2: Search Preparation

Once the system understands the question, it prepares it for retrieval. This usually includes building a retrieval-friendly representation of the query and deciding which sources or chunks are even eligible to be searched.

The project boundary matters here. MARCUS should search only the scope the user intended, not every document everywhere.

Stage 3: Candidate Retrieval

The system then searches the indexed chunks and collects candidate passages that appear relevant.

This is the stage where several practical realities show up:

• if the relevant source was never uploaded, it cannot be retrieved
• if the source is not indexed yet, it cannot be retrieved
• if the project contains many unrelated documents, weak but noisy matches may compete with strong ones
• if the question is vague, the candidate set may also be vague

This is why corpus quality and question quality matter so much.

Stage 4: Ranking And Filtering

Not every candidate passage should appear in the final context. MARCUS ranks and filters the candidates to decide which passages deserve more weight.

Factors that can influence this include:

• semantic relevance to the query
• source quality and authority
• whether several passages reinforce the same answer
• whether a passage comes from a document that fits the query context well

You can think of this as the difference between "this passage mentioned the topic" and "this passage is actually important for answering the question."

Stage 5: Context Assembly

The system then builds a temporary evidence packet from the selected passages. This packet is what the language model actually sees when it writes the answer.

This step matters because the model is not reading the whole corpus at answer time. It is reading the curated subset that retrieval assembled.

That means:

• good retrieval creates a strong answer opportunity
• weak retrieval caps the answer quality even if the model itself is strong

Stage 6: Generation With Citations

Finally, MARCUS generates the answer using the assembled context and packages citations so the user can audit the evidence chain.

This is why a grounded answer is not just prose. It is prose tied to retrieved passages from a defined source set.

What The User Sees During Streaming

During streaming, the frontend shows status messages while the backend moves through steps such as:

• query analysis
• search preparation
• searching and ranking
• context assembly
• response planning
• composition

Then the answer text streams, followed by citations and completion metadata.

These messages are not cosmetic. They help the user understand whether the system is searching in the direction they expect.

What Most Strongly Shapes Answer Quality

In day-to-day use, answer quality is usually driven most by:

• the relevance and quality of the source corpus
• the clarity of the project boundary
• the specificity of the query
• the authority of the retrieved sources
• whether the best source was actually available to retrieve

People sometimes assume the model is the dominant factor. In MARCUS, the corpus and retrieval pipeline often matter more.

Why Good Projects Feel So Different From Bad Ones

In a well-structured project:

• the right documents are eligible to retrieve together
• the retrieved passages reinforce each other more often
• citations feel expected and interpretable
• follow-up questions narrow cleanly

In a poorly structured project:

• irrelevant documents keep intruding
• answers feel generic
• citations look surprising
• users feel they have to "fight" the system with more elaborate prompts

This difference usually comes from retrieval conditions, not from superficial UI differences.

What Retrieval Does Not Solve By Itself

Retrieval improves grounding, but it does not automatically guarantee:

• that the project contains the complete evidence base
• that conflicting sources are resolved
• that the most locally controlling document was uploaded
• that the answer matches a special-case patient or workflow situation

That is why MARCUS still expects the user to open citations and apply judgment.

Practical Implication For Users

If MARCUS is giving vague or weakly supported answers, the fix is usually one of the following:

• narrow the question
• improve the project corpus
• remove conflicting or outdated files
• add stronger, more authoritative sources
• verify that the relevant source actually finished indexing

This is the most important operational insight about MARCUS: when answer quality drops, inspect the retrieval conditions before assuming the model simply "did a bad job."