> Tool calls are nothing more than specially formatted text which gets parsed and interpreted by the inference server
I know this is getting off-topic, but is anybody working on more direct tool calling?
LLMs are based on neural networks, so one could create an interface where activating certain neurons triggers tool calls, with other neurons encoding the inputs; another set of neurons could be triggered by the tokenized result from the tool call.
Currently, the lack of separation between data and metadata is a security nightmare, which enables prompt injection. And yet all I've seen done about is are workarounds.
Each text token already represents the activation of certain neurons. There is nothing "more direct." And you cannot fully separate data and metadata if you want them to influence the output. At best you can clearly distinguish them and hope that this is enough for the model to learn to treat them differently.
> LLMs are based on neural networks, so one could create an interface where activating certain neurons triggers tool calls, with other neurons encoding the inputs; another set of neurons could be triggered by the tokenized result from the tool call.
You can do this. It's just sticking a different classifier head on top of the model.
Before foundation models it was a standard Deep RL approach. It probably still is within that space (I haven't kept up on the research).
You don't hear about it here because if you do that then every use case needs a custom classifier head which needs to be trained on data for that use case. It negates the "single model you can use for lots of things" benefit of LLMs.
I'm a novice in this area, but my understanding is that LLM parameters ("neurons", roughly?), when processed, encode a probability for token selection/generation that is much more complex and many:one than "parameter A is used in layer B, therefore suggest token C", and not a specific "if activated then do X" outcome. Given that, how would this work?
I think this discussion distracts a bit from the main point.
The main point is that there are super widespread software systems in use that we know aren't secure, and we certainly could do better if we (as the industry, as customers, as vendors) really wanted.
A prime example is VPN appliances ("VPN concentrators") to enable remote access to internal company networks. These are pretty much by definition Internet-facing, security-critical appliances. And yet, all such products from big vendors (be they Fortinet, Cisco, Juniper, you name it) had a flood of really embarrassing, high-severity CVEs in the last few years.
That's because most of these products are actually from the 80s or 90s, with some web GUIs slapped on, often dredged through multiple company acquisitions and renames. If you asked a competent software architect to come up with a structure and development process that are much less prone to security bugs, they'd suggest something very different, more expensive to build, but also much more secure.
It's really a matter of incentives. Just imagine a world where purchasing decisions were made to optimize for actual security. Imagine a world where software vendors were much more liable for damage incurred by security incidents. If both came together, we'd spend more money on up-front development / purchase, and less on incident remediation.
But we need to be careful, such strict liability rewards larger companies that can afford such risk. Small companies and freelancers could be left out to dry.
My parents have a sound bowl, and I wanted to know the resonance frequency. Took an audio spectrum, zoomed in on the first peak, read the frequency (iirc it was around 208 Hz).
This is the point where you send a letter to the company, stating both the situation and the remedy you want (e.g. refund of payments for inaccessible services, cancellation of the account, maybe a reasonably small amount as compensation for damages).
In that letter, you set a reasonable deadline.
If they don't respond within that deadline, you take them to a small-claims court.
I understand that us tech bros want to fix everything online, but sadly that doesn't always work. But that's not the end of all your options.
I think OP's context is: they get called to help troubled projects. Often the people that hired them might not know where exactly the trouble comes from.
If you look at a code base that's not really in trouble, these commands don't reveal the source of the trouble, because there might be none.
The time for regulatory action against Microsoft was thirty years ago and the need for it has only grown since then.
The FTC wasn't doing their job between 1980-2020 because of their ridiculous standard of, "if it doesn't raise consumer prices, it must be allowed." This lead to massive consolidation in many industries which of course ended up raising prices and hurting consumers anyway.
Recently they've had some wins but overall they're still failing to do their job.
It was the Clinton administration that started regulatory proceedings against Microsoft, but it was GW Bush that was president during the conclusion of the case. And, true to form:
> The Department of Justice, now under Bush administration attorney general John Ashcroft, announced on September 6, 2001, that it was no longer seeking to break up Microsoft and would instead seek a lesser antitrust penalty
This has really helped in Germany.
reply