확신을 만들지 않는 fusion

score scale은 서로 달라

FTS의 bm25와 vector cosine은 숫자 모양부터 달라. 하나는 낮을수록 좋을 수 있고 다른 하나는 높을수록 비슷해. min-max normalize해서 더하면 query마다 분포가 바뀌고 0.8이라는 숫자가 무슨 뜻인지 설명하기 어렵다.

RRF는 raw score 대신 각 list의 rank만 사용해. 두 lane 모두에서 앞선 item을 보상하면서 scale calibration을 피한다. 단순해서 robust하고 lane을 추가하기도 쉽다.

fusion score는 확률이 아니야

RRF가 0.03이라고 truth probability 3%가 아니고 0.08이라고 merge confidence 80%도 아니야. rank position을 합친 ordering signal일 뿐이야. UI에서 percent나 confidence라고 쓰면 수학보다 강한 의미를 만들어.

label은 Hybrid rank나 combined order처럼 제한적으로 쓰고, item detail에는 각 lane rank와 match reason을 보여줘. score를 감춰도 되지만 provenance를 감추면 안 돼.

missing lane도 상태야

embedding service가 내려가면 lexical-only result를 계속 제공할 수 있어. 다만 fused인 척하지 말고 Meaning lane unavailable을 표시해야 해. partial service를 complete evidence로 포장하면 사용자는 relevance 변화를 content 변화로 오해해.

반대로 FTS rebuild 중 vector-only가 가능할 수도 있어. degradation policy는 lane 독립성을 살리고, health state와 result state를 연결해. query가 0 results인지 lane이 0 available인지 구분해야 해.

평가는 query set으로 해

한 query에서 좋은 result가 위에 왔다고 fusion이 좋다고 결론 내리지 마. exact names, Korean paraphrase, short acronym, long conceptual query처럼 class가 다른 fixed set을 만들고 lexical, vector, fused의 top-k를 비교해.

평가 label도 사람이 source를 읽고 relevance를 판정한 것만 써. click 수는 position bias가 있고, curation UI의 open은 relevant라서가 아니라 이상해서일 수 있어. behavioral proxy를 ground truth로 만들지 마.

rank fusion은 evidence를 정렬할 뿐 confidence를 발명하지 않아. 서로 다른 lane의 scale을 섞지 말고 rank, availability, match reason을 그대로 보여줘.

Code

Reciprocal Rank Fusion의 작은 구현·python

def rrf(rankings, k=60):
    scores = {}
    for ranking in rankings:
        for rank, item in enumerate(ranking, start=1):
            scores[item] = scores.get(item, 0) + 1 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

text = ["a", "b", "c"]
meaning = ["b", "d", "a"]
assert rrf([text, meaning])[0] in {"a", "b"}

score scale은 서로 달라

fusion score는 확률이 아니야

missing lane도 상태야

평가는 query set으로 해

Code

External links

Exercise

Progress

댓글 0