← Volver al blog
Arquitectura

El motor interno: de la pregunta a la respuesta grounded

8 min de lectura · Arquitectura

El motor de Lumentia no es "LLM + buscador". Es un pipeline de varias etapas, cada una con una responsabilidad concreta, de modo que el modelo de lenguaje solo ve evidencia ya filtrada y verificada. Aquí va el recorrido completo.

IntenciónGemini Híbridadense+sparse GrafoNeo4j RerankJina Groundingguards LLMrespuesta Cada etapa acota la evidencia antes de entregarla al modelo.

1. Análisis de intención

Primero clasificamos la consulta y, si es compuesta, la descomponemos en sub-preguntas por producto o característica. Esto permite buscar con la intención correcta en lugar de lanzar una sola búsqueda genérica.

2. Búsqueda híbrida

Combinamos dos señales: búsqueda densa (embeddings semánticos) y sparse (BM25, coincidencia léxica exacta). La híbrida rescata lo que cada una por separado pierde: sinónimos por un lado, códigos de producto y términos exactos por el otro.

3. Expansión de grafo

Con los chunks iniciales, consultamos Neo4j para traer nodos relacionados: el documento padre, entidades conectadas y documentos hermanos. Es la parte "RAG → GraphRAG": la evidencia deja de ser una lista plana y pasa a ser un subgrafo.

4. Reranking

Los candidatos se reordenan por relevancia real respecto a la consulta (con un reranker dedicado), y se recortan a un presupuesto de contexto. El objetivo es que el LLM reciba pocos fragmentos, pero los correctos.

5. Grounding y guards

Antes de generar, se aplican las capas deterministas: el guard de SKU (anti-contaminación cruzada), el guard anti prompt-injection (el contenido recuperado se trata como dato no confiable y se redacta si trae instrucciones) y el grounding restringido (búsqueda externa acotada a dominios permitidos).

6. Generación y respuesta diferida

El LLM genera con el contexto ya filtrado. Si tras todo el pipeline el dato clave (p. ej. el SKU exacto) no aparece en ninguna fuente, el sistema no inventa: activa el protocolo de respuesta diferida y deriva a un humano. El debug_info conserva la trazabilidad de cada decisión para auditar.

La robustez no viene de un prompt gigante, sino de acotar la evidencia etapa por etapa y de saber cuándo no responder.