Stop denying on behalf of all of Reactome - #251
Merged
Merged
Conversation
Adam clicked a search suggestion that mixed a curator's surname with the gene he
was searching for, and got: "The information regarding the relationship between
Tello-Ruiz, IL6, and Beta-1 is not currently available in the Reactome
Knowledgebase."
That statement is false. Marcela Tello-Ruiz is in Reactome as a Person record,
dbId 72611. What the answer meant was "not in the pathway content I searched",
and the prompt told it to say the other thing: "If no relevant information exists
in Reactome, explain the information is not currently available in Reactome."
The search covers pathways, reactions, complexes, proteins, disease variants and
the user guide. Reactome also holds curators, authors, literature references and
much else that is not in this index, so "not in Reactome" is a claim this answer
is not in a position to make.
Measured, four runs each, before and after:
before: all four CONFABULATED -- "The relationship between Tello-Ruiz, IL6, and
Beta-1 can be understood through their involvement in specific
molecular..." -- inventing a role for a person's surname
after: all four scoped the denial correctly and named Tello-Ruiz as the part
not found
The confabulation is worse than the reported overclaim and would have been missed
by measuring denials alone, because inventing a relationship is not a denial. It
was only visible by reading the text.
My first detector matched "not found in the Reactome pathway content searched" --
the correct phrasing -- and scored the working fix as failing. Corrected with a
negative lookahead and validated against four known-good and known-bad strings
before being trusted.
Answer sweep 15/15 with MCP configured, so normal answers are unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The adversarial review of this branch found that I had fixed one instance of a
bug that existed in four. The same instruction -- deny on behalf of an entire
database -- was also in:
src/retrievers/plantreactome/prompt.py "not currently available in Plant Reactome"
src/retrievers/uniprot/prompt.py "not currently available in UniProt"
src/agent/tasks/cross_database/summarize_reactome_uniprot.py
"not currently available in Reactome or UniProt"
Each is wrong for the same reason: only an indexed subset is searched, and the
databases hold far more. The UniProt one is the starkest -- our index is a small
slice of UniProt, so "not in UniProt" is almost always a false statement.
This is the shape the website session named this morning: a second caller kept
doing the wrong thing after the first was fixed. I only found it by grepping for
the pattern after fixing the reported instance, which is the habit worth keeping
rather than the finding.
Measured only for the Reactome path: the answer sweep is 15/15 and six
thinner questions show no over-refusal (0/6 both before and after) and no
citation loss (51 vs 52). The Plant Reactome, UniProt and cross-database prompts
are corrected by the same construction but are not exercised by the sweep, so
that is an argument from consistency rather than a measurement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adam clicked a search suggestion that mixed a curator's surname with the gene he was searching for, and got:
That statement is false. Marcela Tello-Ruiz is in Reactome as a
Personrecord, dbId 72611, Cold Spring Harbor Laboratory.The prompt told it to say that
The search covers pathways, reactions, complexes, proteins, disease variants and the user guide. Reactome also holds curators, authors, literature references and much else that is not in this index — so "not in Reactome" is a claim this answer is not in a position to make. It now says the answer was not found in the Reactome pathway content searched, and names the part it could not find rather than describing it.
What the measurement showed, and it is worse than the report
Four runs each, before and after:
The confabulation is worse than the reported overclaim, and measuring denials alone would have missed it — inventing a relationship is not a denial. It was only visible by reading the text.
My first detector scored the working fix as broken
It matched
not found in (the )?Reactome\b— which also matches the correct phrasing, "not found in the Reactome pathway content searched". So the fix looked like it was failing 1 in 4 runs when it was working.Corrected with a negative lookahead and validated against four known-good and known-bad strings before being trusted:
Verification
Not fixed here
The root cause is in the search suggester, not in us:
suggestreturns untyped strings, sotello-ruizcan sit besideil6rand a click can build a nonsense query. That is the website's, they have diagnosed it, and the fix belongs in ContentService. This change makes our answer honest when such a question arrives anyway.🤖 Generated with Claude Code