# Fixing Model Bugs with Natural Language Patches

Shikhar Murty$\dagger\star$ Christopher D. Manning$\dagger$ Scott
Lundberg$\ddagger$ Marco Tulio Ribeiro$\ddagger$
$\dagger$Computer Science Department, Stanford University $\ddagger$Microsoft
Research
<EMAIL_ADDRESS>{scott.lundberg<EMAIL_ADDRESS>
###### Abstract

Current approaches for fixing systematic problems in NLP models (e.g., regex
patches, finetuning on more data) are either brittle, or labor-intensive and
liable to shortcuts. In contrast, humans often provide corrections to each
other through natural language. Taking inspiration from this, we explore
_natural language patches_ —declarative statements that allow developers to
provide corrective feedback at the right level of abstraction, either
overriding the model (“if a review gives 2 stars, the sentiment is negative”)
or providing additional information the model may lack (“if something is
described as the bomb, then it is good”). We model the task of determining if
a patch applies separately from the task of integrating patch information, and
show that with a small amount of synthetic data, we can teach models to
effectively use real patches on real data—1 to 7 patches improve accuracy by
~1–4 accuracy points on different slices of a sentiment analysis dataset, and
F1 by 7 points on a relation extraction dataset. Finally, we show that
finetuning on as many as 100 labeled examples may be needed to match the
performance of a small set of language patches.

††$\star$ Part of the work done at Microsoft Research.

##  1 Introduction

(a) Developer identifies bugs in model

(b) Incorporating Language Patches

Figure 1: (1(a)) Developers typically fix bugs by writing brittle regex
patches or by finetuning on additional data, which is prone to simple
shortcuts. In contrast, natural language patches are more expressive than
regexes and prevent shortcuts by abstractly specifying when they should be
applied. (1(b)) Our proposed model uses a gating head to predict whether a
patch condition $c$ applies to the input. That (soft) prediction is then used
to combine the original model output with the output of an interpreter head
that uses textual features from both the input as well as the patch consequent
$q$.

Natural language enables humans to communicate a lot at once with shared
abstractions. For example, in teaching someone about the colloquial use of the
term “bomb”, we might say describing food as ‘bomb’ means it is very good,
while saying someone bombed means it was disappointing. This simple sentence
uses various abstractions (e.g., “food”) to provide context-dependent
information, making it easy for humans to generalize and understand sentences
such as “The tacos were bomb” or “The chef bombed” without ever having seen
such examples.

There is a growing body of research focused on using language to give
instructions, supervision and even inductive biases to models instead of
relying exclusively on labeled examples, e.g., building neural representations
from language descriptions (Andreas et al., 2018; Murty et al., 2020; Mu et
al., 2020), or language / prompt-based zero-shot learning (Brown et al., 2020;
Hanjie et al., 2022; Chen et al., 2021). However, language is yet to be
successfully applied for _corrective_ purposes, where the user interacts with
an existing model to improve it. As shown in Fig. 1(a), if a developer
discovers that a model contains bugs (i.e., systematic errors; Ribeiro et al.,
2020), common fixes are either brittle regex-based patches (e.g., Fig. 1(a)
left, where patches either override predictions or replace the word “bomb”
with the word “good”), or collecting hundreds of additional datapoints for
finetuning, a tedious and computationally demanding process that can still
lead to shortcuts such as assuming the word “bomb” is always positive (e.g.,
if the additional finetuning data mostly has the word in its colloquial
sense). Instead, we envision a setting where developers provide corrective
feedback through a _Natural Language Patch_ —a concise statement such as “If
food is described as bomb, then food is good”. Language makes it easy for
developers to express feedback at the right level of abstraction without
having to specify exactly how the condition is applied. The patching system is
responsible for applying the patch and integrating the information
appropriately, e.g., applying it to “The tacos were the bomb” but not to “The
authorities found a bomb in the restaurant”.

In this work, we present an approach for patching neural models with natural
language. Any patching system has to determine when a patch is relevant, and
how it should modify model behavior. We model these tasks separately (Fig.
1(b)): a _gating_ head soft-predicts whether the patch should be applied
(e.g., “food is described as bomb”), and an _interpreter_ head predicts a new
output by combining the information in the patch (e.g., “food is good”) with
the original input. Both heads are trained on _synthetic data_ in a _patch
tuning_ stage between training and deployment, such that new patches can be
combined into a library of patches (or maybe various user-specific libraries),
and applied at test-time without further training. In addition to the
expressivity provided by abstractions, language-based patching is
_lightweight_ , _iterative_ and easily _reversible_. Much like software,
developers can write / edit / remove patches iteratively until errors on unit
tests or validation data are fixed, without constantly retraining the model.

Our experiments are organized as follows. First, in Section 5, we present
controlled experiments that indicate these patches work even for _abstract_
conditions, where regex patches would be infeasible or very difficult—that is,
they are applied correctly when the patch condition is met, and do nothing
otherwise. Perhaps surprisingly, this is true even for test-time patches that
are very different than the ones used in the patch finetuning stage. Next, in
Section 6, we show that despite the synthetic nature of the patch tuning
phase, a small set of very simple patches can fix bugs (and thus improve
performance) on real benchmarks for two different tasks—1 to 6 simple language
patches improve performance by ~1–4 accuracy points on two slices from the
Yelp reviews dataset, while 7 patches improve performance by ~7 F1 points on a
relation extraction task derived from NYT. Finally, in Section 7.2, we compare
language patching, a computationally _lightweight_ procedure, with finetuning,
a computationally and human-labor _intensive_ procedure, and find that as many
as 100 labeled examples are needed to match performance gains from a small set
of 1 to 7 patches. Further, finetuning sometimes fixes bugs at the expense of
introducing new bugs, while patches maintain prior performance on inputs where
they do not apply.

##  2 Natural Language Patching

#### Setup.

We are given a model $f$, mapping an input text $x$ to a probability
distribution over its output space, $f(x)=\Pr(y\mid x)$. The model contains
_bugs_ —defined as behaviors inconsistent with users’ preferences or the
“ground truth”— which we want to fix with a library of patches
$P=\\{lp_{1},lp_{2},\ldots,lp_{t}\\}$. Users explicitly indicate the condition
under which each patch applies and the consequence of applying it, such that
each patch is in the form “If (condition) $c$, then (consequence) $q$”. We use
this format to make modeling easier, noting that it still allows for very
flexible patching through high level abstractions (e.g., “if the customer
complains about the ambience”, “if food is not mentioned”, etc), and that most
patches have an implicit applicability function, and thus can be converted to
this format.

|  Template | Examples
---|---|---
Patches |  Override: If aspect is good, then label is positive |  $e_{0}$: If service is good, then label is positive $e_{1}$: If food is good, then label is positive
Override: If aspect is bad, then label is negative |  $e_{2}$: If service is bad, then label is negative $e_{3}$: If ambience is bad then label is negative
Override: If review contains words like word, then label is positive |  $e_{4}$: If review contains words like zubin, then label is positive $e_{5}$: If review contains words like excellent, then label is positive
Override: If review contains words like word, then label is negative |  $e_{6}$: If review contains words like wug, then label is negative $e_{7}$: If review contains words like really bad, then label is negative
Feature Based: If aspect is described as word, then aspect is good / bad |  $e_{8}$: If food is described as above average, then food is good $e_{9}$: If food is described as wug, then food is bad $e_{10}$: If food is described as zubin, then service is good $e_{11}$: If service is described as not great, then service is bad
Inputs |  The aspect at the restaurant was adj |  The service at the restaurant was really good. $e_{0}$, $e_{3}$ The food at the restaurant was wug. $e_{6}$, $e_{9}$
The restaurant had adj aspect |  The restaurant had really bad service. $e_{7}$, $e_{2}$, $e_{11}$ The restaurant had zubin ambience. $e_{4}$, $e_{10}$
The aspect1 was adj1, the aspect2 was adj2 |  The food was good, the ambience was bad. $e_{1}$, $e_{3}$, $e_{1}$ The service was good, the food was not good. $e_{0}$, $e_{1}$
The aspect1 was adj1 but the aspect2 was really adj2 |  The food was good, but the service was really bad. $e_{7}$, $e_{1}$, $e_{0}$ The ambience was bad, but the food was really not wug. $e_{3}$, $e_{9}$
The aspect1 was really adj1 even though aspect2 was adj2 |  The food was really bad even though the ambience was excellent. $e_{5}$, $e_{7}$, $e_{8}$ The food was really zubin, even though the service was bad $e_{4}$, $e_{10}$, $e_{0}$
Table 1: Patch and Input templates used for the Patch Finetuning stage for the
sentiment analysis task. We divide our patches into 2 categories: _Override_
and _Feature Based_ (see Section 2 for more details). For each input, we
provide examples of patches that apply and patches that don’t apply. The
simplistic nature of these templates makes them easy to write without access
to additional data sources or lexicons.

#### Applying Patches.

As indicated in Fig. 1(b), our model consists of two separate heads. The
gating head $g$ computes the probability that the condition specified by
$lp=(c,q)$ is true for a given input $x$ as $g(x,c)$. The interpreter head
$\mathcal{I}$ computes a new distribution over the label space, that
conditions on $x$ _and_ the consequence $q$. This is then combined with the
original model output $f(x)$ using the above gating probability. A single
patch $lp=(c,q)$, can be applied to any input $x$ as

Fix($f$, $x$, $lp$) $\displaystyle=g(x,c)\cdot\mathcal{I}(x,q)$ (1)
$\displaystyle+[1-g(x,c)]\cdot f(x).$

Given a library of patches $P=\\{lp_{1},\ldots,lp_{t}\\}$, we find the most
relevant patch $lp^{*}$ for the given input, and use that to update the model,

$\displaystyle lp^{*}$ $\displaystyle=\operatorname*{arg\,max}_{lp_{i}\in
P}g(x,c_{i}),$ (2) Fix($f$, $x$, $P$) $\displaystyle=\text{{{Fix}}{($f$, $x$,
$lp^{*}$)}}.$ (3)

#### Patch Types.

We consider two categories of patches (examples in Table 1). Override patches
are of the form “If cond, then label is $l$” i.e., they override the model’s
prediction on an input if the patch condition is true. For these patches, we
do not use the interpreter head since $\mathcal{I}(x,\text{``label is
$l$''})=l$. Feature-based patches are of the form “If cond, then feature”,
i.e., they provide the model with a contextual feature “hint” in natural
language, e.g., in Fig. 3 the feature is “food is good”. For these patches,
the model needs to integrate the hints with the original data, and thus both
the gating and interpreter heads are used.

##  3 Training Patchable Models

Assuming $f$ has a text encoder and a classification head, we have two
finetuning stages. In the Task Finetuning stage, we train $f$ on a labeled
dataset $\\{x_{i},y_{i}\\}$ (standard supervised learning). In the Patch
Finetuning stage, we use the learnt encoder and learn $g$ (initialized
randomly) and $\mathcal{I}$ (initialized with the classification head). For
the patch finetuning stage, we write a small set of patch templates covering
the kinds of patches users may write for their own application (see Table 1
for the patch templates used for our sentiment analysis results). Based on
these templates, we instantiate a small number of patches along with synthetic
labeled examples. This gives us a dataset $\\{x_{i},y_{i},lp_{i}\\}$, where
$lp_{i}$ consists of a condition $c_{i}$ as well as a consequence $q_{i}$. The
interpreter head $\mathcal{I}$ is trained to model $\Pr(y_{i}\mid
x_{i},q_{i})$ through standard log-likelihood maximization. The gating head
$g$ is trained via noise contrastive estimation to maximize

$\displaystyle\log g(x_{i},c_{i})-\sum_{c_{j}\in\textsc{neg}(x_{i})}\log
g(x_{i},c_{j}),$ (4)

where $\textsc{neg}(x_{i})$ is a randomly sampled set of negative conditions
for $x_{i}$.

(a)

(b)

Figure 2: A model can learn from just the labels that “yummy” and “greasy” are
positive and negative words respectively, and learn to perfectly fit training
data without ever using patch features (2(a), top). This behavior can be
explicitly prevented via EITs (2(a), bottom). A model may also fit the data
without using the input features by always predicting 1 / 0 for “food is good”
/ “food is bad” (2(a), top/bottom). Thus, we additionally ensure that the
label cannot be inferred from the patch alone (2(b)).

#### Entropy Increasing Transformations.

Patch Finetuning will fail if the synthetic data can be fit by a model that
ignores the input or the patch (Fig. 2(a)). Thus, to ensure our model cannot
fit the synthetic data without combining patch features with inputs, we
perturb the inputs with _Entropy Increasing Transformations_ (EITs). We
identify words from the input template for which the patch supplies additional
information e.g., aspect adjectives, relationship between entities, and
transform these into a small set of _nonce_ words. Crucially, the meanings of
these nonce words vary from example to example, and can only be inferred from
the patch (Fig. 2(a) bottom; more examples in Appendix A.2). Intuitively, the
transformations inject an additional source of randomness which can only be
recovered via the patch features. Such transformations are also used in
Rajendran et al. (2020) in the context of meta-learning. EITs alone do not fix
the failure mode where the model can fit the data without using input features
at all. For example, in Fig. 2(a) bottom, the model might learn a shortcut so
that it always predicts 1/0 for “food is good” / “food is bad”, regardless of
the input. Thus, in addition to EITs, to ensure that the model uses input
features, we ensure that a given patch consequence $q$ and the target label
are independent (Fig. 2(b)).

##  4 Experimental Setup

#### Applications.

We apply our method to binary sentiment analysis and relation extraction. For
sentiment analysis, our task finetuning data comes from SST2 Socher et al.
(2013). For relation extraction, we use the Spouse dataset (Hancock et al.,
2018) for task finetuning, where the objective is to determine whether two
entities are married or not given a textual context about them.

#### Model.

We use T5-large (Raffel et al., 2019) as implemented in the transformers
library (Wolf et al., 2020) for all experiments. Both the gating and
interpreter heads are separate decoders learnt on top of a shared encoder and
each of these components are initialized with the corresponding T5 pre-trained
weights. To prevent catastrophic forgetting on the original task during patch
finetuning, we also multi-task learn the patch finetuning loss along with the
original task loss. Templates for generating patches for patch finetuning are
in Table 1 for sentiment analysis and in Table 9 ( Section A.2) for relation
extraction. We train separate models for override and feature-based patches
(the former does not need an interpreter head). When using a patch, its
content (either $c$ for the gating head or $q$ for the interpreter head) is
inserted in the beginning of the input with a separator as in Fig. 1(b).

#### Baselines.

We report performance of the original model with only task finetuning (Orig)
and the model obtained after patch finetuning (Orig+PF) without using any
patches, to isolate the gains of language patches from those induced by
training on additional synthetic data. We also report results obtained from
prompting Orig with our patches (Prompt), i.e., inserting the patch text
before the input text to see how well finetuned T5 follows instructions. To
use multiple patches for this baseline, we prompt the model with each
individual patch and ensemble results with majority voting. Finally, we
experiment with _regex-based_ patches (Regex) where patch conditions are
converted to regex rules and consequents are converted into functions
$\operatorname*{Rule}_{q}(x)$. For override patches, this function simply
outputs the specified label. For sentiment analysis, where feature based
patches supply contextual meanings, $\operatorname*{Rule}_{q}(x)$ replaces
words with specified meanings e.g., replacing “bomb” with “good” in “the food
was bomb”. For feature based patches on relation extraction,
$\operatorname*{Rule}_{q}(x)$ appends the patch consequent to the input text.

##  5 Controlled Experiments

Figure 3: (a) Example patches used for our controlled experiments. (b) Some
inputs where the patch is important for making correct predictions. (c) To
control for spurious behaviors such as copying label words from the patch,
performing simple string lookups or affecting predictions when patch features
are unimportant, we also construct invariance tests where we expect model
predictions to be unaffected by the patch.

We test the behavior of language patches (and baselines) under different
controlled conditions with CheckList Ribeiro et al. (2020). Patches and
example inputs are presented in Fig. 3. We test cases where patches apply _and
are relevant_ for predictions, and corresponding cases where they either do
not apply or are not relevant. Thus, models that rely on shortcuts such as
copying the label word from the patch or merely performing token matching
perform poorly on the CheckList.

For sentiment analysis, we test Override patches with _abstract_ conditions
(e.g., “If _food_ is described as weird, then label is negative” ) on various
concrete instantiations such as “The _pizza_ at the restaurant was weird”. We
also construct invariance tests (O-Inv), where adding such patches should not
change predictions on inputs where the condition is false (e.g., “The waiter
was weird”, “The tacos were not weird”). We also construct tests for feature-
based patches (Feat) where patches provide meaning for nonce adjectives, with
analogous invariance tests (Feat-Inv). Finally, we construct analogous tests
for relation extraction, where patches fill in _reasoning gaps_ in the model
such as “If Entity1 gave Entity2 a ring, then Entity1 and Entity2 are
engaged”.

We present the results in Table 2, where we first note that Orig+PF does not
perform well overall, and thus patching improvements are not merely a result
of the additional synthetic data. Regex cannot handle abstract conditions, and
thus (as expected) does not change predictions on sentiment analysis, and does
not do well on relation extraction. While merely inserting the patch into the
input (Prompt) results in some gains when the patch applies, it does so at the
cost of changing predictions when the patch does not apply (O-Inv and Feat-
Inv). In contrast to baselines, our method is able to apply _abstract_ patches
correctly on concrete instantiations, disregarding them when they do not
apply, without relying on shortcuts such as copying the label from the
consequent or merely checking for matching words between patch and input (all
of which are tested by the invariance tests).

Model | Sentiment Analysis |  | Relation Extraction
---|---|---|---
Override | O-Inv | Feat | Feat-Inv |  | Feat | Feat-Inv
Orig | 50.0 | n/a | 59.1 | n/a |  | 14.5 | n/a
Orig+PF | 50.0 | n/a | 59.9 | n/a |  | 35.8 | n/a
Regex | 50.0 | 100.0 | 59.9 | 100.0 |  | 45.8 | 88.1
Prompt | 68.7 | 63.8 | 64.3 | 85.4 |  | 13.9 | 87.6
Patched | 100.0 | 100.0 | 100.0 | 100.0 |  | 47.2 | 92.6
Table 2: Applying patches on CheckLists. We see significant improvements when
the patches apply and invariances when they do not apply or are unimportant.
For Sentiment Analysis, the datasets are designed to evaluate patching with
abstract conditions, thus we see no effects from using regex based patches.
For testing invariance, we report the percentage of inputs for which the
prediction did not change w.r.t. the base model.

##  6 Patching models on real benchmarks

###  6.1 Sentiment Analysis

Unless noted otherwise, all datasets in this subsection are derived from Yelp
Review (Zhang et al., 2015). To fix errors on low-accuracy slices, we write
patches by inspecting a random subset of 10-20 errors made by Orig+PF.

#### Controlling the model.

In order to check if patches can control model behavior with abstract
conditions “in the wild”, we manually annotate a random subset of 500 reviews
with food and service specific sentiment (“The food was good, service not so
much” is labeled as service: 0, food: 1). We then construct override patches
of the form “if food / service is good / bad, then label is positive /
negative”, and evaluate models as to how often (on average) the prediction is
as expected when the patch applies and how often it is unchanged when the
patch does not apply. We present results in Table 3. The sentiment of both
aspects typically agrees, and thus even models without patching often behave
according to the patch. We note that natural language patches improve patched
behavior the most (when compared to baselines), while almost never changing
predictions when the patch does not apply. We additionally present results
only on the subset of our aspect annotated examples where both aspects
_disagree_ in Table 4. Overall, we see a more pronounced difference i.e., our
model gets a ~27 point boost in accuracy when the patch condition applies,
while maintaining invariance when the condition does not apply.

Model | Correctly patched (applies) | Invariance (does not apply)
---|---|---
Orig | 91.5 | n/a
Orig+PF | 91.1 | n/a
Regex | 91.0 | 99.5
Prompt | 92.3 | 98.4
Patched | 95.8 | 99.4
|  |
Table 3: To measure how well patches control behavior “in the wild”, we evaluate the model’s ability to match the label specified by the patch when it applies, and invariance w.r.t the base model when the patch does not apply, on a subset of yelp with sentiment annotations for different aspects Model | Correctly patched (applies) | Invariance (does not apply)
---|---|---
Orig | 52.1 | n/a
Prompt | 55.7 | 97.6
Orig+PF | 53.5 | n/a
Regex | 55.1 | 100.0
Patched | 79.6 | 99.4
|  |
Table 4:  We evaluate the model’s ability to match the label specified by the
patch when it applies, and invariance w.r.t the base model when the patch does
not apply, on a subset of yelp with sentiment annotations for different
aspects. In this table, we specifically consider inputs where both food and
service aspects differ in sentiment.

#### Patching low-accuracy slices.

We identify slices where our base model has (comparatively) low accuracy, and
check whether patches can improve performance. Yelp-stars consists of all
examples in Yelp Review with the word ‘star’ present. For this subset, we use
two overrides patch: “If review gives 1 or 2 stars, then label is negative”,
“If review gives 0 stars, then label is negative”. Yelp-Colloquial is a label-
balanced slice consisting of examples having the colloquial terms {dope, wtf,
omg, the shit, bomb, suck}. Because the colloquial use of these terms depends
on context, we further construct Yelp-Colloquial-Control, a CheckList where
the same terms are used in their traditional sense (e.g., “The manager was a
dope”, “The bomb was found by the police at the restaurant”). A model can do
well on both of these datasets simultaneously only if it understands the
contextual nuance associated with colloquial terms, rather than relying on
simple shortcuts such as equating “bomb” with “good”. For these datasets, we
write simple feature-based patches such as “If food is described as bomb, then
food is good” for each term. Finally, we use the “Women’s E-commerce Clothing
Reviews” dataset (WCR) from Zhong et al. (2021) and add two override patches:
“If review mentions phrases like needs to be returned, then label is
negative”, and “If fit is boxy, then label is negative”.

In Table 5, we observe that a very small number of language patches improve
performance by 0.5-4.1 accuracy points, always outperforming both the original
model and baselines. These gains are not a result of the added synthetic data,
as Orig+PF often _lowers_ performance. Qualitatively, Prompt tends to rely on
shortcuts such as copying over the label in the patch rather than gating and
integrating the information, while Regex cannot deal with simple semantic
understanding, e.g., the rule on Yelp-stars fires for “Will deduct 1 star for
the service but otherwise everything was excellent”, leading to an incorrect
patch application. Natural language patches avoid both of these pitfalls by
explicitly modeling gating and feature interpretation with learnt models.

Model | Yelp-Stars | Yelp-Colloquial | Yelp-Colloquial-Control | WCR
---|---|---|---|---
Orig | 93.1 | 89.1 | 100.0 | 89.6
Orig+PF | 93.6 | 88.6 | 100.0 | 88.9
Regex | 92.7 | 91.9 | 88.1 | 90.0
Prompt | 90.8 | 85.2 | 70.1 | 88.3
Patched | 94.5 | 93.2 | 100.0 | 90.1
Table 5: Using Override and Feature Based patches to fix bugs on various
benchmarks derived from real sentiment analysis datasets. For Yelp-Colloquial,
we also generate an control test based on CheckList.

###  6.2 Spouse Relation Extraction

We construct Spouse-FewRel, an out-of-distribution test benchmark derived from
FewRel Gao et al. (2019) by sampling from all relation types where at least
one of the entities is a person ($n=8400$), and labeling examples as positive
if they have the Spouse relation, negative otherwise. We inspect 20 randomly
sampled errors made by Orig+PF on Spouse-FewRel, and observe that the model
often confuses “Entity1 has a child with Entity2” with ”Entity1 is the child
of Entity2”, and also misclassifies widowhood as negative. Thus, we write
override patches for both of these error categories, resulting in 7 patches,
presented in Table 6. Using all patches, we observe a ~7.4 point F1
improvement over Orig, while baselines either decrease F1 or barely improve
it.

We highlight in Table 6 a phenomenon where each natural language patch in
_isolation_ decreases performance, while all patches together increase
performance. Further analysis reveals that this is because the gating head is
not well calibrated in this case, and thus individual patches are applied
incorrectly. However, the _comparative_ values of $g(x,c_{i})$ are often
ordered correctly, and thus a better patch is the one applied ($lp^{*}$ in Eq
2) when all patches are available. We do further analysis in Table 7, where we
report the _gating accuracy_ (i.e., whether the patch actually applies or not,
labeled manually) of $lp^{*}$ on the subset of inputs where the Patched model
changes the prediction (Diff), and where it changes the prediction to the
correct label (Diff $\cap$ Correct). With the caveat that patches are applied
softly (and thus perfect gating accuracy is not strictly necessary), we
observe that a few patches seem to hurt performance even in combination with
others (e.g., the first one). We also note that the patched model is right
_“for the right reasons”_ in over 72% of inputs where it changes the
prediction to the correct one.

| Model | F1
---|---|---
| Orig | 65.5
| Orig+PF | 61.4
| Regex | 61.0
| Prompt | 65.7
| Patched | 72.9
Using single patch | If $p_{2}$ is the son of $p_{1}$, then label is negative | 57.5
If $p_{1}$ is the son of $p_{2}$, then label is negative | 58.9
If $p_{1}$ and $p_{2}$ have a daughter, then label is positive | 61.9
If $p_{1}$ and $p_{2}$ have a son, then label is positive | 66.8
If $p_{1}$ is the widow of $p_{2}$, then label is positive | 63.6
If $p_{1}$ is the daughter of $p_{2}$, then label is negative | 50.7
If $p_{2}$ is the daughter of $p_{1}$, then label is negative | 49.4
Table 6: Using Override Patches on Spouse-FewRel for Spouse relation extraction. Patch Condition | Diff |  Diff $\cap$ Correct
---|---|---
$p_{2}$ is the son of $p_{1}$ | 0.0 | NaN (0/0)
$p_{1}$ is the son of $p_{2}$ | 75.0 | 75.0
$p_{1}$ and $p_{2}$ have a daughter | 63.3 | 93.8
$p_{1}$ and $p_{2}$ have a son | 78.1 | 98.3
$p_{1}$ is the widow of $p_{2}$ | 10.9 | 19.6
$p_{1}$ is the daughter of $p_{2}$ | 71.4 | 100.0
$p_{2}$ is the daughter of $p_{1}$ | 6.3 | 100.0
Overall | 42.9 | 72.3
Table 7: We measure how often the chosen patch correctly applies to an input
(i.e., gating accuracy) for Spouse-FewRel, for the set of inputs where the
patched model and original model differ (Diff) as well as the subset where the
patched model is correct (Diff $\cap$ Correct).

Figure 4: How many additional finetuning training examples it takes to reach
the same accuracy level as patching. We report the mean and standard
deviations across 5 runs.

##  7 Analysis

###  7.1 How Important are EITs?

Patch Consequent | Patched | Patched (Without EITs)
---|---|---
$p_{1}$ went on a honeymoon with $p_{2}$ | 59.1 | 33.7
$p_{1}$ has kids with $p_{2}$ | 75.2 | 74.4
$p_{1}$ is engaged to $p_{2}$ | 77.7 | 64.8
food is good | 67.8 | 54.2
food is bad | 88.7 | 56.5
service is good | 62.8 | 52.9
service is bad | 62.8 | 52.9
Overall | 70.6 | 55.6
Table 8: Patching Accuracy of a model with and without Entropy Increasing
Transformations (EITs).

The goal of Entropy Increasing Transformations (EITs; Section 3) is to prevent
the interpreter head from learning shortcuts that either ignore patch features
or rely exclusively on them. We perform an ablation, comparing our model to a
model trained without EITs on the CheckLists in Table 2 (Section 5), where the
feature-based patch consequent supplies important information for making a
correct prediction. From Table 8, we note that the interpreter head trained
without EITs has much lower performance on these datasets (as expected).

###  7.2 Comparison to fine-tuning

While patching is computationally lightweight, it requires domain knowledge or
error analysis of incorrectly labeled examples. However, once such analysis is
performed, one can label these additional examples and finetune the model on
them. Ignoring the computational and infrastructure costs of repeated
finetuning, for patching to be a competitive alternative to finetuning from an
_annotation budget_ perspective, we require the gains from patching to only be
matched by multiple labeled examples. To compare language patches with
finetuning, we consider Yelp-stars, Yelp-Colloquial, and Spouse-FewRel and
split each dataset into a training set with 128 examples, and a test set with
remaining examples. Next, we finetune Orig, on $k=\\{2,4,8,16,32,64,128\\}$
examples from the training set, stopping early if finetuning performance
exceeds patched performance. We finetune for 64 steps and optimize using AdamW
with a fixed learning rate of 1e-4. We report means and standard deviations
obtained from finetuning with 5 random seeds.

Results are presented in Fig. 4, where we note that over $100$ labeled
examples are needed to match the performance of a single patch on Yelp-Stars
or 7 patches on Spouse-FewRel. On Yelp-Colloquial, the patched performance is
matched with a mere $16$ examples. However, as noted earlier, Yelp-Colloquial
is susceptible to simple shortcuts, and we observe that the performance on the
control set Yelp-Colloquial-Control suffers significantly as we finetune on
more data (with very high variance). Thus, we conclude that language patches
on these datasets are not only very efficient in terms of annotation effort
(when compared to labeling data for finetuning), but also less susceptible to
simple shortcuts that do not address the problem at the right level of
abstraction.

##  8 Related Work

#### Learning with Language.

Natural language instructions or explanations have been used for training
fewshot image classifiers (Mu et al., 2020; Andreas et al., 2018), text
classifiers Zaidan and Eisner (2008); Srivastava et al. (2018); Camburu et al.
(2018); Hancock et al. (2018); Murty et al. (2020), and in the context of RL
(Branavan et al., 2012; Goyal et al., 2019; Co-Reyes et al., 2019; Mu et al.,
2022). All of these works are concerned with reducing labeled data
requirements with language supervision, while our setting involves using
language as a _corrective_ tool to fix bugs _at test time_.

#### Prompt Engineering.

An emerging technique for re-purposing language models for arbitrary
downstream tasks involves engineering “prompts”. Prompts are high level
natural language descriptions of tasks that allow developers to express any
task as language modeling (Brown et al., 2020; Gao et al., 2021; Zhong et al.,
2021). While we could try and directly use prompting to incorporate language
patches, our experiments show that the models we consider fail to correctly
utilize patches in the prompt (Section 4). With increasing scale models may
gain the ability to interpret patches zero-shot, but qualitative exploration
of the largest available models at the time of writing (e.g. GPT-3; Brown et
al., 2020) indicates they still suffer from the same problem. Using patches
for corrective purposes requires an accurate interpretation model, as well as
ignoring the patch when it is not applicable. We solve these challenges by
learning a gating head and an interpretation head through carefully
constructed synthetic data.

#### Editing Factual Knowledge.

Test time editing of factual knowledge in models is considered by Talmor et
al. (2020); Cao et al. (2021); Mitchell et al. (2021); Meng et al. (2022).
Instead of modifying factual knowledge, we show that _free-form language_
patches can be used to fix _bugs_ on real data, such as correctly interpreting
the meaning of the word “bomb” in the context of food or predicting that
divorced people are no longer married.

##  9 Conclusion

When faced with the task of fixing _bugs_ in trained models, developers often
resort to brittle regex rules or finetuning, which requires curation and
labeling of data, is computationally intensive, and susceptible to shortcuts.
This work proposes _natural language patches_ which are declarative statements
of the form “if $c$, then $q$” that enable developers to control the model or
supply additional information with conditions at the right level of
abstraction. We proposed an approach to patching that models the task of
determining if a patch applies (gating) separately from the task of
integrating the information (interpreting), and showed that this approach
results in significant improvements on two tasks, even with very few patches.
Moreover, we show that patches are efficient (1-7 patches are equivalent or
better than as many as $100$ finetuning examples), and more robust to
potential shortcuts. Our system is a first step in letting users _correct_
models through a _single step_ “dialogue”. Avenues for future work include
extending our approach to a back-and-forth dialogue between developers and
models, modeling pragmatics, interpreting several patches at once, and
automating patch finetuning.

##  10 Acknowledgements

SM was partly funded by a gift from Apple Inc. We are grateful to Jesse Mu,
Mirac Suzgun, Pratyusha Sharma, Eric Mitchell, Ashwin Paranjape, Tongshuang
Wu, Yilun Zhou and the anonymous reviewers for helpful comments. The authors
would also like to thank members of the Stanford NLP group and the Adaptive
Systems and Interaction group at MSR for feedback on early versions of this
work.

##  11 Reproducibility

Code and model checkpoints are available at
https://github.com/MurtyShikhar/LanguagePatching.

##  12 Limitations

#### Scaling to large patch libraries.

For our approach, inference time scales linearly with the size of the patch
library. This is primarily because the gating head makes predictions on each
patch in our patch library (Eq 2). Instead of running the gating head on each
patch, one can trade off exactness for efficiency, by running the gating head
on a much smaller candidate set identified using fast approximate nearest
neighbors (Johnson et al., 2019) on sentence embeddings.

#### Scaling to more patch types.

The current approach requires writing patch templates _beforehand_ based on
prior knowledge of the kinds of corrective feedback that developers might want
to write in the future. Writing patch templates manually is fundamentally
bottlenecked by human creativity and foresight. Morever, since humans are
required to write templates, it makes scaling up to different patch types
harder, since we expect generalization to completely new patch _types_ to be
poor e.g., generalizing to a patch that requires counting. Future work can
explore automatic generation of synthetic patch templates e.g., using pre-
trained language models.

#### Interpreting multiple patches.

Finally, the approach we develop can only incorporate a single patch at a
time, by selecting the most relevant patch from our patch library. This
precludes the model from being able to combine features from multiple
patches—e.g., “caviar is a kind of food” and “If caviar is described as
overpowering, then caviar is spoiled”.

## References

  * Andreas et al. (2018) Jacob Andreas, Dan Klein, and Sergey Levine. 2018.  Learning with latent language.  In _NAACL HLT 2018 - 2018 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies - Proceedings of the Conference_ , volume 1.
  * Branavan et al. (2012) S. R.K. Branavan, David Silver, and Regina Barzilay. 2012.  Learning to win by reading manuals in a monte-carlo framework.  _Journal of Artificial Intelligence Research_ , 43.
  * Brown et al. (2020) Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020.  Language models are few-shot learners.  _Advances in neural information processing systems_ , 33:1877–1901.
  * Camburu et al. (2018) Oana Maria Camburu, Tim Rocktäschel, Thomas Lukasiewicz, and Phil Blunsom. 2018\.  E-snli: Natural language inference with natural language explanations.  volume 2018-December.
  * Cao et al. (2021) Nicola De Cao, Wilker Aziz, and Ivan Titov. 2021.  Editing factual knowledge in language models.
  * Chen et al. (2021) Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harrison Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Joshua Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. 2021.  Evaluating large language models trained on code.  _CoRR_ , abs/2107.03374.
  * Co-Reyes et al. (2019) John D. Co-Reyes, Abhishek Gupta, Suvansh Sanjeev, Nick Altieri, Jacob Andreas, John DeNero, Pieter Abbeel, and Sergey Levine. 2019.  Guiding policies with language via meta-learning.
  * Gao et al. (2021) Tianyu Gao, Adam Fisch, and Danqi Chen. 2021.  Making pre-trained language models better few-shot learners.  In _Association for Computational Linguistics (ACL)_.
  * Gao et al. (2019) Tianyu Gao, Xu Han, Hao Zhu, Zhiyuan Liu, Peng Li, Maosong Sun, and Jie Zhou. 2019\.  FewRel 2.0: Towards more challenging few-shot relation classification.  In _Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP)_ , pages 6251–6256, Hong Kong, China. Association for Computational Linguistics.
  * Goyal et al. (2019) Prasoon Goyal, Scott Niekum, and Raymond J. Mooney. 2019.  Using natural language for reward shaping in reinforcement learning.  _CoRR_ , abs/1903.02020.
  * Hancock et al. (2018) Braden Hancock, Martin Bringmann, Paroma Varma, Percy Liang, Stephanie Wang, and Christopher Ré. 2018.  Training classifiers with natural language explanations.  volume 1.
  * Hanjie et al. (2022) Austin W Hanjie, Ameet Deshpande, and Karthik Narasimhan. 2022.  Semantic supervision: Enabling generalization over output spaces.  _arXiv preprint arXiv:2202.13100_.
  * Johnson et al. (2019) Jeff Johnson, Matthijs Douze, and Hervé Jégou. 2019.  Billion-scale similarity search with GPUs.  _IEEE Transactions on Big Data_ , 7(3):535–547.
  * Meng et al. (2022) Kevin Meng, David Bau, Alex Andonian, and Yonatan Belinkov. 2022.  Locating and editing factual knowledge in gpt.  _ArXiv_ , abs/2202.05262.
  * Mitchell et al. (2021) Eric Mitchell, Charles Lin, Antoine Bosselut, Chelsea Finn, and Christopher D Manning. 2021.  Fast model editing at scale.  _arXiv preprint arXiv:2110.11309_.
  * Mu et al. (2020) Jesse Mu, Percy Liang, and Noah Goodman. 2020.  Shaping visual representations with language for few-shot classification.
  * Mu et al. (2022) Jesse Mu, Victor Zhong, Roberta Raileanu, Minqi Jiang, Noah Goodman, Tim Rocktäschel, and Edward Grefenstette. 2022.  Improving intrinsic exploration with language abstractions.  _arXiv preprint arXiv:2202.08938_.
  * Murty et al. (2020) Shikhar Murty, Pang Wei Koh, and Percy Liang. 2020.  Expbert: Representation engineering with natural language explanations.
  * Raffel et al. (2019) Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. 2019.  Exploring the limits of transfer learning with a unified text-to-text transformer.  _CoRR_ , abs/1910.10683.
  * Rajendran et al. (2020) Janarthanan Rajendran, Alexander Irpan, and Eric Jang. 2020.  Meta-learning requires meta-augmentation.  In _Advances in Neural Information Processing Systems_ , volume 33, pages 5705–5715. Curran Associates, Inc.
  * Ribeiro et al. (2020) Marco Tulio Ribeiro, Tongshuang Wu, Carlos Guestrin, and Sameer Singh. 2020.  Beyond accuracy: Behavioral testing of NLP models with CheckList.  In _Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics_ , pages 4902–4912, Online. Association for Computational Linguistics.
  * Socher et al. (2013) Richard Socher, Alex Perelygin, Jean Wu, Jason Chuang, Christopher D. Manning, Andrew Ng, and Christopher Potts. 2013.  Recursive deep models for semantic compositionality over a sentiment treebank.  In _Proceedings of the 2013 Conference on Empirical Methods in Natural Language Processing_ , pages 1631–1642, Seattle, Washington, USA. Association for Computational Linguistics.
  * Srivastava et al. (2018) Shashank Srivastava, Igor Labutov, and Tom Mitchell. 2018.  Zero-shot learning of classifiers from natural language quantification.  volume 1.
  * Talmor et al. (2020) Alon Talmor, Oyvind Tafjord, Peter Clark, Yoav Goldberg, and Jonathan Berant. 2020\.  Leap-of-thought: Teaching pre-trained models to systematically reason over implicit knowledge.  volume 2020-December.
  * Wolf et al. (2020) Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Rémi Louf, Morgan Funtowicz, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gugger, Mariama Drame, Quentin Lhoest, and Alexander M. Rush. 2020.  Transformers: State-of-the-art natural language processing.  In _Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations_ , pages 38–45, Online. Association for Computational Linguistics.
  * Zaidan and Eisner (2008) Omar F. Zaidan and Jason Eisner. 2008.  Modeling annotators: A generative approach to learning from annotator rationales.
  * Zhang et al. (2015) Xiang Zhang, Junbo Zhao, and Yann LeCun. 2015.  Character-level Convolutional Networks for Text Classification.  _arXiv:1509.01626 [cs]_.
  * Zhong et al. (2021) Ruiqi Zhong, Kristy Lee, Zheng Zhang, and Dan Klein. 2021.  Meta-tuning language models to answer prompts better.  _CoRR_ , abs/2104.04670.

##  Appendix A More details on Patch Finetuning

###  A.1 Sentiment Analysis Data

The templates used for constructing inputs are in Table 12. We
programmatically find all patches for an input, to generate labels.

###  A.2 Relation Extraction Data

#### Override Patches.

Patches and Input templates for constructing patch finetuning data can be
found in Table 13.

#### Feature Based Patches

For training the gating head, we use the same data as generated by Table 13.
For training the interpreter head, we use patches and input templates in Table
11 to generate finetuning data.

###  A.3 Additional Finetuning Details

After the model is finetuned in the Task finetuning stage, we finetune it
additionally with a learning rate of learning rate of 1e-4 and with a linear
warmup scheduler which ramps up the learning rate from $0$ to 1e-4 over $100$
steps. The training batch size is $32$, and we clip gradients to have a max
norm of 5. We early stop based on validation performance on a held out subset
of the patch finetuning data.

Override Patches
---
If [ Entity1/ Entity2] is not a person, then label is negative
If Entity1 is the [child / parent] of Entity2, then label is negative
If Entity1 and Entity2 have children, then label is positive
If Entity1 and Entity2 are divorced, then label is negative
If Entity1 is engaged to Entity2, then label is positive
If Entity1 and Entity2 are siblings, then label is negative
Feature Based Patches
If cond, then Entity1 is [married/not married] to Entity2
If cond, then Entity1 is divorced from Entity2
If cond, then Entity1 is engaged to Entity2
If cond, then Entity1 is the sibling of Entity2
If cond, then Entity1 is dating Entity2
If cond, then Entity1 is the parent of Entity2
Table 9: Patch templates used for the Patch Finetuning stage for relation
extraction. Each Entity is sampled from a small list of names, and cond is a
set of conditions derived from keywords.

##  Appendix B Patches used for Yelp-Colloquial.

We used the following patches for fixing bugs on Yelp-Colloquial:

  * •

“If clothes are described as dope, then clothes are good.”

  * •

“If food is described as the shit, then food is good.”

  * •

“If service is described as bomb, then service is good.”

  * •

“If restaurant is described as bomb, then restaurant is good.”

  * •

“If food is described as bomb, then food is good.”

  * •

“If something is described as wtf, then something is bad.”

  * •

“If something is described as omg, then something is good.”

  * •

“If food is described as shitty, then food is bad.”

##  Appendix C More examples of Entropy Increasing Transformations

To perform Entropy Increasing Transformations (EITs) for relation extraction,
we convert rel (see Table 11 into nonce words $e.g.,{}$ “Alice has a kid with
John” gets transformed into “Alice has a wug with John”, for which we use a
patch “If Entity1 has a wug with Entity2, then Entity1 and Entity2 have kids

##  Appendix D Regex Based Patches.

The exact functions we use for patching with regexes can be found in Listing
13 and Listing 13.

##  Appendix E Data Statistics for all evaluation slices

Statistics for all slices used for evaluation can be found in Table 10.

Dataset | #examples
---|---
Yelp-Stars | 3172
Yelp-Colloquial | 1784
WCR | 2919
Yelp-Colloquial (Control) | 67
Yelp-Aspect | 439
Spouse-NYT | 8400
Table 10: Dataset statistics for all the real data slices considered in this
work. [ Entity1] [ rel] [ Entity2]
---
[ Entity1] [ rel] [ Entity2] and [ Entity1] is (not) married to [ Entity2]
[ Entity1] who [ rel] [ Entity2], [ rel2] [ Entity3]
rel = [have-kids, are-engaged, is-sibling, is-parent]
Entity = [Alice, Bob, Stephen, Mary]
Table 11: Templates used for constructing inputs for patch finetuning stage in
relation extraction analysis. Terms marked with ’()’ are optional. rel is a
list of 4 relation types. For each relation type, we have a small list of 3 to
4 words. For instance have-kids = [‘has a kid with’, ‘has a son with’, ‘has a
daughter with’] The [ aspect] at the restaurant was ( modifier) (not) [ adj]
---
The [ aspect] was ( modifier) (not) [ adj]
The restaurant [has/had] ( modifier) [ adj] [ aspect]
The [ aspect1] was (not) [ adj1], the [ aspect2] was (not) [ adj2]
The [ aspect1] was (not) [ adj1], but the [ aspect2] was (not) [ adj2]
The [ aspect1] was really (not) [ adj1], even though the [ aspect2] was (not)
[ adj2]
aspect = [food, service, ambience]
modifier = [really, surprising, quite]
Table 12: Templates used for constructing inputs for patch finetuning stage in sentiment analysis. Terms marked with ’()’ are optional. adj comes from a small set of 6 positive and 6 negative adjectives, as well as 6 nonce adjectives for EITs | Examples
---|---
Patches |  $e_{0}$: Entity1 divorced Entity2
$e_{1}$: Entity1 has kids with Entity2
$e_{2}$: Entity1 is the parent of Entity2
$e_{3}$: Entity1 and Entity2 are engaged
$e_{4}$: Entity1 and Entity2 are just friends or coworkers
$e_{5}$: Entity1 or Entity2 is not human
Inputs |  Entity1 and Entity2 have a kid named Person3. $e_{1}$, $e_{2}$ Entity1 and Entity2 have a kid named Person3. $e_{2}$, $e_{1}$
Entity1 proposed to Entity2. The event was witnessed by Entity1’s best friend
Person3. $e_{3}$, $e_{4}$ Entity1 proposed to Entity2. The event was witnessed
by Entity1’s best friend Person3. $e_{4}$, $e_{0}$
Entity1 has decided to divorce Entity2. They have a child named Person3.
$e_{0}$, $e_{3}$ Entity1 has decided to divorce Entity2. They have a child
named Person3. $e_{2}$, $e_{0}$
Entity1 works at location. $e_{5}$, $e_{0}$
Table 13: Patches along with a subset of inputs used for the Patch Finetuning
stage for the Spouse relation extraction task. For each input, we highlight
the two entities and provide examples of some positive and negative patches.

⬇

def star_rbpatch(model, inp):

keywords = [’ 0 star’, ’ 1 star’, ’ 2 star’,

’ zero star’, ’ one star’, ’ two star’]

patches = [(keyword, 0) for keyword in keywords]

return sentiment_override_rbpatch(model, inp, patches)

\par\pardef clothing_reviews_rbpatch(model, inp):

return sentiment_override_rbpatch(model, inp, [(’boxy’, 0), (’needs to be
returned’, 0)])

\par\pardef spousenyt(model, inp):

patch_list = [(’Entity1 is the son of Entity2’, 0),

(’Entity2 is the son of Entity1’, 0),

(’Entity1 and Entity2 have a son’, 1),

(’Entity1 and Entity2 have a daughter’, 1),

(’Entity1 is the daughter of Entity2’, 0),

(’Entity2 is the daughter of Entity1’, 0),

(’Entity1 is the widow of Entity2’, 1)]

return re_override_rbpatch(model, inp, patch_list)

\par\par\par# for all override patches

def sentiment_override_rbpatch(model, inp, patch_list):

”’

inp: "X" a review for which we want to predict sentiment

patch_list: list of override patches converted into a form (cond, label) where
cond is

a string condition and label is the associated binary label

”’

for cond, label in patch_list:

if cond in inp:

return label

return model(inp)

\par\par# for override patches for relation extraction

def re_override_rbpatch(model, inp, patch_list):

”’

inp: "X. Entity1: e1. Entity2: e2"

patch_list: list of override patches converted into a form (cond, label) where
cond is

a string condition and label is the associated binary label

”’

text, ent_info = inp.split(’ Entity1:’)

e1, e2 = ent_info.split(’. Entity2:’)

e1 = e1.strip()

e2 = e2.strip()

for cond, label in patch_list:

p = patch.replace(’Entity1’, e1).replace(’Entity2’, e2)

p2 = patch.replace(’Entity1’, ”).replace(’Entity2’, ”)

if p in inp:

return pred

elif p2 in inp:

return pred

return model(x)

\par

Rule based override patching for all our experiments

⬇

# Regex based patching for using feature based patches on

# controlled experiments for sentiment analysis

def sentiment_regex_based(model, inp, patch_list):

”’

inp: "X. Entity1: e1. Entity2: e2"

patch_list: list of feature patches of the form ’if aspect is word, then
aspect is good/ bad’

as a tuple (aspect, word, sentiment)

”’

\parfor aspect, word, sentiment in patch_list:

if ’{} is {}’.format(aspect, word) in inp:

inp = inp.replace(word, sentiment)

break

return model(inp)

\par\par\par\par# Regex based patching for controlled experiments on relation
extraction

def re_regex_based(model, inp, patch_list):

”’

inp: "X. Entity1: e1. Entity2: e2"

patch_list: list of feature patches converted into a form (cond, cons) where
cond

and cons are both strings

”’

text, ent_info = inp.split(’ Entity1:’)

e1, e2 = ent_info.split(’. Entity2:’)

e1 = e1.strip()

e2 = e2.strip()

for cond, cons in patch:

p = cond.replace(’Entity1’, e1).replace(’Entity2’, e2)

if p in inp:

cons_curr = cons.replace(’Entity1’, e1).replace(’Entity2’, e2)

inp = ’{}. {} Entity1: {}. Entity2: {}’.format(cons_curr, text, e1, e2)

break

return model(inp)

\par# Regex based patching on yelp colloquial

def yelp_col_regex_based(model, inp, patch_list):

if ’wtf’ in inp:

inp = inp.replace(’wtf’, ’bad’)

elif ’omg’ in inp:

inp = inp.replace(’omg’, ’good’)

elif ’the shit’ in inp:

inp = inp.replace(’the shit’, ’good’)

elif ’bomb’ in inp and ’food’ in inp:

inp = inp.replace(’bomb’, ’good’)

elif ’bomb’ in inp and ’service’ in inp:

inp = inp.replace(’bomb’, ’good’)

elif ’bomb’ in inp and ’restaurant’ in inp:

inp = inp.replace(’bomb’, ’good’)

elif ’dope’ in inp and ’clothes’ in inp:

inp = inp.replace(’dope’, ’good’)

elif ’sucks’ in inp:

inp = inp.replace(’sucks’, ’bad’)

return model(inp)

Regex based patching for using feature based patches for all experiments.