Ruflo 3.42.4 stops smart memory search from reporting the wrong similarity number

What this is about

Ruflo keeps a memory store that agents search. A plain search returns a relevance score for each result, and the field carrying that number is called similarity. Smart mode adds a second layer on top: several retrieval strategies run and their rankings are fused, which produces a different, internal number used only to decide the order of the list.

Those two numbers mean different things, and one of them had been landing in the other one's field. Anybody reading similarity out of a smart search, or filtering on it downstream, was reading a ranking artefact and treating it as a measure of how well the result matched.

What changed

Release v3.42.4 was published on September 17 from commit e558f0c0. It carries the fix merged as pull request #3340, which the release notes describe as Finding B of issue #3327. The release body gives a concrete example: a raw retrieval relevance of 0.8 was being reported as 0.03252247488101534, because the field was showing the internal fusion score instead.

Three things are now true that were not true before:

• similarity carries the raw retrieval relevance, so a smart search and a plain search describe a result the same way.
• The fused ranking number is still available, under its own name, rankingScore. It was not removed, only relabelled honestly.
• threshold behaviour is unchanged. It is still applied before fusion, reranking and recency weighting, so nothing you already filter on shifts underneath you.

The change ships with fourteen new regression tests across the retrieval package and the tool handler. The release notes also record two things that are easy to miss. Versions 3.42.1 to 3.42.3 went to the package registry without matching version-bump commits on the main branch, and the maintainers checked that each of those tags is an ancestor of this one, so 3.42.4 is a strict superset of everything already shipped. And Finding A of the same issue, where a vector backend reports itself as enabled while actually routing through a fallback, is still open.

Get started

Prerequisites: Node.js 22 or later and a terminal. Nothing else is required to check which version you are on.

npx ruflo@latest --version

Expected result: the command prints a version string. If it is 3.42.4 or higher, the score fix is present. If it is 3.42.0 or lower, a smart search on that installation is still reporting the fusion score as similarity.

Commands here were read from the release notes and repository documentation at the pinned reference; they were not executed as part of writing this article.

Use it today

Practical case: you have a retrieval step that discards anything below a relevance cut-off before handing results to a model. Input is a query and a cut-off. The workflow is a smart memory search, a filter on similarity, then the surviving results. The output before this release was quietly wrong, because almost everything scored far lower than it deserved and useful context was being thrown away.

Reader acceptance test: run the same query twice, once in smart mode and once without it. The similarity values should now be on the same scale in both. If the smart-mode numbers are an order of magnitude smaller, you are running an older build.

Push it further

Experimental commentary. Having both numbers separately available is more interesting than having the right one: rankingScore tells you how the fusion ordered the list, similarity tells you how relevant each item actually is, and the gap between the two orders is a readable signal about whether fusion is helping your corpus or fighting it.

Limitation: this is a reporting fix, not a retrieval-quality improvement. The ordering of results did not change, only the numbers attached to them. Depends on being on 3.42.4 or later. Falsifiable test: sort one result set by similarity and the same set by rankingScore. If the two orders are identical on your data, fusion is contributing nothing you could not get from plain relevance.