Why Model Collapse In LLMs Is Inevitable With Self-Learning

There is a persistent belief in the ‘AI’ community that large language models (LLMs) have the ability to learn and self-improve by tweaking the weights in their vector space. Although there’s scant evidence that tweaking a probability vector space is anything like the learning process in biological brains, we nevertheless get sold the idea that artificial general intelligence (AGI) is just around the corner if we do just enough tweaking.

Instead of emerging super intelligence, the most likely outcome is what is called model collapse, with a recent paper by [Hector Zenil] going over the details on why self-training/learning in LLMs and similar systems is a fool’s errand. For those who just want the brief summary with all the memes, [Metin] wrote a blog post covering the basics.

In the end an LLM as well as a diffusion model (DM) is a statistical model of input data using which a statistically likely output can be generated (inferred) based on an input query. It follows intuitively that by using said output  to adjust the model with, the model will over time converge on a kind of statistical singularity rather than some ‘AI singularity’ event. This is also why these models need to be constantly trained with external, human-generated data in order to prevent such a collapse.

In the paper by [Hector] a mathematical model is created to demonstrate that an LLM, DM or similar statistical model undergoes degenerative dynamics whenever said external input is reduced. Although in the paper a mechanism is suggested to counter the entropy decay within the model, the ultimate point is that a statistical model cannot improve itself without continuous external anchoring.

The idea of LLMs being at all intelligent in any sense has been a contentious one, with the concept of language models being equated with ‘AI’ dating back to the 20th century, including as fun home computer projects. Much of the problem probably lies in humans projecting intelligent behavior onto these statistical models, turning LLMs into ‘counterfeit humans’, not helped by how closely generated text can resemble something written by a human, even if completely confabulated.

Thanks to [deshipu] for the tip.

How To Kill Humidity Sensors With Humidity

An often overlooked section in the datasheets for popular humidity sensors like the BME280 and DHT22 is the ‘non-condensing humidity’ bit, which puts an important constraint on which environments you can use this sensor in. This was the painful lesson that [Mellow Labs] recently had to learn when multiple of such sensors had kicked the bucket after being used in a nicely steamed-up bathroom. Fortunately, it introduced him to sensors that are rated for use in condensing humidity environments, such as the SHT40 that’s demonstrated in the video.

This particular sensor is made by Sensirion, and as we can see in the datasheet it features a built-in heater that allows it to keep working even in a condensing environment. This heater has three heating levels which are controlled via the I2C interface, though duration is limited to one second in order to prevent overheating the sensor.

Of note is that you cannot take measurements while the heater is operating, and its use obviously increases power draw significantly. This then mostly leaves when to turn on the heater as an exercise to the engineer, with [Mellow Labs] opting to start the heater when relative humidity hit 70% as a conservative choice.

In the comments to the video other options for suitable sensors were pitched, including the Bosch BME690 which is similarly rated for condensing environments. All of which condenses down to the importance of reading the datasheet for any part that you intend to use in possibly demanding environments.

Continue reading “How To Kill Humidity Sensors With Humidity”

Using A VT-100 Today

You may not know what a ADM-3, a TV910, or a H1420 are, but you probably have at least heard of a VT-100. They are all terminals from around the same time, but the DEC VT-100 is the terminal that practically everything today at least somewhat emulates. Even though a real VT-100 is rare, since it defined what have become ANSI escape sequences, most computers you’ve used in the last few decades speak some variation of the VT-100’s language. [Nikhil] wanted to see if you could use a VT-100 for real work today.

While the VT-100 wasn’t a general-purpose computer, it did have an 8080 inside. It only had about 3K of RAM, which was enough to act as a serial terminal. A USB serial port and a terminal with modern Linux, how hard could it be?

Continue reading “Using A VT-100 Today”

FLOSS Weekly Episode 869: Linux On Your Toaster

This week Jonathan chats with Andrei, Mahir, and Praneeth, live on location at Texas Instruments! The team at TI has been working hard to provide really good Open Source support for Sitara processors, including upstreaming support to the mainline Linux kernel. We talk about the CI pipeline for these devices, the challenges of doing Open Source at a big company, and more. Check it out!

Continue reading “FLOSS Weekly Episode 869: Linux On Your Toaster”

Bicycle Tubes Aren’t Just Made Of Rubber Anymore

For the average rider, inner tubes have been one of the most enduring and unchanging parts of bicycle design over the decades. They’re made of rubber, they have a Schrader or Presta valve, and they generally do an okay job at cushioning the ride.

However, if you’re an above-average rider, or just obsessive about your gear, you might consider butyl rubber tubes rather old hat. Today, there are far fancier—and more expensive—options on the market if you’re looking to squeeze every drip of performance out of your bike.

Continue reading “Bicycle Tubes Aren’t Just Made Of Rubber Anymore”

Digital Signal Processing On The Pi Pico

If you want to dabble in audio digital signal processing, you would probably think of grabbing a dedicated DSP chip. But thanks to [WeebLabs], you could just pick up a Pi Pico and use this full-featured DSP library.

The system supports plug-and-play USB audio interface that enumerates on Windows, Linux, macOS, and iOS. It can handle 16- or 24-bit inputs at up to 96 kHz. You can output up to four channels of 24-bit S/PDIF or I2S, or switch to an RP2350 to get eight channels. This lets you drive a DAC easily. There is also a direct output for a subwoofer that doesn’t require a DAC.

Each channel has a pre-amp, and a matrix mixer allows routing with different gains and phases for each input. An equalizer allows ten bands per channel. There are also modules to do volume leveling, loudness compensation, and headphone cross-feed.

The library uses both cores of the CPU and manages up to ten preset configurations. The Pico does get an overclock and uses a fixed-point representation. The Pico 2 (RP2350) doesn’t need overclocking and uses single-precision floating point.

Overall, this looks like a great base for any sort of soundcard-like project. We’ve seen DSP stunts on the Pico before. This might also make a nice base for other audio projects.

Ask Hackaday: Do You Need A Tablet?

There’s an old saying that the happiest days of a boat owner’s life are the day they buy the boat, and the day they sell it. For me, the happiest days of an Android tablet owner’s life are the day they buy a new one, and the day they buy a newer one. For some reason, I always buy tablets with great expectations, get them set up, and then promptly lose them in a pile on my desk, not to be seen again. Then a shiny new tablet gets my attention in a year or so, and the cycle repeats.

You might be thinking that I just buy cheap junk tablets. It is true that I have. But I have also bought new Galaxy and Asus tablets with the same result. Admittedly, I have owned several Surface Laptops and Pros, and I do use them. But I can’t remember the last time I have used one without the keyboard. They aren’t really tablets — they are just laptops that can also be heavy, awkward tablets.

Continue reading “Ask Hackaday: Do You Need A Tablet?”