4 ms·
Well, I guess we agree here - the basic functionality will be common, Open AI will not have a monopoly (unless lawmakers really screw up), but will likely exist
by yyyk 3y ago
Well, I guess we agree here - the basic functionality will be common, Open AI will not have a monopoly (unless lawmakers really screw up), but will likely exist and be a major player. I am not sure about Open Source at all just yet - e.g. it's possible that a panic will lead to restrictions that will make open work rather difficult. I guess we'll see.
>what happens when everyone uses AI? One of the most exciting possibilities I see for this technology is to entirely toss out the persnickety concept of the API in favor of LLMs talking to LLMs.
Hmm. Your idea has lower throughput and higher latency, while having not entirely clear security properties. But really, companies will sacrifice nearly all that in the service of faster shipping, paying less to programmers, and easier interfacing. Just look at the history of latency in user systems from the 1980s till today. The only game breaker here is security.
Hm. We implement an internal API that the LLM must use in order to do anything local, and do the limiting/auditing there. So the external interface is language, but what the LLM can do is either use the limited internal API to do approved actions locally, or speak to other LLMs (which will have their own internal APIs) using the user's context (OpenID token, whatever). There's a slight risk in the security boundary here (e.g. make sure the LLM never impersonates - don't allow it to see the actual user context, make sure each LLM instance only has access to the current user context. Also need to make sure it doesn't tell the other LLMs too much), but I think it's handleable?
Regardless, we aren't there yet, and there are still a few issues here (e.g. I expect Microsoft/Google to always have an advantage in Office 365/GSuite integrations somehow). Until we do, integrations will still have a big effect on the market.
- yyyk 3y agoThinking about this a bit more, the main issue is that the LLM is an attack vector. Hallucinations aren't a big deal if the action requires approval or can be easily undone. The only way right now I can see to make LLM interfaces 'safe' would be to give it an internal API and pass the user context so we can set up permissions that way. There are a very few cases where even that might not be enough (basically whenever you pass 'on-behalf-of' transactions _without_ direct approval from the origin via a temporary token - e.g. many backend payment APIs allow this). However, if you have an internal API which is the real security boundary, you might as well expose it. The effort required to add an LLM is now an extra effort and that flips the incentives to where the LLM really adds value. So adding LLMs as interfaces really makes sense on Windows 11 (practically single user, hallucinations have limited cost) and GitHub (devs have local copy anyway), maybe on AWS (devs would like an easier interface, but there's a need to reassure about safety), and none on Stripe or MailGun (complex security scenarios, usually decided by finance/marketing department which don't care about integration difficulty).