Building a Healthcare Copilot for Biology and Life Science Research

owkin · Healthcare · 2025 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Healthcare and life-science research copilot

Owkin needed a copilot that helped biology and life-science researchers answer scientific questions over structured biological databases and literature while respecting healthcare privacy, semantic ambiguity, cost, latency, and evaluation constraints.

Constraints:

• healthcare data is regulated and patient data cannot be casually exposed to prompts or outputs
• biology terms such as genes, proteins, and acronyms are semantically ambiguous
• large tabular and literature corpora are too expensive and slow to pass directly into an LLM
• dense semantic retrieval can miss exact biomedical terms or retrieve related but wrong protein families
• biology answers are often contextual, making generic benchmark evaluation unreliable

Architecture

Owkin built a healthcare copilot with multiple research tools: a prior-knowledge database tool that translates natural-language biology questions into simple Polars SQL over curated Parquet databases, then sends the filtered subset to another LLM for a cited answer; and a literature-search tool that retrieves PubMed abstracts with hybrid sparse+dense search, metadata filters, and reranking before generation. Monitoring runs through LangFuse and OpenTelemetry, and domain experts validate outputs.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  healthcare-copilot["Healthcare copilot"] --> prior-knowledge-database-tool["Prior knowledge database tool"]
  healthcare-copilot --> literature-search-tool["Literature search tool"]
  healthcare-copilot --> monitoring-and-feedback["Monitoring and feedback"]
  prior-knowledge-database-tool --> polars-query-engine["Polars query engine"]
  prior-knowledge-database-tool --> structured-output-layer["Structured-output layer"]
  prior-knowledge-database-tool --> sql-sandbox["SQL sandbox"]
  polars-query-engine --> answer-generation-llm["Answer generation LLM"]
  literature-search-tool --> vector-database["Vector database"]
  vector-database --> metadata-filters["Metadata filters"]
  vector-database --> reranker["Reranker"]
  reranker --> answer-generation-llm
  monitoring-and-feedback --> domain-expert-panel["Domain expert panel"]

Components

Data flow

For structured biology questions, the copilot loads curated biological data into Polars, uses an LLM with enriched column metadata to produce a simple SQL filter, validates and sandboxes that query, feeds the smaller result table or a statistical description into a second LLM, and formats the answer with database links. For literature questions, it encodes PubMed abstracts, retrieves candidates with hybrid sparse and dense vectors, filters metadata such as paper type, reranks the top results, and generates a cited answer.

Why this architecture

Owkin split the copilot into bounded tools because healthcare questions require different data access paths and controls. Text-to-SQL keeps structured database access narrow and auditable, while RAG keeps literature grounding outside model memory. Hybrid search, metadata filters, reranking, schema-constrained SQL, and domain validation were added because simple schema prompting, dense retrieval alone, and public benchmarks were inadequate for biomedical use.

Models used: Anthropic · Claude Sonnet 4 · embedding models

Scale

• The copilot was developed over four months.
  “So what we did at Okins we we developed in four months a copilot which offers for now three tools. One um that helps you v visualize patient data and visualize OMIX data. I will not talk about this but I will talk about the two other tools. one that uh enables the”transcript, stated
• Owkin had around 17 curated open-source databases for prior knowledge.
  “database. So historically at Okin uh we have uh created uh around 17 open source database. We have cleaned it automized uh automized the cleaning the um applied uh biomeds rules that they they want to look the data that they want to look at.”transcript, stated
• The structured database example involved more than 200 columns and 80,000 rows.
  “they were looking at a big Excel file two more than 200 columns 80k rows and they're trying to answer the question like this.”transcript, stated
• The PubMed literature corpus used more than 26 million abstracts.
  “they use PubMed which is one of the biggest platform where where you can find more than 26 millions uh of abstracts”transcript, stated
• Encoding the PubMed abstracts took 24 hours.
  “So here we encoded uh 26 millions it costs a lot uh and also takes a lot of time 24 hours to ingest and we internally uh ask researcher to ask this question what is the role of purin cancer plur is the name of a gene it encodes a protein called upupar and researcher were like”transcript, stated
• The hosted vector database cost roughly $800 per month.
  “roughly we so we use quadrant to host our our vector database. It cost us uh around $800 per month. But you have to think as well about the the hidden costs. So the creation of the of the embeddings which are really costly in computing um and and also uh the maintenance of the”transcript, stated

Alternatives considered (roads not taken)

Put the whole table into the LLM prompt

Rejected because: The transcript says this would not work, would exceed or stress context limits, be slow, and cost too much.

Provide only ordinary database schema to the SQL-generating LLM

Rejected because: Column names and types were not enough for biomedical semantics; column descriptions needed biological context.

Use dense semantic retrieval alone for literature search

Rejected because: Dense retrieval returned papers from a related-but-wrong protein family, so the team combined sparse and dense vectors.

Rely on public biology benchmarks for evaluation

Rejected because: The speaker argued biology answers are contextual and public benchmark items can be wrong, so domain-expert benchmarks are needed.

Patterns

rag-retrieval (retrieval)

The literature tool retrieves PubMed abstracts and passes them to an LLM so answers are grounded in external scientific documents.

hybrid-search (retrieval)

Owkin combined sparse keyword vectors with dense semantic vectors after dense-only retrieval confused exact biomedical terms with related protein-family names.

structured-output-contract (generation)

The text-to-SQL tool used Pydantic and Instructor to constrain LLM outputs to a schema and retry invalid SQL-request objects.

guardrails-io-filtering (safety)

Owkin guarded generated SQL by keyword allow/deny lists, sandbox execution, and Polars exception handling before letting queries touch data.

retrieval-ranking (retrieval)

The PubMed RAG system added metadata filtering and reranking so retrieved papers were original, relevant, and useful for answering the question.

eval-driven-development (evaluation)

Owkin treated public benchmarks as insufficient for scientific questions and used domain experts plus production feedback to validate the copilot.

privacy-preserving-processing (safety)

Healthcare privacy constraints shaped both prompt design and development data access, including avoiding patient data in prompts and using synthetic data for development.

observability-tracing (operations)

The deployed copilot used LangFuse, OpenTelemetry, and explicit user feedback to observe production behavior and feed improvement loops.

Tradeoffs

Structured database access

Chose natural-language-to-SQL over filtered subsets over passing full biological tables into the prompt.

Rationale: Filtered SQL kept the context small enough to be cheaper, faster, and more focused.

Structured output enforcement

Chose Pydantic and Instructor schema retries over free-form SQL-generation outputs.

Rationale: The team needed reliable query objects rather than extra prose around the SQL.

Literature retrieval strategy

Chose hybrid sparse+dense search with metadata filters and reranking over dense-vector semantic search alone.

Rationale: Hybrid search preserved exact biomedical term matching while dense vectors captured semantic similarity.

Security checks in the prompt path

Chose selective guardrails and data exclusion over putting sensitive prompts and patient data directly into LLM calls.

Rationale: Prompt scanning can add latency, and any prompt content must be treated as potentially extractable.

Evaluation approach

Chose custom domain-expert benchmarks and feedback over generic biology benchmark scores.

Rationale: Scientific answers are contextual and public benchmarks can encode wrong or underdetermined Q&A pairs.

Gotchas (what bit them)

A plain schema prompt did not give the LLM enough biomedical context to generate useful SQL.

Root cause: Biology column names and acronyms carry domain-specific meanings that cannot be inferred from simple type information.

Resolution: Owkin enriched column metadata with non-ambiguous descriptions of the biological meaning and relationships behind fields.

Generated SQL could be invalid, too complex, or malicious.

Root cause: The LLM is producing executable queries over data, so malformed or unsafe operations are possible.

Resolution: The team constrained outputs with schema enforcement, keyword lists, sandbox execution, and Polars exception handling.

Pure semantic retrieval returned plausible but wrong biomedical papers.

Root cause: Dense embeddings captured related protein-family semantics while missing the user's exact biomedical term intent.

Resolution: Owkin moved to hybrid search combining sparse keyword vectors with dense semantic vectors.

The system retrieved too many review papers when researchers wanted original science.

Root cause: Retrieval lacked metadata constraints for paper type before generation.

Resolution: The team indexed metadata such as paper type so reviews could be filtered before retrieval and reranking.

Scientific evaluation could not rely on binary public benchmarks.

Root cause: Biology questions often depend on context, and public benchmark answers can be wrong or underspecified.

Resolution: Owkin used custom domain-expert validation and production feedback instead of treating generic benchmarks as definitive.

Developers could not use real patient data locally, even when anonymized.

Root cause: Healthcare privacy and consent constraints apply to development environments as well as production systems.

Resolution: The team used synthetic omics data, but had to make it biologically meaningful rather than random.

Evaluation

Owkin combined production monitoring, thumbs-up/down reviews, detailed user feedback, and custom domain-expert validation rather than relying on generic public benchmarks.

Metrics: thumbs up/down user feedback · detailed production reviews · domain expert validation · benchmark Q&A error analysis

Outcomes

• Researchers could ask natural-language questions over curated biological databases and receive formatted answers with source links.
• The RAG system moved from dense-only retrieval to hybrid retrieval, metadata filtering, and reranking after researcher feedback.
• The copilot was launched for academic biology researchers with monitoring and internal expert feedback.

The system operated over curated databases with hundreds of columns and tens of thousands of rows, and over a PubMed corpus of more than 26 million abstracts; its vector database hosting cost about $800 per month.