03

4:08 - 5:23

Convergence: probabilistic agents with symbolic guardrails

Watch from 4:08

The two lineages introduced in the previous chapter meet in a neuro-symbolic design. An LLM brings flexible language generation and action planning. An ontology brings a formal model of a domain, together with rules that can check what the model proposes. The goal is not to replace the LLM. It is to give its flexible behavior a domain-aware reference frame.

Two different kinds of capability

An LLM is probabilistic. It generates a likely continuation from its prompt and context. This makes it useful when the system must interpret a request, produce language, or suggest the next action. However, likelihood is not the same as truth or consistency with a particular domain.

An ontology supplies the other kind of capability. It represents concepts and their relations in a more formal way. A domain can therefore state what kinds of entities exist, how they may be related, and which rules or constraints apply to those relations.

These are different jobs:

Part of the system Main strength Question it helps answer
Probabilistic agent or LLM Flexible interpretation and generation “What should I say or try next?”
Ontology and symbolic support Explicit concepts, relations, and rules “Does that proposal fit the domain?”

This is a division of labor, not a claim that either part is sufficient by itself. An ontology does not make an LLM non-probabilistic. It gives the surrounding system something formal against which the LLM's proposal can be evaluated.

What “neuro-symbolic” means here

The speaker uses neuro-symbolic AI for neural networks connected to symbolic AI. In this talk, the symbolic side includes rule-based systems and knowledge graphs. “Neuro” refers to the neural model, such as an LLM. “Symbolic” refers to explicit representations and rules that can be inspected and applied.

The important point is the connection between them. The system can use the LLM to generate a candidate answer or action, then use symbolic knowledge to check that candidate. The symbolic layer is not merely a second description of the same text. It supplies structure that free-form generation does not guarantee.

flowchart LR
    R[Request and context] --> L[Probabilistic LLM]
    L --> P[Proposed answer or action]
    P --> V[Ontology, rules, and knowledge graph]
    V -->|fits the domain| A[Continue or act]
    V -->|does not fit| F[Reject, revise, or investigate]

Teaching model: This diagram makes the proposed division of labor explicit. The LLM still generates the proposal. The ontology and its symbolic rules provide the check. The source introduces this architecture at a high level; it does not prescribe this exact diagram or a particular validator implementation.

Guardrails for a generative model

The speaker says that the symbolic side can keep an LLM on guardrails. A guardrail here is a check around the model's behavior. It can compare a proposed result with domain concepts and rules before the system treats that result as acceptable.

The causal idea is:

  1. The agent receives a problem and uses the LLM to generate a possible response or action.
  2. That proposal is represented in a form that can be checked against the domain model.
  3. Ontological rules and related symbolic knowledge provide expectations about valid entities, relations, or outcomes.
  4. The surrounding agent loop can then continue with a result that passes the check, or handle a result that does not.

The later parts of the talk make this more concrete. RDFS and OWL are presented as supporting technologies beside the graph. They can add type inference, relationship behavior, and constraints. For example, domain and range information can infer what kinds of things appear in a relation. OWL property characteristics can express patterns such as transitivity or one-value restrictions. These mechanisms are the concrete forms of symbolic support that this chapter introduces; the detailed examples appear later.

Hallucination as generation, not verification

The speaker describes hallucination as a consequence—or, rhetorically, a feature—of probabilistic generation. He compares it with people imagining things that do not yet exist and then turning those ideas into reality. In that framing, the same generative ability that can produce an unsupported statement can also help produce a new idea or plan.

That framing should not be misunderstood. Calling hallucination a feature does not mean that every unsupported output is acceptable. It identifies the model's imaginative behavior. A separate checking process is still needed when the output must agree with a domain or when it may trigger an action.

For example, an LLM might generate a plausible-looking step in a business workflow. Text alone may make the step sound reasonable. A domain ontology can represent the relevant roles, relationships, and restrictions, giving the system a way to ask whether the step is valid in that domain. If it is not, the agent has a basis for checking or revising it instead of accepting fluent language as proof.

This example is a teaching illustration of the proposed mechanism, not a specific scenario stated by the speaker. The source's claim is broader: formal ontologies and symbolic systems can help keep probabilistic LLM behavior within domain-aware guardrails.

The key implication

The talk is proposing a convergence rather than a victory of one approach over the other:

  • Neural generation supplies flexibility. It can interpret varied requests and propose language or actions.
  • Symbolic representation supplies explicit domain structure. It can state what concepts and relationships mean.
  • Rules and reasoners supply checks. They can derive information or detect that a proposal conflicts with the model.

The resulting system remains probabilistic at its generative center. Its dependability is expected to improve because the agent is not left to treat its own most likely continuation as the final authority. The next sections show how an ontology becomes a graph and how RDFS and OWL add the formal behavior needed for validation.

100% Space + drag to pan | Ctrl/Cmd + wheel to zoom