If an LLM can’t be trusted with a fast food order, I can’t imagine what it is reliable enough for. I really was expecting this was the easy use case for the things.

It sounds like most orders still worked, so I guess we’ll see if other chains come to the same conclusion.

  • hark@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 day ago

    I don’t know how you can think voice input is less versatile than text input, especially when a lot of voice input systems transform voice to text before processing. At least with text you get well-defined characters with a lot less variability.

      • hark@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        20 hours ago

        Special characters is just one case to cover. If the user says they want “an elephant-sized drink” what does that mean to your system? At least that is relevant to size. Now imagine complete nonsense input like the joke you responded to (“-1 beers” or “a lizard”). SQL injection isn’t the only risk with handling inputs. The person who ordered 18,000 waters didn’t do a SQL injection attack.

        • Communist@lemmy.frozeninferno.xyz
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          18 hours ago

          none of those issues work because there is a whitelist of specific terms instead of a blacklist

          -1 cannot be selected, a lizard isn’t on the list of inputs, and my point with the sql is that this isn’t a huge attack vector like an input field on a website, this is a dropdown list, essentially.

          i challenge you to come up with one relevant attack that isn’t order too much of a thing or order conflicting modifications (note of course the modifications are also essentially read from a dropdown list)

          everyone here seems to believe that the input field paradigm is not solveable when the inputs are fixed, that isn’t true.