HackerTrans
TopNewTrendsCommentsPastAskShowJobs

xml

no profile record

comments

xml
·قبل 4 أشهر·discuss
I'd like to add a few failure modes:

- LLM removes/disables/weakens tests (disallowing manipulation of tests is not really possible in Python since the language is too dynamic, so the entire execution has to be sandboxed, which makes timing more difficult)

- LLM mutates input, which might throw off some tests (for example, sorting an array where all values have been set to zero is easy), but this can easily be solved by copying the input to somewhere safe or regenerating it from a fixed random seed.

- LLM writes code that only passes the test cases and nothing else, often with a new special case inserted after every failed test. Randomizing everything seems to be a good defense, although it is not always easy to know beforehand what to randomize. Tensor shapes are obvious, but randomizing data distribution to prevent circumvention via precision downgrades is difficult.

And regarding "10. Baseline Kernel" from the article; I've had LLMs call __import__ or compile and obfuscate the code in order to circumvent tests. The proposed defense of static analysis is not quite sufficient here.

I can relate to all points mentioned in the article. They really do happen in practice, and many are also applicable to test-driven development with LLMs. Is there any benchmark to evaluate whether an agent solves a task "in the spirit of the prompt" instead of simply solving it to pass tests?
xml
·قبل 5 أشهر·discuss
> But on a tangent, why do you believe in mixture of experts?

The fact that all big SoTA models use MoE is certainly a strong reason. They are more difficult to train, but the efficiency gains seem to be worth it.

> Every thing I know about them makes me believe they're a dead-end architecturally.

Something better will come around eventually, but I do not think that we need much change in architecture to achieve consumer-grade AI. Someone just has to come up with the right loss function for training, then one of the major research labs has to train a large model with it and we are set.

I just checked Google Scholar for a paper with a title like "Temporally Persistent Mixture of Experts" and could not find it yet, but the idea seems straightforward, so it will probably show up soon.
xml
·قبل 5 أشهر·discuss
Even with inflated RAM prices, you can buy a Strix Halo Mini PC with 128GB unified memory right now for less than 2k. It will run gpt-oss-120b (59 GB) at an acceptable 45+ tokens per second: https://github.com/lhl/strix-halo-testing?tab=readme-ov-file...

I also believe that it should eventually be possible to train a model with somewhat persistent mixture of experts, so you only have to load different experts every few tokens. This will enable streaming experts from NVMe SSDs, so you can run state of the art models at interactive speeds with very little VRAM as long as they fit on your disk.
xml
·قبل 5 أشهر·discuss
Looks like the pop-ups that cover 70 % of my netbook's screen are still there: https://i.imgur.com/uPbVW2o.png

I wonder if getting rid of those pop-ups would have slowed Stack Overflow's decline. The number of new posts has dropped by 98 % (198540 posts in 2020 down to 3097 in January: https://data.stackexchange.com/stackoverflow/query/1926661#g...)
xml
·قبل 5 أشهر·discuss
To put it into your metaphor: I am not advocating against the existence of bandsaws. I would just rather have bandsaws that do not cut off your fingers if you do not read a book about them first and make it difficult to sew the fingers back on, while requiring arcane incantations to do their work.

There are of course power tools with obnoxious protections that make them difficult to use, but since we are dealing with software here, we are not bound by the laws of physics. I believe that we can create a better tool that is both powerful and easy to use.
xml
·قبل 5 أشهر·discuss
If most people are not using a tool properly, it is not their fault; it is the tool's fault.

Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good.

- The interface is unintuitive.

- Jargon is everywhere.

- Feature discoverability is bad.

- Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it.

Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design.

I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.
xml
·قبل 5 أشهر·discuss


    > this code is not copyright protected, therefore you are not allowed to apply a MIT LICENSE to this project.
Why not? You still can (and probably should) disclaim warranty and whether the code is copyright protected may vary by jurisdiction.

(Not sure if claiming copyright without having it has any legal consequences though.)
xml
·قبل 5 أشهر·discuss


    > Specifically, we collected new data created after January 2025, including: [...] new fiction on Archive of Our Own (Various, 2025),
Not sure how to feel about this. From a researcher's point of view, reproducibility is important, but the last time someone publicly collected data from AO3, the community was not very fond of that.

https://huggingface.co/datasets/nyuuzyou/archiveofourown/dis...
xml
·قبل 5 أشهر·discuss
You can still be excited! Recently, GLM-OCR was released, which is a relatively small OCR model (2.5 GB unquantized) that can run on CPU with good quality. I've been using it to digitize various hand-written notes and all my shopping receipts this week.

https://github.com/zai-org/GLM-OCR

(Shameless plug: I also maintain a simplified version of GLM-OCR without dependency on the transformers library, which makes it much easier to install: https://github.com/99991/Simple-GLM-OCR/)
xml
·قبل 6 أشهر·discuss
Were there any particular challenges when implementing your library? I have implemented my own serialization library [1] (with a focus on not allowing arbitrary code execution), but had skipped dataclasses for now, since they seemed difficult to get right. What was your experience?

[1] https://github.com/99991/safeserialize

Side note: I think that a warning in the README about arbitrary code execution for deserialization of untrusted inputs would be nice.