Entity, Relationship, Claim, Community Report Housekeeping ?

[cchighman]

One common challenge with baseline RAG systems that are incrementally updated is how you are able to manage memories specifying information that is now out of date or no longer relevant. In particular, when processing an incremental update where a new memory is added to a given system reflecting a change to existing knowledge, how can we ensure ambiguity isn't being introduced to the system?

My preference would be to never upsert, merge via density clustering estimations, or delete any previous, validated conclusions reached but rather look at those as a stream over time reflecting how those ideas have changed over time.

To my question, and I haven't tested this yet but a cursory look through code and docs doesn't seem to address, if I consume two or more documents that reflect changes in some common subject matter, does graphrag have a way today to prevent ambiguities from being introduced?

Example: Suppose the relationship between two nodes change. Will the previous one be removed from the system? Example - Service1 used to be owned by Team1 in Org1 but is now owned by Team2 in Org2. A document is consumed reflecting the change.

It looks like incremental updates is more related to the physical updates to underlying final parquets as opposed to logical updates where relationships, covariates, or community reports are updated.

[cchighman]

This question may be very similar in some respects to #1313 which is still open

[cchighman]

It's looking like we need to implement a concept of temporal awareness which introduces timestamps and other dedup / merge behavior. Similar to what's seen here: https://github.com/getzep/graphiti/tree/main

I'm wondering if this might actually be an example of a custom verb that could be implemented as a part of extending GraphRAG for a specific use case. Very curious whether there is a roadmap around temporal awareness for non-static knowledge graphs.