Node.js 醫療科技更新日誌排序：比較 BM25 與向量檢索，選用混合訊號

Short answer: for a healthtech developer changelog tracker, keep BM25 as the fast lexical gate, add vector similarity for meaning, and let a small, measured reranker decide only among the surviving candidates. That hybrid retrieval architecture usually gives better relevance without putting every query on the slowest path. The choice should be made from a latency budget and judged on an error set, not from a pleasing demo.

I care about the storage boundary because ranking is only as trustworthy as the evidence it can retrieve. A changelog entry with a precise version, API name, and deprecation date is not interchangeable with a semantically similar troubleshooting note. Losing that distinction makes a search result look helpful while quietly sending an engineer toward the wrong migration.

What the bill and latency budget are actually made of

The dominant term is often candidate work, not the final score formula. If a query fans out to a lexical index, a vector index, and then a cross-encoder, each additional candidate consumes CPU, memory bandwidth, and tail latency. A 120 ms p95 target can disappear when a reranker sees 200 passages instead of 40, even if the embedding lookup itself is quick.

Measure the stages separately: tokenization, lexical retrieval, vector retrieval, feature assembly, reranking, and storage reads. Store the candidate count and stage timings with the query trace. I once treated the reranker as the expensive part because its model looked impressive; the trace showed that fetching oversized payloads from the document store was the slower operation. That was a 6 ms fix, not a model rewrite.

Retention has a similar shape. Keep the searchable text, a stable entry ID, product area, version range, publication timestamp, and a pointer to the source document. Do not retain every rendered HTML fragment in the hot index. Older fragments increase index size and create duplicate evidence; move raw snapshots to colder storage with a documented retention period. The catch is that deleting them weakens incident reconstruction, so keep enough immutable source metadata to explain why a result was selected.

How should a healthtech changelog tracker combine retrieval architecture and ranking signals?

Use a staged design. BM25 (or another inverted-index scorer) first retrieves exact terms such as FHIR, v2.3, or webhook. Vector search runs in parallel for paraphrases such as “patient identifier format changed.” Merge the two lists by stable entry ID, then calculate a compact feature vector: lexical score, vector score, field match, freshness, version compatibility, and a duplicate penalty. Only then call a learned reranker, and only for the top slice.

The order matters. A freshness score should not resurrect a document that fails the requested version constraint, and semantic similarity should not outrank an exact API token when the query contains a quoted identifier. Treat hard constraints as filters or gates; treat soft signals as ranking features.

from dataclasses import dataclass
from math import log
from typing import Iterable


@dataclass(frozen=True)
class Entry:
    entry_id: str
    lexical: float
    vector: float
    field_match: float
    freshness_days: int
    version_ok: bool
    duplicate: bool


def rank_key(entry: Entry) -> tuple[float, str]:
    if not entry.version_ok:
        return (-float("inf"), entry.entry_id)
    freshness = 1.0 / (1.0 + log(1.0 + entry.freshness_days))
    duplicate_penalty = 0.18 if entry.duplicate else 0.0
    score = (
        0.42 * entry.lexical
        + 0.30 * entry.vector
        + 0.18 * entry.field_match
        + 0.10 * freshness
        - duplicate_penalty
    )
    return (score, entry.entry_id)


def choose_candidates(rows: Iterable[Entry], limit: int = 40) -> list[Entry]:
    eligible = [row for row in rows if row.version_ok]
    return sorted(eligible, key=rank_key, reverse=True)[:limit]

Those weights are an example of an interface, not a universal truth. Fit them against labeled queries, then freeze a version of the feature definition so a later result can be reproduced. A tie-break on the stable ID is deliberately dull; nondeterministic ties make evaluation and audit logs difficult to compare.

Failure modes that make a good score misleading

The first failure is version leakage: a result for a retired endpoint wins because it has more words in common with the query. The second is duplicate amplification: one announcement is chunked into six near-identical passages and occupies the whole top ten. The third is freshness overreach: a new note about an unrelated product area outranks an older, exact migration instruction.

There is a fourth failure that storage teams notice early: metadata drift. If the index says an entry applies to v2.3 but the source record was edited to v2.4, the ranking pipeline can be internally consistent and still wrong. Use an immutable entry ID, an update timestamp, and a source checksum; re-index on change and retain the previous metadata long enough to investigate a bad answer.

Keep one short rule visible.

Latency wins.

Evaluation needs adversarial queries, not just average relevance. Include exact identifiers, misspellings, mixed-version requests, and questions whose answer is “no matching change.” Track recall at the candidate gate, nDCG or reciprocal rank for ordering, and p95/p99 latency by stage. Your mileage may vary: a hospital integration with strict version pinning will value hard filtering more than a broad internal knowledge search.

Which implementation boundary should the team choose?

The comparison is between retrieval shapes, not brands.

Shape	Relevance strength	Latency and storage cost	Use it when
BM25 only	Excellent for identifiers and exact versions	Low and predictable	Changelog vocabulary is stable and queries are literal
Vector only	Handles paraphrase and synonyms	Embedding/index work; weak on exact tokens	Queries are mostly natural-language descriptions
Hybrid plus bounded reranker	Balances exactness and meaning	More moving parts and tail-latency risk	Relevance errors are costly and a measured budget exists
Reranker over every document	Can model nuanced matches	Usually unacceptable latency and cost	Offline analysis only, never the request path

Node.js can coordinate the fan-out, but the protocol between stages should stay generic: query ID, candidate IDs, scores, and versioned metadata. Keep the source of truth outside the search index. If the index is rebuilt, the application should not lose the audit trail or silently change an entry's retention policy.

The approach is not suitable when the team cannot label queries, observe tail latency, or enforce version metadata at ingestion. Stick with a lexical gate in that situation and add semantic retrieval after those controls exist. A more complex stack without measurement is an expensive way to hide uncertainty.