El mecanismo (lo que vimos)

• Un LLM predice el próximo token, no la verdad
• Procesa texto como subpalabras (tokens BPE)
• Usa atención para ponderar qué contexto importa
• Los embeddings son contextuales: la misma palabra cambia de vector según el entorno
• La escala (parámetros, datos, cómputo) produce emergencia: capacidades nuevas que aparecen solo a partir de cierto tamaño

La consecuencia (donde quedamos)

• El modelo optimiza \(P(\text{token} \mid \text{contexto})\), no \(P(\text{verdad})\)
• Por eso alucina: genera contenido fluido pero falso
• Casos teaser: el abogado de Nueva York con seis casos fantasma y otros ejemplos de alucinación

El problema y las defensas

• El problema central + caso completo del abogado
• Defensa 1: buenos prompts
• Defensa 2: salida estructurada
• Defensa 3: grounding con RAG
• Defensa 4: validación y reproducibilidad

Aplicación y herramientas

• Aplicaciones en investigación social
• LLMs vs métodos clásicos
• Cómo correr LLMs desde R:
  • OpenRouter (API agregadora, tier gratuito)
  • Ollama (modelos locales)
  • El paquete ellmer

• Los LLMs son excelentes generadores de texto plausible
• También son pésimas fuentes de verdad sin verificación
• En investigación social esto importa especialmente:
  • Trabajamos con hechos (eventos, fechas, citas, estadísticas)
  • Necesitamos reproducibilidad para que otros validen
  • Nuestros lectores confían en lo que publicamos
• Un LLM que inventa un nombre, una fecha o una cita no es solo molesto: arruina la investigación

• Mata vs. Avianca Inc., Tribunal del Distrito Sur de Nueva York, 2023
• El demandante (Roberto Mata) alegaba lesiones por un carrito de servicio en un vuelo
• Sus abogados pidieron a ChatGPT precedentes legales para apoyar el caso
• El modelo generó seis casos completos:
  • Nombres de partes (Varghese v. China Southern Airlines)
  • Tribunales y jurisdicciones
  • Números de expediente
  • Citas con páginas exactas
  • Argumentos detallados
• Los seis eran completamente ficticios
• Los abogados los presentaron sin verificar

• Fabricación: el modelo inventa datos, nombres, fechas o eventos que no existen
• Citas falsas: papers académicos, libros, números de expediente con apariencia real pero inventados
• Sicofancia (sycophancy): el modelo acuerda con la premisa del usuario aunque sea falsa (“Sí, claro, ese estudio existe…”)
• Atribuciones erróneas: asigna una frase a un autor que nunca la dijo
• Confabulación silenciosa: cuando no sabe algo, llena el vacío con texto plausible en lugar de admitir ignorancia

• Un buen prompt reduce la varianza de la respuesta hacia lo que quieren. Mismo modelo y mismo input: distintos prompts dan resultados muy distintos
• Es prompt engineering. Sus cuatro componentes son el framework PTCF:
  • Persona: ¿quién es el modelo? (“Sos un analista político…”)
  • Tarea: ¿qué tiene que hacer? (“Clasificá la orientación ideológica…”)
  • Contexto: lo que necesita saber (categorías, origen del texto)
  • Formato: estructura de salida (JSON con campos definidos)
• No siempre hacen falta los cuatro: usen los que apliquen
• Fuente: Google (2024)

• El system prompt se envía antes de cualquier mensaje del usuario
• Establece reglas que valen para toda la conversación: rol, restricciones, formato
• Es la forma más efectiva de obtener comportamiento consistente cuando procesan muchos documentos

Ejemplo para anotación sistemática

Sos un asistente de codificación para
investigación en ciencias sociales en
América Latina.

Reglas:
- Respondé siempre en español
- Si no estás seguro, decilo explícitamente
- No inventes datos ni estadísticas
- No agregues comentarios fuera del JSON
- Formato: JSON estricto, sin texto antes o después

Zero-shot: sin ejemplos

Clasificá el sentimiento de
este texto como positivo,
negativo o neutro:

"La economía creció un 5%
pero el desempleo subió."

Funciona para tareas simples y bien definidas. Lo que vimos en la Sesión 4.1 como emergencia hace esto posible

Bueno para empezar y baseline

Few-shot: con ejemplos

Ejemplos:
- "La inflación es alta" → negativo
- "El empleo mejoró" → positivo
- "Los datos son de 2023" → neutro
- "Cayó la pobreza pero subió
  la deuda" → mixto

Clasificá:
"El crecimiento fue moderado" →

Mejora la precisión al mostrar el formato y los matices (Brown et al., 2020; Min et al., 2022)

Tres a cinco ejemplos suelen ser óptimos

Ojo: ejemplos mal elegidos o sesgados pueden empeorar el resultado. La calidad importa más que la cantidad

La técnica

Pedir al modelo que razone explícitamente antes de responder

Antes de clasificar, razoná paso a paso:

Texto: "A pesar de la crisis, el
gobierno logró reducir la pobreza."

Razonamiento:
1. "crisis" es contexto negativo
2. "logró reducir la pobreza" es resultado positivo
3. "a pesar de" indica contraste
4. El resultado supera al contexto

Clasificación: POSITIVO

Modelos de razonamiento (o-series, DeepSeek R1, extended thinking) ya hacen CoT internamente: a veces conviene elegir uno en vez de escribir los pasos a mano

Por qué funciona

• El modelo distribuye el “esfuerzo” en varios tokens
• Captura mejor negaciones, ironías y contrastes
• Mejora notablemente las tareas de razonamiento (Wei et al., 2022)

Cuándo usarlo

• Razonamiento numérico
• Clasificación con varios matices
• Cualquier tarea donde “la primera reacción” del modelo no basta

Costo: respuestas más largas → más tokens → más caro. Vale la pena para tareas complejas

• La temperatura controla qué tanto el modelo se aparta del token más probable (Holtzman et al., 2020; Renze y Guven, 2024)
• Va típicamente de 0 a 1
• Para investigación, casi siempre temperatura baja:
  • Análisis y clasificación: 0,0 - 0,2
  • Resumen factual: 0,2 - 0,4
  • Análisis abierto con creatividad: 0,3 - 0,5
  • Escritura creativa: 0,7 - 1,0
• Temperatura 0 no garantiza determinismo absoluto en APIs comerciales (cambios entre versiones, sampling en GPU), pero se acerca
• Para máxima reproducibilidad: usar modelos locales con seed fijo

• El problema de la salida en prosa: imposible de parsear consistentemente
  • El modelo a veces empieza con “Claro, aquí está mi análisis…”
  • A veces incluye comentarios fuera del JSON
  • A veces cambia el orden de las claves
• La solución: pedir una estructura fija, idealmente JSON
• JSON es legible para humanos y parseable por R con jsonlite

• Pedir “JSON” en texto plano no garantiza que el modelo lo respete
• A veces lo viola: agrega comas finales, mezcla mayúsculas, cambia tipos
• Mejor: usar APIs que fuerzan un tipo durante la generación
  • Structured Output de OpenAI: garantiza que la salida cumpla un esquema JSON
  • Tool calling de Anthropic: el modelo “llama” a funciones con tipos
  • Tipos de ellmer: el paquete R abstrae estas funcionalidades
• Ventaja: su código R recibe una estructura validada, no texto a parsear
• Lo aplicaremos en los labs (con ellmer y quallmer)

• Los LLMs tienen conocimiento congelado en su fecha de corte de entrenamiento
• No saben:
  • Eventos posteriores al entrenamiento
  • Sus documentos privados o internos
  • Su corpus específico de investigación
• Pero el modelo igual intenta responder, y ahí aparece la alucinación

Ejemplo típico

Preguntar a un LLM sobre un artículo académico que el usuario tiene como PDF:

• El modelo no lo conoce
• Pero puede inventar citas, autores y conclusiones

Sí usar RAG cuando

• Su corpus es grande (cientos o miles de documentos)
• Necesitan actualizar la base de conocimiento sin reentrenar
• Necesitan trazabilidad: ¿de qué documento salió esta afirmación?
• Trabajan con dominio muy específico (papers, leyes, transcripciones)
• Quieren que el modelo cite fuentes reales

No necesitás RAG cuando

• El documento entra en el prompt directamente (ventanas de 200K+ tokens permiten artículos completos)
• La tarea es de razonamiento general, no de recuperación factual
• La tarea es creativa (escribir, brainstormear)
• No tienen base de conocimiento estable: quieren que el modelo use su entrenamiento

• Los LLMs son un desafío para la reproducibilidad
• Razones:
  • Los modelos se actualizan (GPT-4 de marzo ≠ GPT-4 de diciembre)
  • Las APIs pueden cambiar comportamiento silenciosamente
  • Temperatura > 0 introduce aleatoriedad
  • Los modelos cerrados son cajas negras
• Buenas prácticas:
  • Documentar modelo exacto, versión, fecha
  • Guardar los prompts completos usados
  • Usar temperatura 0 cuando se pueda
  • Guardar las respuestas crudas, no solo lo procesado
  • Para máxima reproducibilidad: modelo local con versión fija

• El uso más común en ciencias sociales: clasificar texto a escala
• Ayer usamos diccionarios, TF-IDF y LDA. Los LLMs hacen lo mismo con mejor calidad en muchas tareas:
  • Capturan contexto y significado, no solo palabras
  • Manejan negaciones (“no es bueno” = negativo)
  • Manejan ironía y sarcasmo mejor que diccionarios
  • Funcionan multilingüe sin reentrenar
• Evidencia: Gilardi, Alizadeh y Kubli (2023) muestran que ChatGPT supera a anotadores de crowdsourcing (MTurk) en varias tareas de clasificación de tweets
• Costo: centavos por texto vs. dólares por anotador humano

• Datos sintéticos: datos generados por un LLM que imitan datos reales
• Casos legítimos en investigación:
  • Pilotos: probar un análisis antes de recoger datos reales
  • Aumentación: expandir datasets pequeños cuando es difícil obtener más datos
  • Privacidad: generar datos que preserven patrones sin exponer individuos
  • Entrenamiento: crear ejemplos para entrenar clasificadores
• Precauciones serias:
  • Los datos sintéticos reflejan los sesgos del modelo que los genera
  • No reemplazan datos reales para conclusiones sustantivas
  • Deben ser validados contra datos reales cuando se pueda

• ellmer (ellmer.tidyverse.org) es el paquete oficial de Posit para hablar con LLMs desde R
• Una sola interfaz para todos los proveedores:
  • chat_openrouter(), chat_ollama(), chat_openai(), chat_anthropic(), chat_google_gemini()
• Funciones principales:
  • chat$chat(): enviar un mensaje
  • chat$chat_structured(): extraer datos con tipos validados (las defensas 1 y 2 en una sola llamada)
  • chat$tokens(): contar tokens usados
• Trabaja bien con purrr::map() para procesar muchos textos en pipeline

Más detalles en los Laboratorios 7 y 8

Lo que aprendimos hoy

• Defensa 1: buenos prompts (PTCF, system prompts, few-shot, CoT, temperatura baja)
• Defensa 2: salida estructurada (JSON con tipos estrictos)
• Defensa 3: grounding con RAG (cuando su corpus no entra en el contexto)
• Defensa 4: validación contra gold standard + reproducibilidad

Herramientas

• OpenRouter para empezar sin tarjeta
• Ollama para modelos locales y privacidad
• ellmer como interfaz unificada

Regla de oro