Building a Rabbit Hole

An unfamiliar word can hijack a conversation with an AI. You ask about it, the answer introduces another unfamiliar word, and a few follow-ups later you're scrolling back to remember what you were trying to understand.

I built Rabbit Hole to try a different interaction. Click a term in an answer and an explanation opens beside it. The original answer stays in place. The new explanation can have links of its own, so you can follow a question as far as you need to, then return to where you left off.

In this prototype, a question about future science leads to quantum computing. That panel introduces qubits, superposition, and entanglement. Each is a possible detour; none has to take over the original conversation.

The panel layout was inspired by Andy Matuschak's working notes. Following a link there opens another note alongside the one you're reading. I wanted to try that with explanations generated when you ask for them.

A question you can click#

A link saves you from having to compose a follow-up. You can recognise that “superposition” needs explaining before you know enough to ask a useful question about it.

The implementation was small. I asked the model to mark potentially unfamiliar terms in its response, linking each term only on its first appearance. A Markdown parser turned those markers into interactive text. Clicking one opened a panel and made another request. The model suggested the terms; the application handled the panels.

The click also needed to carry context. In the prototype, the request asked for a brief explanation of the term in the context of the original question. That matters for a request like “explain it to an eight-year-old.” A branch about quantum computing should carry that instruction with it. Passing the term alone would throw away part of the question.

As a branch gets deeper, the original question may no longer be enough. Someone who has just read an explanation of qubits shouldn't have to start there again when they click “superposition.” The screen can show a continuous trail even when the next model request is missing a step. A branch needs the relevant context from its parent, including what the reader is pointing at.

Choosing the links shapes the conversation#

Marking a word as clickable gives it extra weight. It tells the reader that this is something worth following. A model generating those links is making an editorial choice about the answer.

The prototype's instruction to link unfamiliar terms made sense as a starting point. It also favours vocabulary. In a technical explanation, the noun may be less interesting than the claim surrounding it. A reader might understand every word in “this design tolerates a regional outage” and still need to ask how, under which conditions, and what happens to writes during the outage.

Selecting any text and opening a branch gives the reader that choice. The model's suggestions shouldn't be the only questions the interface makes easy to ask. Selecting a whole sentence lets the reader choose the part that deserves attention.

Linking every possible detour would make the answer harder to read. A few useful links leave room for the explanation itself. The selection interaction covers what the model leaves out.

Following an answer's dependencies#

A branch asking “why?” could help us examine what an answer depends on. The model might name an assumption, point to evidence, or introduce an intermediate claim. Each gives the reader something more specific to question. Keeping those branches attached to the original answer would make the investigation easier to follow.

Take the regional-outage claim. A “why” branch might point to replication. Following that explanation could uncover an assumption that a copy exists in another region. We could then open a separate branch with that assumption removed and ask the original question again. Does the model change its conclusion? Does it recognise that the condition it cited no longer holds?

That would give us a trace we could inspect: the original claim, its stated support, and how the answer responds when that support changes. It could expose a missing condition or a contradiction that was hard to see in the first response. Asking “why” starts the investigation; testing the explanation gives us more to work with.

Mechanistic interpretability helps explain why that testing matters. In Anthropic's circuit-tracing work on Claude 3.5 Haiku, the model described using ordinary carrying to add two numbers. The researchers instead found parallel computational paths for an approximate answer and the final digit. Its account of the calculation didn't match the mechanism they observed. A model's explanation gives us a hypothesis about how it reached an answer, which we can investigate further.

Rabbit Hole could support that investigation even while the internal computation remains hidden. Changing an assumption and comparing responses lets us examine the model's behaviour, though it doesn't establish which internal mechanism produced either answer. The interface would need to keep the changes between branches visible and distinguish generated explanations from retrieved evidence. A reader could then trace which parts of an answer had been challenged, what held up, and what needed revising.

Finding your way back#

Side-by-side panels help with a short detour. Keep opening them and screen space becomes the constraint. A narrow screen reaches that point almost immediately. Following a branch has to include a way to close it and recover your place in the parent answer.

I'd test this next with a claim someone needs to check. I'd watch whether following its branches helps them find a missing assumption, test it, and return to the original answer knowing what needs to change.