Knowledge graphs are genuinely interesting as a grounding mechanism because they make entity relationships explicit and queryable, something flat vector stores can't do. Overture's cross-theme approach (linking buildings, roads, POIs into a unified graph) gives the LLM a structured substrate rather than a bag of retrieved chunks.
The piece I'd push on: KGs solve the structural grounding problem but don't automatically solve the temporal one. A KG edge asserting "restaurant X is at address Y" is only as fresh as the last ingest. Cosine similarity over embeddings has the same blindspot- our benchmarks found AUROC ~0.59 when trying to separate current from superseded facts via similarity alone, which is near chance. The KG version of this failure is quieter but just as real: a stale edge looks identical to a fresh one at query time.
The more interesting design question is whether you layer a bi-temporal ledger on top of the KG, tracking both valid-time and transaction-time per assertion. so retrieval can enforce "give me the fact that was true as of now, not just the most similar one." That's a different primitive than either RAG or a static KG. (Disclosure: I work on MemStrata, which takes this approach; we published benchmarks on the stale-fact problem at https://arxiv.org/abs/2606.26511.)
Curious whether Overture's team has thought about how to handle entity updates — e.g. a building that changes use and whether the KG schema has first-class support for supersession or just overwrites.
2 comments
[ 2.9 ms ] story [ 21.2 ms ] threadThe piece I'd push on: KGs solve the structural grounding problem but don't automatically solve the temporal one. A KG edge asserting "restaurant X is at address Y" is only as fresh as the last ingest. Cosine similarity over embeddings has the same blindspot- our benchmarks found AUROC ~0.59 when trying to separate current from superseded facts via similarity alone, which is near chance. The KG version of this failure is quieter but just as real: a stale edge looks identical to a fresh one at query time.
The more interesting design question is whether you layer a bi-temporal ledger on top of the KG, tracking both valid-time and transaction-time per assertion. so retrieval can enforce "give me the fact that was true as of now, not just the most similar one." That's a different primitive than either RAG or a static KG. (Disclosure: I work on MemStrata, which takes this approach; we published benchmarks on the stale-fact problem at https://arxiv.org/abs/2606.26511.)
Curious whether Overture's team has thought about how to handle entity updates — e.g. a building that changes use and whether the KG schema has first-class support for supersession or just overwrites.