Cómo medimos la latencia del RESOLVER bi-temporal.

Qué medimos

Latencia wall-clock de una query bi-temporal contra el grafo de memoria tipada. Bi-temporal significa que la query carga dos ejes de tiempo: cuándo el hecho fue verdadero (valid time) y cuándo el sistema aprendió de él (transaction time). Sub-200ms p99 contra un grafo a escala enterprise es el target público, fijado para igualar el reclamo publicado de Zep. La latencia se mide en el límite del resolver, después de la autenticación y antes de la serialización del agent runtime, así que el número es del substrato, no del stack circundante.

Corpus de prueba

El benchmark público corre contra los test fixtures de ai-brain-starter: un grafo enterprise sintético con 50,000 registros de memoria tipada, 5,000 entidades, 12,000 decisiones y 8,000 eventos abarcando 24 meses de valid time. Los fixtures envían con el repositorio para que la metodología sea reproducible por cualquiera con un git clone y un install de Postgres.

Cómo funciona el harness

• Paso 1. Carga el fixture de 50,000 registros en una base de datos Postgres limpia.
• Paso 2. Calienta el caché con un pase de lectura sobre cada registro (elimina varianza de cold-start).
• Paso 3. Corre mil queries bi-temporales contra el caché caliente, muestreadas aleatoriamente a través de dimensiones de entidad, tiempo y predicado.
• Paso 4. Registra latencia p50, p95, p99 y máxima en el límite del resolver.
• Paso 5. Repite la corrida en tres tamaños diferentes de máquina (4 cores / 16 cores / 64 cores) y publica las tres series.
• Paso 6. Re-corre en cada release tagueada de memory-runtime-pro y appendea al historial público de benchmark.

Cómo lo reproduces tú

Clona github.com/adelaidasofia/ai-brain-starter, instala el harness del resolver desde benchmarks/resolver/README.md, corre el harness contra tu propia máquina. Tus números son tuyos. Envía anomalías a contact@mycelium-ai.co; publicamos corridas reproducibles de terceros junto con las nuestras.

Status actual

Baseline enviada (Bucket 2 retrieval híbrido, 2026-05-09)

El substrato Bucket 2 de retrieval híbrido es sobre lo cual el RESOLVER se sentará para queries bi-temporales. Su primera baseline medida fue enviada el 2026-05-09 contra un corpus sintético de 5,000 notas (30,029 chunks) usando el embedder hash-v1 en hardware comodity (MacBook Air, Apple Silicon). Las diez queries de la batería de queries con forma de producción aterrizaron entre 41 y 58 milisegundos de mediana, incluyendo el caso de fallback sin match léxico que no puede aprovechar FTS5 (57 ms mediana, 93 ms p95).

Arquitectura. Retrieval de dos fases. La Fase A pregunta al sidecar FTS5 de SQLite (una tabla virtual sobre los cuerpos y headings de los chunks, mantenida en lockstep con la tabla principal de chunks por triggers de INSERT/UPDATE/DELETE) por hasta 100-500 candidatos ordenados por rank de bm25(). La Fase B corre un pase de re-ranking con coseno vectorizado en numpy sobre los vectores ya hidratados de esos candidatos. Para queries puramente semánticas con cero overlap léxico, un fallback solo-vector decodifica la matriz entera de vectores en una sola llamada a np.frombuffer sobre los bytes de blob unidos, corre coseno y hace partial-sort de top-K vía numpy.argpartition. El fan-out de BM25 lado-Python que estaba en el camino caliente antes permanece en la clase para compatibilidad hacia atrás pero ya no se invoca.

Metodología. 10 queries con forma de producción (la misma batería que el ingeniero de IA del comprador correría: 'qué decidimos sobre pricing en Q2', 'tests de aislamiento de audit log cross-tenant', 'cadencia y scope del consolidation daemon', y así) corrieron 5 repeticiones cada una después de un solo pase de calentamiento por query. 32 de 32 tests de retrieval pasaron localmente; la suite completa no-retrieval estuvo 434/434 en verde. Reportes escritos a memory-runtime-pro/benchmarks/bucket-2/report-hash-5000n-*.md para que cualquier reviewer pueda ver la distribución completa por query, no solo los números titulares.

Artefactos de caso de estudio

El chart pre/post es el artefacto de la conversación de renovación. Compara el mes 1 contra el mes 6 en tres filas que el CFO del comprador reconocerá: decisiones re-litigadas, horas por semana respondiendo preguntas, y pegas manuales de contexto. El mismo generador que produjo la muestra del digest produjo estos. Re-correr scripts/generate-sample-artifacts.py contra el tenant sintético público los reproduce byte-por-byte (módulo el footer 'generated-at' del SVG).

• Chart pre/post de muestra (SVG) — 21 a 15 decisiones re-litigadas (29% drop), 1.23 a 0.88 horas/semana respondiendo (28% drop), 18 a 4 pegas manuales (78% drop).
• Chart pre/post de muestra (CSV) — Números subyacentes que un CFO re-exportaría a una hoja de cálculo.
• Chart pre/post de muestra (JSON) — Snapshot machine-readable para pipelines downstream.

Los detalles de metodología para las tres filas del chart viven en /es/digest-methodology, junto con los tres números + el momento earned-its-keep del digest semanal.

Lo que no haremos

Mycelium no publicará números de latencia desde un harness interno privado contra fixtures privados. Los números sin un harness público y un corpus público son reclamos no verificables, y el lector de Compras tiene razón al ignorarlos. La metodología aterriza primero; los números siguen cuando tanto el harness como el corpus son públicos.