On multiple tokens, we put each option (however many tokens it is) onto a line, and then read the hidden state at the end of that line to use at the option state. This is done option-by-option.
The hidden state at the end of the question is the query `q` (again, not sensitive to how many tokens the question is), each options end-of-line state is the key `k`, and the per-option logit is calculated as `q.k / sqrt(256)`.
To vaguely confirm that this is plausible, i tested the sample query from the post with differently arranged options (This should produce slightly different outputs since each option influences all subsequent hidden states, including those of the other options):
"billing,sales,retail" produces billing -> 0.843, retail -> 0.092, sales -> 0.065
"retail,billing,sales" produces billing -> 0.470, retail -> 0.468, sales -> 0.062
"retail,sales,billing" produces billing -> 0.517, retail -> 0.415, sales -> 0.068
"billing,retail,sales" produces billing -> 0.803, retail -> 0.146, sales -> 0.051
"sales,retail,billing" produces billing -> 0.647, retail -> 0.127, sales -> 0.225
So each of these arrangements favor billing, but with pretty different confidence scores, and it looks like there is a pretty big bias toward the first option listed - which makes me wonder how viable it would be to have the torso process these options independently instead
Their docs say:
> An option's score depends on what it says, not where it sits. There is no per-option parameter anywhere in the model, so nothing can learn that "the first option is usually the right one"
This isn't quite correct. There might not be an explicit "per-option" parameter, but the hidden states themselves "contain" all prior options. My gut feeling tells me they messed up data augmentation by incorrectly permuting options during training.
Edit: the above numbers were obtained with the v19 version/checkpoint, v21 is much less sensitive to ordering, but still shows a first position bias.
[0] https://github.com/strands-labs/strands-decider/blob/main/do...