Hacker Newsnew | past | comments | ask | show | jobs | submit | danielmarkbruce's commentslogin

>> I think suggests to me a level of consistency in the contextual environment that would probably never exist

This is, basically, 100% of the thing. We will never get to the level of automation some folks think for this exact reason.


This is true, and it's strange that people don't think much about the fact that approximately zero % of people on planet earth are actually trying to cure diseases.

Making the edge cases work, and lowering the cost of running it via good model choice, context management etc is in some cases really hard. That's valuable in a decent number of cases. I have a system that does something in financial markets - making sure it doesn't screw up, and doesn't cost a fortune to run, is the entire thing for me.

While I don't believe they are doing the following: you can calibrate by inspecting the reasoning traces. That is the relevant distribution. If you ask someone to explain how/why they are classifying something one way v another, you can get a reasonably good understanding of their confidence level.

This tells me the confidence of the LLM's belief about the response - which is different from the calibrated confidence score. The former also is useful (just not what I thought their advertisement sells - and from the article it seems like it tripped up others as well), and there are different techniques to extract such a value [1] [2], typically via "response sampling", i.e., interrogate the LLM slightly differently to see if it changes its answer.

[1] Semantic Entropy https://www.nature.com/articles/s41586-024-07421-0

[2] Kernel Language Entropy https://openreview.net/pdf?id=j2wCrWmgMX


I mean the model can learn from it during RL training. The confidence score is affected by the tokens prior to it it's output. I was using the word "you" loosely.

For certain tasks, it seems much, much more efficient. That's not nothing. People have been using LLMs for various classification tasks.

In my company, and I think in most companies that are using AI at all, one of the first ways it got integrated is as a classifier, to tag orders based on feeding all their data into a prompt and asking for a structured output.

I think demand for tools that are more tailored for this type of integration is high. I don't really understand why Jev is supposed to get my company's decisions right more than an LLM, but regardless of the tech I think people are just excited about the possibility of iterating faster, more explainability, higher-level tools that are specifically created to help hone classifiers etc.


Great, we don't need 15 thousands posts per hour across social media channels. We had classification NN before LLMs as well.

I think the point of Jev is to thread the needle of the gap between non-LLM classifiers and LLMs.

Classifiers like classical NNs require:

- annotated data, potentially a lot of it - training - inference

#2 and #3 aren’t a big deal if you have an ML engineer, but #1 will always be a potential headache no matter who you are. The tradeoff is that they could be quite fast, cheap, and you can get probabilities, not just classes.

With LLMs you get:

- zero shot classification (no dataset or training required) - potentially can use third party model providers like OpenAI off the shelf. Don’t even need to host your own model.

The downside to LLMs is that they are comparatively slow and expensive to traditional classifiers. Historically they also were prone to hallucination or malformed responses, though not as much these days. You also can technically get log-probs back, but these aren’t equivalent to the classifier probabilities.

Jev gets you the zero-shot, zero-infra benefits of LLMs, while being closer to the speed and cost of traditional ML classifiers, as well as both classification and probability responses.


Yeah but they weren't that great, you couldn't ask for arbitrary classifications after the model was trained. You are underestimating what they've done here, even if it does seem a little overhyped.

No, you don't. You do RLCR, similar to that proposed here:

https://arxiv.org/pdf/2507.16806


yes, and... pretty much everything in the Ai field comes back to "data makes more difference"

Sure, and most days it doesn't rain.

depends on where you live, an important feature for data points about weather pattern probabilities

the underlying data set needs to be representative


RLVR and RLCR really don't need a whole bunch of special data.

the algorithms technically, sure, however the outcomes definitely depend on data quality and coverage like any other training method, this is well known

I don't think you've ever done either of these training steps. You are just handwaving.

you know what they say about making assumptions, yea?

and then you are going to ignore all the research and results that clearly show otherwise? why?

what might we infer about the importance of data from a learning algorithm like decision trees?


Read the paper. They train RLCR on existing big math problems. They subtract a brier score penalty from the correctness reward. No new confidence labels are needed.

Existing datasets, different reward function.


> Read the paper.

I did, in the first days Jev came out, when people were bringing it up. Another assumption. Please review the HN commenting guidelines, the one which starts with "Please don't comment on whether someone read an article." is relevant here.

Nothing in that paper changes that ML algorithms are dependent on the training data. We can step back from Jev and algos to consider Bayes Theorem. If your sample is not representative of the population, your resulting statistics will be off. The same is true here. If the data you train a model like Jev with is not representative, the probabilities and confidences it outputs will not be representative.

What makes Jev interesting is that it works well out of the box across domains. What people who are well known in the field believe is that this is the result of Typesafe having a really good training data set. People are saying similar of MiMo-2.6 today.



"Did you read the article" doesn't apply to a link someone put in a comment. If you are going to be a hall monitor, at least do it properly. You are just acting in bad faith at this point.

You are not engaging with actual points, instead attacking a person based on your bad assumptions and projections.

We both know who is

> just acting in bad faith at this point.


The relevant data is the reasoning trace. Doesn't need user data. You can learn from people's detailed reasoning steps how confident they are, even outside your domain.

Take RL 101. This is a common pattern.


We were talking about Jev and probability, now you're changing the problem, a rhetorical trick some people try to employ.

Another that uses dice rolling, coin flips, and an inventory level example to drive home the point that Jev's output are not real probabilities for outcomes.

https://news.ycombinator.com/item?id=49830385

> Take RL 101

I taught it (ML course; a day on RL, at a university), you should really stop making assumptions friend. Data quality and coverage matters in learning algorithms.

Here's one of the books used in that course https://amlbook.com/

Thinking blocks are not a place you can derive real confidence scores in LLMs


My initial comment and every one following is about RLCR and that paper. You don't appear to grasp the basics of that paper, it's reward function or how the optimizer is updating weights.

You are out of your depth and grasping at straws.


> You are out of your depth and grasping at straws.

Do you have any credentials or evidence that others can use to determine if this statement is not more accurately describing the author who wrote it?

Perhaps a PhD in ML, research output like published papers, or teaching/professional experience - all things I have

We could debate the merits of the paper contents, but I suspect you have intentionally moved on to personal attacks. Regardless, nothing you have said (nor can be found in this paper) has been a counter argument that learning algorithms are sensitive to training data, where the measured output difference is used by the optimization algorithm when updating the parameters. Garbage in, garbage out is a saying for a reason. No algorithm fixes non-representative data.


The claim of how they are doing it is likely wrong.... if you had to bet, it's likely an encoder model of some sort.

You are conflating post training quantization and low bit training.

That's what I meant - we are currently use fp4 formats for training, and we cannot quite get away with that, despite dynamic quant and small block size - we still have to use quite a bit of higher precision (fp8 or even fp16) in various model components.

I might still be misunderstanding what you are saying, but bitnet also keeps high precision latent weights during training. The optimizer updates those, while the weights used in the forward pass are quantized to ternary values.

Doesn't really even need to look like it. If you can verify rewards, RLVR will optimize really really well. If you can't... it's a struggle. There are probably fewer fields where you can verify rewards than one might hope.

> There are probably fewer fields where you can verify rewards than one might hope.

2 tasks I've done today that I believe robots are nowhere near being able to do: Cleaning my wardrobe and draining bad fuel out of my generator. As in generic use cases.


Hard to verify that your wardrobe is clean. Also hard to verify that the bad fuel is out without physical sensors. Many, many tasks are quite difficult to verify beyond "you know it when you see it". That doesn't work so well for training a model.

Humans wear a lot of hats when the do work. They don't even realize how many. My experience with building real systems using LLMs is that you have to be very explicit about such hats and you don't realize how many are worn until you see edge case after edge case after edge case. Check this. Check that. Check this. Check that. Check check check.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: