Automatizando a la IA: Cómo las herramientas deterministas reemplazan a los LLMs
Automating AI Away
Desarrollo Beagle SCM con Anthropic's Fable, un modelo brillante pero torpe que comete errores no deterministas. La solución no es esperar que la IA sea perfecta, sino envolver su inconsistencia entre herramientas deterministas y procesos formales. Al automatizar las rutinas que la IA repite o falla, permitimos que el modelo se automatice a sí mismo, dejando el trabajo pesado a herramientas confiables escritas en C y JavaScript.
La forma de lidiar con un LLM caro, lento y torpe pero brillante es darle herramientas rápidas, potentes y deterministas, y construir todo dentro de un flujo de trabajo formal determinista.
- bob1029
Creo que la semi-automatización con herramientas contextuales y específicas del dominio es la clave para obtener los mejores resultados.
Por ejemplo, con la automatización del navegador, dar acceso directo al DOM literal al LLM generalmente resulta en un desastre para tareas que necesitan ser estables en más de 5-10 interacciones. El mejor enfoque es escribir una capa intermedia que entienda cada vista y pueda proporcionar una lista de herramientas adaptadas con precisión para cada caso. Por ejemplo:
- <raw dom - cientos de kb>
- Herramientas disponibles: <javascript arbitrario>
frente a
- Hemos detectado que esta es la página de inicio de sesión de la aplicación.
- Tiene los siguientes elementos visibles:
+ Nombre de usuario
+ Contraseña
+ Botón de inicio de sesión
- Herramientas disponibles:
+ RealizarInicioDeSesión
+ Salir
El segundo caso requiere mucho más esfuerzo, pero también reduce un espacio de problemas Turing-completo a una decisión binaria en este paso en particular.
- contextfree
Un hábito más tonto pero relacionado que he adoptado es que, si quiero usar IA para realizar algún tipo de refactorización en una base de código de C#, en lugar de pedirle que edite el código directamente, le pido que escriba una transformación de código utilizando la API del compilador Roslyn y luego ejecutar eso sobre el código. El resultado es menos propenso a tener errores sutiles si parece funcionar y pasa una revisión de código ligera de la transformación (es decir, los intentos de hacer trampa con casos especiales extraños son más propensos a destacar entre el código de la API de Roslyn, y si no hay tales casos especiales extraños pero el código está mal, el resultado es más probable que esté completamente roto en lugar de sutilmente roto).
- lubujackson
Tiene sentido; he tenido los mayores éxitos con la IA atacando la no determinismo siempre que es posible.
PD: Probablemente deberías corregir el enlace de Beagle en tu página de inicio: https://replicated.live/beagle/
- derdi
Esta es una introducción muy interesante a una entrada de blog, pero... de alguna manera me falta la entrada de blog real. ¿Cómo funciona esto en la práctica? ¿Cuáles son algunos ejemplos concretos? ¿Cómo se pasa de que JavaScript tokenice cosas en un commit hook a validar que el LLM no deshabilitó pruebas con las que no estuvo de acuerdo, o cualquier otra propiedad útil?
- Animats
Tiene sentido, aunque no está bien descrito aquí.
Los métodos formales, como la prueba de corrección, existen desde hace décadas (yo hacía eso en la década de 1980), pero empujar las pruebas era demasiado laborioso. Se dice que el esfuerzo de verificación de seL4 utilizó más de una década de tiempo de personas.
La idea es que si tienes una especificación formal de lo que quieres que ocurra, puedes pedirle a un LLM que lidie con el sistema de pruebas para lograrlo correctamente. Es una buena tarea para un LLM, porque hay retroalimentación del probador.
Me gustaría ver más ejemplos no triviales de esto. La gente sigue republicando verificaciones del máximo común divisor o algoritmos de pila, lo cual ya se hizo hace décadas.