mumblemumble

Joined 7 years ago

Karma
17,246
Submissions
3,398
Member since
Aug 12
View on Hacker News

Recent submissions

Comment · 2 years ago
Perhaps only if you can also be very certain that the output is correct whenever the logprobs don't trigger the filter.

If that's not the case then it might just trigger bad risk compensation behavior in the model's human operators.

Comment · 2 years ago
I'm not an expert, either, but I've poked at this a little. From what I've seen, token logprobs are correlated enough with correctness of the answer to serve as a useful signal at scale, but it's a weak enough correlation that it probably isn't great for evaluating any single output.

My best guess is that somewhere close to the root of the problem is that language models still don't really distinguish syntagmatic and paradigmatic relationships. The examples in this article are a little bit forced in that respect because the alternatives it shows in the illustrations are all paradigmatic alternatives but roughly equivalent from a syntax perspective.

This might relate to why, within a given GPT model generation, the earlier versions with more parameters tend to be more prone to hallucination than the newer, smaller, more distilled ones. At least for the old non-context-aware language models (the last time I really spent any serious time digging deep into language models), it was definitely the case that models with more parameters would tend to latch onto syntagmatic information so firmly that it could kind of "overwhelm" the fidelity of representation of semantics. Kind of like a special case of overfitting just for language models.

Comment · 2 years ago
I'm not sure it's easy to understand what a big change there has been in the perceived pace of computer technology development if you weren't there. I'm typing this on a laptop that I purchased 11 years ago, in 2013. It's still my one and only home computer, and it hasn't given me any trouble.

In 1994, though, an 11 year old computer would already be considered vintage. In 1983 the hot new computer was the Commodore 64. In 1994 everyone was upgrading their computers with CD-ROM drives so they could play Myst.

Comment · 2 years ago
Dark matter is not a theory, per se. There are many, many theories that attempt to explain dark matter. Some of them have yet to produce testable hypotheses, others have already been tested.
Comment · 2 years ago
Testable hypotheses are at the core of the scientific method, yes. But that's not just limited to the actual testing of hypotheses. All the work that goes into formulating hypotheses is also explicitly part of the scientific method.

Worth noting, too, that the paper outlines several possible experiments. It also specifically mentions some relative shortcomings of the model, and lists existing observations that they haven't tried to reconcile with it yet.

Comment · 2 years ago
I think that similar arguments were made about Ma Bell and Bell Labs back in the day. And it's true, a lot of great things did come out of Bell Labs.

In fact, it almost seems like the only people able to produce great things in the 1970s were massive entrenched corporations like Ma Bell.

Funny, that.

Come to think of it, wasn't there a much more vibrant browser ecosystem in the late 90s and early 2000s, before Google used its dominant position in the ad market to undercut the competition? There used to be a lot more mobile operating systems out there, too.

I wonder what happened to all that competition? It's almost like some sort of massive anti-competitive influence came into force in the tech scene somewhere in the 2000s. . .

Comment · 2 years ago
The central premise of the article seems to me to be a likely misunderstanding of the problem. I would bet that a Scrum Product Owner who uses a "command and control" leadership style and doesn't know how to properly delegate authority would be doing the same under any other development framework, too.

In general I'm a big fan of the "single wringable neck" principle. I've seen it put to great effect in the hands of a skilled leader, in both Scrum and non-Scrum teams. Better yet, when the leader isn't managing things well, it also leaves no question that they're the one who needs to figure out how to set things straight. Same goes for their delegates.

And for the ICs it makes collaboration easier - and therefore, ironically, enables them to work more autonomously. When everyone unambiguously knows what they're in charge of and what the team's big-picture objectives are, they have everything they need to independently figure out how best to make it happen. And it's also a lot easier to figure out who to talk to when they need to call attention to a problem.

I've seen a lot less luck with shared authority and informal delegation. On the best of days, it turns decisionmaking into an unnecessarily political process. More likely, the team will settle into an informal consensus process that typically operates as "rule by the obdurate" in practice. And when things get tough, the leaders will tend to slide into unproductive bickering that all but precludes actually fixing the problem.

Favorite readings that touch on this kind of thing: The Tyranny of Structurelessness by Jo Freeman, and Turn the Ship Around! by David Marquet.

Comment · 2 years ago
The old chestnut about AI just being a term for things we haven't quite figured out yet might apply here. "Products that are well-known... and are used on a daily basis by a significant amount of people" are almost by definition not AI.

But here are some examples of things that used to fall under the AI umbrella but don't really anymore:

  - Fulltext search with decent semantic hit ranking (Google)
  - Fulltext search with word sense disambiguation (Google)
  - Fulltext search with decent synonym hits (Google)
  - Machine translation
  - Text to speech
  - Speech to text
  - Automated biometric identification (Like for unlocking your phone)
If you're more specifically asking for everyday applications of GPT-style generative large language models, I don't think that's going to happen for cost reasons. These things are still far too expensive for use in everyday consumer products. There's ChatGPT, but it's kind of an open secret that OpenAI is hemorrhaging money on ChatGPT.
Comment · 2 years ago
But do I even want an actually smart Siri?

Microsoft's been trying to ram essentially that down my throat for the better part of a year now, and it's mostly convinced me that the answer is "no". I don't want to have arbitrary conversations with my computer.

I still just want the same thing I've been wanting from my digital assistant for 30 years now: fewer "eat up Martha" moments, and handling more intents so that I can ask "When does the next east-bound bus come?" and it stops answering questions like "Will it rain today?" as if I had asked "Is it raining right now?". None of those are particularly appropriate problems for a GPT-style model.

Comment · 2 years ago
Clarke's Third Law is, has always been, and always will be the best explanation for how futurists think about these kinds of things.
Comment · 2 years ago
Moreover, this is exactly the frustration I've experienced when working with outsourced developers.

Which tells me the problem may be fundamental, not a technical one. It's not just a matter of needing "more intelligence". I don't question the intelligence or skill of the people on the outsourced team I was working with. The problem was simple communication. They didn't really know or understand our business and its goals well enough to anticipate all sorts of little things, and the lack of constant social interaction of the type you typically get when everybody's a direct coworker meant we couldn't build that mind-meld over time, either. So we had to pick up the slack with massive over-specification.

Comment · 2 years ago
It's important to accept that you will screw it up. Repeatedly. Interfaces have to be designed before you can start using them, which means that you will never have less information about how a module will be used than you do when you design its interface.

The best defense against this that I've found is to ensure, as much as possible, that interfaces can be replaced. The single responsibility and interface segregation principles can help here. Using small, focused interfaces and letting modules implement more than one of them makes it easier to use the strangler pattern to replace interfaces that no longer work well with new and improved ones.

Also avoid temporal coupling as much as is feasible. Unnecessary statefulness is the easiest way to make this sort of thing harder than it needs to be.

Comment · 2 years ago
Similar experience here. I went to four high schools. The best ones, academically, were the bog-standard schools that people love to use as an easy punching bag.

The ones where classes were a breeze and barely challenging at all were the private college prep school and the not-quite-as-rich-but-still-pretty-wealthy high school in the suburban white flight community. My read on the situation was that teachers had figured out that every single parent believed their kid deserved a constant stream of gold stars, and had the leisure time and resources to make their lives miserable until it started happening. Also the white flight school cared a lot about its football team so you better make for damn sure that the classes aren't so challenging that the quarterback has trouble balancing their time spent on homework, practice, and partying.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton