Amsafis Wiki

Machine Learning · Generative AI (RAG-LLM) · Expert Systems

How they differ, how they interact, and why all three matter in high-stakes decision support.

Modern AI is not a single technology.

At amsafis, decision-support systems combine three distinct forms of Artificial Intelligence, each with a different logic, different strengths and different operational requirements:

1. Machine Learning (ML) — learns predictive patterns from data.
2. Generative AI with RAG (Retrieval-Augmented Generation) — interprets unstructured documents and provides natural-language reasoning grounded in evidence.
3. Expert Systems (ES) — implement transparent, auditable rules for safety-critical or regulated logic.

Each of these is an AI in its own right. None replaces the others.

Together, they form a closed loop:

data → prediction → rules → evidence → decision

Machine Learning extracts patterns, interactions and signals from structured datasets—typically spreadsheet-like tables, not images, audio or video.

amsafis specialises precisely in this domain: numeric or well-coded variables, possibly sparse, noisy or heterogeneous.

ML requires a dataset from which to learn. In real practice:

• rows = cases (patients, assets, events, transactions)
• columns = variables (numeric, ordinal, coded categorical)
• optional time dimension = functional or longitudinal data

At amsafis, ML does not involve:

• image learning
• audio learning
• computer vision
• raw text embedding without structure

(These domains belong to deep-learning specialisations outside the scope of the consultancy.)

Many ML workflows include classical statistical testing:

• chi-square
• t-tests, F-tests
• Fisher exact test
• likelihood ratio tests

These are useful for scientific validation, but not strictly required for integrating new knowledge into:

• Generative AI systems (RAG-LLM)
• Expert Systems

For these two pillars, descriptive statistics often suffice:

• frequencies and cross-tabs
• means, SD, quantiles
• simple associations

If an organisation already has BI tools (Power BI, Tableau, SQL analytics, ERP reports), these descriptive results can be used immediately to feed:

• a rule-based model, or
• a RAG repository

without requiring a full inferential modelling project.

This avoids unnecessary delays and makes AI adoption practical even with modest internal analytics resources.

They can be computed not only from full datasets, but sometimes from summary statistics (SSD):

• number of cases
• means and SD
• correlations
• covariance matrix

This enables:

• linear regression
• mediation
• SEM (structural equation models)
• PLS (partial least squares)

It allows modelling without sharing raw datasets.

But SSD can only encode linear relationships—everything is summarised. SSD cannot retain:

• non-linear interactions
• heterogeneity
• thresholds
• local effects
• latent clusters

To detect these phenomena you must use the full dataset.

This is where modern ML excels:

• additive models
• tree-based models
• kernel methods
• functional data analysis
• hybrid mechanistic-statistical models

SSD cannot express non-linearity. Therefore:

• linear ≠ enough
• linear ≠ realistic for biological, operational or industrial data
• linear ≠ future-proof

ML results are inputs to other components:

• Expert Systems

Rules can incorporate ML-derived thresholds, clusters or risk categories.

• RAG-LLM

ML results can be documented and fed to the evidence repository.

• Optimisation (not AI)

If needed, ML outputs can be used in mathematical optimisation (e.g., linear programming). An Expert System can also call optimisation logic internally.

Generative AI is the most recent AI paradigm, widely known since the release of ChatGPT. Unlike ML and ES, it uses language modelling rather than structured data or explicit rules.

But LLMs are not inherently reliable. They require grounding.

This is why amsafis uses RAG as the mandatory architecture:

• retrieve documents or fragments
• supply them to the model
• generate answers explicitly tied to evidence

• Uses cloud LLMs (OpenAI, Anthropic, etc.)
• Low cost
• Minimal infrastructure
• Adequate for public-information chatbots, manuals, product information, etc.

Required when documents cannot leave the premises (healthcare, regulated industry, R&D).

This requires:

• local hardware (GPU)
• local LLM model (Mistral-7B, Llama-3 8B…)
• local retrieval index
• local knowledge base

The model:

• does not need universal knowledge
• does not contact external servers
• can run offline
• only needs enough capacity to interpret the company’s own documents

If a company is not in aerospace, the model never needs to know anything about the solar system. Its value lies in RAG, not in encyclopedic knowledge.

A good RAG system depends on two delicate components:

1. User prompts — how the end-user formulates the question
2. Written knowledge — how the organisation writes and structures documents

These must *match*.

At amsafis, the knowledge base is reviewed manually before indexing to prevent:

• ambiguous definitions
• overlapping rules
• unintended interpretations
• lexical traps that produce hallucinations

This is equivalent to *prompt engineering on the data side*.

Expert Systems are the first branch of AI formally established as such, and they remain irreplaceable in safety-critical environments.

They execute explicit logic, not statistical inference and not neural-language reasoning.

They can handle:

• hundreds of rules
• multi-step logic
• exceptions
• safety conditions
• protocol enforcement
• reasoning that would overwhelm humans

A clinician, engineer or operator may suspect a specific inference path. An Expert System can be programmed to produce:

• confirmation
• counterexamples
• traceable explanations

This provides an audit trail that RAG-LLMs cannot guarantee.

Expert Systems can:

• read large datasets (thousands of rows)
• apply rules to each case
• generate flags, alerts, categories

These records are not rules themselves. They are evaluated by rules.

• ML produces quantitative patterns → ES can incorporate them as rule thresholds or decision nodes.
• RAG produces narrative knowledge → ES can use it as domain descriptions or contextual constraints.
• ES produces systematised logic → RAG can cite it; ML can be used to test it.

This closes the loop between the three AIs.

Amsafis has developed an executable knowledge layer that enables direct and operational consultation of expert models.

It is not a chatbot nor a generative AI application. It is a service that exposes formalized knowledge so it can be used by:

• people (manual use)
• scripts and integrations
• enterprise software
• future automation systems or agents

The objective is to transform expert knowledge into an executable, traceable, and reusable tool.

In addition to the manual use available through the website, the service can be tested by executing commands from free tools such as:

• Git Bash
• Visual Studio Code (integrated terminal)

(Other consoles may work, but syntax may vary.)

These tools allow direct queries to be sent to the knowledge engine.

curl -X POST https://diseases-non-interactive.amsafis.com/mcp/dispatch \
 -H "Content-Type: application/json" \
 -d "{\"task\":\"diagnose\",\"payload\":{\"symptoms\":[\"Myopia\"]}}"

curl -X POST https://diseases-non-interactive.amsafis.com/mcp/dispatch \
 -H "Content-Type: application/json" \
 -d "{\"task\":\"intersect\",\"payload\":{\"disease_a\":\"biotinidase_deficiency\",\"disease_b\":\"holocarboxylase_synthetase_deficiency\"}}"

curl -X POST https://diseases-non-interactive.amsafis.com/mcp/dispatch \
 -H "Content-Type: application/json" \
 -d "{\"task\":\"review\",\"payload\":{\"disease\":\"biotinidase_deficiency\"}}"

This environment constitutes a Knowledge Tool Provider: a reusable component that can be integrated into more complex architectures without losing model transparency or knowledge governance.

The previous section shows how a knowledge service can be accessed programmatically using a simple curl request based on the Model Context Protocol (MCP).

This is not only a technical detail. It defines how different AI components can be connected and executed as interoperable services.

An Agent builds on this capability.

Rather than calling a single service, an Agent:

• interprets a request,
• selects the appropriate components,
• and coordinates their execution through structured interactions such as MCP calls.

In this context, the Model Context Protocol (MCP) provides a standardized way to exchange structured inputs and outputs between components, enabling:

• reproducible execution,
• traceable interactions,
• and integration across heterogeneous systems.

An Agent may combine:

• Expert Systems (rule-based reasoning),
• Machine Learning models (prediction),
• and LLMs (interpretation and generation),

using MCP as the communication layer between them.

This transforms isolated capabilities into a coherent execution flow, where each component contributes to the final result.

For example:

• an LLM can interpret a clinical description,
• map it into structured concepts,
• trigger a knowledge service through an MCP request,
• and integrate the response into a final output.

This is not a new AI pillar.

It is a way to operationalize the integration described in the previous sections.

In practice, each Agent is designed for a specific use case, with different levels of complexity:

• simple pipelines with minimal orchestration,
• or multi-step processes combining reasoning, prediction, and knowledge retrieval.

This approach enables the transition from:

• isolated tools

to

• integrated, executable decision systems.