De RAG a voz: cómo construir IA en producción que realmente sale al aire

Un founder nos mostró una demo el mes pasado. Chatbot precioso respondiendo preguntas sobre 50,000 PDFs. Lanzado a 200 usuarios enterprise el lunes. Para el miércoles inventaba números de caso, alucinaba términos de contrato y quemaba $4,200/día en tokens. Lo bajaron el viernes.

Este es el gap de producción de la IA, y es donde muere la mayoría de proyectos en 2026. La demo funciona contra una pregunta limpia sobre un dataset limpio. Producción te da 50,000 PDFs desordenados, una cola larga de formas de preguntas que nadie anticipó, usuarios pegando transcripciones de 30K tokens en el buscador, y un equipo de finanzas preguntando por qué la factura de OpenAI se triplicó. Cerrar ese gap es el trabajo real.

Esto es lo que hemos aprendido shippeando IA en producción para 14 clientes en los últimos 18 meses: qué funciona, qué no, en qué gastar plata, y dónde negarse a cortar esquinas.

RAG que sobrevive usuarios reales

Retrieval-augmented generation es la columna vertebral de la IA enterprise útil en 2026. Prompting puro contra un modelo frontier es genial para chat general. Fine-tuning puro es para tareas estrechas y estables. Todo lo demás — búsqueda sobre tus datos, asistentes de soporte, copilots internos — es RAG.

El pipeline naive de RAG (embed todo, similitud coseno, mete top-k en el prompt) es lo que ves en tutoriales. También es lo que falla a escala. Aquí está la versión production-grade.

El chunking es donde más pipelines se rompen

Las estrategias default de chunking parten documentos en ventanas de 500 tokens con overlap de 50. Esto destruye contexto, especialmente para docs legales, médicos y técnicos donde el significado vive cruzando páginas.

Lo que sí funciona en 2026:

• Chunking semántico por sección. Usa la estructura del propio documento — headers, secciones, párrafos. Para PDFs no estructurados, usa un parser layout-aware (Unstructured.io, LlamaParse o Reducto).
• Parent-child chunks. Indexa chunks pequeños para precisión de retrieval, devuelve el chunk padre (la sección completa) para contexto. LangChain le dice ParentDocumentRetriever. Nosotros le decimos la cosa que sí funciona.
• Chunks con metadata. Adjunta a cada chunk: nombre de archivo fuente, número de página, título de sección, fecha de última actualización, permisos de acceso. Vas a necesitar todos después.

La búsqueda híbrida le gana a la vectorial

La búsqueda vectorial pura es mala con queries de exact-match. Pregúntale a tu sistema vector-only por “sección 4.2.1” y mira cómo devuelve chunks semánticamente similares pero equivocados.

Corremos búsqueda híbrida por defecto: BM25 (léxica) más similitud vectorial, fusionada con reciprocal rank fusion. En Postgres con pgvector, son 30 líneas extra de SQL. En Pinecone o Weaviate es un feature flag. Sáltatelo y vas a quemar semanas debuggeando “por qué devolvió el doc equivocado.”

El reranking no es opcional

Retrieval te da 50 candidatos. El contexto del LLM aguanta quizás 10. Elegir cuáles 10 con un reranker (Cohere Rerank, Voyage o un BERT pequeño fine-tuneado) sube la calidad de respuesta 15-30% en cada eval que hemos corrido. El costo es $0.0005 por query. Agrégalo.

Cuándo elegir qué storage

• pgvector en Postgres. Elección default para menos de 5M chunks. Ya tienes Postgres. Un sistema menos que operar.
• Pinecone. Cuando cruzas 10M chunks o necesitas aislamiento multi-tenant con metadata por namespace. Costos escalan con vectores almacenados.
• Turbopuffer. Barato a escala, cold starts rápidos. Vemos más equipos moviéndose acá en 2026.
• Weaviate o Qdrant self-hosted. Cuando data-residency o costo-a-escala lo demanda. Tomas el ops.

Agentes verticales que manejan workflows reales

Los “agentes de IA” genéricos que navegan la web y reservan vuelos son mayormente una demo. Los agentes útiles en 2026 son verticales: manejan un workflow end-to-end dentro de un dominio, con herramientas restringidas a ese dominio.

El patrón que más shippeamos: un agente de soporte que lee un ticket, jala el estado de la cuenta del cliente vía API, chequea contra documentación vía RAG, redacta una respuesta, y o la manda (tickets de bajo riesgo) o rutea a un humano con un draft recomendado (tickets de alto riesgo).

Construir eso confiablemente requiere cuatro cosas que la mayoría de equipos se salta.

Herramientas, no acciones free-form

Definimos cada acción que el agente puede tomar como una función tipada: get_customer_account(customer_id), check_refund_eligibility(order_id), escalate_to_human(reason, priority). El LLM elige herramientas y argumentos; código determinístico las ejecuta. Esta es la diferencia entre un agente que funciona y un agente que “lo intenta.”

LangGraph y el Agents SDK de OpenAI formalizan este patrón. La API de tool-use de Anthropic lleva dos años estable. No hay excusa para acciones free-form en 2026.

Las máquinas de estado le ganan a “deja que el modelo lo descubra”

Para workflows con más de tres pasos, usamos una máquina de estado explícita. El LLM decide transiciones; el framework hace cumplir la validez. LangGraph, el agent kit de Inngest, o Temporal-con-pasos-LLM funcionan acá.

Dejar a GPT-5 o Claude 4.7 “descubrir el workflow” funciona en demos. En producción, con 500 usuarios concurrentes, vas a ver el agente loopearse, saltarse pasos requeridos, o simplemente colgarse. Las máquinas de estado lo arreglan.

Guardrails en tres capas

• Input. Filtra intentos de prompt injection antes de que peguen al modelo. Lakera, NeMo Guardrails o un clasificador pequeño que entrenas tú.
• Tool. Chequeo de permisos en el límite de la herramienta. El modelo puede pedir reembolsar $50K; tu código se niega a menos que el usuario sea admin.
• Output. Scrubbing de PII y chequeos de política antes de que la respuesta llegue al usuario.

Los guardrails no son opcionales cuando tienes clientes reales. El costo de un output malo a un cliente importante es más alto que cada guardrail que vas a pagar.

Evals desde el día uno

Si no tienes un eval set, no tienes un producto de IA. Tienes una vibra.

Nuestro mínimo: 50 casos de prueba curados a mano que representan inputs reales de usuarios, con outputs esperados (o señales de comportamiento esperado). Re-corre en cada cambio de prompt, cada upgrade de modelo, cada tweak de retrieval. Trackea pass rate y latencia en el tiempo.

Herramientas que usamos: Braintrust, LangSmith, o un harness propio con PostHog loggeando los resultados. Honeycomb si quieres tracing OpenTelemetry-native.

Agentes de voz — modo difícil

La voz es donde más equipos subestiman el trabajo de ingeniería por 10x. Un RAG de texto que tarda 3 segundos en responder se siente bien. Un agente de voz que tarda 3 segundos se siente roto.

Budget de latencia objetivo para un agente de voz: menos de 800ms desde fin-de-habla hasta inicio-de-respuesta. Menos de 500ms se siente natural. Más de 1.2s y el usuario cuelga.

Ese budget se come rápido:

• Speech-to-text: 100-200ms (Deepgram Nova-3, AssemblyAI Universal-2)
• LLM first-token latency: 200-500ms (Claude Haiku, GPT-4.1 Mini o un modelo pequeño fine-tuneado)
• Text-to-speech first-byte: 100-300ms (ElevenLabs Turbo, Cartesia, OpenAI tts-1)
• Overhead de red y orquestación: 50-200ms

Las empresas de infra que resuelven la mayoría de esto por ti en 2026: Vapi, Retell, LiveKit Agents y Pipecat. Elige una. Construye solo la lógica de negocio.

Las cosas no obvias que importan más que el modelo elegido para voz:

• Manejo de interrupciones. Las conversaciones reales se interrumpen. Si tu agente no puede ser cortado a media oración, se siente robótico.
• Detección de endpoint. Saber cuándo el usuario dejó de hablar. VAD (voice activity detection) necesita tuning por caso de uso. Soporte aguanta más pausa que dispatch de emergencias.
• Stream de todo. STT streamea al LLM, el LLM streamea al TTS, el TTS streamea al audio. Cualquier lugar donde esperas una respuesta completa es donde muere la latencia.
• Fallbacks. Cuando el LLM se cuelga, el agente dice “déjame chequear eso” mientras encolas un retry en background. El silencio es la peor UX.

Hemos shippeado agentes de voz para calificación de ventas, agendamiento de citas e intake clínico. Los que funcionan tratan la voz como un problema de sistemas en tiempo real, no como un problema de IA.

LLM ops — las cosas aburridas que deciden si sobrevives

Los equipos cuyos productos de IA siguen vivos al mes 12 comparten unos hábitos.

Techos de costo, no estimaciones de costo

Cada llamada al LLM lleva un budget de tokens. Cada usuario un techo diario. Cada endpoint un circuit breaker. El comportamiento default cuando se rompe el budget: degradar grácilmente (modelo más pequeño, respuesta cacheada, “vemos alto volumen, intenta en un minuto”). Nunca seguir quemando en silencio.

Usamos Helicone o Langfuse para trackear gasto por usuario y por feature. Un reporte semanal va al equipo. Las sorpresas en la factura de OpenAI dejan de aparecer.

Cachear lo cacheable

Prompt prefix caching (Anthropic, OpenAI y Gemini lo soportan en 2026) corta costos 50-90% en cargas RAG donde el system prompt y los chunks recuperados se repiten. Préndelo.

Caché semántico de respuestas completas para queries tipo FAQ: otro 30-60% ahorrado. Redis con índice vectorial, o GPTCache.

Routing de modelos

No toda query necesita el modelo frontier. Ruteamos por complejidad: clasificación simple de intent a Haiku o 4.1-mini, razonamiento complejo a Sonnet o GPT-5, el trabajo analítico más pesado a Opus o o3. Un router (custom u OpenRouter) ahorra 60-80% del gasto en la mayoría de productos.

Observabilidad

Cada llamada LLM loggea: prompt, respuesta, latencia, tokens, costo, usuario, feature, modelo. Tageamos cada prompt con una versión. Cuando cae la calidad, sabemos exactamente qué cambio la causó.

Realidad de pricing

Desde $15K. 3-8 semanas.

Lo que eso compra en el piso: un RAG en producción sobre tus datos con retrieval híbrido, evals, guardrails y observabilidad. Deployado, monitoreado, entregado.

En el techo: un agente vertical o agente de voz con workflows multi-tool, máquinas de estado, harness de evals, y 60 días de tuning post-launch.

Lo que no compra: un proyecto “iremos descubriendo el caso de uso a medida que construyamos”. Trae un workflow real que quieras automatizar, o una pregunta real que tus usuarios repiten. IA sin objetivo es la forma más cara de gastar plata en 2026.

Lo que no construimos

Rechazamos proyectos de IA cuando:

• El usuario ya tiene 4 vendors de IA y va por el 5to. El problema no es el modelo.
• El “caso de uso” es “necesitamos IA en el producto”. Eso es un pedido de junta, no un problema.
• Los datos no están listos. Preferimos pasar 4 semanas en pipelines de datos primero que shippear un producto que alucina.

¿Listo para shippear IA que no se rompa el lunes?

Cuéntanos el workflow que quieres automatizar. Volvemos con: viabilidad, arquitectura recomendada, plan de evals, y un precio fijo. Llamada gratis de 30 minutos.

Agenda una llamada sobre IA o lee cómo validamos a nuestros ingenieros antes de confiarles tu stack de IA en producción.