Análisis del sistema actual
El capítulo de Punto de Partida ya describió el prototipo Python + FAISS desarrollado durante las prácticas. No hace falta repetir aquí su arquitectura interna, pero sí conviene detenerse un momento en por qué, mirado desde la óptica de un módulo industrial integrado, el prototipo no podía evolucionar en línea recta hacia la solución que este capítulo propone.
Lo que el prototipo demostraba — y lo que no
El prototipo dejó claro tres cosas que en su momento no eran obvias: que la búsqueda por similitud vectorial responde con la latencia que un agente RAG necesita, que un LLM moderno puede generar SQL razonable a partir de contexto recuperado por similitud, y que la búsqueda semántica funciona razonablemente bien sobre recursos industriales incluso cuando se mezclan idiomas. Eran resultados suficientes para justificar seguir invirtiendo en el enfoque.
Lo que no dejó claro fue cómo encajar esa pieza en el día a día de DWall. El sistema vivía al margen del backend: un proceso Python con sus ficheros .index, sus JSON de metadatos y sus regeneraciones manuales cuando alguien se acordaba. Mientras el inventario era pequeño y el equipo de pruebas era una persona, la cosa funcionaba. Pero la pregunta natural de un cliente — "si añado una variable nueva un martes a las cinco, ¿cuándo aparece en la búsqueda?" — no tenía una respuesta defendible.
El cambio de premisa
La diferencia entre aquel prototipo y el módulo que se construye en este capítulo no es de implementación, es de premisa. El prototipo asumía que la base de conocimiento del agente se podía gestionar al margen del sistema: los embeddings eran un artefacto generado fuera, alimentado por scripts y consultado por un servicio externo. Para que esto sirviera en producción había que invertir esa relación: los embeddings tenían que ser un recurso más de DWall — generados, mantenidos y consultados por el propio backend, sometidos a las mismas reglas de consistencia, eventos y transacciones que cualquier otra entidad del sistema.
Visto así, las decisiones que llenan el resto del capítulo — pgvector en lugar de una base vectorial dedicada, eventos de dominio en lugar de jobs batch, una tabla de embeddings por tipo de recurso — no son optimizaciones del prototipo. Son consecuencias de haber decidido que la base de conocimiento del agente es ciudadana de primera clase de DWall, no una capa externa que la alimenta desde fuera.
Lo que se conserva
No todo se descarta. La elección de Gemini como modelo de embeddings se mantiene; el criterio sobre qué textos alimentan al modelo — descripción del recurso más sus campos técnicos relevantes — se mantiene y se formaliza; y la métrica de similitud y el índice HNSW son técnicas estándar que el prototipo ya usaba, simplemente en otra implementación. Lo que cambia es dónde vive todo eso, quién lo dispara y a qué reglas obedece. Eso es lo que el siguiente subcapítulo empieza a aterrizar.