Skip to content

411 implement combimatch to improve reasoner performance#526

Merged
bnouwt merged 19 commits intomasterfrom
411-implement-combimatch-to-improve-reasoner-performance
Aug 23, 2024
Merged

411 implement combimatch to improve reasoner performance#526
bnouwt merged 19 commits intomasterfrom
411-implement-combimatch-to-improve-reasoner-performance

Conversation

@bnouwt
Copy link
Copy Markdown
Collaborator

@bnouwt bnouwt commented Aug 23, 2024

No description provided.

bnouwt and others added 18 commits June 27, 2024 13:02
Look at this later, because is this how we want it?
Had to introduce new strategy that limits the full matching to a single
rule. This was neccesary to make meta-knowledge-interactions work
faster.

Also had to remove some invert match code, which I found strange, but
had to do to make it work.

There are still quite some tests the fail, so those need to be fixed
first. Starting with the looping test.
Included matching configuration using Enums and mapped those to 4 levels
of interoperability.

Knowledge Gaps are not yet working, so the
TestDynamicSemanticComposition test is not yet working.

Also, the matching algorithm needs to also support the highest levels.
However, it does not fully work yet. Some tests are still failing and we
need to compare whether the results are comparable with the previous
graph pattern matcher. Also, maybe discuss the different levels of
interoperability with others and make sure the TKE fits into that.

Extra configuration options to add to TKE (as opposed to reasoner):
- do not include meta graph patterns (ReasonerProcessor)
- only go one level deep with reasoning
(ReasoningPlan#createOrGetReasoningNode)
Things still to do:
- replace matcher with reasoner? and remove matcher?
- more testing on performance?
This configuration options allows the user to configure whether the meta
KIs of the Knowledge Engine should be included when executing a
particular user KI.

Also removed the SerialMatchingProcessor entirely and always use the
ReasonerProcessor.
- correctly dealing with splitted forward reasoning.
- make biggest matches not contain too many matches (which are actually
not biggest).
Using default Java Collections parallelism really improves the
performances and makes it utilize multiple CPU cores much better.

Although it is not enough, because there are just too many bindings that
need to be merged.
411-implement-combimatch-to-improve-reasoner-performance

Also added a debugging mechanism to help finding out why the reasoner
does not return the info you expect.
Mainly:
- took over error messages from serialmatchingprocessor in reasoning
processor.
- also include binding set validation in Java API, instead of only in
REST API.
@bnouwt bnouwt linked an issue Aug 23, 2024 that may be closed by this pull request
Although that is not necessarily caused by the new matching algorithm.
@bnouwt bnouwt merged commit 261fd41 into master Aug 23, 2024
@bnouwt bnouwt deleted the 411-implement-combimatch-to-improve-reasoner-performance branch August 23, 2024 15:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement CombiMatch to improve reasoner performance

1 participant