DEV M1 · MSO Foundations — Resumen de estudio

Curso 1 de 5 · Claude Certified Developer – Foundations · 9 pantallas, 2 checkpoints
Vocabulario base que el resto del curso da por sabido: tokens, contexto, sampling, modelos, modos de prompting y cómo se llega a la API.

1. Cómo se comportan los LLM

Tokens

Claude lee tokens, no caracteres ni palabras. Los caracteres por token dependen del tokenizer de cada modelo (verifícalo al construir).
Todo cuenta en tokens: prompt, historial, definiciones de tools, resultados de tools y respuesta.
Tokens = unidad de precio y de presupuesto. Piensa en tokens, no en palabras.

Context window: un presupuesto fijo

Contiene todo a la vez: system prompt, conversación, documentos, resultados de tools y la salida.
Dos comportamientos en el borde:
1. Input ya más grande que la ventana → error de validación antes de generar.
2. El input cabe pero la generación llega al techo → se devuelve lo generado con stop reason model_context_window_exceeded (no es un error).
Lo más antiguo no se descarta en silencio: recortar o resumir el historial es trabajo de tu aplicación.
En desarrollo casi nunca se llena (inputs cortos); en producción, sí.

Sampling

El modelo genera una distribución de probabilidad sobre el siguiente token y muestrea.
Temperature baja → más repetible; alta → más variado.
Temperature 0 NO garantiza salidas idénticas.
⚠️ En los modelos más nuevos, temperature, top_p o top_k con valores no default devuelven error 400; el comportamiento se guía con el prompt.

Non-determinism → cómo testear

La misma entrada no garantiza la misma salida.
No compares texto exacto. Verifica propiedades (el campo existe, el valor está en rango, la estructura parsea).
Para juzgar el significado → eval con un model-graded judge.

2. Modelos y modos de razonamiento

Familia actual (4 tiers):
- Fable: el más capaz (razonamiento, código y trabajo agentic más exigente).
- Opus: trabajo exigente por encima de Sonnet.
- Sonnet: el default equilibrado.
- Haiku: velocidad y costo.
Regla: empieza con Sonnet, sube si un eval muestra que no alcanza la calidad y baja a Haiku si un eval muestra que la caída es aceptable.
Elegir el modelo ≠ elegir el modo de razonamiento (se configura por llamada).
- En modelos actuales: adaptive thinking. El modelo decide cuándo y cuánto pensar, y tú ajustas la profundidad con effort.
- budget_tokens está deprecado y en los modelos más nuevos da 400.
- En los modelos más nuevos el contenido del thinking se omite por defecto; pide la visualización resumida si la necesitas.
- El razonamiento vale la pena en problemas difíciles de varios pasos y es desperdicio en búsquedas o clasificación.
Las dos palancas se combinan: modelo capaz sin razonamiento = rápido y directo; modelo chico con razonamiento = gasta más tokens pensando.

3. Modos de prompting

Modo	Qué es	Cuándo
Zero-shot	Solo la instrucción	Tarea simple, forma de salida obvia
One-shot	1 ejemplo entrada → salida	La estructura o un caso límite no sale con la descripción
Multi-shot / few-shot	Varios ejemplos	Igual, cuando la estructura es más específica

Los ejemplos no son entrenamiento: viven en el prompt, cuestan tokens en cada llamada y consumen contexto.
Uno o dos ejemplos correctos suelen arreglar un problema de forma antes que otro párrafo de instrucciones.
Modo y modelo interactúan: un modelo más capaz puede resolver en zero-shot lo que uno más chico resuelve con ejemplos, así que con ejemplos a veces sirve un modelo más barato. Elige el modelo más simple y los menos ejemplos que pasen tu eval.

4. Sustrato técnico: SDK, REST, streaming y async

REST: request HTTP con API key + cuerpo JSON → respuesta JSON.
SDK (Python, TypeScript, etc.): una capa delgada sobre la misma API (auth, construcción del request, retries, parsing). Mismo modelo y misma API.

Patrón	Cuándo
Síncrono	Respuestas cortas, backend sin nadie esperando
Streaming (server-sent events)	Respuestas largas o un usuario mirando; el texto aparece de inmediato
Async/await (`AsyncAnthropic` en Python; en TypeScript el cliente ya es Promise-based, no hay clase async aparte)	Concurrencia sin bloquear tu aplicación; la respuesta sigue siendo en tiempo real
Message Batches API	Volumen alto offline: envías un lote, recibes un ID y consultas el estado. Hasta 24 h, menor costo por token. Pipelines, evals, jobs masivos

Quiz y ejercicio (respuestas)

Quiz:

¿Prompts idénticos dan texto idéntico? → B: no necesariamente; se muestrea cada token.
Modelo vs razonamiento → C: el modelo elige qué miembro de la familia corre; el thinking es un ajuste por llamada.
Clasificación que ya funciona en zero-shot + 3 ejemplos → B: más costo por llamada sin ganancia.
Miles de entradas offline al menor costo → C: batch con polling.

Predecir el comportamiento:

Temperature 0 vs alta en un clasificador → A: la baja es mucho más consistente (pero nunca determinista); la alta varía incluso la etiqueta.
Estructura incorrecta en zero-shot → multi-shot → B: 2–3 ejemplos muestran la forma; cuesta tokens en cada llamada.
50,000 documentos de noche → C: batch + polling (un loop síncrono choca con los rate limits; el streaming no aporta nada).
Sesión larga que llena la ventana → B: presupuesto fijo; error si el input ya es enorme, truncado con model_context_window_exceeded si se llena al generar. Hay que recortar o resumir.

Para recordar

Tokens = unidad de input, output y costo.
La context window es un presupuesto fijo; gestionar el historial es tarea de la app.
El sampling vuelve la generación no determinista → evals, no comparación de texto exacto.
Modelo y modo de razonamiento son palancas separadas y combinables.
REST, normalmente vía SDK; elige síncrono, streaming, async o batch según si alguien espera y el volumen.