La ingeniería de harness no tiene una dirección fija
La ingeniería de harness no es un lugar en tu pila de software. Es una propiedad de tu código.
Mucha gente piensa que el harness es solo un envoltorio (wrapper) alrededor de un modelo de IA. Esto es un error. El harness es lo que hace que un modelo sea útil para un negocio real.
Utilizo una fórmula sencilla: Agente = Modelo × Harness.
El modelo es el motor. El harness es la dirección, los frenos y las barandillas de seguridad.
Pero aquí está el problema. El modelo está creciendo constantemente. Cada nueva versión del modelo absorbe partes del harness.
- Los modelos de razonamiento ahora gestionan la lógica de cadena de pensamiento (chain-of-thought).
- Los modelos mejores gestionan el uso de herramientas de forma nativa.
- Las ventanas de contexto largas reemplazan los antiguos sistemas de memoria.
Si el modelo se "come" el harness, ¿qué queda por construir?
Las partes que se funden son la mecánica. Los bucles, los reintentos y la unión de memoria (memory stitching) se convertirán en commodities. No apuestes tu carrera a construir tuberías.
Las partes que permanecen son la especificación y la verificación.
- Especificación: Debes definir qué tiene permitido hacer el agente. Un modelo no puede conocer tu política de reembolsos específica o tu tolerancia al riesgo. Eso reside en tu código.
- Verificación: Debes demostrar que el agente se mantuvo dentro de tus reglas. Un modelo no puede juzgarse a sí mismo de forma fiable. Necesitas una capa externa para revisar el trabajo.
Piensa en un agente de reembolsos.
Si pones el límite de reembolso en un prompt, un usuario puede engañar al modelo. Si pones el límite en una sentencia if en tu código, el modelo no puede discutirlo.
Esa sentencia if es ingeniería de harness.
La ingeniería de harness trata de dos cosas:
- Definir el perímetro del comportamiento permitido.
- Demostrar que el agente se mantuvo dentro de él.
El modelo es la planta que estás controlando. La especificación es tu objetivo. El harness es el controlador. Las evaluaciones son la retroalimentación.
Las herramientas y la mecánica cambiarán cada mes. La disciplina de la especificación y la verificación no.
Deja de construir tuberías. Empieza a construir restricciones y pruebas.
Source: https://dev.to/saurav_bhattacharya/harness-engineering-has-no-fixed-address-2m7a
Optional learning community: https://t.me/GyaanSetuAi