Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen NCA-GENL. Lee de arriba a abajo o salta a una sección.
Explique qué permite a un transformer ponderar tokens distantes al generar el siguiente.
Auto-atención. Cada token atiende a todos los demás tokens a través de proyecciones de query/key/value, produciendo representaciones ponderadas por el contexto.
Por qué: La atención, no la recurrencia, es lo que proporciona a los transformers un contexto de largo alcance y un entrenamiento paralelizable.
Elija cómo inyectar nuevos conocimientos o comportamientos en un LLM.
Hechos nuevos que cambian a menudo → RAG. Nuevo comportamiento/estilo de tarea → fine-tune. Nueva capacidad/vocabulario base a escala → pre-training continuado.
Por qué: RAG mantiene los datos externos y actualizables; el fine-tuning incorpora el comportamiento en los pesos; el pre-training es la palanca más cara.
Defina qué convierte un modelo en un foundation model.
Un modelo grande pre-entrenado con datos amplios, en su mayoría no etiquetados, adaptable a muchas tareas posteriores mediante prompting, RAG o fine-tuning.
Estime cómo el texto se asigna a las unidades de entrada del modelo y qué impulsa el costo.
El texto se divide en sub-word tokens mediante un tokenizer (por ejemplo, BPE). El costo y los límites de contexto se miden en tokens, no en caracteres o palabras.
Por qué: Las palabras raras o no inglesas se dividen en más tokens, inflando el uso del contexto y el costo de inferencia.
Un documento largo no cabe en un solo prompt.
La entrada excede la context window del modelo (tokens máximos para entrada + salida). Divida el documento para RAG o elija un modelo con un contexto más largo.
Por qué: La context window es un límite estricto; todo lo que está más allá se trunca y se pierde silenciosamente.
Potenciar la semantic search o la recuperación de RAG sobre texto.
Utilice un embedding model para convertir texto en vectores densos, luego recupere por similitud de coseno/producto escalar de un vector store.
Por qué: Los embeddings colocan texto semánticamente similar cerca uno del otro, lo que permite una recuperación basada en el significado en lugar de la recuperación por palabras clave.
Elija el comportamiento de salida: determinista vs. creativo.
Temperatura baja (~0.0-0.3) → enfocada, repetible. Temperatura alta (~0.7-1.0) → diversa, creativa. Use cerca de 0 para clasificación o extracción.
Por qué: La temperatura escala la distribución de probabilidad antes del muestreo; los valores más bajos concentran la masa en los tokens superiores.
Restrinja el conjunto de tokens candidatos más allá de la temperatura.
Top-k mantiene los k tokens más probables; top-p (núcleo) mantiene el conjunto más pequeño cuya probabilidad acumulada alcanza p.
Por qué: Top-p adapta el conjunto de candidatos a la forma de la distribución; top-k tiene un ancho fijo independientemente de la confianza.
Identifique cómo los LLMs aprenden de texto sin etiquetar.
Aprendizaje auto-supervisado — la predicción del siguiente token (causal) o del token enmascarado crea etiquetas a partir del propio texto, sin anotación humana.
Por qué: Es lo que permite a los LLMs entrenar en corpora a escala de internet sin etiquetado manual.
Asigne la arquitectura a la familia de tareas.
Generación → solo decodificador (estilo GPT). Comprensión/clasificación → solo codificador (estilo BERT). Traducción/resumen de secuencia a secuencia → codificador-decodificador (estilo T5).
Por qué: Los modelos solo de decodificador predicen de izquierda a derecha; los codificadores ven el contexto bidireccional, mejor para tareas de representación.
Haga que un modelo base siga instrucciones y prefiera respuestas útiles y seguras.
Ajuste de instrucciones seguido de alineación como RLHF — aprendizaje por refuerzo a partir de clasificaciones de preferencias humanas.
Por qué: Un modelo pre-entrenado en bruto predice texto; la alineación lo dirige hacia el comportamiento de asistente deseado.
El modelo afirma hechos con confianza pero fabricados.
Alucinación. Mitigue fundamentando con RAG, bajando la temperatura, citando fuentes y añadiendo guardrails más revisión humana para salidas de alto riesgo.
Por qué: Los LLMs predicen tokens plausibles, no hechos verificados; la fundamentación proporciona la evidencia que falta.
Distinga el tamaño del modelo del tamaño de los datos de entrenamiento.
Parámetros = pesos aprendidos (capacidad del modelo). Tokens = volumen de texto de entrenamiento. Ambos escalan la capacidad bajo las leyes de escalado.
Por qué: Un modelo más grande sub-entrenado con muy pocos tokens rinde menos que uno más pequeño y bien entrenado (conocimiento de Chinchilla).
Separe las dos fases intensivas en GPU del ciclo de vida de un LLM.
El entrenamiento actualiza los pesos a partir de los datos (una sola vez, por lotes). La inferencia ejecuta el modelo congelado para generar salidas (continua, sensible a la latencia).
Por qué: Las herramientas de optimización difieren: el entrenamiento utiliza frameworks de paralelismo; la inferencia utiliza TensorRT-LLM y Triton.
Un modelo fine-tuned memoriza ejemplos de entrenamiento y falla en nuevas entradas.
Overfitting. Mitigue con más/diversidad de datos, early stopping, menor tasa de aprendizaje, menos épocas o regularización como dropout.
Por qué: Una gran brecha entre entrenamiento y validación significa que el modelo ajustó el ruido en lugar de patrones generalizables.
Despliegue rápidamente un LLM optimizado como microservicio de producción con una API compatible con OpenAI.
Utilice un microservicio NVIDIA NIM — un endpoint de modelo preconstruido, contenedorizado y optimizado para TensorRT-LLM.
Por qué: NIM empaqueta el modelo, el runtime y el motor optimizado, lo que le permite omitir el cableado manual de TensorRT-LLM y Triton.
Sirva múltiples modelos con batching, concurrencia y múltiples backends detrás de un único inference server.
NVIDIA Triton Inference Server. Soporta dynamic batching, ensembles de modelos y backends de TensorRT/PyTorch/ONNX.
Por qué: Triton maximiza la utilización de la GPU mediante la ejecución concurrente de modelos y el dynamic batching.
Reduzca la latencia de inferencia de LLM en GPUs NVIDIA antes de la servir.
Compile el modelo con TensorRT-LLM — fusión de kernel, quantization, in-flight batching y optimización de KV-cache.
Por qué: TensorRT-LLM produce un motor optimizado mucho más rápido que ejecutar el modelo de framework en bruto.
Entrene, personalice o haga fine-tuning de LLMs a escala en GPUs NVIDIA.
Framework NVIDIA NeMo — toolkit de extremo a extremo para construir, personalizar y desplegar modelos de IA generativa.
Por qué: NeMo cubre data curation, training, PEFT y alignment en una sola pila diseñada para escalado multi-GPU.
Construya una aplicación que responda a partir de documentos privados que el modelo base nunca vio.
RAG pipeline: divida + incruste documentos en un vector store, recupere top-k por similitud en el momento de la consulta e inyéctelos en el prompt.
Por qué: La recuperación fundamenta las respuestas en datos actuales y propios sin reentrenar el modelo.
Restrinja el tono, el rol y las reglas del asistente en toda una conversación.
Establezca un system prompt/mensaje que defina el rol, las restricciones y el formato antes de los turnos del usuario.
Por qué: El system message persiste a lo largo de los turnos y dirige el comportamiento de manera más confiable que las instrucciones por turno.
Mejore la precisión en una tarea estructurada sin ningún entrenamiento.
Few-shot prompting — incruste 2-5 ejemplos de entrada/salida en el prompt antes de la entrada real.
Por qué: El in-context learning permite que el modelo haga coincidir patrones con ejemplos sin actualizaciones de peso.
El modelo resuelve incorrectamente problemas de razonamiento de varios pasos o problemas matemáticos.
Chain-of-thought prompting — instrúyale a razonar paso a paso antes de dar la respuesta final.
Por qué: Obtener pasos intermedios mejora la precisión del razonamiento en tareas composicionales.
Permita que el LLM active APIs externas, bases de datos o herramientas de manera confiable.
Utilice function/tool calling — defina esquemas de herramientas; el modelo emite argumentos estructurados que su código ejecuta.
Por qué: Las llamadas a herramientas estructuradas superan el parsing de texto libre, y fundamentan el modelo en sistemas en vivo para flujos agentic.
El código downstream necesita JSON estricto del modelo.
Solicite un esquema JSON en el prompt y use decodificación restringida/guiada; valide la salida antes de usarla.
Por qué: La decodificación guiada por esquema previene JSON mal formado que rompería el parsing.
Una UI de chat debe mostrar tokens a medida que se producen en lugar de después de la finalización.
Utilice inferencia por streaming (token a token) desde el serving endpoint.
Por qué: El streaming reduce la latencia percibida; NIM y Triton admiten respuestas en streaming.
Componga pasos de retrieval, prompting y herramientas en una única pipeline de aplicación.
Utilice un framework de orquestación como LangChain o LlamaIndex para encadenar retrievers, prompts, modelos y herramientas.
Por qué: Estos frameworks proporcionan abstracciones reutilizables de RAG y agent sobre los endpoints de NIM/NeMo.
Decida entre un microservicio empaquetado y una pila de serving construida manualmente.
Despliegue rápido y estandarizado → NIM. Lógica de backend/modelo personalizada profunda → Triton + TensorRT-LLM directamente.
Por qué: NIM sacrifica configurabilidad por velocidad; Triton en bruto ofrece control total del grafo de serving.
Haga fine-tuning de un modelo grande con memoria GPU limitada sin tocar todos los pesos.
LoRA / PEFT — entrene pequeñas matrices adaptadoras de bajo rango mientras congela los pesos base.
Por qué: LoRA reduce los parámetros entrenables en órdenes de magnitud, por lo que el fine-tuning cabe en GPUs modestas.
Haga fine-tuning de un modelo muy grande con el presupuesto de memoria más ajustado posible.
QLoRA — cuantifique el modelo base congelado a 4 bits y entrene adaptadores LoRA encima.
Por qué: La cuantización de la base reduce la memoria aún más que solo LoRA, lo que permite modelos más grandes en una GPU.
Elija la personalización más económica que cumpla con el estándar de calidad.
Escalar en orden: prompt engineering → few-shot → RAG → LoRA fine-tuning → full fine-tuning.
Por qué: El costo y el esfuerzo aumentan en cada paso; deténgase en el primero que alcance el objetivo.
El supervised fine-tuning necesita la forma correcta de los datos de entrenamiento.
Proporcione pares instrucción/respuesta (prompt-completion), típicamente en JSONL.
Por qué: SFT enseña al modelo a mapear entradas a salidas deseadas; los pares definen ese mapeo.
La pérdida de fine-tuning diverge o el modelo olvida capacidades previas.
Reduzca la tasa de aprendizaje y/o las épocas; observe la pérdida de validación para detectar el catastrophic forgetting.
Por qué: Una LR demasiado alta desestabiliza el entrenamiento y sobrescribe el conocimiento pre-entrenado.
Mida si un cambio en fine-tune o prompt realmente ayudó.
Reserve un conjunto de validación/prueba en el que el modelo nunca se entrenó y compare las métricas antes y después.
Por qué: Evaluar con datos de entrenamiento sobreestima la calidad; solo los datos retenidos reflejan la generalización.
Compare muchas ejecuciones de fine-tuning con diferentes hiperparámetros y datos.
Registre ejecuciones, configuraciones y métricas con un experiment tracker (por ejemplo, MLflow, Weights & Biases, TensorBoard).
Por qué: La reproducibilidad requiere registrar qué configuración produjo qué resultado; la memoria no escala.
Califique automáticamente la calidad del texto generado.
Resumen → ROUGE. Traducción → BLEU. Coincidencia semántica → BERTScore. Calidad abierta → LLM-as-judge o evaluación humana.
Por qué: Las métricas de superposición léxica omiten el significado; para una calidad matizada, se necesita evaluación humana o con modelo-juez.
RAG recupera contexto irrelevante o demasiado escaso.
Ajuste el tamaño/solapamiento de los chunks, top-k, el embedding model, y añada re-ranking; verifique la calidad de la recuperación por separado de la generación.
Por qué: La mayoría de los fallos de RAG son fallos de recuperación; arregle la recuperación antes de culpar al generador.
Decida cuál de dos variantes de prompt funciona mejor.
Ejecute ambas contra un conjunto de evaluación fijo y compare las métricas; itere sobre datos y prompts, no solo sobre el modelo.
Por qué: La comparación controlada con las mismas entradas aísla el efecto del cambio de prompt.
Después de hacer fine-tuning en una tarea específica, el modelo pierde la capacidad general.
Catastrophic forgetting. Mitigue con PEFT/LoRA, LR más baja, menos épocas o mezclando datos generales en el conjunto de fine-tuning.
Por qué: El ajuste basado en adaptadores preserva los pesos base, limitando la desviación de las capacidades originales.
Cure un gran corpus web/texto para el entrenamiento de LLM a escala de GPU.
NVIDIA NeMo Curator — limpieza, deduplicación, filtrado de calidad y manejo de PII acelerados por GPU para datos de entrenamiento.
Por qué: La calidad de los datos impulsa la calidad del modelo; Curator escala la curación que sería inviable en CPU.
El corpus de entrenamiento contiene muchos documentos casi duplicados.
Desduplique (exacta y difusa/casi duplicada) antes del entrenamiento.
Por qué: Los duplicados desperdician cómputo, sesgan el modelo hacia contenido repetido y conllevan riesgo de memorización/fuga.
Divida documentos para la recuperación de RAG.
Divida en pasajes semánticamente coherentes con un solapamiento modesto; dimensione según el embedding model y el presupuesto de contexto.
Por qué: Los chunks demasiado grandes diluyen la relevancia; los chunks pequeños pierden contexto. El solapamiento preserva el significado de los límites.
El texto raspado en bruto es ruidoso, con contenido repetitivo, tóxico o de baja calidad.
Aplique filtros de calidad y toxicidad, identificación de idioma y heurísticas para descartar documentos de bajo valor.
Por qué: La entrada de mala calidad degrada el modelo; el filtrado mejora la calidad posterior más que añadir volumen en bruto.
Prepare una colección de documentos para la recuperación semántica.
Genere embeddings para cada chunk con un embedding model consistente y almacénelos en un índice vectorial.
Por qué: Los embeddings de consulta y documento deben provenir del mismo modelo para ser comparables.
Verifique si un conjunto de entrenamiento subrepresenta grupos o temas.
Analice la distribución entre clases, fuentes y datos demográficos; reequilibre o aumente las brechas antes del entrenamiento.
Por qué: Los datos de entrenamiento sesgados producen un comportamiento de modelo sesgado; la solución pertenece a la capa de datos.
Los datos de entrenamiento o RAG pueden contener información personal.
Detecte y redacte/mascare PII durante la preparación de datos antes de que llegue a los pesos del modelo o al índice.
Por qué: El conocimiento incorporado en los pesos no puede enmascararse de forma confiable en la inferencia; elimine la PII en la etapa anterior.
Mantenga una aplicación LLM en el tema, bloquee contenido inseguro y prevenga jailbreaks.
NVIDIA NeMo Guardrails — rails programables para control de temas, filtrado de seguridad y flujo de diálogo.
Por qué: Los guardrails aplican políticas en las entradas y salidas independientemente del modelo subyacente.
Reduzca las respuestas confiadas pero erróneas en un asistente desplegado.
Fundamente las respuestas con RAG, requiera citas, añada rails de verificación de hechos y mantenga a los humanos en el bucle para resultados de alto riesgo.
Por qué: La fundamentación proporciona evidencia verificable que el modelo de otro modo inventaría.
La entrada del usuario intenta anular el system prompt o exfiltrar datos.
Defensa en profundidad: guardrails, filtrado de entrada/salida, aislamiento de instrucciones y permisos de herramientas con el menor privilegio para agents.
Por qué: Ningún control único detiene la inyección; combine el filtrado con capacidades limitadas.
Un modelo desplegado produce salidas sesgadas o injustas para ciertos grupos.
Audite las salidas en busca de sesgos, reequilibre/aumente los datos de entrenamiento y añada verificaciones de equidad a la evaluación.
Por qué: El sesgo generalmente se origina en los datos; mídelo y corríjalo antes y después del despliegue.
Los prompts y las respuestas no deben salir del control de la organización.
Autohospede con NIM/Triton en infraestructura propia, cifre los datos y evite enviar contenido sensible a APIs de terceros.
Por qué: El despliegue on-prem o VPC mantiene los datos confidenciales dentro del límite de confianza.