Site Logo
Published on

Acervo en pausa — cuando la idea es buena pero la implementación no alcanza

Authors
This post is also available in English →

Este post me costó escribirlo. Después de cinco versiones, benchmarks, un fine-tune propio y meses de trabajo, decidí pausar Acervo.

No porque la idea esté mal. Sigo convencido de que comprimir conocimiento en un grafo y activar solo lo relevante por cercanía semántica es un camino correcto — los números de v0.5 (21x de eficiencia vs un agente con tools) lo respaldan. El problema es otro: la forma en la que lo intenté implementar no es lo suficientemente buena.

El problema real: conversaciones dinámicas

Los benchmarks de v0.5 contaban una historia parcial. Sobre proyectos indexados, con preguntas más o menos previsibles, el pipeline funcionaba bien. Pero cuando lo usaba en charlas reales — de esas que saltan de tema, vuelven atrás, corrigen algo dicho tres turnos antes, mezclan dos proyectos en la misma frase — Acervo empezaba a perder datos de contexto de forma consistente.

Y tiene sentido si mirás cómo está construido. El pipeline S1→S2→S3 depende de que cada turno se pueda descomponer limpiamente: extraer entidades, activar nodos por BFS, ensamblar contexto. Cuando la conversación es dinámica, esa descomposición se rompe en varios frentes:

  • S1 extrae por turno, sin memoria del flujo. Si un dato importante se construye a lo largo de tres mensajes ("el proyecto ese...", "sí, el de las tareas", "usa Postgres ahora"), ningún turno individual contiene la información completa, y el grafo termina con fragmentos o directamente sin el dato.
  • El BFS necesita un seed correcto. En charla dinámica, el topic del turno actual muchas veces no matchea ningún label del grafo — referencias implícitas, pronombres, sobreentendidos. Sin seed, no hay activación, y el LLM responde sin contexto.
  • Las correcciones acumulan en vez de reemplazar. Ya lo había documentado en v0.5: "cambié de SQLite a PostgreSQL" agrega PostgreSQL pero no quita SQLite. En una conversación larga y viva, el grafo se llena de estados contradictorios.

Cada uno de estos por separado tiene parches. Pero la suma me hizo ver que el problema no es de parches: es estructural. Estoy intentando reconstruir en cada turno, desde afuera del modelo, un estado conversacional que el modelo ya maneja internamente mucho mejor que yo.

La solución que no sé hacer (todavía)

La dirección que creo correcta es dejar de pelear contra el contexto desde afuera y trabajar más cerca del modelo: mejorar o directamente hacer otro estilo de KV-cache. En vez de re-inyectar texto comprimido en cada turno y rezar que el extractor no pierda nada, mantener y manipular el estado de atención del modelo de forma más inteligente — comprimirlo, podarlo, reutilizarlo entre turnos sin perder lo que importa.

Hay investigación activa en esa línea y los resultados son prometedores. Pero seamos honestos: implementar algo así en serio no es escribir otro pipeline de Python sobre una API. Es meterse en las tripas de la inferencia — atención, memoria, cuantización, todo el stack que hasta ahora usé como caja negra.

Y ahí está el punto: no lo sé hacer aún. Puedo seguir iterando fine-tunes del extractor y ganando puntos porcentuales en benchmarks, pero sería optimizar la implementación equivocada. Prefiero frenar, ponerme a estudiar ingeniería de machine learning en serio, y volver a Acervo cuando tenga las herramientas para atacar el problema de verdad, no sus síntomas.

Así que Acervo queda pausado. No muerto — pausado. El código, el modelo y el training data siguen públicos y open source.

Mientras tanto: Graphify

Lo bueno es que no hace falta esperarme. Existe un proyecto con ideas muy similares a las de Acervo, que ya está maduro y se puede usar hoy: Graphify.

La premisa les va a sonar familiar si vinieron siguiendo esta serie: convertir una codebase — con sus docs, schemas SQL, configs y PDFs — en un knowledge graph consultable. Un grafo real que se traversa, no embeddings con retrieval probabilístico. Las mismas apuestas conceptuales que venía haciendo con Acervo, mejor ejecutadas:

  • Parsing local y determinístico con tree-sitter para ~40 lenguajes. Cero llamadas a LLM para extraer código: nada sale de tu máquina. Donde yo dependía de un fine-tune que extraía "casi siempre" bien, ellos usan el AST directamente.
  • Relaciones con procedencia. Cada edge está taggeado como EXTRACTED (explícito en el código) o INFERRED (resuelto por la herramienta). Es la respuesta elegante al problema de las entidades fantasma que yo atacaba con specs de calidad en YAML.
  • Detección de comunidades con clustering de Leiden para identificar subsistemas, y "god nodes" para encontrar los conceptos más conectados.
  • Query en lenguaje natural (graphify query), trazado de conexiones entre dos entidades (graphify path), y funciona como skill para Claude Code, Cursor, Codex y compañía, con soporte MCP para acceso persistente al grafo.
  • Open source, dual-licensed Apache 2.0 / MIT.

Si algo de la serie de Acervo les hizo ruido en el buen sentido — la idea de que el contexto de un proyecto vive mejor en un grafo que en un vector store — pruébenlo. Es la versión de esa idea que ya funciona.

Lo que me llevo

Cinco versiones de Acervo me enseñaron más que cualquier curso: qué es un pipeline de extracción, cómo se hace un fine-tune con LoRA, cómo se diseñan benchmarks que no se mientan a sí mismos, y — la lección más cara — cómo reconocer cuándo el problema que tenés adelante es más profundo que las herramientas que manejás.

Nos vemos del otro lado del machine learning engineering.