LLM-Oracle Machines
Abstract
Contemporary AI applications leverage large language models (LLMs) to harness their knowledge and reasoning abilities for natural language processing tasks. This approach shares similarities with the concept of oracle Turing machines (OTMs). To capture the broader potential of these computations, including those not yet realized, we propose an extension to OTMs: the LLM-oracle machine (LLM-OM), by employing a cluster of LLMs as the oracle. Each LLM acts as a black box, capable of answering queries within its expertise, albeit with a delay. We introduce four variants of the LLM-OM: basic, augmented, fault-avoidance, and -fault. The first two are commonly observed in existing AI applications. The latter two are specifically designed to address the challenges of LLM hallucinations, biases, and inconsistencies, aiming to ensure reliable outcomes.
1 Introduction
In an oracle Turing machine, the oracle embodies a decision problem. It acts as a hypothetical, all-powerful entity that can instantly determine whether a query, an instance generated during the computation, is a positive instance of the decision problem. OTMs have played a significant role in the development of both computation theory and computational complexity theory.
Drawing inspiration from the concept of using external knowledge to assist with computing tasks, and motivated by the recent advancements in LLMs with their powerful knowledge bases and inference capabilities, we use a cluster of LLMs in place of the oracle in OTMs.
We treat LLMs as black boxes, capable of answering queries within their domains of expertise, albeit with a delay111The assumption of delay may be omitted if we are focusing on generating trustworthy results.. Both queries and responses are exchanged in natural language, encompassing formatting. Since each LLM is trained on diverse datasets using different technologies, their capabilities vary. Therefore, we use a cluster of LLMs as the oracle, selecting an appropriate LLM to respond to a query during an LLM-OM computation.
Unlike in an OTM, where the oracle represents a decision problem and a query asks whether an instance is positive, a query generated in the computation of an LLM-OM consists of a task and a sequence of specifications, with the response being a solution to complete the task.
In a nutshell, the computation of an LLM-OM takes an input representing a task to accomplish, generates queries, acquires answers to each query from the appropriate LLM in the LLM-oracle, and continues this process until the LLM-OM reaches a halting state with the final answer.
Unlike in an OTM where the oracle reliably provides an answer to a query, LLMs can generate fabricated or misleading information, resulting in incorrect or inadequate answers (e.g., see [1, 2]). LLMs may also provide answers with different meanings to the same query at different times. These issues of information hallucination (or better phrased as “information nonsense” because LLMs cannot distinguish between truth and lies), inadequacy, and inconsistency are common in LLMs.
While advancing technologies aim to mitigate these issues, complete elimination remains challenging. Therefore, we assume that there exists a probability that an LLM may provide an unacceptable answer to a query. Depending on the context of the application, an unacceptable answer could be one that is outright incorrect or one that, while not incorrect, fails to meet the required level of adequacy.
2 LLM-OM Basics and Variants
An LLM-OM can be viewed as a deterministic algorithm with access to an LLM oracle. Similar to an OTM, each computation step in an LLM-OM represents a transition. We denote an LLM-OM as , the input representing the task inquiry (including optional specifications) as , and the output as the answer to . This output can take various forms, including human-like text, code snippets, or other representations. Both inputs and outputs can be encoded as binary strings for compatibility with traditional computing models.
During the computation, generates a query in the form of , denoted as , where is an intermediate task for completing and each is an attribute. These attributes can be
-
•
Selected text to provide relevant context for .
-
•
Specific requirement to detail the desired outcome of .
-
•
Solution format to instruct on how to express the answer (e.g., text, code).
-
•
Verification method to specify how to validate the answer’s correctness.
-
•
Self-critique instruction to guide to evaluate its own response.
Other specifications with any additional details relevant to completing may also be attributes. Collectively, these attributes form a prompt that instructs the LLMs on how to approach the intermediate task effectively.
The computation begins with interpreting the input task . If possible, it decomposes into a sequence of smaller, more manageable subtasks, denoted as . However, if cannot be further broken down, it remains the sole subtask.
2.1 Basic variants: adaptive and non-adaptive
The basic variant of the LLM-OM utilizes two query types: adaptive and non-adaptive.
In an adaptive LLM-OM: subtasks are interdependent. This means some subtasks require answers from previous subtasks before generating all queries. For a subtask , the LLM-OM generates a query specifying the task within the query. It then retrieves an answer from a chosen LLM in the oracle and uses to determine the next step. The final answer is derived by combining answers from subtasks, potentially involving the LLM-oracle again.
In a non-adaptive LLM-OM, subtasks are independent. Each subtask is completed by sending a set of independent queries generated during the computation to the LLM-oracle. The final answer is produced solely from these answers, without further interaction with the LLM-oracle.
Ideally, the final answer should directly address the original inquiry and remain relevant to the topic. Let denote the collection of topics within text .
-
•
We say that is relevant to , denoted by , if .
Remark 1. The basic functionality of many LLM web applications, like free versions of ChatGPT and Gemini, exemplifies the non-adaptive LLM-OM variant. In these applications, users submit queries, which directly translate to the subtasks in the LLM-OM. The system then independently generates a set of queries based on the user’s input and sends them to the underlying LLM-oracle. Finally, the application presents the user with the final answer derived solely from these responses, without further interaction with the LLM.
2.2 Augmented LLM-OM
The augmented LLM-OM takes a pair as input. Here, represents an “augmented text” in natural language, acting as verified background knowledge or ground truth. remains the task inquiry, specifying what information to extract or infer from . This information can include specific sentences, topics, summaries, entities, relationships between entities, events, event relationships, logical consequences, or numerical consequences. Similar to the basic variant, queries generated during the computation can be either adaptive or non-adaptive.
Ideally, the answer to the inquiry should align with the augmented text . Here’s a formal definition of this alignment. Let denote the set of meanings of text .
-
•
We say that complies with with respect to , written as , if the following conditions hold:
-
1.
Relevance: is relevant to . Namely, .
-
2.
Inclusiveness: is inclusive in . Namely, .
-
1.
Note that even if two texts and have the same set of meanings (i.e. ), it doesn’t necessarily mean they are identical. There are many ways to express the same idea with different wording.
To complete the task represented by query , the LLM-OM first identifies relevant content, denoted as , within the augmented text . It then leverages this content along with an appropriate LLM from the LLM-oracle to generate an answer to , denoted as , ideally complying with with respect to , namely, .
Remark 2. Web applications like ChatGPT 4o that employ Retrieval-Augmented Generation (RAG) techniques with an LLM can be seen as a practical application of the augmented LLM-OM framework. In RAG-based applications, the retrieved information acts as the augmented text that confines the LLM’s response. This retrieved information helps the LLM generate answers that are more grounded in factual evidence and more likely to comply with the user’s query.
2.3 Fault-avoidance LLM-OM
The basic and augmented LLM-OM variants do not inherently guarantee consistency, correctness, or adequacy in the final answer for several reasons:
-
1.
Limitations of LLMs: Even the most advanced LLMs can be susceptible to biases, factual inaccuracies, and hallucinations in their responses. These issues can directly translate into inconsistencies or errors in the final answer generated by the LLM-OM.
-
2.
Incomplete or unclear input: If the initial user inquiry or the augmented text in the augmented variant is ambiguous, incomplete, or misleading, it can lead the LLM-OM down an incorrect path and ultimately result in an inadequate or incorrect answer.
-
3.
Dependence on LLM selection: The choice of LLM from the LLM-oracle can also influence the outcome. Different LLMs have varying strengths and weaknesses, and an inappropriate selection might hinder the generation of a consistent or accurate answer.
-
4.
Query design challenges: Crafting effective intermediate queries is crucial. Poorly designed queries can lead the LLM-OM to misunderstand the intent or miss key aspects of the overall task, compromising the final answer’s adequacy.
For the purpose of illustration, we assume that both the user inquiry and the augmented text in the augmented variant are well-defined and free from ambiguity, incompleteness, and misleading information. This idealized scenario allows us to focus on the limitations inherent to the LLM-oracle itself, independent of potential issues with the input data. We define these terms (consistency, correctness, and adequacy) as follows:
-
•
is consistent if, for any user inquiries and posed at different points in time, if , then outputs an answer to and an answer to such that .
-
•
Suppose is augmented with input and output being and . We say that is correct for with respect to if the following conditions hold:
-
1.
Compliance: complies with the ground truth with respect to . Namely, .
-
2.
Exclusiveness: doesn’t include unnecessary information outside the scope of . In other words, if we let denote the set of intended meanings of , then .
-
3.
Completeness: doesn’t miss any information contained in that are relevant to . In other words, .
-
4.
Distribution agreement: If has more than one meaning, then , where denotes the distribution of meanings within answer and denotes the distribution of meanings in the corresponding text for in the augmented text .
We say that is correct with respect to if for any input , returns an answer that is correct for with respect to .
-
1.
-
•
Suppose is an augmented LLM-OM with input that generates an answer . We say that answer is adequate for with respect to if complies with with respect to . However, unlike correctness, adequacy allows for some flexibility in the answer:
-
1.
Non-exclusiveness: may contain information that extend beyond the specific information requested in the user inquiry . Namely, .
-
2.
Incompleteness: may miss information from that pertains to . Namely, .
-
3.
Distribution discrepancy: .
Essentially, adequacy acknowledges that the answer may not be perfect, but it provides valuable information to the query from the augmented text.
We say that is adequate if for all inputs , returns an answer that is adequate for with respect to .
-
1.
-
•
If is not augmented, assume the existence of a set of texts, denoted by , that represents the true knowledge and information for the areas of interest. We say that is correct if is correct with respect to , is adequate if is adequate with respect to . Set is referred to as the absolute truth.
Note that if is correct for with respect to , then is adequate for with respect to , but not vice versa.
A fault-avoidance LLM-OM is an augmented LLM-OM that is consistent and correct. A weak fault-avoidance LLM-OM is an augmented LLM-OM that is consistent and adequate. It is necessary for to identify the best-matched content from for each query , and the chosen LLM from the LLM-oracle must comply with when generating an answer to .
Verifying the correctness or adequacy of the answer for a given query with respect to calls for concrete implementations of , , , and using techniques in natural language processing, machine learning, deep learning, and other methods.
Consistence, however, is harder to verify. We may aim to develop a method that provides a certain guarantee that is consistent with a desired high probability.
2.4 -fault LLM-OM
An -fault LLM-OM is a non-augmented LLM-OM that is consistent and correct with probability of with respect to the absolute truth for the areas of interest, where is some small positive parameter. Likewise, a weak -fault LLM-OM is similarly defined by replacing correctness with adequacy.
Let be the LLMs in the LLM-oracle, where each has a small probability of generating hallucinated answers to queries. Different LLMs may hallucinate on different queries. However, doesn’t know which LLM will hallucinate an answer to a given query, and alone cannot verify if an answer is incorrect, as the absolute truth is not provided as an augmented input.
We aim to investigate whether it is possible to utilize these LLMs to obtain an answer to a query with a certain level of guarantee that the answer is correct or adequate with a desired probability for some .
Making certain reasonable assumptions may be useful in the quest to obtain such a result. For example, we may assume that for a given query, there is always an that produces a correct and adequate answer; we just don’t know which one.
References
- [1] J. Li, J. Chen, R. Ren, X. Cheng, W. X. Zhao, J.-Y. Nie, and J.-R. Wen, “The dawn after the dark: An empirical study on factuality hallucination in large language models,” 2024. arXiv 2401.03205.
- [2] R. Stureborg, D. Alikaniotis, and Y. Suhara, “Large language models are inconsistent and biased evaluators,” 2024. arXiv 2405.01724.