Knowledge Graph vs Vector Database para la memoria del agente
Agentled - Arquitecta de sistemas
Knowledge Graph vs Vector Database para la memoria del agente
Ambos se describen como "memoria de IA". Ambos aparecen en diagramas de arquitectura. Pero resuelven problemas diferentes, y utilizar el incorrecto es uno de los errores más costosos en los sistemas de agentes de producción.
Aquí hay una comparación honesta: cómo funciona cada uno, dónde sobresale cada uno y por qué la mayoría de los equipos necesitan comprender la diferencia antes de diseñar cualquier cosa.
Cómo funcionan las bases de datos vectoriales
Una base de datos vectorial convierte el contenido en representaciones numéricas de alta dimensión (incrustaciones) y las almacena indexadas por similitud. Cuando consulta una base de datos vectorial, se pregunta: "¿Qué contenido almacenado es semánticamente similar a esta entrada?"
La mecánica:
- El texto (u otro contenido) se pasa a través de un modelo de incrustación (OpenAI, Cohere, etc.)
- El resultado es un vector: una lista de 768 o 1536 números de punto flotante que representan el significado.
- Estos vectores se almacenan e indexan (normalmente con indexación HNSW o IVF)
- En el momento de la consulta, su consulta también se incrusta y la búsqueda del vecino más cercano encuentra los vectores almacenados más similares.
En qué son buenos los DB vectoriales:
- Búsqueda semántica ("buscar contenido similar a este")
- Generación de recuperación aumentada (RAG): extracción de contexto relevante antes de una llamada LLM
- Coincidencia difusa en grandes corpus no estructurados
- Deduplicación y agrupación por similitudes.
La característica crítica: Las bases de datos vectoriales son almacenes sin estado. Mantienen contenido y permiten la recuperación. No razonan sobre las relaciones entre elementos. No se actualizan según los resultados. Cada consulta es independiente.
Cómo funcionan los gráficos de conocimiento
Un gráfico de conocimiento almacena entidades y relaciones, no contenido sin procesar. Un KG representa el mundo como una red estructurada de nodos tipificados y bordes etiquetados.
Ejemplo: una entidad podría ser Company: Acme Corp, con relaciones como employs → Person: Jane Smith, operates_in → Geography: Germany, similar_to → Company: TechStart GmbH. Estas no son sólo co-ocurrencias: son relaciones explícitas, tipificadas y transitables.
La mecánica:
- Los datos se estructuran en tripletas sujeto-predicado-objeto (o equivalente en forma de gráfico de propiedades)
- Las relaciones son ciudadanos de primera clase: tienen tipos, propiedades y pueden contener metadatos.
- Las consultas atraviesan el gráfico (Cypher, SPARQL, Gremlin) en lugar de buscar similitudes.
- Los nuevos aprendizajes añaden nodos y aristas; Las relaciones se actualizan según lo que observa el sistema.
Para qué son buenos los gráficos de conocimiento:
- Razonamiento de múltiples saltos ("¿qué saben los colegas de Jane sobre este mercado?")
- Descubrimiento de relaciones y recorrido de caminos.
- Almacenamiento de conocimiento de dominio estructurado que evoluciona con el tiempo.
- Llevar memoria que persiste y se actualiza a través de ejecuciones de agentes.
- Codificar correcciones y comentarios humanos como hechos estructurados.
La característica crítica: Los gráficos de conocimiento tienen estado y son relacionales. Modelan causa, conexión y estructura, no sólo similitud.
Comparación directa
| Vector Database | Knowledge Graph | |
|---|---|---|
| Abstracción central | Similitud | Relación |
| Modelo de consulta | Búsqueda de vecino más cercano | Recorrido de gráficos |
| Estado | Sin estado (almacena; no aprende) | Con estado (actualizaciones con nuevas observaciones) |
| Mejor para | Recuperar contenido relevante | Razonamiento sobre hechos estructurados |
| Maneja la ambigüedad | Sí (borroso por diseño) | Estructuradas (relaciones explícitas) |
| Aprendizaje cruzado | No | Sí |
| Tipos de relación | Implícito (incrustaciones) | Explícito (bordes etiquetados) |
| Actualizar modelo | Agregar/eliminar vectores | Agregar/actualizar/eliminar nodos y bordes |
| Razonamiento de múltiples saltos | Débil | Fuerte |
| Correcciones humanas | Difícil de incorporar | Operación de primera clase |
| Herramientas típicas | Piña, Weaviate, Qdrant, Chroma | Neo4j, Memgraph, Amazon Neptune, AgentLed KG |
Cuando las bases de datos vectoriales son la elección correcta
Si su caso de uso principal es la recuperación (encontrar contenido relevante de un gran corpus no estructurado), una base de datos vectorial es correcta.
Las canalizaciones RAG son el ejemplo canónico. Tiene una base de conocimientos de documentos, políticas o conversaciones pasadas. Antes de cada llamada LLM, recupera los fragmentos más relevantes. El LLM produce una mejor respuesta porque tiene un contexto relevante. El trabajo de la base de datos vectorial es la recuperación, no el razonamiento.
Utilice una base de datos vectorial cuando:
- Necesita búsqueda semántica en grandes conjuntos de documentos.
- Estás creando una capa RAG para un LLM
- Su contenido es principalmente texto no estructurado.
- No necesitas que el sistema recuerde entre sesiones.
- La similitud es la principal señal de recuperación.
Cuando los gráficos de conocimiento son la opción correcta
Si sus agentes necesitan transmitir conocimiento estructurado a través de múltiples ejecuciones (recordando qué funcionó, qué falló, qué relaciones importan), una base de datos vectorial le fallará. Necesitas un gráfico.
El modo de falla del uso de una base de datos vectorial para la memoria del agente es predecible: el agente se ejecuta 100 veces y la ejecución 101 comienza con el mismo conocimiento que la ejecución 1. Puede recuperar interacciones pasadas similares, pero no puede razonar sobre ellas. Puede encontrar "algo como esto sucedió antes", pero no puede aplicar "lo que aprendimos cuando esto sucedió antes".
Utilice un gráfico de conocimiento cuando:
- Sus agentes necesitan mejorar con el tiempo sin necesidad de reconfiguración humana
- Estás almacenando conocimiento de dominio estructurado (entidades, empresas, personas, procesos)
- Necesitas razonar sobre las relaciones, no sólo recuperar contenido similar.
- Los comentarios y correcciones humanos deberían actualizar el comportamiento del sistema.
- Cuestiones transversales de múltiples saltos ("encontrar clientes potenciales conectados a inversores en nuestra cartera")
Cómo Knowledge Graph de AgentLed almacena los aprendizajes sobre el flujo de trabajo
KG de AgentLed está diseñado específicamente en torno al caso de uso agente: no la recuperación de documentos, sino la memoria operativa.
Cuando un agente completa una ejecución de flujo de trabajo, se pueden volver a escribir varios tipos de aprendizajes en el KG:
Datos de rendimiento: qué enfoque (modelo, solicitud, fuente de datos) produjo la mejor calidad de resultado para un tipo de tarea determinado. Almacenado como propiedades en nodos de ejecución de flujo de trabajo.
Correcciones humanas: cuando un revisor cambia el resultado de un agente o proporciona comentarios, esa corrección se escribe como un hecho estructurado. "Para el emparejamiento de inversores, la superposición de carteras es una señal más fuerte que el enfoque sectorial declarado". Esto se convierte en conocimiento transitable, no en una entrada de registro enterrada.
Relaciones entre entidades: a medida que los agentes interactúan con los datos (empresas, personas, productos, procesos), construyen un gráfico de relaciones. Una empresa que se encontró por primera vez como un cliente potencial podría vincularse más tarde con un competidor, un inversor compartido y una señal de contratación. Esas conexiones persisten.
Calibración de confianza: El KG rastrea no solo lo que hizo el agente, sino también su confianza y si esa confianza estaba justificada. Con el tiempo, esto calibra la incertidumbre del agente: aprende cuándo señalar para la revisión humana en lugar de proceder de forma autónoma.
Nodos de patrón: las estructuras recurrentes se representan explícitamente. "Introducción cálida a LinkedIn + conexión de inversor compartida = alta tasa de respuesta para este ICP" se convierte en un nodo de patrón con nombre que los pasos de decisión posteriores pueden consultar directamente.
El resultado: un agente que ejecuta la iteración 50 del flujo de trabajo es materialmente diferente de uno que ejecuta la iteración 5. No se vuelve a entrenar: el modelo subyacente es el mismo. Pero está operando con un contexto estructurado más rico sobre lo que ha funcionado y lo que no.
El error común: no tienes que elegir
Los sistemas de agentes sofisticados a menudo utilizan ambos, cada uno donde encaja.
Una arquitectura típica:
- Capa de base de datos vectorial: recuperación de RAG antes de las llamadas a LLM. Extraiga documentos, políticas o contenido anterior relevantes para fundamentar el contexto del modelo.
- Capa KG: Memoria operativa. Almacene aprendizajes estructurados, relaciones entre entidades, correcciones humanas y patrones de desempeño.
La base de datos vectorial responde "¿qué es relevante?" El KG responde "¿qué sabemos?" Son complementarios, no competitivos.
Lo que los equipos cometen mal es tratar una base de datos vectorial como sustituto de la memoria estructurada o crear esquemas gráficos elaborados cuando solo necesitan una búsqueda semántica. Haga coincidir la herramienta con el problema.
Orientación práctica
Si está creando una canalización RAG pura para preguntas y respuestas sobre documentos: utilice una base de datos vectorial.
Si está creando agentes autónomos que necesitan mejorar con el tiempo, recuerde las relaciones específicas del dominio e incorpore comentarios humanos: utilice un gráfico de conocimiento.
Si está creando flujos de trabajo agentes a escala que necesitan recuperación y memoria: use ambos, en diferentes capas de la pila.
La decisión arquitectónica es importante desde el principio. Una base de datos vectorial a la que se le pide que actúe como memoria desarrollará soluciones alternativas (filtros de metadatos, reindexación manual, incrustaciones de trucos) que agravan la deuda técnica. Un KG elegido para la búsqueda de similitudes parecerá excesivo y agregará complejidad innecesaria.
Primero haz la capa correcta. Las opciones de herramientas dentro de cada capa son secundarias.