Démonstration du service de règles métiers sur bluemix (business rules service)

1. © 2015 IBM Corporation
Rules in Artificial Intelligence
Nov 2015
Pierre Feillet – Decision automation architect

2. © 2015 IBM Corporation
Agenda
2
 Origins
 Expert System -> Inference Engine -> Rules
 Current state
 From raw inference engine to Entreprise decision automation
 Business Rules in Bluemix
 Perspectives

3. © 2015 IBM Corporation
RULES TO MIMIC HUMAN MIND
From Expert Systems to Operation Decision Management

4. © 2015 IBM Corporation
Expert Systems
4
 An expert system is a computer system that emulates the decision-making ability of a human
expert. Expert systems are designed to solve complex problems by reasoning about
knowledge, represented primarily as if–then rules rather than through conventional procedural
code.
 The first expert systems were created in the 1970s and then proliferated in the 1980s. Expert
systems were among the first truly successful forms of AI software. Expert systems were
introduced by the Stanford Heuristic Programming Project. Applied to domains where
expertise was highly valued and complex, such as diagnosing infectious diseases (Mycin).
 The typical expert system consisted of a knowledge base and an inference engine.
 The knowledge base stored facts about the world.
 The inference engine applied logical rules to the knowledge base and deduced new
knowledge. This process would iterate as each new fact in the knowledge base could trigger
additional rules in the inference engine.

5. © 2015 IBM Corporation
Rules as expertise programming model
5
 The logic that an inference engine uses is typically represented as IF-THEN rules.
 The general format of such rules is IF <logical expression> THEN <logical expression>.
 Prior to the development of expert systems and inference engines artificial intelligence
researchers focused on more powerful theorem prover environments that offered much fuller
implementations of First Order Logic. For example, general statements that included universal
quantification (for all X some statement is true) and existential quantification (there exists
some X such that some statement is true).
 What researchers discovered is that the power of these theorem proving environments was
also their drawback. It was far too easy to create logical expressions that could take an
indeterminate or even infinite time to terminate.
 Focusing on IF-THEN statements (what logicians call Modus Ponens) still gave developers a
very powerful general mechanism to represent logic but one that could be used efficiently with
computational resources. What is more there is some psychological research that indicates
humans also tend to favor IF-THEN representations when storing complex knowledge.

6. © 2015 IBM Corporation
Rule Logic
6
 A simple example of Modus Ponens often used in introductory logic books is "If you are
human then you are mortal". This can be represented in pseudocode as:
Rule1: Human(x) => Mortal(x)
 2 primarly modes: forward chaining and backward chaining.
 Forward chaining starts with the known facts and asserts new facts.
Ex: Socrate is Human so he is mortal
 Backward chaining starts with goals, and works backward to determine what facts must be
asserted so that the goals can be achieved.
 Ex: Is Socrate mortal? It would search through the knowledge base and determine if
Socrates was Human and if so would assert he is also Mortal.
 Backward chaining can include a common technique was to integrate the inference engine
with a user interface to ask questions when facts are not enough and would then use that
information accordingly.
 This innovation of integrating the inference engine with a user interface led to the second
early advancement of expert systems: explanation capabilities. At first these explanations
were not much different than the standard debugging information that developers deal with
when debugging any system. However, an active area of research was utilizing natural
language technology to ask, understand, and generate questions and explanations using

7. © 2015 IBM Corporation
Rule Logic
7
 An inference engine cycles through three sequential steps: match rules, select rules, and
execute rules. The execution of the rules will often result in new facts or goals being added
to the knowledge base which will trigger the cycle to repeat. This cycle continues until no
new rules can be matched.
 In the first step, match rules, the inference engine finds all of the rules that are triggered by
the current contents of the knowledge base. In forward chaining the engine looks for rules
where the antecedent (left hand side) matches some fact in the knowledge base. In
backward chaining the engine looks for antecedents that can satisfy one of the current
goals.
 In the second step select rules, the inference engine prioritizes the various rules that were
matched to determine the order to execute them.
 In the final step, execute rules, the engine executes each matched rule in the order
determined in step two and then iterates back to step one again. The cycle continues until
no new rules are matched.
 Rule engine algorithms
 RETE, sequential, IBM Fastpath, etc
 Stateless & stateful processing

8. © 2015 IBM Corporation
From Expert Systems to Operational Decision Management
8
 Goal: Empower Business Users to author,
test, simulate, deploy their decision logic
 Bring a Business Model on the top of Java,
XML, JSON, COBOL, etc
 Add high level rule artifacts: Decision Table
& Trees
 Provide near natural language DSLs with
editors to write your rules in your preferred
locale: Chinese, English
 Integrate the rule engine into a server to
scale, and hot deploy ruleset in a 24/7
manner
 Trace decisions for auditability
 Cloud
 PaaS & SaaS
Rule
engine
Business
Model
Localized
Business
Languages
Decision
warehouse
Decision
Server
Testing &
Simulation
Business
Rules
Tools Cloud

9. © 2015 IBM Corporation
IBM BUSINESS RULES
Business rules as a service in IBM Bluemix

10. © 2015 IBM Corporation
Your Application
Externalize Decisions from Applications into Business Rules
Manage decision logic independently from applications
Your Application
Decision logic
 Natural language rules can be easily read
 Externalized rules are easy to change
 Centralized rules enable reuse and
consistency
 Rules written in software code cannot be
read easily
 Hard coded rules are difficult to change
 Rules intertwined within applications
cannot be reused by other systems
Business Rules

11. © 2015 IBM Corporation
IBM Business Rules, a Smarter Process high value service
Familiar Environment for Authoring
Developers can download an Eclipse
based authoring tool and author rules in a
familiar user-friendly environment.
Separate Business Logic
Business logic is authored separately from
the application which enables easier
change in business policy / logic and
codified capture of business policies,
practices and regulations..
Business logic is easily expressed with
business rules to automate decisions with
the fidelity of a subject matter expert.
Bridge Business Users and Developers
Deploy Versioned Business Logic
Multiple versions of the Business logic can
be tested and deployed in the same
Business Rules Service. Switching,
upgrading, sharing business logic across
applications has never been easier.
Enables developers to spend less time recoding and testing when the
business policy changes. The Business Rules service minimizes your
code changes by keeping business logic separate from application logic.
Business Rules

12. © 2015 IBM Corporation
The Business Rules service simplifies the experience of creating and
managing mobile app business logic – making apps more adaptable
• Rules tied to mobile services like push or location enable advanced scenarios

13. © 2015 IBM Corporation
Developing and deploying applications using the Business Rules
service
IBM Bluemix
One
app
Another
app
Business Rules
service instance
Author business rules with Rule
Designer plug-ins for Eclipse
Deploy
business
rules
Develop and push app code
Call the
service
Users access
apps from their
devices
Non-Bluemix apps
can call the service
too
Call the service

14. © 2015 IBM Corporation
Perspectives
14
 Extending to event driven long term stateful situation detection
 Detect automatically risks & opportunity and operate decisions
 See IBM ODM Decision Server Insights
 Cloud
 Top down modelling, ootb connectivity for easy to consume cloud offerings
 IoT
 Functional coverage
 Improve explanation
 What if analysis
 Recycling of past decisions
 Measuring & optimizing decision fitness
 Rule mining
 Learn rules from past decisions & reasoning
 Combination of Predictive & Prescriptive analytics

15. © 2015 IBM Corporation
Wrap up
15
 Rules
 From 70s IA to today enterprise decision management
 Empower developers and business users to automate decision making
 Provides transparency and explanation
 Rules are based on Causality while Big Data & Machine Learning are based on correlation
 Try Business Rules in Bluemix https://console.ng.bluemix.net on London datacenter
Business Rules

16. © 2015 IBM Corporation
Q & A
16

17. © 2015 IBM Corporation
in your app
in Bluemix
in Eclipse
in Bluemix
Steps to author and deploy business rules
 Provision a Business Rules service
 Download the Rule Designer Eclipse plug-ins to author Business Rules
 Install the plug-ins
 Create a new Rule project
 Create the eXecution Object Model (XOM) from Java or XSD
 Define the Business Object Model (BOM) for rules
 Orchestrate and author the rules, decision tables
 Deploy your rule application to the Business Rules service
 Bind the Business Rules service to your application
 Call to the Business Rules service from your application code
The Rule Project Map guides you through all the authoring steps.