Resumen del curso/Configura el espacio de trabajo2 de 4
Qué puedes delegar y qué no
Qué puedes delegar y qué no
Distingue un fallo evidente de uno silencioso y descubre por qué debes auditar el SQL que no escribiste.
Fallos evidentes y fallos silenciosos
Ya sabes por la lección anterior qué es una consulta: una pregunta escrita en SQL, enviada a una base de datos y respondida con filas. Todo el curso gira en torno a la distinción entre dos formas en que una consulta puede fallar.
Un error de sintaxis - una errata, una columna mal escrita o una coma que falta - te cuesta un minuto. La base de datos se niega a ejecutar la consulta y te dice dónde está el problema. Ese es un fallo evidente: se detiene, se queja y lo arreglas antes de que nadie vea un número. Una consulta que se ejecuta, devuelve un número y está equivocada puede costar un trimestre. Ese es un fallo silencioso: funciona y devuelve la respuesta incorrecta, y nada te avisa. El número llega a un informe, alguien actúa basándose en él y el error sale a la luz semanas después.
Los fallos evidentes son baratos porque la herramienta los encuentra por ti. Los fallos silenciosos son caros porque solo puede detectarlos alguien que sepa leer la consulta. Convertirte en esa persona es el objetivo de este curso.
Un agente escribe sintaxis SQL correcta más rápido que tú. En esquemas de manual - un esquema es el diseño completo de una base de datos: qué tablas existen y qué columnas tiene cada una - los modelos actuales responden correctamente a preguntas en lenguaje natural más del 90 % de las veces. En esquemas empresariales reales, con cientos de tablas y columnas cuyos nombres inducen a error, los mismos modelos de vanguardia bajan a alrededor del 20 %. La diferencia no está en la sintaxis. Los modelos siguen produciendo SQL válido. El fallo es semántico: qué columna contiene los ingresos que buscas, qué filas debes excluir y qué unión duplica silenciosamente un total.
Un agente no puede saber que net_price es la columna de ingresos y unit_price no lo es, a menos que alguien se lo diga. Tampoco puede saber que un pedido puede no tener estado o que dos tablas unen una fila con muchas. Esos hechos están en tu cabeza, en los datos y en los archivos que entregas al agente. Por eso auditas el SQL que no escribiste, incluso cuando se ejecuta.
La misma distinción, desarrollada con un ejemplo de este conjunto de datos, está en docs/failure-modes.md del proyecto; tendrás ese archivo en tu máquina después de la configuración de la siguiente lección. La sección 2 te hace escribir SQL a mano antes de delegar nada, no porque te dediques a teclear SQL, sino porque no puedes auditar lo que no puedes leer.
Comprueba lo que has entendido
- ¿Cuál es la diferencia entre un fallo evidente y uno silencioso?
- ¿Por qué una consulta que se ejecuta correctamente necesita revisión?
- Nombra una cosa que un agente no puede saber sobre tus datos si no se la dices.
Hazlo con tu agente
Esta es una lección conceptual: todavía no hay nada que construir. Di next lesson y tu agente te guiará por ella y comprobará que la has seguido con unas preguntas. Después di next lesson de nuevo para continuar.