DataTalks.Club Podcast Wiki

Comparison

Knowledge Graph vs Vector Search

A podcast-grounded comparison of knowledge graphs and vector search for retrieval, RAG, semantic search, relationship-heavy knowledge systems, and production evaluation.

Related Wiki Pages

Knowledge Graph vs Vector Search Graph RAG vs Vector RAG Search, RAG, and Knowledge Systems Vector Databases Embeddings Search Retrieval-Augmented Generation Production Search Evaluation LLM Evaluation Workflows

Knowledge graphs and vector search solve different retrieval problems because they preserve different signals. A knowledge graph stores entities, properties, relations, and paths. Vector search stores embeddings and retrieves nearby items by similarity.

The DataTalks.Club archive treats them as complements, not enemies. Use vector search when the system must find semantically similar passages or products. It also fits images, users, and sessions. Use a knowledge graph when the relation is part of the answer.

Parent-child structure, order, lineage, and provenance fit the graph side. Simulation links, ownership, and domain constraints also belong there.

Anahita Pakiman gives the clearest graph-side example in Knowledge Graphs and LLMs for Automotive R&D. At 15:58-22:11, she explains why automotive R&D teams use graph databases for semantic reporting and vehicle-part relationships. She also covers clustering and load-path detection.

Atita Arora gives the clearest vector-side RAG example in Modern Search Systems. At 38:24-42:49, she describes chunking and embedding transcripts. The system then retrieves relevant chunks and passes them to an LLM with citations.

For the deeper archive reference, use Knowledge Graph vs Vector Search. Use Graph RAG vs Vector RAG when the question is what context an LLM should receive. Use Vector Database vs Search Engine when the question is whether vector retrieval belongs in a dedicated vector database or an existing search stack.

Short Comparison

Use vector search when the system needs fuzzy recall. A user can ask with one wording, while the useful passage or product uses another. Reem Mahmoud’s Production ML Search episode frames this around embeddings as shared representations at 21:55. The same episode separates candidate retrieval from ranking at 12:45, which matters because vector similarity finds candidates. The product still has to rank, filter, and evaluate them.

Use a knowledge graph when the system must preserve relationships.

Anahita’s automotive R&D example needs these relationships:

Anahita explains this at 20:32-22:11 in Knowledge Graphs and LLMs for Automotive R&D. Graph visualization and weighted paths reveal structure that’s hard to look at as a table.

The practical split is:

Read this comparison alongside Search, RAG, and Knowledge Systems, then use Vector Databases and Embeddings for the vector layer. Use Search and Retrieval-Augmented Generation for the retrieval and RAG layers.

Vector Search Fit

Choose vector search when users need related material, not exact terms. In Modern Search Systems, Atita starts from Solr and Lucene. She then moves to Elasticsearch, OpenSearch, Qdrant, and standalone vector databases. At 17:01-20:27, she says teams should first ask what they want to achieve with vectors. They can use vectors inside an existing search system, or add a dedicated vector database when separate iteration and reindexing constraints matter.

Vector search is also the natural starting point for text-heavy RAG. Atita’s podcast-transcript example at 35:49-42:49 shows the workflow.

That connects vector search to RAG, not only to storage. If retrieval returns weak chunks, the LLM can’t reliably answer from the right evidence.

Atita’s 48:09 section adds multi-level evaluation:

Vector search also fits product search and recommendations. In Production ML Search, the 29:00-30:22 section separates vector compute from vector storage. Teams compute embeddings during ingestion and again at query time. They also need consistent model versions, reindexing plans, and fast query handling.

The same episode expands vector search beyond text. At 33:13, it discusses multimodal embeddings such as image and text representations. At 34:00-45:11, it adds hybrid search with recency and popularity. Behavior, metadata, and query-time weights matter too.

In production search, semantic similarity is one signal rather than the whole product.

Knowledge Graph Fit

Choose a knowledge graph when losing structure loses the answer. Anahita’s episode starts with semantic reporting for automotive crash simulations. At 15:58, she explains why graph databases became attractive when vehicle structures, simulation relationships, and changing automotive data made a relational model costly to maintain.

At 20:32-22:11 in Knowledge Graphs and LLMs for Automotive R&D, Anahita compares graph and tabular representations. She says many graph facts can be expressed in tables. The graph helps with complex relationships and visual comparison across hundreds of simulations. It also helps with clustering and load-path detection.

In that example, the relationship between parts isn’t metadata around the answer. It’s the answer.

The same logic applies to documents when section order, containment, and entity relationships matter. Around 38:10, Anahita contrasts chunks in a vector database with a knowledge graph. A vector database can store embedded chunks, but a graph can also store chapters and sections. It can also store ownership, order, and relationships between chunks.

Around 39:56, she shows the retrieval version. Prompt templates can use Cypher-style graph queries to retrieve relationship-aware context.

Graphs shift the hard work instead of removing it. At 42:42, Anahita warns that LLM-extracted graph content still needs verification. Teams can use LLMs to extract candidate entities and relationships. They still need to model, check, and maintain trusted relations.

That places graph systems near LLM Evaluation Workflows and production search evaluation.

Combined Systems

Combine knowledge graphs and vector search when the user needs both semantic recall and relationship-aware context. The archive’s strongest combined case is RAG over complex knowledge. Vector search can find likely passages or entities, then the graph can supply neighborhoods and paths. It can also supply section hierarchy or domain constraints before the LLM answers.

Anahita describes that combined direction at 33:43-39:56 in Knowledge Graphs and LLMs for Automotive R&D. She frames knowledge graphs and LLMs around grounding answers, then explains why chunk-only vector retrieval can miss relations. The graph adds semantics that the prompt can use.

Atita’s transcript RAG example gives the vector-first version of the same architecture. At 42:49 in Modern Search Systems, the vector query retrieves chunks, and the prompt asks the model to answer from that context. If the product later needs section hierarchy or speaker identity, a graph layer can provide those signals. It can also provide episode order and concept relationships instead of asking vector similarity to preserve all structure.

Production search uses a similar principle without necessarily calling it a knowledge graph. In Production ML Search, the 34:00-45:11 section combines vector similarity with filters, freshness, and popularity. It also covers user behavior and query-time weights. Those signals remind teams that retrieval quality depends on more than nearest-neighbor distance.

Production Risks

Vector search fails when the embedding space doesn’t preserve the property the product cares about. It also fails when chunks are too small, too large, or stale. Missing metadata can break filtering and citations. Atita’s 38:24-48:09 RAG discussion ties those risks to chunking, overlap, and retrieval count. It also ties them to answer generation, references, and human review.

Vector search also creates pipeline work. In Production ML Search, the 29:00-30:22 section makes ingestion and query-time embedding two separate compute paths. When the model changes, teams may need to recompute vectors. When documents change, teams need reindexing. When product goals change, teams may need new ranking signals or query-time weights.

Knowledge graphs fail differently because they can encode the wrong relation. They can also miss an important relation or become stale as the domain changes. They can become brittle if the schema is too rigid. Anahita’s 42:42 warning about verifying LLM-generated graph content matters here. A graph can make relationships more visible, but it doesn’t make them true automatically.

Evaluate both systems by checking whether the user got the right evidence or answer. For vector search, check retrieval, ranking, and citations. Then check answer quality. For graphs, check entity extraction and relation correctness. Check traversal and provenance too.

Use Production Search Evaluation for retrieval metrics and business outcomes. Use LLM Evaluation Workflows when the retrieved context feeds an LLM.

Guest Experts

Anahita Pakiman is the main archive expert for knowledge graphs in this comparison. Her automotive R&D episode connects Neo4j, semantic reporting, graph ML, and RAG. It also covers Cypher-style retrieval and verification of extracted knowledge.

Atita Arora is the main archive expert for vector RAG and modern search architecture. Her modern search episode connects Solr, Lucene, Qdrant, and vector databases. It also covers transcript RAG, citations, and human-in-the-loop evaluation.

Reem Mahmoud anchors the production vector-search side through Production ML Search. That episode covers embeddings as shared representations and vector compute. It also covers hybrid search, metadata, and recency. Query-time weighting, vector-database selection, and business metrics matter there too.

Ranjitha Kulkarni adds the agent boundary in Building Agentic AI Systems. At 29:30-37:39, she treats RAG as useful but constrained by latency and cost. Metadata, noisy context, and garbage-in-garbage-out matter too. Retrieval becomes one tool inside an agent when the workflow needs planning or actions.

Use these pages for the surrounding retrieval and production context: