[llama.cpp] Build Question

Asking a language model a question and asking it to choose from a list are quietly different jobs. The first one produces prose you have to parse; the second produces a probability distribution over options you defined, which is something a graph can act on.

[llama.cpp] Build Question is the node that defines those options. It takes your question text, a flat list of possible answers, and a type - choice or score - and packs them into the typed question object that the pack's System One nodes understand.

What it actually does

Pure payload building; no inference happens here. Three inputs:

• question - multiline STRING, the instructions the model sees. Empty by default, and an empty value is rejected.
• answer - the option list, wired in as a single flat ComfyUI STRING list. The author's tooltip is the spec: "Choice requires 2–26 unique options; score requires 2–10 unique levels in lowest-to-highest order."
• type - a COMBO, defaulting to choice.

The output is one question socket of custom type OLLAMA_IMAGE_LIST_LLAMA_CPP_QUESTION - {type, question, answer} - for [llama.cpp] System One Decide or one of the sequential variants.

The difference between the two types isn't cosmetic. With choice, the server is given your options as named criteria and returns a probability per option; the selected output downstream is the label itself. With score, the criteria keep their supplied order and are treated as an ordered scale, and the value you get back is the model's expected 0-based level index - so a four-level morning/evening/afternoon/night list does not come back as "afternoon", it comes back as something like 1.7 sitting between two levels. That's a real feature when you want to threshold or smooth a rating, and a real surprise if you expected a label.

Building the answer list

answer is a wire, not a widget - you're expected to feed it a list. In the author's own System One workflow that's a CreateList fed by PrimitiveString nodes:

PrimitiveString("morning") ─┐
PrimitiveString("evening") ─┤
PrimitiveString("afternoon")─┼─ CreateList ─ answer ─┐
PrimitiveString("night") ───┘                        │
PrimitiveString question text ─────────────────── question ─ Build Question ─ question → Decide

If you're comfortable with primitives, that's the whole pattern, and it's the one thing about this node worth practising before you build a graph around it.

Installing it

Part of the same pack as everything else here:

cd ComfyUI/custom_nodes
git clone https://github.com/craftingmod/ComfyUI-llama-multimodal.git

Restart ComfyUI, or install ComfyUI-llama-multimodal from ComfyUI Manager by searching llama multimodal. It requires ComfyUI 0.19.3+, your GGUF plus matching mmproj in ComfyUI/models/LLM, and - for the decision nodes - the pack's optional llama dependency (makoto-decision, listed in requirements.txt). Manager installs it for you; a bare git clone may not.

Where it goes wrong

The list has to be flat. Nested lists get rejected outright, and so do duplicate or blank entries. Two identical strings are not "two options", they're an error - the pack checks uniqueness before any request is sent. Do that debugging on the canvas, not in the server log.

Score order is load-bearing. Levels are scored lowest-to-highest in the order you supplied them. Swap two primitives and your expected index silently inverts; nothing errors, you just get backwards numbers. If a score decision looks wrong, check the wire order first.

Choice caps at 26 options, score at 10 levels, and both limits are checked before the request leaves the node - a 27-item list just fails. If you genuinely need more granularity than a score scale gives you, you probably want a different question shape rather than a longer list.

A Native Session will refuse this question. System One only runs on Runtime or Connect Sessions; the prefill path (Build Question (Prefill), Prefill Decide) is the one that accepts Native sessions and scores A–Z letter tokens, and the pack's own examples note it "might be ineffective on systemone models". Pick the path that matches your model, not the one you wired first.

Garbage in, confident-looking distribution out. The model was never told your options mean what you think they mean. Vague labels like "good" and "fine" produce crisp probabilities that don't correspond to anything useful - same as asking a human for a rating out of ten with no rubric.