Answering Pet Health Questions by Walking the Graph

"Why is Max scratching more this week?"

Somewhere in Max's data, the makings of an answer exist: his bowl logged a food switch on July 5, the new kibble's ingredient list includes chicken meal, his tracker has flagged more nighttime restlessness since July 8, and the literature notes chicken as a common sensitivity in retrievers.

No document contains that answer. It has to be assembled — joined across a device, a product database, and a book that have never met. This post is about the retrieval side of our pet graph: how a question becomes a walk through evidence-weighted relationships, why we ripped out the industry-standard alternative to build it this way, and — the part most retrieval write-ups skip — what the system does when the answer honestly isn't there.

The problem: similar text is not an answer

The default architecture would embed the question, fetch the most cosine-similar chunks, and hand them to an LLM. Run that on Max's question and you get… paragraphs about scratching. Grooming tips. A passage on seasonal shedding. All similar; none relevant, because relevance here is a chain of specific facts about this specific dog, and no chunk contains the chain.

There's a second, quieter failure: "more this week" is arithmetic. It means comparing this week's scratching and restlessness against Max's own baseline — a windowed time-series comparison no embedding can perform.

We know these failure modes intimately because we lived them. An earlier iteration of our retrieval stack blended vector similarity with keyword scores, rank fusion, and a reranker. Instrumenting it revealed that the signals we thought were in charge often weren't deciding anything at all, while every quality fix meant re-tuning knobs that broke something else. (That story gets the full post-mortem in Part 5.)

The approach: three signals, and only three

Today's retrieval architecture is deliberately austere. Every ranking and filtering decision comes from exactly three signals:

1. Graph traversal — typed relationship paths, connected-subgraph assembly, and community structure. Connectivity is the substrate: things are related because the graph says so, not because their names co-occur in a paragraph.
2. Evidence-weighted ranking — one ranker: a personalized random walk (Personalized PageRank) over belief-weighted edges. The Dempster–Shafer weight from Part 3 sets each edge's channel width. No score blending, no second ranker layered on top.
3. Provenance chains — every candidate carries its evidence trail as a first-class output, and answers cite sources inline by default.

Just as important is the banned list: vector cosine as a ranking signal, keyword scoring, composite blended scores, text rerankers, and "rescue" floors that quietly pad thin results. Each earned its ban by breaking quality in ways that took weeks to diagnose.

The process: one question, end to end

Step 1 — Understand the question, deterministically. The same zero-shot entity recognition that reads documents at ingest reads the question: it finds Max and scratching as entity mentions, using the graph's own ontology labels. The likely relationship is identified by matching the question's phrasing against the graph's relation vocabulary — its schema, not its content. Anchors resolve to actual graph vertices, then get re-scored by a distinctly graph-flavored check: does this candidate actually have the kinds of relationships the question asks about? If the household has "Bella" the beagle and "Bella's" the boarding kennel, the one with exhibits and ate edges wins the tie. There's no LLM on this hot path; understanding is fast, cheap, and reproducible.

Step 2 — Send the arithmetic to the numbers. "More this week" goes to the measurement layer from Part 2: a windowed comparison against Max's rolling baseline. The two layers meet in exactly two places, and it's worth being precise about them, because "we combine graph and vector search" is where most systems get vague:

• Numbers seed the graph. A range query over measurements returns entity IDs, not rows — "which pets are eating below baseline this week" produces a set of starting points, and the walk begins there. Numeric filter, graph ranking.
• Correlations become edges. When the system finds a statistically meaningful relationship between two measured series, it writes that back into the graph as a real, weighted edge. From then on it's evidence like any other, and the walk can traverse it.

What measurements never do is rank. Numbers answer "how much, compared to what." The graph answers "what's connected and trusted."

Step 3 — Walk. From the anchor vertices, a personalized random walk spreads ranking mass across the neighborhood. Belief weights steer it: the well-corroborated ate → Brand X edge (bowl events, purchase record) is a wide channel; a single-source speculation is a trickle; a refuted edge is a wall the walk cannot cross. Mass concentrates on vertices that are both topologically close to the question and reached through trusted evidence.

Step 4 — Assemble a connected answer. The top-ranked vertices aren't returned as a list — they're stitched into a connected subgraph, formulated as an optimization: vertices carry prizes (their walk mass), edges carry costs (inverse belief), and the system finds the connected structure that maximizes prize minus cost. The consequence worth italicizing: topology decides admission. A vertex with a great score that can't be cheaply connected to the rest of the answer is a near-miss, not an answer — exactly the discipline cosine retrieval lacks. The token budget applies only at the very end, admitting evidence in rank order until it's spent; there is no relevance-threshold knob to tune.

Step 5 — Answer with receipts. The subgraph and its supporting passages go to the language model for phrasing — the LLM narrates; it does not retrieve. Every claim carries an inline citation resolving to a real stored source: a bowl event, a vet note's passage, a book chunk. The full evidence chain rides along as structured output, ordered so the pet's own data leads and imported knowledge trails.

The part most retrieval posts skip: when the graph has nothing

Every retrieval system eventually gets a question its data can't answer. What happens next is a product decision, not a technical one — and it's where trust is won or lost.

Our rule: the assistant may still answer, but it must say what the answer is standing on. Every piece of context carries a class, and the class determines both the wording and the citation:

The first three carry citations. The fourth cannot — so it carries a label instead, and that label is mandatory, never quietly dropped.

Three rules fall out of this, and they're the ones we'd defend hardest:

• Classes mix visibly, never blended. An answer may combine "intake is down 12%" [bowl] with "chicken is a common retriever sensitivity" [reference] — but each claim keeps its own citation, and the connection between them is attributed to the assistant, not to a source. The system says "this may explain it," not "your vet records say this."
• Never guess a number. If someone asks about data we don't have, the answer says so — and, where relevant, which device would capture it. A fabricated gram count is worse than no answer.
• Health questions fail conservative. For symptom, medication, or toxicity questions with thin evidence, the answer gives careful general guidance, states plainly that it couldn't consult the pet's records, and points to a vet. No confident clinical claims from model priors, ever.
  
  

The results: what comes back

Here's the shape of the final answer (illustrative):

Max's scratching is up ~40% over his baseline this week [tracker, Jul 8–14]. The most connected explanation in his graph: his food changed on July 5 [bowl, Jul 5] to a formula containing chicken meal [product data], and poultry is a commonly reported sensitivity in retrievers [care guide, ch. 7]. His activity and appetite are otherwise normal [bowl; tracker, Jul 7–14]. Worth discussing an elimination diet with your vet — this is a pattern, not a diagnosis.

Every bracketed citation resolves to a real record a pet parent (or a vet) can open. That's not UI garnish; it's the retrieval architecture showing its work — the same evidence chain the ranker actually used. And note what the last sentence does: the causal link is offered as a pattern the assistant assembled, not as a claim any single source made.

Compared against our earlier similarity-based stack on multi-hop pet-wellness questions, the graph-walk architecture retrieves the connecting facts substantially more often and fabricates connections less. [METRIC PLACEHOLDER — needs approved figures before publishing: (a) multi-hop retrieval hit rate before/after, (b) citation precision, (c) share of answers carrying correct class labels. If none are cleared, cut this paragraph rather than soften it.]

Where this fits at Hoomanely

Hoomanely builds a connected wellness ecosystem for pets — a smart feeding bowl, a wearable tracker, and an AI companion that helps pet parents understand the family member who can't explain himself. Retrieval is where that promise is actually kept or broken. When our assistant connects a bowl reading to a vet note and suggests a conversation about an elimination diet, a real family may act on it. That's why the architecture refuses to guess, cites everything it can, and labels everything it can't. The goal was never a system that always has an answer — it's a system whose answers you can check.

Key takeaways

• Multi-hop questions are answered by assembling paths, not matching paragraphs — similarity can't join facts it never saw together.
• Retrieval runs on three signals only: graph traversal, one belief-weighted random-walk ranker, and provenance. Blended scores and rescue heuristics are banned by architecture, not by convention.
• Question understanding is deterministic — the graph's own ontology reads the question; the LLM only narrates at the end.
• Measurements and the graph meet in exactly two ways: numbers seed the walk, correlations become edges. Numbers never rank.
• Connectedness is a relevance test: a high-scoring fact that can't join the answer's subgraph doesn't belong in the answer.
• Every claim carries its evidence class — and when the honest class is "general knowledge," the answer says so out loud.

Next in the series → Part 5: Five Lessons from Building GraphRAG for Pet Devices — the post-mortems behind these design rules.