b9adb186d1
Skill: NONE | Type: troubleshooting Summary: EPISODIO 2 — MNEMO_PRE_DIGEST: Dos recomendaciones nuevas, ambas **gateadas** (n
2.9 KiB
| episode_id | puente_flat | session_code | acto_dialogico | actor_flujo | criticidad_aegis | skill_dominante | fase_proyecto | tipo_semantico | summary_one_line | source_type | trust_boundary | created_at | relectura_tagged | forgejo_commit_sha |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0f619cd3-3150-4ad6-a4ee-a57b746c2def | EXPLORA_dos-recomendaciones-nuevas-ambas-gateada_S20260719.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260719.ORACULO_RETRIEVAL_X09 | informar | multi_actor | low | NONE | operations | troubleshooting | EPISODIO 2 — MNEMO_PRE_DIGEST: Dos recomendaciones nuevas, ambas **gateadas** (no se ejecut | claude_code | internal | 2026-07-19T19:24:46.072612+00:00 | false | pending |
Los otros 4 documentos eran panoramas del campo. El de Grok es distinto: un plano de construcción — código listo para un sistema de memoria bi-temporal en Neo4j+FAISS que detecta contradicciones ("vivía en Madrid → ahora en Londres") e invalida el hecho viejo sin borrarlo. Al verlo, sospeché que su sintaxis estrella ("in-index filtering" de Neo4j 2026 con la cláusula SEARCH) era inventada — igual que la bibliografía fabricada del doc "hola plex". Fui a la documentación oficial de Neo4j y me equivoqué: es real y actual. El filtrado dentro del índice vectorial existe desde Neo4j 2026.02, la cláusula SEARCH es la forma preferida desde 2026.01, y la cuantización escalar está documentada. Grok escribió un blueprint técnicamente correcto (único detalle: usa un flag deprecado en 2026.06). En sencillo: Grok no alucinó — y decírtelo cuando mi sospecha falla vale tanto como cuando acierta.
Segundo, el juicio de fondo: buena pieza, escalón equivocado
El sistema de Grok resuelve contradicción temporal (qué hecho sigue vigente). Nuestro cuello medido es otro: densidad de distractores — 828 turnos ceremoniales casi idénticos con resumen vacío entierran al correcto (0.06 de acierto). Son problemas ortogonales: puedes tener la bi-temporalidad perfecta y seguir sin encontrar el turno correcto entre 828 gemelos. Peor aún: el sistema de Grok trabaja sobre hechos ya extraídos (sujeto-predicado-objeto) — presupone justo la capa de extracción que nosotros no tenemos todavía (nuestro summary está vacío en 826/828). Es un escalón 3-4 de la escalera; nosotros estamos construyendo el 1.
Qué aprovechamos entonces
- Para F4 (futuro): su blueprint de supersession bi-temporal es la implementación de referencia de mi recomendación R3 — cuando lleguemos ahí, no diseñamos de cero.
- Ya, gratis: su patrón "cheap-then-escalate" (probar lo barato antes de llamar al LLM caro) confirma la escalada que ya usamos en el governor.
- Experimento barato a la PILA: el concepto de filtered-search dentro del índice es adoptable en Qdrant (ya lo soporta nativo) sin migrar nada a Neo4j — candidato gateado por held-out.
- No cambia el orden: PRE-F2-ORACULO sigue siendo el primer paso.