Refinement of PFOCR Result-level Enrichment

[AlexanderPico]

We've been assessing the result-level enrichment/augmentation with PFOCR hits. The output today has some consistent issues:

• Too many hits (burden on performance?)
• Low quality, irrelevant hits

In parallel, we've been assessing the edge retrieval hits on the same queries and have been pleasantly surprised by the quality. This observation suggests some specific refinements we might pursue...

Using an MVP2 query of "Genes increased by Bivalirudin" as an example, currently, we traverseResultForNodes to collect a set of genes, including subject and object (answer) nodes, along with any intermediate nodes (from 2-hop), and then perform an intersection. We require a MATCH_COUNT_MIN = 2 and calculate a score based on precision and recall.

This is too relaxed. We end up with a ton of hits having 2 matching CURIES, sometimes not include either of the original subject or object nodes. Each of these on their own is a fairly weak and useless finding for researchers.

Proposals:

1. Focus on subject and object nodes. Once we are able to consider chemicals and diseases, then we could perform an intersection where resultCuries are restricted to just those two nodes. This would dramatically reduce the number of PFOCR hits, while dramatically increasing their relevance.
   • We could follow-up these hits with a secondary intersection including the other nodes from traverseResultForNodes in order to get a total resultGenesInFigure to be used in the calculation of precision, i.e., for scoring. Both the traversal and the secondary intersection would only be performed on the subset of figures that pass the first intersection, so this might be faster as well.
2. I suspect the calculation of resultGenesInOtherFigures is time consuming. If so, we could skip it and rely solely on precision to calculate a score.

[AlexanderPico]

Alt proposal: We keep the current enrichment algo as-is, applied to all nodes from traverseResultForNodes and then add a secondary filter to only keep hits that contain both the input entity (subject) and answer (object).

Advantages:

• Easier to implement given existing code base, i.e., just add a filter step
• More flexible solution that could be adapted to require only input entity or answer, for example

Disadvantages:

• Might be slower? Not sure about this actually.

[tokebe]

Given the times we're seeing with the present queries to BioThings PFOCR (>15 seconds per batch), it makes more sense to me to reduce back down to just querying for subject and object, and then doing a secondary traverseResultsForNodes for better scoring.

[tokebe]

As of https://github.com/biothings/bte_trapi_query_graph_handler/pull/211, we are no longer traversing the entire result for nodes, instead just looking at direct result-bound nodes. We do traverse results after to increase the node pool, which is used for relevancy ranking. Additionally, the scoring function has been made less expensive in https://github.com/biothings/bte_trapi_query_graph_handler/pull/207

So, the scope of this issue is changed to two objectives:

• Fix behavior in creative mode so enrichment only occurs at the end (this will prevent template-related figures that are not necessarily matching the creative-result nodes)
• Add additional node type support so we can do enrichment on more types of queries