AI & Algorithms, Explained

About this series

Original summaries, honest credit

This is an original educational summary written by Jeremy Tabernero, MD, JTMDAI's founder, as he learns to program. The concept map follows 50 Algorithms Every Programmer Should Know, 2nd edition, by Imran Ahmad, Ph.D. (Packt Publishing), and its companion code repository, github.com/cloudanum/50Algorithms.

No text is reproduced from the book, and this series is not affiliated with or endorsed by the author or Packt. If these ideas are useful to you, buy the book — it goes far deeper, with working Python for every algorithm. Where a case study leans on a third-party explainer (for example, Jay Alammar's The Illustrated Transformer or Chris Olah's Understanding LSTM Networks), it is credited in the full version's sources. Each case study here links to the complete, source-cited version on drjeremytabernero.org.

Alongside the four Parts, the series carries standalone concept deep-dives — single ideas behind current AI research, explained on the same ladder: starting from what a working physician already knows (a bell curve, a pre-test probability) and climbing to the concept itself.

The healthcare examples are illustrative and educational. Nothing here is medical advice.

Four parts + concept deep-dives

What's inside

• Part 1 · Foundations. Big-O, data structures, sorting & searching, and how to design an algorithm.
• Part 2 · Graphs & Machine Learning. Shortest paths, clustering, and prediction from labeled data.
• Part 3 · Deep Learning & Sequences. Neural networks, embeddings, and the road to ChatGPT.
• Part 4 · Applied Systems. Recommenders, cryptography, scale, and the ethics of automation.
• Deep-dive · Naive Bayes. Bayes' rule as belief-updating — the spam filter and bedside diagnostic reasoning are the same math.
• Deep-dive · Latent Space. Embeddings put words, documents, and patients on a map where distance means similarity.
• Deep-dive · Gaussian Splatting & the Jacobian. From the bell curve on a lab report to photorealistic 3-D scenes — and how networks learn.

Part 1 — Foundations · Chapters 1–4

Foundations: What Makes an Algorithm Work

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

Punchline first: an algorithm is a recipe, and a recipe you never tested is just a guess with confidence. Everything below is about writing the recipe well and proving it works.

An algorithm is just a finite list of unambiguous steps that turns an input into an output — sort these names, find this patient's record, route this truck. The steps are the algorithm; the code is one way of writing them down. Before code, we usually write pseudocode — the recipe in plain structured English — precisely so we can check the logic before a single line runs.

The first thing engineers ask about a recipe is how does it scale? That is Big-O notation (the "complexity" of an algorithm) — a shorthand for how the work grows as the input grows. Think of it clinically: a test that takes the same time whether you have 10 patients or 10,000 is O(1), constant. One that doubles its work when you double the patients is O(n), linear. One that compares every patient against every other is O(n²) and will crawl on a big ward. Big-O isn't about seconds on your laptop; it's about the shape of the growth curve, and a gentle curve beats a vicious one once the data gets large.

Recipes need containers — data structures — and the container matters as much as the steps:

• A list is an ordered shelf you can grow and index into.
• A tuple is the same shelf, but glued shut — fixed, unchangeable.
• A dictionary (a "hash map") is a labeled pill organizer: hand it a label ("metformin"), get the value back instantly, no scanning.
• A set is a bag that refuses duplicates — perfect for "unique diagnoses seen today."
• A stack is a spring-loaded plate dispenser: last plate in is the first one out.
• A queue is the triage line: first in, first out.

Two of the oldest chores are sorting and searching. Sorting methods range from the naive — bubble, insertion, selection sort, simple but O(n²) — to the fast divide-and-conquer methods, merge sort and quicksort, at roughly O(n log n). Searching splits the same way. Scanning every item top to bottom is linear search. Binary search is the doctor's move: with a sorted list, check the middle, throw away half, repeat — O(log n), absurdly fast. But note the fine print, because it matters later: binary search only works if the input is already sorted. Feed it unsorted data and it confidently returns the wrong answer.

Finally, algorithm design is a small toolbox of strategies: divide and conquer (split the problem, solve the pieces, combine); dynamic programming (break into overlapping subproblems and cache the answers so you never recompute the same thing); greedy (grab the best-looking option at each step and hope local wins add up to a global one); and linear programming (optimize a goal under constraints). Some problems resist all of them — the classic is the Traveling Salesman Problem: find the shortest route visiting every city once. Easy to state, brutally hard to solve exactly, so in the real world we settle for good enough, fast.

Where you've seen it

On August 1, 2012, the trading firm Knight Capital deployed new software to its order router without adequate validation. Per the SEC's order, in the first 45 minutes of trading the router fired more than 4 million orders trying to fill just 212 customer orders, traded more than 397 million shares, and left Knight with a loss of more than $460 million. The firm nearly died and paid a $12 million settlement. The algorithm wasn't exotic — it was an unvalidated deployment, the whole lesson of this section in one headline.

In healthcare

The sharpest lesson lands in our own hospitals. The Epic Sepsis Model is a proprietary early-warning algorithm built into one of the country's most widely used electronic health records. Epic's internal materials cited an accuracy (AUC, where 1.0 is perfect and 0.5 is a coin flip) of 0.76 to 0.83. Then Wong and colleagues did the thing Knight Capital didn't — they externally validated it on real patients. Published in JAMA Internal Medicine in 2021 across 27,697 patients and 38,455 hospitalizations, the model scored an AUC of just 0.63 — and at its alerting threshold it missed 67% of the patients who actually had sepsis (1,709 of 2,552) while flooding clinicians with alerts. The math wasn't fraudulent — it had simply never been proven on the population it was deployed against. Validation isn't a formality; it's the difference between a tool and a liability.

Dynamic programming shows up on the bench, too. The Needleman–Wunsch algorithm, published in 1970 in the Journal of Molecular Biology by Saul Needleman and Christian Wunsch, was one of the first applications of dynamic programming in biology — it aligns two DNA or protein sequences optimally by building a grid of best partial alignments and reusing them, and it still underlies how we compare a patient's variant against a reference genome.

Why it matters when you work with AI

If you take one habit from these four chapters into your AI work, make it this: validate the algorithm on your data, not the vendor's brochure. Every AI model you're offered comes with a number measured on someone else's patients; your job is to demand the external validation — the AUC, the sensitivity, the miss rate — measured on people like yours.

Three foundations transfer directly. First, complexity is destiny at scale: a model that's fine on a pilot ward can choke on a health system, so ask how the cost grows, not just how it runs today. Second, garbage in, wrong out — confidently: binary search returns nonsense on unsorted input without complaining, and an AI model does the same with biased or mismatched data. Third, correct-looking is not correct: Timsort was trusted for years before a proof exposed the bug. The discipline that separates a $460-million mistake from a working system isn't cleverness — it's the boring, non-negotiable step of proving the thing works before you trust it with a life.

Read the full case study, with sources →

Part 2 — Graphs & Machine Learning · Chapters 5–7

Graphs & Machine Learning: Finding Structure and Making Predictions

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

Two big ideas live in this part, and they fit together.

The first is the graph — not a bar chart, but a web of things (called nodes) joined by relationships (called edges). Cities joined by roads. Web pages joined by links. Patients joined to compatible donors. Once you draw your problem as a graph, a small family of algorithms can walk it. Breadth-first search explores outward one ring at a time, like ripples in a pond — good for "what's the fewest hops to get there." Depth-first search plunges down one path to the end before backing up — good for "is there any way through at all." And when the edges have a cost — miles, minutes, dollars — shortest-path algorithms find the cheapest route. The punchline: most "find the best connection" problems are secretly the same problem.

The second idea is machine learning — letting a program find the pattern instead of hand-writing the rule. It splits into two camps. Unsupervised learning gets unlabeled data and hunts for structure: clustering (k-means, hierarchical, DBSCAN) sorts examples into natural groups nobody named in advance, and PCA (principal component analysis) squeezes dozens of measurements down to the two or three that carry most of the signal, so you can actually see it. Supervised learning gets examples with the answer attached and learns to predict the answer on new cases: logistic regression for yes/no odds, decision trees for a flowchart of if-then splits, and ensembles like random forests and gradient boosting that combine hundreds of weak trees into one strong predictor.

The mental model to keep: a graph is a map of how things connect, and machine learning is a machine for turning examples into predictions. Neither one is magic. Both are just bookkeeping done carefully at scale.

Where you've seen it

Every time your phone reroutes you around traffic, you are watching a shortest-path algorithm run. The ancestor of that feature is a single 1959 paper by Edsger Dijkstra, A Note on Two Problems in Connexion with Graphs, three pages long, that described how to find the cheapest route through a weighted graph. By his own account he worked the idea out in his head in about twenty minutes at a café, a few years before he wrote it down. Sixty-some years later it runs billions of times a day inside mapping apps.

In healthcare

These same tools quietly run through medicine, often decades before anyone called it "AI."

Start with graphs. Kidney paired donation is a graph-matching problem. You have willing donors who don't match their intended recipient; draw an edge wherever donor A matches recipient B, and the job is to find cycles and chains that let everyone get a compatible organ. This is exactly the market-design work that earned Alvin Roth (with Lloyd Shapley) the 2012 Nobel Prize in Economics. It is not abstract: the New England Journal of Medicine documented a nonsimultaneous, extended, altruistic-donor chain in which one altruistic donor kicked off a chain that transplanted ten recipients. That is a matching search over a compatibility graph, saving real lives.

Now clustering. In 2019, Seymour and colleagues published their work on novel clinical phenotypes for sepsis in JAMA. Using k-means clustering across three cohorts totaling 63,858 patients, they derived and validated four reproducible sepsis phenotypes — labeled α, β, γ, and δ — that differed in lab values, organ dysfunction, and mortality. Nobody defined those four groups in advance; the algorithm surfaced them. The provocative part: in re-analyses of clinical-trial data, the mix of phenotypes changed whether a treatment looked helpful or harmful. Sepsis may not be one disease we keep failing to treat, but several diseases wearing the same name.

PCA earns a beautiful non-clinical demonstration too. In 2008, Novembre and colleagues genotyped around 3,000 Europeans at about half a million DNA sites, then ran PCA on the genomes of the roughly 1,400 individuals who passed quality filters. The top two components — the two axes that captured the most variation — reconstructed a recognizable map of Europe. Plot each person by their genetic coordinates and you get the geography back, close enough that half of them landed within about 310 kilometers of home. Genes mirror geography, and PCA is what let us see it.

Finally, supervised prediction. Long before machine learning was fashionable, cardiology built a working clinical predictor with plain regression. The Framingham risk score, published by Wilson and colleagues in Circulation in 1998, used sex-specific proportional-hazards regression to turn age, cholesterol, blood pressure, smoking, and diabetes into a personalized 10-year risk of coronary heart disease. That is textbook supervised learning — inputs in, calibrated risk out — sitting in clinical guidelines for a generation.

Why it matters when you work with AI

Three things stick with me as a physician learning to build.

First, most hard problems are old problems in a new coat. Routing, ranking, matching, and risk-scoring are graph and regression problems we have understood for decades. When a vendor pitches "AI" for care coordination, the honest question is often just: what's the graph, and what's the objective?

Second, the boring model usually wins on tabular data. Gradient-boosted trees, not deep networks, dominate structured prediction — as XGBoost's Kaggle record shows. For most clinical spreadsheets, reaching for a neural network first is a tell that someone likes the tool more than the problem.

Third, unsupervised methods find structure, not truth. k-means will hand you four sepsis clusters whether or not four is the right number; PCA will draw axes whether or not they mean anything. The sepsis phenotypes are compelling because they were validated and tied to outcomes — not because the algorithm produced them. That discipline, verify before you believe, is the same one I use at the bedside, and it's exactly the habit that keeps machine learning honest.

Read the full case study, with sources →

Part 3 — Deep Learning & Sequences · Chapters 8–11

Deep Learning & Sequences: From Neural Nets to ChatGPT

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

A neural network is just layers of tiny math units stacked on top of each other. Each unit — a "neuron" — takes some numbers in, multiplies each by a weight, adds them up, and passes the total through an activation function: a nonlinear gate (common ones are ReLU, sigmoid, and tanh) that decides how much signal to let through. One neuron is dumb. A few million of them, arranged in layers, can approximate almost any pattern you can throw at them.

How does it learn? Two words: backpropagation and gradient descent. You show the network an example, measure how wrong its answer is, then work backward through the layers to figure out which weights to blame — and nudge each one a little in the direction that reduces the error. Repeat that a few million times and the network "learns." Transfer learning is the shortcut: instead of training from scratch, you take a network someone already trained on a huge dataset and fine-tune it on your smaller problem. It's borrowing an educated brain instead of raising a child.

Language is harder, because computers read numbers, not words. So we tokenize (chop text into pieces), sometimes stem (trim words to their root, so "running" becomes "run"), and score which words actually matter with TF-IDF (a word is important if it's frequent here but rare everywhere else). The real leap is word embeddings: placing every word as a point in a high-dimensional coordinate space, learned so that meaning becomes geometry. That's what makes the famous king − man + woman ≈ queen trick work — you can literally do arithmetic on meaning.

Words come in order, so we need models with memory. Recurrent neural networks (RNNs) read one token at a time, carrying a running summary forward. But plain RNNs forget: signals fade as they travel back through many steps — the vanishing-gradient problem. LSTMs and GRUs fix this by adding gates that choose what to keep, update, or discard. Chris Olah's Understanding LSTM Networks is still the clearest picture of how those gates work.

Then, in 2017, a smarter idea: attention. Instead of shuffling information step by step, let the model look at every word at once and decide, for each word, which other words matter. Jay Alammar's The Illustrated Transformer walks through it panel by panel. Stack that mechanism into a big network, feed it much of the internet, and you get a large language model — the family that ChatGPT belongs to.

Where you've seen it

The modern deep-learning era has a clean starting gun: 2012, when AlexNet — built by Alex Krizhevsky, Ilya Sutskever, and Geoffrey Hinton — won the ImageNet image-recognition contest with a top-5 error rate of 15.3%, well ahead of the runner-up's 26.2% (NeurIPS, 2012). A roughly eleven-point gap overnight told everyone that deep neural networks weren't a curiosity — they were the future of computer vision.

In healthcare

This is where it stops being abstract for a physician. In 2016, a Google team led by Varun Gulshan trained a deep network to read retinal photographs for diabetic retinopathy and published it in JAMA, reporting an area under the ROC curve of about 0.99 for referable disease on two validation sets (Gulshan et al., 2016) — algorithm sensitivity and specificity in the range of a trained grader.

Then came a regulatory first. In April 2018 the FDA authorized IDx-DR as the first autonomous AI diagnostic system that returns a screening result without a clinician interpreting the image. Its pivotal trial in primary-care offices reported observed sensitivity of 87.4% and specificity of 89.5% for more-than-mild retinopathy (Abràmoff et al., npj Digital Medicine, 2018). That's a camera in a family-medicine clinic, not an eye specialist, making the call.

The pattern repeated in cardiology. Awni Hannun and colleagues trained a deep network on more than 90,000 single-lead ECGs and reported arrhythmia detection at a level comparable to expert cardiologists, in Nature Medicine (Hannun et al., 2019).

And the language models came for our exams. In 2023, Kung and colleagues reported that ChatGPT scored at or near the roughly 60% passing threshold across all three USMLE steps, with no specialized medical training (Kung et al., PLOS Digital Health, 2023). "Almost passing" is the honest framing — but it was a general-purpose chatbot, not a medical one.

Why it matters when you work with AI

Here's the through-line worth carrying into your own coding. Every system above — retinal screener, ECG reader, ChatGPT — is the same machinery: weighted layers, an activation function, backprop, and (for the recent ones) attention over embeddings. Once you see that, the field stops looking like a wall of buzzwords.

A few practical takeaways:

• These are pattern-matchers with error bars, not oracles. A 0.99 AUC or a "cardiologist-level" result is a statistic on a specific dataset — it can drift on patients, cameras, or populations the model never saw. Ask what it was validated on.
• Embeddings and attention are the ideas to actually internalize. They explain both the magic (meaning as geometry, focus on what's relevant) and the failure modes (a model confidently "hallucinating" is just attention landing on the wrong pattern).
• Transfer learning is why you rarely start from zero. Almost everything you'll build fine-tunes or prompts a pretrained model rather than training one — which is a gift, and also means you inherit its blind spots.
• Verify before you trust, especially in medicine. The FDA authorized an autonomous tool only after a prospective trial, not a demo. That's the right instinct to bring to any AI you'd put near a patient — or into production.

Read the full case study, with sources →

Part 4 — Applied & Systems · Chapters 12–16

Applied Systems: Recommenders, Cryptography, Scale, and Responsibility

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

This is the part of the book where the ideas leave the whiteboard and hit the real world — the messy engineering of getting software to recommend, store, protect, scale, and behave itself.

Start with recommendation engines, the software that guesses what you'll want next. There are two basic recipes. Content-based filtering says "you liked this thing, here's another thing with similar features." Collaborative filtering ignores the features entirely and looks at behavior: "people who acted like you also liked X." Most real systems are hybrid — they blend both. The classic headache is the cold-start problem: a brand-new user or a brand-new item has no history, so the system has nothing to reason from. It's the recommender equivalent of a new patient with no chart.

Next, data handling — the unglamorous plumbing of storing, governing, and shrinking data. Compression is the standout trick. Huffman coding, an algorithm David Huffman worked out as an MIT term paper in 1951 and published in 1952, gives frequent symbols short codes and rare ones long codes, squeezing files with zero loss. It still lives inside ZIP archives and JPEG photos today.

Then cryptography, the math that makes secrets possible over an open wire. Symmetric encryption uses one shared key for locking and unlocking — fast, but both sides need the same secret. Asymmetric (public-key) encryption uses a pair: a public key anyone can use to lock, and a private key only you can use to unlock. Hashing is different again — a one-way fingerprint of data. A good hash should never produce the same fingerprint for two different inputs; when it does, that's a collision, and it's a security emergency.

Then scale. Amdahl's law, stated by Gene Amdahl in 1967, is the cold shower of parallel computing: if part of a job must run in sequence, that serial part caps your maximum speedup no matter how many processors you throw at it. Per the standard formulation, a task that's 10% inherently serial can never go more than 10 times faster. GPUs (graphics chips repurposed for math) and tools like Apache Spark push against that ceiling by doing enormous amounts of work in parallel.

Finally, responsibility: explainability (can you say why the model decided that?), bias (does it treat groups unfairly?), and NP-hard problems (a class of problems for which no known algorithm finds the perfect answer quickly, so we settle for good-enough).

Where you've seen it

The Netflix Prize is the recommender legend. From 2006 to 2009, Netflix offered $1 million to anyone who could beat its Cinematch algorithm by 10% on rating-prediction accuracy (RMSE). A stitched-together ensemble of over 100 models finally won. The twist: Netflix's own 2012 engineering blog explained that the full winning ensemble was never put into production — the accuracy gain didn't justify the engineering cost, and the business had already moved from DVD ratings to streaming behavior. Meanwhile the workhorse that actually scaled was Amazon's item-to-item collaborative filtering, described by Linden, Smith, and York in IEEE Internet Computing in 2003 — the "customers who bought this also bought" engine.

In healthcare

For a physician, these abstractions have blood pressure.

Encryption is the difference between a HIPAA safeguard and a breach. The HHS HIPAA Security Rule treats encryption of electronic protected health information — both at rest on disk and in transit across the network — as a core safeguard for keeping patient data confidential. When broken cryptography meets clinical systems, the result is not abstract: the 2017 WannaCry ransomware worm swept through the NHS, and the UK National Audit Office later reported roughly 19,000 cancelled appointments and an estimated £92 million in total cost. Cancelled appointments are delayed diagnoses.

Bias in a care algorithm is a clinical harm. The most sobering example is Obermeyer and colleagues in Science in 2019. A widely used population-health algorithm decided who got extra care management — but it used past healthcare spending as a stand-in for health need. Because less money had historically been spent on Black patients at the same level of illness, the model systematically judged them healthier than they were. The authors calculated that fixing the proxy would raise the share of Black patients flagged for extra help from about 17.7% to 46.5%. Same data, wrong target variable, real patients left out.

And the tide of data is only rising. The cost of sequencing a human genome has fallen off a cliff — the NHGRI's cost-per-genome data shows a drop from roughly $100 million in 2001 to a few hundred dollars, outpacing even Moore's law. Cheaper genomes mean more genomic data flooding into medicine, which loops right back to storage, governance, and encryption.

Why it matters when you work with AI

If you take one lesson from this part of the book, make it this: an accurate model is not the same as a usable, safe, or fair one. Netflix proved a champion algorithm can be too costly to ship. Amazon and COMPAS proved a confident model can be confidently unjust. Obermeyer proved that the thing you optimize for — cost versus need — can quietly encode discrimination even when nobody intends it.

So when you evaluate any clinical AI, ask the questions this chapter arms you with:

• What is it actually optimizing? A proxy like cost or prior utilization can smuggle in bias, as the Science study showed.
• Can it explain itself? An unexplainable score is hard to challenge at the bedside.
• Was it tested across the groups you serve? Aggregate accuracy hides subgroup harm.
• Is the data protected end to end? Encryption and sound key management are patient safety, not just IT hygiene — WannaCry is the cautionary tale.
• Where's the cold-start blind spot? New patients and rare conditions are exactly where thin data makes models least trustworthy.

You don't need to build these systems to interrogate them. Knowing how recommenders guess, how encryption holds, where parallelism hits its ceiling, and how bias sneaks in through the objective function is enough to be the person in the room who asks the question that keeps a patient safe.

Read the full case study, with sources →

Part 5 — Concept Deep-Dives · Chapter 7 companion

Naive Bayes and Thinking in Probabilities

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

Punchline first: Bayes' rule is the arithmetic of changing your mind. You start with a belief, you meet a piece of evidence, and the rule tells you exactly how far to move. That's the whole idea. Everything else is bookkeeping.

Three words carry it. The prior is what you believed before the evidence arrived — "about 15% of the email this address receives is spam," or "this kind of patient has maybe a 15% chance of the disease." The evidence is the clue you just observed. The posterior is your updated belief afterward. Bayes' rule is the recipe that turns prior + evidence into posterior, and it has one non-negotiable insight baked in: how much a clue should move you depends not just on how often it shows up when the answer is yes, but on how often it also shows up when the answer is no. A clue that appears either way tells you nothing, no matter how dramatic it looks.

Now the "naive" part. A real email — or a real patient — presents many clues at once, and in truth the clues are tangled: the word "FREE" and three exclamation points travel together. Modeling all those tangles is combinatorially hopeless. Naive Bayes makes one cheerful simplification: pretend every clue is independent — treat each one as its own separate nudge and just multiply the nudges together. That assumption is almost always false. And here is the small miracle the algorithm is famous for: it works anyway. For classification you don't need the exact probability, only for the right answer to come out ahead — and the independence shortcut usually preserves the ranking while making the math cheap enough to run on every email you'll ever receive.

Where you've seen it

The canonical story is spam. In A Plan for Spam (2002), Paul Graham described ditching hand-written filter rules for a statistical approach: score every token by how often it appears in your spam versus your legitimate mail, then, for a new message, combine the fifteen most telling tokens with Bayes' rule into a single spam probability. What's worth dwelling on — and what makes this a deep-dive rather than a footnote — is why that beat the rule-writers. First, the filter is personal: it learns your mail, so the word "mortgage" can be damning in my inbox and routine in a loan officer's. Second, it's adversary-resistant in an honest way: to evade it, a spammer has to make spam look statistically like the mail you actually receive, which mostly defeats the purpose of the spam. Third, it degrades gracefully: no single token decides; fifteen weak clues vote. Graham reported his filter missing fewer than 5 spams per 1,000 with zero false positives — from math a first-year statistics student can follow.

In healthcare

Here is the part I find genuinely satisfying: this is the algorithm a hospitalist already runs mentally on every shift. Clinical epidemiology just uses different words. Pre-test probability is the prior. The likelihood ratio (LR) of a test is the strength of the nudge. Post-test probability is the posterior. "Pre-test probability × likelihood ratio → post-test probability" is Bayes' rule — the Fagan nomogram that generations of residents learned from is nothing more than a paper Bayes calculator, published in the New England Journal of Medicine in 1975.

Work one familiar example. A young patient with pleuritic chest pain but a low pre-test probability of pulmonary embolism — say a few percent. A negative d-dimer is a strong negative nudge (a very small likelihood ratio), and a few percent multiplied down lands close to zero: that is the entire logical basis for using d-dimer to rule out PE in low-risk patients, and for not ordering it when the pre-test probability is high, where even a negative result can't push the posterior low enough to act on. Troponin behaves the same way: the identical number means something different in a 30-year-old with a pulled muscle and an 80-year-old with crushing substernal pressure, because the priors differ. Steven McGee's Simplifying Likelihood Ratios even gives clinicians the mental shortcut: LRs of 2, 5, and 10 raise the probability by roughly 15, 30, and 45 percentage points. That's a bedside naive Bayes, run in your head, no computer required.

So when a physician meets the spam filter, nothing new is being learned — the two are the same math wearing different clothes. The filter's "tokens" are your history, exam, and labs; its spam score is your post-test probability. (As always in this series: the clinical examples are illustrative and educational, not medical advice.)

Why it matters when you work with AI

First, small and auditable beats big and opaque more often than the hype admits. A naive Bayes triage model has parameters you can print on one page: this clue, this weight, learned from these counts. When it errs, you can see which clue misled it and fix the data. Cynthia Rudin's argument in Nature Machine Intelligence is exactly this: for high-stakes decisions, stop explaining black boxes after the fact and use models that are interpretable to begin with — the accuracy sacrifice is frequently zero. For a great many sorting-and-flagging jobs (which message, which claim, which chart needs a human first?), the tiny probabilistic model you can audit is the better engineering choice, not the budget one.

Second, Bayesian thinking is how you should read any model's output — including a large language model's. A confident answer is evidence, not truth: it should update your belief in proportion to how often the system is right on cases like this one, starting from a sensible prior. And never forget the base rate: a 95%-accurate alarm hunting a condition present in 1 patient per 1,000 will be wrong in the overwhelming majority of its alerts, because the prior was tiny before the alarm ever fired. Clinicians internalize this about screening tests; the same discipline applies verbatim to AI alerts, AI diagnoses, and AI-generated citations. The habit this deep-dive is really selling isn't an algorithm — it's thinking in posteriors: hold beliefs in percentages, move them in proportion to the strength of the evidence, and be suspicious of any clue (or any model) that claims to settle the question alone.

Read the full case study, with sources →

Part 6 — Concept Deep-Dives · Deep-dive companion

Latent Space: The Map of Meaning

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

Punchline first: a modern AI model doesn't store words — it stores addresses. Every word, sentence, image, or patient record the model handles gets converted into a long list of numbers, and that list is a location in a huge abstract space. Things that mean similar things get nearby addresses. That space is called latent space (latent because nobody designed it — it emerges from training), and one thing's address in it is called its embedding.

The mental model is a map. On a city map, two restaurants that are close together are close in geography. In latent space, two points that are close together are close in meaning: "chest pain" and "angina" land near each other, "chest pain" and "parking invoice" land far apart. Distance on this map is something you can compute — usually the angle between the two number-lists, called cosine similarity — so "how alike are these two things?" stops being a judgment call and becomes arithmetic.

Two more ideas complete the picture. First, arithmetic with meaning. The word2vec paper (Mikolov and colleagues, 2013) showed that directions in this space can carry concepts: take the point for king, subtract man, add woman, and the nearest point is roughly queen. Honest caveat: that famous example is the show pony — it's the one that works beautifully, many analogies come out mushier — but the underlying finding is real and it changed the field: meaning has geometry.

Second, the flattening lens. Real embedding spaces have hundreds or thousands of dimensions; humans can look at two or three. Tools like t-SNE (van der Maaten & Hinton, 2008) and UMAP (McInnes and colleagues, 2018) squash the space down to a 2-D picture that tries to keep neighbors as neighbors. The gotcha, spelled out in Distill's How to Use t-SNE Effectively: these pictures preserve who is near whom, but cluster sizes and the distances between clusters are largely artifacts — two blobs looking far apart, or one blob looking tighter than another, is not evidence of anything. Read the picture like a subway map, not a satellite photo: connections are real, geography is stylized.

Where you've seen it

Embeddings are why search stopped needing the magic words. Classic search matched the letters you typed; semantic search embeds your query and returns the nearest neighbors in meaning — ask "why does my chest hurt when I climb stairs" and documents about exertional angina surface, even if they never use your phrasing. The same trick drives recommendations ("people who liked this sit near you in taste-space") and RAG — retrieval-augmented generation — where an assistant embeds your question, fetches the closest passages from a document store, and answers from those. When a chatbot "looks something up," latent-space nearest-neighbor search is almost always the looking.

In healthcare

The clinical version of "words that behave alike sit together" is patients who behave alike sit together. Embed each patient — labs, vitals, medications, diagnoses — as a point, and clusters become candidate phenotypes: subtypes nobody defined in advance. The flagship example is the sepsis work by Seymour and colleagues in JAMA (2019), which clustered 63,858 patients and found four reproducible sepsis phenotypes (α, β, γ, δ) with different organ-dysfunction patterns and different mortality — and, provocatively, re-analyses where the phenotype mix changed whether a trial's treatment looked helpful. Patient-similarity search points the same direction: "show me patients whose trajectory looks like this one's" is a nearest-neighbor query in a latent space.

The discipline to carry in: clusters are hypotheses, not diagnoses. An algorithm will always hand you clusters — that's its job — whether or not they carve nature at the joints. The sepsis phenotypes earn attention because they were validated across cohorts and tied to outcomes, not because a colorful UMAP plot contained blobs. A cluster is where the science starts, never where it ends. (Illustrative and educational, as always — not medical advice.)

Why it matters when you work with AI

First, embeddings are how AI systems actually remember and retrieve. Behind nearly every "the assistant searched your documents" feature is the same loop: embed everything once, embed the query, return the nearest neighbors. If you understand that one loop, RAG, semantic search, recommendation, and agent "memory" stop being separate mysteries — they're all the same map lookup.

Second, the distance threshold is a judgment call, and someone has to own it. How close must a retrieved passage be to count as relevant? How far can a draft drift before our brand gate rejects it? Nothing in the math answers that; a human picks the number, watches what it lets through and what it wrongly blocks, and tunes. It is a sensitivity/specificity trade-off — a dial every clinician already knows how to reason about.

Third, latent space is where bias hides. The map is learned from human text, so it inherits human associations: Bolukbasi and colleagues showed in 2016 that word embeddings trained on news text placed man near computer programmer and woman near homemaker, and proposed ways to measure and reduce such bias. A patient-similarity space learned from historical care data can encode historical inequities in exactly the same silent way. The geometry is powerful precisely because it absorbs the data's structure — including the structure we'd rather it hadn't learned. Audit the map before you navigate by it.

Read the full case study, with sources →

Part 7 — Concept Deep-Dives · Deep-dive companion

Gaussian Splatting and the Jacobian: From Bell Curves to 3-D Worlds

Study notes shared as our founder learns to program — the ideas come from Imran Ahmad's 50 Algorithms Every Programmer Should Know; the plain-language explanations and any mistakes are ours.

The idea, in plain language

Punchline first: the technology behind the eerily photorealistic 3-D captures showing up in phones and film is built from two ideas you already half-know — the bell curve, and "how fast things change here." None of this sits in a silo. Let's build the ladder one rung at a time.

Rung one: a Gaussian is just the bell curve. Every physician reads one daily without ceremony: lab reference ranges are bell curves. A normal sodium isn't a single number — it's a hump of likely values, densest in the middle, fading smoothly at the tails, described completely by a center (the mean) and a width (the standard deviation). Now free the bell curve from the lab report. In two dimensions it becomes a soft hill; in three, a fuzzy blob — dense at its center, translucent toward its edges, with a center, a size, and (if you let the widths differ by direction) an orientation. Hold that image: a soft, stretchable, tiltable blob of density. That is all a 3-D Gaussian is.

Rung two: a derivative is "how fast things change right here." Speed is how fast position changes; a rising creatinine's slope is how fast kidney function is worsening. Zoom in far enough on any smooth curve and it looks like a straight line — the derivative is that line's steepness, a local linear stand-in for a complicated curve. Now widen the idea to many dimensions at once. A camera projection takes a point in 3-D space (three input numbers) to a pixel on your screen (two output numbers). Ask "if I nudge the point a hair in each 3-D direction, how does its screen position shift?" and the answer is a small grid of slopes — every output's sensitivity to every input. That grid is the Jacobian. It is the derivative's grown-up form: the local linear window that tells you how a tiny patch of space gets stretched, squeezed, and rotated by a transformation. Complicated mapping, honest simple summary — valid right here, in this neighborhood.

Rung three: put them together and you get Gaussian splatting. 3D Gaussian splatting (Kerbl, Kopanas, Leimkühler & Drettakis, 2023) represents a scene as millions of those soft 3-D blobs, each with a position, shape, color, and transparency. To draw the scene from your viewpoint, each blob must be projected — "splatted" — onto the screen. Projection is a warping, nonlinear map, but each blob is tiny, and inside a tiny neighborhood the Jacobian's linear window is an excellent stand-in. So the renderer uses exactly it: the Jacobian of the camera projection turns each 3-D Gaussian into the right stretched, tilted 2-D ellipse on screen — the local linear approximation doing real work, a trick worked out in the EWA splatting literature (Zwicker and colleagues, 2002) two decades before. Layer millions of soft ellipses, blend them front to back, and a photograph-like image emerges.

Where you've seen it

This is the technology behind the current wave of photorealistic 3-D capture — walk around an object or a room with an ordinary camera, and software reconstructs a scene you can fly through from any angle. Earlier "radiance field" methods (NeRFs) produced stunning stills but rendered slowly, because answering "what color is this pixel?" meant querying a neural network over and over. The Gaussian-splatting paper changed the trade: represent the scene as explicit blobs instead of a network, splat them with the Jacobian trick, and the authors reported real-time rendering (≥ 30 frames per second at 1080p) with state-of-the-art visual quality. Real-time is the threshold that moves a technique from "research demo" to "product" — which is why splat-style captures have spread quickly into phone scanning apps, VR walkthroughs, visual effects, and game tooling. When you see a drone-scanned house you can tour in a browser, or a film set digitized for reshoots, you are very likely looking at millions of bell curves.

In healthcare

Two bridges, one honest and one already under your feet.

The honest one: 3-D reconstruction is an active research direction in medicine, not deployed practice. The appeal is easy to state. Surgical planning and simulation want faithful, explorable 3-D models built from ordinary imaging; endoscopy and laparoscopy produce video from a moving camera — exactly the input these reconstruction methods eat — and research groups are exploring splat-style techniques for reconstructing anatomy from such footage, where real-time rendering matters because a simulator must react at interactive speeds. Whether these approaches become clinical tools depends on the same gauntlet every clinical technology faces: validation on real cases, failure-mode analysis, and regulatory review. Treat this paragraph as a map of potential, not a claim that your hospital does this today. (Illustrative and educational — not medical advice, and not a product claim.)

The bridge already under your feet: you have trusted Gaussians your whole career. A reference range is a statement that a population's values form a bell curve and that we act differently in its tails. Splatting simply promotes the same object from describing a lab value's uncertainty to describing where matter sits in space — density highest at the blob's center, fading at its edges. The math didn't change when it left the lab report; it just got a graphics card.

Why it matters when you work with AI

Here is why this deep-dive ends the ladder rather than decorating it: differentiability is the engine of modern AI, and the Jacobian is the engine part. A neural network learns by asking, millions of times: "if I nudge this internal knob slightly, does my error go up or down, and how fast?" That question is answered by derivatives, and pushing the answer backward through a network's many layers — backpropagation, the algorithm popularized by Rumelhart, Hinton & Williams in 1986 — is nothing more than chaining local linear windows together: each layer's Jacobian says how small changes pass through it, and multiplying the windows layer by layer tells every knob its share of the blame. Gaussian splatting trains the same way — the renderer itself is differentiable, so each blob's position, shape, and color get nudged by gradients until the rendered images match the photographs.

So the ladder closes into a loop. The bell curve from your lab reports gives us a soft, adjustable building block. The derivative — "how fast things change here" — grows up into the Jacobian, the local linear window on any complicated transformation. Rendering uses that window to draw; learning uses that same window, chained, to improve. One piece of calculus, pointed in two directions. When someone tells you a system "learned," you now know the mechanism underneath: not magic, not understanding — millions of tiny, local, honest measurements of how fast things change here, followed accumulatively downhill. That intuition travels to every AI system you will ever evaluate.

Read the full case study, with sources →