Skip to content

Introduction

Vulcan is a forward-chaining inference engine written in Python with a focus on innovative capabilities, scalable performance, and a delightful developer experience. Developers familiar with traditional enterprise rule engines will notice that Vulcan shares many familiar concepts such as: Facts, Conditions, and Actions.

What makes Vulcan special is the seamless integration of modern AI capabilities such as LLM prompting and vector database similarity searching within rule definitions. This hybrid approach allows developers to mix the consistency of computational logic with the flexibility of predictive language models.

As an open-source project, Vulcan is shaped by community input and contributions. As your project needs grow, commercial support and value-add features are available to ensure your success.

What is "Forward-Chaining Inferencing?"

A forward-chaining inference engine is essentially a large data-driven "if-then" statement that is dynamically evaluated based on "rules" that have criteria that match "facts" in working memory. As rules are evaluated, the working memory is updated with new facts. These facts may trigger additional rules to be evaluated, and the process continues until no more rules can be evaluated - hence the term "forward chaining".

This differs from imperative programming where the developer defines the order of operations. In a forward-chaining system, the order of operations is determined by the state of the working memory.

LLM Problems

LLMs are powerful tools for generating text, but often struggle with complex instructions and may hallucinate at unexpected times. As statistically-predictive language models, they are unable to truly exercise memory, logic, or arithmetic. This poses significant risk when using LLMs for decision making, especially as the reasoning behind an LLM's response is often unclear. With larger prompts, context, and instruction complexity, these shortcomings become more significant and unpredictable.

Consider the following LLM prompt:

LLM Prompt
As a bakery, I want to buy 10 apples if I have less than 10 in inventory, but only if my supplier has apples used for baking in stock. Given I have 9 apples, and my supplier has "Honeycrisp", how many apples should I order?

While prompt-engineering techniques can be very complex, the above is a simple but valid approach: We describe a scenario with conditions and provide a set of information (context) for the LLM to process. In practice, the prompt would be templatized with variables substituted to evaluate different scenarios - but for simplicity in our example, we are not using a template.

Given this prompt, an LLM may respond with something like the following:

LLM Response
Okay, so if you have 9 apples, how many apples do I have? Hmmm... If I have 2 apples and I give them to you, then you will now have 12 apples. So in that case, you should order 0 apples.

This illustrates several ways in which an LLM may fail to reason through our prompt:

  • The LLM appears to have a bias towards conversational responses and hallucinates an unprompted scenario.
  • It fails to perform basic arithmetic to determine the correct number of apples to order.
  • It seemingly "forgets" or ignores consideration of the type of apples in stock.

Admittedly, this is a trivial example, and advanced LLMs such as GPT and Claude will probably provide the correct answer. But the key point is: "probably." Many use cases cannot afford to accept the risk of unreliable automated decision-making.

These problems and risks grow as the size and complexity of the prompt and context increase. It is true that guardrails and validation checks can be used to constrain the LLM's response, but these techniques only offer a reduction in risk (and to an uncertain degree).

The Vulcan Approach

A central idea behind Vulcan is that many LLM risks arise from a lack of adequate separation of concerns. Using an LLM to perform computational or logical reasoning tasks should be seen as flawed as using a hammer to drive screws. Sure it's possible, but there are better tools for the job.

While LLMs can be very convincing in their ability to reason, the probability of an LLM successfully "guessing" the correct answer decreases the further away from the training data an LLM operates. With variable input, it's not "if" an LLM will fail, but "when." Guardrail frameworks, complex prompt engineering, and fine-tuning can help reduce, but not eliminate, these risks.

Vulcan takes a fresh approach to solving these problems by integrating computational and predictive capabilities into a single reasoning engine observing clear separation of concerns. It provides a means to declare explicit logic and computation, while reducing the risk of LLM failure via "microprompting."

The following is a simplified comparison between Vulcan's hybrid approach and a typical LLM application:

Vulcan Hybrid Reasoning

flowchart TD
    api[API] -->|Query Facts| framework
    framework -->|Decision| api

    subgraph framework[Vulcan Reasoning Engine]
        rules[Rule Matcher] --> computation[Logic Solver]
        computation -->|LLM Rules| context["Microcontext Fetcher<p style="font-size:75%">(APIs, Vector DBs, etc.)</p>"]
        context -->|Variables, RAG| prompt[Microprompts]
        prompt -->|New Facts| rules
        computation -->|New Facts| rules
    end

    prompt<-->llm[LLM]

Typical LLM Usage

flowchart TD
    api[API] -->|Query| framework

    subgraph framework[LLM Framework]
        context["Context Fetcher<p style="font-size:75%">(APIs, Vector DBs, etc.)</p>"] -->|Variables, RAG| prompt[Template Population]
        prompt -->|Large Prompt| guardrail[Guardrails]       
    end

    guardrail <-->|Filtering| llm["LLM + Tool APIs"]
    guardrail -->|Response| api

Vulcan uses discrete computational operations expressed as rules outside of the LLM prompt. A typical LLM application may often rely on the LLM to evaluate logical and arithmetic operations (or to call tools) within one or more relatively large prompts. Furthermore, Vulcan encourages a "microprompting" approach, reducing the amount of instruction and context required for the LLM to process.

By comparison, Vulcan offers a number of benefits over typical LLM usage:

  1. Consistency: "1+1" will always equal "2" and such operations are immune to LLM hallucination or prediction variance.
  2. Adherence: By using microprompts, LLMs are easier to direct and more difficult to jailbreak.
  3. Cost & Performance: Logic and arithmetic operations are faster and cost less when performed on a CPU than an LLM.
  4. Explainability: Rule-based reasoning provides far better insight into the decision-making process.

In Summary

Vulcan offers developers the ability to easily mix the consistency of computational logic with the flexibility of predictive language models. By promoting a hybrid reasoning approach, Vulcan reduces the risk of LLM failures and provides more consistent, predictable, and explainable automated decision-making.