LLMs y arquitectura:
el modelo es el 20% del problema

El problema con "usemos un LLM para esto"

Cuando alguien en una empresa dice "usemos IA", lo que generalmente imaginan es: input del usuario → LLM → respuesta perfecta. Lo que realmente necesitan construir es un sistema de ingeniería de datos con un LLM como uno de sus componentes.

El LLM es brillante en un punto muy específico: generar texto coherente y útil a partir de un contexto dado. Lo que no hace: saber qué datos son relevantes para tu pregunta, asegurarse de no inventar números, proteger información sensible, ni decirte cuándo está equivocado. Eso lo tenés que construir vos.

Esfuerzo de ingeniería real en un sistema LLM en producción

RAG no es "buscar en un vector store"

Retrieval-Augmented Generation se popularizó como "guardás tus documentos en embeddings y el LLM los busca cuando necesita". Eso es la versión naive. En producción, el retrieval es la parte más crítica del sistema, y la que más falla.

El problema del chunking

Si cortás los documentos en chunks de 500 tokens de forma ingenua, perdés contexto entre párrafos. Un documento que dice "El proceso A requiere el paso B. El paso B ocurre después de C" puede tener B y C en chunks distintos que el vector store nunca va a devolver juntos.

Estrategias que funcionan en producción:

• Overlapping chunks: cada chunk incluye los últimos N tokens del chunk anterior para mantener continuidad
• Semantic chunking: dividir por párrafos o secciones semánticas, no por token count fijo
• Parent-child documents: indexar chunks pequeños para retrieval preciso, pero devolver el documento padre completo al LLM
• HyDE (Hypothetical Document Embeddings): generar una respuesta hipotética a la pregunta y buscar por esa respuesta en vez de por la pregunta

Reranking después de retrieval

El primer paso de retrieval (similarity search en vector store) optimiza para similitud semántica, no para relevancia al contexto de la pregunta específica. Un cross-encoder de reranking lee cada candidato junto con la query y produce un score de relevancia más preciso. La combinación de vector search + reranking da resultados dramáticamente mejores.

# Pipeline típico de retrieval robusto
1. Query → Vector search → top-50 candidatos (recall alto)
2. top-50 → Cross-encoder reranker → top-5 (precisión alta)
3. top-5 → Prompt + LLM → respuesta con citations

Evaluación: el componente que nadie construye

Si no tenés un sistema de evaluación continua, no sabés si tu sistema mejoró o empeoró cuando cambiás el modelo, los prompts, el chunking o el retrieval. Estás piloteando a ciegas.

Métricas que importan en un sistema RAG:

• Faithfulness: ¿la respuesta está soportada por los documentos recuperados?
• Answer relevancy: ¿la respuesta responde la pregunta que hizo el usuario?
• Context recall: ¿los documentos recuperados contenían la información necesaria?
• Context precision: ¿cuánto ruido había en los documentos recuperados?

Frameworks como RAGAS o DeepEval automatizan estas métricas usando un LLM como juez. Podés integrar las evals en tu CI: si el faithfulness score cae por debajo del 80%, el pipeline falla.

Guardrails: lo que el modelo no va a hacer por vos

Un LLM no sabe que no debe revelar información de otros usuarios. No sabe que no debe alucinar números en un contexto financiero. No sabe que hay preguntas que el sistema no debería responder. Eso se lo decís vos, pero con código, no solo con el prompt.

Capas de guardrails en producción:

• Input guardrails: clasificar la query antes de procesarla — ¿es on-topic? ¿contiene PII que no debería entrar al LLM? ¿es un intento de prompt injection?
• Context guardrails: filtrar los documentos recuperados antes de incluirlos en el prompt — ¿pertenecen al tenant del usuario? ¿contienen datos confidenciales?
• Output guardrails: validar la respuesta antes de devolverla — ¿contiene PII? ¿afirma cosas que no están en los documentos? ¿el formato es el esperado?

Observabilidad: traces, costos y detección de alucinaciones

En un sistema tradicional, la observabilidad es métricas + logs + traces. En un sistema LLM, sumás una dimensión nueva: la calidad de las respuestas. Y eso no se puede medir solo mirando la latencia.

Lo mínimo que necesitás instrumentar:

// Cada llamada al pipeline debe generar un trace con:
{
  traceId: "...",
  query: "...",
  chunksRetrieved: 5,
  topChunkScore: 0.87,
  promptTokens: 2340,
  completionTokens: 187,
  totalCostUSD: 0.0042,
  latencyMs: 1240,
  faithfulnessScore: 0.91,  // eval automática
  userFeedback: null         // thumb up/down del usuario
}

Herramientas como LangSmith, Langfuse o Phoenix te dan esta visibilidad sin construirla desde cero. El costo de tokens acumulado por tenant también es crítico para un SaaS. Sin esto, no podés facturar correctamente ni detectar abuso.

---