The main use case for LLMs is writing text nobody wanted to read. The other use case is summarizing text nobody wanted to read. Except they don’t do that either.

The Australian Securities and Investment Commission investigated LLM text summaries. ASIC’s answer to the Senate Select Committee on Adopting Artificial Intelligence was released yesterday. [Parliament, PDF; Crikey, archive]

Facebook’s Llama2-70B model summarized five submissions to a parliamentary inquiry, working to a list of criteria. ASIC staff were given the same task. The summaries were then reviewed — but the reviewers weren’t told that any of the summaries were AI-generated.

The humans beat the AI on every criterion for every submission:

• “It was wordy and pointless — just repeating what was in the submission.”
• “Included analysis which did not come from the document and does not serve the purpose.”
• “Made strange choices about what to highlight.”

The reviewers agreed that AI summaries were likely to make more work for bureaucrats, not less.

What  went wrong? LLMs don’t summarize text — they just shorten it. That’s a subtle difference, but it’s key.

Gerben Wierda evaluated a similar summary of a paper on Dutch pension fund guidance earlier this year. The LLM summarized the content — but it reversed the key point of the paper. [R&A]

Facts are not a data type in LLMs. They don’t understand anything at all. If you need the details right, they’ll get them wrong. But it’ll read smoothly!

David appears today on Paris Marx’s podcast Tech Won’t Save Us, talking about AI hype, cryptocurrency, social media — and the supposed topic of the show, Twitter co-founder Jack Dorsey and just what it is he believes and wants.

Paris and David first met at the Crypto Policy Symposium in London in September 2022 and discussed doing a podcast interview. Crypto fell out of public attention, but when David posted about Jack Dorsey and Bluesky, Paris realised there was a hook there.

The recording is just over an hour. This came out really nicely. [The Nation, audio]

24 April 2023 by Phillip Johnston

Many people are interested in becoming more effective, improving their quality of life, having a better recall of what they learn, performing at a higher level, producing fewer errors, etc. You can find countless podcasts, books, articles, and tweets on the topic. People want to adopt strategies or structure their day to maximize effectiveness.

But for some reason, the simplest fixes get overlooked.

• If you want to become better at everything you do, there’s one basic step you can take: prioritize your sleep. Sleep deprivation is bad on all counts. End of story.
• After that comes exercise – are you doing any? Do you just cycle through sitting at your desk, your car, a table, your couch?
• What about nutrition – are you giving your body high quality inputs on a sound schedule, or are you eating nutrient poor food and spiking your blood sugar repeatedly throughout the day?
• How about attention – do you create the conditions that allow you to focus on your work? Or are you constantly distracted by endless notifications, social media addiction, and the compulsion to check Slack and email every 5 minutes?

These are fundamentals of life. Unless you’re attending to these areas, they are probably the primary limiting factor in your effectiveness. Not some hidden knowledge you haven’t yet discovered. Not the perfect tool you haven’t found yet. Not a magical process that will ensure you never make mistakes. Not some advanced skill you haven’t unlocked.

The most common response when I point this out is “if only it was that easy.” IT IS THAT EASY!

Are there good reasons that some people don’t sleep enough (or exercise, or eat well, or or or)?

Yes, certainly. I’ve had to work many late nights, especially when I had a job that required talking to folks in China. I also have two kids that interrupt my sleep quite frequently. But it is willfully ignorant to act as if there are only good reasons we don’t get enough sleep. I often don’t get enough sleep due to my own choices: scrolling on my phone, playing chess, working on my computer too late on unimportant tasks, binge-reading a book, etc. In any case, whether the reason is good or not doesn’t matter one bit. Sleep deprivation affects you the same regardless of the justification.

“If only it were that easy” is also willfully ignorant of science and your own experiences as a human being. We have so much data on the negative impacts of insufficient sleep, skipping exercise, and eating poorly. But I don’t need studies. Basic observation works just as well. I can monitor my own state of being and see the impacts of being well-rested or not: I am meaner, more sensitive, and more distracted when I am tired. Not only do I know this about myself, but everyone around me knows it too. And the impacts of sleep, nutrition, and exercise are extremely obvious when you’re around children. Kids are much more pleasant and focused when they’re well-rested, and cranky and scattered when they are tired. When they’re eating well, they’re pleasant, and when they’re hungry or blood sugar crashes they are prone to tantrums. When they’re insufficiently exercised and full of energy, they’re unfocused and scattered and destructive and annoying.

Why do you think the same factors do not impact you, fellow human? Have you transcended your biology?

References

• Prioritize Your Sleep (Member’s Content)

The post The Simple Fixes on the Quest for Improved Performance appeared first on Embedded Artistry.

Hello! I’ve been working on writing a zine about debugging for a while (here’s an early draft of the table of contents).

As part of that I thought it might be fun to read some academic papers about debugging, and last week Greg Wilson sent me some papers about academic research into debugging.

One of those papers (Towards a framework for teaching debugging [paywalled]) had a categorization I really liked of the different kinds of knowledge/skills we need to debug effectively. It comes from another more general paper on troubleshooting: Learning to Troubleshoot: A New Theory-Based Design Architecture.

I thought the categorization was a very useful structure for thinking about how to get better at debugging, so I’ve reframed the five categories in the paper into actions you can take to get better at debugging.

Here they are:

1. learn the codebase

To debug some code, you need to understand the codebase you’re working with. This seems kind of obvious (of course you can’t debug code without understanding how it works!).

This kind of learning happens pretty naturally over time, and actually debugging is also one of the best ways to learn how a new codebase works – seeing how something breaks helps you learn a lot about how it works.

The paper calls this “System Knowledge”.

2. learn the system

The paper mentions that you need to understand the programming language, but I think there’s more to it than that – to fix bugs, often you need to learn a lot about the broader environment than just the language.

For example, if you’re a backend web developer, some “system” knowledge you might need includes:

• how HTTP caching works
• CORS
• how database transactions work

I find that I often have to be a bit more intentional about learning systemic things like this – I need to actually take the time to look them up and read about them.

The paper calls this “Domain Knowledge”.

3. learn your tools

There are lots of debugging tools out there, for example:

• debuggers (gdb etc)
• browser developer tools
• profilers
• strace / ltrace
• tcpdump / wireshark
• core dumps
• and even basic things like error messages (how do you read them properly)

I’ve written a lot about debugging tools on this blog, and definitely learning these tools has made a huge difference to me.

The paper calls this “Procedural Knowledge”.

4. learn strategies

This is the fuzziest category, we all have a lot of strategies and heuristics we pick up along the way for how to debug efficiently. For example:

• writing a unit test
• writing a tiny standalone program to reproduce the bug
• finding a working version of the code and seeing what changed
• printing out a million things
• adding extra logging
• taking a break
• explaining the bug to a friend and then figuring out what’s wrong halfway through
• looking through the github issues to see if anything matches

I’ve been thinking a lot about this category while writing the zine, but I want to keep this post short so I won’t say more about it here.

The paper calls this “Strategic Knowledge”.

5. get experience

The last category is “experience”. The paper has a really funny comment about this:

Their findings did not show a significant difference in the strategies employed by the novices and experts. Experts simply formed more correct hypotheses and were more efficient at finding the fault. The authors suspect that this result is due to the difference in the programming experience between novices and experts.

This really resonated with me – I’ve had SO MANY bugs that were really frustrating and difficult the first time I ran into them, and very straightforward the fifth or tenth or 20th time.

This also feels like one of the most straightforward categories of knowledge to acquire to me – all you need to do is investigate a million bugs, which is our whole life as programmers anyway :). It takes a long time but I feel like it happens pretty naturally.

The paper calls this “Experiential Knowledge”.

that’s all!

I’m going to keep this post short, I just really liked this categorization and wanted to share it.