El libro tiene un proyecto que lo atraviesa de principio a fin: un sistema que aprende a escribir como su dueño. Sirve de excusa para recorrer todo lo que hay alrededor de un modelo —recolección de datos, preparación de conjuntos, ajuste fino, alineación por preferencias, recuperación de documentos, evaluación, despliegue y vigilancia— y ese recorrido completo es su mejor cualidad.
Qué saqué de él
La separación en tres tuberías: una que ingiere y prepara, otra que entrena, otra que responde. Parece un detalle de ingeniería y es una decisión de arquitectura con consecuencias comerciales: si están separadas, se puede cambiar el modelo sin tocar la ingesta, o rehacer la ingesta sin volver a entrenar nada. Si están enredadas, cualquier cambio obliga a repetirlo todo y el mantenimiento se come el presupuesto. Desde que lo leí, la primera pregunta que hago frente a un sistema con IA que ya existe es por dónde pasa la frontera entre esas tres cosas.
La segunda idea es menos glamorosa: casi todo el trabajo es plomería de datos. Traer, limpiar, versionar, saber de dónde salió cada cosa. El libro insiste en versionar los conjuntos de datos y las instrucciones igual que se versiona el código, y tiene razón: sin eso, nadie puede explicar por qué el sistema respondía mejor el mes pasado.
La tercera, que uso al cotizar: la vigilancia no es un extra, es parte del sistema. Un modelo no se rompe con un error visible, se degrada en silencio.
Qué dejé fuera
El ajuste fino, que es donde el libro pone más páginas. Para casi todo lo que pide una empresa mediana, recuperar los documentos correctos y escribir bien la instrucción rinde más y cuesta menos que entrenar un modelo propio. Se escriben más capítulos sobre ajuste fino porque es la parte interesante de contar, no porque sea la que más veces hace falta. También dejé fuera los capítulos de despliegue atados a una nube concreta.