Hasta hace poco, una conversación de soporte de 6 meses entre un cliente y una marca no podía pasar al modelo de IA en una sola llamada. Había que resumir, recortar, vectorizar y recuperar trozos vía RAG. Funcionaba, pero perdía matices: tono histórico, decisiones previas, frases textuales del cliente, contradicciones entre sesiones.
Con la liberación de modelos con ventanas de 1 millón de tokens (Claude Sonnet 4.6, GPT-5, Gemini 2.5 Pro), el cálculo cambia. La pregunta ya no es qué resumir, sino cuándo todavía conviene resumir. Esta guía cubre qué se desbloquea y qué problemas — sorprendentemente — no resuelve.
La aritmética nueva
Un millón de tokens son aproximadamente 750.000 palabras. Para dimensionar:
- Una conversación típica de WhatsApp soporte: 500-2.000 palabras / mes por cliente activo
- Un historial completo de 12 meses con un cliente: ~25.000 palabras
- Toda la documentación de producto + políticas + FAQs internas: 50.000-150.000 palabras
- Manual de operaciones de una empresa mediana: 200.000-400.000 palabras
Con 1M tokens, podés llevar al modelo el historial completo del cliente + toda la documentación + las últimas 50 conversaciones de casos similares y todavía sobrar espacio. Sin RAG, sin pérdida.
Qué se vuelve viable
1. Memoria longitudinal de cliente, sin embeddings
Antes: vectorizabas cada conversación previa, hacías top-k similarity, recuperabas snippets. Útil pero ruidoso.
Ahora: cargás el historial completo del cliente como contexto. El modelo recuerda que en marzo te dijo que prefería WhatsApp por la mañana, que su hijo tiene 4 años, que ya tuvo un siniestro en 2024. Ese contexto persiste en cada turno sin trabajo de retrieval.
2. Onboarding instantáneo de nuevos agentes
Cargar todo el manual de operaciones, todas las políticas, los últimos 6 meses de casos resueltos por humanos como ejemplos. Un agente IA "junior" recién instanciado tiene acceso al equivalente del onboarding de un humano de 6 meses, sin training adicional.
3. Análisis de cohortes de conversaciones
Un equipo de ops puede pedirle al modelo "leé estas 200 conversaciones de quejas del último mes y dame los 5 patrones más frecuentes con citas textuales". Antes requería un pipeline de NLP custom; ahora es una llamada con contexto largo.
4. Long-form research con fuentes
Procesar 30 PDFs de regulación de un país y extraer las cláusulas relevantes para un caso específico. Útil en seguros, banking, legal — donde antes había que hacer RAG con re-ranking.
5. Contratos vivos con histórico
Una conversación que arranca en enero y sigue en agosto puede ser una sola sesión continua para el modelo. El cliente que vuelve después de meses encuentra a una IA que recuerda exactamente lo que se conversó.
Qué NO resuelve
Aquí es donde la mayoría de los anuncios omiten la letra chica:
1. Costo lineal con el contexto
Procesar 1M tokens cuesta significativamente más que procesar 100K. Si cargás el historial completo en cada turno de cada cliente, el costo escala feo. Hay dos mitigaciones: prompt caching (cachear el contexto invariante para abaratar reuse), y tiering (contexto pesado solo en turnos críticos, no en cada saludo).
2. Latencia
Más contexto = más latencia. En WhatsApp el cliente espera segundos, no minutos. La estrategia que mejor funciona: contexto medio en hot path (~50-100K tokens), contexto grande en background para análisis o decisiones difíciles.
3. Lost in the middle
Aunque el modelo "vea" 1M tokens, su atención no es uniforme. Información en el medio del prompt tiende a tener menor recall que info al principio o al final. Para producción, todavía conviene estructurar bien el contexto y poner lo crítico en posiciones favorables.
4. Privacidad y retención
Cargar el historial completo de un cliente en cada llamada implica que esos datos viajen a la API en cada turno. Para sectores regulados (salud, finanzas), eso puede chocar contra políticas de minimización de datos. Solución: pseudonimización + flags de qué información puede salir.
5. Calidad de la fuente
Si cargás 200K tokens de "todo lo que sabemos sobre el cliente" pero esa data está mezclada con notas internas inconsistentes, el modelo puede usar lo equivocado. Más contexto no sustituye a curaduría de la fuente.
El patrón que está funcionando: contexto stratificado
En implementaciones LATAM bien diseñadas, el patrón que da mejor resultado es estratificar el contexto en capas:
- Capa 1 — Identidad (siempre, ~2K tokens): perfil del cliente, preferencias declaradas, idioma, tono.
- Capa 2 — Sesión actual (siempre, ~5K tokens): los últimos 50 turnos del hilo activo.
- Capa 3 — Historial reciente (a demanda, ~30K tokens): últimas 5 conversaciones / interacciones.
- Capa 4 — Histórico profundo (solo cuando se detecta caso complejo, ~200K tokens): historial completo + documentación + políticas.
El modelo solo accede a la Capa 4 cuando un classificador upstream marca el caso como "needs deep context" — atención de siniestros graves, escalación a tier-2, análisis post-mortem. El 80% de las interacciones no la necesitan.
Implicancia para Keebai y plataformas similares
Para nosotros, el cambio práctico es que ya no necesitamos pipelines de RAG enormes para casos donde antes eran obligatorios. Eso simplifica el stack, reduce puntos de falla y abre nuevos casos de uso (atención longitudinal, agentes con memoria persistente, análisis de cohortes).
Pero la disciplina sigue siendo la misma: curar bien la fuente, estratificar el acceso, medir lo que el modelo está usando, controlar costos. La ventana de 1M es una palanca, no una varita.
Próximos pasos
Si tu operación ya usa IA con RAG, vale la pena auditarlo: probablemente hay 1-2 pipelines donde RAG ya no aporta valor y se puede simplificar a contexto largo directo. Esa auditoría sola puede bajar latencia, reducir costo de infra (Pinecone, Weaviate) y mejorar calidad de respuesta.