<p>Healthcare and longevity have always fascinated me—understanding how the body works, what interventions actually have evidence behind them, and how to make proactive health decisions rather than reactive ones. Discovering Peter Attia's "Outlive" and the concept of Medicine 3.0 didn't spark this interest; it gave a name and framework to what I already believed: that we should use data, evidence, and proactive strategies to extend not just lifespan but healthspan. Combining this passion with my work in AI felt natural—what if I could build a system that answers health questions using actual scientific evidence instead of potentially hallucinated responses? In this article, I'll walk through the architecture, the technical decisions, and how you can build something similar.</p>
<h2>The Problem: Information Overload in Health Research</h2>
<p>PubMed contains over <strong>35 million biomedical articles</strong>, growing by thousands daily. When you want to understand something like "What supplements help with inflammation?" or "How does zinc affect testosterone?", you face two challenges:</p>
<ol>
<li><strong>Finding relevant studies</strong> among millions of papers</li>
<li><strong>Trusting the answers</strong> you get from AI systems that might hallucinate</li>
</ol>
<p>Traditional RAG (Retrieval-Augmented Generation) systems can retrieve documents, but they lack the structured relationships needed to answer questions like "What TREATS insomnia?" with precision. I needed something better.</p>
<hr>
<h2>Why a Knowledge Graph?</h2>
<p>The core philosophy behind this project is <strong>"Quality over Quantity"</strong>. Rather than ingesting all of PubMed, I built a curated knowledge graph that:</p>
<ul>
<li>Starts with <strong>high-quality, manually selected studies</strong> (clinical trials, meta-analyses)</li>
<li>Extracts <strong>structured relationships</strong> between biological entities (drugs, diseases, genes)</li>
<li>Provides <strong>exact citations</strong> for every claim (PMID links to source papers)</li>
<li><strong>Avoids hallucinations</strong> by grounding all answers in actual research</li>
</ul>
<p>The result is a system that can answer questions like "What can help with insomnia?" by querying a graph of Evidence nodes, each backed by specific PubMed abstracts.</p>
<p><img alt="Screenshot of the Streamlit application showing a health query with evidence-backed results including PMID citations and confidence scores" src="/assets/blog/images/graphrag-pubmed-longevity-ai-1.png"></p>
<hr>
<h2>Architecture: The Two-Layer Graph</h2>
<p>The system uses <a href="https://neo4j.com/">Neo4j</a> as the graph database, with a two-layer structure:</p>
<h3>Layer 1: Entity Skeleton</h3>
<p>The foundation consists of <code>(:Entity)</code> nodes representing biological concepts—drugs, diseases, genes, proteins. These come from the <a href="https://www.scidb.cn/en/detail?dataSetId=4Tda4ac08e9540889a33fbdd3ebf26ce">PKG 2.0 dataset</a>, which provides standardized IDs (CHEBI for chemicals, MeSH for diseases, NCBIGene for genes).</p>
<h3>Layer 2: Evidence Library</h3>
<p>The enrichment layer consists of:</p>
<ul>
<li><strong><code>(:Evidence)</code> nodes</strong> - Represent a unique relationship type between two entities</li>
<li><strong><code>(:Chunk)</code> nodes</strong> - Individual study abstracts supporting that relationship</li>
</ul>
<p>The graph pattern looks like this:</p>
<pre><code>(Entity1)-[:HAS_EVIDENCE]-&gt;(Evidence)-[:TARGETS]-&gt;(Entity2)
(Evidence)-[:HAS_CHUNK]-&gt;(Chunk)
</code></pre>
<p>For example, if three studies show that zinc decreases inflammation, they share one Evidence node with three Chunk nodes:</p>
<pre><code class="language-cypher">(zinc:Entity)
    -[:HAS_EVIDENCE]-&gt;
(evidence:Evidence {
    relation_type: "DECREASES",
    chunk_count: 3,
    avg_confidence: 0.87
})
    -[:TARGETS]-&gt;
(inflammation:Entity)

(evidence)-[:HAS_CHUNK]-&gt;(chunk1:Chunk {pmid: "31550200", confidence: 0.92})
(evidence)-[:HAS_CHUNK]-&gt;(chunk2:Chunk {pmid: "28768407", confidence: 0.85})
(evidence)-[:HAS_CHUNK]-&gt;(chunk3:Chunk {pmid: "33864754", confidence: 0.84})
</code></pre>
<p><br><img alt="Neo4j graph visualization showing the Entity-Evidence-Chunk pattern with zinc, inflammation, and connected study abstracts" src="/assets/blog/images/graphrag-pubmed-longevity-ai-2.png"></p>
<h3>The 6 Standardized Relation Types</h3>
<p>I use a focused set of pharmacologically relevant relationships:</p>
<table>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
<th>Example</th>
</tr>
</thead>
<tbody><tr>
<td><strong>INCREASES</strong></td>
<td>Upregulates, enhances, boosts</td>
<td>Zinc INCREASES testosterone</td>
</tr>
<tr>
<td><strong>DECREASES</strong></td>
<td>Downregulates, reduces, lowers</td>
<td>Omega-3 DECREASES inflammation</td>
</tr>
<tr>
<td><strong>TREATS</strong></td>
<td>Improves, alleviates, helps with</td>
<td>Melatonin TREATS insomnia</td>
</tr>
<tr>
<td><strong>INHIBITS</strong></td>
<td>Blocks, suppresses, prevents</td>
<td>Aspirin INHIBITS COX-2 enzyme</td>
</tr>
<tr>
<td><strong>CAUSES</strong></td>
<td>Induces, triggers, leads to</td>
<td>High cortisol CAUSES inflammation</td>
</tr>
<tr>
<td><strong>PREVENTS</strong></td>
<td>Protects against, reduces risk</td>
<td>Vitamin D PREVENTS deficiency</td>
</tr>
</tbody></table>
<p>Why only 6 types? They cover most pharmacovigilance use cases while keeping the LLM extraction reliable and the queries precise.</p>
<hr>
<h2>The Three-Stage Pipeline</h2>
<h3>Stage 1: Building the Foundation</h3>
<p>The pipeline starts with curated PubMed IDs in a <code>pmids.txt</code> file—studies I've selected for quality (clinical trials, systematic reviews, papers from reputable journals).</p>
<pre><code class="language-python"># extract_entities.py - Scans PKG 2.0 dataset to find entities mentioned in curated papers
def extract_entities_from_pkg(pmids_file, pkg_file):
    """
    Reads pmids.txt and scans the 65GB PKG file once,
    extracting all entity IDs mentioned in our seed studies.
    """
    pmids = set(open(pmids_file).read().strip().split('\n'))

    entity_ids = set()
    with open(pkg_file, 'r') as f:
        for line in f:
            parts = line.strip().split('\t')
            if parts[1] in pmids:  # PMID column
                entity_ids.add(parts[7])  # EntityId column

    return entity_ids
</code></pre>
<p>After extraction, entities are loaded into Neo4j along with their relationships from PKG, creating a "map" of ~1.2M known connections to explore.</p>
<h3>Stage 2: Creating Evidence Nodes</h3>
<p>This is where the LLM magic happens. I manually curate interesting relationships by querying Neo4j:</p>
<pre><code class="language-cypher">-- Find what zinc relates to in our knowledge base
MATCH (e1:Entity {name: 'zinc'})-[r:RELATED_TO]-(e2:Entity)
RETURN DISTINCT r.pmid AS PMID, e1.name, e2.name
LIMIT 20;
</code></pre>
<p>For each relationship I want to investigate, the system:</p>
<ol>
<li><strong>Downloads the abstract</strong> from PubMed using the NCBI Entrez API</li>
<li><strong>Sends it to the LLM</strong> to extract the relationship type and confidence</li>
<li><strong>Creates Evidence and Chunk nodes</strong> in Neo4j with 768-dimensional embeddings</li>
</ol>
<pre><code class="language-python"># LLM prompt for relation extraction
prompt = f"""You are a biomedical expert analyzing research abstracts.

ABSTRACT:
{abstract_text}

ENTITIES: {entity1_name}, {entity2_name}

Extract the directional relationship between these entities.
Return JSON: {{"source_entity": "...", "relation_type": "INCREASES|DECREASES|TREATS|...",
              "target_entity": "...", "confidence": 0.0-1.0}}
"""
</code></pre>
<p>The <code>--log-only</code> flag lets me verify extractions before committing to the database:</p>
<p><img alt="Terminal output showing the LLM analyzing abstracts and extracting relationships with confidence scores - shows PMID, entity pairs, relation types like DECREASES and TREATS, and confidence values" src="/assets/blog/images/graphrag-pubmed-longevity-ai-3.png"></p>
<h3>Stage 3: The Query Application</h3>
<p>A <a href="https://streamlit.io/">Streamlit</a> application provides the user interface. It supports three query patterns:</p>
<ol>
<li><strong>Explanation Pattern</strong> (2+ entities): "How does zinc affect inflammation?"</li>
<li><strong>Discovery Pattern</strong> (1 entity, typed): "What treats insomnia?"</li>
<li><strong>General Discovery</strong> (1 entity, any type): "What affects testosterone?"</li>
</ol>
<pre><code class="language-python">def query_discovery_pattern(entity, relation_type, question, driver):
    """Find what entities relate to target via specific relation type."""

    question_embedding = embedding_model.encode(f"query: {question}")

    cypher_query = """
    MATCH (source:Entity)-[:HAS_EVIDENCE]-&gt;(ev:Evidence)-[:TARGETS]-&gt;(target:Entity)
    WHERE toLower(target.name) = toLower($entity)
      AND ev.relation_type = $relation_type

    MATCH (ev)-[:HAS_CHUNK]-&gt;(c:Chunk)

    WITH source, ev, c,
         gds.similarity.cosine(c.embedding, $question_embedding) AS similarity

    RETURN source.name AS entity, c.pmid AS pmid, c.abstract_text AS abstract,
           c.confidence AS confidence, similarity AS score
    ORDER BY similarity DESC
    LIMIT 5
    """

    return session.run(cypher_query, entity=entity,
                       relation_type=relation_type,
                       question_embedding=question_embedding)
</code></pre>
<p>The semantic ranking ensures that when you ask about "inflammatory bowel disease", abstracts mentioning bowel conditions rank higher than general inflammation studies.</p>
<hr>
<h2>Tech Stack and Cost Considerations</h2>
<h3>Running Locally: $0 API Costs</h3>
<p>One of the key decisions was running everything locally on Apple Silicon:</p>
<ul>
<li><strong>LLM</strong>: <code>mlx-community/Qwen2.5-7B-Instruct-8bit</code> via <a href="https://ml-explore.github.io/mlx/">MLX</a> (Apple's ML framework)</li>
<li><strong>Embeddings</strong>: <code>intfloat/e5-base-v2</code> (768-dimensional, cosine similarity)</li>
<li><strong>Database</strong>: Neo4j Community Edition (free, with vector search)</li>
<li><strong>Data</strong>: PubMed via NCBI Entrez API (free with rate limiting)</li>
</ul>
<p><strong>Total API costs: $0</strong>. Everything runs on my MacBook Pro.</p>
<h3>Component Breakdown</h3>
<table>
<thead>
<tr>
<th>Component</th>
<th>Choice</th>
<th>Why</th>
</tr>
</thead>
<tbody><tr>
<td>Graph Database</td>
<td>Neo4j 5.x</td>
<td>Native vector search, Cypher query language</td>
</tr>
<tr>
<td>Embeddings</td>
<td>e5-base-v2</td>
<td>High quality, 768-dim, works well for scientific text</td>
</tr>
<tr>
<td>LLM</td>
<td>Qwen2.5-7B-Instruct</td>
<td>Excellent instruction following, runs efficiently on MLX</td>
</tr>
<tr>
<td>UI</td>
<td>Streamlit</td>
<td>Fast prototyping, built-in caching, reactive updates</td>
</tr>
<tr>
<td>Data Source</td>
<td>PKG 2.0 + PubMed</td>
<td>Standardized entity IDs, free abstract access</td>
</tr>
</tbody></table>
<hr>
<h2>Limitations and Future Improvements</h2>
<h3>Current Limitations</h3>
<p>The biggest limitation is relying on a <strong>7B parameter model</strong> for extracting medical relationships from abstracts. While Qwen2.5-7B-Instruct performs well for clear-cut relationships ("Zinc supplementation significantly reduced inflammation"), it can struggle with:</p>
<ul>
<li><strong>Nuanced findings</strong>: "While some studies suggest a correlation, the causal relationship remains unclear"</li>
<li><strong>Contradictory evidence</strong>: Papers that report both positive and negative effects</li>
<li><strong>Complex mechanisms</strong>: Multi-step biochemical pathways</li>
</ul>
<p>The confidence scores help flag uncertain extractions, but some relationships inevitably get misclassified.</p>
<h3>Ideas for Improvement</h3>
<ol>
<li><p><strong>Larger models for extraction</strong>: Using GPT-4 or Claude for the initial extraction phase would improve accuracy, though at the cost of API fees. A hybrid approach—local model for obvious relationships, API for uncertain ones—could balance cost and quality.</p>
</li>
<li><p><strong>Ensemble approaches</strong>: Running multiple smaller models and only keeping relationships where they agree could reduce false positives.</p>
</li>
<li><p><strong>Fine-tuning</strong>: Training a specialized model on manually verified medical relationship extractions could dramatically improve accuracy for this specific task.</p>
</li>
<li><p><strong>Human-in-the-loop validation</strong>: The <code>--log-only</code> mode already supports manual review. Building a simple validation UI where domain experts can approve/reject extractions would create a feedback loop for continuous improvement.</p>
</li>
<li><p><strong>Confidence thresholds</strong>: Currently all extractions above 0.3 confidence are included. Implementing tiered confidence levels (high/medium/low) and displaying them in the UI would help users assess evidence strength.</p>
</li>
</ol>
<hr>
<h2>Conclusion</h2>
<p>By combining <strong>Neo4j knowledge graphs</strong> with <strong>local LLM inference</strong>, I built a system that answers health questions with traceable, evidence-based citations. The "Quality over Quantity" philosophy means every answer is grounded in actual PubMed research, with confidence scores and direct links to source papers.</p>
<p>This approach aligns perfectly with Medicine 3.0 principles—using technology to make proactive, evidence-based health decisions rather than relying on generic advice or potentially hallucinated AI responses.</p>
<p>The system currently handles queries about supplements, biomarkers, and disease relationships, but the architecture extends naturally to any domain where you need structured, evidence-backed answers from scientific literature.</p>
<hr>
<h3>Resources</h3>
<ul>
<li><strong>Neo4j Documentation</strong>: <a href="https://neo4j.com/docs/">https://neo4j.com/docs/</a></li>
<li><strong>PKG 2.0 Dataset</strong>: <a href="https://www.scidb.cn/en/detail?dataSetId=47da4ac08e9540889a33fbdd3ebf26ce">https://www.scidb.cn/en/detail?dataSetId=47da4ac08e9540889a33fbdd3ebf26ce</a></li>
<li><strong>PubMed/NCBI Entrez</strong>: <a href="https://www.ncbi.nlm.nih.gov/home/develop/api/">https://www.ncbi.nlm.nih.gov/home/develop/api/</a></li>
<li><strong>MLX (Apple ML Framework)</strong>: <a href="https://ml-explore.github.io/mlx/">https://ml-explore.github.io/mlx/</a></li>
<li><strong>E5 Embeddings</strong>: <a href="https://huggingface.co/intfloat/e5-base-v2">https://huggingface.co/intfloat/e5-base-v2</a></li>
<li><strong>Streamlit</strong>: <a href="https://streamlit.io/">https://streamlit.io/</a></li>
</ul>
<hr>


Building an evidence-based health knowledge graph using Neo4j, PubMed research, and local LLM inference. A practical approach to answering health questions with traceable citations.

Building an Evidence-Based Health Knowledge Graph: Where AI Meets Longevity

Keywords: