Memoria local en SQLite para CLIs de IA: cuándo sustituye a los almacenes vectoriales

Tu CLI de codificación con IA puede mantener la memoria del proyecto en un archivo SQLite local. En un sistema de trading algorítmico de 50.000 líneas, una evaluación de 105 sesiones afirmó que 186 pruebas unitarias pasaron sin regresiones. La memoria permanece en la máquina y bajo el control del operador.

El archivo puede sustituir a un almacén vectorial a medida cuando el trabajo se mantiene dentro de un solo repositorio y la recuperación puede apoyarse en búsqueda de texto completo, embeddings locales estáticos o ambos. Engrim es una capa de memoria SQLite de alcance de proyecto, almacenada localmente, para agentes de línea de comandos con IA. Engrim nombra a Google Antigravity, Claude Code, Cursor, Windsurf y Codex como entornos compatibles. Engram es un ejecutable en Go que almacena datos en SQLite con búsqueda de texto completo FTS5 y expone interfaces CLI, HTTP, MCP y TUI. Lista a Claude Code, OpenCode, Gemini CLI, Codex, VS Code Copilot, Antigravity, Cursor y Windsurf como agentes compatibles.

Las bases de datos vectoriales en la nube añaden una ruta de red y un lugar donde el contexto del proyecto puede filtrarse. Un archivo local es más fácil de inspeccionar, respaldar y eliminar. Engrim almacena su base de datos en ~/.engrim/memory.db y no utiliza telemetría, sincronización en la nube ni rastreo. Engram trata la base de datos SQLite local como el almacén autoritativo, con las capacidades en la nube como replicación opcional o acceso compartido.

El archivo local es el producto

El trabajo del operador no es ajustar un índice alojado. Es elegir un archivo, un esquema y una ruta de recuperación que el agente pueda invocar sin salir de la máquina. Almacena el contexto que un ingeniero nuevo pediría: decisiones de arquitectura, alternativas descartadas, peculiaridades del entorno, comandos de prueba y modos de fallo conocidos. No almacenes cada línea de código. La base de código ya está disponible.

Mantén el esquema aburrido. Una pequeña tabla de notas, marcas de tiempo y etiquetas es más fácil de depurar que un grafo complejo. Si el agente no puede explicar por qué se recuperó una nota, la ruta de recuperación es demasiado opaca. La memoria local debe ser inspeccionable con herramientas ordinarias.

La recuperación determina si el archivo es útil

La búsqueda de texto completo maneja bien las coincidencias exactas: nombres de archivo, nombres de función, cadenas de error, claves de configuración y decisiones citadas. La búsqueda de texto completo FTS5 le da a la base de datos local un motor léxico sin mover datos a otro sistema.

Los embeddings locales estáticos añaden una segunda ruta. La capa de embeddings de Engrim utiliza embeddings locales estáticos de model2vec, carga en unos 30 ms y puede funcionar en modo puramente léxico con ENGRIM_EMBED=off. Eso es suficiente para muchas memorias de proyecto. El agente puede pedir significado cercano mientras permanece offline.

La evaluación es una señal, no una prueba. Muestra que un archivo local puede soportar una carga de trabajo de codificación larga y acotada. No demuestra que la memoria léxica supere a todos los almacenes vectoriales.

La recuperación semántica es la objeción

La búsqueda léxica puede perderse en la paráfrasis. Si el agente guardó «usa la cola de reintentos» y luego pregunta por «cómo manejar trabajos fallidos», un índice de palabras clave puede perder el vínculo. Un almacén vectorial diseñado para corpus grandes y entre proyectos puede ser mejor en ese tipo de recuperación.

Para un solo proyecto, la tasa de fallos suele ser aceptable. La memoria es más pequeña, el vocabulario más estrecho y el agente ya ve la base de código. Los identificadores exactos y las notas recientes tienen peso. Los embeddings estáticos reducen la brecha sin añadir un servicio alojado.

Cuando la memoria crece más allá de un repositorio, la regla se invierte. Si el agente debe recuperar información entre muchas bases de código, muchos equipos o un gran corpus histórico, usa un almacén vectorial de propósito específico. La memoria local basada en archivos sirve para la memoria de proyecto. No sustituye la búsqueda semántica universal.

Los proyectos acotados mantienen la memoria local

Usa memoria SQLite local cuando la memoria está ligada a un solo proyecto, el operador quiere almacenamiento offline y la recuperación puede apoyarse en búsqueda de texto completo, embeddings locales estáticos o ambos. Usa un almacén vectorial cuando la recuperación semántica entre corpus grandes y entre proyectos es crítica.

Antes de cambiar, ejecuta un análisis breve de tu propia carga de trabajo y anota lo que el agente devuelve.

• Pide al agente que recupere una decisión de una sesión anterior.
• Pídele que recupere una convención de un archivo anterior.
• Pídele que recupere un modo de fallo de una ejecución previa.

Si el archivo local devuelve las notas correctas, mantenlo local. Si devuelve coincidencias débiles, añade un almacén vectorial donde la brecha de recuperación realmente perjudica.