Guía técnica de LangChain para principiantes

LangChain es un framework pensado para construir aplicaciones basadas en modelos de lenguaje de forma estructurada. En lugar de hacer una sola llamada a un LLM y ya está, LangChain permite encadenar pasos, gestionar contexto, conectar fuentes externas y crear flujos más útiles para productos reales.

Si estás empezando como desarrollador en el mundo de la IA aplicada, lo más importante es entender tres conceptos base: Chains, Memory y Agents. Una vez entiendes esas piezas, ya puedes construir asistentes, buscadores semánticos, chatbots con contexto y pipelines de RAG.

¿Qué es LangChain?

LangChain es una capa de orquestación para aplicaciones con LLMs. Su objetivo no es reemplazar al modelo, sino ayudarte a organizar el flujo alrededor del modelo. Por ejemplo:

• Preparar prompts de forma dinámica.
• Conectar documentos, APIs o bases de datos.
• Guardar contexto entre interacciones.
• Decidir qué herramienta usar en cada momento.

Dicho de forma simple: el LLM genera texto, pero LangChain organiza la lógica de la aplicación.

1. Chains: encadenar pasos de procesamiento

Un Chain es una secuencia de pasos donde la salida de un paso alimenta al siguiente. Es el concepto más directo de LangChain y el primero que conviene dominar.

Por ejemplo, imagina este flujo:

1. Recibes una pregunta del usuario.
2. Buscas contexto relevante en una base vectorial.
3. Construyes un prompt con ese contexto.
4. Envías el prompt al LLM.
5. Devuelves la respuesta final.

Eso ya es un chain.

¿Por qué usar Chains?

• Separan responsabilidades.
• Hacen el flujo más mantenible.
• Permiten depurar cada paso.
• Facilitan reutilizar componentes.

Ejemplo conceptual de Chain

Pregunta del usuario
   -> Recuperar documentos relevantes
   -> Formatear contexto
   -> Construir prompt
   -> Llamar al LLM
   -> Respuesta

En un proyecto real, este patrón aparece en asistentes con documentación, buscadores internos y sistemas RAG.

2. Memory: cómo recordar contexto

La Memory permite que una aplicación recuerde información entre mensajes. Sin memoria, cada interacción es aislada. Con memoria, el sistema puede mantener continuidad.

Ejemplo sin memoria:

Usuario: Mi proyecto usa FastAPI y PostgreSQL.
Usuario: ¿Qué arquitectura me recomiendas?
Asistente: ¿Para qué stack?

Ejemplo con memoria:

Usuario: Mi proyecto usa FastAPI y PostgreSQL.
Usuario: ¿Qué arquitectura me recomiendas?
Asistente: Para un stack con FastAPI y PostgreSQL, te conviene…

Tipos de memoria comunes

• Buffer memory: guarda el historial reciente tal cual.
• Summary memory: resume conversaciones largas para ahorrar tokens.
• Entity memory: recuerda entidades concretas, como nombres, proyectos o preferencias.

Cuándo usar Memory

• Chatbots conversacionales.
• Copilots internos.
• Asistentes de soporte técnico.
• Sistemas donde el usuario da contexto en varios pasos.

Ojo: la memoria no sustituye una base de conocimiento. Sirve para continuidad conversacional, no para almacenar grandes volúmenes de información estructurada.

3. Agents: decidir qué hacer dinámicamente

Los Agents van un paso más allá. En vez de seguir una secuencia fija, un agent puede decidir qué acción tomar según la tarea.

Por ejemplo, si el usuario pregunta:

“Busca en mis documentos el contrato más reciente y resume las cláusulas de pago”

Un chain tradicional requeriría un flujo predefinido. Un agent, en cambio, puede:

1. Interpretar la intención.
2. Elegir una herramienta de búsqueda.
3. Leer el documento correcto.
4. Resumir el contenido.

Qué hace un Agent en la práctica

• Recibe un objetivo.
• Evalúa qué herramienta usar.
• Ejecuta una o varias acciones.
• Observa resultados.
• Produce una respuesta final.

Ejemplos de herramientas para Agents

• Búsqueda web.
• Consultas a una base de datos.
• Calculadoras.
• APIs internas.
• Recuperación desde un vector store.

La ventaja principal es la flexibilidad. La desventaja es que el sistema se vuelve más complejo y menos predecible que un chain fijo.

Diferencia rápida entre Chains, Memory y Agents

Ejemplo de flujo de trabajo: PDF -> Embeddings -> Vector Store -> LLM

Este es uno de los patrones más comunes cuando trabajas con documentación privada o conocimiento interno. La idea es transformar un PDF en algo que un LLM pueda consultar de forma eficiente.

Paso 1: cargar el PDF

Primero se extrae el texto del PDF. Ese texto normalmente se divide en fragmentos pequeños llamados chunks. Esto es necesario porque los modelos y los sistemas de embeddings trabajan mejor con bloques controlados de texto.

PDF
   -> extracción de texto
   -> división en chunks

Paso 2: generar embeddings

Un embedding es una representación numérica del texto. En vez de guardar solo palabras, conviertes cada chunk en un vector que captura significado semántico.

Esto permite buscar no solo coincidencias exactas, sino también similitud de significado.

Por ejemplo, “política de devoluciones” y “reembolso de compras” podrían acabar cerca en el espacio vectorial aunque no compartan exactamente las mismas palabras.

Paso 3: guardar embeddings en un Vector Store

Una vez generados los embeddings, se almacenan en un vector store. Este componente está optimizado para búsquedas por similitud semántica.

Algunas opciones conocidas son Chroma, FAISS, Weaviate o Pinecone. La idea es la misma en todas: guardar vectores y recuperar los más parecidos a una consulta.

Chunks de texto
   -> Embeddings
   -> Vector Store

Paso 4: recibir una pregunta del usuario

Cuando el usuario hace una pregunta, esa pregunta también se convierte en embedding. Luego se compara con los vectores almacenados para recuperar los chunks más relevantes.

Pregunta del usuario
   -> Embedding de la pregunta
   -> Búsqueda semántica
   -> Chunks relevantes

Paso 5: enviar contexto al LLM

Finalmente, los fragmentos recuperados se añaden al prompt del modelo. Así el LLM responde usando contexto real del documento, en lugar de depender solo de conocimiento general o de inventar información.

Chunks relevantes
   -> Prompt con contexto
   -> LLM
   -> Respuesta final

Resumen del pipeline completo

PDF
   -> Text Splitter
   -> Embeddings
   -> Vector Store
   -> Retriever
   -> Prompt
   -> LLM
   -> Respuesta

Ejemplo técnico simplificado en Python

Este ejemplo no pretende cubrir todos los detalles de producción, pero sí mostrar la arquitectura mental correcta.

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA

# 1. Cargar PDF
loader = PyPDFLoader("manual.pdf")
docs = loader.load()

# 2. Dividir en chunks
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100
)
chunks = splitter.split_documents(docs)

# 3. Crear embeddings
embeddings = OpenAIEmbeddings()

# 4. Guardar en vector store
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings
)

# 5. Crear retriever
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

# 6. LLM
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# 7. Chain de recuperación + respuesta
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever,
    chain_type="stuff"
)

# 8. Pregunta
response = qa_chain.invoke({"query": "¿Qué dice el PDF sobre autenticación?"})

print(response["result"])

Qué está pasando en ese código

• PyPDFLoader carga el documento.
• RecursiveCharacterTextSplitter divide el contenido en fragmentos manejables.
• OpenAIEmbeddings convierte cada chunk en vectores.
• Chroma almacena esos vectores.
• Retriever recupera los fragmentos más parecidos a la consulta.
• ChatOpenAI genera la respuesta final usando el contexto recuperado.
• RetrievalQA une recuperación y generación en un solo flujo.

Cuándo usar este patrón

El flujo PDF -> Embeddings -> Vector Store -> LLM es ideal para:

• Chat con documentación técnica.
• Búsqueda interna sobre manuales o contratos.
• Soporte al cliente basado en base documental.
• Asistentes para equipos legales, producto o ingeniería.

Errores comunes al empezar con LangChain

1. Meter demasiado texto en un solo chunk

Chunks enormes hacen más difícil recuperar contexto preciso. Mejor trabajar con tamaños moderados y algo de solapamiento.

2. Confundir memoria con conocimiento

La memoria recuerda conversación reciente. El vector store guarda conocimiento consultable. No son lo mismo.

3. Usar Agents cuando un Chain basta

Muchos principiantes montan agents demasiado pronto. Si el flujo es fijo, un chain suele ser más simple, barato y fácil de depurar.

4. No evaluar la calidad de recuperación

Si recuperas malos fragmentos, el LLM responderá mal aunque el modelo sea bueno. En sistemas RAG, la recuperación es tan importante como la generación.

Conclusión

LangChain te ayuda a pasar de “hacer prompts” a construir aplicaciones de IA con arquitectura real. Para empezar, conviene pensar así:

• Chains para flujos definidos.
• Memory para continuidad conversacional.
• Agents para decisiones dinámicas con herramientas.

Y si quieres construir un sistema útil sobre documentos, el patrón PDF -> Embeddings -> Vector Store -> LLM es una de las mejores puertas de entrada. Es práctico, entendible y aparece en muchísimos productos reales basados en RAG.

La mejor forma de aprender LangChain no es memorizar clases, sino entender la arquitectura: qué entra, qué se transforma, qué se recupera y qué consume el modelo. Cuando dominas eso, el framework deja de parecer mágico y empieza a ser una herramienta de ingeniería.