When teams talk about RAG, the conversation quickly moves to vector databases, embeddings, chunk sizes, Top-K, hybrid search, and rerankers. That sequence feels natural: split documents well, embed them well, retrieve the closest passages, and the answer quality should improve.
In enterprise systems, however, there is a question that comes before retrieval quality.
Why was this document allowed into the candidate corpus for this task?
If that question is unresolved, a better retriever can become very good at finding the best documents inside the wrong search space. That is the pattern I ran into again while designing a B2B Deal Intelligence and RFP-oriented Market Intelligence flow.
Relevance and business eligibility are different decisions
An enterprise knowledge estate contains many documents that look semantically similar: previous proposals, customer references, product collateral, market reports, win/loss notes, delivery material, partner documents, and current account context.
A semantic retriever may correctly rank a proposal from another customer very highly for a new logistics-automation opportunity. From an information-retrieval perspective, that can be a strong match.
But business eligibility is a separate question. The document may contain confidential customer context. Its commercial assumptions may not apply to the current deal. It may describe an obsolete capability, or it may belong to a solution scope that the current opportunity does not actually own.
Enterprise RAG therefore needs two distinct gates:
- Is it relevant? — Is the content semantically useful for the query?
- Is it eligible? — Is this source valid for the current task, authority boundary, time horizon, and scope?
The eligibility question comes first.
This changes the conceptual pipeline from a simple Query → Retrieval → Generation sequence to something closer to:
Business Context → Retrieval Scope → Eligible Sources → Retrieval → Evidence Validation → Generation
Semantic search still matters. Its role simply becomes clearer: it should rank what matters inside an already valid business scope, rather than decide on its own what the business scope is.
Turn Deal Context into a Retrieval Scope Contract
For a B2B deal, an account name alone is rarely enough to determine that scope. Retrieval eligibility is usually a function of several dimensions: the opportunity, stage, industry, offering, region, active solution scope, research intent, and the date from which evidence should be considered current.
A simplified context object might look like this:
{
"account": "Customer A",
"opportunity_id": "OPP-2026-001",
"deal_stage": "RFP",
"industry": "Retail",
"offering": "Logistics Automation",
"region": "KR",
"solution_scope": ["WCS", "Control Integration", "Commissioning"],
"research_intent": "competitive_strategy",
"as_of": "2026-10-02"
}The value is not in the JSON format itself. The value is that these fields become retrieval-routing keys.
If the deal is Retail × Logistics Automation, the system can first resolve which references, competitive material, internal knowledge, and current external evidence are eligible for that combination. Only then does semantic ranking begin.
I think of this as a Retrieval Scope Contract, not merely metadata filtering. The contract can also state what a source is allowed to prove, how current it must be, and for which business purpose it can be used.
A word in an RFP does not automatically create a research scope
This became especially clear in a recent Market Intelligence Agent pilot for a logistics-automation RFP. The bundle contained many terms that could easily trigger new research paths: cloud, network, security, AI, robotics, and other adjacent technologies.
A keyword-driven approach could have opened a separate research branch for each of them. It would have produced more information, but also more context that was not necessarily material to the actual deal.
The pilot separated four different signals:
Mention ≠ Integration Dependency ≠ Scope Ownership ≠ Active Research Grain
Security appearing in an RFP does not automatically make Security a standalone offering in the deal. AWS appearing in an architecture section does not automatically turn the opportunity into a cloud-transformation engagement. A robotics reference does not automatically justify a separate robotics-market research track.
Only areas with confirmed scope ownership and material strategic relevance were promoted to an active research grain. Other signals remained CONTEXT_ONLY. The primary research grain ultimately stayed bounded to a single Industry × Offering axis.
The point was not that searching less is inherently better. The important result was that the system could explain why one area was searched and another was not.
That explanation matters in enterprise work because adding more retrieved context does not only add useful evidence. It can also mix different source authorities, time horizons, customers, and commercial assumptions into the same model context.
Metadata filters are implementation details, not the architecture
It would be easy to reduce this argument to a tip such as WHERE industry = 'Retail'. Metadata filters are useful, but they are only one implementation mechanism.
Two documents can share the same industry and offering metadata while having different business eligibility. One may be a reference that cannot be reused for the current account. Another may describe a three-year-old capability that no longer proves the current state. Public market evidence and internal win/loss material can both be valuable, but they do not carry the same authority for the same claims.
A useful separation is:
- Business Context — Which Account, Opportunity, Case, or RFP is being handled?
- Source Eligibility / Authority — Which source classes may be used, and what may they support?
- Retrieval Mechanics — Inside that bounded space, should the system use vector search, keyword search, SQL, an API, or web search?
A vector database metadata filter sits in the third layer. So do Salesforce queries, SharePoint folder boundaries, document ACLs, SQL predicates, and domain-restricted web research.
The architecture should therefore start from the business boundary and let the retrieval infrastructure implement it—not the other way around.
Before tuning embeddings, inspect the candidate corpus
When a RAG answer looks wrong, teams often investigate familiar knobs:
- chunk size
- embedding quality
- hybrid search
- Top-K
- reranking
- query rewriting
All of them matter. But enterprise diagnosis needs one earlier question:
Why was this document in the candidate corpus at all?
If material from the wrong account, another deal, an obsolete policy, or an unauthorized source has already entered the candidate set, a better reranker may reduce some symptoms without fixing the scope error.
When the candidate space is business-valid, the retriever’s job becomes simpler in a more important sense. The system stops forcing evidence that should never compete with each other into the same ranking pool.
Evaluate scope quality before Recall@K
Recall@K, Precision@K, MRR, and NDCG remain useful retrieval metrics. Enterprise RAG needs an additional layer of evaluation around the scope itself.
| Dimension | Question |
|---|---|
| Scope Precision | How much of the candidate set actually belongs to the current business scope? |
| Authority Violation | Was a source used to support a claim it is not authorized or suitable to prove? |
| Temporal Validity | Is the evidence still valid for the current as-of date? |
| Context Coverage | Was enough Account/Deal/Product context resolved before retrieval began? |
| Cross-scope Leakage | Did material from another customer, deal, or tenant enter the current scope? |
Cross-scope leakage is especially important because it is not merely an answer-quality issue. In customer- or tenant-sensitive systems, retrieval quality and authorization boundaries meet at the same point.
There is an obvious trade-off: aggressive scope restriction can reduce recall and exclude useful evidence. Context-first RAG is therefore not a claim that smaller search spaces are always better. It is a claim that business eligibility should be explicit, and the recall cost of that boundary should be measured rather than left implicit.
Let Context control Retrieval, and Retrieval control Model Context
Better embeddings and rerankers absolutely matter. What they cannot decide by themselves is which knowledge is legitimate evidence for the business task in front of them.
The design principle I took away from building the Deal Intelligence flow is straightforward:
Context should control Retrieval, and Retrieval should control Model Context.
If the entire enterprise knowledge estate is exposed first and the LLM is expected to sort out relevance, policy, authority, and scope by itself, several different control problems have been collapsed into one probabilistic step.
If Account, Deal Stage, Industry, Offering, Scope, Source Authority, and as-of context first constrain the candidate space, semantic retrieval can focus on the problem it is actually good at: ranking what matters inside a valid boundary.
A good Enterprise RAG system is not the one that shows the model the most knowledge.
It is closer to a system that shows the model only the knowledge that is eligible for this task, at the moment it is needed.