Hello, tech innovators, data nerds, and health-tech visionaries! π Welcome to the ultimate engineering deep-dive of Med AI.
If you followed our journey in Round 1, you know we laid the groundwork by analyzing how raw brute-force data parsing heavily chokes LLM context windows and spikes infrastructure bills. But we didn't stop there. We got selected in top 15 for Round 2, we took the baseline prototype and scaled it into a monster: benchmarking three entirely different retrieval architectures against a massive, custom-generated 100 Million Token Dataset.
Here is the continuation of how we evolved Med AI from a local hack into a hyper-scale clinical intelligence suite. ποΈπ¨
βͺ Round 1 Retrospective: The Genesis of Med AI
In the first round, our mission was simple but brutal: prove that standard linear search methods break down when processing large-scale medical data. We built our initial System Auditor UI to load raw CSV medical files straight into local RAM. While the clinical summaries generated by the LLM were highly detailed, the system ground to a halt under load.
We proved that sending unorganized, flat text blocks directly to an LLM context window creates massive token bloat and unacceptable latency. Round 1 exposed the problem; Round 2 was built to engineer the ultimate enterprise-tier solution.
π The Foundation: Inside the 100M Token Engine Matrix
To push our Round 2 architectures to their absolute limits, we generated a massive 33-column production database matrix. Real-world clinical workflows don't operate on simple text snippets. They require deeply nested, multi-layered variables. Our underlying engine ingests an incredibly rich web of features for every single record, including:
-
Clinical Classifications:
disease_id,disease_name,icd_code,category,disease_type -
Symptom Progressions:
symptoms,early_symptoms,severe_symptoms -
Pathophysiology & Risks:
causes,risk_factors,affected_organs,body_system -
Therapeutic Protocols:
complications,diagnosis_method,treatments,prescribed_medicine,medicine_classes -
Prognostics & Demographics:
prevalence,mortality_rate,contagious,genetic,chronic,emergency_level,age_group,gender_risk,prognosis,recovery_time,vaccine_availability,specialist_required -
Validation Layer:
references(Mapping to global authorities like the WHO Clinical Guidelines and NCBI)
π A Sneak Peek at the 33-Column Production Engine Data
π οΈ The Round 2 Tri-Pipeline Architectural Showdown
We built a state-of-the-art Unified Cross-Examiner Dashboard to watch these three generations of retrieval engines battle side-by-side in real-time. We threw a single query at all of them live on stage: "Asthma therapeutic protocols".
Here is the exact breakdown of how each pipeline stacked up under the hood. π§ β‘
π΄ Pipeline 1: The Raw Brute-Force Framework (Pandas)
- The Strategy: Our baseline Round 1 architecture. When a query hits the terminal, it allocates local memory and loads the entire 33-column, 100M token dataset into RAM using Pandas, executing a linear string search across every variable.
- The Bottleneck: Extreme token hemorrhage. Because it returns raw, unorganized row text blocks across dozens of columns, it floods the LLM context window with immense waste data.
-
The Telemetry Verdict: * β±οΈ Execution Latency:
6.37s(Dangerous for a live doctor standing in an emergency room!)- π·οΈ Token Cost Bracket: HIGH (
3,267+ tokens)
- π·οΈ Token Cost Bracket: HIGH (
π‘ Pipeline 2: Vector Semantic Indexing (ChromaDB)
-
The Strategy: Moving into vector math. We implemented
SentenceTransformer("all-MiniLM-L6-v2")to convert the dense 33-column clinical text rows into 384-dimensional vector embeddings, saving them into a localized, persistent ChromaDB database (chroma_db_100M). -
The Bottleneck: While speed increased drastically, we hit Context Loss. Vector search squashes text into abstract mathematical distances, stripping away hyper-specific relational links (like losing the rigid connection between a specific
prescribed_medicineand its correspondingsevere_symptomsstage during high-dimensional chunk splitting). -
The Telemetry Verdict: * β±οΈ Execution Latency:
1.45s(Much faster!)- π BERTScore F1:
0.8102(Suffered from critical clinical omission errors due to vector flattening).
- π BERTScore F1:
π΅ Pipeline 3: The Med AI Enterprise GraphRAG Framework π
- The Strategy: The ultimate architectural breakthrough of Round 2. Instead of flat text row scans or abstract vector coordinates, we simulated an enterprise graph database network natively in memory.
- How it Works: The complex 33-column medical records are transformed into explicit topological networks: Vertices (Nodes representing concrete entities like Diseases, SymptomClusters, and TherapeuticProtocols) and Edges (The direct relationships connecting them, like MANIFESTS_AS or MANAGED_BY).
- The Magic: When a query runs, the system performs a localized graph traversal, extracting an isolated sub-graph topology map. The LLM receives zero fluffβno preamble, no introductory waste textβonly pristine, pre-linked relational facts.
-
The Telemetry Verdict:
- β±οΈ Execution Latency: 0.82s (Sub-second hyper-speed! β‘)
- π·οΈ Token Cost Bracket: LOW (
450 tokens maxdue to zero waste data!) - π― LLM-as-a-Judge Score:
98% Relevance(Absolute structural precision).
π The Final Dashboard Audit Matrix
When we click LAUNCH SYNCHRONIZED SCANS on our master evaluation console, the systems run side-by-side. The telemetry results are undeniable:
| Evaluation Metric | Pipeline 1 (Brute Force) | Pipeline 2 (Vector RAG) | Pipeline 3 (GraphRAG) |
|---|---|---|---|
| Execution Latency |
6.37s π΄ |
1.45s π‘ |
0.82s π’ |
| Token Efficiency | Bloated (3,267+ tk) |
Moderate (1,150 tk) |
Ultra-Lean (450 tk) |
| Compute Cost | High ($$$) | Medium ($$) | Fractions of a Micro-Cent ($) |
| BERTScore F1 | 0.9684 |
0.8102 (Context Drop) |
0.9912 (Max Accuracy) |
| LLM-as-a-Judge | 94% Relevance | 76% (Hallucination Risk) | 98% Structural Precision |
π The Road to Production: Taking Med AI Public
. Enterprise Graph Scale: Routing our Pipeline 3 engine away from memory simulations directly into a live distributed TigerGraph Cloud instance (tgcloud.io) via secure REST endpoints
π‘ The Takeaway
Building high-scale medical AI isn't about throwing the biggest, most expensive model at a problem. It's about Data Architecture. By structuring our dense, 33-column dataset into an explicit knowledge network, GraphRAG allowed us to slash latency by 87% and slice token overhead to a fraction of the cost, all while increasing accuracy. That is how we build the future of health-tech. π©Ίππ
π Project Ecosystem & Codebase
Want to see how this was built under the hood or review our historical development iterations? Explore the official Med AI ecosystem across these links:
- π Read the Round 1 Core Ideation Blog Here β A retrospective look at how our initial architecture was born.
- π» Explore the Med AI Source Repository on GitHub β Clone the codebase, check out our implementation history, and view the configurations.
- π Access the Raw 100M Token Engine Dataset via Google Drive β Direct download link to access the underlying 33-column production database engine.
- π€ Connect with Me on LinkedIn β Let's network, discuss health-tech scaling, and collaborate on enterprise AI systems.







Top comments (1)
Clinical-scale AI is where the verify layer stops being optional, a hallucination in a med context isn't a bug, it's a liability. At 100M tokens the cost-and-correctness engineering matters more than the model choice: grounding every claim, abstain-on-uncertainty, and an audit trail for what was decided and why. The teams that do this well treat "I don't know" as a first-class answer instead of forcing a guess. That verify-or-abstain discipline is core to how I think about output in Moonshift, different stakes obviously. How are you handling the abstain case clinically, hard confidence thresholds or human-in-the-loop review?