# What is Reciprocal Rank Fusion (RRF) and How It Powers LLM Wiki Search

> Discover Reciprocal Rank Fusion RRF a powerful ranking technique that unifies LLM Wiki search results from filenames phrases and relevance for superior accuracy and efficiency.

- Repository: [nash_su/llm_wiki](https://github.com/nashsu/llm_wiki)
- Tags: deep-dive
- Published: 2026-09-12

---

**Reciprocal Rank Fusion (RRF) is a ranking aggregation technique that combines multiple ordered search results by summing the reciprocal of each document’s rank plus a constant, and the nashsu/llm_wiki repository leverages this algorithm in [`src-tauri/src/commands/search.rs`](https://github.com/nashsu/llm_wiki/blob/main/src-tauri/src/commands/search.rs) to unify filename matches, phrase detection, and graph-based relevance into a single sorted list.**

When searching large knowledge bases, relying on a single relevance signal often yields incomplete results. The **nashsu/llm_wiki** repository addresses this limitation by implementing **Reciprocal Rank Fusion (RRF)** to merge distinct retrieval strategies into one coherent ranking. This approach ensures that documents consistently placed near the top of multiple independent searches rise to the top of the final result set.

## Understanding the Reciprocal Rank Fusion Algorithm

RRF aggregates ranked lists from multiple retrieval models without requiring score calibration between systems. For each document appearing in a result list, the algorithm assigns a score of **1/(k + rank)**, where **k** is a constant smoothing factor and **rank** is the document’s position in that specific list (1-indexed). Documents appearing in multiple lists accumulate higher scores, while those ranked lower contribute diminishing values.

The formula effectively normalizes positional information across different search strategies, allowing boolean matchers, vector similarity, and graph-based scoring to contribute equally to the final ordering.

## RRF Implementation in LLM Wiki's Search System

The search architecture in `nashsu/llm_wiki` implements RRF in Rust to fuse five distinct relevance signals before returning results to the TypeScript frontend.

### Core Constant and Configuration

In [`src-tauri/src/commands/search.rs`](https://github.com/nashsu/llm_wiki/blob/main/src-tauri/src/commands/search.rs), the RRF constant is defined at line 14:

```rust
const RRF_K: f64 = 60.0;

```

This constant mitigates the impact of low-ranked outliers while preserving discriminative power at the top of each result list. The value 60.0 represents a balance between harsh rank penalties and score granularity.

### Aggregating Multiple Relevance Signals

LLM Wiki applies RRF to combine several specialized retrieval strategies:

- **Exact-filename matches**: Receives a bonus of +200
- **Phrase matches in titles**: Receives a bonus of +50
- **Phrase matches in content**: Receives +20 per occurrence (capped at 10 occurrences)
- **Token-level scores**: Weighted at 5:1 for title versus content
- **Graph-based relevance**: Scores derived from the internal link graph structure

Each signal produces its own ranked list of candidate documents. The system then calculates the RRF contribution for each document within its respective list using the formula found at lines 495-498:

```rust
// For a document at position `rank` in a specific signal's result list
let rrf_increment = 1.0 / (RRF_K + rank as f64);
rrf_total += rrf_increment;

```

### Final Score Composition and Frontend Sorting

After aggregating the reciprocal rank contributions, the system combines this value with graph-based relevance at line 650:

```rust
score: graph_score / (RRF_K + 1.0)

```

This final `score` field attaches to each `ProjectSearchResult` object returned to the client. The frontend component [`src/components/search/search-view.tsx`](https://github.com/nashsu/llm_wiki/blob/main/src/components/search/search-view.tsx) receives these fused scores and sorts the results at line 69:

```typescript
// Results arrive with pre-computed RRF-derived scores
const sorted = results.sort((a, b) => b.score - a.score);

```

This ensures the UI presents documents in strict adherence to the aggregated RRF ranking without requiring additional client-side computation.

## Code Examples

The following Rust snippet demonstrates the complete RRF calculation pipeline used during the search command execution:

```rust
// src-tauri/src/commands/search.rs
const RRF_K: f64 = 60.0;

fn calculate_fused_score(document_rankings: Vec<usize>, graph_score: f64) -> f64 {
    let rrf_sum: f64 = document_rankings
        .iter()
        .map(|rank| 1.0 / (RRF_K + *rank as f64))
        .sum();
    
    // Combine with graph relevance as implemented at line 650
    let final_score = graph_score / (RRF_K + 1.0);
    final_score + rrf_sum
}

```

The corresponding TypeScript interface ensures type safety for the scored results:

```typescript
// src/components/search/search-view.tsx
interface ProjectSearchResult {
  id: string;
  title: string;
  score: number; // RRF-derived fusion score
  snippet: string;
}

// Sorting implementation at line 69
const sortedResults = searchResults.sort((a, b) => b.score - a.score);

```

Unit tests in [`src/lib/search-rrf.test.ts`](https://github.com/nashsu/llm_wiki/blob/main/src/lib/search-rrf.test.ts) validate the mathematical properties of the fusion algorithm:

```typescript
import { rrfScore } from "./search-rrf";

test("RRF combines multiple source ranks correctly", () => {
  const ranks = [1, 2, 5]; // Positions across three different signals
  const expected = 1.0/(60+1) + 1.0/(60+2) + 1.0/(60+5);
  expect(rrfScore(ranks)).toBeCloseTo(expected);
});

```

## Summary

- **Reciprocal Rank Fusion** combines multiple ranked lists using the formula **1/(k + rank)** to normalize across different search strategies.
- The **nashsu/llm_wiki** implementation uses a constant **RRF_K = 60.0** defined in [`src-tauri/src/commands/search.rs`](https://github.com/nashsu/llm_wiki/blob/main/src-tauri/src/commands/search.rs) to stabilize rankings.
- Five distinct signals contribute to the fusion: exact filename matches, title phrases, content phrases, token-level matches, and graph-based relevance.
- Final scores are computed in Rust and sorted in the frontend component [`search-view.tsx`](https://github.com/nashsu/llm_wiki/blob/main/search-view.tsx), ensuring consistent ranking across the application.

## Frequently Asked Questions

### What is the exact RRF formula implemented in LLM Wiki?

The implementation uses the standard reciprocal rank formula **1/(RRF_K + rank)** where `RRF_K` is defined as `60.0` in [`src-tauri/src/commands/search.rs`](https://github.com/nashsu/llm_wiki/blob/main/src-tauri/src/commands/search.rs) at line 14. For documents appearing in multiple result sets, the system sums these reciprocal values to produce a composite relevance score.

### Why does LLM Wiki use multiple search signals instead of a single index?

Using multiple specialized signals—such as exact filename matching (+200 bonus), phrase detection in titles (+50), and graph-based relevance—allows the system to capture different aspects of document relevance. RRF provides the mathematical framework to merge these heterogeneous signals without requiring score normalization between the disparate matching strategies.

### How does the graph score interact with the RRF calculation?

According to line 650 in [`src-tauri/src/commands/search.rs`](https://github.com/nashsu/llm_wiki/blob/main/src-tauri/src/commands/search.rs), the graph-based relevance score contributes to the final ranking through the expression `score: graph_score / (RRF_K + 1.0)`. This integrates the structural importance of documents (derived from internal link graphs) with the position-based RRF scores from content matching.

### Where does the final sorting of search results occur?

The definitive sort occurs in [`src/components/search/search-view.tsx`](https://github.com/nashsu/llm_wiki/blob/main/src/components/search/search-view.tsx) at line 69, where the frontend sorts the `ProjectSearchResult` array by the `score` field descending. This `score` value arrives pre-computed from the Rust backend, having already aggregated all RRF contributions and graph signals.