Ja tenim les tres eines simbòliques del mòdul: la lògica de 06-01 per representar coneixement, el sistema expert de 06-02 per decidir amb regles i les xarxes bayesianes de 06-03 per decidir amb incertesa. Aquesta lliçó les treu del laboratori de NovaMarket i les situa al món: on s'han fet servir i es fan servir els sistemes basats en regles i coneixement, quin coneixement codifiquen, per què en cada cas es trien regles i no aprenentatge automàtic (explicabilitat, normativa, poques dades) i on són els seus límits. Recorrerem la medicina, les finances, la indústria, l'agricultura, el dret i l'administració, l'educació i el comerç electrònic, i veurem en què s'han convertit avui els sistemes experts: motors de regles de negoci, taules de decisió DMN, grafs de coneixement i, sobretot, la combinació amb l'ML i els LLM que vam anunciar en tancar 05-05: l'enfocament neurosimbòlic. En codi construirem una taula de decisió per a l'encaminament de tiquets d'atenció al client de NovaMarket i un exemple neurosimbòlic executable en què un model estima la probabilitat de defecte i el motor de regles de 06-02 decideix, amb la banda de revisió humana de 02-04, si s'accepta la garantia automàticament o passa a una persona. És important perquè és la manera com les regles sobreviuen i prosperen en la IA actual: no competint amb les xarxes, sinó governant-les.
Contingut
- Panorama: on viuen els sistemes basats en regles
- Medicina: de MYCIN a les alertes clíniques
- Finances: scoring, compliment normatiu i regles de negoci
- Indústria i manteniment: diagnòstic i configuració
- Agricultura, dret i administració, educació
- Atenció al client i comerç electrònic: el cas de NovaMarket
- Taula resum: sector, sistema, coneixement i per què regles
- Els sistemes experts avui: BRMS, DMN, grafs de coneixement
- Neurosimbòlic: regles i models junts
- Codi: taula de decisió DMN per a l'encaminament de tiquets
- Codi: un exemple neurosimbòlic executable
- Errors Comuns i Consells
- Exercicis
- Conclusió
- Panorama: on viuen els sistemes basats en regles
Després de l'hivern de finals dels 80 (01-01), la paraula "sistema expert" va caure en desús, però la tecnologia no: es va rebatejar com a motor de regles de negoci, sistema de suport a la decisió o automatització de decisions, i es va integrar en el programari corporatiu. Avui hi ha regles explícites darrere de gairebé cada decisió repetitiva amb conseqüències reguladores: si un banc et concedeix una targeta, si una recepta dispara una alerta, si una declaració d'impostos s'accepta, si el teu tiquet de suport va a un equip o a un altre. La raó és la mateixa en tots els sectors i ja la coneixes del mòdul: quan la decisió la defineix una norma o una política, s'ha de justificar cas per cas, hi ha poques dades o els casos límit importen, les regles escrites guanyen el model après, o com a mínim l'acompanyen. Recorrem els sectors amb aquesta lent: quin coneixement es codifica, per què regles i quins límits tenen.
- Medicina: de MYCIN a les alertes clíniques
- MYCIN (06-02) no va arribar mai a la clínica, però els seus hereus sí: els sistemes de suport a la decisió clínica (CDSS) integrats a la història clínica electrònica. El més estès: les alertes d'interacció de fàrmacs i de dosi: regles del tipus "SI el pacient pren l'anticoagulant A I es prescriu l'antiinflamatori B ALESHORES alerta de risc de sagnat", amb milers de parells de fàrmacs, contraindicacions per al·lèrgia, ajustos per funció renal, i protocols clínics (guies de pràctica) codificats com a arbres de decisió.
- Coneixement codificat: farmacologia, guies clíniques, criteris diagnòstics; l'escriuen comitès d'experts i l'actualitzen amb l'evidència.
- Per què regles: la responsabilitat legal exigeix poder dir per què va saltar (o no) una alerta; les guies clíniques ja són regles; els esdeveniments greus són rars (poques dades per aprendre'ls); la regulació de dispositius mèdics exigeix validació i traçabilitat.
- Límits: fatiga d'alertes (massa alertes irrellevants que el metge acaba ignorant: el problema de la precisió de 04-05 en versió humana), manteniment de la base al ritme de l'evidència, i la incapacitat de les regles per al diagnòstic per imatge o la predicció de risc, on l'ML dels mòduls 4 i 5 domina. La combinació típica: un model estima el risc de sèpsia, una regla decideix quan i a qui avisar.
- Finances: scoring, compliment normatiu i regles de negoci
- Scoring per regles i polítiques de crèdit: "SI ingressos < X O antiguitat laboral < 6 mesos ALESHORES denegar"; avui conviuen amb models de risc, però les regles de política (edat mínima, llistes de morosos, límits reguladors) van abans i després del model.
- Compliment normatiu (compliance) i antiblanqueig (AML): regles de detecció d'operacions sospitoses exigides per la normativa (imports fraccionats just per sota del llindar de declaració, països de risc, patrons d'ingrés en efectiu), regles de coneixement del client (KYC) i de sancions. Es codifiquen literalment de la llei i de les circulars del regulador.
- Motors de regles de negoci per a tarifació d'assegurances, liquidació de comissions, elegibilitat de productes, gestió de sinistres senzills.
- Per què regles: la llei és una regla i el regulador pregunta "per què s'ha marcat aquesta operació?"; el dret a explicació de decisions de crèdit (RGPD, 02-04) exigeix motius llegibles; el frau canvia i les regles s'editen en hores sense reentrenar.
- Límits: els defraudadors aprenen les regles i les voregen; moltes falses alarmes; milers de regles acumulades amb interaccions que ningú no recorda (el mal de XCON). Per això els sistemes moderns combinen regles dures (normativa) amb models (patrons subtils) i amb la banda de revisió d'analistes.
- Indústria i manteniment: diagnòstic i configuració
- Configuració: XCON (06-02) configurava ordinadors; els seus descendents són els configuradors de producte (un cotxe amb les seves opcions compatibles, una màquina industrial, una tarifa de telecomunicacions), on les regles expressen restriccions "aquesta targeta necessita aquella font d'alimentació", un problema de satisfacció de restriccions (03-02) més que d'aprenentatge.
- Diagnòstic de fallades: arbres de decisió escrits per enginyers per a avaries de turbines, locomotores, línies de producció; els manuals de servei són sistemes experts en paper. Amb sensors, es combinen amb detecció d'anomalies (04-02) que dispara l'arbre de diagnòstic.
- Control de processos: control difús (06-03) en forns, cimenteres, climatització.
- Per què regles: el coneixement és al cap d'enginyers que es jubilen (conservació del coneixement); les fallades greus són escasses; en seguretat industrial cal poder certificar el comportament.
- Límits: cobertura incompleta de fallades noves; els arbres queden obsolets amb cada revisió de l'equip.
- Agricultura, dret i administració, educació
- Agricultura: sistemes d'assessorament de reg, fertilització i tractament de plagues ("SI humitat del sòl < X I previsió sense pluja ALESHORES regar N litres"), i de diagnòstic de malalties de cultius per símptomes visibles. Codifiquen agronomia i normativa d'ús de fitosanitaris; avui la part de percepció (fotos de fulles) la fa una CNN (05-04) i la part de recomanació continuen sent regles.
- Dret i administració: elegibilitat per a ajuts i prestacions, càlcul d'impostos, tramitació de llicències: la llei es codifica en regles i taules (els mateixos formularis de l'administració són arbres de decisió). Els assistents de tributació són sistemes experts gegantins que s'actualitzen amb cada llei de pressupostos. És el terreny on l'exigència d'explicació i d'igualtat de tracte és màxima i on una decisió automatitzada errònia té més conseqüències (02-04): les regles permeten auditar i recórrer; un model après d'expedients passats n'heretaria els biaixos. Com en les devolucions, la normativa la fixa i la revisa un professional legal; el sistema l'aplica.
- Educació: els tutors intel·ligents (des dels anys 80) modelen el coneixement de la matèria i les regles de producció que un estudiant aplica en resoldre un problema (per exemple, d'àlgebra), comparen els seus passos amb les regles correctes i les errònies conegudes, i adapten les pistes. Codifiquen pedagogia i errors típics; avui es combinen amb models de coneixement de l'estudiant i amb LLM per al diàleg.
- Atenció al client i comerç electrònic: el cas de NovaMarket
Aquí NovaMarket s'hi reconeix del tot:
- Motors de regles de promocions: "3x2 en càpsules", "enviament gratis a partir de 49 €", "cupó no acumulable amb rebaixes", exclusions per categoria; milers de botigues els executen a cada cistella. És lògica pura, amb conflictes entre promocions que es resolen per prioritat, exactament com a 06-02.
- Polítiques de devolució i garantia: el sistema expert del cas 8 que vam construir.
- Encaminament de tiquets: quin equip, amb quina prioritat i amb quines accions automàtiques atén cada incidència, en funció del tipus, l'import, el client i el canal (codi de la secció 10).
- Prevenció de frau: regles dures (més de N comandes a la mateixa adreça amb targetes diferents) davant i darrere del model de risc del cas 3.
- Assistents: el chatbot del cas 7 amb RAG (05-05) respon preguntes; però decidir una devolució ho delega al motor de regles, perquè un LLM no pot garantir que aplica la política.
- Per què regles: la política és de l'empresa i canvia amb el màrqueting i amb la llei; cada decisió cap al client s'ha de poder explicar; els casos límit (higiene obert, garantia ampliada) són pocs i no s'aprenen bé.
- Límits: el diagnòstic de causes (cas 9) no cap en regles nítides i necessita la xarxa de 06-03; la lectura de ressenyes i fotos necessita les xarxes del mòdul 5.
- Taula resum: sector, sistema, coneixement i per què regles
| Sector | Sistema típic | Coneixement codificat | Per què regles i no (només) ML | Límit principal |
|---|---|---|---|---|
| Medicina | Alertes d'interacció de fàrmacs, protocols (hereus de MYCIN) | Farmacologia, guies clíniques | Responsabilitat legal, esdeveniments rars, regulació de dispositius | Fatiga d'alertes, manteniment |
| Finances | Scoring per polítiques, AML, KYC, tarifació | Llei, circulars del regulador, política de risc | Dret a explicació, la norma és una regla, canvi ràpid | Els defraudadors voregen les regles; falses alarmes |
| Indústria | Configuradors (XCON), arbres de diagnòstic, control difús | Restriccions de producte, experiència d'enginyers | Conservar coneixement, fallades escasses, certificació | Fallades noves, obsolescència |
| Agricultura | Assessor de reg/tractaments, diagnòstic de plagues | Agronomia, normativa fitosanitària | Recomanacions justificables; la percepció la fa la CNN | Variabilitat local |
| Dret i administració | Elegibilitat, tributació, llicències | Legislació | Igualtat de tracte, recurs, auditoria; biaix d'expedients passats | Llei ambigua; volum de canvis |
| Educació | Tutors intel·ligents | Regles de la matèria i errors típics | Retroalimentació explicable pas a pas | Cobertura d'estratègies de l'alumne |
| Comerç electrònic | Promocions, devolucions (cas 8), encaminament de tiquets, antifrau | Política comercial, normativa de consum | Política pròpia i canviant; explicació al client; casos límit | Diagnòstic i percepció necessiten ML |
- Els sistemes experts avui: BRMS, DMN, grafs de coneixement
- BRMS (Business Rules Management Systems): motors de regles amb editor per a usuaris de negoci, versionat, proves i desplegament: Drools (Java, codi obert), IBM ODM, FICO Blaze, entre d'altres. Són EMYCIN amb vestit corporatiu: separen les regles (propietat de negoci, editables pel Diego) del codi (propietat de TI), amb Rete per a l'eficiència i salience per a les prioritats.
- DMN (Decision Model and Notation, estàndard OMG): notació gràfica per modelar decisions, la peça central de la qual és la taula de decisió: files = regles, columnes = entrades i sortides, i una política d'encert (hit policy) que diu què fer si diverses files encaixen: UNIQUE (només en pot encaixar una), FIRST (la primera en ordre), PRIORITY (la de més prioritat de sortida), COLLECT (totes, per acumular accions o sumar). És la resolució de conflictes de 06-02 estandarditzada i llegible per un auditor. La programarem a la secció 10.
- Grafs de coneixement: la lògica de primer ordre de 06-01 a escala: entitats i relacions (
NovaClean —es_un→ aspirador —categoria→ llar,NovaClean —compatible_amb→ bossa B-12) amb consultes i raonament (ontologies, inferència de tipus). Google, Wikidata, els catàlegs de productes i les bases de fàrmacs són grafs de coneixement; per a NovaMarket, un graf de productes i compatibilitats donaria respostes exactes ("quines bosses van amb el meu aspirador?") que un LLM al·lucinaria. - Motors de flux i RPA que executen regles dins de processos de negoci; i els fulls de càlcul, el sistema expert més usat del món, amb els seus
SI(...)imbricats sense traça ni proves: justament el que un BRMS arregla.
- Neurosimbòlic: regles i models junts
02-02 va anunciar la tendència neurosimbòlica i 05-05 la va deixar pendent. Ara podem ser concrets. Les xarxes perceben i estimen; les regles representen, decideixen i garanteixen. Tres patrons de combinació, tots aplicables a NovaMarket:
| Patró | Qui fa què | Exemple NovaMarket |
|---|---|---|
| ML/LLM → regles (el model alimenta la regla) | El model estima una probabilitat o extreu una dada; la regla la fa servir com a fet i decideix amb la política | p_defectuos del model de 04/05 entra al motor de 06-02: garantia automàtica, revisió humana o desistiment (secció 11). La CNN de 05-04 classifica la foto del paquet; la xarxa de 06-03 diagnostica |
| Regles → LLM (les regles governen el model) | Regles que validen, filtren o corregeixen les sortides d'un LLM abans que arribin a l'usuari | L'assistent del cas 7 redacta la resposta, però la decisió de si procedeix retornar la pren el motor; regles de seguretat bloquegen respostes que prometen reemborsaments o revelen dades d'altres clients; verificació que la xifra citada existeix al document recuperat |
| LLM → coneixement (el model ajuda a construir la part simbòlica) | L'LLM llegeix documents i proposa regles o fets que un expert valida | Extreure de la política de devolucions i de la normativa un esborrany de regles SI ... ALESHORES que el Diego revisa; extreure entitats i relacions per al graf de productes; suggerir CPT inicials que després s'estimen d'incidencies.csv |
I el més important a la pràctica és el primer, perquè resol el dilema de 05-05: aprofitar la percepció i les probabilitats dels models sense renunciar a l'explicabilitat i al control que exigeix l'AI Act. La decisió final és una regla llegible; el model és un sensor més, amb la seva incertesa convertida en una banda de revisió humana. També hi ha recerca d'integració més profunda (xarxes que aprenen regles lògiques, raonament diferenciable, LLM que criden demostradors) que queda fora d'aquest curs; 08-03 la menciona entre les tendències.
- Codi: taula de decisió DMN per a l'encaminament de tiquets
Cada incidència que entra a atenció al client de NovaMarket ha d'anar a un equip amb una prioritat, i de vegades desencadenar accions automàtiques. Ho modelem com dues taules de decisió: la d'encaminament, amb política "primera fila que encaixa" (FIRST: les files van de més específica a més general, amb una fila final per defecte), i la d'accions, amb política "totes les que encaixen" (COLLECT: diverses accions es poden acumular). Cada casella d'entrada pot ser un valor, un conjunt de valors, una condició (funció) o "qualsevol".
QUALSEVOL = None
def encaixa(casella, valor):
"""El valor de l'entrada encaixa amb la casella de la taula?"""
if casella is QUALSEVOL:
return True
if callable(casella): # condicio com a funcio, p. ex. lambda x: x > 300
return casella(valor)
if isinstance(casella, (set, tuple, list)):
return valor in casella
return valor == casella
ENTRADES = ["tipus_incidencia", "import_comanda", "client_vip"]
# Cada fila: (caselles d'entrada en l'ordre d'ENTRADES, sortides)
TAULA_ENCAMINAMENT = [
(("producte_no_arriba", lambda x: x > 300, QUALSEVOL), {"equip": "logistica_senior", "prioritat": "alta"}),
(("producte_no_arriba", QUALSEVOL, True), {"equip": "logistica_senior", "prioritat": "alta"}),
(("producte_no_arriba", QUALSEVOL, QUALSEVOL), {"equip": "logistica", "prioritat": "mitjana"}),
(("producte_defectuos", QUALSEVOL, QUALSEVOL), {"equip": "garanties", "prioritat": "mitjana"}),
(({"paquet_danyat", "producte_equivocat"}, QUALSEVOL, QUALSEVOL), {"equip": "magatzem", "prioritat": "mitjana"}),
(("retard", QUALSEVOL, True), {"equip": "atencio_vip", "prioritat": "mitjana"}),
(("retard", QUALSEVOL, QUALSEVOL), {"equip": "atencio", "prioritat": "baixa"}),
((QUALSEVOL, QUALSEVOL, QUALSEVOL), {"equip": "atencio", "prioritat": "baixa"}), # per defecte
]
# Segona taula: accions complementaries (diverses files es poden aplicar alhora)
TAULA_ACCIONS = [
((QUALSEVOL, QUALSEVOL, True), {"accio": "cupo_5_euros"}),
((QUALSEVOL, lambda x: x > 300, QUALSEVOL), {"accio": "trucada_telefonica"}),
(("producte_no_arriba", QUALSEVOL, QUALSEVOL), {"accio": "obrir_traca_transportista"}),
(("paquet_danyat", QUALSEVOL, QUALSEVOL), {"accio": "demanar_foto_embalatge"}),
]
def avaluar_taula(taula, tiquet, politica="primera"):
"""politica='primera': retorna la sortida de la primera fila que encaixa (DMN FIRST).
politica='totes': retorna la llista de sortides de totes les files que encaixen (DMN COLLECT)."""
coincidencies = []
for i, (caselles, sortida) in enumerate(taula, start=1):
if all(encaixa(casella, tiquet[entrada]) for casella, entrada in zip(caselles, ENTRADES)):
coincidencies.append((i, sortida))
if politica == "primera":
break
return coincidencies
tiquets = [
dict(id="T-9001", tipus_incidencia="producte_no_arriba", import_comanda=450, client_vip=True),
dict(id="T-9002", tipus_incidencia="retard", import_comanda=35, client_vip=False),
dict(id="T-9003", tipus_incidencia="paquet_danyat", import_comanda=120, client_vip=True),
dict(id="T-9004", tipus_incidencia="consulta_factura", import_comanda=0, client_vip=False),
]
for t in tiquets:
fila, sortida = avaluar_taula(TAULA_ENCAMINAMENT, t, "primera")[0]
accions = [s["accio"] for _, s in avaluar_taula(TAULA_ACCIONS, t, "totes")]
print(f"{t['id']} ({t['tipus_incidencia']}, {t['import_comanda']} €, vip={t['client_vip']}): "
f"fila {fila} → {sortida['equip']}/{sortida['prioritat']}; accions: {accions or '-'}")
print("\nEncaminament amb politica 'totes' per a T-9001:")
for fila, sortida in avaluar_taula(TAULA_ENCAMINAMENT, tiquets[0], "totes"):
print(f" fila {fila}: {sortida}")Sortida:
T-9001 (producte_no_arriba, 450 €, vip=True): fila 1 → logistica_senior/alta; accions: ['cupo_5_euros', 'trucada_telefonica', 'obrir_traca_transportista']
T-9002 (retard, 35 €, vip=False): fila 7 → atencio/baixa; accions: -
T-9003 (paquet_danyat, 120 €, vip=True): fila 5 → magatzem/mitjana; accions: ['cupo_5_euros', 'demanar_foto_embalatge']
T-9004 (consulta_factura, 0 €, vip=False): fila 8 → atencio/baixa; accions: -
Encaminament amb politica 'totes' per a T-9001:
fila 1: {'equip': 'logistica_senior', 'prioritat': 'alta'}
fila 2: {'equip': 'logistica_senior', 'prioritat': 'alta'}
fila 3: {'equip': 'logistica', 'prioritat': 'mitjana'}
fila 8: {'equip': 'atencio', 'prioritat': 'baixa'}Explicació:
encaixaés l'aparellador de caselles: quatre tipus de casella cobreixen la majoria de les taules DMN reals (qualsevol, condició, conjunt, valor).avaluar_taularecorre les files en ordre i aplica la política: amb"primera"s'atura a la primera coincidència; amb"totes"les acumula.- La taula d'encaminament amb FIRST exigeix que les files estiguin ordenades d'específica a general: el tiquet T-9001 (no arriba, 450 €, VIP) encaixa amb les files 1, 2, 3 i 8, com mostra l'avaluació amb
"totes", i guanya la 1 per ordre. Aquest és el punt delicat de FIRST: l'ordre és la prioritat, i una fila inserida al lloc equivocat canvia decisions silenciosament. Per això DMN ofereix també UNIQUE (que obliga que només encaixi una fila i detecta solapaments en temps de disseny) i PRIORITY. - La taula d'accions amb COLLECT és l'ús natural de "totes les que encaixen": T-9001 acumula cupó (VIP), trucada (import > 300) i traça amb el transportista (no arriba); T-9002 cap.
- T-9004 mostra la fila per defecte: un tipus d'incidència que no està previst va a atenció amb prioritat baixa en lloc de quedar-se sense ruta (el "cap regla aplicable" de 06-02, resolt per disseny).
El Diego pot llegir i editar aquestes dues taules en un full de càlcul; TI les pot versionar i provar amb una bateria de tiquets, com els casos A-E de 06-02. Això és un BRMS en miniatura.
- Codi: un exemple neurosimbòlic executable
Tanquem el mòdul amb el patró "model → regles". Un client sol·licita una devolució al·legant (o no) un defecte. Un model (aquí una regressió logística ja entrenada, simulada amb pesos fixos: en producció seria el model.predict_proba de 04-04 o l'MLP de 05-03, alimentat amb el text de la sol·licitud, la foto i l'històric del producte) estima p_defectuos. Aquesta probabilitat entra com un fet més al motor de regles de 06-02, juntament amb tres regles noves que apliquen la banda de revisió humana de 02-04 (LLINDAR = 0,40, BANDA = 0,20) i una quarta que impedeix denegar automàticament una garantia quan el client al·lega defecte i el model el descarta.
Copiem de 06-02 només l'imprescindible (Regla i un MotorInferencia compacte sense la interfície de preguntes):
import math, operator
# ---- Peces minimes del sistema expert de 06-02 (mateixes idees, sense la interficie de preguntes) ----
OPERADORS = {"==": operator.eq, "!=": operator.ne, "<=": operator.le, "<": operator.lt,
">=": operator.ge, ">": operator.gt, "in": lambda a, b: a in b}
class Regla:
def __init__(self, nom, condicions, conclusions, prioritat=0, justificacio=""):
self.nom, self.condicions, self.conclusions = nom, condicions, conclusions
self.prioritat, self.justificacio = prioritat, justificacio
def aplicable(self, fets):
return all(a in fets and OPERADORS[op](fets[a], v) for a, op, v in self.condicions)
class MotorInferencia:
def __init__(self, regles, fets):
self.regles, self.fets, self.traca, self.disparades = regles, dict(fets), [], set()
def executar(self, objectiu="decisio"):
while objectiu not in self.fets:
candidates = [r for r in self.regles if r.nom not in self.disparades and r.aplicable(self.fets)]
if not candidates:
return None
regla = max(candidates, key=lambda r: (r.prioritat, len(r.condicions))) # prioritat > especificitat
detall = ", ".join(f"{a}={self.fets[a]!r}" for a in dict.fromkeys(a for a, _, _ in regla.condicions))
self.fets.update(regla.conclusions)
self.disparades.add(regla.nom)
self.traca.append(f"{regla.nom} perquè {detall} → {regla.conclusions} ({regla.justificacio})")
return self.fets[objectiu]
# ---- Part "neuro": un model que estima P(defectuos) a partir de la sol·licitud ----
PESOS = {"biaix": -2.0, "esmenta_no_funciona": 2.2, "esmenta_rascada": -1.5,
"taxa_defectes_producte": 6.0, "dies_des_lliurament": -0.004, "foto_adjunta": 0.8}
def p_defectuos(peticio):
"""Simula el model dels moduls 4/5 (una regressio logistica ja entrenada):
suma ponderada de caracteristiques + sigmoide. En produccio seria model.predict_proba."""
z = PESOS["biaix"] + sum(PESOS[k] * float(peticio[k]) for k in PESOS if k != "biaix")
return 1 / (1 + math.exp(-z))
# ---- Part "simbolica": les regles de garantia de 06-02 mes les de la banda de revisio de 02-04 ----
LLINDAR, BANDA = 0.40, 0.20 # els mateixos valors que a 02-04
def regles_neurosimboliques():
return [
Regla("N1", [("p_defectuos", ">=", LLINDAR + BANDA)], {"defectuos": True}, prioritat=20,
justificacio="el model estima defecte amb confiança alta: s'accepta com a fet"),
Regla("N2", [("p_defectuos", ">=", LLINDAR), ("p_defectuos", "<", LLINDAR + BANDA)],
{"decisio": "revisio_humana", "motiu": "zona grisa del model de defectes"}, prioritat=20,
justificacio="banda de revisió humana de 02-04: una persona confirma"),
Regla("N3", [("p_defectuos", "<", LLINDAR)], {"defectuos": False}, prioritat=20,
justificacio="el model descarta el defecte amb confiança"),
Regla("N4", [("declara_defecte", "==", True), ("defectuos", "==", False), ("dies_des_lliurament", ">", 14)],
{"decisio": "revisio_humana", "motiu": "el client al·lega defecte i el model el descarta"}, prioritat=15,
justificacio="denegar una garantia és una decisió amb efectes significatius: no s'automatitza"),
Regla("R1", [("defectuos", "==", True), ("producte_nou", "==", True), ("dies_des_lliurament", "<=", 1095)],
{"decisio": "garantia", "enviament_devolucio": "gratuit"}, prioritat=10,
justificacio="garantia legal de 3 anys; enviament a càrrec de NovaMarket"),
Regla("R2", [("defectuos", "==", True), ("dies_des_lliurament", ">", 1095)],
{"decisio": "denegada", "motiu": "fora del termini de garantia legal"}, prioritat=9,
justificacio="passats 3 anys, servei tècnic de pagament"),
Regla("R4", [("dies_des_lliurament", "<=", 14), ("usat", "==", False), ("etiqueta_original", "==", True)],
{"decisio": "reemborsament_desistiment", "enviament_devolucio": "a carrec del client"}, prioritat=5,
justificacio="desistiment de 14 dies"),
Regla("R8", [("dies_des_lliurament", ">", 14), ("defectuos", "==", False)],
{"decisio": "denegada", "motiu": "fora de termini i sense defecte"}, prioritat=2,
justificacio="la regla del Diego"),
]
PETICIONS = [
dict(id="S-101", producte="Aspirador NovaClean", declara_defecte=True, dies_des_lliurament=200, usat=True, etiqueta_original=False, producte_nou=True,
esmenta_no_funciona=1, esmenta_rascada=0, taxa_defectes_producte=0.12, foto_adjunta=1),
dict(id="S-102", producte="Cafetera NovaBrew", declara_defecte=True, dies_des_lliurament=45, usat=True, etiqueta_original=False, producte_nou=True,
esmenta_no_funciona=1, esmenta_rascada=0, taxa_defectes_producte=0.04, foto_adjunta=0),
dict(id="S-103", producte="Auriculars NovaSound", declara_defecte=True, dies_des_lliurament=30, usat=True, etiqueta_original=True, producte_nou=True,
esmenta_no_funciona=0, esmenta_rascada=1, taxa_defectes_producte=0.02, foto_adjunta=0),
dict(id="S-104", producte="Monitor NovaView", declara_defecte=False, dies_des_lliurament=6, usat=False, etiqueta_original=True, producte_nou=True,
esmenta_no_funciona=0, esmenta_rascada=0, taxa_defectes_producte=0.03, foto_adjunta=0),
]
for s in PETICIONS:
fets = dict(s)
fets["p_defectuos"] = round(p_defectuos(s), 3) # la sortida del model entra com un fet mes
motor = MotorInferencia(regles_neurosimboliques(), fets)
decisio = motor.executar("decisio")
print(f"{s['id']} {s['producte']}: p_defectuos={fets['p_defectuos']} → {decisio} ({motor.fets.get('motiu') or motor.fets.get('enviament_devolucio')})")
for pas in motor.traca:
print(" ", pas)Sortida:
S-101 Aspirador NovaClean: p_defectuos=0.715 → garantia (gratuit)
N1 perquè p_defectuos=0.715 → {'defectuos': True} (el model estima defecte amb confiança alta: s'accepta com a fet)
R1 perquè defectuos=True, producte_nou=True, dies_des_lliurament=200 → {'decisio': 'garantia', 'enviament_devolucio': 'gratuit'} (garantia legal de 3 anys; enviament a càrrec de NovaMarket)
S-102 Cafetera NovaBrew: p_defectuos=0.565 → revisio_humana (zona grisa del model de defectes)
N2 perquè p_defectuos=0.565 → {'decisio': 'revisio_humana', 'motiu': 'zona grisa del model de defectes'} (banda de revisió humana de 02-04: una persona confirma)
S-103 Auriculars NovaSound: p_defectuos=0.029 → revisio_humana (el client al·lega defecte i el model el descarta)
N3 perquè p_defectuos=0.029 → {'defectuos': False} (el model descarta el defecte amb confiança)
N4 perquè declara_defecte=True, defectuos=False, dies_des_lliurament=30 → {'decisio': 'revisio_humana', 'motiu': 'el client al·lega defecte i el model el descarta'} (denegar una garantia és una decisió amb efectes significatius: no s'automatitza)
S-104 Monitor NovaView: p_defectuos=0.137 → reemborsament_desistiment (a carrec del client)
N3 perquè p_defectuos=0.137 → {'defectuos': False} (el model descarta el defecte amb confiança)
R4 perquè dies_des_lliurament=6, usat=False, etiqueta_original=True → {'decisio': 'reemborsament_desistiment', 'enviament_devolucio': 'a carrec del client'} (desistiment de 14 dies)Explicació:
p_defectuosés la part subsimbòlica: una suma ponderada de característiques (si el text esmenta "no funciona", si esmenta una rascada, la taxa històrica de defectes del producte, els dies transcorreguts, si hi ha foto) passada per la sigmoide, la neurona de 05-01. Els seus pesos són opacs per naturalesa; no intentem explicar-los: els tractem com un sensor que retorna una probabilitat.- Les regles N1-N3 converteixen aquesta probabilitat en fets simbòlics amb la banda de 02-04: ≥ 0,60 s'accepta com a defecte, entre 0,40 i 0,60 va a revisió humana, < 0,40 es descarta. Tenen la màxima prioritat perquè s'avaluïn abans que la política. N4 és una salvaguarda del RGPD/AI Act: si el client al·lega defecte i el model el descarta, no deneguem automàticament; una persona confirma. Sense N4, S-103 aniria a R8 i es denegaria per un càlcul opac, exactament el que 02-04 prohibeix.
- Després actuen les regles de la política de 06-02 (R1, R2, R4, R8), sense canvis: l'explicació final és la cadena "N1 (el model ho estima amb 0,715) → R1 (garantia legal, enviament gratuït)", llegible pel client i per l'auditor, i en què el model apareix amb el seu número i els seus llindars.
- Els quatre casos cobreixen les sortides: garantia automàtica (S-101), zona grisa (S-102), al·legació descartada pel model → persona (S-103) i desistiment ordinari en què el model simplement confirma que no hi ha defecte (S-104). Canviar els llindars o les regles no exigeix tocar el model; reentrenar el model no exigeix tocar les regles. Aquesta separació és el valor de l'enfocament neurosimbòlic.
Errors Comuns i Consells
- Triar ML "perquè és IA". Si la decisió la defineix una norma o una política, escriu la regla; el model, si de cas, estima els fets incerts que la regla necessita.
- Triar regles per al que no sap escriure ningú. Reconèixer una foto o predir la demanda no cap en regles: mòduls 4 i 5.
- Taules FIRST amb files en ordre descurat. L'ordre és la prioritat. Prova amb "totes" per veure els solapaments, o fes servir UNIQUE quan les files hagin de ser excloents.
- Regles sense propietari ni proves. Cada taula o base de regles necessita propietari (el Diego), versionat i una bateria de casos que s'executi a cada canvi.
- Deixar que l'LLM decideixi. Que redacti, resumeixi, extregui i proposi; que la decisió amb efectes sobre el client la prengui una regla o una persona, i que una regla validi el que l'LLM diu.
- Llindars del model amagats al codi. Els llindars són política (quant risc s'accepta): deixa'ls en regles explícites i visibles com
LLINDARiBANDA, no enterrats en una funció. - Oblidar la banda de revisió humana. El model s'equivoca; la banda és on la seva incertesa es converteix en feina humana en lloc d'un error cap al client.
Exercicis
Exercici 1. Afegeix a TAULA_ENCAMINAMENT una regla nova que el Diego demana: els tiquets de producte_defectuos amb import superior a 500 € han d'anar a garanties_senior amb prioritat alta. En quina posició ha d'anar la fila perquè la política "primera" funcioni? Comprova-ho amb un tiquet de 700 € i un altre de 80 € i explica què passaria si la posessis al final.
Exercici 2. Executa l'exemple neurosimbòlic amb la sol·licitud S-105: auriculars NovaSound, declara_defecte=False, 30 dies, usat, amb etiqueta, i les mateixes característiques del model que S-103. Què decideix el sistema i per què és diferent de S-103? Després canvia BANDA a 0,40 i torna a executar els quatre casos originals: quines sol·licituds canvien de decisió? Quin cost i quin benefici té ampliar la banda?
Exercici 3. Per a l'assistent del cas 7 (LLM amb RAG, 05-05), dissenya sense codi tres regles de validació de la sortida del model abans de mostrar-la al client (patró "regles → LLM" de la secció 9): què comprova cadascuna, què fa si falla i de quin mòdul del curs ve la necessitat. Després indica una tasca en què faries servir el patró "LLM → coneixement" per al sistema de devolucions i quin control humà hi posaries.
Solucions
Solució 1. La fila (("producte_defectuos", lambda x: x > 500, QUALSEVOL), {"equip": "garanties_senior", "prioritat": "alta"}) ha d'anar abans de la fila general de producte_defectuos (l'actual fila 4), perquè és més específica; col·locada al final no s'hi arribaria mai amb la política "primera": la fila 4 encaixa abans i el tiquet de 700 € aniria a garanties/mitjana. Amb la fila al seu lloc, el de 700 € va a garanties_senior/alta i el de 80 € a garanties/mitjana. És el mateix principi que l'especificitat de 06-02, només que a DMN FIRST l'apliques tu amb l'ordre.
Solució 2. S-105 obté p_defectuos = 0,029 (mateixes característiques que S-103), N3 fixa defectuos = False, i com que el client no al·lega defecte N4 no s'aplica; amb 30 dies i sense defecte, R8 denega: "fora de termini i sense defecte", la regla del Diego, ara amb el suport del model. És diferent de S-103 perquè allà el client al·legava defecte i denegar automàticament contra la seva al·legació exigeix una persona. Amb BANDA = 0,40 la zona grisa passa a ser [0,40, 0,80): S-101 (0,715) deixa d'anar a garantia automàtica i passa a revisió humana; S-102 continua en revisió; S-103 i S-104 no canvien. Benefici: menys garanties acceptades per error del model; cost: més feina humana i més espera per a clients amb defectes clars. L'amplada de la banda és una decisió de negoci que es pren amb la matriu de costos de 04-05, no un paràmetre tècnic.
Solució 3. Exemples de regles de validació: (1) "SI la resposta conté una xifra de dies o d'euros I aquesta xifra no apareix als fragments recuperats ALESHORES substituir-la per la resposta genèrica amb enllaç a la política i registrar-ho" (al·lucinacions, 05-05); (2) "SI la resposta conté un compromís de reemborsament o d'acceptació de garantia ALESHORES eliminar-lo i derivar la decisió al motor de regles de 06-02" (l'LLM no decideix, 02-04); (3) "SI la resposta conté dades personals que no són del client autenticat (un altre nom, un altre número de comanda) ALESHORES bloquejar i alertar" (RGPD, 02-03). Patró "LLM → coneixement": demanar a l'LLM que llegeixi la política de devolucions vigent i la normativa aplicable i proposi un esborrany de regles SI ... ALESHORES amb la seva justificació i exemples; control humà: el Diego valida cada regla, un professional legal revisa les que depenen de la normativa, i la bateria de casos A-E (i els nous) s'executa abans d'activar qualsevol regla proposada.
Conclusió
En aquesta lliçó hem vist que els sistemes basats en regles i coneixement no són una relíquia dels 80 sinó la capa de decisió de la majoria dels sistemes de negoci: alertes de fàrmacs i protocols en medicina, scoring per polítiques i antiblanqueig en finances, configuradors i arbres de diagnòstic en indústria, assessors agrícoles, elegibilitat i tributació a l'administració, tutors intel·ligents i, en el comerç electrònic de NovaMarket, promocions, devolucions, encaminament de tiquets i antifrau; en tots ells, regles perquè la norma mana, l'explicació s'exigeix, les dades escassegen o els casos límit importen, i amb els límits de manteniment, cobertura i incertesa que ja coneixíem. Hem situat les seves formes actuals (BRMS com Drools, taules de decisió DMN amb les seves polítiques d'encert, grafs de coneixement) i hem concretat l'enfocament neurosimbòlic en tres patrons: el model alimenta la regla, la regla governa l'LLM, i l'LLM ajuda a construir el coneixement. En codi, la taula de decisió ha encaminat els tiquets de NovaMarket amb FIRST i COLLECT, i l'exemple neurosimbòlic ha convertit la p_defectuos d'un model en un fet del motor de 06-02, decidint garantia automàtica, revisió humana o desistiment amb la banda de 02-04 i una traça que cita el model i la regla.
Amb això tanquem el mòdul 6 i, amb ell, el recorregut conceptual per les dues meitats de la IA. Ja saps representar coneixement amb lògica i encadenar regles (06-01), construir un sistema expert amb prioritats, explicació i interfície (06-02), raonar amb probabilitat i xarxes bayesianes i decidir per utilitat esperada (06-03) i combinar regles amb models on cadascun rendeix millor (06-04). La Marta i el Diego tenen ara les regles del cas 8, la xarxa de diagnòstic del cas 9 i el criteri per saber quina part de cada problema va a les regles, quina part a l'ML i quina part a una persona. Fixa't en com ho hem fet: tot el mòdul en Python pur, amb diccionaris, llistes, itertools i fractions, mentre que als mòduls 4 i 5 vam fer servir scikit-learn i PyTorch, i hem anat citant de passada Prolog, CLIPS, Drools, experta o pgmpy sense instal·lar-los. És hora d'ordenar aquest ecosistema: quins llenguatges es fan servir en IA i per què Python domina, què aporten NumPy, pandas i Matplotlib, quines llibreries hi ha per a cada tasca de les que hem vist i en quins entorns es treballa. És el mòdul 7, Eines i Llenguatges de Programació en IA, que comença a 07-01 comparant Python amb Prolog, Lisp, R, Julia i els llenguatges de producció.
Fonaments d'Intel·ligència Artificial (IA)
Mòdul 1: Introducció a la Intel·ligència Artificial
Mòdul 2: Principis Bàsics de la IA
- Conceptes Fonamentals: Agents, Entorns i Racionalitat
- Tipus d'Intel·ligència Artificial
- Les Dades com a Matèria Primera de la IA
- Ètica i Consideracions en IA
Mòdul 3: Algorismes en IA
- Introducció als Algorismes
- Algorismes de Cerca
- Cerca amb Adversari: Jocs i Minimax
- Algorismes d'Optimització
Mòdul 4: Aprenentatge Automàtic (Machine Learning)
- Conceptes Bàsics de Machine Learning
- Tipus d'Aprenentatge Automàtic
- Preparació de Dades i Característiques
- Algorismes de Machine Learning
- Avaluació i Validació de Models
- Sobreajust, Regularització i Ajust d'Hiperparàmetres
Mòdul 5: Xarxes Neuronals i Deep Learning
- Introducció a les Xarxes Neuronals
- Arquitectura de Xarxes Neuronals
- Com Aprèn una Xarxa: Descens del Gradient i Retropropagació
- Deep Learning i les seves Aplicacions
- Transformers, Grans Models de Llenguatge i IA Generativa
Mòdul 6: Lògica i Sistemes Experts
- Lògica en IA
- Sistemes Experts
- Raonament amb Incertesa: Probabilitat i Xarxes Bayesianes
- Aplicacions dels Sistemes Experts
Mòdul 7: Eines i Llenguatges de Programació en IA
- Llenguatges de Programació per a IA
- Python Científic: NumPy, pandas i Matplotlib
- Eines i Llibreries Populars
- Entorns de Desenvolupament
Mòdul 8: Projectes i Casos d'Estudi
Mòdul 9: Exercicis i Pràctiques
- Exercicis d'Algorismes
- Pràctiques de Machine Learning
- Projectes de Xarxes Neuronals
- Projecte Integrador: de la Idea al Prototip
