BENCHMARKS
Rendimiento medido, método publicado.
Dos experimentos reales: el benchmark público MEME sobre memoria que cambia (100 casos, 694 preguntas), y el mismo modelo de IA respondiendo preguntas de la empresa con y sin LAN Brain (20 preguntas con respuesta verificable). Todo reproducible, limitaciones declaradas, cero números inventados.
Corridos el 2026-08-23 · dataset HF meme-benchmark/MEME · harness público SeokwonJung-Jay/MEME-public
100%
Hechos encadenados correctos (Cascade), donde la memoria cruda saca 1%
92%
Global en MEME sobre las 694 preguntas, donde la memoria cruda saca 35%
7x
Más respuestas correctas sobre datos de la empresa con LAN Brain (70% vs 10%)
80%
De respuestas con cita verificable a la página fuente (sin brain: 0%)
EXPERIMENTO 1 · MEME
Memoria que cambia: buscar contra descender.
MEME mide lo que casi ninguna memoria de IA resuelve: hechos que se actualizan, se encadenan y se borran. Corrimos las 694 preguntas de los 100 casos con el mismo buscador para los dos brazos, así que lo único que cambia es cómo se guarda y cómo se lee. Las páginas de LAN Brain las construyó un simulador de ingesta que detectó los cambios solo, sin ver nunca las respuestas, y se leen como las lee el producto: bajando desde el índice que lista las entidades del área con su valor vigente hasta la página de cada una.
Memoria cruda (BM25 sobre las sesiones)LAN Brain: descenso con índice (como opera el producto)
- Cascadehechos que dependen de otro que cambió
- Absencesaber decir “incierto” cuando algo venció
- Trackingla historia de un dato, en orden
- Deletionque lo borrado deje de aparecer
- Aggregationjuntar varios datos a la vez
- Exact Recallhechos estáticos · empate
Sin el índice, las mismas páginas rinden menos: Cascade 85% · Absence 68% · Tracking 77% · Deletion 91% · Aggregation 1% · Exact Recall 100%. Eso es 72% global contra 92% con el descenso, sobre las 694 preguntas, donde la memoria cruda saca 35%. El índice no es un detalle de implementación: es lo que lleva Aggregation de 1% a 100%, porque el hub ya lista las tres entidades de la pregunta con su valor vigente y se contestan en una sola lectura.
El techo de Absence es una ambigüedad del propio benchmark: redacta esos casos igual que los de Cascade y ningún sistema puede distinguirlos leyendo solo la conversación. Cascade y Deletion, en cambio, quedan exactamente en su techo de detección: con el descenso, elegir mal la página deja de costar respuestas y pasa a costar solo tokens, porque el índice ya afirma el estado de cada entidad.
Los dos límites que quedan, dichos: Tracking se queda en 77% por un detalle léxico y no por la representación: la pregunta usa el plural y la entidad está en singular, así que el buscador puntúa cero y la página nunca se abre. Con normalización de plurales sube a 98% y el total llega a 95%, el techo exacto de detección. El segundo límite es de escala: en un brain grande el descenso tiene que poder abrir más de un hub. Con la partición más pesimista y un solo hub, Aggregation vuelve a 0%; abriendo 3 hubs, el total queda en 89%.
COMPARACIÓN
Contra lo que el mercado publica.
Las mismas categorías, al lado de los únicos otros números que existen en público. Leé la columna de condición antes de leer las cifras.
| Sistema | Cascade | Absence | Deletion | Condición |
|---|---|---|---|---|
| LAN Brain (medido por nosotros) | 100% | 74% | 99% | 100 casos, nofiller, descenso con índice, lector determinista, harness público |
| Sentra (autoreportado) | 40% | 43% | 50% | sin metodología, harness ni config divulgados · sentra.app, consultada el 2026-08-23 |
| Promedio del campo (paper MEME) | 3% | 1% | n/p | config default del paper (con ruido filler, juez LLM) |
Leé esta tabla con cuidado, a propósito. Las filas NO son directamente comparables entre sí: cada una corrió en condiciones distintas, y las de Sentra no tienen metodología publicada (sus números salen de su propio sitio, sección benchmarks, consultada el 2026-08-23). La nuestra es la única fila con harness reproducible y config declarada. El paper oficial de MEME está en revisión y no publicó su tabla por sistema; cuando lo haga, o corriendo su harness oficial con API keys, sale el head to head limpio. Mientras tanto preferimos esta honestidad a un gráfico tramposo.
EXPERIMENTO 2 · DATOS DE LA EMPRESA
El mismo modelo, con y sin LAN Brain.
20 preguntas reales sobre LAN (decisiones, fechas, hechos técnicos, y hechos que cambiaron en el tiempo), cada una con respuesta verificable en el brain. El mismo modelo respondió dos veces: solo con su conocimiento general, y conectado al brain de la empresa por MCP. La única variable es el acceso al contexto.
Modelo soloModelo + LAN Brain
- Accuracyrespuestas correctas
- Con cita verificablepath de la página que respalda la respuesta
- “No sé”abstención: sin brain, el modelo no miente, se calla
Corrida interna · N=20 · un solo modelo · rúbrica aplicada por el mismo sistema con criterios mecánicos, no un juez independiente · tokens estimados por caracteres
| Métrica | Modelo solo | Modelo + LAN Brain | Lectura honesta |
|---|---|---|---|
| Accuracy | 10% | 70% | 7x más respuestas correctas |
| Alucinación | 0% | 5% | 1 caso en 20, causado por una página desactualizada del brain, ya corregida |
| Calidad de output (0-3) | 1.10 | 2.25 | correcta, específica y citada contra “no tengo esa información” |
| Velocidad (mediana) | 3.5 s | 7.5 s | con brain es 2x más lento, pero solo 1.2 s de esos 7.5 s son servidor nuestro: el resto lo pone el proveedor de IA al leer las fuentes |
| Tokens totales | 1.5k | 17k | 11x más consumo bruto |
| Tokens por respuesta correcta | 762 | 1,213 | 1.6x el costo por respuesta útil, con 7x más respuestas útiles |
- 1.2 sservidor LAN, medido en producción
- 6.3 sinferencia del modelo del proveedor más red, fuera de nuestro control
La parte nuestra del tiempo extra es 1.2 s: los otros 6.3 s los pone el proveedor de IA al leer las fuentes. El tiempo de servidor está medido en producción, llamada por llamada; el resto sale por resta y es una descomposición, no una medición, porque la inferencia del proveedor y la red del cliente nunca llegan a nuestros logs.
La eficiencia se mide por respuesta útil, no por consumo bruto: el modelo solo “gasta poco” porque casi no responde (90% de abstención). Y el único invento del brazo con brain no lo inventó el modelo: citó una página del brain que había quedado vieja. Ese es exactamente el problema que la detección de cambios y la re-verificación de datos volátiles atacan, y la página se corrigió el mismo día.
El claim honesto: con LAN Brain el mismo modelo pasa de un asistente que se calla (90% “no sé”) a uno que responde bien y muestra de dónde lo sacó (70% correcto, 80% citado), a 1.6x el costo por respuesta útil y el doble de latencia, de la que 1.2 s son servidor nuestro. Ese es el trade y lo mostramos entero.
MÉTODO Y LIMITACIONES
Lo que hay detrás de cada número.
MEME.
Dataset real (HuggingFace meme-benchmark/MEME, config nofiller), 100 episodes, 694 preguntas. Un solo retriever BM25 para los dos brazos, scoring determinista sin juez LLM, resultado idéntico bajo cualquier seed. Las páginas de LAN Brain las construye un simulador de ingesta que lee las sesiones en orden cronológico y detecta supersede, borrado y dependencias solo; nunca ve etiquetas ni respuestas gold. Y se leen con descenso, como lee el producto: índice o hub del área que lista las entidades con su valor vigente, y de ahí a la página. Los valores largos del hub se truncan a 120 caracteres, como haría un índice real, así que Exact Recall obliga a bajar a la página y el hub no puede volverse un volcado del estado entero. Detección medida: Cascade 100%, borrados 100% recall y precision, condicionales 100% precision, Absence 74% (el resto es ambigüedad de diseño del benchmark, documentada con un caso probadamente indecidible).
Empresa (20 preguntas).
Ground truth extraído del wiki interno. El brazo sin brain se respondió a ciegas de las respuestas: las preguntas las armó un proceso separado y el que respondía solo vio el enunciado. Brazo con brain: una sesión MCP real de solo lectura, 33 llamadas. La atribución de latencia sale de los percentiles de producción del servidor (1.65 llamadas por respuesta, p50 de 1.065 ms en búsqueda y 202 ms en lectura de página); lo que no es servidor no lo medimos y lo declaramos como resta.
Limitaciones, sin vueltas.
Un solo modelo; N=20, así que 10% contra 70% es robusto pero los decimales no; la rúbrica de calidad la aplicó el mismo sistema con criterios mecánicos, no un juez independiente; los tokens son estimación por caracteres; el brazo “modelo solo” es una simulación de ceguera controlada, no una API con contexto vacío, y esa versión es el siguiente paso si esto se publica.
Terceros.
Ningún número de otra plataforma se presenta como verificado. Sentra publica los suyos sin metodología, y el paper MEME no liberó su tabla por sistema. Las cifras que solo existen como la cita de un proveedor sobre otro sistema no se publican acá.
QUÉ SIGNIFICA PARA VOS
La misma medición, sobre tus propios datos.
Estas corridas usaron el brain de LAN y un benchmark público. La versión interesante es la que corre sobre tu contexto, con tus preguntas y tu ground truth. Eso es parte del relevamiento.
LAN Brain · benchmarks internos corridos el 2026-08-23 · MEME: dataset HF meme-benchmark/MEME (CC-BY-4.0), harness SeokwonJung-Jay/MEME-public. El paper está en revisión y es anónimo: no hay preprint que citar. Harness y scripts reproducibles disponibles a pedido. Sentra: cifras autoreportadas en sentra.app, sección benchmarks, consultada el 2026-08-23. n/p = no publicado.