Preparación para entrevistas en LangChain con respuestas cortas, detalles más profundos y trampas comunes

Las preguntas de entrevista sobre LangChain fallan cuando se convierten en trivia sobre nombres de clases. A los responsables de contratación que han desarrollado sistemas reales les importa si puedes identificar el problema, elegir la abstracción adecuada, indicar qué sigue siendo propiedad de tu aplicación y admitir un modo de fallo. Las etiquetas de la API cambian; esa estructura no.

Esta guía sigue ese patrón en temas como conceptos fundamentales, mensajes y prompts, salida estructurada, herramientas, composición y algunos ejercicios de lectura de código. Los ejemplos reutilizan un único ticket de soporte técnico para que las respuestas permanezcan concretas:

Después del lanzamiento de las 14:05, el tráfico de pagos en la UE comienza a fallar. Los registros de checkout-api indican tiempos de espera al llamar a payments-svc.

Trata cada tema como un guion de ensayo: respuesta breve de treinta segundos, seguimiento más profundo y el error común de sonar competente pero omitir el aspecto técnico relevante.

Sección 1: LangChain y llamadas a modelos

¿Qué es LangChain? En resumen: una herramienta de orquestación para combinar llamadas a modelos con prompts, herramientas, recuperación de información y flujos de control. En profundidad: no es un proveedor de modelos ni sustituto de la lógica del producto. Tu aplicación sigue siendo responsable de la autenticación, la gestión por tenant, la evaluación y de qué significa “completado” para un ticket. Error común: describirlo como “un LLM” o como algo obligatorio para todas las llamadas a OpenAI.

¿Cuándo deberías usar en su lugar un SDK de proveedor directo? En resumen: cuando el proceso consiste en una sola llamada a un modelo con prompts estables y sin grafos de herramientas ni recuperación de información. En profundidad: los SDK minimizan las partes móviles en funcionalidades simples; LangChain resulta útil cuando necesitas composiciones ejecutables, bucles de herramientas o abstracciones compartidas entre proveedores. Error común: envolver todo “por flexibilidad futura” antes de contar con un segundo proveedor o una segunda etapa.

Proveedor vs modelo vs interfaz de LangChain. En resumen: el proveedor aloja los modelos; un modelo es una opción concreta de endpoint o pesos; la interfaz de LangChain es un envoltorio portátil que hace que las operaciones de invocación, flujo y procesamiento en lotes se vean similares. En profundidad: la portabilidad es parcial, ya que persisten las peculiaridades de los herramientas y los límites de tokens. Error común: asumir que cambiar los argumentos de init_chat_model nunca afecta el comportamiento.

¿Qué hace init_chat_model? En resumen: crea un objeto de modelo de chat a partir del nombre del modelo y de opciones opcionales del proveedor.

from langchain.chat_models import init_chat_model

model = init_chat_model(
    "provider:model-name",
    temperature=0,
    timeout=20,
)

En profundidad: centraliza la configuración de modo que el resto del sistema dependa de un objeto Runnable, y no de un cliente SDK codificado de forma fija. Error común: tratarlo como algo mágico que elimina la necesidad de comprender los límites de tasa y las ventanas de contexto.

Métodos principales de invocación. En resumen: invoke para un uso único, stream para tokens, batch para listas, además de variantes asíncronas cuando están disponibles. En profundidad: el streaming modifica la forma en que se manejan las llamadas a herramientas y las actualizaciones de la interfaz; el batching afecta la granularidad de los fallos. Error común: usar batch cuando se necesita la cancelación por elemento.

¿Hace que la temperatura haga al modelo determinista? En resumen: no. En profundidad: la temperatura influye en la aleatoriedad, pero las semillas, los detalles de muestreo y los cambios en el lado del proveedor siguen siendo importantes. Para auditorías, prefiera los modos deterministas del proveedor cuando existan y verifique igualmente. Error común: prometer resultados idénticos solo con temperature=0.

Sección 2: Mensajes y prompts

¿Por qué usar objetos de mensaje en lugar de una única cadena larga? En resumen: los roles (sistema/usuario/asistente/herramienta) aportan la estructura que los proveedores esperan para las llamadas a herramientas y el estado en múltiples turnos.

from langchain.messages import HumanMessage, SystemMessage

messages = [
    SystemMessage(
        "Review tickets using only the supplied evidence."
    ),
    HumanMessage(ticket_text),
]

Más en profundidad: los mensajes estructurados permiten añadir resultados de herramientas sin tener que modificar la cadena textual. Error: concatenar las transcripciones en un único bloque de texto del usuario y preguntarse por qué se interrumpen los bucles de las herramientas.

Plantillas de prompts vs. plantillas de prompts de chat. En resumen: las plantillas de cadena formatean el texto; las plantillas de chat formatean listas de mensajes con variables.

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
    ("system", "Classify the ticket. Return the schema."),
    ("human", "Service: {service}\nTicket: {ticket_text}"),
])

Más en profundidad: las plantillas de chat mantienen estables las instrucciones del sistema mientras que los campos del usuario cambian según cada solicitud. Error: ocultar el texto de políticas mutable únicamente dentro de los mensajes del usuario, lo que hace que se elimine primero bajo presión.

¿Cómo se depura una plantilla? En resumen: formátela o invóquela e inspeccione los mensajes resultantes sin llamar a un modelo.

value = prompt.invoke({
    "service": "checkout-api",
    "ticket_text": "database connection refused",
})

assert value.messages[0].type == "system"
assert "checkout-api" in value.messages[1].content

Más en profundidad: cree capturas de estado de los mensajes formateados en las pruebas para que las ediciones rápidas no eliminen silenciosamente variables. Error: depurar únicamente leyendo las respuestas del modelo.

Sección 3: Salida estructurada

¿Por qué parsers/salida estructurada? En resumen: convierten las respuestas de texto libre del modelo en campos que el código normal puede validar.

from typing import Literal
from pydantic import BaseModel, Field

class TicketClass(BaseModel):
    severity: Literal["SEV1", "SEV2", "SEV3", "SEV4"]
    service: str
    confidence: float = Field(ge=0, le=1)classifier = model.with_structured_output(TicketClass)
result = classifier.invoke(messages)

Más en profundidad: prefiera esquemas que se ajusten a la forma en que el servicio de soporte redacta los tickets —gravedad, servicio afectado, próxima acción— en lugar de ensayos abiertos. Error: usar expresiones regulares frágiles para el análisis después de solicitar “JSON, por favor” en texto narrativo.

Fallo común. Los modelos omiten campos o inventan enumeraciones. Es necesario protegerse con errores de validación que soliciten la acción nuevamente una vez y luego transfieran el caso a un humano. Los valores predeterminados silenciosos ocultan los incidentes.

Sección 4: Herramientas

¿Qué es una herramienta? En resumen: una función llamable de tipo específico que el modelo puede solicitar, con un nombre, descripción y esquema.

from langchain.tools import tool

@tool
def lookup_service(service: str) -> dict:
    """Return the owner and runbook ID for one service."""
    return service_catalog[service]

En profundidad: la descripción forma parte de la instrucción. Las herramientas vagas se invocan al azar; las demasiado amplias se convierten en brechas de seguridad. Error: exponer SQL o shell sin procesar como herramientas “flexibles” en una demostración que posteriormente se usa en producción.

¿Cómo terminan los bucles de herramientas? En resumen: límite máximo de iteraciones, acciones explícitas para respuesta final o condiciones basadas en grafos. En profundidad: siempre registrar las entradas/salidas de las herramientas para el registro de auditoría del servicio de soporte. Error: bucles ilimitados con APIs inestables.

Sección 5: Composición

¿Qué hace el encadenamiento de Runnables? En resumen: envía la salida de una etapa a la siguiente.

chain = prompt | model | parser
result = chain.invoke({"ticket_text": ticket_text})

Más en profundidad: la composición al estilo LCEL es legible hasta que aparecen las ramificaciones y los intentos repetidos; entonces, a menudo son más útiles los grafos explícitos (LangGraph o máquinas de estado manuales). Error común: anidar lambdas hasta el punto de que nadie pueda probar el proceso a mitad de camino.

RunnableParallel / agrupación por lotes. Utiliza la distribución paralela cuando la recuperación de datos y el enriquecimiento de metadatos son independientes. Ten en cuenta el costo: la ejecución paralela no es gratuita.

Sección 6: Respuestas estructuradas según el proceso de recuperación

Los entrevistadores suelen preguntar cómo se integra LangChain en RAG. Respuesta breve: los cargadores, divisores, recuperadores y cadenas pueden definir el flujo; tu aplicación sigue siendo responsable de la política de fragmentación, el control de acceso y la evaluación. Más en profundidad: cita los documentos en el esquema de salida estructurado, no solo en texto narrativo. Error común: equiparar “VectorStoreRetriever” con un sistema RAG en producción.

Ejercicios de código

Ejercicio 1: ¿Qué devuelve esto?

reply = model.invoke([
    SystemMessage("Use only the supplied ticket text."),
    HumanMessage(ticket_text),
])

Hablen sobre los tipos y si realmente se llama a un modelo. Muchos fragmentos solo formatean las solicitudes.

Ejercicio 2: ¿Qué garantiza el analizador?

chain = prompt | model.with_structured_output(TicketClass)
result = chain.invoke(values)

Distingan entre “el proveedor prometió el modo JSON” y “su esquema está validado”.

Ejercicio 3: ¿Qué tiene de malo esta herramienta?

@tool
def ticket(action: str, payload: dict) -> dict:
    """Do ticket operations."""

Búsquen strings de documentación/esquema faltantes, efectos secundarios o deficiencias en la autenticación: el servicio de soporte no debe llamar a refund_all sin un ID de ticket.

Ejercicio 4: ¿Pueden ejecutarse estas llamadas juntas?

owner = lookup_owner(service)
incidents = recent_incidents(service)

Analicen el estado compartido, los límites de velocidad y si es seguro realizar llamadas en paralelo para el mismo hilo de conversación.

Ejercicio 5: ¿Qué falta en esta respuesta RAG?

docs = retriever.invoke(question)
answer = model.invoke(format_prompt(question, docs))

Por lo general: citas, filtros de acceso o una ruta de recuperación vacía que debería rechazar la solicitud en lugar de inventar historias sobre el proceso de pago.

Cómo practicar sin memorizar las APIs

Elija diez preguntas y respóndalas en voz alta basándose en la ficha de pago. Mida el tiempo que tarda en dar una respuesta breve. Luego añada la información más detallada solo si surge una pregunta adicional. Mantenga un catálogo personal de los fallos que haya observado: recuperación vacía, alucinaciones de las herramientas, mitos relacionados con la temperatura, porque a los entrevistadores les quedan más grabadas las historias que las rutas de importación.

Cuando el nombre de una API haya cambiado desde su último proyecto, hágalo saber. Decir “En la versión actual de LangChain este es init_chat_model; anteriormente conectábamos manualmente al cliente del proveedor” indica que sigue los cambios en lugar de aferrarse a un tutorial obsoleto.

Qué tienen en común las respuestas sólidas

Parten del daño que sufre el usuario del servicio de soporte, no del nombre del paquete. Separan los elementos adicionales del framework de las responsabilidades del sistema. Nombran los compromisos necesarios: latencia frente a exhaustividad, autonomía frente a auditabilidad, portabilidad frente a las funciones del proveedor. Finalizan indicando cómo verificarían la solución en el entorno de pruebas: mediante fixtures, registros de trazas o conjuntos de evaluación, y no con una respuesta vaga como “lo monitorearíamos”.

Asociación de preguntas con la historia del servicio de soporte

Utilizan el cierre temporal de los procesos de pago en la UE como eje central. Los modelos de clasificación determinan el nivel de gravedad. Las plantillas de mensajes incluyen los nombres de los servicios. La salida estructurada genera un borrador de ticket. Las herramientas obtienen registros desde payments-svc. Cadenas o diagramas compilan la respuesta del manual de procedimientos. La recuperación de información extrae los análisis posteriores a tiempos de inactividad similares del último trimestre. Cada abstracción encuentra su justificación dentro de esa narrativa, y así es como se debe responder cuando una sesión en la pizarra blanca se alarga.

Si el entrevistador cambia de tema a LangGraph, mantén la misma estructura: los estados almacenan los campos de los tickets, los nodos se encargan de clasificar y recuperar información, y las aristas condicionales activan procedimientos adicionales cuando la confianza es baja. No es necesario que recites cada clase; basta con demostrar que sabes cuándo una cadena lineal ya no es suficiente.

Lista de verificación antes de la entrevista

• Explica LangChain en una sola oración sin llamarlo LLM.
• Sabes cuándo omitirlo en favor de una llamada directa al SDK.
• Formatea un prompt para chat y muestra los mensajes resultantes.
• Dibuja un esquema de herramienta que no permita la fuga de información confidencial.
• Describe cómo pruebas un camino RAG con resultados de recuperación vacíos.
• Admite qué no garantiza la parámetro temperatura.
• Cuenta una historia de uso en producción donde los registros detallados superaron a las conjeturas.

Si practicas esos siete y los treinta y cinco ejemplos anteriores, estos se convertirán en variaciones de un mismo tema en lugar de una tarea de memorización forzada. El objetivo no es sonar como la documentación oficial, sino como alguien que ya ha implementado un asistente de servicio al cliente y aún recuerda dónde presentó problemas.

Notas adicionales para la práctica de los conceptos básicos

Los grupos entrevistadores suelen comenzar con definiciones para calmar al grupo, y luego pasar a hablar de los fallos. Prepárate para ambos temas. En respuesta a “¿qué es un Retriever?”, da la explicación relacionada con la interfaz: entrada de consulta, salida de documentos; luego añade inmediatamente cómo manejas los resultados vacíos en el flujo del servicio al cliente. En respuesta a “¿qué es un Documento?”, menciona el contenido de la página además de los metadatos, y luego indica qué campos de metadatos necesitas para las citaciones y los filtros ACL.

Esteja listo para comparar los auxiliares de estilo ConversationalRetrievalChain con rutas LCEL o gráficas construidas a mano. Los auxiliares son adecuados para prototipos. Las rutas creadas manualmente son las mejores cuando se necesitan soluciones alternativas personalizadas, índices por usuario o resultados estructurados que incluyan listas de citas.

En cuanto a la memoria: distinga los buffers del historial de chat de la memoria respaldada por almacenamiento. Los asistentes de soporte técnico que “recuerdan” información a lo largo de varios días requieren persistencia y procesamiento de datos confidenciales, no solo una lista en memoria. Explique cómo evita que la información personal sensible se filtre a los almacenamientos a largo plazo.

En cuanto a la evaluación: nombre los casos de prueba sin conexión (tickets dorados), las trazas en línea y los conjuntos de pruebas de regresión que se ejecutan cuando cambian las solicitudes. Si ha utilizado LangSmith o un herramienta similar, describa una señal en el panel de control sobre la cual tomó acción concreta: picos de latencia tras agregar una herramienta, o una disminución en la cobertura de citas.

Sobre la gestión de versiones: fije las versiones de los paquetes, registre los hashes de los comandos junto a las compilaciones desplegadas, y se niegue a depurar en entornos “de producción” con un cuaderno de notas no fijado. A los entrevistadores que han sufrido por actualizaciones silenciosas les encanta esa respuesta.

Sobre la seguridad: las listas de herramientas permitidas, los filtros de salida para el lenguaje utilizado en reembolsos y la aprobación humana para acciones de alto impacto forman parte importante del relato. LangChain facilita la integración; no elige su política de riesgos.

Sobre configuraciones con múltiples proveedores: explique una razón concreta por la que abstrajo la construcción de modelos —precios, región o conmutación ante interrupciones— y un comportamiento que aún difiere tras la abstracción, como el formato de las llamadas a herramientas. La honestidad sobre posibles fugas de datos es mejor que afirmar una portabilidad perfecta.

Sobre la transmisión a las interfaces de usuario: mencione que las llamadas parciales a herramientas requieren un manejo cuidadoso por parte del cliente y que se debe almacenar en búfer hasta que el nombre de la herramienta esté completo antes de mostrar un indicador de carga para payments-svc. Los pequeños detalles demuestran el trabajo real de implementación.

Sobre las pruebas: demuestre que es posible probar funcionalmente de forma unitaria a las funciones puras relacionadas con el grafo —como los clasificadores de gravedad y los formateadores de citas— sin necesidad de simular todo el proveedor. Reserve las pruebas de integración para la ruta real de llamada.

Estas notas no son preguntas separadas; son detalles que se revelan cuando el entrevistador dice “cuénteme más”. Manténgalas breves, relacionadas con el ticket de compra, y evite elogios excesivos al proveedor. Así es como las preguntas básicas se convierten en ofertas. Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al marco de trabajo. Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al marco de trabajo. Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al marco de trabajo. Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al marco de trabajo. Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al marco de trabajo. Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al marco de trabajo. Mantenga las respuestas c

Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios al marco a nivel de eslogan.Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios al marco a nivel de eslogan.Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios genéricos al framework.Mantenga las respuestas concretas, cite el ticket y prefiera historias de verificación sobre elogios al marco a nivel de eslogan.Prefiera las historias de verificación sobre los elogios al marco a nivel de eslogan. Mantenga las respuestas concretas, cite el ticket correspondiente y opte por historias de verificación en lugar de comentarios genéricos sobre el marco.