Trust, but Trace
EN ES
Empieza aquí · Antes de la parte 1 de 12

Qué da por sabido
esta serie

Esta serie está pensada para un ingeniero que se pasa a la ingeniería de ML y solo deja fuera a quien empieza de cero. Conviene precisarlo, porque la barrera que frena a la mayoría es imaginaria.

Lo que
da por sabido

Ingeniería de software normal y corriente.

Si sabes leer un fichero de Python, ejecutar algo en una terminal y razonar sobre cuánto cuesta un programa, tienes lo necesario.

  • Saber leer Python. Basta con leerlo, aunque no lo escribas con soltura. Ningún ejemplo de código llega a las quince líneas.
  • Una terminal y git. Lo justo para clonar un repositorio y mirar qué hay dentro.
  • Qué te da un sistema de tipos. La comparación de la parte 3 solo cala si alguna vez un comprobador de tipos te ha cazado algo.
  • Cuánto cuesta un pipeline. Que unas etapas son baratas y otras no, y que la diferencia se puede medir.

En esas dos últimas se apoya toda la serie. Al pasar a la ingeniería de ML, lo que sabes de software sigue valiendo, solo que cambia de sitio. De ese cambio sale la mayoría de las sorpresas.

Lo que
no da por sabido

La barrera imaginaria.

No hace falta cálculo, ni haber hecho un curso de álgebra lineal, ni haber usado PyTorch. Las matemáticas no pasan de la aritmética y alguna que otra raíz cuadrada. Cuando aparece una fórmula, se escribe en código y se contrasta con un número.

Las partes leen ficheros reales (el model.py de nanoGPT, el modeling_llama.py de transformers) como leerías cualquier código desconocido: buscas el punto de entrada, sigues las formas de los tensores, lo ejecutas y lo rompes a propósito. Eso ya sabes hacerlo.

Nada de esto te ahorra aprender las matemáticas tarde o temprano. Lo que digo es que no te hacen falta para empezar y que quien espera a saberlas no empieza nunca.

Si te
falta algo

Mejor la fuente que un resumen.

Son los sitios a los que mandaría a alguien. Ninguno es mío y cada uno es la referencia en lo suyo.

Cómo
leerla

En orden y sin prisa.

En orden. Cada parte termina justo en lo que recoge la siguiente (la 3 acaba en un cuadrado y la 4 es la que lo llena), así que si las lees en otro orden esos relevos se pierden.

Una idea por parte. Cada una señala una sola cosa que no se comporta como en el software (una forma que nadie comprueba, un coste que el código no deja ver). Si te quedas con una frase de cada parte, que sea esa.

Las demos son el experimento. Ninguna está de adorno. Cada una es la medición que describe la sección, con las entradas libres para que las muevas y veas cambiar el número.