Huyen parte de una distinción que en las conversaciones de venta se pierde: una cosa es entrenar un modelo y otra construir un producto encima de un modelo que ya existe. Lo segundo es casi todo lo que se hace hoy en una empresa mediana, y tiene sus propios problemas: elegir el modelo, medir si sirve, ajustarlo, controlar el costo por respuesta y cerrar el circuito con lo que dicen los usuarios.
Qué hice con él
El orden de adaptación es lo que más uso. Primero lo barato y reversible —cambiar lo que se le pide al modelo—, después traer los documentos propios al contexto, y solo al final ajustar el modelo. Al revés se gasta mucho y se aprende poco, y ajustar un modelo antes de saber qué está fallando es la forma más cara de descubrir que el problema eran los datos.
Los capítulos de evaluación me dejaron una regla de trabajo: no se empieza a construir hasta que existe la forma de saber si quedó bien. Eso significa un conjunto de casos con su respuesta esperada, escrito con quien conoce el negocio, antes de la primera línea. Cuesta un día y ahorra el mes en el que nadie se pone de acuerdo sobre si mejoró.
Y una tercera, de arquitectura: el modelo es una pieza intercambiable, no el centro. Si la aplicación está escrita de manera que cambiar de proveedor sea una decisión de días, uno negocia con los precios que hay hoy y no con los que firmó hace un año.
Qué dejé fuera
La parte de optimización de inferencia, que es excelente y no es mi problema: quien paga por uso no se pelea con la memoria de una tarjeta gráfica. Y las cifras concretas de modelos y precios, que ya envejecieron mientras el libro se imprimía. Lo que no envejece es el método, y es la mitad del libro.