IA para Científicos Sociales

Sesión 5.1: Modelos de lenguaje locales

Danilo Freire
danilofreire@gmail.com

Department of Data and Decision Sciences
Emory University

Repaso del día 4

Cómo funcionan los LLMs

  • Predicen el próximo token a partir del contexto
  • Tokens, embeddings, atención, transformers
  • La escala produce capacidades emergentes

Cómo usarlos en investigación

  • Las cuatro defensas: prompts, salida estructurada, RAG, validación
  • ellmer como interfaz única desde R
  • quallmer para crear codebooks y mejorar la reproducibilidad y la transparencia de los análisis con LLMs

Hasta ahora: la nube

  • Usamos modelos a través de OpenRouter y APIs comerciales
  • Funciona, pero el texto sale de nuestra computadora hacia un servidor externo

Hoy: el otro camino

Correr un LLM enteramente en nuestra propia máquina, sin internet, sin API, sin que los datos salgan de ahí

Agenda de la sesión

  • ¿Por qué correr modelos localmente? Privacidad, costo, reproducibilidad
  • Pesos abiertos: qué son y por qué la ciencia los necesita
  • Cuantización: cómo entra un LLM en una laptop común
  • Usos en investigación social: datos sensibles, corpus grandes, replicación
  • Ollama: correr un LLM desde la terminal y personalizarlo con un Modelfile
  • Conectar el modelo local con R: ellmer y quallmer
  • Límites de los modelos locales


En el laboratorio de hoy lo ponemos en práctica con codificación cualitativa

¿Por qué correr modelos localmente?

La nube tiene un costo oculto

  • Cuando usamos un LLM en la nube, nuestro texto viaja a un servidor de OpenAI, Google o un agregador
  • Para muchas tareas, eso está bien. Pero en investigación social a veces el texto es sensible:
    • Entrevistas con sujetos humanos
    • Datos bajo acuerdo de confidencialidad
    • Archivos restringidos o con información personal
  • Subir esos datos a una API puede violar el consentimiento o las reglas del comité de ética
  • También dependemos de que la empresa no cambie ni retire el modelo que usamos

Correr local resuelve varias cosas a la vez

  • Privacidad: los datos nunca salen de su máquina
  • Costo: cero por uso, sin tarjeta
  • Reproducibilidad: la versión exacta del modelo queda congelada en su disco
  • Autonomía: funciona sin internet y nadie puede quitárselo

Nota

Pista: para datos de sujetos humanos, “local” no es un lujo técnico, es muchas veces un requisito ético.

¿Cuándo conviene local y cuándo la nube?

Criterio Modelo local (Ollama) Modelo en la nube
Privacidad Los datos no salen de su máquina El texto viaja a un servidor externo
Costo Cero por uso Gratuito limitado o pago por uso
Reproducibilidad Versión exacta congelada Puede cambiar entre versiones
Calidad Buena, por debajo de los de frontera La mejor disponible
Velocidad Depende de su hardware Rápida y constante
Requisitos 8+ GB de RAM, descarga inicial Solo una conexión y una API key


Regla práctica: datos sensibles o necesidad de reproducibilidad → local. Máxima calidad o prototipo rápido → nube

Modelos de pesos abiertos

¿Qué es un modelo de pesos abiertos?

  • Los pesos son los miles de millones de parámetros que el modelo aprendió durante el entrenamiento. Son, literalmente, el modelo
  • Un modelo de pesos abiertos es uno cuya empresa publica ese archivo de números: cualquiera puede descargarlo, correrlo y modificarlo
  • Las familias que vimos ayer: Llama (Meta), Qwen (Alibaba), DeepSeek, Mistral, Gemma (Google); y otras como Granite (IBM), la que usaremos hoy
  • ¿Dónde viven? En Hugging Face (el “GitHub de los modelos”) y en la biblioteca de Ollama
  • ¿Por qué las empresas los liberan? Para crear ecosistema, atraer talento y volverse el estándar que todos usan

Abierto no siempre es “open source”

  • Casi nunca se publican los datos de entrenamiento ni el proceso completo
  • Algunas licencias restringen usos comerciales
  • Lo que sí obtenemos: el modelo exacto, congelado, en nuestro disco

Nota

Pista: para investigación, lo decisivo no es la licencia sino el control: nadie puede cambiar ni retirar un modelo que ya está en su máquina.

La ciencia necesita modelos abiertos

Un argumento que gana fuerza en la metodología (Spirling, 2023; Palmer, Smith y Spirling, 2024):

  • Un modelo cerrado puede cambiar o desaparecer sin aviso. Si su medición dependía de él, nadie puede repetirla
  • No se puede auditar: no sabemos con qué datos fue entrenado ni qué sesgos trae
  • El costo por uso crea desigualdad entre equipos de investigación con y sin presupuesto
  • Con pesos abiertos, el paquete de replicación puede fijar el modelo exacto, igual que fijamos la versión de un paquete de R

La recomendación emergente

Usar modelos abiertos por defecto en investigación, y justificar explícitamente cuando se usa uno propietario.

Algunas revistas ya piden esa justificación en la sección de métodos.

Nota

Pista: es el mismo principio de la ciencia abierta que ya conocen: datos abiertos, código abierto y ahora modelos abiertos.

¿Cómo entra un LLM en su laptop? Cuantización

  • Cada parámetro es un número guardado con cierta precisión (cantidad de bits)
  • La cuenta para un modelo de 3 mil millones de parámetros (un “3B”, como el del curso):
    • A 16 bits (2 bytes) por parámetro: ~6 GB de RAM
    • Cuantizado a 4 bits: ~2,1 GB. Eso es lo que baja Ollama por defecto
  • La analogía: como redondear 3,14159265 a 3,14. Se pierde un poco de precisión y se gana muchísimo espacio
  • El costo en calidad es pequeño: se nota recién en tareas muy finas o razonamiento largo
Precisión Bits RAM aproximada (modelo 3B)
Original (FP16) 16 ~6 GB
q8 8 ~3,2 GB
q4 (default de Ollama) 4 ~2,1 GB

La regla práctica

El modelo tiene que entrar cómodo en su RAM, dejando espacio para el sistema y para R.

  • 8 GB de RAM → modelos de hasta ~3 GB
  • 16 GB de RAM → modelos de hasta ~9 GB
  • 32+ GB → modelos medianos (14B-30B cuantizados)

Nota

Pista: ayer vimos que los modelos MoE activan solo una parte de sus parámetros por token. Cuantización y MoE son las dos razones por las que hoy corre en su laptop algo que hace tres años necesitaba un servidor.

Modelos locales en la investigación social

Datos sensibles: cuando la nube no es una opción

Casos típicos en ciencias sociales:

  • Entrevistas con víctimas, activistas o funcionarios bajo confidencialidad
  • Datos de salud o trayectorias personales
  • Denuncias y expedientes con información identificable
  • Convenios con instituciones que prohíben transferir los datos a terceros

Subir ese texto a una API es transferirlo a un tercero, a veces en otro país. Puede violar:

  • El consentimiento informado que firmaron los participantes
  • Las reglas del comité de ética
  • Leyes de datos personales: Ley 18.331 en Uruguay, GDPR en Europa

Con un modelo local, todo queda en su máquina

  • Transcribir las entrevistas (Whisper también corre local)
  • Codificar y clasificar el material
  • Resumir y extraer temas
  • Anonimizar: detectar y reemplazar nombres, lugares y fechas

Nota

Pista: una estrategia híbrida común: anonimizar primero con el modelo local y recién después, si hace falta más calidad, mandar el texto ya anónimo a la nube

Corpus grandes: el costo marginal es cero

En la nube se paga por token. Una cuenta rápida:

  • Clasificar 1 millón de noticias (~400 tokens cada una) ≈ 400 millones de tokens de entrada
  • A USD 1,25 por millón de tokens ≈ USD 500 solo de entrada, más la salida
  • Y los modelos :free tienen límites de velocidad (lo sufrimos en el lab 7)

Con un modelo local: cero costo por uso, sin límites de requests, y la computadora puede trabajar de noche

Dónde aparece esto en la investigación

  • Archivos históricos de prensa
  • Décadas de discursos parlamentarios
  • Respuestas abiertas de encuestas grandes (Latinobarómetro tiene cientos de miles)
  • Millones de posteos de redes sociales

Nota

Pista: el flujo del lab 8 sigue valiendo: validar el codificador en una muestra con gold standard y recién después soltarlo sobre el corpus completo

Reproducibilidad: congelar el modelo

  • Ayer vimos el problema: el GPT-4 de marzo no era el de diciembre, y la API puede cambiar sin aviso
  • Con un modelo local, la versión queda congelada en su disco
  • Ollama identifica cada modelo con un digest, una huella digital única (ollama show la muestra)
  • Un paquete de replicación completo: el Modelfile, el digest del modelo, los prompts y el código

Quien quiera replicar su medición en 2030 puede correr exactamente el mismo pipeline

La conexión con quallmer

qlm_trail() ya documenta el flujo de codificación. Con un modelo local, ese registro pasa de “documentado” a completamente reproducible: el motor también está versionado.

Nota

Pista: temperatura 0 + modelo local + semilla fija es lo más cerca de un análisis determinista que se puede estar con un LLM

Un flujo de trabajo realista

La pregunta no es “¿nube o local?”, es qué parte del flujo va en cada lado.

  1. Prototipar el codebook en la nube con una muestra chica (labs 7 y 8): los modelos de frontera ayudan a refinar las instrucciones
  2. Validar el modelo local y el de la nube contra el mismo gold standard (qlm_validate)
  3. Si el local rinde parecido → producción local sobre el corpus completo
  4. Reportar todo: modelo, versión, métricas de validación


Nota

Pista: si el modelo local pierde demasiada precisión en el paso 2, las opciones son: un modelo local más grande, anonimizar y usar la nube, o codificar en la nube solo los casos difíciles

Ollama: su LLM en la terminal

¿Qué es Ollama?

  • Ollama (ollama.com) es una herramienta de línea de comandos para correr LLMs en su computadora
  • Los modelos vienen pre-entrenados: se descargan y se usan, sin configurar nada
  • Hay decenas de modelos en su biblioteca: Llama, Qwen, DeepSeek, Gemma, Granite, phi, entre otros
  • Funciona en Windows, macOS y Linux
  • El único costo real es el espacio en disco y la RAM: los modelos grandes pesan, pero hay versiones chicas muy capaces

https://ollama.com

Ollama es como un gestor de modelos: pull para bajar, run para conversar, y listo.


Nota

Pista: el mismo programa que usan para chatear en la terminal expone un servidor local que R puede consultar. Eso es lo que conecta Ollama con ellmer

Instalar y correr Ollama

Tres pasos, una sola vez

  1. Descargar e instalar desde ollama.com/download

  2. Bajar el modelo del curso (~2 GB):

ollama pull granite4.1:3b
  1. Conversar con él en la terminal:
ollama run granite4.1:3b

Para salir de la conversación: /bye

Qué esperar

  • La descarga tarda según su conexión, háganla antes de la clase
  • Una vez bajado, el modelo queda en su disco y no hay que volver a descargarlo
  • La primera respuesta puede tardar unos segundos mientras el modelo se carga en memoria

Nota

Pista: con ~2 GB, el modelo entra cómodo en cualquier laptop con 8 GB de RAM. Con más memoria, pueden probar modelos más grandes y comparar la calidad

Comandos esenciales de Ollama

Manejar modelos

ollama pull <modelo>   # descargar
ollama run  <modelo>   # conversar
ollama ls              # listar descargados
ollama ps              # ver qué corre ahora
ollama rm   <modelo>   # borrar

Dentro de la conversación

/bye      # salir
/?        # ayuda

Información

ollama show <modelo>   # detalles del modelo
ollama help            # ayuda general

Con pull, run y ls ya alcanza para todo lo de hoy

El modelo del curso: IBM Granite

  • Usamos granite4.1, de la familia Granite (IBM)
  • Por qué este modelo para investigación social:
    • Chico: ~2 GB, corre en una laptop común
    • Multilingüe: maneja bien el español y muchos otros idiomas
    • Estructurado: afinado para devolver JSON con el formato exacto que ellmer y quallmer necesitan
    • Abierto: licencia Apache 2.0, sin restricciones de uso ni redistribución
Modelo Tamaño Para
granite4.1:3b ~2,1 GB Default del curso

La familia Granite incluye modelos más grandes para máquinas con más memoria; para codificar en el laboratorio, la versión de 3B alcanza

Una cosa importante para investigación

Algunos modelos “piensan” antes de responder (modo razonamiento). Ayuda en problemas difíciles, pero para codificar miles de textos es lento e inestable

Granite responde directo y está afinado para salida estructurada: devuelve el JSON que quallmer necesita, texto a texto, sin divagar

Nota

Pista: es la misma idea de reproducibilidad de ayer. Salida estructurada + temperatura 0 = la misma entrada da casi siempre la misma salida

¿Qué tan rápido va a ser? Expectativas de hardware

  • La velocidad se mide en tokens por segundo
  • En una laptop moderna (Apple Silicon o con GPU), granite4.1:3b genera decenas de tokens por segundo: un párrafo en pocos segundos
  • En una máquina sin GPU dedicada puede ser varias veces más lento: ahí conviene un modelo más chico
  • Si el modelo no entra en la RAM, el sistema usa el disco como memoria y todo se arrastra. Mejor un modelo más chico que uno grande ahogado

La buena noticia para codificar

Las tareas del laboratorio piden respuestas cortas (una categoría, un puntaje). Eso es rápido incluso en máquinas modestas

Nota

Pista: para un corpus grande no importa tanto la velocidad por texto sino dejar el script corriendo solo. Mil textos a 5 segundos cada uno son menos de una hora y media

Personalizar: el Modelfile

¿Qué es un Modelfile?

  • Un Modelfile es un archivo de texto con instrucciones para crear su propia versión de un modelo
  • Parte de un modelo base y le agrega configuración fija: un rol, parámetros, ejemplos
  • Los campos más usados:
    • FROM: el modelo base (por ejemplo, granite4.1:3b)
    • PARAMETER: ajustes como temperature, num_ctx, top_p
    • SYSTEM: el rol persistente, el “system prompt” que vimos ayer
    • MESSAGE: ejemplos de conversación (few-shot incorporado)


Es como guardar su mejor prompt dentro del modelo, para no repetirlo cada vez

Un Modelfile para investigación

Un asistente de codificación cualitativa: cauteloso, en español, que no inventa

FROM granite4.1:3b

# Para investigación queremos respuestas estables, no creativas
PARAMETER temperature 0

# Ventana amplia para documentos largos
PARAMETER num_ctx 8192

SYSTEM """
Sos un asistente de codificación para investigación social.
Tu tarea es clasificar y resumir textos políticos en español
de forma cuidadosa y conservadora.

Reglas:
- Respondé solo con lo que el texto dice. No inventes datos,
  nombres ni cifras.
- Si el texto no da información suficiente, respondé
  "no determinado" en vez de adivinar.
- Cuando se te pida una categoría, elegí una de las opciones
  dadas y nada más.
- Sé breve y directo.
"""

Crear y correr su modelo

  1. Guarden el texto anterior en un archivo llamado codificador (sin extensión)

  2. Creen el modelo a partir del Modelfile:

  • -f indica el archivo (file)
ollama create codificador -f codificador
  1. Úsenlo como cualquier otro modelo:
ollama run codificador

Qué ganamos

  • El rol y la temperatura quedan fijos: cada vez que lo llamamos, se comporta igual
  • No hay que pegar el system prompt en cada consulta
  • Si otra persona usa el mismo Modelfile, obtiene el mismo asistente

Nota

Pista: un Modelfile es texto plano. Súbanlo a su repositorio y su codificador queda documentado y reproducible

¿Para qué sirve un Modelfile?

  • A medida: un asistente especializado en su tema, su esquema de codificación o su idioma
  • Reproducible: el rol y los parámetros quedan escritos y versionados, no dependen de la memoria de quien lo usa
  • Eficiente: fijan un comportamiento una vez y lo reutilizan en todo el proyecto
  • Privado: corre en su máquina, ideal para datos que no pueden salir de ahí


Para un proyecto de codificación, el Modelfile es su “libro de códigos”

Local desde R

Conectar Ollama con ellmer

  • Ollama deja corriendo un servidor local que ellmer consulta igual que a la nube
  • Cambian chat_openrouter() por chat_ollama() y el resto del código no se toca
  • Las mismas cuatro defensas de ayer siguen aplicando
library(ellmer)

chat <- chat_ollama(
  model = "granite4.1:3b",
  system_prompt = "Sos un analista político..."
)

chat$chat("Clasificá el sentimiento de este texto: ...")

Extracción estructurada, local

chat$chat_structured(
  "La economía está en crisis.",
  type = type_object(
    tema        = type_string(),
    sentimiento = type_string(),
    confianza   = type_number()
  )
)
  • quallmer, el paquete de codificación cualitativa, usa ellmer por debajo
  • Así que todo esto funciona también con un modelo local

En el laboratorio: codificamos un corpus con granite4.1 y validamos el resultado

quallmer con un modelo local

  • Todo el flujo del lab 8 funciona igual: codebook, codificar, validar, comparar
  • Lo único que cambia es el string del modelo
library(quallmer)

codificado_local <- qlm_code(
  textos,
  codebook,
  model = "ollama/granite4.1:3b",
  max_active = 1
)
  • Ayer era "openrouter/...", hoy es "ollama/...". El prefijo indica el proveedor
  • max_active = 1: el servidor local procesa de a un pedido; en paralelo, los pedidos se acumulan y dan timeout

Ventajas inmediatas

  • No hay límites de la API ni errores 400: el servidor es suyo
  • No hay API key que configurar
  • Se puede correr con la computadora sin internet

Nota

Pista: qlm_replicate() acepta un model distinto. Eso permite comparar el codificador local contra uno de la nube con qlm_compare(): ¿cuánta calidad cuesta la privacidad?

Lo que hoy no cubrimos: fine-tuning

  • Todo lo que hicimos esta semana cambia el contexto (prompts, ejemplos, Modelfile), nunca los pesos
  • El fine-tuning va un paso más allá: re-entrena parcialmente los pesos con sus propios ejemplos etiquetados
  • La técnica más común es LoRA (Hu et al., 2021): entrena unos adaptadores chicos en vez de tocar todo el modelo, así que es viable en una sola GPU
  • Con pesos abiertos, el fine-tuning es posible. Con modelos cerrados, dependen de lo que ofrezca la empresa

¿Cuándo considerarlo?

  • Cuando el prompting con few-shot no alcanza y tienen miles de ejemplos etiquetados
  • Para tareas muy especializadas (jerga legal, registros históricos)

Nota

Pista: para la mayoría de los proyectos de investigación social, un buen codebook bien validado alcanza. El fine-tuning es la herramienta de último recurso, no la primera

Los límites de los modelos locales

  • Calidad: un modelo de 3 mil millones de parámetros codifica peor que uno de frontera en la nube
  • Velocidad: depende de su hardware; sin GPU puede ser lento
  • Memoria: los modelos grandes (30B+) no entran en una laptop
  • Tareas complejas: razonamiento largo o matices sutiles pueden superarlo

Por eso siempre validamos

Un modelo local es un punto de partida útil apenas

La defensa 4 de ayer sigue siendo la regla: la validación y la reproducibilidad mejoran mucho la calidad de la investigación

Nota

Pista: corran el modelo local sobre una muestra con respuestas conocidas (gold standard) y midan qué tan seguido acierta antes de confiar en él para todo el corpus

Resumen de la sesión

Lo que vimos

  • Correr local da privacidad, costo cero y reproducibilidad
  • Pesos abiertos: el modelo congelado en su disco, auditable y replicable
  • La cuantización es lo que hace entrar un LLM en una laptop común
  • En investigación social: datos sensibles, corpus enormes y paquetes de replicación
  • Ollama: pull, run, ls y poco más; el Modelfile fija un rol reproducible
  • Desde R, chat_ollama() y model = "ollama/..." reemplazan a la nube sin reescribir código

Cuándo usar cada cosa

  • Datos sensibles o reproducibilidad → local
  • Máxima calidad o prototipo rápido → nube
  • Lo habitual es combinar. Prototipar en la nube, validar ambos, producir en local. O viceversa, dependiendo del proyecto

Regla de oro

Nota

Pista: local o nube, ningún LLM es fuente de verdad. Siempre validar contra un estándar conocido

Próximos pasos

  • Sesión 5.2: ética, sesgo, privacidad y regulación de la IA

  • Laboratorio 9, en dos partes:

    • Codificar datos sensibles (simulados) con quallmer y el modelo local, y validar contra un gold standard
    • Auditar la equidad de un modelo de crédito con fairmodels

  • Sesión 5.4: mini-propuestas de investigación, discusión de proyectos y cierre


Antes del laboratorio: ollama pull granite4.1:3b (~2,1 GB)

Nos vemos en unos minutos 😉