Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

🖥️ Diapositivas — Sesión 03 (lun 5 oct)

Esta página le da el vocabulario de trabajo para el resto del capítulo: qué calcula realmente un modelo de lenguaje de gran escala (LLM), cómo uno se convierte en un «agente» y qué modos de falla provienen de qué parte de la maquinaria. Saber por dónde entran los errores es lo que le permite buscarlos.

Qué calcula un LLM

Un modelo de lenguaje de gran escala es un transformer — la arquitectura basada en atención cuya mecánica cubrimos con los modelos de secuencias en el capítulo 4.4 — entrenado para predecir el siguiente token del texto. La atención permite que cada token se condicione a todos los tokens anteriores (la generación corre de izquierda a derecha, así que la atención está enmascarada causalmente: ningún token ve su propio futuro), y por eso estos modelos manejan estructura de largo alcance (una variable definida 200 líneas antes, una afirmación hecha tres párrafos atrás) que los modelos de secuencias más antiguos perdían. Escalada a miles de millones de parámetros y entrenada sobre una fracción grande del internet público, la predicción del siguiente token resulta producir un motor general de texto-entra, texto-sale: resumen, traducción, código y respuesta a preguntas se vuelven todos «continúe este texto de forma plausible».

Tres etapas de entrenamiento convierten ese motor en un asistente:

  1. Preentrenamiento: predecir el siguiente token sobre un corpus enorme. De aquí viene el conocimiento del lenguaje, del código y (de forma imperfecta, hasta una fecha de corte del entrenamiento) del mundo.
  2. Ajuste por instrucciones: entrenamiento adicional sobre pares curados (instrucción, buena respuesta), para que el modelo responda las preguntas en vez de meramente continuarlas.
  3. Aprendizaje por refuerzo a partir de retroalimentación humana (RLHF) y sus sucesores: se entrena un modelo de preferencias sobre clasificaciones humanas de respuestas y luego se optimiza el LLM contra él. Esto hace que los modelos sean útiles y corteses. También los hace complacientes — un sesgo que usted medirá en 6.2, porque un modelo ajustado para agradar a los evaluadores tiende a agradarle a usted, incluso cuando usted está equivocado sharma2023sycophancy.

Dos hechos mecánicos que debe tener presentes:

Ventanas de contexto. El modelo ve una ventana finita de tokens — cientos de páginas en los modelos actuales, pero finita, y la atención sobre contextos muy largos se degrada: el material que está en medio de un contexto largo se recuerda con menos confiabilidad que el material cercano a sus extremos liu2024lost. Consecuencia práctica para el uso en investigación: un agente que «lee» su repositorio de 40 archivos lo está muestreando y resumiendo, y puede responder con toda confianza a partir de las partes que atendió.

Tokenización, y por qué los LLM son malas calculadoras. El texto se divide en tokens — fragmentos de subpalabra, ni caracteres ni palabras. Los números se fragmentan arbitrariamente: 13.847 puede volverse 13, ., 847. El modelo no tiene un tipo numérico; los dígitos son solo vocabulario. Así que la aritmética es completado de patrones sobre cadenas de dígitos, lo cual funciona para los patrones comunes y falla silenciosamente en lo demás. Lo mismo aplica con más fuerza a las series numéricas: pegar 3650 desplazamientos GNSS diarios en un prompt (instrucción) y pedir la tendencia es entregarle un problema de regresión a un motor de completado de texto. Responderá, con fluidez, y el número será aproximadamente plausible. La solución no es un mejor prompt; es darle al modelo una calculadora — que es justamente el sentido del uso de herramientas, abajo. Un agente bien construido al que se le pide una velocidad GNSS debería escribir y ejecutar código de numpy, no «leer» los números.

Generación aumentada por recuperación (RAG)

El conocimiento del preentrenamiento está congelado en una fecha de corte y es borroso a nivel de los detalles. RAG le acopla una memoria: los documentos se dividen en fragmentos y se representan como vectores (las ideas de representación del capítulo 3), la pregunta del usuario recupera los fragmentos más similares, y el texto recuperado se coloca en la ventana de contexto con la instrucción «responda a partir de estos documentos». El modelo ahora cita material sobre el que nunca fue entrenado.

Ejemplo geocientífico: un sistema RAG sobre el corpus de metadatos de estaciones de su red (respuestas instrumentales, bitácoras de despliegue, reportes de problemas de datos). «¿Qué estaciones de banda ancha cerca del margen de Cascadia tuvieron problemas conocidos de sincronización de tiempo en 2021?» se vuelve recuperable y respondible con fuentes. El modo de falla también se desplaza: una respuesta RAG es solo tan buena como su recuperación, y el modelo sintetizará con gusto una respuesta a partir de los fragmentos equivocados. Cuando evalúe un sistema RAG, evalúe las fuentes recuperadas, no solo la prosa.

Uso de herramientas: lo que hace a un agente

La llamada a funciones permite que un modelo emita, en lugar de prosa, una solicitud estructurada — query_catalog(min_magnitude=5, region="Cascadia", since="2020-01-01") — que su código ejecuta, devolviendo el resultado al contexto del modelo. Un agente no es nada más exótico que:

un LLM + un conjunto de herramientas + un bucle sobre observaciones.

El modelo propone una acción, el arnés la ejecuta, la observación regresa al contexto, y el modelo propone la siguiente acción, hasta que decide que la tarea está terminada. Leer archivos, ejecutar Python, buscar en la web y consultar un catálogo sísmico FDSN son todas, simplemente, herramientas dentro del bucle. Un agente al que se le pregunta «¿cambió la tasa de sismicidad después del evento M6.4 de 2022?» puede consultar el catálogo, escribir la prueba de cambio de tasa, ejecutarla, mirar los números y revisar — una tarea científica genuina de varios pasos.

Esta arquitectura reubica la confianza. La aritmética ahora la hace numpy, que es confiable. Lo que sigue siendo no confiable es todo lo que el modelo aún decide: cuáles datos consultar, cuál prueba correr, si se manejó la magnitud de completitud, si un resultado vacío de la consulta significa «no hubo sismos» o «la solicitud estaba mal». Los errores de los agentes por lo general no son errores de cálculo; son errores de especificación y de juicio. Por eso 6.3 evalúa a los agentes de principio a fin contra una verdad de referencia en lugar de revisar su código línea por línea.

Un párrafo sobre los modelos de razonamiento y el cómputo en tiempo de inferencia: los modelos actuales se pueden correr de modo que generen largas cadenas internas de trabajo intermedio — redactar, comprobar, retroceder — antes de responder, gastando más cómputo por consulta a cambio de mejor desempeño en matemáticas, código y problemas de varios pasos. Esto ayuda de forma confiable, y cambia el modelo de costos (una pregunta difícil cuesta más que una fácil). No cambia sus obligaciones: una respuesta equivocada después de diez mil tokens de deliberación sigue siendo equivocada, y un «razonamiento» largo y visible puede hacer que los errores sean más persuasivos, no menos frecuentes.

Modelos de pesos abiertos frente a modelos por API

Usted puede llamar a un modelo de frontera alojado a través de una API, o correr localmente un modelo de pesos abiertos (pesos descargables, ejecutados en su propio hardware). Las disyuntivas son genéricas y vale la pena razonarlas proyecto por proyecto y no por moda:

Modelo de frontera por APIPesos abiertos, autoalojado
CapacidadLa más alta disponibleLos modelos más pequeños han cerrado buena parte de la brecha; todavía suelen ir detrás de la frontera
Estructura de costosPor token; escala con el usoHardware y configuración por adelantado; costo marginal casi nulo
LatenciaIda y vuelta por la red; límites de tasaLocal; usted controla el rendimiento
PrivacidadLos datos salen de su máquina — revise los términos antes de enviar datos no publicados o material sujeto a control de exportacionesLos datos se quedan locales; a menudo el factor decisivo para datos clínicos, propietarios o previos a publicación
ReproducibilidadLos modelos alojados cambian bajo sus pies; fije la versión cuando el proveedor lo permitaUsted controla los pesos exactos para siempre — fíjelos como cualquier dependencia (capítulo 5)

Para flujos de trabajo científicos por lotes — extracción estructurada de diez mil resúmenes, digamos — un modelo pequeño de pesos abiertos con un conjunto de evaluación bien diseñado a menudo supera a un costoso modelo de frontera sin ninguno.

Alucinación: un modo de falla distinto del error

Un error ordinario es una respuesta equivocada producida por un proceso rastreable — un fallo de programación, un supuesto malo, ruido. La alucinación es fabricación fluida: el modelo produce contenido específico, seguro y bien formateado sin fuente alguna, porque generar texto plausible es exactamente aquello para lo que está optimizado. La distinción importa porque sus instintos de detección de errores están calibrados para los errores ordinarios, que por lo general se ven mal de algún modo. El contenido alucinado está seleccionado por verse bien.

El caso científico canónico es la cita fabricada: autores que suenan reales, un título plausible, una revista real, un DOI bien formado que no resuelve a nada. La extracción estructurada tiene una versión más sutil: pídale a un modelo que extraiga magnitudes, profundidades y ubicaciones de cincuenta resúmenes hacia una tabla, y la mayoría de las filas estarán bien mientras unas pocas contendrán valores que no aparecen en ninguna parte del texto fuente, formateados de forma idéntica a los correctos. Nada las marca.

Las consecuencias, que los dos cuadernos siguientes convierten en práctica:

Trate la salida de un LLM como trata una medición de un instrumento sin calibrar: posiblemente excelente, inutilizable hasta que haya corrido su propia calibración. Construir esa calibración son los dos cuadernos siguientes.