CCDV-F · Selección y optimización de modelos
Tokens, no determinismo, pensamiento y esfuerzo, fast mode y few-shot
Un test compara la respuesta byte a byte contra una captura y falla cada noche con casos distintos. Un clasificador de doce etiquetas devuelve stop_reason: max_tokens sin texto. Un equipo quiere que el parche de un asistente de código termine de llegar antes y prueba un modelo más chico. Los tres problemas se resuelven entendiendo cómo genera el modelo y qué opciones tiene, no cambiando de modelo a ciegas.
Tokens y generación
El modelo procesa y produce tokens (fragmentos de palabra), uno por vez: cada token nuevo se elige a partir de todo lo anterior. De ahí salen tres consecuencias prácticas:
- Todo lo que entra (system prompt, historial, herramientas, documentos) y todo lo que sale ocupa la ventana de contexto y se cobra por token.
- El pensamiento también son tokens de salida: cuenta dentro de
max_tokensy se cobra aunque no se muestre. - Si la ventana se llena, la respuesta corta con
stop_reason: model_context_window_exceeded; si se agotamax_tokens, conmax_tokens.
No determinismo
Generar es elegir entre tokens posibles, así que la misma entrada puede dar salidas distintas. Eso es no determinismo (non-determinism), y no se apaga del todo: ni bajar la temperatura en los modelos que la aceptan garantizaba respuestas idénticas, y los modelos más nuevos directamente rechazan temperature, top_p y top_k. El comportamiento se guía con el prompt y se verifica con evaluaciones.
La consecuencia para las pruebas: validá estructura y propiedades (la categoría correcta, los campos obligatorios, que la justificación cite el texto), no el texto exacto.
Pensamiento y esfuerzo
- Pensamiento extendido con
budget_tokens: el desarrollador fijaba cuántos tokens podía pensar. Es el esquema viejo y los modelos nuevos lo rechazan. - Pensamiento adaptativo (adaptive thinking): el modelo decide en cada pedido si piensa y cuánto. Puede haber turnos sin bloque de pensamiento.
- Nivel de esfuerzo (effort), en
output_config.effort(low,medium,highy, según el modelo,xhighymax): la palanca calibrada para cuánto trabaja el modelo. Afecta todo lo que genera: pensamiento, texto y llamadas a herramientas.
Si el modelo piensa de más en una tarea simple, bajá el esfuerzo y confirmá con tu set de evaluación que la calidad se mantiene. Pedirle en el prompt “no pienses” no es confiable. Si las respuestas cortan por max_tokens en tareas que sí necesitaban razonar, subí max_tokens.
Modo rápido
El modo rápido (fast mode), con speed: "fast", corre el mismo modelo con una inferencia más rápida:
- misma calidad y mismas capacidades;
- más tokens de salida por segundo, no un primer token más temprano;
- precio premium y disponible solo en algunos modelos;
- no se combina con la Message Batches API.
Sirve cuando el usuario espera el final de una respuesta larga. Si el problema es el costo, es la herramienta equivocada.
Zero-shot, one-shot y few-shot
Sin ejemplos (zero-shot) alcanza cuando la tarea está clara y el formato es flexible. Cuando el contenido sale bien pero el formato varía (fechas escritas de tres maneras, montos con palabras), los ejemplos en el prompt (few-shot (multi-shot) prompting) son la corrección más directa: tres o cuatro casos variados con la salida exacta esperada. Uno solo (one-shot) tiende a que el modelo copie de más ese caso.
Las trampas típicas
- Bajar la temperatura o fijar
top_ppara “hacerlo determinista”. - Reintentar un test hasta que coincida, o regenerar las capturas cada noche.
- Escribir en el prompt “respondé sin pensar” en lugar de bajar el esfuerzo.
- Volver a
budget_tokensen un modelo que usa pensamiento adaptativo. - Creer que el modo rápido usa un modelo más chico o que acorta el tiempo al primer token.
- Cambiar a un modelo más grande cuando lo que falla es el formato.
En el examen
Leé qué síntoma describe el escenario. Respuestas que varían con el contenido correcto: validar propiedades. Pensamiento que se come max_tokens en una tarea simple: bajar el esfuerzo y medir. Usuarios que esperan el final de una salida larga: modo rápido. Formato inconsistente con buena precisión: ejemplos variados.
Pregunta rápida
Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.
An analytics company generates long quarterly reports with Claude from a Python batch job that runs during business hours. Each request asks for a very large max_tokens value so the full report fits in one response, and the job uses the SDK's standard non-streaming messages.create call.
Since the reports grew longer, the SDK has started refusing some of these calls before sending them, warning that the request is expected to exceed its time limit, and a few that went through failed after the connection sat idle for many minutes.
The job doesn't need to show progress to anyone; it only needs the final text written to storage.
What is the most appropriate fix?