Diferencias

Muestra las diferencias entre dos versiones de la página.

--- cursos:sdd:05-patrones-agenticos [2026/09/17 17:40] – Razonador-Refutador: por qué gana el Refutador y qué pasa después claude
+++ cursos:sdd:05-patrones-agenticos [2026/10/26 16:09] (actual) – Enlaces internos: los anclajes no llevan el número de sección claude
@@ Línea 8: / Línea 8: @@
 ^ Patrón ^ Cuándo se usa ^
-| [[#1_pipeline_prompt_chain|Pipeline]] | La tarea se parte en pasos fijos, conocidos de antemano |
+| [[#pipeline_prompt_chain|Pipeline]] | La tarea se parte en pasos fijos, conocidos de antemano |
-| [[#2_enrutador|Enrutador]] | Entradas de tipos distintos que se atienden mejor por separado |
+| [[#enrutador|Enrutador]] | Entradas de tipos distintos que se atienden mejor por separado |
-| [[#3_planificador-ejecutor|Planificador-Ejecutor]] | Conviene revisar el plan antes de que se toque nada |
+| [[#planificador-ejecutor|Planificador-Ejecutor]] | Conviene revisar el plan antes de que se toque nada |
-| [[#4_orquestador|Orquestador]] | Las subtareas no se conocen hasta ver el problema |
+| [[#orquestador|Orquestador]] | Las subtareas no se conocen hasta ver el problema |
-| [[#5_ejecutor-revisor|Ejecutor-Revisor]] | Hay criterios claros y la crítica mejora el resultado |
+| [[#ejecutor-revisor|Ejecutor-Revisor]] | Hay criterios claros y la crítica mejora el resultado |
-| [[#6_adversarios|Adversarios]] | Interesa encontrar el fallo, no pulir el acabado |
+| [[#adversarios|Adversarios]] | Interesa encontrar el fallo, no pulir el acabado |
-| [[#7_razonador-refutador|Razonador-Refutador]] | La causa de un fallo no está clara y conviene acertar antes de arreglar |
+| [[#razonador-refutador|Razonador-Refutador]] | La causa de un fallo no está clara y conviene acertar antes de arreglar |
-| [[#8_best-of-n|Best-of-N]] | Los intentos salen muy distintos y verificar es barato |
+| [[#best-of-n|Best-of-N]] | Los intentos salen muy distintos y verificar es barato |
-| [[#9_human-in-the-loop_hitl|Human-in-the-loop]] | Hay acciones irreversibles o responsabilidad de por medio |
+| [[#human-in-the-loop_hitl|Human-in-the-loop]] | Hay acciones irreversibles o responsabilidad de por medio |
-| [[#10_memoria_persistente|Memoria persistente]] | El trabajo dura más que una sesión |
+| [[#memoria_persistente|Memoria persistente]] | El trabajo dura más que una sesión |
 ----
@@ Línea 339: / Línea 339: @@
 **Por qué gana el Refutador aunque tenga menos pruebas.** Para que una explicación sea cierta tiene que cumplirse **todo** lo que exige; para que sea falsa basta con que falle **una sola cosa**. Por eso mil pistas a favor no pesan nada frente a un hecho que la hace imposible.
-Por ejemplo, el Razonador ve 500 errores ''DatabaseConnectionException'' en los logs de un servicio y concluye que la base de datos está caída. El Refutador comprueba la base de datos: está en marcha, al 1 % de CPU y atendiendo a otros servicios. La explicación es falsa, da igual cuántos logs la apoyen.
+Por ejemplo, fallan 30 tests con ''NullPointerException'' dentro de ''PedidoService.calcularTotal()'', y el Razonador concluye que el pedido llega sin cliente. El Refutador lee el código: el constructor de ''Pedido'' lanza una excepción si no recibe cliente, así que un pedido sin cliente nunca llega hasta ahí. La explicación es falsa, da igual cuántos tests fallen.
-**Qué pasa cuando gana.** El trabajo no termina ahí: vuelve al Razonador, y **lo que ha tumbado la explicación pasa a ser un hecho comprobado**. Con esa pista nueva, el Razonador propone otra explicación —«la base de datos funciona, así que algo corta la conexión por el camino: un cortafuegos bloqueando el puerto 5432»— y el Refutador intenta tumbarla también. Se repite hasta que una explicación aguanta. Cada vuelta descarta una causa y deja un hecho más, así que el círculo se va cerrando.
+**Qué pasa cuando gana.** El trabajo no termina ahí: vuelve al Razonador, y **lo que ha tumbado la explicación pasa a ser un hecho comprobado**. Con esa pista nueva, el Razonador propone otra explicación —«el cliente nunca es nulo, así que el nulo sale de otro campo que usa ''calcularTotal()'': el descuento, que solo se rellena cuando hay cupón»— y el Refutador intenta tumbarla también. Esta vez no puede: los 30 tests que fallan crean pedidos sin cupón y los que pasan, con cupón. Se repite hasta que una explicación aguanta, y solo entonces se arregla. Cada vuelta descarta una causa y deja un hecho más, así que el círculo se va cerrando.
-  * **Cuándo**: fallos que van y vienen, lentitud sin causa clara, errores cuyo origen no se ve a simple vista.
+  * **Cuándo**: tests que unas veces pasan y otras no, código lento sin causa clara, errores cuyo origen no se ve a simple vista.
   * **En contra**: más tiempo y más coste. Si la causa era obvia desde el principio, sobra.
-  * **Regla del Refutador**: puede comprobar hechos —mirar el estado de un servicio, leer logs—, pero no propone soluciones ni escribe código. Solo señala qué paso no se sostiene y con qué prueba.
+  * **Regla del Refutador**: puede comprobar hechos —leer el código, lanzar un test—, pero no propone soluciones ni escribe código. Solo señala qué paso no se sostiene y con qué prueba.
 **Ejemplo.** Encontrar la causa de un fallo antes de arreglarlo. El auditor **se lanza en ese momento** y no sabe nada del problema, así que el encargo lleva el contexto y el razonamiento:
@@ Línea 353: / Línea 353: @@
 FASE 1, RAZONAMIENTO. Escribe tres listas:
-  - HECHOS: lo que has visto de verdad: errores, logs, cuándo pasa y
+  - HECHOS: lo que has visto de verdad: errores, trazas, qué tests
-    cuándo no. Solo lo comprobado.
+    fallan y cuáles no. Solo lo comprobado.
   - DEDUCCIONES: qué concluyes, un paso por línea, diciendo de qué hecho
     sale cada uno.
@@ Línea 378: / Línea 378: @@
 </code>
-----
+Más informnación:
+  * [[https://dzone.com/articles/multi-agent-infrastructure-observability|What Actually Makes AI Infrastructure Agents More Reliable (It's Not More Agents)]]
 ===== 8. Best-of-N =====