Supply5411

Server side rendering

Great example. Right, the deep learning approach uncovers all kinds of hidden features and relationships automatically that a team of humans might miss.

I guess I'm thinking about this problem from the perspective of these GPT models requiring more training data than a normal person can acquire. Currently, it seems you need the entire internet worth of training data (and a lot of money) to get something that can communicate reasonably well. But most people can communicate reasonably well, so it would be cool if that basic communication knowledge could be somehow used to accelerate training and minimize the reliance on training data.

I wonder if an expert can "impose" weights onto a model and the model will opt to continue with them when it resumes training. For example, in the vision example, the expert may not know where "orangeness" currently exists, but if they impose their own collection of weight adjustments that represent orangeness, will the model continue to use these weights as the path of least resistance when continuing to optimize? Just spitballing, but if we can't pick out which neurons do what, the alternative would seem to be to encourage the model to adopt a control interface of neurons.

I've been kicking around a similar idea for awhile. Why can't we have an intuitive interface to the weights of a model, that a domain expert can tweak by hand to accelerate training? For example, in a vision model, they can increase the "orangeness" collection of weights when detecting traffic cones. That way, instead of requiring thousands/millions more examples to calibrate "orangeness" right, it's accelerated by a human expert. The difficulty is obviously having this interface map to the collections of weights that mean different things, but is there a technical reason this can't be done?

They're not. A query produced by an LLM may do exactly what the user asks for, but it is not safe to execute.

So tools carry the same level of risk if the only way they can do harm is user error, even if that user error is easier to miss by design? I guess I just fundamentally disagree because I think risk analysis is holistic. Is the tool fundamentally correct (free of bugs) and is it easier to misuse.

I'm going to look at an outer join FAR more critically, regardless of who wrote it, because it's easy to mess up the conditions.

>We burned over 200 hours on it with nothing to show for our time.

Can you talk more about this? I'm working in this space now, but not from the "make an LLM give you the right query" perspective, but from the "make the LLM-produced query be safe" perspective[1]

1. https://docs.heimdallm.ai/en/main/blog/posts/safe-sql-execut...

Outer joins are inherently risky because they make it very easy to put conditions in a place that looks correct (read: passes review) but isn't, and the results are disastrous (information leak).

Having a deeper understanding of the different JOIN flavors is critical. For example, I don't think many people realize how deceptively dangerous OUTER joins are:

  SELECT user.user_id
  FROM users
  RIGHT JOIN purchases
    ON purchases.user_id = user.user_id
    AND user.user_id=123

By leaving the user_id=123 constraint in the JOIN instead of putting it in the WHERE, you've just exposed everyone's purchase data to the user. Easy to miss too if your tests don't fully create fixtures for multiple users. This becomes even more dangerous as we're entering the world of LLMs generating SQL[1]

1. https://docs.heimdallm.ai/en/main/attack-surface/sql.html#ou...

I must be getting older, because "everything old is new again" keeps coming to mind.

Only advice would be: don't follow these fads unless you a) are doing it to learn or b) can quantify tangible business value in the change. The worst reason to do it is because everyone else seems to be doing it*

*Unless literally everyone is doing it and the "old" thing becomes unsupported.

There isn't a 1-1 of ascii character to base64 character is the thing. 3 ascii character = 4 base64 characters, so changing one of the input changes 1 or 2 of the output.

Call it whatever makes you feel better, it doesn't change the law, which doesn't make this a tech/privacy issue.

>Algorithmically it seems to be a 8-bit byte to character mapping

Base64 is 6-bits, so there is no mapping of a single character to another single character. Changing 1 character in the input can change 1 or 2 characters in the output because each of the 6-bit "characters" are up against each other. So there is no mapping of input character to output character(s), it depends on context.

I'm aware that regular NL translations are a similar problem, but with base64, it's a much more exact and unforgiving problem, and GPT-4 seems to perform at a very high level.

I don't know why this surprises me but translating natural languages doesn't. I think it is the sustained accuracy.

Thanks, confirmed. Do you have any resources where I can read more about this phenomenon?

Huh, you're right. It got the random string close, but not exact. I'm still blown away... what in its training set could predict that random string as base64 that closely?

https://chat.openai.com/share/02d616c2-5667-454d-9b72-43dfb1...

GPT 4 gets it right. I understand that LLMs have some very rough emergent properties, like arbitrary arithmetic (but its often incorrect). I don't really understand how its able to base64 decode values it has never seen though. I'm using unique snippets from my own private source code.

I'm getting perfect results with very long strings. Can you share an example that fails for you?

Sorry but I have to call bs. How do you explain this? It decodes a huge (guaranteed unique) string perfectly:

https://chat.openai.com/share/417169ed-8256-46cb-a3ed-81ab06...

>Court and police records show that police began investigating 17-year-old Celeste Burgess and her mother Jessica Burgess after receiving a tip-off that the pair had illegally buried a stillborn child given birth to prematurely by Celeste. The two women told detective Ben McBride of the Norfolk, Nebraska Police Division that they’d discussed the matter on Facebook Messenger, which prompted the state to issue Meta with a search warrant for their chat history and data including log-in timestamps and photos.[1]

Police were given a tip. They talked to the women, who then admitted to coordinating the crime over chat. A warrant was issued. No 4th amendment was violated.

1. https://www.theverge.com/2022/8/10/23299502/facebook-chat-me...

>Why would you even make this opt-in?

Businesses are not your friend

The real issue is obviously people are mad that abortion laws are being enforced. If two people were coordinating their intentions to murder their friend and get rid of the body, would you be mad if the company turned over their "private" chats? If no, then it's not a tech/privacy issue at all.

Do everything as fast as possible, seems about right

You answered your own question: the advertising that they produce is what they're comfortable with.

Maybe the real lesson here is nobody who wants to speak their mind should be supporting themselves on a platform of nervous advertisers.

This reads like you're saying its a bad thing to prove the existence of these manipulative power structures because it happens to make someone more credible. Like "No, no, power structures, stay hidden, you're only helping him."

>you're not actually competing over someone who's using an AI girlfriend since they have removed themselves from the dating pool.

They're still competing for the attention of men they don't desire.

If you feel an existential crisis now, just wait until the artificial wombs. Replacing man's reliance on woman is where technology is heading.

The same way you know that the things you learn from a person isn't made up gibberish: You see how well it explains a scenario, how well it lines up with your knowledge and experience, and you sample parts to verify.

I'm very far from the beginning of my career, but maybe I see a point in your comment, because I frequently try technologies that I am not an expert in.

Just yesterday, I asked if Typescript has the concept of a "late" type, similar to Dart, because I didn't want to annotate a type with "| null" when I knew it would be bound before it was used. Searching for info would have taken me much longer than asking the LLM, and the LLM was able to frame the answer from a Dart perspective.

I would say that that information neither "important to digest" nor "readily available."