三种搜索系统技术解析

Entire.io团队构建了三个对比系统来测试不同的优化假设。本章深入解析这三种系统的技术架构、设计哲学和核心差异。

系统概览

flowchart LR
    subgraph "基线系统"
        A[ripgrep] --> A1[极简后处理]
        A1 --> A2[按原顺序返回]
    end
    
    subgraph "速度优化系统"
        B[fff] --> B1[bigram索引]
        B --> B2[mmap内存映射]
        B --> B3[SIMD加速扫描]
        B --> B4[frecency排名]
    end
    
    subgraph "质量优化系统"
        C[pgr] --> C1[定义优先]
        C --> C2[源代码>测试/vendor]
        C --> C3[分组输出]
        C --> C4[代理友好呈现]
    end
    
    style A fill:#ffebee
    style B fill:#fff3e0
    style C fill:#e8f5e9

系统一：ripgrep（基线控制组）

设计哲学

ripgrep作为控制组,回答一个基本问题：使用标准强本地搜索工具且无额外智能时,代理的搜索行为如何？

技术实现

ripgrep是Rust编写的高性能代码搜索工具,特点包括：

• 默认递归搜索：自动遍历目录树
• 智能过滤：自动忽略.gitignore、隐藏文件和binary文件
• 正则表达式支持：完整PCRE2正则
• 并行处理：多线程搜索

在本研究中,ripgrep配置为：

# 研究中的ripgrep使用方式
rg --line-number --column --color never \
   --no-heading --trim --max-count 100 \
   "$QUERY" .

关键特性

结果排序：ripgrep返回结果的顺序即其扫描顺序——通常是文件系统顺序或并行处理顺序,无智能排名。

输出格式：原始文本输出,包含文件名、行号、匹配行内容。

file1.rs:10:fn main() {
file2.rs:5:pub struct CheckpointStore
file1.rs:25:let store = CheckpointStore::new();

作为基线的合理性

选择ripgrep作为基线的原因：

1. 行业标准：ripgrep是代码搜索的事实标准
2. 性能优秀：已优化的本地搜索工具,非低效实现
3. 广泛采用：大多数AI代理和IDE使用类似工具
4. 公平对比：确保任何改进都源于新方法,而非基线低效

系统二：fff（速度极致优化）

设计哲学

fff的核心假设是：如果搜索延迟是主要瓶颈,那么极大提升速度应该带来显著端到端改善。

技术架构

fff是一个有状态MCP(Model Context Protocol)搜索服务器,采用多项高级优化技术：

flowchart TD
    A[查询输入] --> B[bigram索引查找]
    B --> C[候选文件列表]
    C --> D[mmap内存映射]
    D --> E[SIMD并行扫描]
    E --> F[匹配行提取]
    F --> G[frecency排名]
    G --> H[结果返回]
    
    subgraph "索引层"
        B
    end
    
    subgraph "扫描层"
        D
        E
        F
    end
    
    subgraph "排名层"
        G
    end
    
    style B fill:#e3f2fd
    style E fill:#f3e5f5
    style G fill:#e8f5e9

核心技术详解

1. bigram索引（双字母组合索引）

// 概念性bigram索引实现
struct BigramIndex {
    // 映射每个bigram到包含它的文件列表
    index: HashMap<String, Vec<FileId>>,
    // 示例："ab" -> [file1, file5, file12]
}

fn build_bigram_index(files: &[PathBuf]) -> BigramIndex {
    let mut index = HashMap::new();
    for file in files {
        let content = fs::read_to_string(file)?;
        for bigram in extract_bigrams(&content) {
            index.entry(bigram)
                 .or_insert_with(Vec::new)
                 .push(file.id());
        }
    }
    BigramIndex { index }
}

优势：快速缩小候选文件范围,避免全文件系统扫描。

局限：

• 内存占用高（需存储所有bigram映射）
• 增量更新复杂（文件变更需重建部分索引）
• 对短查询效果有限

2. mmap内存映射

// 使用mmap而非read_file
use memmap2::Mmap;

fn scan_file_mmap(path: &Path) -> io::Result<Vec<Match>> {
    let file = File::open(path)?;
    let mmap = unsafe { Mmap::map(&file)? };
    
    // 直接在内存中扫描,避免系统调用开销
    find_matches(&mmap)
}

优势：

• 避免用户态/内核态切换开销
• 利用操作系统页缓存
• 支持惰性加载（只访问需要的部分）

劣势：

• 复杂错误处理（SIGBUS信号）
• 大文件可能耗尽虚拟地址空间
• 不适用于所有文件系统

3. SIMD加速扫描

// 概念性SIMD字符串匹配（使用AVX2）
#[cfg(target_arch = "x86_64")]
use std::arch::x86_64::*;

fn simd_search(haystack: &[u8], needle: &[u8]) -> Vec<usize> {
    unsafe {
        let mut matches = Vec::new();
        let needle_vec = _mm256_loadu_si256(needle.as_ptr() as *const __m256i);
        
        // 每次处理32字节
        for chunk in haystack.chunks_exact(32) {
            let data = _mm256_loadu_si256(chunk.as_ptr() as *const __m256i);
            let cmp = _mm256_cmpeq_epi8(data, needle_vec);
            let mask = _mm256_movemask_epi8(cmp);
            
            // 处理匹配位
            if mask != 0 {
                // 提取匹配位置...
            }
        }
        matches
    }
}

实测性能提升：在现代x86_64处理器上,SIMD扫描可比标量扫描快3-5倍。

4. frecency排名

frecency(frequency + recency)是Firefox浏览器首先使用的排名算法,结合：

• frequency：访问频率（长期重要性）
• recency：最近访问时间（短期相关性）

fn frecency_score(access_count: u32, last_access: SystemTime) -> f64 {
    let days_since = now.duration_since(last_access).as_secs() / 86400;
    let time_decay = (-days_since as f64 / 30.0).exp(); // 30天半衰期
    
    access_count as f64 * time_decay
}

fff的性能表现

搜索延迟对比（来自Entire研究）：

这是一个惊人的速度提升：中位数延迟降低8.6倍,几乎消除了搜索执行时间。

但端到端影响如何？

核心发现：即使搜索速度快了8.6倍,端到端性能仅提升4.1%。为什么？

因为工具执行时间原本就只占总时间的0.4%。即使完全消除这0.4%,最大改善也只有0.4%。

flowchart LR
    subgraph "38.57秒总运行时间"
        A[工具执行]:::tiny
        B[模型推理 约30秒]:::large
        C[结果解析 约5秒]:::medium
        D[决策规划 约3秒]:::medium
    end
    
    A -->|仅占| A1[0.4%]
    
    classDef tiny fill:#ffcdd2,stroke:#f44336
    classDef medium fill:#fff9c4,stroke:#ffeb3b
    classDef large fill:#c8e6c9,stroke:#4caf50

fff的价值：反证假设

fff并未带来预期的端到端改善,但这恰恰是它的价值所在：它证明了速度不是主要瓶颈。

如果没有fff这个极端优化案例,开发者可能会持续投资于速度优化,永远无法发现真正的优化机会在于搜索结果质量。

系统三：pgr（质量优化系统）

设计哲学

pgr的核心假设是：真正重要的是代理首先看到什么。优化结果的呈现顺序和相关性,可以减少代理的探索次数。

与fff追求速度不同,pgr追求有用性。

技术架构

flowchart TD
    A[查询输入] --> B[候选检索]
    B --> C1[定义识别]
    B --> C2[路径分析]
    B --> C3[上下文评估]
    
    C1 --> D[排名算法]
    C2 --> D
    C3 --> D
    
    D --> E[定义优先]
    E --> F[源码>测试/vendor]
    F --> G[分组呈现]
    G --> H[精简输出]
    H --> I[结果返回]
    
    subgraph "理解层"
        C1
        C2
        C3
    end
    
    subgraph "排名层"
        D
        E
        F
    end
    
    subgraph "呈现层"
        G
        H
    end
    
    style D fill:#e8f5e9
    style E fill:#e8f5e9
    style F fill:#e8f5e9

核心优化策略

1. 定义优先（Definitions First）

代理搜索时通常寻找：

• 函数/方法定义
• 结构体/类定义
• 常量/变量定义
• 接口/ trait定义

pgr策略：优先返回定义位置,而非所有匹配。

// 代码分析识别定义模式
fn is_definition(line: &str, language: Language) -> bool {
    match language {
        Language::Rust => {
            line.contains("fn ") ||      // 函数
            line.contains("struct ") ||  // 结构体
            line.contains("enum ") ||    // 枚举
            line.contains("trait ") ||   // trait
            line.contains("impl ")       // 实现
        }
        Language::TypeScript => {
            line.contains("function ") ||
            line.contains("class ") ||
            line.contains("interface ") ||
            line.contains("const ") ||
            line.contains("type ")
        }
        // ... 其他语言
    }
}

fn rank_by_definition_priority(matches: Vec<Match>) -> Vec<Match> {
    matches.into_iter()
        .map(|m| {
            let is_def = is_definition(&m.line, m.language);
            let score = if is_def { m.base_score * 2.0 } else { m.base_score };
            (m, score)
        })
        .sorted_by(|a, b| b.1.partial_cmp(&a.1).unwrap())
        .map(|(m, _)| m)
        .collect()
}

为什么有效：代理通常从定义开始理解代码,而非从使用处。定义优先减少代理的跳转次数。

2. 源代码优先于测试和vendor

代理搜索时经常遇到：

• 测试文件中的mock实现
• vendor目录的第三方代码
• generated自动生成的代码
• build产物

pgr策略：降级非核心代码的排名。

fn path_priority_score(path: &Path) -> f64 {
    let path_str = path.to_string_lossy();
    
    // 降低优先级的模式
    if path_str.contains("test") || 
       path_str.contains("spec") ||
       path_str.contains("vendor") ||
       path_str.contains("node_modules") ||
       path_str.contains("generated") ||
       path_str.contains("target/") ||
       path_str.contains("dist/") {
        return 0.3; // 大幅降级
    }
    
    // 提升优先级的模式
    if path_str.contains("src/") ||
       path_str.contains("lib/") ||
       path_str.contains("core/") {
        return 1.5; // 适度提升
    }
    
    1.0 // 默认
}

为什么有效：减少代理在无关文件中的探索,更快定位到实际业务逻辑。

3. 分组和精简输出

ripgrep默认返回所有匹配行,可能导致信息过载。代理需要处理大量文本才能找到真正需要的。

pgr策略：

• 按文件分组,而非按匹配行
• 每个文件只展示最相关的几行
• 高亮定义和关键调用点

fn format_results_grouped(matches: Vec<Match>, max_files: usize) -> String {
    let grouped = matches.into_iter()
        .group_by(|m| m.file.clone())
        .into_iter()
        .take(max_files)
        .collect::<Vec<_>>();
    
    let mut output = String::new();
    for (file, file_matches) in grouped {
        output.push_str(&format!("\n📄 {}\n", file.display()));
        
        // 只展示前3个最相关的匹配
        let top_matches = file_matches.into_iter()
            .take(3)
            .collect::<Vec<_>>();
        
        for m in top_matches {
            let icon = if m.is_definition { "🔧" } else { "📍" };
            output.push_str(&format!("  {} {}:{} {}\n", 
                icon, m.line_num, m.col, m.line));
        }
    }
    output
}

示例输出对比：

ripgrep输出（可能返回20+匹配行）：

file1.rs:10:fn main() {
file1.rs:25:let store = CheckpointStore::new();
file1.rs:50:store.save(checkpoint);
test/mock.rs:15:struct MockCheckpointStore;
test/mock.rs:20:impl CheckpointStore for MockCheckpointStore {
vendor/lib.rs:100:pub struct CheckpointStore;
...
（更多匹配行）

pgr输出（分组且精简）：

📄 src/store.rs
  🔧 15:pub struct CheckpointStore {
  📍 30:impl CheckpointStore {

📄 src/main.rs
  📍 25:let store = CheckpointStore::new();

📄 tests/integration.rs
  📍 15:let store = CheckpointStore::new_test();

MCP服务器接口

pgr作为MCP服务器,通过JSON-RPC与代理通信：

// 初始化请求
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {}
}

// 列出工具
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

// 调用搜索
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "search_code",
    "arguments": {
      "query": "CheckpointStore",
      "max_files": 5
    }
  }
}

接口设计刻意简单,与代理现有工作流无缝集成。

三种系统的技术差异总结

radar-beta
    title "三种系统特性对比"
    axis search_speed "搜索速度"
    axis ranking_quality "排名质量"
    axis memory_usage "内存占用"
    axis implementation_complexity "实现复杂度"
    axis agent_orientation "代理友好度"
    
    
    
    data ripgrep "ripgrep" [70, 30, 90, 20, 40]
    data fff "fff" [100, 50, 40, 90, 50]
    data pgr "pgr" [75, 95, 80, 60, 100]

为什么pgr的架构选择有效？

代理vs人类的不同需求

pgr的设计完全针对代理的认知特点：

• 定义优先：为代理提供明确的探索起点
• 降噪：减少无关文件干扰代理决策
• 精简输出：降低代理处理信息的负担
• 结构化呈现：代理更容易解析和利用结果

技术权衡的合理性

pgr在以下方面做出了权衡：

1. 牺牲极致速度换取智能：没有采用SIMD等复杂优化,但增加了语义分析
2. 适度内存使用换取排名质量：缓存文件元数据用于路径分析
3. 增加复杂度换取代理友好度：理解代码结构和代理工作流程

这些权衡的根本依据是研究数据：代理的时间开销不在搜索执行,而在搜索后的处理。因此,让搜索结果更有用比让搜索更快更有价值。

小结

三种系统代表了三种不同的优化哲学：

1. ripgrep（基线）：证明现有工具的能力边界
2. fff（速度）：证明速度不是主要瓶颈（反证假设）
3. pgr（质量）：证明结果排名和呈现方式的重要性

技术实现上,fff采用了bigram索引、mmap、SIMD等高级优化,将搜索延迟降低8.6倍。而pgr则采用相对简单的启发式排名和结构化输出,在检索质量指标上取得显著改善。

核心启示：不要优化已经够快的部分,而要优化真正影响结果的部分。