eliomattia

The article can be summarized as: context richer prompt history yields answers that are better aligned with expectations.

> the practical constraint of a finite context window coupled with meta-in-context learning’s rapid prompt length increase

The model is not influenced by the added context. The answers are. The abstractions, or, what the LLM "knows", are in the model itself, whereas the answers are just byproducts.

There is an ongoing related discussion on LLMs lacking world model. One could say LLMs do implement a computable model, albeit a dead, static, non-editable one.

By human feedback in T, I meant indeed RLHF. By chat histories H in T, I meant a later selection of user feedback. While plug-ins and added context can be visualized as g(f(H)), fine tuning could be thought of as g(f)(H). There are humans in the loop, however which entailment loop? Not the one affecting the hardware-like f. Unless we retrain de novo.

> This is true for almost everything politicians promote as a "solution"

:-) In their defense, this time they may not even be aware.

> So for most people, they actually see g which is something like g(f(H)))

It is interesting to consider the entailment structure of g(f(H)). f(H), or A, is entailed from H by f. g(f(H)), let us call it A', is entailed from f(H) by g. Using |- as the symbol for entailment, or "entails":

  f |- f(H)
  g |- g(f(H))

All included plugins, embeddings, other API endpoints in g will definitely affect the results, turning answer A, or f(H), into a modified answer A', or g(f(H)). However, what entails f? Nothing in the context of applying g.

To a first approximation, design D and training T are the ones that entail f. T includes all human feedback (training pairs, not direct edits on the entailment in f), and also previous chat histories H for subsequent releases f', however this inclusion is behind decision hierarchies, and the effects of the inclusion on f are largely outside of users' or researchers' precise or accurate control. Training pairs can be added to fine tune, e.g., to filter out violent content, but the results can only be checked downstream of the new f', and fine tuning will retain previous entailments hence acting similarly to a g().

  (D,T) |- f

Let us consider programming, where software S entails output o. What [subject] entails software [direct object]? Programmers P, directly and reliably. Not only can programs be affected precisely and accurately. If we want to modify a program, we do not wrap it inside another program g, hoping that the functional composition will yield the desired result, which will invariably contain entailment from the one we are stuck with. Instead, we edit it.

  S |- o
  P |- S
  S |- P

Programming is interactive, between programmers and software, whereas with LLMs users are downstream when it comes to wanting to affect directly the entailment patterns in f. The human-like chat UX of LLMs leads us to think that chatting with them, giving them human feedback, prompts, or guidelines, or adding plugins and context will naturally flow into us being able to affect f, and that since humans can be manipulated, then so can LLMs. The core of the matter is that f, which entails issues, cannot be affected easily, precisely, or accurately, despite any g that we may want to wrap around it.

There are two divergent analogies to analyze. Compared to programming software, LLMs are experientially closer to the malleability of interacting with humans on the one hand, while functionally closer with hardware entailment-wise, on the other hand. Using symbols that do not overlap with the above: in a computer, hardware W entails that the execution of software S can yield output o from input i. Programmers have the freedom to edit S and experiment with their i/o data. However, it is W, unentailed internally, that defines the boundaries of what is possible for a user: changing W requires hardware engineers and new designs. If W is a desktop computer, programming car engine simulations as S will not turn W into a car. This creative example is meant to indicate that the causation cycle behind a functional component such as W that is unentailed internally at the user/computer level is inherently layered. Similarly, the interactions f has had with H might fully, minimally, or might not at all be considered in the next release. In the case of computers, a user cannot modify W, but hardware engineers can, with full control. With LLMs, not even the researchers can fully control f, for example, to impose that violent themes not be discussed, even using impersonations or a developer mode.

The reason it is important to remain aware that f is not necessarily coevolving with all provided H is the social ease of overlooking how each component is entailed in the current mainstream paradigm. In LLMs, f literally remains unchanged with each interaction, yet a common impression is that we can affect LLMs by chatting with them since the ChatGPT UX is strikingly similar to the experience of chatting with a human. It feels plausible that the effect of just talking to LLMs will be as strong, or even stronger than editing code because when talking to an intelligent human, H can indeed affect their biological f. However, the analogy that holds the strongest with LLMs is that the entailment of f is close to that of hardware W: changing f is much more akin to requesting hardware engineers for edits to W, with the caveat of giving up on editing precision or accuracy, especially if attempting to mask or remove harmful information and when not retraining from scratch. It is true that feedback from H will affect future releases f', but 1) in each release, f remains immutable just like W throughout the interactions, 2) feedback is integrated with delays and slowly, 3) editing is not generally available to users directly except for more superficial fine-tuning, 4) feedback is orders of magnitude less impactful compared to training corpora and design decisions in foundation models, and 5) unlike with designing actual hardware W, even by calling f ChatGPT as a whole, including its many releases, changing f is neither precise nor accurate, as one would imagine an editing process to be and as modifying software S directly is.

Returning to the jailbreak article and using the parallel with the hardware analogy, I assume the intention of the legislators is ultimately to change f, the source of the causation that entails all answers A in chat history H, both by further fine-tuning the models and by adding a list of chat guidelines that are fed as part of the prompt. However, due to the entailment hierarchy of the general architecture, the latter attempt will have zero impact on f itself, thereby not addressing the issue at a fundamental level, while the former strategy will only have a limited effect, due to a fundamental lack of direct control on f: researchers do not have a way to precisely and accurately steer f, and users are even further separated from affecting it.

This is not meant to be dismissive of the current achievements, the results are impressive and the techniques are steadily improving, but rather a critical look at the entailment structures at hand, both perceived and observed, and at the available strategies regarding safeguards. I find it interesting to ask: how can f be made functionally closer to programming S than to W?

There are assumptions here that are intimately related to the meta questions mentioned.

> Prompt injection or prompt attacks are well known and likely impossible to guard against.

They are impossible to guard against under the assumption that the current LLM paradigm is all there is and all there could possibly be. There could be other realizations of AI. The latest impressive achievements are yielding an ongoing identification of the current computational approaches with human intelligence itself, with how we humans model reality by using natural language, and with how we could ever imagine that a computer can model reality via natural language. These are all strong assumptions and are very common even amongst researchers.

> Can you really get a human to be invulnerable to manipulation?

Most definitely not, but we are specifically not talking about humans, but about:

> AI, which relies upon computers, algorithms, and numbers written on memory

I am not making a case for machines being completely invulnerable to manipulation, which requires an analysis of the entailment structures of reality that would yield that complete invulnerability is impossible, but for better direct control on the internals, rather then relying on external instructions that easily undergo jailbreaks with simple prompt attacks.

> Why would we expect the machines to be any better?

One argument is: because they can be programmed and the memory they rely upon for its algorithms can be edited directly, with both accuracy and precision. The missing piece is how to model reality via natural language in a computer, in a way that we would know what to edit in order to affect the model with accuracy and precision.

LLMs, currently, are non-editable. When interacting with ChatGPT, its answers A will be generated from chat history H, which includes prompts and guidelines, by an immutable function, or program, f: A = f(H). It is remarkable that, in LLMs, f cannot be edited and is never entailed by the individual chat H. Since we can have multiple exchanges in the same history, H will itself contain information (entailment) from f, but never the other way around: f is not entailed by A or H, it is fixed, and only entailed externally by the design and training steps. f can be fine-tuned, yet it will retain remnants of past training, hence it cannot be truly be edited at will unless we retrain the whole model. Even then, control on f is neither accurate nor precise.

It seems that non-editable LLMs remove some of the agency that is inherent in programming: editing the internals of a program to shape the entailment structures that we want to realize, with accuracy and precision.

I am by no means indicating that editable AI models that can be steered are easy to achieve, rather that the very possibility thereof is rarely mentioned, and often implicitly assumed not to exist in absolute statements that in fact only strictly apply to the current mainstream approaches.

As a programmer, I find it fascinating to build things from the ground up, with the inner workings either in full display or readily accessible for editing. With AI, the need to beg it to please behave, with a long list of things to do and not to do and a resounding order not to disclose such a list, is becoming commonplace.

Obviously, finding jailbreaks in LLMs is extremely important and consequential. However, there are meta questions around modern AI that remain valid, and this article is a reminder: is a continuous and direct feedback loop between code and coder a thing of the past? To what extent should we accept that LLMs are trained one-way, that we can only truly edit them with expensive trial-and-error retraining runs, hence, all we are left with is asking kindly? Are the current implementations all, or are we dealing with just one possible paradigm? Do we want AI, which relies upon computers, algorithms, and numbers written on memory, to be fundamentally programmable?

Fully agree. Compression in many cases removes the ability to diff easily, however. In a large dataset where, in terms of size, 1% of the original data undergoes changes, or new data the size of 1% of the original dataset is added, I think compressing does not compare with just deduplicating the unchanged 99% in terms of storage, but when speed is the #1 factor, the discussion is more nuanced. It might be interesting to have a combination of deduplication and better compression of the changes, in some form, to get the optimal tradeoff. Repo sizes in ML these days are high, I'm curious which repository compression techniques are being evaluated and deployed.

*I have just (only now) read the second paragraph in your message. Not sure if that came across correctly, that first sentence was too compressed.