Nuestro primer writeup de BEAM-100K terminó en 70,9% de puntuación media con GLM-5.2 como lector, y defendía que la ingeniería de memoria importaba más que la elección del lector. Tres semanas después estamos en 75,5% de media (323 de 400 correctas, 80,8% binaria) con el stealth Ox Alpha como lector, y en esta ronda el lector pagó casi todo. El lado de la memoria movió el número en casi exactamente cero. Ese es el hallazgo, así que abrimos con él: cuando el retrieval pone el contexto correcto delante del modelo la mayor parte del tiempo, los puntos restantes viven en el lector, y un parámetro de API compra más de ellos que una semana de trabajo de retrieval.
Dos números aparecen en este post y no son intercambiables. El leaderboard del AMB ordena por la media de puntuaciones del juez por criterio; la llamamos "media" a lo largo del texto. La tasa binaria de acierto (correctas/total) siempre da más alta; la llamamos "binaria" y la usamos sobre todo para contar fallos. Cada tabla dice cuál de las dos está usando. El run con effort máximo descrito aquí terminó el 2026-08-23.
Dónde empezamos
Todos los runs de este post usan el mismo juez (GLM-5.2) y el mismo split de 400 preguntas del BEAM-100K. El lector base era Gemini 3.6 Flash sobre el mismo retrieval de ValorBrain: 69,3% de media, 304/400 correctas. El post anterior, con 70,9%, usaba GLM-5.2 como lector y otro juez, así que no es directamente comparable; aparece en la tabla final con su setup declarado.
Las pérdidas se concentraban en abstención y orden de eventos, y el análisis de errores decía que eran problemas del lado del lector. La pregunta era cuánto de esa brecha podía cerrar un lector mejor, y qué más estaba escondido debajo.
Paso 1: cambiar el lector
Reemplazamos Gemini 3.6 Flash por stealth/ox-alpha vía OpenRouter. Nada más cambió. (Nota de identidad: el stealth/ox-alpha fue revelado después como el GLM-5.3-flash de Z.ai servido bajo el alias stealth de OpenRouter — un modelo open-weights de tier flash.)
69,3% → 72,3% de media (304 → 313 correctas).
Tres puntos con un cambio de modelo es una ganancia sólida y poco notable. Y se estancó de inmediato, como le pasa a todo equipo que lanza modelos mayores sobre setups retrieval-augmented: si el contexto lleva ruido o datos viejos, el razonamiento mejor se quema en entradas malas.
Paso 2: perfilar todo
Mientras los benchmarks corrían, perfilamos la infraestructura debajo. Tres cosas aparecieron.
Índices HNSW halfvec. El retrieval denso corría sobre índices HNSW float32 completos, 2,5 GB en cuatro tenants. Cambiar al halfvec_cosine_ops de pgvector cortó el almacenamiento a 687 MB y hizo las queries 4,7x más rápidas, con pérdida de recall cero en nuestro eval. Los vectores se guardan como fp16 dentro del índice y las distancias exactas siguen disponibles en el momento de la query.
Un bug de validación en nuestro access method personalizado de PostgreSQL. Cada acceso a valor multivector corría un scan completo del buffer de comprobaciones isfinite, O(count x dim). Token pooling accede valores O(tokens²) veces por documento, así que a 500 tokens por documento el build quemaba miles de millones de comprobaciones redundantes. Quitar la validación redundante de los caminos calientes llevó builds de horas a minutos.
Dos migraciones que nunca corrieron. El runner no alcanzaba la base de datos, así que dos migraciones quedaron pendientes. Una de ellas creaba admin_active_users_5m(), función de monitoreo que venía fallando en silencio en los logs de producción durante semanas. Aplicadas.
Nada de esto movió el benchmark. Hizo posible iterar, lo que vale más que un punto de exactitud en un ciclo de tres semanas: builds que llevaban horas pasaron a llevar minutos, y por fin se podía ver qué estaba haciendo el sistema.
Paso 3: esfuerzo de razonamiento
Ox Alpha es un modelo de razonamiento, y OpenRouter lo enruta con esfuerzo moderado por defecto. Seteamos reasoning.effort: "max".
72,3% → 75,5% de media (313 → 323 correctas). Un parámetro de API, 3,2 puntos.
Por categoría, puntuación media del juez, 40 preguntas cada una:
| Categoría | Esfuerzo default | Esfuerzo máx | Δ |
|---|---|---|---|
| preference_following | 86,2% | 96,5% | +10,3 |
| information_extraction | 84,2% | 89,6% | +5,4 |
| instruction_following | 83,1% | 86,9% | +3,8 |
| temporal_reasoning | 69,4% | 72,5% | +3,1 |
| summarization | 67,4% | 70,4% | +3,0 |
| contradiction_resolution | 87,2% | 90,0% | +2,8 |
| knowledge_update | 60,0% | 62,5% | +2,5 |
| multi_session_reasoning | 66,3% | 68,3% | +2,0 |
| event_ordering | 53,4% | 54,2% | +0,8 |
| abstention | 62,5% | 60,0% | −2,5 |
Nueve de diez categorías suben. La única que baja, abstención, es la que revela el mecanismo: preguntas en las que el comportamiento correcto es negarse a responder. Más razonamiento dejó al modelo más seguro, y los modelos seguros responden en lugar de negarse. Orden de eventos, nuestra peor categoría, casi no se mueve: pensar más no fabrica estructura cronológica que el contexto no tiene.
Costo: las respuestas tardan aproximadamente 44% más. Para análisis en batch, intercambio fácil. Para chat interactivo mantenemos el esfuerzo default.
Paso 4: construir el rerank ColBERT, y después apagarlo
Construimos un reranker ColBERT late-interaction sobre LFM2.5-ColBERT-350M: scoring a nivel de token sobre representaciones pooled de documentos, guardadas como códigos sq8 cuantizados en un índice de grafo personalizado de PostgreSQL, tokens de query embebidos por un servicio sidecar, MaxSim contra los candidatos, resultados reordenados. Corrió de punta a punta.
Efecto neto en el benchmark completo: 72,3% → 73,0% de media (313 → 312 correctas). La media esconde la forma:
- multi_session_reasoning +6,6, contradiction_resolution +4,4, preference_following +4,4, instruction_following +3,8
- information_extraction −3,6, abstention −6,3, event_ordering −2,9
MaxSim promueve solapamiento léxico, lo que ayuda a preguntas que sintetizan fragmentos dispersos y perjudica preguntas que dependen de reconocer ausencia o cronología estricta. Una capa que ayuda a la síntesis y daña la abstención, con un neto de +0,7, todavía no es una feature. Es una feature detrás de un router que sepa qué pregunta es cuál. La apagamos, mantuvimos la infraestructura, y volvemos con gating por categoría.
El hallazgo que más importa
Después de los experimentos clasificamos cada fallo del run con esfuerzo default (87 respuestas erradas, binaria) como retrieval miss (la memoria correcta no estaba en el contexto) o reader error (la memoria estaba ahí y el modelo se equivocó igual).
77 de los 87 fallos eran reader errors.
El retrieval pone las ventanas correctas delante del modelo más del 90% del tiempo. Lo que viene después depende de que el lector sintetice entre sesiones, rastree valores a través del tiempo, reconozca cuándo la información no existe y calcule diferencias de fechas. Esos ya son problemas de razonamiento, y por eso un único parámetro de razonamiento rindió más que cualquier cambio de retrieval que probamos en este ciclo.
Progresión completa
| Configuración | Juez | Media | Binaria |
|---|---|---|---|
| Lector GLM-5.2 (post anterior) | deepseek-v4-flash | 70,9% | 78,0% |
| Lector Gemini 3.6 Flash | glm-5.2 | 69,3% | 76,0% (304/400) |
| Ox Alpha, esfuerzo default | glm-5.2 | 72,3% | 78,3% (313/400) |
| Ox Alpha, esfuerzo máx | glm-5.2 | 75,5% | 80,8% (323/400) |
¿Es SOTA? Todavía no.
La configuración RAG de Hindsight hace 86,2% de media en el mismo benchmark (lector Gemini 3.1 Pro, juez Gemini 3.5 Flash). Estamos 10,7 puntos detrás. Su configuración single-query hace 73,4%, que superamos por 2,1 puntos. Lectores y jueces distintos en ambos lados, así que trate cualquier número que cruce sistemas como indicativo; el arnés es público y la comparación honesta es correr los dos usted mismo.
No estamos reclamando SOTA hoy. Estamos reclamando 75,5% reproducibles, con juez declarado, split declarado y arnés público, más una taxonomía de fallos que dice dónde están los próximos diez puntos.
Y un compromiso: vamos por ese 86,2%, en público. Los tres patrones de fallo de abajo son el mapa. Cada intento, acierte o falle, sale escrito aquí y en X. Si nos estancamos, van a ver el estancamiento.
Lo que no funcionó
- Rerank ColBERT como capa universal. Ayuda a la síntesis, daña abstención y extracción. Espera un router.
- Expandir el presupuesto de entrega de contexto. El razonamiento multi-sesión mejoró y el orden de eventos empeoró: más ventanas significa más secuencias compitiendo, y el orden se degrada.
- Configuración uniforme entre categorías. Cada categoría tiene su óptimo. Una sola configuración deja puntos en la mesa.
Conclusiones
Si estás construyendo un sistema de memoria y benchmarkeando de punta a punta:
- Mide retrieval separado de la lectura. No se arregla lo que no se aísla, y la separación dice en qué lado gastar la semana.
- Prueba el esfuerzo de razonamiento antes de añadir infraestructura. Un parámetro, 3,2 puntos de media, cero código.
- Más contexto no es mejor contexto. Nuestra expansión de entrega cambió una categoría por otra.
- Publica detrás de flags. Corrimos ColBERT de punta a punta, medimos un neto de +0,7 y lo apagamos sin downtime.
- Perfila antes de optimizar. Nuestra mayor corrección de performance vino de un stack dump de gdb, no de la intuición.
Lo que sigue
Los 77 fallos restantes se agrupan en tres patrones:
- Síntesis multi-sesión: preguntas que necesitan secuencias completas de eventos armadas desde fragmentos dispersos. Presupuestos de entrega ajustados por tipo de pregunta, no globalmente.
- Cómputo temporal: "cuántos días hay entre X e Y" exige extraer dos fechas, restar y citar ambas. Hints de output estructurado son la siguiente prueba.
- Calibración de abstención: el lector debe distinguir "existe un tópico adyacente" de "la respuesta existe". Ejemplos few-shot de abstención en el prompt son la prueba más barata.
Del lado de la infraestructura: enrutamiento de rerank por categoría (ColBERT solo para preguntas de síntesis), token pooling paralelo entre documentos, y un formato de docmap de 64 bits para índices MV pasando los 33k documentos.
Reproduciendo
Los resultados son reproducibles vía el Agent Memory Benchmark con el provider ValorBrain. Crea una cuenta ValorBrain en valorbrain.valor.digital para obtener una clave de API.
Referencias
- Tavakoli et al. (2025). "Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs." ICLR 2026.
- Vectorize/Hindsight. "Agent Memory Benchmark (AMB)." https://github.com/vectorize-io/agent-memory-benchmark
- Post anterior: "La Calidad de la Memoria Vale Más Que el Lector: Evidencia del BEAM-100K" (2026-08-04)