Readit News logoReadit News
tango12 commented on Being “Confidently Wrong” is holding AI back   promptql.io/blog/being-co... · Posted by u/tango12
lucideer · 4 days ago
While the thrust of this article is generally correct, I have two issues with it:

1. The words "the only thing" massively underplays the difficulty of this problem. It's not a small thing.

2. One of the issues I've seen with a lot of chat LLMs is their willingness to correct themselves when asked - this might seem, on the surface, to be a positive (allowing a user to steer the AI toward a more accurate or appropriate solution), but in reality it simply plays into users' biases & makes it more likely that the user will accept & approve of incorrect responses from the AI. Often, rather than "correcting" itself it merely "teaches" the AI how to be confidently wrong in an amenable & subtle manner which the individual user finds easy to accept (or more difficult to spot).

If anything, unless/until we can solve the (insurmountable) problem of AI being wrong, AI should at least be trained to be confidently & stubbornly wrong (or right). This would also likely lead to better consistency in testing.

tango12 · 4 days ago
The AI being wrong problem is probably not insurmountable.

Humans have meta-cognition that helps them judge if they're doing a thing with lots of assumptions vs doing something that's blessed.

Humans decouple planning from execution right? Not fully but we choose when to separate it and when to not.

If we had enough data on here's a good plan given user context and here's a bad plan, it doesn't seem unreasonable to have a pretty reliable meta cognition capability on the goodness of a plan.

tango12 commented on Being “Confidently Wrong” is holding AI back   promptql.io/blog/being-co... · Posted by u/tango12
rwmj · 4 days ago
Only thing? Just off the top of my head: That the LLM doesn't learn incrementally from previous encounters. That we appear to have run out of training data. That we seem to have hit a scaling wall (reflected in the performance of GPT5).

I predict we'll get a few research breakthroughs in the next few years that will make articles like this seem ridiculous.

tango12 · 4 days ago
Author here.

You’re right in that it’s obviously not the only problem.

But without solving this seems like no matter how good the models get it’ll never be enough.

Or, yes, the biggest research breakthrough we need is reliable calibrated confidence. And that’ll allow existing models as they are to become spectacularly more useful.

tango12 commented on Getting AI to write good SQL   cloud.google.com/blog/pro... · Posted by u/richards
tango12 · 3 months ago
What’s the eventual goal of text to sql?

Is it to build a copilot for a data analyst or to get business insight without going through an analyst?

If it’s the latter - then imho no amount of text to sql sophistication will solve the problem because it’s impossible for a non analyst to understand if the sql is correct or sufficient.

These don’t seem like text2sql problems:

> Why did we hit only 80% of our daily ecommmerce transaction yesterday?

> Why is customer acquisition cost trending up?

> Why was the campaign in NYC worse than the same in SF?

tango12 commented on After 6 years, I'm over GraphQL   bessey.dev/blog/2024/05/2... · Posted by u/mattbessey
cletus · a year ago
Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL.

Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps:

1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has;

2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data.

3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data.

Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other.

The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak.

How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.

tango12 · a year ago
Counter-opinion:

I totally agree with the sentiment here, but disagree with the conclusion.

1. The rest of the world doesn't have facebooks data layer. Ergo, GraphQL is very hard for everyone who's not FB.

2. Turns out GraphQL is actually a really good data API. Whether it's a postgres/mongo/graph/REST data source. Because it's a great mid-point between something as flexible as SQL but as controlled as a REST API.

Here are 3 things that GraphQL is absolutely great at:

  - Select a 2 fields out of a 100 attributes in a data model? GraphQL is great.
  - Gradually deprecate an old field in a database and replace with a new one? GraphQL is great.
  - Want a flexible way to filter/join/paginate regardless of the underlying storage layer? GraphQL is great.
Other API formats suck at this.

Working with GraphQL ought to feel like you're working entirely with your database and sprinking the right bits of transform/validation/authz business logic and then the API that other teams can use is "free".

GraphQL is dying as a replacement to a REST API layer. I think GraphQL will see its second wind as a data API. Microsoft and Google announced their GraphQL data APIs recently.

GraphQL will probably only make sense when it's as close as a 1:1 map to a DB beneath it. Whether relational or NoSQL or graph.

In all other cases, the GraphQL juice is not worth the squeeze.

u/tango12

KarmaCake day837February 14, 2015
About
Founder @ promptql.io, hasura.io Custom AI for accurate analysis & automation

he/him

tanmaig [at] promptql [dot] io

View Original