Distance of Thinking

←→

See all1 / 10

Summary

The piece turns an actual model mechanism into an interaction. The path a visitor flies picks the model's next token, and that path becomes the answer. The probabilities on screen aren't imitated – they are the logprobs a local model really produced.

6

next-token candidates at every step

the model's own probabilities; taking the top six is a design value

11

stages, from prompt to residual memory

Output

4 days

to the prototype

Measured – 22 commits

Personal work – concept, interaction design, visuals, frontend, server and hardware controller

Overview

Visitors pilot a ship through a tunnel of probabilities the model actually computed, and each word they pass is committed to the answer. A local model replaces a cloud API, so the piece runs in the gallery without internet.

Problem

The piece treats AI not as a thinking being but as a system that keeps calculating the probability of the next token. The condition was to use the values the model really computed rather than drawing probability as a metaphor.

Hallucination is modelled here as convergence on low probability. That is how the piece works, not a claim about why hallucination happens in real language models. What the piece shows stops at: keep choosing the unlikely branch and watch the sentence come apart.

Key decisions

1. 01No separate answer – the flight path is the answer

   What the piece shows had to be what actually happens. Only by intervening in sampling is the answer literally made by the visitor's choices.

   →Each token passed is committed, one by one, into a sentence. Flying hands-off follows the likeliest path. The concept and the build say the same thing.

2. 02Real probabilities, not imitated ones

   Cloud models don't expose real probabilities, so the piece couldn't claim to show the model's internal state.

   →Local Ollama logprobs supply the real candidates and probabilities. The 3D coordinates carry meaning and probability rather than decoration: a token's position comes from its embedding, its distance from dead ahead from its probability.

3. 03Pick the model by language

   EXAONE writes Korean well but looped on English prompts.

   →Korean prompts are answered by EXAONE 3.5, English ones by Llama 3.

4. 04Drop the shake input; tilt only steers

   If shaking the sensor broke the sentence, the cause would be the visitor's hand. In the piece's own terms the cause had to be low probability.

   →Instability builds only when flying into low-probability tokens. Removing one input kept the controls from contradicting the claim.

5. 05No colour – black and white only

   The moment warning colours appear, it looks like any 'AI UI'.

   →Meaning is carried by density, opacity, size and motion alone. The reference is Ryoji Ikeda's data-verse.

Process

How it works

1. Tokens – the visitor's sentence is split with the real Llama 3 tokenizer.
2. Meaning space – each token's 4,096-dimension embedding is projected into 3D, and tokens that land close are joined by lines.
3. Next-token candidates – the model is asked for one token at a time, returning its top six candidates and their probabilities. The likeliest sits straight ahead; less likely ones form the outer rings of a tunnel.
4. Steering – a tilt sensor (MPU6050) picks a branch and a rotary dial sets temperature, which widens the field on screen and is sent to the model itself.
5. The sentence coming apart – straying into unlikely branches raises an instability value and produces misspelled "ghost" words. That is a rule the piece sets, not an output of the model.

Built for the gallery

• Exhibition mode – operator UI hides, and after 75 seconds without input an attract loop takes over.
• Warm-up – a button preloads the models before visitors arrive; if generation fails, a local fallback keeps the visuals running.
• Network – Web Serial needs a secure page, so instead of a cloud deploy it runs on one HTTPS address on a private network.

Reflection

What held up

• It persuades only if what it shows is true. Choosing real values over imitated ones made the concept and the build say the same thing.
• Choosing a local model. It gives real probabilities and runs offline in the gallery. A cloud API would have lost both.
• Throwing one input away. Removing the shake kept the controls aligned with what the piece claims.

What failed

• I assumed one model could carry both languages. The model that writes Korean well looped on English, so the model is now picked by language.
• I assumed shaking the sensor was good interaction. It was fun, but it put the cause in the visitor's hand, which is the opposite of the point.
• I assumed a sensor-driven piece could be deployed to the cloud. Web Serial requires a secure context, so the whole setup moved to one HTTPS address on a private network.

What I would test next

• Whether visitors read "probability" at all. No visit data was collected in the gallery, so there's no measure of whether the piece communicates the idea.
• The physical sculpture wasn't made, and the Arduino controller was never tested on real hardware. Every flight so far used the mouse as a stand-in.
• Long-run stability – whether the local model and the serial link hold up over hours of continuous running is untested.