Del motor a un sistema que asesora.
01Ya tenemos hechos, reglas y un motor.
02Ahora necesitamos explicar, adquirir conocimiento y mantenerlo.
Experto en algo concreto.
01Un sistema experto aplica conocimiento especializado en un dominio delimitado.
02En el enfoque del apunte, ese conocimiento se expresa mediante reglas.
03Buen desempeño en un dominio no implica sentido común general.
Cinco piezas, responsabilidades diferentes.
01Base: reglas del dominio. Memoria: hechos del caso.
02Motor: aplicar las reglas. Explicación: justificar el recorrido.
03Adquisición: cargar, revisar y depurar conocimiento.
¿Qué pieza está trabajando ahora?
- AdquisiciónEl especialista y el ingeniero revisan reglas.
- Base de conocimientoReglas del dominio, reutilizables entre casos.
- Memoria de trabajoObservaciones y conclusiones de este caso.
- Motor de inferenciaComprueba condiciones y aplica reglas.
- ExplicaciónRelaciona conclusiones y preguntas con sus razones.
Consultar observaciones y reglas del caso
Observaciones: no_enciende, sin_luz_fuente, cable_ok
- R1
no_enciende ∧ sin_luz_fuente → problema_alimentacion - R2
problema_alimentacion ∧ cable_ok → fuente_danada - R3
no_enciende ∧ hay_luz_fuente → problema_placa - R4
fuente_danada → reemplazar_fuente - R5
problema_placa ∧ pitidos → revisar_memoria
Acotar antes de codificar
El especialista y el ingeniero acuerdan el dominio: esta PC y estas cinco reglas. La interfaz de adquisición ayuda a cargarlas y depurarlas; no descubre por sí sola el conocimiento tácito.
«Cómo llegaste» y «por qué preguntás».
01Cómo: reconstruir la cadena de premisas y reglas.
02Por qué: mostrar qué objetivo o regla necesita un dato.
03Una explicación fiel no demuestra que las observaciones sean verdaderas.
¿Dónde vive el dato del caso?
El trabajo empieza antes del código.
01Delimitar → adquirir → formalizar → validar.
02El especialista aporta experiencia; el ingeniero ayuda a hacerla explícita.
03Las etapas se revisitan cuando aparecen excepciones.
Una pregunta que podamos evaluar.
01«Resolver problemas tecnológicos» es demasiado amplio.
02«Asignar soporte de aula a solicitudes de equipos docentes» tiene límites comprobables.
03Acordar entradas, salidas, exclusiones y quién revisa excepciones.
Preguntar también por los casos difíciles.
01Entrevistas y observación del trabajo.
02Casos concretos, pensamiento en voz alta y contraejemplos.
03Registrar dudas y excepciones antes de convertirlas en reglas.
Traducir no es copiar una frase.
01Definir qué significa cada condición.
02Explicitar conjunciones, excepciones y acciones.
03Revisar contradicciones e interacciones con reglas anteriores.
solicitud ∧ equipo_docente → soporte_aula
Una regla se enfrenta a casos concretos.
solicitud → soporte_aula
Política acordada: solicitud y equipo docente. Casos completos; la salida indica si se asigna soporte de aula.
Ver casos y resultados esperados
- Solicitud de equipo docente: solicitud, equipo_docente. Esperado: true.
- Solicitud de otro equipo: solicitud. Esperado: false.
- Equipo docente sin solicitud: equipo_docente. Esperado: false.
- Sin solicitud ni equipo docente: ningún hecho. Esperado: false.
Los resultados de cada caso aparecerán al avanzar.
Regla candidata y criterio del especialista
Se debe asignar soporte de aula si hay solicitud y equipo docente. Estos cuatro casos especifican completamente ambas condiciones; esperamos true o false para la acción.
Pasar los ejemplos no cierra el trabajo.
01Casos con respuesta conocida y casos nuevos supervisados.
02Incluir positivos, negativos, excepciones y casos fuera del dominio.
03Al cambiar una regla, repetir también las pruebas anteriores.
El especialista dice: «me doy cuenta».
Varias reglas pueden estar listas.
01La agenda reúne activaciones habilitadas.
02La estrategia decide cuál se ejecuta en el ciclo.
03Conflicto entre activaciones no significa contradicción lógica.
Elegir requiere una política explícita.
01Orden: primera en la lista. Especificidad: más premisas distintas.
02Prioridad: mayor peso declarado.
03Novedad: en esta demo, mayor instante entre las premisas.
Mismos hechos, otra primera acción.
Hechos e instantes: solicitud @1 · equipo_docente @2 · urgente @3 · canal_virtual @4. Ya ejecutadas: ninguna.
| Regla y acción | Premisas | Prioridad | En este paso |
|---|---|---|---|
| R1 · Atención general | solicitud | 10 | Pendiente |
| R2 · Soporte de aula | solicitud ∧ equipo_docente | 20 | Pendiente |
| R3 · Revisión urgente | urgente | 90 | Pendiente |
| R4 · Mesa virtual | canal_virtual | 5 | Pendiente |
Un ciclo, una selección
Primero formamos el conjunto de activaciones. Después aplicamos Orden de la lista. Una activación es una regla con sus condiciones satisfechas en este caso.
También hay que decidir cómo desempatar.
01En esta demo, los empates conservan el orden de la lista.
02Una activación ya ejecutada no vuelve a participar en este caso fijo.
03En motores con variables, la activación incluye la regla y sus hechos asociados.
Elegir una acción no es calcular todo el cierre.
01El Python anterior recorre reglas y agrega hechos hasta terminar.
02En su fragmento positivo y finito, cambiar el orden conserva el cierre.
03Con acciones, retractaciones o corte tras una selección, el orden puede cambiar el resultado operativo.
¿Más condiciones significa mejor regla?
Cinco proyectos, distintos aprendizajes.
01DENDRAL: química y estructuras moleculares.
02MYCIN: asesoramiento sobre infecciones bacterianas. XCON: configuración de computadoras.
03PROSPECTOR: exploración geológica. Cyc: conocimiento de sentido común.
Evaluar bien y adoptar son problemas distintos.
01Proyecto de investigación con resultados destacados en evaluaciones acotadas.
02Integración, interfaz, alcance y costo de uso también condicionan la adopción.
03La responsabilidad por decisiones merece una discusión separada.
El éxito también produce mantenimiento.
01Configuró sistemas informáticos en producción.
02Un estudio de 1987 reportó unas 6.200 reglas y cambios frecuentes.
03El problema no era solo responder: era poder modificar la base sin romperla.
Cambiar el dominio cambia el desafío.
01PROSPECTOR asistía la exploración de minerales con conocimiento geológico.
02Cyc aborda la representación de conocimiento de sentido común.
03No todos estos sistemas tienen el mismo alcance ni el mismo mecanismo.
El cuello de botella no estaba solo en la máquina.
01Disponibilidad de especialistas. Conocimiento tácito y excepciones.
02Tiempo para formalizar, contrastar y acordar criterios.
03Una interfaz de carga facilita el trabajo; no elimina esos problemas.
Cada cambio puede tocar otros casos.
01Nuevas reglas interactúan con las existentes.
02Guardar razones, versiones y casos de regresión.
03Revisar cambios con especialistas y observar su uso.
Reconocer cuándo el caso queda afuera.
01Un sistema acotado puede fallar fuera de su dominio.
02Detectar entradas no cubiertas y pedir revisión.
03La claridad de una explicación no mide su confiabilidad.
Registrar experiencia no cambia las reglas solo.
01El sistema clásico de reglas manuales requiere revisión explícita.
02Un modelo de aprendizaje automático necesita entrenamiento y evaluación.
03Más datos no garantizan una mejora: importan calidad, tarea y distribución.
El conocimiento explícito sigue siendo útil.
01Políticas de negocio y criterios que deben poder auditarse.
02Reglas claras con responsables de actualización.
03Elegir el enfoque por el problema, la evidencia y el costo de mantenimiento.
Antes de agregar otra regla…
Del apunte a los proyectos originales.
01Base de la clase: apunte de la Unidad 2, apartados 6.1–6.5.
02Las fuentes complementarias permiten contextualizar logros, límites y fechas.