El problema: RAG que no podia seguir el ritmo
Las bases de conocimiento solo son utiles si la recuperacion es rapida. Cuando lanzamos el soporte RAG en JieGou, el pipeline funcionaba: los documentos se fragmentaban, se generaban embeddings y se inyectaban en los prompts. Pero el rendimiento contaba una historia diferente.
Una base de conocimiento con 705 documentos tardaba ~160 segundos en recuperar el contexto relevante. Eso significaba que cada ejecucion de recipe, cada paso de workflow y cada conversacion de agent que accedia a una base de conocimiento pagaba un impuesto de varios minutos antes de que el LLM comenzara a generar.
Para casos de uso interactivos — un agente de soporte buscando una politica, un representante de ventas consultando especificaciones de producto durante una conversacion — 160 segundos es inaceptable.
Necesitabamos reducir la recuperacion a menos de un segundo sin anadir complejidad de infraestructura.
Fase 1: Busqueda vectorial nativa de Firestore
El enfoque de recuperacion original cargaba todos los embeddings desde Firestore, calculaba la similitud del coseno en el codigo de la aplicacion y devolvia los top-k resultados. Era simple y correcto, pero escalaba linealmente con la cantidad de documentos.
La primera optimizacion fue mover la busqueda de similitud al propio Firestore usando Firestore Vector Search (basado en indexacion ScaNN). En lugar de cargar los 705 embeddings en memoria y calcular distancias, dejamos que Firestore manejara la busqueda de vecinos mas cercanos de forma nativa.
Lo que cambio
- Antes: Obtener todos los embeddings → calcular similitud del coseno en Node.js → ordenar → tomar top-k
- Despues: Una sola consulta a Firestore con
findNearest()→ devuelve top-k directamente
Esto elimino la transferencia de datos y computacion O(n). El indice vectorial de Firestore utiliza vecinos mas cercanos aproximados, lo que intercambia una cantidad insignificante de recall por ganancias masivas de velocidad en colecciones grandes.
Resultados
La consulta en frio sobre 705 documentos bajo de ~160s a ~10s. Una mejora de 16x — pero aun demasiado lenta para workflows interactivos.
Fase 2: Recuperacion hibrida con fallback
No todas las consultas se benefician de la busqueda vectorial por igual. Algunas bases de conocimiento son lo suficientemente pequenas como para que la fuerza bruta sea mas rapida que la sobrecarga de una consulta al indice vectorial. Otros documentos no generan buenos embeddings (tablas, fragmentos de codigo, datos estructurados).
Implementamos una estrategia de recuperacion hibrida:
- Intentar busqueda vectorial primero — Si existe un indice vectorial de Firestore y la base de conocimiento tiene embeddings, usar
findNearest() - Recurrir a fuerza bruta — Si la busqueda vectorial falla, no esta disponible o devuelve muy pocos resultados, cargar embeddings y calcular similitud en el codigo de la aplicacion
- Combinar y deduplicar — Unir resultados de ambas rutas, deduplicar por ID de documento, reordenar por puntuacion de similitud
El enfoque hibrido significa que la recuperacion nunca falla. Si los indices vectoriales de Firestore aun no se han creado (por ejemplo, en un entorno recien provisionado), el sistema degrada elegantemente a la ruta original de fuerza bruta.
La flag usedVectorSearch
Cada operacion de recuperacion ahora incluye un booleano usedVectorSearch en su span de traza. Esto nos permite monitorear que consultas estan usando la ruta rapida y cuales recurren al fallback, e identificar bases de conocimiento que necesitan creacion de indices o re-embedding.
Fase 3: Cache Redis para consultas frecuentes
La optimizacion final apunta a consultas repetidas — la misma pregunta hecha contra la misma base de conocimiento en una ventana corta de tiempo. Esto ocurre constantemente en produccion:
- Multiples pasos de workflow consultando la misma base de conocimiento de FAQ
- Conversaciones de agent que recuperan contexto en cada turno
- Ejecuciones batch donde 50 elementos consultan documentos de referencia identicos
Anadimos un cache Redis por documento con un TTL de 10 minutos:
- Antes de ejecutar la busqueda de similitud, verificar en Redis si hay resultados cacheados con la clave
(knowledgeBaseId, queryEmbeddingHash) - Si hay cache hit, devolver inmediatamente — sin consulta a Firestore en absoluto
- Si hay cache miss, ejecutar el pipeline de recuperacion hibrida y cachear los resultados
Resultados
| Escenario | Antes | Despues |
|---|---|---|
| Consulta en frio, 705 docs | ~160s | ~10s |
| Consulta frecuente (Redis hit) | ~160s | <1s |
| KB pequena (<50 docs) | ~5s | ~2s |
| Batch de 50 elementos, misma KB | ~8,000s total | ~10s + 49x <1s |
El escenario batch es donde el cache ofrece la mayor ganancia. El primer elemento paga el costo de consulta en frio; los 49 restantes aciertan en Redis y retornan en milisegundos.
Arquitectura: cero dependencias externas
Una restriccion de diseno clave fue sin infraestructura adicional. Muchas plataformas RAG requieren aprovisionar y gestionar una base de datos vectorial dedicada — Pinecone, Weaviate, Qdrant, Milvus. Cada una agrega:
- Otro servicio para desplegar y monitorear
- Otro conjunto de credenciales para gestionar
- Otra dimension de facturacion de proveedor
- Otro punto de fallo en tu pipeline
El enfoque de JieGou usa solo la infraestructura que ya tienes:
| Componente | Proposito | Ya existe? |
|---|---|---|
| Firestore | Indice vectorial + almacenamiento de documentos | ✅ Tu base de datos principal |
| Redis | Cache de resultados de consulta | ✅ Usado para rate limiting y sesiones |
| Codigo de aplicacion | Fallback de fuerza bruta | ✅ Se ejecuta en tus pods existentes |
Sin Pinecone. Sin Weaviate. Sin nueva infraestructura que aprovisionar, asegurar o pagar.
Lo que esto significa para tus workflows
Ejecucion de recipes mas rapida
Cada recipe que usa una base de conocimiento ahora recupera contexto en menos de un segundo para consultas frecuentes. El spinner de “pensando…” antes de la generacion desaparecio para casos de uso repetidos.
Procesamiento batch practico
Las ejecuciones batch que procesan cientos de elementos contra la misma base de conocimiento ahora son viables. El primer elemento calienta el cache; el resto pasa volando.
Conversaciones de agent que se sienten instantaneas
Los agents conversacionales re-consultan las bases de conocimiento en cada turno. Con el cache Redis, los turnos 2 a N recuperan contexto en milisegundos en lugar de re-ejecutar la busqueda de similitud.
Recuperacion observable
La flag de traza usedVectorSearch significa que puedes ver exactamente que ruta de recuperacion se uso en cada ejecucion. Si una base de conocimiento esta recurriendo consistentemente a fuerza bruta, sabes que necesita atencion.
Pruebalo hoy
Si ya estas usando las bases de conocimiento de JieGou, estas optimizaciones estan activas — no se requieren cambios de configuracion. Tus bases de conocimiento existentes se benefician automaticamente de la busqueda vectorial de Firestore y el cache Redis.
Si aun no has configurado una base de conocimiento:
- Ve a Knowledge Bases en la consola de JieGou
- Sube documentos o importa desde una URL
- Adjunta la base de conocimiento a cualquier recipe o workflow
- Observa como la recuperacion ocurre en menos de un segundo
La combinacion de busqueda vectorial nativa de Firestore, recuperacion hibrida y cache Redis significa que tus automatizaciones de AI obtienen contexto especifico de tu empresa sin el impuesto de latencia — y sin gestionar una sola pieza adicional de infraestructura.