Si activas el bozo bit, se apaga el aprendizaje

 (surfingcomplexity.blog)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El bozo bit es una actitud que considera que ya no vale la pena escuchar el juicio ni las palabras de cierta persona
  • Si se separa a la persona involucrada en un incidente como alguien incompetente, la organización reduce sus oportunidades de aprender del incidente
  • La respuesta de PocketOS ante su incidente de IA corresponde a lo que Cook y Woods llaman distancing through differencing
  • Una planta en EE. UU. que vio un incendio en una fábrica en el extranjero como problema ajeno pasó por alto las similitudes compartidas del sistema
  • Si un incidente de IA se cierra con “ellos debieron haberlo sabido”, es difícil que eso lleve a mejorar la seguridad

Cuando se trata un incidente como problema ajeno, el aprendizaje se detiene

  • bozo bit es una expresión de la industria del software para referirse a dejar de respetar el juicio de cierta persona y considerar que ya no vale la pena escuchar lo que dice
  • Cuando alguien oye sobre un incidente y dice algo como “¿cómo es posible que no hicieran X?”, termina viendo a las personas involucradas como incompetentes y separándolas de su propia organización
  • La publicación en X del fundador de PocketOS, Jer Crane, An AI Agent Just Destroyed Our Production Data. It Confessed in Writing, atrajo mucha atención como incidente relacionado con IA, y en línea hubo muchas opiniones que calificaban a PocketOS como incompetente
  • Esta actitud reduce las oportunidades de aprender de los incidentes y corresponde a lo que Cook y Woods llaman distancing through differencing

  • Tomar distancia a través de las diferencias (distancing through differencing)

Incidentes que se repiten y similitudes que se pasan por alto

  • Cook y Woods analizan como caso un incendio químico en una planta manufacturera de EE. UU.
  • Antes ya había ocurrido un incendio similar en una fábrica de la misma empresa en el extranjero, y el personal en EE. UU. conocía ese hecho
  • Sin embargo, el personal en EE. UU. consideró que sus colegas del extranjero eran menos capacitados, menos motivados y menos cuidadosos, y concluyó que no había nada que aprender para ellos
  • Incluso después del incendio en la planta de EE. UU., trabajadores de otros turnos en la misma planta atribuyeron la causa del incidente a la menor habilidad del turno afectado
  • Esta clase de distinción impide ver las similitudes del sistema que comparten quienes estuvieron involucrados en el incidente y quienes no
  • Cook y Woods sostienen que no se deben descartar eventos que parecen distintos en la superficie, y que en cierto nivel de análisis todos los eventos son únicos, pero en otros niveles revelan patrones compartidos
  • Si el incidente de PocketOS se cierra simplemente con la conclusión de que “usaron IA de forma irresponsable”, deja de haber algo que aprender
  • Railway, que usaba PocketOS, era un proveedor que exponía una API de borrado, y después reveló en Your AI wants to nuke your database. Guardrails fix that que hizo cambios para elevar la seguridad de todo el sistema
  • En adelante seguirán apareciendo incidentes relacionados con IA en la industria, y la actitud de “debieron haber sabido que no había que hacer X” es caer en la trampa del distancing through differencing
  • No es lo mismo que alguien asuma deliberadamente un riesgo excesivo a que lo asuma sin darse cuenta, y es difícil culpar a una persona solo por no haber sabido lo que no sabía
  • Cuando se supera el distancing through differencing, la respuesta de una organización puede cambiar

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Opiniones en Lobste.rs

  • El valor del bozo bit está en que ciertas personas son una fuente estable de información inversa
    Esas personas llegan repetidamente a conclusiones equivocadas por costumbre, malinterpretan incluso documentos redactados de forma muy directa, y proponen diseños que no resuelven el objetivo mientras crean problemas nuevos
    Activarle el bozo bit a alguien significa que decidiste que intentar obtener conocimiento de la comunicación de esa persona es una pérdida de tiempo
    Este texto mezcla el bozo bit con otro fenómeno: creer firmemente que cierto problema no puede ocurrir y luego inventar razones en retrospectiva a partir de ahí
    Un término conocido para eso es racionalización a posteriori, y desde hace siglos o incluso milenios se discute que debe evitarse
    Volviendo al ejemplo del texto, la empresa que le dio privilegios de administrador de base de datos en producción a un LLM, la reacción de “eso no me pasaría a mí por X” está justificada si X se parece a “darle privilegios de administrador de base de datos en producción a un LLM es tan raro y absurdamente peligroso que simplemente no lo hacemos”
    Es parecido a la gente que come algo peligroso y termina en una tragedia. Si leo una noticia de alguien que comió una babosa y murió por un parásito cerebral, puedo estar seguro de que yo no voy a morir por esa causa específica
    El autor imagina que eso se debe a que creo ser mejor o más inteligente que la persona que murió, pero el proceso mental real se parece más a “estoy 100% seguro de que, incluso si estuviera muriéndome de hambre en una isla desierta llena de babosas jugosas, no me comería una voluntariamente, así que los parásitos transmitidos por babosas no están en mi modelo de riesgo”
    También me cuesta estar de acuerdo con la parte de que decir “debieron haberlo sabido” es incoherente. A la gente se le culpa todo el tiempo por cosas que no sabe, y eso es parte de vivir como adulto
    Si un niño de 3 años se comiera una babosa, no lo culparía, pero si un colega de 30 años se comiera una babosa, por supuesto que sí lo culparía. Una acción demasiado obviamente estúpida sí puede justificar culpar a una persona

    • Ya existe el término ignorancia deliberada para responder a la idea de que no se puede culpar a alguien por “no saber algo”
      Creo que este texto plantea un buen punto que no había considerado antes, pero para mí también tenía algunos defectos claros, y ese es el primero
      El segundo es que, al leer sobre los estadounidenses, terminé preguntándome: “aun así, ¿su distanciamiento por diferenciación realmente es lo mismo que hago yo cuando descarto un incidente de borrado en producción causado por IA?”
      Es decir, si simplemente decidieran que el riesgo no les alcanza sin saber en absoluto cómo ocurrió en otra fábrica, entonces no estaría justificado
      Pero si escuchara que un gerente metió en el piso de una fábrica un robot humanoide nuevo, experimental y no determinista, y le permitió ayudar libremente a trabajadores calificados para que hicieran su trabajo más rápido, entonces no vería su indiferencia bajo la misma luz
      Aun así acepto la conclusión. Porque la imprudencia no es binaria
      La próxima vez que escuche una historia absurda, probablemente me detendré un momento a pensar: “aunque yo no sea tan descuidado como ellos, ¿qué cosas de las que hago sí ameritan más cuidado y más salvaguardas?”
    • No preguntaría por qué un niño de 3 años se comió una babosa
      Pero si un colega de 30 años se hubiera comido una babosa, investigaría a fondo cómo llegó a esa situación
      Si sintiera ganas de “culpar” a esa persona, primero preguntaría por qué contratamos a alguien que come babosas, y si eso sigue ocurriendo ahora
    • La principal conclusión que saco de este texto es que el autor no sabe qué es el bozo bit

  • Hay varios puntos válidos
    En la parte que dice “quiero explicar por qué esta reacción es contraproducente. También quiero señalar el término técnico para este fenómeno emparentado con activar el bozo bit. Se llama distanciamiento por diferenciación”, esta reacción es productiva y al mismo tiempo contraproducente
    Es productiva porque, en un mundo donde ya caen demasiados incidentes como para procesarlos todos, es una optimización enorme no tener que evaluar cada input
    Y al mismo tiempo es contraproducente por las razones que da el texto
    El verdadero truco es saber qué cosas vale la pena tomar en serio y a cuáles prestar atención. Cuando aprenda ese truco, les aviso

  • ¿Qué se supone que debo aprender del hecho de que alguien le dio acceso directo al entorno de producción a una IA?

    • Si se interpreta el incidente del LLM con algo de generosidad, la lección podría ser que el acceso a producción debe tener control de acceso, y que las operaciones destructivas deben requerir aprobación de dos personas
      Trabajé alguna vez en una empresa que estaba creciendo rápido, y muchas de sus prácticas de ingeniería se parecían más a las de una startup de garaje que a las de una multinacional de 1000 personas
      En ese momento eran ciertas tres cosas. Primero, para desplegar un servicio había que hacer cd al directorio del checkout de Git en la laptop y ejecutar <tool> deploy <service-name>, y se desplegaba exactamente el commit de Git que estuviera actualmente checkoutado
      Segundo, por una cultura de confianza entre colegas, el sistema de despliegue tenía controles de acceso mínimos. Había una allow-list de personas autorizadas para desplegar, y si estabas en ella podías desplegar cualquier servicio
      Tercero, como el repositorio principal de Git era grande y el wifi de la oficina estaba saturado, clonarlo tomaba mucho tiempo. Para que la gente nueva pudiera empezar más rápido, la imagen de aprovisionamiento de laptops incluía un checkout de Git del repositorio principal
      Entonces un día entró un nuevo practicante al equipo de base de datos y, siguiendo el tutorial del wiki Database Team 101, ejecutó el comando recomendado para verificar que sus permisos de despliegue funcionaban: <tool> deploy --prod <database>
      Resultó que la imagen de aprovisionamiento de la laptop estaba desactualizada, y el practicante todavía no había llegado a la parte del onboarding donde le enseñaban a correr git pull origin master
      La historia de “el LLM rompió producción” y la historia de “el practicante rompió producción” se parecen, pero la segunda es más fácil de aprender. Porque los errores individuales son más pequeños

  • Desde la perspectiva del análisis de incidentes, activar el bozo bit y dejar de aprender es detenerse en un solo factor contribuyente cuando en realidad hay que mirar todo el árbol de fallas, o sea: “¡error humano!”
    En el ejemplo presentado, el nodo “se le dio acceso a producción al loop del LLM” activa en el lector la heurística de “ignora a los idiotas”
    Pero su nodo hermano, “el sistema permitía borrados no verificados por API”, es una lección valiosa, y puedes perderla si te detienes en el primer nodo que resalta
    Además, el árbol de fallas también debería incluir nodos hijos que profundicen en por qué esa operación peligrosa fue eliminada del GUI pero seguía disponible en la API, y por qué el LLM llegó a tener acceso a producción

    • Por un lado, uno puede preguntarse si deberíamos asumir que es menos probable reconstruir un árbol de fallas razonable a partir de reportes provenientes de lugares bozo
      Por otro lado, quizá la verdadera pregunta es si ahí dentro hay nodos que brillan más precisamente bajo condiciones bozo
      Puede que no importe mucho si esos nodos fueron mal identificados o mal conectados. Después de todo, lo que necesito no es el árbol de fallas de sus errores pasados, sino revisar qué estoy omitiendo yo en mi propio árbol de fallas para evitar mis errores futuros

  • Este texto se salta de forma bastante evidente la parte de explicar por qué está mal activarle el bozo bit al bozo de su ejemplo central
    Pasa a un caso de paper y no aborda el ejemplo principal de su propio texto
    Así que da la impresión de que el autor está intentando dejar pasar discretamente a otro bozo

  • Sí aprendí algo: no usar herramientas de IA