Do you need a graph database to model semantics accurately? Or can modern medical LLMs combined with a hybrid retrieval engine and learning-to-rank strategies replace that layer?
Pharma enterprises are racing to deploy AI agents across research, clinical operations, safety, regulatory, and commercial functions. For enterprise IT teams building these systems, the top priority is no longer model selection; it is context: which ontology concepts, evidence objects, rules, and data attributes reach the agent for each task.
Life sciences context engines must operate across standardized ontologies like MedDRA and SNOMED CT, internal vocabularies, structured warehouses, and sparse document corpora: often under strict governance requirements.
For years, enterprises encoded these relationships in graph ontologies. However building a graph is relatively straightforward. Maintaining it across ontology releases, new crosswalks, and evolving business rules is not. Semantic accuracy has become one of the defining questions in enterprise AI and there is more than one way to solve it. Let's uncover what they are.
What do we mean by semantic search?
Modern reasoning and embedding models are already good at understanding related medical, scientific, and commercial terminology. They can often recognize that a disease, synonym, drug class, adverse event, endpoint, brand, molecule, indication, or therapeutic area may be related, even when the exact wording differs.
This does not necessarily mean the models have been explicitly trained on every public ontology in a governed way. But many foundation and biomedical language models have absorbed biomedical terminology from scientific literature, clinical language, regulatory content, and other public sources. As a result, these models are useful for semantic discovery: mining candidate relationships, expanding queries, identifying synonyms, normalizing language, and retrieving conceptually related content.
For example, a model can often understand that:
- "heart attack" is related to "myocardial infarction."
- "high blood sugar" is related to "hyperglycemia."
- "semaglutide" is related to "Ozempic," "Wegovy," "GLP-1 receptor agonists," Type 2 Diabetes, obesity, and cardiometabolic risk.
For many knowledge discovery and document retrieval use cases, embedding based semantic retrieval is extremely useful. You do not always need a graph to find related language
Graph or no graph? Inference vs. fact: the governance line
However this does not mean the model should become the system of record. That separation is critical.
A graph is not inherently wrong for pharma context layers. It is often valuable, but not always required. The distinction that matters is between inference and fact, non-deterministic and deterministic paradigms:
- A model can propose that two concepts are related → an inference, non-deterministic
- A governed store can validate that the relationship is approved → a fact, deterministic
Not every question needs regulatory rigor that needs to be grounded in fact. A few can rely on an LLM to make the final semantic determination.
Therefore the question is not "graph or no graph." It is when to use what:
Which relationships need to be governed, validated, versioned, and auditable — and which can be inferred, retrieved, or ranked at query time?
In simpler terms:
Which use cases need a deterministic paradigm, and which can be exploratory?
LLM proposes. Governed mappings validate. Hybrid retrieval retrieves and ranks across both
What this means for enterprise architecture
If a graph already exists in R&D, medical, safety, or ontology management, use it. Do not duplicate it inside an AI application. Let the graph, or equivalent governed mapping store, remain the authoritative relationship layer where the business requires it.
But recognize that the graph is only one part of the enterprise context layer.
A complete AI answer may need structured data from Snowflake, Databricks, BigQuery, or analytics marts. It may need unstructured and multimodal content from PDFs, PowerPoint decks, tables, charts, images, and documents. It may need graph relationships from ontology stores, terminology systems, or knowledge graphs. It may need reasoning models to interpret the question and propose semantic paths. It may need a hybrid retrieval engine to rank and package the right context.
The enterprise AI layer therefore should not replace the graph, warehouse, or document repositories.
It should make them agent-queryable.
Graphs and LLMs solve different parts of the problem. For a significant class of use cases, a third layer, retrieval and ranking intelligence, can substitute for the graph's disambiguation role entirely, leaving governed mappings needed only where compliance demands it.
So when is a graph or ontology relationship store required
What is needed is a governed relationship store when mappings must be trusted. You cannot eliminate a separate ontology store when dealing with:
- Governed crosswalks for pharmacovigilance and regulatory coded output
- Version-exact terminology resolution for submission datasets
- Steward-approved mapping provenance where auditors require it
- Business rules that override semantic similarity (e.g. "always use MedDRA for AE reporting")
That store can be:
- A graph database
- Mapping tables in Snowflake or Databricks
- A reference data management system
- A terminology server
Graph is strongest when you need multi-hop traversals, path explanation, complex relationship queries, and cross-ontology navigation with provenance.
Hybrid retrieval may be enough when you only need concept lookup, synonym expansion, document and evidence retrieval, and agent context packaging; with simpler mapping tables where needed. Architecting such a hybrid retrieval is what we call a retrieval intelligence stack.
The cases where retrieval intelligence replaces graph investment share a common profile:
- The use case tolerates probabilistic concept resolution
- The primary output is agent assistance rather than coded regulatory data
- The retrieval pipeline is engineered to production standard — not demo standard
Three tiers: classify before you architect
Before selecting infrastructure, classify your agent use cases by governance tier. The decision to use a graph, governed mapping tables, or LLM-only resolution should be driven by use case tier, not technology preference.
| Tier | Pattern | Governed mappings | Good for |
|---|---|---|---|
| Tier 1 — Assistive | LLM + hybrid retrieval engine | Optional | Research assistants, copilots, competitive intelligence, document exploration |
| Tier 2 — Operational | LLM proposes → governed mappings validate → hybrid retrieval ranks | Recommended | Safety analytics, clinical ops, cohort building, cross-system analytics |
| Tier 3 — Regulated | Governed crosswalk is source of truth; LLM assists only | Required | Pharmacovigilance, regulatory reporting, EHR coding, submission datasets |
Ask three discovery questions before you build:
- Is this agent assistance or coded operational output?
- Do mappings need steward approval and audit trails?
- Are ontology versions and effective dates in scope?
Download our decision matrix paper— To Graph or Not to Graph? — for a worked example table mapping common life sciences scenarios (synonym discovery, adverse event coding, brand positioning, clinical endpoint mapping) to the right tier and architecture pattern.
The retrieval intelligence stack
Retrieval intelligence is the ability to understand a question, identify the evidence required, retrieve it from the correct sources, and assemble a coherent, ranked context package for downstream reasoning. In pharma, this operates across five layers:
| Layer | Capability | Graph alternative |
|---|---|---|
| Query understanding | Decompose intent, identify ontology namespaces | Manual query templates |
| Concept resolution | Hybrid search over labels, synonyms, codes, definitions | Graph synonym expansion |
| Evidence retrieval | Route to correct corpus, table, or structured source | Graph traversal to documents |
| Ranking | Multi-signal scoring: relevance, version, domain, confidence | Graph path length / edge weight |
| Context assembly | Deduplicate, provenance-tag, token-budget package | Subgraph export to prompt |
Teams that invest in retrieval intelligence routinely achieve production accuracy without maintaining a graph ontology layer for every use case. The graph was doing disambiguation work that a well-engineered retrieval pipeline can now handle — when the tier allows it.
Example: medical and commercial context together
Imagine a medical affairs leader asks:
"Summarize the latest evidence and field narrative for Brand X in Type 2 Diabetes patients with cardiovascular risk, and compare this with current regional performance."
A strong answer requires multiple retrieval paths:
- The model interprets that "cardiovascular risk" relates to specific clinical concepts, endpoints, comorbidities, or patient segments
- If a governed mapping store exists, the system queries it for product-to-indication mappings, drug class relationships, or internal therapeutic area taxonomy
- The structured warehouse provides regional performance, prescription trends, claims data, or patient cohort metrics
- The hybrid retrieval layer finds relevant PowerPoint slides, advisory board summaries, medical documents, field insights, embedded charts, and tables
The final answer should not be generated from one giant prompt.
It should be generated from a ranked context package.
That is the difference between a context window and a context layer.
The downloadable paper includes a five-phase implementation strategy where we talk about how to make this context come alive. To Graph or Not to Graph?
Where theHaZe.ai fits
┌─────────────────────────────────────────────────────────┐
│ Agent (Claude, internal copilot, workflow) │
└──────────────────────────┬──────────────────────────────┘
│ MCP
┌──────────────────────────▼──────────────────────────────┐
│ theHaZe.ai orchestration │
│ · query decomposition │
│ · tier-aware routing (validate or not?) │
│ · context packaging │
└──────┬───────────────────────────────┬──────────────────┘
│ │
▼ ▼
┌──────────────┐ ┌───────────────────────┐
│ LLM │ │ Governed mapping │
│ (propose) │◄────────────►│ store (customer's │
└──────┬───────┘ validate │ ontology layer) │
│ │ · graph DB │
▼ │ · Snowflake tables │
┌──────────────┐ │ · terminology server │
│ Hybrid │◄── join on stable IDs ──┘
│ retrieval │
│ engine │
│ (retrieve │
│ + rank) │
└──────┬───────┘
│
▼
┌──────────────────────────────────────────┐
│ Unstructured corpus + ontology exports │
│ (docs, CSRs, ontology flat files) │
└──────────────────────────────────────────┘Life sciences retrieval cannot rely on a single embedding model and hope for the best. A production system uses multiple retrieval signals: keyword precision, semantic embeddings, domain-specific embeddings, metadata filters, document structure, multimodal extraction, table and chart understanding, provenance, recency, authority, and machine-learned ranking.
The best answer is often not the most semantically similar result. It is the most relevant result for the specific user, domain, business context, and task.
A field insight deck, a medical summary, and a sales dashboard may all mention the same brand and disease. The right context depends on the question:
- Brand positioning → prioritize commercial narrative and approved messaging assets
- Medical evidence → prioritize clinical publications, medical summaries, and evidence documents
- Regional performance → prioritize structured data and analytics marts
theHaZe.ai does not replace the customer's graph, warehouse, analytics mart, or document repositories. It acts as the agent-facing context intelligence layer:
- Decomposes the user question and routes by governance tier
- Retrieves unstructured and multimodal context via hybrid search and multi-signal ranking
- Calls the customer's graph or terminology server where governed relationships are required
- Packages ranked, provenance-tagged context for the agent via MCP
For non-regulated semantic retrieval, theHaZe.ai uses multiple embeddings, multimodal retrieval, metadata, and machine-learned ranking across documents, decks, PDFs, tables, charts, and structured sources.
For governed workflows, theHaZe.ai calls the customer's existing ontology infrastructure and retrieves only approved relationships.
In this model:
- The reasoning model interprets intent and proposes candidates
- The governed store validates durable semantic relationships where required
- The warehouse provides structured facts
- The document base provides narrative and evidence
- theHaZe.ai retrieves, ranks, and packages the right context
We do not force a graph where AI retrieval is enough. We do not infer relationships where governance is required. We orchestrate both.
TL;DR
Semantic AI should not start with a technology choice. It should start with a governance decision.
Classify your use cases by tier. Invest in retrieval intelligence before committing to graph build-out. Use governed mappings only where compliance demands deterministic alignment.
theHaZe.ai helps life sciences enterprises design and deploy the context layer between agents and enterprise knowledge — across unstructured, structured, and governed semantic needs.
Next steps
- Download the To Graph or Not to Graph? decision matrix >> map your scenarios to the right tier and architecture pattern.
- Architecture review: we'll assess your ontologies, corpora, and agent use cases and recommend a tier-aware context design. (advisory)
- Design partner program: deploy theHaZe.ai on your data with measurable context assembly accuracy. (build)
Contact us at hello@thehaze.ai
A companion article on the ideal context intelligence engine - please feel free to read it https://thehaze.ai/blog/ideal-context-intelligence-engine-life-sciences