Soporte para búsqueda semántica

[rey9606]

Bro, ¿y si en vez de usar el motor FTS5 usas búsqueda semántica con algún embedding pequeño (o le das opción al usuario para que elija)? Las búsquedas serían un poquito más lentas, pero serían mucho más precisas. Recientemente hice algo similar para buscar issues en GitHub Project, también en un sistema de FAQs , y los resultados fueron espectaculares. O sea a partir de un nuevo issue que trajera los 5 mas semanticamente similares a este para prevenir duplicados y mejorar el contexto.También esto ayuda a clasificar mejor el issue y, si es en equipos grandes, hasta sabes a quién asignárselo, ya que, por ejemplo, si ves que la mayoría los hizo cierto desarrollador.

En mi caso lo hice en Postgres usando PGVector, pero acabo de investigar y al parecer SQLite también tiene algo similar. En mi caso utilicé modelos pequeños (y que soportaran español jeje), por ejemplo Xenova/all-MiniLM-L6-v2, aunque Google tiene uno bastante bueno y también pequeñito. Al final, eso ya es preferencia del usuario; yo siempre busco la mejor relación entre tamaño y calidad porque en Cuba la velocidad de internet es de menos de 1 MB/s jeje.

[josecanciani]

To avoid changing too much: libSql (Turso) has a native Vector datatype, and is a drop-in replacement for SQLite3 (also open source).

I'm doing some projects with it, works fine, although I still have to test how it scales with a lot of rows.

[Alan-TheGentleman]

Buena idea! FTS5 funciona muy bien para el caso actual porque los agentes guardan resúmenes estructurados con keywords explícitas — pero semántica mejoraría el recall para búsquedas más ambiguas.

El desafío principal es mantener la filosofía de engram: zero dependencies, single binary, sin APIs externas.

Turso/libSQL: descartado

@josecanciani sugirió libSQL, pero después de investigar no es viable:

• Requiere CGO — engram usa modernc.org/sqlite (pure Go, zero CGO), que es lo que nos permite compilar un solo binario estático que funciona en todos lados
• Sin soporte Windows — go-libsql solo tiene libs para linux/darwin. Justo acabamos de agregar soporte Windows
• Riesgo de formato — las columnas vector de libSQL pueden no ser legibles por herramientas SQLite estándar

sqlite-vec es más viable

sqlite-vec es una extensión SQLite en C puro — chica, sin dependencias. Pero el problema es: ¿de dónde salen los embeddings?

Approach	Pro	Contra
API externa (OpenAI, Ollama)	Embeddings de alta calidad	Agrega config, dependencia de red, costos — rompe "zero dependencies"
Modelo embebido (GGUF via sqlite-lembed)	Sin dependencia externa	El binario pasa de ~15MB a 100MB+
El agente genera el embedding al guardar	Zero dependencias nuevas — el LLM ya procesa el texto	Agrega un param nuevo al MCP tool, calidad varía según modelo

Realidad actual

Los agentes no buscan como humanos. Guardan contenido estructurado con keywords explícitas (**What**: Fixed N+1 query, **Where**: src/store/store.go) y buscan con términos específicos. FTS5 funciona muy bien para esto.

La búsqueda semántica ayudaría con queries ambiguos tipo "eso que hicimos con la base de datos", pero en la práctica los agentes son buscadores precisos.

Camino a seguir

1. FTS5 queda como default — sin cambios para usuarios existentes
2. sqlite-vec como opt-in — flag --experimental-vector o config
3. Embeddings del lado del agente — agregar un param opcional embedding a mem_save. El LLM genera el vector. Sin modelo bundleado, sin API externa
4. Búsqueda híbrida — FTS5 para keywords + vector para semántica, merge de resultados

Dejé un análisis más detallado en #24. Gracias por la propuesta!

[Alan-TheGentleman]

Already discussed — FTS5 handles the current workflow well. Semantic search is a long-term consideration. Related to #24. Thanks!