When I say “non-neural AI,” I mean that the system can function at every stage without neural networks.
Oh. I see. If that mean neural networks are allowed during development, that opens up quite a few more options. These are only a few examples, but for instance:
A practical distinction could be:
Neural systems may help discover, generate, organize, or test the runtime artifacts, but the deployed system must still operate without neural networks.
Under that definition, the development process could use an LLM as an annotator, hypothesis generator, program author, test generator, or black-box teacher. The deployed artifacts could then be ordinary rules, classical statistical models, finite-state machines, probability tables, symbolic programs, decision tables, or lookup tables.
This would not automatically transfer the full open-domain ability of an LLM into a compact symbolic system. However, it could substantially reduce the human effort required to construct a narrower non-neural system.
The most defensible current pattern seems to be:
human defines the domain and formal interfaces
→ neural tools propose many candidate artifacts
→ independent tools execute, verify, compare, and compress them
→ only accepted non-neural artifacts are deployed
→ the completed runtime is tested with every neural dependency removed
This is different from simply asking an LLM for a set of rules and trusting the answer. In one study of inductive rule learning, language models were strong at proposing plausible hypotheses, but much less reliable at consistently applying those hypotheses. Performance improved when a task-specific symbolic interpreter systematically filtered the proposed rules. That suggests a useful division of labor: use the model as a broad hypothesis generator and another system as the judge. See Qiu et al., “Phenomenal Yet Puzzling”.
A rough decision tree would be:
Can the generated artifact be checked mechanically?
├─ Yes
│ ├─ rule, regular expression, grammar
│ ├─ program, workflow, query, planning domain
│ └─ automaton or state machine
│ → generate candidates and use execution, tests, solvers,
│ type checkers, or model checkers to reject bad ones
└─ No
├─ semantic label
├─ natural-language judgment
└─ response-quality judgment
→ use independent human-reviewed data or another gold standard
Is the target a bounded prediction problem?
├─ Yes
│ └─ generate annotations, then train a classical model
└─ No
Is the relevant behavior mostly sequential or finite-state?
├─ Yes
│ └─ extract or learn a DFA, weighted automaton, HMM,
│ transition matrix, or probabilistic policy
└─ No
Are there already many related symbolic solutions?
├─ Yes
│ └─ find repeated structures and build a compressed reusable library
└─ No
Is the target broad open-domain understanding and fluency?
├─ Yes
│ └─ compact and faithful non-neural distillation is not established
└─ No
└─ domain-specific compilation is much more realistic
My default route would therefore be:
- Define a small symbolic language for the runtime artifacts.
- Let development-time neural tools generate examples and candidates in that language.
- Make every candidate executable or otherwise testable whenever possible.
- Reject candidates using independent tests, counterexamples, and formal checks.
- merge repeated or behaviorally similar artifacts;
- compile the result into a compact non-neural runtime;
- disconnect all neural services and run a cold end-to-end evaluation.
The target does not need to be one monolithic “distilled LLM.” It may be more effective to distill different bounded functions into different representations:
| Function |
Possible deployed artifact |
| Intent or dialogue-act recognition |
SVM, logistic regression, decision tree, rule list |
| Entity or slot extraction |
CRF, finite-state transducer, grammar |
| Dialogue progression |
State machine or probabilistic transition matrix |
| Tool selection |
Decision table, rule list, classical classifier |
| Multi-step action |
Symbolic program, workflow, planner |
| Repeated reasoning pattern |
Reusable symbolic function or library primitive |
| Sequential probability |
HMM or weighted finite automaton |
| Known finite mappings |
LUT, perfect hash, decision tree |
| Response realization |
Templates, grammar, deterministic surface realizer |
| Knowledge candidates |
Versioned symbolic records with source and confidence |
The important part would be to keep the meaning of each artifact explicit. A compact state transition table is useful only if the states themselves still preserve distinctions needed by the task.
1. Generating annotations and training classical non-neural models
One relatively mature option is to use an LLM to help create a labeled dataset, then train a conventional non-neural student.
For example, the development system could generate or label:
- intents;
- dialogue acts;
- slots and entity spans;
- semantic-form candidates;
- paraphrases;
- negative examples;
- ambiguous examples;
- tool-selection examples;
- error categories;
- clarification cases.
The final runtime learner might be:
- logistic regression;
- an SVM;
- a CRF;
- an HMM;
- a decision tree;
- gradient-boosted trees;
- a sparse rule list;
- a probabilistic grammar.
Alfred is an example of prompted weak supervision. It lets users express weak-supervision sources through natural-language prompts, maps their outputs to weak labels, and combines disagreeing sources with a label model.
This route is relatively practical when the output space is already well defined. For example:
refund_request
product_compatibility_question
account_access_problem
is a bounded label space. It is much easier to transfer this decision than to transfer unrestricted natural-language understanding.
A useful pipeline would be:
human defines labels and edge cases
→ LLM generates or weakly labels examples
→ human reviews a stratified sample
→ classical model is trained
→ evaluation uses a separately created holdout set
→ uncertain inputs cause clarification or abstention
The independent holdout is important. If the teacher labels both training and evaluation data, a student can appear successful merely by reproducing the teacher’s biases.
It would also help to compare at least three quantities:
- agreement with the neural teacher;
- agreement with independently checked gold labels;
- performance relative to a manually written or classical baseline.
Teacher agreement and correctness are not the same measurement.
2. Generating rules, grammars, and symbolic programs
If an output can be executed, compiled, or checked, neural generation becomes more useful because incorrect candidates can be rejected mechanically.
Possible generated artifacts include:
- regular expressions;
- finite-state grammar rules;
- semantic parsing rules;
- production rules;
- SQL queries;
- logic programs;
- action schemas;
- PDDL domains;
- workflows;
- small deterministic programs;
- response-planning rules.
A simple workflow could be:
examples and specification
→ LLM proposes 100 candidate rules
→ parser rejects invalid syntax
→ type checker rejects invalid interfaces
→ interpreter runs candidates on tests
→ solver searches for counterexamples
→ redundant candidates are removed
→ accepted rules become part of the runtime
This resembles counterexample-guided inductive synthesis, often abbreviated CEGIS.
In a CEGIS loop:
candidate
→ verifier
├─ valid → accept
└─ invalid → return a counterexample
→ refine the next candidate
A study combining LLM generation with an SMT solver used counterexamples from the solver to iteratively improve planning artifacts: Jha et al., “Neuro Symbolic Reasoning for Planning”.
This does not mean that arbitrary generated programs become safe automatically. The strength of the result depends on the specification.
If the specification only contains ten examples, the generated program may merely fit those ten examples. If the specification includes types, invariants, preconditions, postconditions, forbidden states, and exhaustive finite cases, the verifier can provide much stronger evidence.
The ideal role split is therefore:
LLM:
- searches broadly;
- proposes unusual candidates;
- translates between natural language and the DSL;
- produces test and counterexample suggestions.
Formal or classical tools:
- define what acceptance means;
- execute candidates;
- prove bounded properties;
- reject contradictions;
- produce concrete failure cases.
For a beginner-friendly implementation, this could start without SMT solving. A strict parser, a small interpreter, and a comprehensive test table would already provide the same basic architecture.
3. Learning reusable symbolic libraries rather than accumulating rules forever
A particularly relevant research direction is library learning.
Suppose development-time tools generate hundreds or thousands of symbolic programs or rules. Many will contain repeated structures.
Instead of deploying all of them independently, a library-learning system can search for common subprograms and replace them with reusable abstractions.
Conceptually:
program 1: normalize name → find account → check status → answer
program 2: normalize name → find account → check plan → answer
program 3: normalize name → find account → open ticket
could become:
resolve_account(name):
normalize name
find account
followed by smaller task-specific programs.
DreamCoder alternates between solving tasks as programs and extending its symbolic language with reusable abstractions. A neural component guides program search, but the learned concepts themselves are compositional symbolic programs.
Stitch focuses directly on extracting reusable abstractions from a corpus of programs. It searches for functions that capture common structure and then rewrites the original programs using the learned library.
LILO combines LLM-guided program synthesis, Stitch-style symbolic compression, and automatic documentation. It repeatedly synthesizes programs, compresses them into reusable functions, and gives those functions readable names and descriptions.
These are limited program-synthesis settings, not general conversational-AI distillation. However, they provide a concrete answer to an important engineering problem:
How can a system prevent a large collection of generated symbolic solutions from becoming an unmaintainable pile of almost-duplicate rules?
A development architecture could therefore be:
LLM generates task-specific symbolic programs
→ programs are tested
→ accepted programs enter a corpus
→ library learner finds repeated structures
→ reusable abstractions are added to the DSL
→ old programs are rewritten using the abstractions
→ the new compact library becomes the next generation target
This can produce more than compression. The discovered abstractions may become the system’s higher-level vocabulary.
For example, many low-level rules involving product lookup, version comparison, and support dates might eventually be compressed into a reusable operation such as:
support_status(product, version, date)
The caution is that syntactic repetition is not always semantic equivalence. Two fragments may look similar while differing in an important side effect or exception. Library candidates should therefore be tested against both existing examples and deliberately generated counterexamples.
4. Extracting finite-state and probabilistic behavior
Your intention to use probabilistic systems makes this branch especially relevant.
Some behavior may be represented as:
- a deterministic finite automaton;
- a probabilistic finite-state machine;
- a hidden Markov model;
- a weighted finite automaton;
- a dialogue-state transition matrix;
- an action-selection probability table;
- a probabilistic grammar.
For example, a bounded dialogue manager might contain states such as:
waiting_for_product
waiting_for_version
checking_policy
ready_to_act
tool_failed
completed
Development-time neural systems could generate dialogues or propose state assignments. A classical learner could then estimate:
P(next_state | current_state, observed_dialogue_act)
P(action | current_state, known_slots)
P(clarify | ambiguity_type, current_state)
There is also a more direct black-box extraction literature.
Weighted-automaton extraction has been used to approximate sequential black-box models by querying their inputs and observing numerical outputs, without requiring access to the original training data or internal representation.
Other work studies extracting a weighted automaton of a chosen size, allowing an explicit tradeoff between model size and approximation quality. This is useful when a full extracted automaton would be too large to inspect or run efficiently.
A recent and especially relevant example is Ctrl-G, which distills an HMM approximation from an LLM and combines it with deterministic finite automata representing logical constraints.
However, Ctrl-G does not replace the complete LLM with the HMM. The LLM still provides the main text-generation distribution; the HMM makes future constraint probabilities tractable.
It therefore demonstrates:
useful portions of an LLM’s sequential probability behavior can be approximated by a non-neural probabilistic model;
but not:
an HMM currently reproduces the complete meaning, reasoning, and fluency of a general LLM.
The central difficulty is usually not estimating a transition matrix after the states are known. The difficult question is deciding which histories may safely be merged into the same state.
If the states are too broad, important context is lost. If they are too specific, the state space and matrices become enormous.
A practical compromise is to define semantically meaningful states manually, then learn only the transition and output probabilities.
For example:
human-defined state:
waiting_for_version
observed events:
version_provided
product_changed
ambiguous_number
user_cancelled
learned probabilities:
transition or clarification policy
This is less ambitious than automatically discovering the complete latent state of a language model, but much easier to inspect and maintain.
5. Symbolic knowledge distillation
Another possible use of development-time LLMs is generating a symbolic knowledge resource.
Possible outputs include:
- knowledge-graph edges;
- ontology candidates;
- commonsense relations;
- typed claims;
- rule candidates;
- schema mappings;
- entity aliases;
- questions and answers grounded in a document set.
Symbolic Knowledge Distillation used a general language model to author a large symbolic commonsense resource based on ATOMIC, with filtering used to select higher-quality generations.
This demonstrates that a neural teacher can help construct a symbolic corpus.
It does not mean every generated symbolic statement is true.
For a conversational runtime, the generated knowledge should still pass through an admission process such as:
generated candidate
→ source or evidence check
→ schema and type validation
→ attribution, time, and negation checks
→ duplicate and conflict detection
→ accepted / quarantined / rejected
The source of a generated claim should also be distinguishable:
directly extracted from source document
inferred by symbolic rule
proposed by neural development tool
approved by human reviewer
Otherwise a later user may see a symbolic triple without knowing whether it came from a document, a derivation, or a teacher model’s prior knowledge.
The most conservative use would be to let the neural system propose:
- possible ontology links;
- aliases;
- extraction patterns;
- candidate rules;
- likely missing tests;
while keeping factual admission dependent on the original documents or independent review.
6. Rule merging, decision tables, LUTs, and approximate compression
Once many rules exist, a separate rule compiler could simplify them before deployment.
A possible compilation process is:
candidate rules
→ canonical representation
→ remove exact duplicates
→ remove unreachable rules
→ detect logical equivalence
→ detect subsumption
→ measure behavior on probe inputs
→ cluster behaviorally similar rules
→ synthesize generalized or parameterized rules
→ test the compressed rule base
→ deploy
The first part can be exact.
For example:
A and B → X
A and not B → X
can sometimes be simplified to:
A → X
without changing behavior.
The later part may be approximate.
For example:
premium and purchase_age < 28 → refund
premium and purchase_age < 30 → refund
premium and purchase_age < 31 → refund
might be replaced by one parameterized rule if the small difference is acceptable for the intended task.
A useful objective could informally balance:
prediction error
+ number of rules
+ total rule length
+ runtime cost
+ maintenance cost
CORELS is one example of optimizing sparse rule lists using a regularized objective that trades predictive performance against rule-list complexity.
This does not directly merge arbitrary dialogue rules, but it establishes that bounded rule systems can be optimized explicitly for both accuracy and simplicity.
Decision tables and LUTs are also valid deployed representations.
They are particularly suitable for:
- token normalization;
- finite grammar actions;
- dialogue transitions;
- operator dispatch;
- tool selection in a bounded state space;
- validation codes;
- error-to-recovery mappings;
- policy-version selection;
- frequent query results;
- response-template selection.
A development-time decision table can be useful even if a compiler would eventually generate a table automatically. It gives developers a visible place to inspect:
- missing combinations;
- conflicting outcomes;
- unreachable rows;
- exceptions;
- version differences;
- generated-rule coverage.
A practical runtime need not use one enormous dense table. It may use a mixture of:
small dense LUTs
sparse hash tables
tries
decision trees
finite automata
default rule + exception table
memoized symbolic results
The main limitation is combinatorial explosion.
If a table key includes:
utterance category
dialogue state
user attributes
document version
time
tool availability
previous tool result
the full Cartesian product may be too large.
It is therefore more realistic to use many local tables at well-defined component boundaries than one universal table for the entire conversation.
Approximate compression should also be separated from exact compression.
Exact:
- duplicates;
- equivalences;
- unreachable branches;
- dominated rules.
Approximate:
- merged thresholds;
- removed rare exceptions;
- clustered states;
- low-rank probability tables;
- generalized behaviors.
Exact transformations can often be accepted automatically.
Approximate transformations should be evaluated on:
- ordinary holdout examples;
- rare but important exceptions;
- action-safety tests;
- ambiguity tests;
- update and rollback tests.
7. A concrete development pipeline
A small initial project could use:
- one language;
- one bounded support or policy domain;
- a versioned collection of 8–12 documents;
- three tools;
- perhaps 8–20 dialogue states;
- an explicit semantic schema;
- a small rule or program DSL.
Example tools:
check_product_version(product, version)
check_policy(policy, customer_type, date)
create_ticket(product, issue, contact)
Phase 1: define the runtime contracts manually
utterance
→ semantic form
→ dialogue state
→ accepted claims
→ conclusion or plan
→ action
→ response plan
Define each intermediate format before generating a large amount of data.
Phase 2: use neural tools for data creation
Generate:
- paraphrases;
- ambiguous requests;
- slot labels;
- semantic-form candidates;
- dialogue examples;
- tool-call examples;
- negative and boundary cases.
Review a sample and train classical components where appropriate.
Phase 3: generate executable symbolic candidates
Generate:
- parsing rules;
- policy rules;
- clarification rules;
- action programs;
- knowledge-admission rules;
- response plans.
Run them in a sandboxed interpreter.
Phase 4: use counterexamples
Whenever a candidate fails, store:
input
expected result
actual result
component responsible
candidate version
Feed the counterexample into the next synthesis or repair iteration.
Phase 5: learn abstractions
When the accepted program corpus becomes large:
- find repeated subprograms;
- create reusable library functions;
- rewrite old programs;
- rerun regression tests.
Phase 6: compile
Convert readable authoring representations into suitable runtime forms:
rules → decision tree or indexed rule engine
state transitions → table or automaton
probabilistic policy → sparse matrix
finite mappings → LUT
program library → frozen interpreter or compiled code
response plans → templates or grammar
Phase 7: perform a cold-runtime test
Remove or block:
- all teacher APIs;
- neural model weights;
- embedding services;
- neural rerankers;
- neural critics;
- online neural fallback;
- cached neural outputs not declared as runtime data.
Then run the complete test suite from a clean environment.
This verifies the deployment claim:
the system can function at every stage without neural networks.
It may still be historically true that neural systems helped create its rules or resources, but the runtime dependency is independently testable.
8. Evaluation controls
Several measurements should be kept separate.
Teacher fidelity
How often does the deployed system reproduce the neural teacher?
This measures behavioral imitation.
Independent correctness
How often does it match human-reviewed or otherwise independent expected results?
This measures whether the imitation is actually useful.
Task performance
Can it complete the full task over multiple turns, including actions and recovery?
This measures the integrated system.
Compression
How much was the generated artifact reduced?
Possible measurements:
- number of rules;
- total rule length;
- number of states;
- nonzero matrix entries;
- library size;
- executable size;
- memory;
- latency.
Maintenance
How much work is required to:
- add a new capability;
- correct one error;
- update one source;
- modify a schema;
- replace the teacher;
- retrain or recompile after a change?
Important controls
Independent holdout
Do not let the same teacher generate all training data and all expected answers.
Distribution shift
Test paraphrases, entities, and combinations not used during generation.
Rare exceptions
Give critical exceptions more weight than ordinary examples.
A small average error may still be unacceptable if all failures occur on tool execution or policy exceptions.
Ambiguity
Test whether the system asks for clarification instead of confidently following a compressed but incorrect rule.
Knowledge update
Change one source fact and verify that only dependent conclusions change.
Action failure
Make one tool fail and verify that the system does not fabricate success.
Ablation
Compare:
manual artifacts only
neural-generated artifacts before compression
after exact compression
after approximate compression
This reveals whether the neural generation and compression steps actually improve the system.
Full provenance
For each deployed artifact, record:
how it was proposed
which tests accepted it
which source examples support it
which compiler produced it
which version is deployed
This is especially useful if a generated rule later produces an unexpected result.
9. What appears mature, conditional, or still open
Relatively mature for bounded tasks
- neural-assisted annotation;
- weak supervision;
- training classical classifiers from teacher-generated labels;
- executable rule and program generation with testing;
- finite-state extraction for restricted sequential behavior;
- exact duplicate and subsumption removal;
- decision-table and LUT compilation;
- symbolic program library learning in constrained DSLs.
Demonstrated, but dependent on strong assumptions
- extracting weighted automata from black-box sequential models;
- HMM approximations of portions of LLM sequence behavior;
- LLM-guided formal synthesis with solver feedback;
- generating symbolic knowledge resources;
- approximate rule compression;
- automatically discovering reusable abstractions from program corpora.
Still broadly open
- faithfully transferring general open-domain semantics into a compact symbolic representation;
- discovering all of the right conversational states automatically;
- preserving rare but important behavior while aggressively compressing a large teacher;
- transferring broad social and linguistic fluency into templates, rules, or finite-state systems;
- jointly compressing parsing, dialogue, knowledge, reasoning, planning, tools, and generation into one general non-neural optimizer;
- guaranteeing equivalence outside the tested input distribution.
So the main practical opportunity is probably not to treat the LLM as a complete design that must somehow be copied neuron by neuron.
It is to treat it as a development-time search system that can produce:
- candidate data;
- candidate rules;
- candidate programs;
- candidate abstractions;
- candidate states;
- candidate tests.
The non-neural development tools can then turn those proposals into a smaller collection of verified and reusable runtime artifacts.
For your architecture, the most promising branch may depend on what your existing “natural language processing structures” already look like:
- If they already use explicit rules or a DSL, rule/program generation plus verification and library learning may fit naturally.
- If they use a bounded dialogue-state model, probabilistic transition matrices or automata extraction may fit.
- If they mainly classify intents or extract fields, weak supervision followed by a classical learner may be enough.
- If the main target is broad unrestricted fluency, that remains the least established part of this development-time distillation route.
The default recommendation would be:
define a small inspectable runtime language first, let neural tools generate many candidates inside that language, and invest more effort in the verifier, compression process, and independent tests than in any single generation prompt.
That would preserve the requirement of a fully non-neural runtime while making substantially more development strategies available.