DEV Community: Lavitra

The Algorithm Behind "Are You Also Experiencing X?"

Lavitra — Wed, 26 Aug 2026 06:11:43 +0000

A symptom checker that only reads one message and immediately names a diagnosis is not doing anything a doctor would recognize as diagnosis. A real intake asks a follow-up question, one that actually narrows things down, not a random one. Building the Neo4j knowledge graph project, that follow-up question turned out to be the single most interesting piece of logic in the whole app, more interesting than the graph schema itself, because it is a small, greedy algorithm making a real decision under uncertainty, three times in a row, before giving up and committing to an answer.

Why the naive versions of this don't work

The obvious bad version is a fixed checklist, ask about fever, then cough, then fatigue, in that order, every time, regardless of what the patient already said. That wastes questions on symptoms that do not actually distinguish between the diseases still under consideration. A slightly less bad version asks about a random unconfirmed symptom, which at least avoids a fixed order but still has no reason to expect the answer will be useful.

What actually needs to happen is closer to how a doctor thinks: given everything the patient has said so far, what one additional piece of information would eliminate the most remaining possibilities. That is a real algorithmic question, and answering it requires two things: a ranked list of current candidate diseases, and a way to pick the most informative next question from that ranked list.

The actual two-step algorithm

Step one, rank candidate diseases by how well they match confirmed symptoms so far.

MATCH (s:Symptom)-[:INDICATES]->(d:Disease)
WHERE s.name IN $confirmed
WITH d, count(s) as match_score, collect(s.name) as matched
ORDER BY match_score DESC
RETURN d.name as disease, match_score, matched
LIMIT 5

This finds every disease connected to at least one confirmed symptom, counts how many confirmed symptoms each one matches, and returns the top five, ranked by match count. Early in a conversation, with only one or two symptoms confirmed, this list is going to be broad, plenty of diseases share a single common symptom like fatigue or headache. That breadth is expected and fine, it is exactly what the next step is meant to narrow down.

Step two, and this is the actual clever part, find the symptom that appears most often across the current candidates, excluding anything already asked about.

MATCH (s:Symptom)-[:INDICATES]->(d:Disease)
WHERE d.name IN $diseases AND NOT s.name IN $exclude
RETURN s.name as symptom, count(d) as freq
ORDER BY freq DESC, symptom ASC
LIMIT 3

$diseases is the current candidate list from step one. $exclude is every symptom already confirmed or already ruled out, so the same question never gets asked twice. The query counts, across only the current candidates, how many of them share each remaining symptom, and returns the most common one first. This is a real, if simple, information-theoretic idea: the symptom shared by the most current candidates is the one whose answer, yes or no, is most likely to split the candidate list meaningfully, confirming it strengthens several candidates at once, ruling it out eliminates several at once. A symptom relevant to only one candidate barely moves the needle either way.

The loop asks, evaluates, and re-ranks, up to three times, and this is enforced explicitly, not left implicit. The actual stopping condition in the application code is direct:

if st.session_state.question_count >= 3 or not next_symptom or not candidates:
    st.session_state.stage = "diagnosed"

Three clarifying questions, or an earlier exit if the algorithm runs out of useful questions to ask, whichever comes first. This cap is a genuine product decision, not a technical limitation, more questions might narrow the candidate list further, but real users lose patience with an interrogation, and three rounds was the balance chosen between accuracy and not being annoying.

Answers are not restricted to a fixed yes or no. A patient can respond with plain free text instead of tapping a button, and that response gets analyzed separately, first checked for whether it confirms or denies the specific symptom asked about, and second, scanned for any other symptom the patient volunteered that was not explicitly asked for:

prompt = f"""
The doctor asked the patient if they have the symptom: "{current_symptom}".
The patient responded: "{user_text}".

Analyze the patient's response and extract:
1. Did they confirm having "{current_symptom}"? (true, false, or null if unclear).
2. Did they mention any other symptoms they have, from this allowed list:
{json.dumps(all_symptoms)}
"""

That second part matters more than it might look like. A patient answering "no, but I do have chest pain" should not have that volunteered detail thrown away just because it was not the specific symptom asked about, so any additional confirmed symptoms found in the response get added straight into the confirmed set, feeding directly back into the next round's candidate ranking. There is also a plain keyword-matching fallback for when no LLM API key is configured, checking for words like "yes" or "no" directly, which keeps the app functional in a degraded but still usable way without an API dependency.

Where this algorithm is honestly limited

This is a greedy heuristic, not a real diagnostic reasoning system, and it is worth being direct about the gap. It optimizes one step at a time, picking whichever single question looks most useful right now, with no lookahead into how the answer might interact with a question two steps later. It also treats every disease-symptom connection as equally weighted, a genuinely rare, highly specific symptom and a common, low-specificity one count identically in the match score, when a real diagnostic process would weight a rare, specific symptom far more heavily, since it carries much more information. None of this makes the algorithm wrong for what it is being asked to do, narrow a candidate list reasonably well in three questions or fewer, it just means calling it "diagnostic reasoning" would be overselling a fairly simple, honest heuristic.

What this means practically

A hard question limit is a legitimate product decision, not a compromise to apologize for. Optimizing for "most useful next question" only matters if the user actually sticks around to answer it.
Ranking a next question by how many current candidates share it is a simple, effective approximation of information gain, without needing the full statistical machinery of a real Bayesian update.
Free-text answers should be scanned for more than the literal yes or no you asked for. Discarding volunteered information because it did not fit the expected answer shape wastes a genuinely useful signal the user already gave you.
Be honest in the actual product about what kind of reasoning this is. A greedy, unweighted heuristic can produce a genuinely useful conversation without needing to be dressed up as more sophisticated than it actually is.

Conclusion

"Are you also experiencing X" is not a random or scripted question in this project, it is the output of a two-step query: rank the current candidate diseases by symptom overlap, then find the single remaining symptom shared by the most of them, repeated up to three times, with every answer, confirmed, denied, or volunteered, feeding back into the next round. It is a small algorithm, honestly closer to a smart checklist than real medical reasoning, but it is the specific piece of this project that actually behaves like it is thinking, rather than just retrieving.

Three.js Explained: What You're Actually Building With Scene, Camera, and Mesh

Lavitra — Thu, 20 Aug 2026 10:22:36 +0000

Every Three.js scene, no matter how impressive the final result looks, is built from the same four pieces: a scene to hold things, a camera to look at them from somewhere, a renderer to actually draw the picture, and one or more meshes, the objects themselves. Nothing about a spinning 3D product viewer or a particle-filled hero section changes that foundation, it just adds more of these same four ingredients and animates them over time.

What problem Three.js actually solves

The browser can talk to a GPU directly through low-level graphics APIs, historically WebGL, more recently WebGPU. Both are genuinely low-level, closer to how a graphics driver thinks than how a developer thinks, full of buffers, shaders, and matrix math that has nothing to do with the actual 3D object you are trying to put on screen. Three.js exists to sit on top of that low-level API and give you a much higher-level vocabulary, scenes, cameras, meshes, lights, instead of raw GPU buffers, so building a 3D scene feels closer to assembling objects than programming a graphics pipeline by hand.

The four pieces, and what changed underneath them

Scene, camera, renderer, mesh, the minimum you actually need.

import * as THREE from 'three';

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
const renderer = new THREE.WebGLRenderer();
renderer.setSize(window.innerWidth, window.innerHeight);
document.body.appendChild(renderer.domElement);

const geometry = new THREE.BoxGeometry(1, 1, 1);
const material = new THREE.MeshStandardMaterial({ color: 0x2266ff });
const cube = new THREE.Mesh(geometry, material);
scene.add(cube);

const light = new THREE.DirectionalLight(0xffffff, 1);
light.position.set(5, 5, 5);
scene.add(light);

camera.position.z = 5;
renderer.render(scene, camera);

Each piece has exactly one job. The Scene is a container, nothing renders unless it has been added here. The PerspectiveCamera defines a viewpoint, its field of view, aspect ratio, and near and far clipping distances, essentially how far away things can be before they stop being drawn at all. A Mesh is not one thing, it is always two things combined, a Geometry, the actual shape, and a Material, how that shape's surface responds to light and color. A box with no light in the scene will render as a flat, unlit silhouette, because a standard material needs a light source to actually shade its surfaces, which is why the DirectionalLight in that example is not optional decoration, it is what makes the cube look three-dimensional instead of a flat colored square.

The renderer is the piece that changed the most, and 2026 is specifically when that change became real. For most of Three.js's history, WebGLRenderer was the only serious option, translating your scene into WebGL draw calls. As of Three.js r171, released in late 2025, WebGPURenderer became a genuinely production-ready alternative, not an experimental side project. The part worth knowing is what did not change, the Scene, Camera, and Mesh API stays identical either way, swapping renderers is close to a one-line change:

import * as THREE from 'three/webgpu';

const renderer = new THREE.WebGPURenderer({ antialias: true });

WebGPURenderer automatically falls back to a WebGL 2 backend if the user's browser does not support WebGPU, so choosing it does not mean abandoning older devices, it means opportunistically getting WebGPU's benefits, lower CPU overhead and access to compute shaders for things like large particle systems, when the browser can provide them.

Shaders got a real upgrade too, through something called TSL. Historically, custom shader code in Three.js meant writing raw GLSL, WebGL's shading language, which simply does not run on a WebGPU backend, which speaks WGSL instead. TSL, the Three.js Shading Language, lets you write shader logic once in a JavaScript-like syntax that gets transpiled automatically to either GLSL or WGSL depending on which renderer actually ends up running. This matters concretely for anyone who has hand-written shaders before, it removes the need to maintain two separate shader codebases just to support both rendering backends.

The honest caveat worth having before reaching for WebGPU

It would be misleading to present this as a strict upgrade with no tradeoffs, so it is worth being direct about the real state of things in 2026. Browser support, while much better than a couple of years ago, is still not universal, several major browser and platform combinations, including Firefox on Linux and on Android, did not have stable WebGPU support as of mid-2026, which is exactly why the automatic WebGL fallback is not a minor detail, it is the thing keeping those users from silently getting a broken scene.

It is also not automatically faster. Independent benchmarks on scenes with a large number of separate, non-instanced meshes have found WebGLRenderer outperforming WebGPURenderer in specific cases, and Three.js's own maintainers are explicit that simply swapping the renderer class, with no other changes, should not be expected to produce a free performance win. WebGPU's real advantages, lower CPU overhead, native compute shader access, better handling of very high draw call counts, show up specifically in compute-heavy or draw-call-heavy scenes, not universally. For an existing, non-trivial scene, migrating fully, including any custom postprocessing, which does not carry over automatically and needs rebuilding on the newer stack, has reportedly taken production teams a few months, not an afternoon.

What this means practically

Every Three.js scene reduces to the same four building blocks, regardless of how visually complex the final result is: a scene to hold objects, a camera defining a viewpoint, a renderer that draws the picture, and meshes made of geometry plus material.
A mesh with a standard material needs a light in the scene to actually look three-dimensional. An unlit scene is a common first mistake, not a bug.
For a new project today, starting with WebGPURenderer is low risk, given the automatic WebGL fallback, but do not assume it hands you a performance improvement without profiling your specific scene.
For an existing production scene, only invest in a full WebGPU migration if you are actually hitting a specific performance ceiling WebGL cannot solve, compute-heavy workloads or very high draw call counts, rather than migrating for its own sake.

Conclusion

Three.js's real contribution has never been the renderer choice, it is the higher-level vocabulary, scene, camera, mesh, light, that stays consistent no matter which low-level graphics API is doing the actual drawing underneath. The WebGL-to-WebGPU shift happening through 2025 and 2026 is a genuinely significant change to what is possible, particularly for compute-heavy scenes, but it is an addition to that vocabulary, not a replacement for understanding it, and treating a renderer swap as an automatic win, rather than something to profile and decide on deliberately, is the mistake worth avoiding.

Agentic RAG: What Happens When Retrieval Becomes a Decision Instead of a Step

Lavitra — Thu, 20 Aug 2026 04:46:09 +0000

An earlier post on RAG described it as handing a model the right reference right before it answers. That description was accurate, and it was also describing the simplest possible version of the idea: retrieve once, generate once, done. Agentic RAG is what you get when retrieval stops being a fixed step in a pipeline and becomes something an agent decides to do, evaluates, and redoes if the first attempt was not good enough. It is the same retrieval concept from before, placed inside the same think, act, observe loop covered in the agent posts, with the "act" step specifically being a search.

Where the fixed pipeline actually falls short

Traditional RAG runs the same three steps for every query, regardless of what that query actually needs: embed the question, retrieve the closest matching chunks, hand them to the model to generate an answer. This works well for direct lookup questions, where the answer genuinely lives in one or two retrieved passages. It has no good answer for a question that needs comparing numbers from two different documents, or one where the first retrieval attempt returns irrelevant chunks because the query was phrased ambiguously. A fixed pipeline has no mechanism to notice that its own retrieval was weak, it just generates an answer from whatever came back, confidently, regardless of whether that evidence was actually sufficient.

Retrieval as a loop, not a step

The core change is a control loop wrapped around retrieval.

Instead of retrieve once and generate, an agentic RAG system retrieves, reasons about whether what it got back is actually enough to answer the question, and either proceeds to generate or goes back and tries again, a different query, a different source, a different tool entirely. This is the exact same loop shape from the earlier agent posts, applied specifically to the retrieval step. Where a fixed pipeline treats retrieval as a single deterministic action, agentic RAG treats it as one possible action the agent can choose to take, evaluate, and repeat.

A few named patterns are worth knowing, because they show up constantly in how this actually gets built.

Corrective RAG explicitly scores the relevance of retrieved chunks before generation, and if that score is low, triggers a fallback, often a web search, rather than feeding weak evidence to the model anyway. Self-RAG has the model reflect on its own retrieved context and its own draft answer, checking whether the response is actually grounded in what was retrieved before finalizing it. Adaptive and multi-hop patterns handle questions that genuinely require several rounds of retrieval, where each round's results inform what to search for next, closer to research than lookup. None of these are exotic, they are all specific implementations of the same underlying idea: do not trust the first retrieval blindly, build in a checkpoint that can catch a bad one.

This is also exactly where a framework like LangGraph earns its place.

A fixed RAG pipeline fits naturally into a linear chain, which is why plain LCEL-style composition works fine for it. The moment retrieval needs to loop back on itself, retrieve, evaluate, maybe retrieve again, that is precisely the shape a linear chain cannot express and a graph with a conditional edge can. An agent node evaluates retrieved chunks, a conditional edge routes either forward to generation or back to a retrieval node with a reformulated query, and that backward edge is the loop that makes the whole pattern possible, the same mechanism covered in the LangGraph post, just applied to a retrieval-specific agent instead of a general tool-calling one.

None of this is free, and pretending otherwise would be dishonest.

Adding an evaluation and retry loop around retrieval genuinely increases both cost and latency, current estimates put agentic RAG in the range of three to ten times the token usage and two to five times the latency of a single-pass retrieval pipeline, because you are now potentially running multiple retrieval rounds and extra reasoning steps the simple version never needed. That is not a rounding error, it is a real operational tradeoff, and it only makes sense to pay for use cases where the fixed pipeline's blind spot actually matters, ambiguous or multi-part questions, high-stakes domains where a wrong answer built on weak evidence is genuinely costly, not for straightforward lookup questions where one good retrieval pass was always going to be enough.

What this means practically

⁘ Agentic RAG is not a strictly better version of RAG, it is RAG with a loop wrapped around the retrieval step, and that loop costs real tokens and real latency every time it runs.

⁘ The actual mechanism worth remembering is evaluation before generation, checking whether retrieved evidence is sufficient rather than assuming it is, and only that checkpoint is what justifies the added cost.

⁘ If most of your queries are direct lookups with a clear answer in one or two documents, a fixed pipeline is not a lesser choice, it is the correctly scoped one for that problem.

⁘ Reach for agentic RAG specifically when queries are multi-part, ambiguous, or high-stakes enough that a confidently wrong answer built on a bad first retrieval is a real cost worth paying extra latency and tokens to avoid.

Conclusion

Agentic RAG is not a separate technology from RAG or from agents, it is the intersection of both ideas already covered separately: the retrieval mechanism from the RAG post, placed inside the loop structure from the agent posts, with a graph like LangGraph providing the conditional edge that lets a weak retrieval trigger a retry instead of getting passed straight to generation. The value is real for the specific class of question a fixed pipeline cannot handle well. The cost is also real, and skipping the honest tradeoff is how a genuinely useful pattern turns into something reached for by default when a simpler pipeline would have done the job for a fraction of the price.

LangGraph Explained: Giving an LLM Pipeline the Ability to Loop Back on Itself

Lavitra — Tue, 18 Aug 2026 07:11:11 +0000

Part one of this series ended on a specific boundary:LangChain's chain model, even with LCEL's clean pipe syntax, is built for pipelines that flow forward, not ones that loop, branch based on a runtime decision, or need to pause and resume days later. That boundary is exactly where LangGraph starts, and it is worth being precise about what actually changes, because the difference is not "LangGraph is a more powerful LangChain," it is a genuinely different way of modeling a workflow.

From a chain to a graph

A chain, as LCEL expresses it, is a straight line, step one feeds step two feeds step three. LangGraph replaces that shape entirely with a directed graph: named nodes, each one a function that does some work, connected by edges that say which node runs next. The difference that actually matters is that edges do not have to move only forward. A node can have an edge pointing back to an earlier node, which is what makes a real loop possible, and an edge can be conditional, decided at runtime based on the current state, rather than fixed at the moment the pipeline was written.

That last part, an explicit, shared state object that every node reads from and writes back to, is the other core difference. A chain passes output from one step directly into the next. A graph maintains one persistent state across the entire run, and every node's job is to read what it needs from that state and return an update to it.

Nodes, edges, and where the loop actually lives

The basic building blocks, stripped down. A LangGraph graph starts with a state definition, a node or two, and edges connecting them to the built-in START and END markers:

from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END

class State(TypedDict):
    url: str
    result: str
def call_api(state: State):
    result = fetch(state["url"])
    return {"result": result}
builder = StateGraph(State)
builder.add_node("call_api", call_api)
builder.add_edge(START, "call_api")
builder.add_edge("call_api", END)
graph = builder.compile()

This alone is not more powerful than a simple LCEL chain, it is a single node, run once. The actual value shows up once you add a second kind of edge.

Conditional edges are where branching enters the picture.

Instead of a fixed edge, add_conditional_edges connects a node to a routing function that inspects the current state and decides, at runtime, which node should run next:

def route_by_category(state):
    return state["category"]

workflow.add_conditional_edges(
    "classify",
    route_by_category,
    {
        "billing_support": "billing_support",
        "technical_support": "technical_support",
        "general_support": "general_support",
    },
)

The graph does not know in advance which support node will run, that decision genuinely depends on what the model produced in the classify step and gets resolved fresh on every run. This is the kind of branching a linear chain has no clean way to express, because a chain's structure is fixed at write time, not decided at run time.

The loop itself is just an edge pointing backward.

This is the part that actually solves the problem part one ended on. A tool-calling agent, the classic think, act, observe pattern, is expressed as a conditional edge from the agent node that either goes to a tool node or exits, combined with a normal edge sending the tool node's result straight back to the agent:

workflow.add_node("email_agent", call_agent_model_node)
workflow.add_node("email_tools", tool_node)
workflow.add_edge(START, "email_agent")
workflow.add_conditional_edges(
    "email_agent",
    route_agent_graph_edge,
    ["email_tools", END],
)
workflow.add_edge("email_tools", "email_agent")

Trace the actual path: email_agent decides whether a tool call is needed. If yes, execution moves to email_tools, which runs the tool and then unconditionally routes straight back to email_agent. That last edge is the loop, drawn explicitly as a graph structure instead of hidden inside a while statement somewhere in application code. The agent keeps deciding, acting, and observing until its own routing function finally returns END instead of the tool node.

State and persistence turn a single run into something that can pause and resume.

Attaching a checkpointer to a compiled graph saves its state after every step, tied to a thread_id:

from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()
graph = builder.compile(checkpointer=checkpointer)
config = {"configurable": {"thread_id": "session-1"}}
graph.invoke({"url": "https://example.com"}, config)

This is what makes a graph resumable across separate calls instead of only existing for the duration of one Python process. It is also what makes a real human-in-the-loop pattern possible: a node can call interrupt(), which pauses graph execution entirely and waits, potentially for a long time, for an external value before continuing exactly where it left off:

def human_review(state):
    answer = interrupt("Do you approve?")
    return {"messages": [{"role": "user", "content": answer}]}

A chain has no equivalent to this. Once an LCEL chain starts running, it runs to completion or it fails, there is no built-in notion of pausing mid-pipeline and picking back up later with new information.

Why this is a different tool, not a strictly better one

Everything LangGraph adds, explicit state, conditional routing, cycles, checkpointed persistence, comes with more to design and more to reason about compared to a linear chain. A straightforward RAG pipeline gains nothing from being modeled as a graph, it has no branches, no loops, and no need to pause mid-run, so wrapping it in StateGraph just adds ceremony around something LCEL already expresses more simply. LangGraph earns its complexity specifically when a workflow has a genuine loop, a genuine runtime branch, or a genuine need to persist and resume, not by default for anything agent-shaped.

What this means practically

⁘ Model a workflow as a graph the moment it needs to loop, branch based on a runtime decision, or survive being paused and resumed, not before.

⁘ A conditional edge pointing back to an earlier node is the actual mechanism behind a tool-calling agent loop, worth recognizing directly in the graph structure rather than treating agent behavior as a black box.

⁘ A checkpointer and thread_id are what separate a single in-memory run from a workflow that can genuinely pause for human input and resume later, which matters for anything that cannot or should not run start to finish unattended.

⁘ Reaching for LangGraph on a workflow that is genuinely linear adds structure without adding capability. The graph model earns its cost specifically on the class of problem chains cannot express.

Conclusion

The gap identified at the end of part one, loops, runtime branching, and persistent state, is exactly what LangGraph exists to close, by replacing a fixed, forward-only chain with an explicit graph where edges can point backward and state persists across steps and even across sessions. Part one's chain and this post's graph are not competing answers to the same question, they are the right tool for two different shapes of problem, and knowing which shape you actually have is most of the decision.