weightedKeywordScore
@forge/monorepo / backend/src / weightedKeywordScore
Function: weightedKeywordScore()
weightedKeywordScore(
entry,queryTerms):number
Defined in: backend/src/tools/find.ts:152
The same score, divided by document length — and this is what fixed a real ranking defect.
The 200-tool measurement found find_tools returning archive_post_metrics above get_post_metrics. Both
match the query's terms identically, so the raw scores tied and the tie-break — alphabetical by name — decided
it. Alphabetical order is arbitrary with respect to relevance, and in a catalogue whose near-duplicates are
<verb>_<object> it is systematically wrong: it prefers whichever verb sorts earliest.
Length normalisation is the standard answer and it is the correct one here rather than a fitted one: the
distractors are the base tool's description plus a qualifier, so they say the same thing less densely. A
short, focused description that matches your query is a better match than a long one that matches it
incidentally. sqrt rather than a linear divisor, as in BM25, so a genuinely detailed description is not
punished out of contention.
The raw score still decides the floor (see MIN_KEYWORD_SCORE); this decides the order. Two values,
because "is this a match at all" and "which match is better" are different questions.
Parameters
entry
queryTerms
readonly string[]
Returns
number