HN user

bjterry

1,476 karma

bjterry at google's email service

Posts12
Comments399
View on HN

For all the people represented in the training data to receive royalties would be an incredible wealth transfer to the Extremely Online. My forum posts, StackOverflow answers etc are also contributing to the model outputs. The training data, by volume, mostly belongs to blog authors, redditors, Wikipedia editors, to us!

Having a relatively new LinkedIn account now is probably a very bad move if you don't have an established network to reach out to for jobs. There are tons of AI generated profiles flooding every job post (particularly remote) from scammers who create new LinkedIn profiles. It's one of the most frequent signs of a fake submission.

Founder Mode 2 years ago

A founding CTO is more effective than a hired CTO, because the founding CTO has more moral authority to create a consistent system. In other companies there's infighting between people (senior engineers, senior managers) with different architectural preferences (e.g. microservices vs monoliths, Java vs Python). These senior people get half what they want, meaning half your system works one way and half the other. A CTO can hold to their singular vision.

It could be that the moral authority stems from having as much of a full picture as a single person can have over the entire lifecycle of the company, but I think a lot is also just the effect of "I got you here."

I'm glad pg named this effect, since I've talked about the related phenomenon for CTOs with many people.

It would be interesting to allow users of models to customize inference by tweaking these features, sort of like a semantic equalizer for LLMs. My guess is that this wouldn't work as well as fine-tuning, since that would tweak all the features at once toward your use case, but the equalizer would require zero training data.

The prompt itself can trigger the features, so if you say "Try to weave in mentions of San Francisco" the San Francisco feature will be more activated in the response. But having a global equalizer could reduce drift as the conversation continued, perhaps?

It's interesting that Valve's policy requires disclosure of AI generated code:

Any kind of content (art/code/sound/etc) created with the help of AI tools during development.

But that none of the categories the author of this post identified included code, only visual, audio and text content.

Karpathy says:

The single number that should summarize your expectations about any LLM is the number of total flops that went into its training.

One thing I've been curious about is whether a model that's trained well beyond the Chinchilla level of compute will suffer more from quantization. All of that information has to live somewhere within the weights, so it stands to reason that you may have to keep more bits of information to keep that performance benefit.

If so, it would also mean that a smaller model that's been "overtrained," but which can't be quantized without suffering quality loss isn't necessarily cheaper for inference than a larger model which isn't overtrained, but which can be aggressively quantized. I haven't seen anyone discuss this, but maybe there's a paper on it.

If you could characterize what level of overtraining leads to quality loss at different levels of quantization, you could possibly figure out a more optimal model for overtraining. E.g. if you train with 10T tokens and you see quality loss at 4 bit, and you train with 20T tokens and see quality loss at 6 bit, you can fit a curve to those data points to estimate the maximum amount of tokens the model can train on with the current methodology.

I don't think this is true. My startup had a couple desks in the Palace of Fine Arts when they had an ill-fated attempt to convert part of it to a co-working space. They shut down co-working to turn it into a full-time event space. The building is basically one giant room, with a raised mezzanine floating above part of the floor. It has one small permanent theater on the north end, and they convert the southern end into a larger theater for music shows, and this is the seating chart being shown in the above link (I saw a Ninja Sex Party show there one time, but this theater isn't reflected on the tour photos. When I was working there in 2016 it was an exhibit for Hunger Games).

https://palaceoffinearts.com/tour/

I bought this book on Audible based on a random recommendation, not really knowing anything about it. On the page to buy it, it said it was released in 2020. I spent the first 80% of the book thinking that it was written in the 2010s, but intentionally written as if it were the 1980s. That is, with explanations that didn't presage the development of the Internet, and using analogies that would be understood by the people of that era. I was impressed with how perfectly the author was able to channel that era without anachronism, and even told a couple friends about this.

When I learned it was written in the 1980s, I wasn't exactly shocked. But then, I learned it was written by the Klein bottle guy, and that really was shocking. It's become one of my favorite books.

The cargo a plane can carry isn't limited only by the volume of the interior, but also by the amount of weight that can be carried safely in the plane. Airlines try to balance the amount of dense and non-dense (a.k.a. volumetric) cargo to solve for the joint constraint by charging different prices for cargo depending on the greater of its weight cost vs. its volume cost.

Even if it turned out to be practical to double the volume of cargo you could carry, it seems unlikely that it would allow you to double the weight of the cargo, since the engines and the airframe have all been designed around the same set of engineering requirements. The best case scenario would be a decrease in the cost of volumetric cargo, with dense cargo staying the same.

Donkey code 3 years ago

In WW2, British intelligence analysts inferred that a secret Nazi radar system used only a single beam based on its code name: Wotan (Odin), a god with one eye. For a long time, I have occasionally referenced this example, but today I learned that it was actually sheer luck. The prior radar system that used two beams was also codenamed Wotan.

https://en.wikipedia.org/wiki/Battle_of_the_Beams#Y-Ger%C3%A...

Best practices are not actually the best practice in many situations. Best practices by their nature are legible and acceptable in a broad variety of contexts. What are the chances that in your situation, the legible, broadly acceptable practice is actually going to be optimal?

The formalisms of systems thinking don't really work when you try to incorporate uncertainty. You have to frame things in terms of stocks and flows, but risk and uncertainty resolve in sudden leaps, not incrementally. If you assign 30% probability to "will have an incident" it doesn't smoothly climb from 30% to 100% over time, you roll the dice it jumps discontinuously to 100%. I'm not saying that attempting to quantify code quality and its impact is not useful, I'm saying the tools of systems thinking don't add anything to that exercise. Even if you gather data on the quality of your code, you still use expertise and intuition to judge those metrics, because they are always weak proxies.

To explain intuition, I do think it's successful to list the pros and cons and be explicit about which ones you think are low-medium-high likelihood and low-medium-high impact. Then people can disagree regarding your richer model.

A couple years ago I did a deep dive into systems thinking. Two people whose ideas I highly respect, John Cutler and Will Larsen, reference ideas from systems thinking, which is what piqued my interest. In the end, what I found is that it wasn't that useful for the problems I face as an engineering manager, and I am skeptical about whether it's formally useful except in a very casual way.

The key work in systems thinking is drawing causal loop diagrams to identify potential feedback loops, some of which tend to stability and some of which tend towards instability. The way you draw these has almost infinite degrees of freedom, and so while they can sometimes be helpful in eliciting your own ideas, the outcome is ultimately heavily grounded in your preconceptions of what's important and about the relevant scope of the exercise. In working with it, I never had a sudden realization that some neglected factor was the key to everything and would provide previously unexpected levels of leverage. I never identified a feedback loop which provided outsized control over the process that I couldn't identify and attempt to resolve with traditional tools. So, as an individual analytical tool, I don't think it added much to deep thought, an outliner and a notepad.

The case studies and the literature about the practice emphasize its importance as a tool for communication and collaboration. It seems to me that many of the practitioners are mostly trying to use it as a rhetorical tool to try to win arguments about which they've already decided their bottom-line opinion. But I think in the context of a business, it fails at this in lightweight terms (i.e. without a major top down organizational push) because the idea is so foreign to others. First you would have to teach them what a causal loop diagram is, which is itself a quite nuanced topic, then you'd have to convince them that your particular construction and emphasis is the one that's most relevant for a decision. The "success stories" here make a lot of money for the consultants that are able to go do training for 5 layers of management like this author, but no one ever adopts it and makes important decisions which they credit to the incredible causal loop diagrams they drew.

Two additional issues. Systems thinkers sometimes emphasize the importance of quantitatively modeling the feedback loops. For almost all the things I care about, that's impossible or admits to the same explosion of degrees of freedom as the loop structure. If you decide that code quality is a concern, or that a deteriorating dev experience could be impacting velocity, you could try to find metrics that capture those, but finding metrics that capture those AND act as inputs or outputs to further nodes of the causal loop is pretty much impossible. Qualitative aspects of a system are of critical importance, and you ignore them at your peril.

Second, systems thinkers are not very good at thinking about probability and risk. The causal models allow you to think about what happens assuming you know about the inflows and outflows of systems and processes, but they can't be readily combined with an understanding of your own limited knowledge, or risks that are ever present in every decision. Thinking about risks quantitatively, even in ballpark terms, I found way way way more useful to my decision-making than all the time I spent thinking about feedback loops. Knowing whether your confidence that an improvement will work is 30% or 70% is directly useful, even if its only your informal probability, assuming that you are reasonably well calibrated.

No one in this thread (nor in the article) has made the obvious observation that this means there are a massive variety of genuinely safe foods that could be made via currently banned practices. You can only get an exception at great cost for foods with existing cultural practice. Some real innovations, like the initial invention of the Peking duck, are basically prohibited.

It's possible that if you changed from translating the code to prose by hand and translating it with the tool, you would find that the "value" of that translation would be reduced. Basically, I think reading the code and mentally analyzing it enough to write to prose is doing most of the work, and when you read the prose, it's only a reminder for the deeper analysis you've done in your head.

The video from the article (https://www.youtube.com/watch?app=desktop&v=bydMm4cJDeU) is much better because it highlights the index of the outer loop, which is unclear from the cascading visualization there. By seeing the indexes it becomes clear that (1) in the area before the outer index, every value gets swapped in and out of the outer loop location to put them in order, and (2) at the end of the first outer loop iteration, the largest element will be at the location of the outer loop index, and so everything to the right is unchanged in each iteration.