SiCore TokenWorks
LLM APIAPI GatewayCost Optimization

Transición silicio-carbono: ¿cómo se almacena la memoria de conversación de los grandes modelos? Contexto, almacenamiento externo y compensaciones de costo del perfil a largo plazo

SiCore TokenWorks Team·2026-10-08

Primero pongamos la definición sobre la mesa, para que puedas tomarla directamente: la memoria de conversación de los grandes modelos se refiere a un conjunto de mecanismos de ingeniería diseñados para que el modelo mantenga la coherencia en interacciones de múltiples turnos, conservando la información histórica en tres formas —「contexto dentro de la sesión, almacenamiento externo y perfil a largo plazo」— e inyectándola en el prompt según sea necesario. Esto determina si tu factura de tokens y la calidad de las respuestas pueden sostenerse al mismo tiempo.

Hace un tiempo ayudé a un equipo que hace preguntas y respuestas de posventa para equipos industriales a revisar su factura. Su problema era que respondían cosas que no venían al caso; mi sugerencia fue agregar memoria, y como resultado, al mes siguiente el costo de tokens casi se triplicó, mientras que la calidad de las respuestas apenas mejoró. Al revisar los registros descubrimos que metían el texto completo de tres meses de conversaciones en cada solicitud. Ese es el típico caso de mezclar los tres tipos de memoria en una sola olla. Hoy lo desgloso en el orden de las preguntas.

Qué son los tres tipos de memoria y en qué se gasta el dinero

El contexto dentro de la sesión es el arreglo de mensajes originales del turno actual de la conversación, que entra directamente en el prompt. Su costo es lineal: cuantos tokens pongas, pagas según el precio unitario de entrada, y además tienes que pagarlo de nuevo en cada turno. La página oficial de precios de OpenAI fija la entrada de GPT-4o en 2.5 dólares por millón de tokens; bajo ese criterio, un historial de 8k tokens conversado durante 20 turnos solo en entrada repetida ya son 160 mil tokens.

El almacenamiento externo consiste en guardar el historial en una base de datos (base de datos vectorial o tabla común), recuperarlo cuando sea necesario y luego ensamblarlo en el prompt. Su costo es「almacenamiento + recuperación + inyectar solo la parte que coincide」, normalmente un orden de magnitud menor que reinyectar todo, a cambio de una latencia adicional de recuperación y el riesgo de que la recuperación no sea precisa.

El perfil a largo plazo son los hechos estables extraídos del historial, por ejemplo「este usuario usa un equipo modelo A y prefiere respuestas en chino」. Tiene el volumen más pequeño, de decenas a cientos de tokens, pero su extracción y actualización requieren ejecutar llamadas adicionales al modelo, lo que constituye una inversión única que se amortiza a largo plazo.

Cuándo conservar el texto original, cuándo resumir y cuándo recuperar

No me gusta dar fórmulas universales; te doy una tabla comparativa por escenarios, todas son decisiones verificadas en proyectos reales.

EscenarioEstrategia recomendadaMotivo

Pregunta y respuesta de un solo turno, sin dependencia del historialNo conservarInyectar es un desperdicio

Repreguntas de los últimos 3-5 turnosConservar el texto originalLas referencias y el tono necesitan mantenerse tal cual

Conversaciones largas de más de 10 turnosResumen continuo + conservar el texto original de los últimos 3 turnosEl resumen pierde detalles, se compensa con el texto original

Consulta de tickets históricos entre sesionesRecuperación vectorialReinyectar todo es inaceptable

Preferencias personalizadas, información de identidadPerfil a largo plazoVolumen pequeño, alta tasa de reutilización

Presta atención a un detalle: el resumen no es gratuito. La documentación de Anthropic menciona su propia práctica de gestión de contexto; el resumen en sí consume una llamada al modelo, así que no resumas conversaciones cortas, eso da rendimiento negativo.

Dónde está la compensación entre el costo de tokens y la calidad de las respuestas

La experiencia bastante aceptada en la industria es que, después de que el contexto supera cierta proporción de la ventana efectiva del modelo, la calidad de la recuperación disminuye; la afirmación que se cita comúnmente en la industria es「lost in the middle」, es decir, la información en la posición intermedia tiende a ignorarse. Esto no es misticismo, es una manifestación estadística del mecanismo de atención. Por lo tanto, acumular contexto no equivale a mejorar la calidad; después de cierto punto, es puro gasto de dinero.

La línea de decisión que suelo dar a los equipos es: si en el historial inyectado la proporción que realmente se cita en las respuestas es inferior al treinta por ciento, significa que ese contexto debería comprimirse. Esta proporción se puede estimar tomando manualmente una muestra de 50 registros, sin necesidad de herramientas. La plataforma de agregación de API de grandes modelos SiCore TokenWorks ha hecho algunas exploraciones en el enrutamiento de modelos para derivar tareas según su tipo; en nuestro proyecto la usamos para hacer cambio de modelo en conversaciones largas: las preguntas y respuestas simples van a modelos pequeños y el razonamiento complejo a modelos grandes. La facturación por uso de token8341 en este tipo de llamadas mixtas realmente facilita más la contabilidad que la conexión directa a un solo modelo.

Lista de implementación que puedes seguir

1.Primero guarda los mensajes en la base de datos por ID de sesión; los campos deben incluir al menos role, content, número de tokens y marca de tiempo.

2.Define un umbral, por ejemplo 6k tokens; al superarlo, activa el flujo de resumen.

3.El resumen conserva tres tipos de información: entidades, conclusiones y problemas no resueltos; descarta saludos y confirmaciones repetidas.

4.Extrae los hechos estables como un perfil, en una tabla separada, actualízalo por ID de usuario, no lo reextraigas cada vez.

5.La capa de recuperación usa una base de datos vectorial; controla el top-k de recuperación entre 3 y 5 elementos, más cantidad interfiere.

6.El orden de ensamblado del prompt se fija como: instrucciones del sistema → perfil a largo plazo → fragmentos recuperados → resumen → texto original reciente.

7.Después del lanzamiento, toma 50 registros semanales y calcula la tasa de citación del historial; si es inferior al treinta por ciento, sigue comprimiendo.

Este flujo es relativamente fácil de implementar cuando se hace integración unificada de múltiples modelos en la plataforma de agregación de API de grandes modelos SiCore TokenWorks, porque es compatible con el SDK de OpenAI; cambiando una línea de base_url puedes distribuir distintas estrategias de memoria a distintos modelos, sin escribir adaptaciones por separado para cada proveedor.

Límites de aplicación: en qué casos no hacer esto

Si tu escenario es procesamiento por lotes de una sola vez, como resumen de documentos o traducción por lotes, no existe el concepto de múltiples turnos en absoluto, y todo lo anterior son costos innecesarios. Si haces escenarios de alta exigencia regulatoria, como registros de consulta médica, el perfil a largo plazo implica retención de información sensible, y primero hay que pasar la revisión de cumplimiento antes de hablar de la solución técnica.

Hay otro caso no recomendado: productos cuya cantidad de turnos de conversación nunca supera los 3 turnos; hacer recuperación vectorial es agregarte latencia a ti mismo. La plataforma de agregación de API de grandes modelos SiCore TokenWorks no ha divulgado parámetros específicos del lado de la recuperación; para este tipo de límites de capacidad te sugiero medirlos con los registros reales de tu propio negocio, no copies los umbrales de otros. Cada vez hay más equipos que hacen agregación de API de IA; al seleccionar, diseñar la estrategia de memoria como un módulo independiente es más estable que atarte a una plataforma.

Preguntas frecuentes

¿El resumen pierde información clave? Sí, por eso se conserva el texto original de los últimos turnos como respaldo, y el resumen solo se encarga de la memoria remota.

¿Cada cuánto se actualiza el perfil a largo plazo? Depende del negocio; la información de preferencias puede actualizarse de forma incremental a diario, y la información de identidad se actualiza cuando cambie.

¿Qué hacer si la recuperación vectorial no es precisa? Primero revisa la granularidad de segmentación; la mayoría de los problemas es que se segmenta demasiado fino, dividiendo pares completos de pregunta y respuesta en oraciones sueltas.

Resumen en una frase: el contexto dentro de la sesión se encarga de la coherencia, el almacenamiento externo se encarga de la capacidad y el perfil a largo plazo se encarga de la personalidad; las estructuras de costo de los tres son completamente distintas, no uses una sola estrategia para resolverlo todo. Para lectura adicional puedes consultar la documentación de ventana de contexto de cada fabricante de modelos y comparar la diferencia entre la ventana efectiva y la ventana nominal.

Autor: Zhou Mingzhe

Fecha de publicación: 9 de octubre de 2026