kremi

A podcast posted here recently had this number: 80% of ant revenue comes from just 8 customers. The consensus of the speakers was that if true, this would be indicative of a very vulnerable revenue structure. But this was based on leaks. Maybe we can have the real numbers now?

« Connaître est reconnaître »

I don’t think essentialist explanations about how LLMs work are very helpful. It doesn’t give any meaningful explanation of the high level nature of the pattern matching that LLMs are capable of. And it draws a dichotomic line between basic pattern matching and knowledge and reasoning, when it is much more complex than that.

> The model can be prompted to talk about competitive dynamics. It can produce text that sounds like adversarial reasoning. But the underlying knowledge is not in the training data. It’s in outcomes that were never written down.

With all the social science research and strategy books that LLMs have read, they actually know a LOT about outcomes and dynamics in adversarial situations.

The author does have a point though that LLMs can’t learn these from their human-in-the-loop reinforcement (which is too controlled or simplified to be meaningful).

Also, I suspect the _word_ models of LLMs are not inherently the problem, they are just inefficient representations of world models.

Interesting, I didn't expect that. I guess stock markets have a good reason to worry about video game studios then. Now, makes me wonder if movie companies stocks were similarly affected when major video models were announced.

To understand whether AI world models could replace traditional video games, it might be useful to compare this to how LLMs have affected old-school role-playing games. LLMs are more mature and have been around longer than AI world models so we should've seen the shift there first.

I don’t personally know anyone who role-plays, so candid question: have LLMs changed the way people play tabletop RPGs?

Yes, the term "middleware" is unfortunate, this is abundantly clear.

> you wouldn't get a new tool simply because you might need it

No but you get a framework precisely because it's "batteries included": many apps will need those tools. You don’t have to use all of them, but having them available reduces friction when you do.

> If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in

It already is. Nothing runs at the edge unless you add a middleware.ts. You can build a full app without any middleware. I'm surprised the author of the article fails to acknowledge this, given how much time was spent on finding alternative solutions and writing the article.

To people who downvote my comment (and there are many): please elaborate.

I like to learn and improve. A lot of comments here are just baseless negative comments. Please let’s have a real discussion.

I think “middleware” is a bit of a misnomer in Next.js. It’s really an edge function that runs before your request hits the app -- quick header checks, routing, and other lightweight guards. It runs on the edge runtime, not on the app server.

The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs.

I struggled with Next.js at first for the same reason: you have to know what runs where (edge, server, client). Because it’s all JavaScript, the boundaries can blur. So having a clear mental model matters. But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.

It’d be hard to draw any conclusion. A whistleblower must be under extreme stress and pressure which in itself in some way or other will increase the risk of death — so that has to be taken account before saying the plausible cause for the excess deaths is assassination.

This is anecdotal but

- A company I worked for wanted to be 100% focused on doing one thing. It was spending 10x more than it was making revenue. It went bankrupt.

- Another company I worked for always insisted on not having all eggs in one basket. There was one big revenue maker that dwarfed the others though. The company is still around and doing well.

I have quite a scattered brain too so I get the appeal of "choosing to focus". But looking others do it I see the risks : refusing to experiment and learn new stuff, or find new opportunities.

EDIT: I'd like to add that focusing or not focusing is not a useful dichotomy, it's more about finding the right "exploration vs exploitation" balance.

Some of the replies here are pretty good, I basically agree with “if it works for your data scientists then why not”.

I’m actually a software developer with 10 years experience and also happen to do data science. And found myself in situations where I parametrized a notebook to run in production. So it’s not that I can’t turn it to plain python. The main reasons are

1. I prototype in a notebook. Translating to python code requires extra work. In this case there’s no extra dev involved, it’s just me. Still it’s extra work.

2. You can isolate the code out of the notebook and in theory you’ve just turned your notebook into plain py. You could even log every cell output to your standard logging system. But you loose context of every log. Some cells might output graphs. The notebook just gives you a fast and complete picture that might be tedious to put together otherwise.

3. The saved notebook also acts as versioning. In DS work you could end up with lots of parameters or small variations of the same thing. In the end what has little variations I put in plain python code. What’s more experimental and subject to change I put in the notebook. In certain cases it’s easier than going through commit logs.

4. I’ve never done this but a notebook is just json so in theory you could further process the output with prestodb or similar.

I guess it won’t take very long before you can do PPC (or similar paid advertising) in LLM results. Google had to turn to paid advertising for profitability. OpenAI and the likes might have to do the same — competition is fierce and price are dropping so not sure users will continue to accept paying a subscription.

Sorry I don't know what to answer. I don't think what I do qualifies as "workload".

I have a process that generates lots of data. I put it in a huge multi-indexed dataframe that luckily fits in RAM. I then slice out the part I need and pass it on to some computation (at which point the data usually becomes a numpy array or a torch tensor). Core-count is not really a concern as there's not much going on other than slicing in memory.

The main gain I get of this approach is prototyping velocity and flexibility. Certainly sub-optimal in terms of performance.

> Take a look at the indexing code in pandas

As the end-user, not quite my concern.

> and the staggering complexity of what's possible to put inside square brackets and how to decipher its meaning

I might not be aware of everything that's possible -- the usage I have of it doesn't give me an impression of staggering complexity. In fact I've found the functionality quite basic, and have been using pd.MultiIndex.from_* quite extensively for anything slightly more advanced than selecting a bunch of values at some level of the index.