Evaluating the Ripple Effects of Knowledge Editing in Language Models (2024)

Abstract: Modern language models capture a large body of factual knowledge. However, some facts can be incorrectly induced or become obsolete over time, resulting in factually incorrect generations. This has led to the development of various editing methods that allow updating facts encoded by the model. Evaluation of these methods has primarily focused on testing whether an individual fact has been successfully injected, and if similar predictions for other subjects have not changed. Here we argue that such evaluation is limited, since injecting one fact (e.g., “Jack Depp is the son of Johnny Depp”) introduces a “ripple effect” in the form of additional facts that the model needs to update (e.g., “Jack Depp is the sibling of Lily-Rose Depp”). To address this, we propose novel evaluation criteria that consider the implications of an edit on related facts. Using these criteria, we then construct RippleEdits, a diagnostic benchmark of 5K factual edits, capturing various types of ripple effects. We evaluate prominent editing methods on RippleEdits, showing that they fail to introduce consistent changes in the model’s knowledge. In addition, we find that a simple in-context editing baseline obtains the best scores on our benchmark, suggesting a promising research direction for model editing.1

## introduction modern language models (lms) capture a large volume of factual knowledge in their parameters, which can be effectively utilized in downstream tasks @xcite @xcite @xcite @xcite . however, factual beliefs captured by the model may be incorrect or become outdated over time, potentially affecting the model's performance on downstream tasks, its reliability, and its usability @xcite @xcite . this limitation has prompted research on knowledge editing (ke) methods, which modify lms to fix their factual errors (we provide a formal definition in §2). knowledge editing work has focused on applying factual updates to lms. given an entity-relation-object triplet (e, r, o) representing a fact (e.g., ''lionel messi plays for the inter miami team''), recent work proposed various methods @xcite @xcite @xcite to inject this fact into the parameters of a given lm, while ''overriding'' beliefs the model might have on e and r (e.g., that messi plays for paris saint-germain). a key question with ke is how to evaluate the success of such editing operations. the most basic ''sanity-check'' is that the model correctly completes (e, r, ?), as well as other paraphrases of this task, with o. however, this is not enough as an evaluation, since one needs to check that the model did not distort other facts. indeed, the standard evaluation protocol @xcite @xcite for ke focuses on these two aspects of correctly completing various paraphrases of the new fact, as well as ensuring that other unrelated facts have not been changed. in this work, we argue that to evaluate model edits, one should go beyond the single fact that was edited and check that other facts that are logically derived from the edit were also changed accordingly. for example, if z is the mother of e, then the children of z are the siblings of e. consequently, once we modify the belief of a certain model that @xmath0, then we should also ensure that the model's belief regarding the siblings of e is also correct. figure 1 illustrates another example, where editing the team for which lionel messi plays modifies other related facts, such as his country of residence, while other facts figure 1 : illustration of the evaluation scope of rippleedits, compared to existing knowledge editing benchmarks. for a given factual edit, we consider the ''ripple effect'' of the edit on the model's knowledge. to account for ripple effects in the evaluation of factual edits, we propose six concrete evaluation criteria (see §3, figure 2 ), for testing which facts other than the edit itself should be modified or retained post-editing. our tests evaluate how well the model integrates the edit with the rest of its knowledge, through queries that involve logical reasoning, complex composition of facts with the edit as an intermediate step, subject aliasing, and specificity across relations. building upon these criteria, we create rippleedits, a new benchmark for comprehensive evaluation of ke of lms (see §4). rippleedits includes 5k entries, each consisting of a factual edit, along with a set of test queries that check if the edit was successful in terms of its ripple effect. moreover, rippleedits contains meta-data for each edit, including information about the timestamp of the edit (i.e., recent versus old), and the popularity of the entities (i.e., head versus tail). we use rippleedits to evaluate three popular editing methods on five recent strong lms (see §5). we find that, even though current ke methods are effective in modifying a particular fact, they often fail to capture the ripple effects entailed by that fact, and demonstrate poor performance on most of our evaluation criteria. moreover, analyzing how editing performance varies across model sizes and entity frequencies, we find that (a) larger models handle ripple effects better, and (b) editing frequent entities results in more logical reasoning errors. last, we consider a simple in-context editing baseline for ke that leverages the casual attention mechanism rather than explicit parametric updates. while this method achieves the best results on our benchmark, outperforming current parametric ke methods, there is still ample room for improvement that calls for future research. to conclude, our work makes multiple contributions: (a) it highlights key limitations of ke evaluation, specifically regarding ripple effects and introduces comprehensive evaluation criteria to mitigate those limitations, (b) it proposes rippleedits, a benchmark inspired by these criteria, (c) it evaluates current methods for ke and shows that they do not perform well on this task, while demonstrating that in-context editing is a promising direction for ke. we release rippleedits and our code to facilitate future work on ke. ## problem setting we consider editing of factual knowledge, where facts are expressed as triplets (e, r, o) of a subject entity e (e.g., lionel messi), a relation r (e.g., team), and an object o (e.g., inter miami). we distinguish between two edit types, based on the knowledge encoded in the model before the edit: (a) modification of a fact that is already encoded in the model (e, r, o) → (e, r, o * ), that is, updating the object @xmath1, and (b) injection of a new fact (e, r, o * ) that is not captured by the model. moreover, we note that for one-to-one relations like date of birth, where there is a single object for a given subject, an injection edit can be viewed as populating an empty object (e, r, ∅) → (e, r, o * ). in contrast, for one-to-many relations, such as sibling and occupation, an injection edit augments the set of objects (e, r, for logical generalization (a), the additional fact that needs to be inserted to the knowledge graph (kg) is presented with an edit sign next to the relation. we show the same node in different colors for completeness, as the tested subject is also the object in the edit that needs to be inserted. for compositionality i, ii (b, c), the model needs to hop over the edit to arrive at the target. in subject aliasing (d) we verify the edit also propagates to paraphrases of the input. in preservation (e), we verify that other targets of the edited subject-relation are preserved. in relation specificity, we verify other relations for the subject are not modified. {o 1 , .., o n }) → (e, r, {o 1 , .., o n , o * }). whether an edit is viewed as a modification or injection, depends on whether that information was captured in the model before the edit. moreover, evaluating if a specific fact (before or after an edit) is encoded by a model is typically done by testing if the model predicts the object for various input queries that represent the subject and relation (see more details in §3.2). ## ripple effects of factual edits we focus on evaluating the downstream effect of a given edit, i.e., given an edit (e, r, o) → (e, r, o ), we expect certain facts related to the edit to change as well. consider, for example, the edit shown in figure 1 . changing the team for which messi plays might also affect the league he plays in and his country of residence. formally, for a given model, assume a knowledge-graph k := {(e i , r i , o i )} n @xmath2, representing the model's knowledge, and let δ : (e, r, o) → (e, r, o ) be an edit request for k. we define the ripple effect of δ on k, as the set of triplets r(δ) that the model implicitly needs to inject, modify, or delete from k to reflect the world state after the edit. notably, different edits can cause ripple effects of varying magnitudes. for example, changing the country of rome from italy to france, will entail many follow-up changes, such as the country in which the colosseum is located, the language spoken in rome, and so forth. in contrast, updating the siblings of prince (figure 2 ) is both more realistic and should result in a more local effect. we refer to the number of facts affected by a single edit δ (i.e., |r(δ)|) as its severity. in general, editing popular entities that appeared frequently during training is likely to introduce more changes, and thus, editing their properties has a higher severity. ## the rippleedits benchmark in this section, we describe a data generation pipeline ( §4.1) for factual edit requests and queries for evaluating their ripple effects. then, we apply our pipeline to create the rippleedits benchmark for comprehensive ke evaluation ( §4.2), and validate the quality of the data ( §4.3). ## experiments we use rippleedits to evaluate recent ke methods, and show that despite substantial progress on existing benchmarks, current methods struggle to introduce consistent changes to the model's knowledge after an edit. moreover, a simple incontext editing baseline that conditions the generation on the edited fact obtains better results, while leaving ample room for improvement for future research. ## conclusion and discussion we introduce the notion of ripple effects in knowledge editing, suggesting that editing a particular fact implies further updates of related facts. we additionally propose evaluation criteria for ripple effects and create rippleedits, a diagnostic benchmark designed to evaluate how well ke methods handle the ripple effects of various edits. we evaluate prominent ke methods and show that they often fail to introduce consistent edits that capture the ripple effects of an edit, suggesting that future development of ke methods should consider those effects more carefully. last, we show that a simple in-context editing method achieves the best results on rippleedits, highlighting the potential of such editing approaches. notably, our benchmark covers a small fraction of all possible ripple-edits. for example, one could consider ripple effects that involve more than two hops, and explore the graph structure of different edits. in addition, while we focus on ripple effects of single edits, future work can consider the effect of editing multiple facts in a single batch. finally, it would be interesting to consider cases where models succeed in capturing ripple-edits, and analyze how these are implemented mechanistically in the transformer architecture @xcite . limitations our data generation pipeline relies on information from an existing knowledge-base (wikidata in our case), which could be incomplete or outdated. while rippleedits does not aim to cover all the possible ripple-edits in wiki-data, these concerns might be a major issue when seeking a comprehensive evaluation or considering domain-specific knowledge-bases, which often tend to be incomplete. a possible solution to explore in that case is to use lms internal knowledge instead of an external knowledge-base @xcite . with rippleedits focusing on the ripple effect of edits, it does not include tests, such as paraphrasing of the edit and subject specificity, that evaluate the edit itself and are covered by existing benchmarks (e.g., counterfact). in addition, it does not verify that many other facts that are distantly related to the edit, i.e., triplets that are not included in the close neighbourhood of the edit, were retained post-editing. for example, we expect that editing the capital of france would not affect the population of poland, yet this is not explicitly checked. we note that building such an evaluation is hard, since there are many facts to consider and it is unclear how to determine automatically which triplets should and should not be affected by a certain edit.