Most enterprise AI programs in life sciences do not fail because the language model is too small. They fail because the context layer is under-designed: wrong documents, wrong tables, wrong ontology concepts, or too much noise reaching the agent.
This article is about how to build that layer — the ideal context intelligence engine. If you are still deciding whether you need a graph, governed crosswalks, or hybrid retrieval alone, start with our companion piece: To Graph or Not to Graph?. It provides a tier-based decision matrix for semantic governance. This post focuses on the engineering principles that make retrieval work in production.
LLM proposes. Governed mappings validate. Hybrid retrieval retrieves and ranks.
Retrieval is the product — the model is the articulation layer
In regulated life sciences, a fluent answer is not enough. The system must return the right reference — fast, accurate, and traceable to approved content.
Enterprise conversations often jump straight to knowledge graphs, ontology platforms, and semantic modeling projects. Those investments matter at maturity. But many teams stall because they try to model an entire therapeutic area before they can reliably answer one HCP question from one approved document.
The practical learning path is different:
- Get hybrid retrieval and ranking right on your corpus.
- Add governed ontology infrastructure where tier and compliance require it.
- Package context for agents — not as chunk dumps, but as ranked, provenance-tagged briefings.
That is what a context intelligence engine does. It is not generic RAG with a larger embedding model. It is a governed pipeline with three distinct engineering stages, each with its own optimization target. Conflating them is the most common mistake we see in pharma AI programs.
A worked example: one HCP question, four constraints
A medical science liaison sits across from a cardiologist at a congress. The physician asks:
"What is the recommended starting dose of Vasculor for Stage II hypertension in adults, and what is the titration range if blood pressure is still uncontrolled?"
The MSL does not need a fluent paragraph. They need the right reference — fast, accurate, and traceable:
- the Vasculor HCP Prescribing Guide,
- the dosing table on page 12, and
- the section that distinguishes Stage II from Stage I initiation.
The large language model is the articulation layer. The retrieval engine is the trust layer. In front of an HCP, returning the mechanism-of-action slide or a Stage I footnote is not a demo failure — it is a compliance and credibility failure.
This question bundles four constraints that map directly to retrieval design:
| Constraint | What the system must resolve |
|---|---|
| Brand / product | Vasculor — not a competitor or drug-class overview |
| Severity | Stage II hypertension — not general BP management |
| Population | Adults |
| Evidence type | Starting dose and titration range — numeric, tabular, label-derived |
Search-based AI should treat this as constraint satisfaction, not mere semantic similarity. If retrieval returns the wrong section, the LLM will still sound polished. That is why retrieval design comes first.
Retrieval fundamentals — before you model the universe
Before investing in graph infrastructure, most teams should master these capabilities on their approved content:
Lexical matching (BM25) — exact brand names, drug classes, stage labels, and section headings. Critical when the query contains precise product language.
Structure-aware lexical features — proximity, orderedness, and completeness for multi-constraint HCP queries. "Stage II" near "starting dose" should outrank a passing mention in a safety appendix.
Semantic retrieval — text embeddings when guidelines use different language than the rep or MSL ("initiation dose" vs "starting dose").
Multi-representation indexing — separate index strategies for narrative text, tables, charts, and label sections — not one blended vector for the whole PDF.
Multi-phase ranking — a fast first pass for recall, a second pass for precision before the LLM speaks.
What can a graph add?
Knowledge graphs can link brands, indications, contraindications, and internal taxonomies across systems. Treat them as a maturity step, not a prerequisite. Add graph structure when it solves a clear gap: entity linking across silos, policy traversal, or steward-curated synonym control. For many field and medical affairs workflows, hybrid retrieval on approved content is the right starting point.
Read the tier framework and decision matrix in To Graph or Not to Graph? before committing to graph build-out.
Stage 1: Ingestion — preserve structure, not just text
Most pipelines treat ingestion as OCR-with-extra-steps. They destroy the structural information that makes pharma documents useful: tables, charts, headers, footnotes, cross-references, and the relationship between visual and textual content on the same page.
For the Vasculor question, ingestion must ensure the dosing table on page 12 is indexed as a table — with headers, units, stage labels, and footnotes — not as a flattened paragraph lost between adjacent sections.
Principles:
- Index CSRs and labels with section-aware chunking — outcomes tables as tables, not paragraphs
- Preserve ontology exports with full synonym, definition, and hierarchy metadata
- Ingest mapping tables with confidence scores, provenance, and version attributes
- Attach structural metadata to every indexed unit for retrieval-time routing
Ingestion optimizes for fidelity. If structure is lost here, no ranking model recovers it reliably.
Stage 2: Indexing — multi-representation, not one-size-fits-all
A single embedding model applied uniformly across all content types is a compromise that satisfies no one. The index should maintain multiple representations of the same knowledge, each optimized for different query types.
| Content type | Index representation | Query type |
|---|---|---|
| Ontology concepts | Hybrid lexical + dense embeddings on labels/synonyms | Concept disambiguation |
| Clinical documents | Section-aware chunks + table/chart embeddings | Evidence retrieval |
| Safety tables | Structured field indexing + sparse matching | Factual lookup |
| Crosswalk mappings | Multi-signal attributes: confidence, version, domain | Mapping ranking |
| Business rules | Rule text + metadata filters | Policy enforcement |
| HCP / label content | Section-tagged chunks + table extraction | Dose, contraindication, indication lookup |
When a user asks a factual question ("What is the Stage II starting dose?"), the system routes to the representation most likely to contain a precise answer. When they ask an analytical question ("How does titration differ across stages?"), it routes differently. This query-aware routing keeps token budgets tight without sacrificing recall.
Indexing optimizes for recall with the right representation.
Stage 3: Retrieval — rank, don't just retrieve
Vector similarity is a starting point, not an endpoint. The retrieval pipeline operates as a sequence, not a single lookup:
- Query understanding — the LLM decomposes intent and identifies relevant namespaces (product label, medical guide, internal policy)
- Candidate generation — hybrid retrieval surfaces broad evidence candidates across representations
- Validation — for Tier 2/3 use cases, governed mappings confirm or override proposals (see companion article)
- Multi-signal ranking — score by relevance, structural match, version, source authority, and domain
- Context assembly — deduplicate, provenance-tag, and package for agent delivery via MCP
The output is not a list of chunks. It is a structured context package: ranked, deduplicated, and sized to the agent's task. Each item carries source document, page or section, concept ID where applicable, extraction confidence, and timestamp.
For the Vasculor question, the package might contain three items — prescribing guide reference, page-12 dosing table, Stage II initiation section — not twenty chunks from across the brand corpus.
Retrieval optimizes for precision and trust.
Context window vs context layer
A naive RAG pipeline retrieving top-10 chunks at 512 tokens each sends 5,120 tokens of context per query. Accuracy on enterprise corpora often lands around 60–70% — meaning three in ten queries get wrong or incomplete answers, each costing a full inference run plus human correction.
A well-architected context engine sends 1,500–2,500 tokens per query — less than half the volume — with accuracy in the 85–92% range on the same corpus. The savings compound: lower input costs, faster inference, cheaper model tiers, and fewer failed queries.
The goal is not to fill the context window. It is to send the smallest amount of governed, explainable information that lets the agent answer correctly.
That is the difference between a context window and a context layer.
Reference architecture: where theHaZe.ai fits
theHaZe.ai implements this architecture as an MCP-enabled context intelligence layer deployed in the customer's cloud. It does not replace existing ontology infrastructure, warehouses, or document repositories. It mediates between enterprise knowledge and agent reasoning.
| Component | Role |
|---|---|
| Agent (Claude, copilot, workflow) | Consumes ranked context packages via MCP |
| theHaZe.ai orchestration | Query decomposition, tier-aware routing, context packaging |
| LLM | Intent recognition, concept proposal, sub-query generation |
| Hybrid retrieval engine | Hybrid search, synonym expansion, multi-signal ranking |
| Governed mapping store | Crosswalks, hierarchies, provenance — when tier requires |
| Enterprise data | Snowflake, Databricks, BigQuery, S3, document repos |
Query flow: understand → propose → validate (if required) → retrieve → rank → package.
For non-regulated retrieval — field insights, medical affairs Q&A, competitive intelligence — theHaZe.ai uses multimodal retrieval, metadata, and machine-learned ranking across documents, decks, PDFs, tables, charts, and structured sources.
For governed workflows — safety coding, cross-ontology analytics, regulated terminology — theHaZe.ai calls the customer's existing graph, terminology server, or mapping tables and retrieves only approved relationships.
We do not force a graph where hybrid retrieval is enough. We do not infer relationships where governance is required. We orchestrate both.
What to measure before you scale
Teams that skip retrieval evaluation deploy three times and learn the same lesson. Measure these before committing to production:
- Recall@k — is the correct document or passage in the top results?
- Passage / table accuracy — did the system return the specific table or section, not just the right file?
- Context assembly accuracy — given the retrieved package, does the agent produce the correct, traceable answer?
- Tokens per successful query — are you paying for noise?
Separate retrieval failures from generation failures. Most production misses in enterprise RAG trace back to retrieval — not the LLM.
TL;DR
A context intelligence engine is not a bigger vector database. It is a three-stage pipeline — ingestion, indexing, retrieval — with tier-aware governance on top.
- Master hybrid retrieval and ranking on approved content before over-investing in graph modeling.
- Preserve document structure at ingestion; index multiple representations; rank before the LLM speaks.
- Package provenance-tagged context for agents — not chunk dumps.
- Use governed ontology infrastructure where compliance demands deterministic mapping.
Next steps
1. Download the companion decision matrix
Not sure whether your use cases need a graph, governed crosswalks, or retrieval alone? Download To Graph or Not to Graph? — our tier-based decision matrix for life sciences context architecture.
Download the decision matrix → (gated — Formspree: https://formspree.io/f/xpqkznpy)
2. Architecture review
We'll assess your corpora, ontology landscape, and agent use cases and recommend a tier-aware context design. (advisory)
3. Design partner program
Deploy theHaZe.ai on your data with measurable context assembly accuracy. (build)
Contact: hello@thehaze.ai · thehaze.ai
Companion reading: To Graph or Not to Graph? Designing the Life Sciences Context Layer for Enterprise AI