Hacker News Reader

Comment by WhitneyLand | Hacker News Reader

His claim was that the title is misleading, not sure how it's relevant to that claim that you use "string models" (full LLMs).

The original title before it changed less than an hour ago was:

"Jev: New frontier model 40-400x cheaper and 20-200x faster"

I'm going to agree that was misleading.

And on the second point:

>>Also "can't hallucinate" seems wrong? Sure, it can't emit an invalid type, but it can still emit a completely wrong valid value.

>that is likely true of all ML! perhaps we could debate semantics, but I don't think it's fair to say a random forest "hallucinates" in the way LLMs do"

Also going to disagree here, and I don't think it's semantics.

Type safety is not factual correctness.

View on HN

> Type safety is not factual correctness.

I very much agree with this and want to hone in on where do actually disagree. Would you say a linear classifier hallucinates?

Hallucinations were defined in the context of text generation models so your question does not really make sense.

IMO your system can make mistakes that are similar in spirit to hallucination (i.e. answering with a false answer instead of abstaining to answer).

And furthermore, because the model is forced to answer in a boolean (if in boolean mode), if the user input is outside of the range of a boolean, it's forced to hallucinate. It can't abstain.

Let's say classifiers don't hallucinate. To make a fair comparison we should constrain LLMs to the same classification task. In that case, no, LLMs also don't hallucinate.

- Give Jev and LLM the same input

- Lock down both to approved/rejected/unknown (LLM restricts on decoding)

- Both can be wrong, but neither can hallucinate (invent an another option).

id say yes. a linear classifier that classifies between red and yellow balls will hallucinate on blue.

linear regressions hallucinate in the simpson's paradox.

the model output can be quite confident and not representative of reality

No. Your launch post puts “0%” on a hallucination chart, then explains that the number comes from guaranteed schema matching.

You’ve already agreed that this doesn’t establish correctness. An approve for an unauthorized action still meets the schema guarantee.

That’s why I find the messaging misleading. You’re acknowledging the limitations in these replies while defending the broader reliability pitch.

Even granting that each answer is calibrated individually, that doesn’t establish calibration of the decision that combines them.

Sure, I can threshold a composite score, but there may be many wrong answers with the same score. An unauthorized action doesn’t become acceptable because it scores highly on the other dimensions.

I still have to define the constraints and test which wrong actions get through the complete workflow on my own data. That’s a substantial part of the work being pushed back onto the developer.

hallucinations are not wrong answers, that's why we use a different term

User input: "Hey, have your human support agent call me, tomorrow at 5pm."

Model input: "Does the user want to speak to a human support agent?"

Output: Yes.

I imagine that your model would produce this, and I think it's fair to say this is a hallucination. A human would caveat it with: "Yes, but not right now.", your model is incapable of that. Yes is technically correct, but within the context of being in a live chat, a human would understand that the caveat is required.

To be fair - you’re crafting a deliberately bad model input for a contrived example.

No, the model has answered correctly. Your question is poorly phrased (possibly deliberately).

Your question would correctly classify the user's input as requesting a human support agent, but at an indeterminate time.

If you wanted to determine whether the user wants to speak to a human support agent immediately, you would have to correctly qualify your question, e.g. "Does the user want to speak to a human support agent now?". You could have another question which is "Is the user requesting a call-back from a human support agent?". Or you could have a multiple choice query which would filter the conversation into one of a number of pre-written possibilities.

This is nothing to do with accuracy or hallucination. It's a different method of interacting with the model where you are relied upon to be precise.

Add:

    "call_back_day": {
      "criteria": {
        "none": "The user does not want a call back.",
        "today": "The user wants a call back today.",
        "tomorrow": "The user wants a call back tomorrow."
      },
      "instructions": "When does the user want a call back?",
      "type": "choice"
    }

And you get: "tomorrow": confidence 1

A hallucination in the context of LLMs is generally understood as an incorrect answer presented as factual. If you claim that "x can't hallucinate" in the context of LLMs, you're saying that x always gives accurate answers. It does not matter whether the answer is type safe. If its value is incorrect, it's a hallucination.

> I very much agree with this

From the intro blog

"Hallucination and type-safety are intrinsically related"

I'm not entirely sure why we're conflating type safety with, I guess, value or output safety.

"Would you say a linear classifier hallucinates?"

No, but it can be (and often is) mathematically correct and functionally incorrect. It doesn't help to say "a linear classifier can't hallucinate" when you get even 99% accuracy. That's 100% a semantic play, and it doesn't help when the picture of a dog is labeled cat and the response is "yeah but that's not a hallucination, only stupid LLMs do that"

Reply on news.ycombinator.com