Cog-RAG: Cognitive Retrieval-Augmented Generation
Cog-RAG es la arquitectura propietaria de Queria que transforma la busqueda documental de un proceso mecanico a uno cognitivo. En lugar de limitarse a encontrar documentos similares a una pregunta, el sistema comprende, planifica, razona y verifica antes de responder.
A partir de la v3.5.0 todo el ciclo Cog-RAG se implementa como un canvas DSL (purpose = CHAT), una pipeline grafica compuesta de nodos tipados que el tenant puede personalizar sin escribir codigo. El mismo patron se aplica a la ingestion (purpose = INGESTION) y a las integraciones externas (purpose = SERVICE para OAuth).
Ver tambien
- Chat DSL (Canvas) -- como configurar la pipeline de chat para tu empresa
- Ingestion DSL -- pipeline de ingestion role-aware
- OAuth y Service Canvas -- integraciones autenticadas
El problema del RAG tradicional
Un sistema RAG clasico sigue tres pasos:
- Recibe la pregunta del usuario
- Busca los documentos mas similares en la base de datos vectorial
- Pasa los documentos encontrados al modelo de lenguaje para generar la respuesta
Este enfoque tiene limites evidentes. No gestiona preguntas complejas que requieran informacion de fuentes distintas. No adapta la estrategia de busqueda a la complejidad de la pregunta. No verifica si los resultados encontrados son realmente pertinentes. No es capaz de razonar sobre varios documentos para producir una sintesis. No tiene memoria de quien esta hablando o de lo que se ha preguntado antes.
De RAG a Cog-RAG agentico con memoria
La arquitectura de Queria evoluciona el RAG tradicional a lo largo de tres ejes:
- Cognitivo (Cog) -- el sistema comprende el intent, planifica la estrategia, descompone las consultas y verifica el grounding antes de responder.
- Agentico -- patron ReAct multi-step: el motor ejecuta una cadena de observacion, razonamiento y accion (llamada a herramientas, recuperacion, sintesis), repetida hasta convergencia o limite de iteraciones.
- Con memoria -- cada usuario tiene un Memory Subject persistente que conserva hechos, preferencias y contexto entre conversaciones. El bot recuerda quien eres, en que estas trabajando, que ya has visto.
El conjunto de los tres ejes se implementa como un canvas DSL personalizable. Lo que sigue describe el flujo "de sistema" -- punto de partida para cada tenant, modificable sin release de backend.
Como funciona Cog-RAG agentico
Cog-RAG introduce un ciclo cognitivo completo entre la pregunta y la respuesta, memory-aware y agentic:
[Memory recall]
|
v
Pregunta ----> [Memory subject + conversation history] ----> contexto
| |
v |
[1] Analisis y comprension de la consulta (con contexto usuario) |
| |
v |
[2] Planificacion de la estrategia de busqueda |
| |
v |
[3] Descomposicion en sub-consultas (si hace falta) |
| |
v |
[4] *Loop agentico ReAct* |
| | |
| v |
| Action: llamada a herramientas (retrieval, external_tool, ...) <-+
| |
| v
| Observation: resultados herramientas
| |
| v
| Reasoning: el critic evalua la suficiencia
| |
| v
| (converge?) --no--> nueva action
| |
| si
|
v
[5] Reordenamiento semantico
|
v
[6] Verificacion calidad y grounding (critic)
| |
| (insuficiente)
| |
| v
| Retorno al loop agentico
| con scope ampliado
|
v
[7] Sintesis con razonamiento profundo
|
v
[8] Update memoria (hechos persistentes emergidos)
|
v
Respuesta con citasCada paso es un nodo del canvas, gestionado por componentes especializados que colaboran de forma autonoma. El critic -- un nodo LLM dedicado -- evalua en cada iteracion si las evidencias recogidas son suficientes y precisas; si no lo son, el sistema relanza el loop con scope ampliado. La conversacion se cierra solo cuando el critic esta de acuerdo o se alcanza el limite de iteraciones configurado.
Memoria persistente por usuario
Una caracteristica distintiva de Cog-RAG v3.5.0 es la memoria persistente que el sistema mantiene para cada usuario, a traves de distintas conversaciones y canales (web, widget, WhatsApp).
Memory Subject
Cada usuario tiene un Memory Subject -- una estructura en DB que recoge:
| Categoria | Contenido | Ejemplos |
|---|---|---|
| Perfil profesional | Rol, area de responsabilidad, dominio de interes | "Responsable compliance", "trabaja en contratos GDPR" |
| Preferencias | Estilo de respuesta, idioma, nivel de detalle | "quiere respuestas breves", "prefiere italiano" |
| Contexto operativo | En que esta trabajando, plazos, proyectos abiertos | "analiza el balance 2025", "deadline 31 diciembre" |
| Referencias | Documentos, clientes, proveedores mencionados a menudo | "trabaja a menudo con el proveedor Rossi srl" |
El Memory Subject esta aislado por (userId, companyId): ningun dato de un usuario fluye hacia otro, ni siquiera dentro de la misma empresa.
Tres niveles de memoria
+-----------------------------+
| Memoria intra-conversacion | ultimos N mensajes (turnos)
+-----------------------------+
|
v
+-----------------------------+
| Historial conversaciones | resumenes de sesiones previas
+-----------------------------+
|
v
+-----------------------------+
| Memory Subject (persistente)| hechos, preferencias, contexto usuario
+-----------------------------+- Intra-conversacion: el asistente recuerda exactamente lo que se dijo en los turnos previos de la misma chat. Puedes referirte al "punto 3 de la respuesta previa" sin repetirlo.
- Historial de conversaciones: resumenes compactos de las conversaciones pasadas consultables al vuelo. Util para retomar un tema abierto hace dias.
- Memory Subject: hechos clave extraidos automaticamente o senalados explicitamente. Persisten hasta que el usuario los elimine desde su perfil de memoria.
Actualizacion de la memoria
Un nodo memory_writer al final del canvas extrae de los turnos completados informacion candidata a promocionar al Memory Subject. La promocion siempre es transparente: el usuario ve un aviso "he memorizado que..." y puede rechazar la promocion, o consultar su perfil de memoria desde la configuracion.
Privacidad de la memoria
- Lado usuario: la pagina Perfil > Memoria muestra todos los hechos memorizados, con posibilidad de modificacion y eliminacion puntual.
- Lado administrador: el SYSTEM_ADMIN puede visualizar la memoria agregada de una empresa solo para auditoria, nunca contenidos por usuario individual sin mandato explicito.
- Eliminacion del usuario: todos los Memory Subject asociados se eliminan en cascada.
Para la guia del lado usuario ver Memoria y Contexto.
El sistema de dos cerebros
En el corazon de Cog-RAG operan dos modelos IA con roles complementarios:
Planner: el cerebro rapido
El Planner es un modelo rapido y ligero, optimizado para decisiones inmediatas. Se ocupa de:
- Clasificacion del intent: entiende lo que el usuario esta realmente preguntando
- Routing: decide que pipeline activar (busqueda simple, descomposicion, comparacion)
- Descomposicion de las consultas: descompone preguntas complejas en sub-preguntas manejables
- Evaluacion de la complejidad: estima la dificultad de la pregunta para calibrar los parametros de busqueda
- Utility y soporte: gestiona operaciones auxiliares como reformulacion y resumenes rapidos
El Planner opera en milisegundos y no compromete recursos computacionales pesados.
Writer: el cerebro profundo
El Writer es un modelo potente con capacidad de razonamiento avanzado. Se ocupa de:
- Sintesis multi-documento: combina informacion de decenas de fuentes en una respuesta coherente
- Razonamiento complejo: afronta preguntas que requieren inferencias, comparaciones, analisis
- Generacion de alta calidad: produce textos profesionales, estructurados y precisos
- Pensamiento explicito: usa un proceso de razonamiento interno (thinking) antes de formular la respuesta
El Writer entra en juego solo cuando hace falta su potencia, preservando la eficiencia general del sistema.
La colaboracion
El Planner decide que hacer y como hacerlo. El Writer ejecuta con profundidad. Esta separacion permite obtener tiempos de respuesta rapidos para preguntas simples (gestionadas casi totalmente por el Planner) y respuestas de alta calidad para preguntas complejas (donde el Writer invierte tiempo en el razonamiento).
El Critic
Al patron agentic se anade un tercer rol: el Critic. Es una instancia LLM dedicada que, despues de cada accion del Writer, evalua el resultado a lo largo de dimensiones explicitas (suficiencia de las evidencias, contradicciones internas, alineacion con la pregunta original, cobertura de las sub-consultas). Si el analisis falla uno o mas criterios, el critic emite una devolucion al loop agentico con instrucciones dirigidas (ej. "busca tambien en fuentes normativas", "profundiza el aspecto X").
El Critic es activable mediante kill-switch CHAT_CRITIC_ENABLED. En escenarios latency-critical puede desactivarse; en escenarios mission-critical (legal, sanitario, fiscal) esta siempre activo.
Patron agentic y tool use
En modalidad agentica, el Writer no se limita a sintetizar: es un agente que decide que herramientas invocar para llegar a la respuesta. Las herramientas disponibles en el canvas son:
| Tipo de herramienta | Ejemplos |
|---|---|
| Retrieval interno | Busqueda en colecciones Qdrant del tenant (KB, user docs, sector) |
| External sources | Legal Sources, Food Sources, Chem Sources, Pharma Sources, AE Sources |
| External tools via OAuth | Slack post_message, Stripe customer.lookup, GCal create_event |
| Open data | Geocoding (Nominatim), POI (Overpass), meteo (Open-Meteo), enciclopedia (Wikipedia) |
| AI Constructor | Pipelines sectoriales pre-empaquetadas (Tourism, en roadmap Fiscal, Sanitario) |
| Memory lookup | Consulta del Memory Subject del usuario actual |
Cada herramienta es un nodo del canvas. El agente elige iterativamente cual invocar observando los resultados previos y razonando sobre el gap respecto a la pregunta. Toda la secuencia se traza y es visible en el panel de razonamiento.
Orquestacion de las consultas
No todas las preguntas son iguales. Cog-RAG clasifica cada query y elige la estrategia de orquestacion mas adecuada.
Consultas simples
Para preguntas directas con una respuesta esperada clara, el sistema ejecuta una busqueda directa y genera la respuesta. Sin descomposicion, sin pasos superfluos.
Ejemplo: "Cual es la fecha de vencimiento del contrato con el proveedor X?"
Descomposicion secuencial
Cuando las sub-preguntas dependen entre si, se ejecutan en secuencia. La respuesta de una alimenta la siguiente.
Ejemplo: "Quienes son los herederos designados en el testamento y que cuota corresponde a cada uno?" Primero se identifican los herederos, luego se buscan las cuotas para cada uno.
Descomposicion paralela
Cuando las sub-preguntas son independientes, se ejecutan en paralelo para maximizar la velocidad.
Ejemplo: "Compara las condiciones contractuales del proveedor A con las del proveedor B." Las busquedas sobre los dos proveedores ocurren simultaneamente.
Descomposicion jerarquica
Para preguntas exploratorias, el sistema parte de lo general y profundiza progresivamente.
Ejemplo: "Cuales son las principales problematicas emergidas en los informes de auditoria del ultimo ano?" Primero una busqueda amplia, luego profundizaciones dirigidas en las tematicas emergidas.
Descomposicion comparativa
Para comparaciones estructuradas, el sistema recoge informacion de ambas partes y produce un analisis side-by-side.
Ejemplo: "Cuales son las diferencias entre la poliza de seguro actual y la propuesta?"
Busqueda adaptativa
Los parametros de busqueda se calibran automaticamente en base a la complejidad estimada de la query:
| Complejidad | Documentos buscados | Umbral minimo | Reranking | Diversificacion |
|---|---|---|---|---|
| Simple | Pocos, dirigidos | Alto | Si | Bajo |
| Moderada | Cantidad media | Medio | Si | Media |
| Compleja | Cantidad amplia | Bajo | Si | Alta |
| Agregativa | Cobertura maxima | Muy bajo | No | Maxima |
Las consultas agregativas (estadisticas, resumenes de grandes conjuntos) requieren un enfoque distinto: maxima cobertura con diversificacion alta para evitar resultados redundantes.
Busqueda hibrida
Cada busqueda combina dos enfoques complementarios:
Busqueda semantica: compara el significado de la pregunta con el de los documentos a traves de vectores de 1024 dimensiones. Sobresale al encontrar documentos pertinentes incluso cuando las palabras son distintas.
Busqueda lexica (BM25): compara las palabras clave. Sobresale al encontrar documentos con terminos especificos (codigos, nombres propios, numeros de articulo).
Los resultados de las dos busquedas se combinan mediante Reciprocal Rank Fusion (RRF), un algoritmo que balancea los puntajes de ambos enfoques para producir un ranking final optimo.
Integracion multi-fuente
Cog-RAG no se limita a los documentos empresariales. El sistema integra de forma transparente:
- Documentos empresariales: archivos subidos por la organizacion
- Knowledge Base: la base de conocimiento curada y permanente
- Fuentes externas certificadas: bases de datos especializadas en ambito legal, alimentario, quimico y farmaceutico
Todas las fuentes participan en el mismo proceso de busqueda y reranking. El usuario recibe una respuesta unificada con citas que identifican claramente el origen de cada informacion mediante badges de color distintos por tipo de fuente.
Razonamiento transparente
Una caracteristica distintiva de Cog-RAG es la transparencia del proceso de razonamiento. El Writer usa un modo de thinking explicito: antes de formular la respuesta, genera un razonamiento interno donde analiza las fuentes, evalua la pertinencia, identifica posibles contradicciones y planifica la estructura de la respuesta.
Este razonamiento es visible al usuario a traves del panel dedicado en la interfaz. El usuario puede verificar como el sistema llego a una determinada conclusion, que fuentes considero relevantes y por que, y donde encontro posibles lagunas informativas.
La transparencia del razonamiento es fundamental en contextos enterprise donde las decisiones basadas en las respuestas del sistema deben ser verificables y justificables.
Personalizabilidad via canvas DSL
A diferencia de las arquitecturas RAG monoliticas, Cog-RAG v3.5.0 esta enteramente construido sobre canvas DSL. Esto significa:
- Cada tenant puede duplicar la pipeline de sistema y modificarla -- anadir herramientas, cambiar el orden de los nodos, excluir el critic, anadir steps de sanitizacion PII antes del envio del prompt.
- Cada topic puede tener una pipeline dedicada (ej. el topic "Compliance" usa critic + fuentes normativas obligatorias, el topic "Marketing" usa una pipeline mas libre).
- Los canvas estan versionados: snapshots, rollback, auditoria inmutable de las versiones pasadas.
- Los cambios de pipeline no requieren release del backend.
Para el editor canvas, los nodos disponibles y los ejemplos ver la seccion Canvas Agent Builder.
Resumen v3.5.0
| Dimension | Implementacion |
|---|---|
| Cognitivo | Planner + Writer + Critic, descomposicion adaptativa, busqueda hibrida |
| Agentico | Patron ReAct multi-step, tool use dinamico, convergencia guiada por el critic |
| Memoria | Memory Subject persistente por (user, company), tres niveles (intra-conversacion, historial, perfil) |
| DSL-native | Canvas tipados para CHAT / INGESTION / SERVICE / WIDGET con purpose distintos |
| Multi-fuente | Documentos tenant + KB + 5 external sources + open data + OAuth tools |
| Multi-canal | Web app, widget incrustado, WhatsApp via Twilio (V1) |
| Transparencia | Panel de razonamiento visible, audit inmutable snapshot canvas |
| Privacidad | Aislamiento multi-tenant, memoria usuario-local, IA on-prem (DGX Spark) |