• 3 Posts
  • 31 Comments
Joined 1 year ago
cake
Cake day: August 2nd, 2023

help-circle



  • IMO copying communities from Reddit as-is was a mistake long-term, but was maybe necessary short-term so that people wouldn’t be confused. If I had my druthers, I’d make a new system where communities are uniquely identified purely as !UUID@lemmy.instance (though still with a human-friendly display name). You don’t get to create a community that namesquats something like !gaming@lemmy.world. All posts would be made with hashtags like Mastodon, and then each community would just configure “Include all posts with this tag in our community”. The big issue then is who moderates tags? I think a system like Bluesky has would work well, as you mention. People can moderate tags and other people can follow their work, or not.

    If that was combined with seamless account/community migration, that would solve a lot of moderation issues. If you mod a community and the admins suck, just move it to a new instance. If the mods of a particular community suck, start your own. They won’t be able to monopolize a common name, so it’s much easier to get traction.

    On the long-ago internet, there were many, many different software options that supported the same protocols, and they were also a lot more configurable generally speaking

    Lemmy is pretty good about that, actually. It’s interoperable with Mastodon via ActivityPub, and there’s other projects like MBin that work nicely with Lemmy.









  • It would be nice if there was a way to handle instance/user migrations. If an instance gets their domain name taken away, there’s no way AFAIK for the admin to say “Here’s our new location, with a verifiable signature”. Likewise there’s no way for a user AFAIK to move their account with a verifiable signature that the new one is still them. Ideally this could all happen automatically with signatures getting synced automatically and all that.

    I’m sure it would be a lot of work and no idea if ActivityPub would get in the way, but it would give people a lot more assurance that they didn’t pick a server that will screw them over by going down.


  • The whole “it’s just autocomplete” is just a comforting mantra. A sufficiently advanced autocomplete is indistinguishable from intelligence. LLMs provably have a world model, just like humans do. They build that model by experiencing the universe via the medium of human-generated text, which is much more limited than human sensory input, but has allowed for some very surprising behavior already.

    We’re not seeing diminishing returns yet, and in fact we’re going to see some interesting stuff happen as we start hooking up sensors and cameras as direct input, instead of these models building their world model indirectly through purely text. Let’s see what happens in 5 years or so before saying that there’s any diminishing returns.


  • Gary Marcus should be disregarded because he’s emotionally invested in The Bitter Lesson being wrong. He really wants LLMs to not be as good as they already are. He’ll find some interesting research about “here’s a limitation that we found” and turn that into “LLMS BTFO IT’S SO OVER”.

    The research is interesting for helping improve LLMs, but that’s the extent of it. I would not be worried about the limitations the paper found for a number of reasons:

    • There doesn’t seem to be any reason to believe that there’s a ceiling on scaling up
    • LLM’s reasoning abilities improve with scale (notice that the example they use for kiwis they included the answers from o1-mini and llama3-8B, which are much smaller models with much more limited capabilities. GPT-4o got the problem correct when I tested it, without any special prompting techniques or anything)
    • Techniques such as RAG and Chain of Thought help immensely on many problems
    • Basic prompting techniques help, like “Make sure you evaluate the question to ignore extraneous information, and make sure it’s not a trick question”
    • LLMs are smart enough to use tools. They can go “Hey, this looks like a math problem, I’ll use a calculator”, just like a human would
    • There’s a lot of research happening very quickly here. For example, LLMs improve at math when you use a different tokenization method, because it changes how the model “sees” the problem

    Until we hit a wall and really can’t find a way around it for several years, this sort of research falls into the “huh, interesting” territory for anybody that isn’t a researcher.








  • The collect’s in the middle aren’t necessary, neither is splitting by ": ". Here’s a simpler version

    fn main() {
        let text = "seeds: 79 14 55 13\nwhatever";
        let seeds: Vec<_> = text
            .lines()
            .next()
            .unwrap()
            .split_whitespace()
            .skip(1)
            .map(|x| x.parse::<u32>().unwrap())
            .collect();
        println!("seeds: {:?}", seeds);
    }
    

    It is simpler to bang out a [int(num) for num in text.splitlines()[0].split(' ')[1:]] in Python, but that just shows the happy path with no error handling, and does a bunch of allocations that the Rust version doesn’t. You can also get slightly fancier in the Rust version by collecting into a Result for more succinct error handling if you’d like.

    EDIT: Here’s also a version using anyhow for error handling, and the aforementioned Result collecting:

    use anyhow::{anyhow, Result};
    
    fn main() -> Result<()> {
        let text = "seeds: 79 14 55 13\nwhatever";
        let seeds: Vec<u32> = text
            .lines()
            .next()
            .ok_or(anyhow!("No first line!"))?
            .split_whitespace()
            .skip(1)
            .map(str::parse)
            .collect::<Result<_, _>>()?;
        println!("seeds: {:?}", seeds);
        Ok(())
    }